Tracking which nodes are used to hop

Due to the limited bandwidth of LoRa, Meshtastic does not keep track of the nodes a message used to hop to the destination. However, in the latest 2.0.8 alpha release, there is a new ‘TraceRouteModule’ (as per an idea of @mc-hamster) that allows you to track which nodes are used to hop to a certain destination.

In order to use it, you have to flash the firmware to all your nodes and upgrade the Python CLI (using pip3 install meshtastic --upgrade). Then use this command:

meshtastic --traceroute ‘<destinationId>’

Where for <destinationId> you have to fill in the ID of the node you want to trace the route to, which you can get from running meshtastic --nodes. Depending on your OS, you might need quotation marks around it. Then it will send a specific message to track the hops. For example, this is what you will get:

meshtastic --traceroute ‘!bff18ce4’
Connected to radio
Sending traceroute request to !bff18ce4 (this could take a while)
Route traced:
!25048234 --> !ba4bf9d0 --> !bff18ce4

The first ID shown is the node you are connected to. As you can see, this packet went through one other node to get to its destination. Only nodes that know the encryption key can be traced. Also note that a message may arrive via multiple routes due to duplication because of rebroadcasting. This will only show the route of the first packet containing the traceroute request that arrived at the destination.

I hope you find it useful.


Awesome work @GUVWAF!!!


Really love this! Good work!

Newb question here but without using this feature, was/is there a way to know your message made it to your intended recipient? For example my message is ack’d once it hits another node in the mesh, but if that node can’t reach the recipient it’s not delivered, would that be a case where you would use this feature to confirm it is ‘ping able’?

Indeed at this point you cannot guarantee that the message made it to the intended recipient. There is an open issue for this. It will require to flood the ACK back to the original sender, but we have to check what the influence of that is on channel utilization.

While this feature can be used to check if the node is ‘ping-able’, it is not really well-suited for checking whether a message really reached the destination, as it may vary per message especially if your nodes are moving.

Thanks for the answer, that’s good to know! :slight_smile:

So if this hops through any node that isnt 2.0.8 or later it will not be successful. Is that correct?

Nodes that are not 2.0.8 or higher will not add themselves to the list of nodes that are used to hop, so the list may be incomplete then. At least the sender and destination should be >=2.0.8, otherwise it won’t work at all.