python icon indicating copy to clipboard operation
python copied to clipboard

meshtastic doesnt exit after succesful traceroute

Open MansM opened this issue 1 year ago • 1 comments

bin/meshtastic --ble bluetoothaddress --traceroute '!nodeB'
Connected to radio
Sending traceroute request to !nodeB (this could take a while)
Route traced:
!nodeA --> !nodeB




^CException ignored in: <module 'threading' from '/opt/homebrew/Cellar/[email protected]/3.12.2_1/Frameworks/Python.framework/Versions/3.12/lib/python3.12/threading.py'>
Traceback (most recent call last):
  File "/opt/homebrew/Cellar/[email protected]/3.12.2_1/Frameworks/Python.framework/Versions/3.12/lib/python3.12/threading.py", line 1622, in _shutdown
    lock.acquire()
KeyboardInterrupt:

I had to use ctrl+c to get out.

After a failed traceroute because of timeout it will exit though

MansM avatar Apr 09 '24 08:04 MansM

I don't think this is purely a BLE issue. I have seen what appears to be the same issue when using the CLI as a library communicating with a node connected over serial. In my code:

self._interface.sendTraceRoute(num, 3, 0)

Will sometimes never return, and ctrl-c yields the same threading exception above. As a work around, I now construct/send the packet myself using mesh_pb2.RouteDiscovery() and sendData(), and implement my own on response function to handle recording when a traceroute last succeeded...

The scenario (in case it helps) is this - my app tracks node (and packet) data in its own extended nodedb. Once every 2 hours it will send a traceroute to nodes seen in the last 2-hours (excluding any via MQTT). Traceroute requests are spaced by a minimum of 5 seconds (only 4-7 nodes typically visible in my area, except for some occasions where I can hear nodes, but they cannot hear me, so the test allows for understanding which nodes are actually participating in the local mesh vs just blasting us with unidirectional data)

jbroxson avatar Jul 31 '24 03:07 jbroxson