This is useful when using multiple interfaces and bridge.py is employed
as an application gateway between multiple un-connected networks (like
VPNs to the real world).
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.
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.
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.
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
did not add the additional code to use unauthenticated IPSC with the
log mixin. Added it blind - as in I've not tested it yet. If someone
finds this and tests it BEFORE I do, please let me know if it works.
As of now, dmrlink.py is only a behind the scenes worker... It's just
the base class to take care of link establishment and maintenance.
Applications, such as bridging or logging will now be in their own
files and inherit from dmrlink.py
Cort Buffington