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?
Turns out we have to do this in TWO places, when processing the peer
list (or could be peer reg. replies, but I only do it once) AND the
master registration reply. So rather than duplicate the code, I moved
it to a function.
Since peers are no-longer de-registered just by missing too many
keep-alives (instead returned to registration phase), there must be a
way to remove a peer that we have in our list(s) that are NOT in new
peer lists from the master. This was added.
moved many of the inline print statements to logger.debug. The code is
solid enough they’re no longer needed.
Also made a couple of minor logic changes:
When a peer misses too-many keep-alives, it doesn’t de-register, it
just goes back to registration attempt until a new peer list is
recieved, or a de-registration is recieved. Also, outstanding
keep-alives are set to 0 when a peer or master exceed max-keep-alives
and return to registration pending.
repeaters don’t reply to keep alives while they are transmitting.
Changed addes so that when voice packets are received, the keep-alive
monitor is reset for that peer.
0x61, 0x62 and 0x63 have been mostly decoded. Still don’t know what all
of the pieces do, but know what they’re for finally!
This will mean big things for log.py as I figure out the details.
Cort Buffington