Hi, currently using two Heltec Lora 32 modules, coupled to supplied antennas. One is connected via bluetooth to Android phone and other via bluetooth to Iphone. I am able to send messages between them and am also seeing several nodes on both devices. A few are local to me and the other more distant nodes are clearly relayed by these local nodes via the mesh network. I have also seen several messages from these distant nodes, however, I am unable to respond to them, although I do receive an acknowledgement (I assume this is from directly received nodes) Additionally, Traceroute only appears to work when interrogating directly received nodes. This seems to be happening on both modules. I’m relatively new to Meshtatstic so wonder if I’m missing something ? Any help appreciated
Traceroutes (and other things) can/will fail if people in your local mesh have nodes that are running old formware - especially 2.1.0 or lower. They’ll do the basics like node visibility, but won’t pass things like traceroute requests properly.
Hi Paul, Thanks for the reply and that’s useful to know. Unfortunately, atm, I don’t know any of the users in the nodes I am picking up, so not sure what software version is in use. However, I am picking up over 30 nodes and so far traceroute is failing on all attempts to staions not being received directly. Am I correct in believing that a “trace route” is not stored as part of the initial contact data and that therefore the nodes you are querying must be switched on and receiving the query at the time you initiate the traceroute ? ie I guess it’s possible that although a path was there when a node was received, that path may no longer be there when you actually initiate a trace route.
Traceroutes are actively generated when you click the button to initiate one in the UI. You may be seeing nodes that passed through your mesh, or in some cases, you’ll see nodes that someone with an MQTT server is forwarding onto the mesh. Do you have location data from any of the nodes in question? That should help get an idea of whether they’re actually within your local transmission range.
For example, the edge of my local mesh just barely touches a local interstate highway. I often get people passing through, who I’ll likely never see again, but they show up in my node-list. You can “forget” such nodes by selecting them from the app UI and selecting “forget node.”
Traceroute packets do persist through multiple hops, I assume behaving according to maximum hop-count like most other message packets. I regularly see my rooftop node serving as an intermediary for two “walking around” nodes.
I’ve found the best way to do an immediate test to see whether a specific node can hear you is to send it a direct message. The iconography is different depending on whether the packet is picked up by the mesh (or not), and again whether the intended recipient has acknowledged receipt. Remember, all it takes for your DM to be picked up by the mesh is any one ohter single radio in-range…it doesn’t guarantee the intended recipient is active or in-range at that exact moment, so watch for that acknowledgement indicator in the UI.
Thanks for reply. I’m starting to conclude my Traceroute issue is probably due to either a) low signal strength from the nearby, direct relaying node and the radio path has since dropped below a workable level, or b) One of the nodes along the route has been deactivated. If possible, would appreciate clarification on a couple of the points you made, viz “Traceroute packets do persist through multiple hops” - I wonder what you mean by persist - does this mean it continues to make several attempts to trace a route before timing out ? and secondly “so watch for that acknowledgement indicator in the UI” I was under the impression that if you sent a DM, the acknowledgement is sent from the first node that picks up and relays the message and not actually from the node you DM’d. Still very much in a learning phase so may well be wrong on this. Thanks for your help.
Happy to help if I’m able!
With regard to the traceroutes being “persistent” I just meant that they behave with a decrementing “hop count” number. If you don’t change the defaults, this is set to three hops and unless you’re really sure you know what you’re doing, it’s not recommended to change this value…or you could end up flooding your mesh.
If I remember correctly, a maximum hop-count value of three will actually persist a packet through to five nodes, including the originator.
A->B: Hop Count 3
B->C: Hop Count 2
C->D: Hop Count 1
D->E: Hop Count 0
Once hop count gets to zero, “E” will either be the intended destination, thus you have a successful delivery…or if “E” is not the intended recipient, the packet is discarded.
I’m no expert on the mesh routing protocol, but it’s important to remember the mesh is a flood routing algorithm. Every node just re-broadcasts everything it hears from every other node. Without some kind of killl switch on the packets, they’ll just bounce around forever unless acknowledged or killed due to hop-count.
My comment was just around the fact that traceroute packets must behave similarly, as in they are routed…but behave according to the standard maximum hop count. So if you’re trying to trace something that’s more than 5 hops distant, even if it’s technically within range, is going to timeout.
The UI presents the message statuses differently depending on whether you’re on Android or iOS.
For Android:
- Cloud with an up arrow - Queued on the app to be sent to your device.
- Cloud only - Queued on the device to be sent over the mesh.
- Cloud with a check mark - At least one other node on the mesh acknowledged the message.
- Person with a check mark - The intended recipient of your direct message acknowledged the message.
- Cloud crossed out - Not acknowledged or message error.
For iOS:
when the message is sent you will first see a
Waiting to be acknowledged...status beneath the message. If the message is acknowledged by a node on the mesh this will update toAcknowledgedin orange, which turns into grey when sending a direct message and the intended recipient acknowledged it. If no nodes have responded it will indicateMax Retransmission Reached. If there is an error, the status will update to the appropriate error. Additionally, you can long press on the message and selectMessage Detailsto view the date/time sent, if ack was received and the time ack was received or the error (if there was one).
Reference: FAQs | Meshtastic
With regard to retries, I don’t know exactly what the retry policy is with Meshtastic, but I do know that it does attempt to send a number of times before giving up and reporting that node as unreachable.
You’re right that there is an acknowledgement from the first node a message hits, that’s letting you know that the message has been received by somebody even if it’s not the intended recipient. This is where you’ll get the little cloud icon with the up-arrow (on Android).
If, after that, the intermediary node(s) are finally able to reach the intended end-of-line recipient, and that recipient’s message is able to relay all the way back to the original sender, the icon in the Android UI changes to a person icon with a checkmark, indicating a full round trip with acknowledgement.
Here’s a great video which visually demonstrates what’s going on using real radios:
and here’s a good one which drills down into the nuance of the traceroute module:
