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.
Move bridge.py's config information to a separate file.
Provide a sample file for bridge.py (bridge_rules_SAMPLE.py)
Tell peers we're a 3rd party app and repeater monitor.
Internal data structure change for how peers are stored. Instead of a
list of dicts, it is now a dict of dicts where the dict key IS the
radio ID, and the Radio ID is no longer stored in the "inner" dict.
This does NOT affect bridge.py or log.py, only dmrlink.py
This has gotten messy durring development, so I decided to clean it up
some. The system logger should ONLY be used for internal logging of the
program, not to try and make a "netwatch" out of (for you c-Bridge
users). Please use the log.py module for that type of thing.
Fixed a bug where I accidentally over-wrote original packet data when
forwarding to an IPSC peer... making it impossible to bridge a packet
to more than one destination IPSC correctly. Currently, DMRlink is
bridging three IPSCs and transcoding group IDs.
unauthenticated packets were subject to having their hashes stripped
just like other packets. The problem is that they don't have hashes to
strip, so I was throwing away part of the packet. Fixed in log.py,
dmrlink.py and bridge.py
All "useful" call-back actions removed. This is because it's time to
start using derived classes to make applicaitons out of dmrlink.py as a
base class.
Preparing to use DMRlink as a python module. The name needed to be
changed to not clash with the resource sub-directory, and functions
were moved into the main class that are intended to be changed in a
derived class.
DMRlink is now a functional module. I will be shifting ALL development
of "application" level features to other files with derived classes,
and dmrlink.py will ONLY include protocol update/fixes/etc.
Cort Buffington
Cort Buffington