Commit Graph

60 Commits

Author SHA1 Message Date
Cort Buffington
dbe69bb15e keep-alive packet logging set for debug level 2014-01-21 10:49:13 -06:00
Cort Buffington
620d013e92 Added debug logging for keep-alives 2014-01-21 10:40:52 -06:00
Cort Buffington
98300901cc cfg file note added 2014-01-03 15:03:41 -06:00
Cort Buffington
874b11db7b Daemon Support
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.
2014-01-03 15:01:43 -06:00
Cort Buffington
97246370c5 Official Version V0.1 Release 2014-01-02 11:16:23 -06:00
Cort Buffington
6b4fa3b479 Configuraiton Clean-up 2013-12-22 16:16:10 -06:00
Cort Buffington
b461bc9240 Imported Logger - more config items 2013-12-15 09:45:39 -06:00
Cort Buffington
53d7472fa6 See Detailed Description
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.
2013-12-13 12:07:18 -06:00
Cort Buffington
878fec4a3e Begin Adding Features to Bridging 2013-12-12 19:59:04 -06:00
Cort Buffington
bf46299a2a re-add accidental deletion. 2013-12-12 18:20:21 -06:00
Cort Buffington
872053d6a5 Continue peer connection improvements 2013-12-12 17:03:00 -06:00
Cort Buffington
f3e2d53d9f Revert to Previous Peer De-registration Behavior
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?
2013-12-12 16:59:56 -06:00
Cort Buffington
98b12aedd3 Import Simplification
Several imports only imported one function, so I changed them to “from
xxx import yyy”
2013-12-12 16:23:46 -06:00
Cort Buffington
101c627d3f Better Processing of MODE and FLAGS 2013-12-12 16:12:36 -06:00
Cort Buffington
d9cf7c3b8a More MODE and FLAGS additions 2013-12-12 07:50:47 -06:00
Cort Buffington
87260cc56e Peer Flag & Mode Additions 2013-12-12 07:42:56 -06:00
Cort Buffington
bbf5ce5282 See Previous Commit 2013-12-11 20:56:39 -06:00
Cort Buffington
8971bb8aed Added MODE decoding function
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.
2013-12-11 20:53:55 -06:00
Cort Buffington
8aec3d5078 Fixed the last fix :) 2013-12-11 19:25:19 -06:00
Cort Buffington
d6b948e0d1 Master Mode info (info only) wasn't gathered properly. 2013-12-11 19:10:08 -06:00
Cort Buffington
810e0c8c22 fixed Master information gathering 2013-12-11 19:09:38 -06:00
Cort Buffington
44b3e37142 No real change 2013-12-11 14:50:03 -06:00
Cort Buffington
5b35993159 Change In Peer Processing
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.
2013-12-09 16:48:44 -06:00
Cort Buffington
af7941a484 Code Maturity Clean-Up
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.
2013-12-09 16:14:03 -06:00
Cort Buffington
922308bcb3 typo 2013-12-06 07:11:19 -06:00
Cort Buffington
cea2cee20e Minor Clean-Up 2013-12-06 07:00:40 -06:00
Cort Buffington
d356459ad2 minor logging changes... preferences really 2013-12-05 18:46:54 -06:00
Cort Buffington
c3f53b5eb7 Fixed Keep-Alive While Transmitting Issue
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.
2013-12-05 15:20:59 -06:00
Cort Buffington
f84a1a2cc7 Logging Clean-Up 2013-12-03 10:47:08 -06:00
Cort Buffington
aea410ec58 bug fixes after fixing the bugs... 2013-12-01 19:24:50 -06:00
Cort Buffington
6b74cc94b8 Lot's 'O Formatting & Bugs 2013-11-26 16:05:08 -06:00
Cort Buffington
b74b46e3bd Shebang and app notes added... 2013-11-24 22:01:20 -06:00
Cort Buffington
8e78d70f0e THREE PACKET TYPES FIGURED OUT!
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.
2013-11-23 17:30:12 -06:00
Cort Buffington
94ef04fbea Working with Call Control Packets
I’m very close to figuring these out. Getting them taken care of will
end the clipped transmissions when bridging.
2013-11-22 15:43:47 -06:00
Cort Buffington
45da762a38 Work on NAT 2013-11-22 09:23:55 -06:00
Cort Buffington
056e55823e Nat work 2013-11-21 18:50:01 -06:00
Cort Buffington
b0175dbbbf NAT Work 2013-11-21 18:38:15 -06:00
Cort Buffington
a46a35dbd1 NAT improvements 2013-11-21 18:34:06 -06:00
Cort Buffington
ce28dec967 Work with NAT 2013-11-21 18:30:02 -06:00
Cort Buffington
c08ecd5905 housecleaning 2013-11-21 11:47:43 -06:00
Cort Buffington
7a0cedb7cb Multiple - See Extended
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.
2013-11-17 18:13:59 -06:00
Cort Buffington
2c826f76ed Bug Fix 2013-11-15 12:44:14 -06:00
Cort Buffington
48a100f0df Fixed a few more bugs...
AND found some caveats, which will be listed as issues shortly.
2013-11-13 19:07:20 -06:00
Cort Buffington
2811e980d9 Missed change in structure reference 2013-11-13 18:17:52 -06:00
Cort Buffington
b90ec9b7f4 MAJOR - Data Structure Update
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
2013-11-13 16:19:32 -06:00
Cort Buffington
3f0e2724db Jon: Fixed Typo in Unauth Function 2013-11-12 15:10:11 -06:00
Cort Buffington
e538def5be minor formatting tweaks 2013-11-11 14:38:27 -06:00
Cort Buffington
bbfaea6387 Logging cleanup 2013-11-10 21:43:55 -06:00
Cort Buffington
5ee94034d6 System Logger Cleanup
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.
2013-11-09 11:33:52 -06:00
Cort Buffington
13157cd4e2 2 Peer Bug Fixed
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.
2013-11-09 10:14:39 -06:00