search

LX3JL / xlxd

HAM radio multiprotocol dstar reflector server
GNU General Public License v3.0
170 stars 110 forks source link

allow YSF clients to change linked module by DG-ID #197

Closed narspt closed 2 years ago

narspt commented 3 years ago

This patch adds code to allow YSF clients to change linked module by using DG-ID code, similarly to some other YSF reflectors.

Use DG-ID 01 for A, 02 for B, etc... Using DG-ID 00 (or a number higher than the number of enabled modules on reflector) will just use current linked module without any change (like without this patch)

hb9gfx commented 3 years ago

I checked this functionality, works fine, but I miss a function/parameter: After a certain time of inactivity relink to the default Module. In my case on XLX508 I have Module J as default Module set. When you connect the repeater/hotspot to XLX508 you are linked to XLX508J which should be like this. But when someone changes the Module using DG-ID it stays on this Module. It should be possible to fall back to the default module by a time after inactivity which can be defined. Example; YSF DG-ID Fallback value = 600 (10 min)

narspt commented 3 years ago

@hb9gfx: I may try later to look if I can implement that (but that would be a separate PR anyway), but honestly I don't like very much the idea of reflector forcing users to change module, without users having a way to prevent it and stay on desired module... IMO such feature should be implemented at client side and allowing user to control it, like DMRGateway allows.

LX3JL commented 2 years ago

Nice feature! Could we change the GD-id to Module letter mapping to 10 = 'A', 11 = 'B', etc.. This is to be compatible with soon to be released IMRS protocol compatibility (for Yaesu's DR-2Xcrepeaters)...

LX3JL commented 2 years ago

Also, as implemented now, the gatekeeper is bypassed, which means that an transmission from a callsign black-listed by the sysop CAN change the linked module...

LX3JL commented 2 years ago

I would suggest to put the dg-id to module in the IsValidDvHeaderPacket() function, updating there the Header rpt2 module and call the client->SetReflectorModule in the OnDvHeaderIn() function

hb9gfx commented 2 years ago

As long as the Module after linking by DG-ID to another Modul, and there is traffic, from HF site, it should stay on that module as long as there is traffic is coming. Only after a defined time no traffic is on HF site, it should fall back to the default which is defined.

narspt commented 2 years ago

@LX3JL: No problem, I can change it. Btw, am I right in thinking that rpt2 module should be ALWAYS set on IsValidDvHeaderPacket() even when not using translatable DG-ID values (i.e. set to current linked module), so that gatekeeper module white-listing feature actually works? (if I see it correctly that should be currently broken on master as ' ' module is always passed to MayTransmit() and think that is also a problem on DMR protocol? )

narspt commented 2 years ago

@LX3JL: I did just commit an update to change DG-ID module letter mapping and fix gatekeeper bypass when changing module as you requested.

Concerning the gatekeeper module white-listing issue I did mention on my last comment, when using non-translatable DG-ID values, I did leave it untouched as I'm not sure I should overcomplex things due to that or how you may want to fix it exactly... and anyway it is out of the scope of this PR. Also I did test and confirm the issue exists with DMR protocol also, actually worst as on DMR you are really able to connect to a non white-listed module, while on YSF you are not able to link (after my update) but if already linked (for eg. on public repeater - linked by other operator) you are then able to TX when using non-translatable DG-ID even if you don't match the white-list.

LX3JL commented 2 years ago

Excellent. thanks