What a traceroute result proves, what it does not prove and how to use it without confusing one packet with the whole network.
Meshtastic traceroute sends a special request to a destination and records the nodes involved in the first copy that reaches it. In firmware 2.5 and later, the return path and link SNR values can also be recorded. It is a diagnostic snapshot for one exchange—not a permanent route, a routing command or proof that all messages follow the same path.
Why Meshtastic traceroute is different
Traditional IP traceroute discovers hop-by-hop forwarding in a network that makes routing decisions. Meshtastic uses managed flooding: several eligible nodes may rebroadcast a packet and the destination may receive duplicates through different paths. The traceroute result follows the first request copy that arrived. Another copy may have taken another path, and a later request may produce a different result.
The official traceroute documentation also notes that only nodes able to decrypt the channel can be identified in the trace. Repeaters or nodes without the relevant key can appear as unknown, depending on firmware and what is present in the client’s node database.
Reading a result
| Observation | Reasonable interpretation | Do not conclude |
|---|---|---|
| Direct target | This request reached the target without a recorded relay | The direct link is continuously reliable |
| One or more hops | The first successful request used those recorded relays | Those nodes are assigned routers |
| Different return path | The response’s first successful path differed | The original path is broken |
| Unknown node | A hop could not be identified or decrypted | An unauthorized device attacked the mesh |
| No response | The diagnostic exchange did not complete | The target is certainly offline |
A careful test procedure
- Confirm both nodes have compatible modem and channel settings.
- Verify the target was recently heard before sending repeated traces.
- Run one trace and save the time, origin, destination and result.
- Wait before repeating; do not flood the mesh with diagnostic requests.
- Repeat at different times if investigating instability.
- Compare with Neighbor Info, direct packet tests and independent observers.
Android, Apple, the Python CLI and Web clients expose traceroute, although presentation differs. The CLI command is meshtastic --traceroute 'destinationId'. A multi-hop request can take time because it must traverse the mesh and receive a response.
Using SNR correctly
From firmware 2.5, recorded link SNR can help identify a weak segment. SNR belongs to a particular reception on a particular modem preset. Compare it with the sensitivity requirements of that preset and with repeated samples. One favorable SNR does not measure packet-loss rate, while a negative SNR can still be decodable with LoRa.
If a trace consistently relies on one marginal hop, schedule a direct range test or add an independent path. Do not promote every intermediate node to a Router role in response; roles and rebroadcast behavior must be coordinated at network level.
Common diagnostic uses
- Checking whether a new infrastructure node appears in observed paths.
- Comparing outbound and return paths during one-way-link investigation.
- Finding an apparent single bridge between two regions.
- Verifying that a configuration change did not isolate a target.
- Collecting examples before a planned site improvement.
What to store in MeshAtlas
A traceroute record should include timestamp, firmware context, channel/preset context, origin and destination, direction, recorded nodes and unknown hops. If shown publicly, protect private node identities and locations. Never display a traced path as the network’s fixed topology.
Neighbor Info offers periodic direct-neighbor observations; traceroute offers the path of one completed diagnostic exchange; packet-loss testing measures repeated delivery. Together they provide a useful operational picture, but none replaces the others. See Neighbor Info and mesh topology and the range-test guide.