Cort N0MJS <n0mjs@...>
Today I identified and corrected to critical problems with hblink.py in CLIENT mode, and have pushed to the master branch on GitHub. The HB_Bridge branch is also affected, but not updated by me at this time. Both issues are related.
Somewhere along the line, I walked away from the code half baked and never finished implementing the missed keep-alive counter. So it was not working correctly. It has not been extensively tested, but I believe it’s at least “pretty good” now. You will see some logging updates that go along with this.
when incoming packets are received, the “command” length is variable. Mostly, they can be disambiguated with 4 characters. When this is possible, I only parse 4 characters as to not waste time re-parsing. The “MSTNAK” – master negative acknowledgment to the client can be disambiguated with “MSTN”… so what did I do? Started looking for the radio ID (next piece of data) at offset 4… forgetting about the “AK”… I should have started parsing at offset 6.
@ elif _command == 'MSTN': # Actually MSTNAK -- a NACK from the master
- _radio_id = _data[4:8]
+ _radio_id = _data[6:10]
This caused hblink.py in client mode to NOT honor MSTNAK and not reset the connection. Between this and Issue 1, it’s possible for hblink.py to continue thinking it’s connected to an application virtually forever. What’s worse, if the master it is connected to continues to answer keep-alives even if it’s disconnected a client (there’s one that does this), it’s hard to even troubleshoot… which I’ve been doing for days.
A few minor changes so that per-packet logging does not occur at debug. The lines are still there and commented out. Uncomment locally if you need to debug that deeply.
Extra props go out to Corey Dean, N3FE for helping troubleshoot this one - Thanks Corey.
0x49 DE N0MJS