Nondecrementing router/repeater role

Request for a ‘nondecrementing router/repeater’ role, in addition to the existing ‘router’ and ‘repeater’ roles.

‘Nondecrementing’ meaning that the device does not decrement the hop count for messages passing through it.

We are planning (in the oncoming summer) to test the usability of lora devices with meshtastic for exploration team communication in unterground structures like caves. Given a sufficiently fitting geometry of the cave, like big tunnel structures and rather large halls, it should be possible to use a number of lora router devices for continuous team communication with base camp (and each other), even from within one to two kilometers deep into the cave. However due to the meandring nature of cave geometries, this will require quite some router devices and the resulting mesh will be more like a chain and not like a real mesh. Optimistic estimates suggest that the number of repeating nodes along the chain will be at least 8-10+ devices. Less optimistic estimates suggest more. This amount of devices exceed the max hop count limit for meshtastic communication. Understanding the idea of a low hop count limit for open outdoor meshes, we however request the possibility to suppress hop count decrementation on single nodes for very specific use cases.

Thank you


With 7 hops, you can have 9 nodes in a chain where each node can only reach 1 (edges) or 2 (middle) nodes near them. I’ve yet to see a mesh that really needs this; longest traceroute I’ve seen is 4 hops.
7 hops already means you need to divide the potential data rate roughly by 7, so it will only work if you have very little traffic. Instead of increasing the hop limit, you can also try to use a slower preset first, such that you can cover longer distances between nodes. Setting a higher hop limit than needed may cause a lot of unnecessary rebroadcasts.
I would first try it out with let’s say 4 hops (chain of 6 nodes) and see how far you can get. If it turns out you really need more than 7 hops, then I think your proposal is something to consider, but it needs to be done carefully because you want to avoid packets going around indefinitely.


Man!, he wants to set this up for using in Caves !
where communication usually not possible…
thats awsome :slight_smile:
thats predestined for needing very long traceroutes that you will never see on surface.

little traffic and data rate will also not be a problem, since its only used to get messages in two directions… specially if the routers are setup as repeaters and dont generate any traffic themselfes…

rising the hop limit is not a good option here, much better what marvac asked for: a repeater setting that does not -1 the Hop limit… to get signals aorund corners in these caves :slight_smile:


Indeed, it’s a cool use case. It just depends on how the cave looks like and how much traffic there will be how feasible it is.

Not decrementing the hop limit will have the same effect as using a higher hop limit. Nodes do not care about what the actual value of the hop limit is, they will rebroadcast if the hop limit is not yet 0. So 3->2->1->0 will lead to the same amount of rebroadcasts as 1->1->1->0 (assuming it’s a chain of nodes).

1 Like

a little different:

if he can set hop limit to 7, 12 or 37 or whatever, each one of the nodes on the way will set -1 and the messages can go wild at any location :slight_smile: , also between users at basecamp.

if he has just a few certain nodes that will not decrement, he can choose where it is -1 and where not.
these could be placed in the “hidden corner places” to get the signal deeper into the cave… still using a low hop-limit of 3 or 4.
so the non-decrementing nodes are deep in the caves in the places where they cannot reach more than the direct neighbor… and will not cause the messages to go wild between user-nodes (unless equipped users are just passing by there)… and the hop limit can stil stay very low…


True, but nodes do not rebroadcast anymore if they hear another already doing that. So assuming all users at basecamp are in range, only one of them will rebroadcast to get it into the cave.

I can point you to the line in the code where you can make repeaters not decrement the hop count, but adding it as a role will likely cause users choosing it in a normal mesh where it isn’t needed.


Thank you for all your feedback.

  • Yes, we are considering and will test the ‘long_slow’ and ‘very_long_slow’ presets, wich are probably the most usefull settings for our purposes. The datarate is most likely not a problem. We won’t get very chatty there. Maybe a message every 15 minutes at average.

  • Yes, the plan was to use the nondecrementing nodes in the middle of the chain and the ‘normal’ nodes towards the ends of the chain.

We have currently no idea how this will work out. Maybe its a good idea or maybe its just not practicable. That is what we are going to find out this summer. The test scenario will include 8 devices, so this request is not very ‘urgent’ right now. But if everything is working good, it might be usefull in the future.

