Traceroute not working

Running meshtastic V2.0.9
Running Firmware firmware-tbeam-
I have only three nodes (Node 1 - Repeater - Node 2).

Running traceroute I only get timeout errors (I have the primary and two secondary channels (admin and gpio)). Even doing a traceroute from Node 1 to Repeater I get a timeout error (same thing when doing traceroute from Node 1 - Node 2). Hop limits are all set to 3.

Also tried with --dest command just to get a variable read back…it still times out. I can send a text (using Apple API) and it works just fine.


I assume all nodes are using 2.0.13 and all have the encryption key of the primary channel? Can you show the command you were using?
The Apple apps have a Traceroute option now as well (from version 2.0.9): under Contacts > Direct Messages, long hold a destination node and select ‘Trace Route’ to send the request. Maybe you can give that a try?

Sure, here are the commands that I used:
meshtastic --dest !55c6db90 --get lora.hop_limit
meshtastic --traceroute !8487cf58

Correct, they all share the same primary, admin and GPIO encryption keys (here’s two of the nodes)
PRIMARY psk=secret { “psk”: “3iuW5n4n9R2zh0QikmfAjbR7kBxVJckpaNLZIiFC4t4=” }
SECONDARY psk=secret { “psk”: “EC2n2WJAA/mRHqfOUCrSXODwXp6TsmQlGevWcxq3jwQ=”, “name”: “admin” }
SECONDARY psk=secret { “psk”: “6Up1MCONj0xDTT8lD6qqqS9zGAFxuDENUOjWZvyfht0=”, “name”: “gpio” }

PRIMARY psk=secret { “psk”: “3iuW5n4n9R2zh0QikmfAjbR7kBxVJckpaNLZIiFC4t4=” }
SECONDARY psk=secret { “psk”: “EC2n2WJAA/mRHqfOUCrSXODwXp6TsmQlGevWcxq3jwQ=”, “name”: “admin” }
SECONDARY psk=secret { “psk”: “6Up1MCONj0xDTT8lD6qqqS9zGAFxuDENUOjWZvyfht0=”, “name”: “gpio” }

Your traceroute command seems fine, I am not sure what is going wrong if they are all firmware version 2.0.13 and have the encryption key.

I think the Testflight version is discontinued since the app is available from the App store right now. It needs to be at least version 2.0.9 and you have to long hold one of the contacts to send the Traceroute request.

All three nodes have 2.0.13 and encryption keys

Yea, that part i figured out after i posted…

So an update… I can run traceroute on my iPhone but only appears to work from one hop. If i run traceroute to the repeater, i get the query and response back. if i run the query THRU the repeater (Node 1 - Repeater - Node 2), i never get a response.

If i run traceroute on the CLI, i get no response for either scenario.


Are you getting a real acknowledgement when sending a direct message from Node 1 to Node 2? You can confirm this when the text ‘Acknowledged’ turns from orange into grey.
If that works, the Traceroute should also work. You might have to try it multiple times (and wait a while in between), because there is only zero-hop reliability in the protocol, meaning if one of the packets beyond the repeater get lost, it doesn’t automatically retransmit.

Yes, when I send a test message I get the “acknowledge” prompt right underneath the text that was sent from one of the nodes. I can see the Traceroute command go out and come back on the iPhone app in the Mesh Log.

So I guess I need to look at the path of the traceroute in the Repeater and see if it comes in and goes out and so forth.

OK, there is something definitely wrong with the traceroute command. I did a factory reset of two nodes.
Via the cli (meshtastic V2.0.9)
Set lora.region to US.
They connect.
Run traceroute - nothing
run sendtext command - works just fine…

So there is DEFINITELY something wrong with traceroute…

It shows the message delivered directly in the iPhone app there, did not use your repeater at all, working fine.

this was just two T-Beams set to Factory reset - doesn’t even know about my “mesh”

traceroute on the CLI times out

C:\Users\Meshtastic\firmware->meshtastic --port com3 --traceroute !8487cf58
Connected to radio
Sending traceroute request to !8487cf58 (this could take a while)
Aborting due to: Timed out waiting for traceroute

The cli times out quite a bit, the iOS app has the same info

Can you confirm that you can send a traceroute on you mesh from the cli and not get the same problem please?

If you do get the same timeout, then there is a problem with meshtastic, if it works for you then it is something with my system (which i doubt as the factory reset “mesh” of two devices exhibited the exact same problem - timeout)

I have tested traceroute on the cli and it works, I wrote the iOS functionality that I see working properly in your screenshot. The cli is rough on windows.

% meshtastic --traceroute ‘!bd5ad298’
Connected to radio
Sending traceroute request to !bd5ad298 (this could take a while)
Route traced:
!f71e89f0 → !bd5ad298

1 Like

When you send from Node 1 to Node 2, does the text ‘Acknowledged’ become grey? If it stays orange, it only means that at least one device on the mesh received it (the repeater in this case probably), not that it actually ended up at Node 2.

I am not sure why it does not work at all using the CLI for you. I tested this on Windows as well.

ok, so cli on windows is rough. fair enough…

on the iOS when I look at the Mesh Log window, how do i drill down into one of the entries? In other words, how do I get the route that was taken for the traceroute?

The ‘Acknowledged’ turns grey. Mesh Log also shows that as well.

I get 100% timeouts using the cli for traceroute. I need to be able to follow the path to know how the packet was routed. Can i get that information from the IOS app?

Yes, if it is not received directly, it will show the route like:
id1 → id2 → id3.

So, looking at possible culprit. I am running two different T-Beam boards. Two are SX1262 and two boards are SX1268. Are both chips supported?

Although SX1268 is rare (I think there is only a 433 MHz version), both chips are supported.

But what is exactly the problem now? You showed the Traceroute works using the iOS app. It might be that from Node 1 to Node 2 the packet is also received directly, even if the repeater in between received it as well.