Bridge application that identifies known bridges based on RADIO ID and
does NOT bridge if they are actively connected to an IPSC and MODE byte
shows linking on a timeslot.
If a peer “re-registers” we were not updating it’s registration
information. For example, it may have changed it’s MODE byte, or worse,
it’s port number, etc. and we’d have missed it
Previously, an unauthenticated network used a different class that
subclassed IPSC and overrode the the three functions that affect
authentication. Now, during class instantiation ( with __init__ ), the
set of functions are “aliased” depending on whether or not the IPSC’s
auth flag is set in dmrlink.cfg
Shebangs added to all files expected to be executed, command line
argument for configuration file added (otherwise, it looks for
dmrlink.cfg in the same directory as dmrlink.py) - this divorces it
from the last ties to a shell environment… or at least I think.
Made some changes to better stabilize where dmrlink.py looks for the
csv files… not perfect, but better. Expect more changes.
Have waffled back and forth on how to handle peers we lose contact
with… de-reg for sure, but ignore them, or try forever (until we get a
peer list without them from the master) to re-register with the peer?
Settled on trying forever, but will add code to request a new peer-list
every few hours.
The quandry is what to do with peers that have disappeared for too
long. If we keep trying to re-register, we could be quite busy doing
that for an eternity… but if we de-reg the peer and it comes back in 10
minutes, but, say, never lost the master, we don’t get a peer list for
a LONG time and we don’t get it back then either…. There’s no good
answer right now. Anyone got one?
