Skip to main content

Traceroute Module Usage

Overview​

Due to the limited bandwidth of LoRa, Meshtastic does not keep track of the nodes a message used to hop to the destination. However, from firmware 2.0.8 on, there is a Traceroute Module that can show you this.

Only nodes that know the encryption key of the channel you use can be tracked. Also note that a message may arrive via multiple routes due to duplication because of rebroadcasting. This module will only track the hops of the first packet containing the traceroute request that arrived at the destination.

In order to use it, make sure your devices use firmware version 2.0.8 or higher.

From firmware version ≥ 2.5, the route back to the origin is recorded, along with the Signal-to-Noise Ratio (SNR) for each link. Nodes with older firmware or those unable to decrypt the traceroute will be shown as "Unknown" (represented by an ID equal to 4294967295 or 0xFFFFFFFF in hexadecimal) if all nodes in the route are using at least firmware version 2.3.12.

Repeater Behavior​

Repeater nodes will appear in the traceroute log if they have the encryption key, but if they are not in the node list they might appear as "Unknown" depending on the app.

Traceroute Module Client Availability​

CLI​

Make sure the CLI is at least version 2.0.6. Then use this command:

CLI traceroute command
meshtastic --traceroute 'destinationId'

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

Traceroute from !25048234 to !bff18ce4
meshtastic --traceroute '!bff18ce4'
Connected to radio
Sending traceroute request to !bff18ce4 (this could take a while)
Route traced towards destination:
!25048234 --> !ba4bf9d0 (6.0dB) --> !bff18ce4 (-3.5dB)
Route traced back to us:
!bff18ce4 --> !ba4bf9d0 (-2.75dB) --> !25048234 (5.25dB)

The first ID shown is the origin device connected via the CLI. As demonstrated in the image above, the packet traveled through one additional node to reach its destination and return.