We will take the 8 nodes and deploy them in different areas with different geometries and find out how far we can get in each case. And then estimate how much nodes we would need for ‘real’ communication chains. We think it shouldn’t be more than 15-20 chain nodes at max, because things would get rather impractical after that. After all you have to carry them around and deploy them on your way down and recollect them on your way up. It will be interesting how the radio signals will behave in that environment: there are solid walls, flat water surfaces but also mud and gravel. So they may get bounced, reflected or absorbed in different or unexpected ways. The s/n ratio may work in our favor, because its really silent on those frequencies down there.

Our current deployment plan is to use the ‘router’ role for different reasons. First because I’d like to walk along while regularily tracerouting the last deployed node until connection is lost and then go back a bit until I can reconnect to find the best maximum distance between nodes. And also because I can traceroute a team member to get his coarse location from the nearest chain node, because there is no possibility to get a position otherwise. And I think ‘repeaters’ don’t show up on the traceroute afaik. Is there a setting on the app ui that shows from which node the last message was first delivered to a client?

As I understand from your explanations, the forwarding node does not remember which messages he already did rebroadcast and which not. Thus endless loops are possible if the hop count is not decremented. Somehow I was under the impression, nodes do remember messages or message hashes they already encountered, so thats an issue. Initially I thought I should request a fourth bit for the hop count, making it 15 max. But I didn’t know how precious bitspace on the device is or if it is embedded between other data and can not be expanded easily. So I figured maybe a ‘nondecrementing’ node role would be the better and simpler solution. But maybe it is not.

Thanks for your help and explanations.


If the repeaters have the encryption key, they do show up on traceroute, but as “Unknown” (there’s no NodeDB entry and thus no name associated with them). Meshtastic doesn’t keep track of who is rebroadcasting (only the original transmitter and destination it known) except when using traceroute, so clients also don’t know this.

Nodes do remember messages they already encountered, but only up to a certain time to limit memory use and to recycle message IDs. It was recently increased to 10 min. because 5 min. wasn’t enough. If nodes keep on rebroadcasting and there are multiple messages in the queue, it may take a long time before a message circles back to a node and the packet record might already be removed. But in case you only have a chain of nodes, I think that will not be a problem.

There are still 3 bits left in the header, but unless it will become a common problem that 7 hops is not enough, I don’t think Meshtastic will allow more by default. You can change it for your use case though.

1 Like

Thanks for your answers GUVWAF.

I’m not sure if I can easily set up the development environment and build my own firmware version (and how to you test/debug this then?), but nonetheless:

Can you point me to the code where it decrements the hop count?
And can you hint me on setting a forth bit to the hop counter (likely not just a single line I presume)?
(Any chance making the number of hop count bits a global parameter variable?)

Thank you.

1 Like

I would first test how far you get with 9 nodes in a chain (7 hops), so you don’t have to build new firmware. Place them as far as possible from each other, but where you still have a reliable connection. If you’re lucky, with reflections you may get even connections beyond line of sight.

Instructions for building firmware can be found here.

Here it decrements the hop count: firmware/src/mesh/FloodingRouter.cpp at 4c55d5d9e46eeb7ca5c1ab22c9e5b75a9cc9a9a7 · meshtastic/firmware · GitHub

The mask for the three bits of the hop limit in the header flags is here: firmware/src/mesh/RadioInterface.h at 4c55d5d9e46eeb7ca5c1ab22c9e5b75a9cc9a9a7 · meshtastic/firmware · GitHub
You’ll probably need to rearrange the other bits such that you can use a mask of 0x0F (4 bits in a row). E.g. WANT_ACK then becomes 0x10 and VIA_MQTT 0x20 (this will not be compatible with default Meshtastic firmware).
And you have to increase MAX_HOP here: firmware/src/mesh/MeshTypes.h at 4c55d5d9e46eeb7ca5c1ab22c9e5b75a9cc9a9a7 · meshtastic/firmware · GitHub

Good luck!


I am also interested in using meshtastic in caves, primarily for communications during a cave rescue. I’d like to avoid using stupid large hop counts by defining a role for nodes in linear chain. Then we need to work out a way to handle acks. I’ve poked at this some with the simulator. I see an issue with collisions leading to messages stopping moving along the chain. Since a node likely has two neighbors, and the neighbors can’t here each other, it is possible for both neighbors to transmit at once, leading to a collision. I would like the solution to be compatible with regular networks so we can leverage the mesh nature for nodes on the surface.

We’ve done some basic in cave testing and need to do more to get a feel for node placement. We did have mqtt set up and it was pretty cool to message from inside a cave to a friend at home who has the other end of mqtt setup.


If you talking about my interactive web simulator, I’ve also observed this issue with linear chains. Messages can get stopped by crosstalk.
… but I think in reality it wont be quite as bad, not sure the actual mechanics but there is a variable wait between detection of clear airwaves and actual transmission, which lessens the chance of crosstalk (my simulator doesnt do this at all)

What I get the feeling is needed a way for nodes to retry messages, at the individual node level (not just from the origin sender node), so that messages can retry if not ACK’ed.
… but seems like this would be a bigger change to routing algorithm, but would be more robust.

A more promiscuous repeater (that doesnt decerment the hoplimit) doesnt seem like will help all that much, as messages will still be stalled by crosstalk. And would as noted above, just get more bounces of the same message back and forth.

Hi fifi314,

thanks for your feedback. I had no opportunity for rl testing yet. But I prepared a couple of nodes and some hand tuned antennas of different types for reachable distance comparison. I agree that proper node placement will be essential for a successfull implementation of a com chain. I think depending on the type of cave and the cave geometry, it will ultimately take some experience to find the ideal node distribution. If you already have experience, I would like to know what the cave plan looked like and what distances you were able to achieve between the nodes.

My idea is that a mesh network is ideal not only for cave rescue but also generally within a research and expedition team, especially if the participants are widely dispersed in large spaces or the noise level in water-bearing parts makes direct communication impossible. In all cases, however, the resulting network will consist of a real mesh within a group on one side and a real mesh outside the cave connected with a linear chain of nodes in between. A bit like a weight trade. This could potentially be a real challenge for the routing algorithm.

There is some good data on in cave testing here: GitHub - semper-ad-fundum/vangelis: Long range, low power messaging system based on Meshtastic relays suitable for underground communications


Thank you. Very interesting report and results.

Add this feature to my fork …

Have you already received a traceroute with 7 hops (so 9 nodes in the list)?

Unless really needed (I would first place your nodes more strategically, higher up and use better antennas), or in the specific example of a cave with nodes in a linear topology, I wouldn’t recommend this. It will likely create unnecessary rebroadcasts and it will mess up the hops_away metric (which controls retransmissions and automatic assignment of hop limits for ACKs/responses) and NeighborInfo module.

It depends. In principle, I agree with you.

If your location is far away and you need several repeaters in strategically unfavorable intermediate stations, then I can see this as a solution. Not everyone can position a repeater in a prime location. Most nodes will have a hop limit of 3, i.e. they will not be able to answer you.

I am aware that many feature requests will not be approved by decision-makers because they are fundamentally opposed to them. On the other hand, everyone can adapt the source to their own needs.

@roha-github: Thanks for the code snippet and the link to the fork.

@GUVWAF: Here in my area in rl I get a couple of 5 hop traceroutes and very rarely some 6 hop ones. No 7 hop so far.

Regarding caves or linear topology meshes:
My current understanding is, that there is a danger of cluttering up the mesh. In the situations I’ am planning for, there is the linear ‘chain’ mesh acting as a kind of backbone comm line. And then there are teams which might need to communicate between each other. But there is no need that the communication of one team creeps into that of another. Only messages that are intented for inter team communication or communication with the base camp need to travel along the backbone mesh. So essentialy there are messages which need two different hop count limits. Inteam messages actually need no more than 3 or even 2, but backbone line messages would need i.e. 7.

So that would conclude that one would use two channels, one for inteam comm and one for inter team or base camp comm. And that also would indicate that instead of beeing set on the device level, the hop count limit may better be a parameter of individual channels, so depending on the channel used, your messages would get different initial hop counts - keeping the backbone line free of unneccesary clutter.

1 Like