Hop Limit (Meshtastic)

The hop limit is a Meshtastic LoRa configuration value that controls how far a packet travels across the mesh before it is dropped. Each packet carries a hop count; when a node relays it, the count decrements by one, and once it reaches zero, receiving nodes stop rebroadcasting. The default is 3 and the maximum is 7. This simple mechanism is what keeps a flood-routed mesh from drowning itself in endlessly circulating traffic.

Why the limit exists

Meshtastic uses managed flooding: there is no central router and no routing table, so every node that hears a new packet may rebroadcast it. The protocol is smarter than naive flooding — nodes deduplicate packets they have already seen, and rebroadcast timing is weighted so that nodes which received the packet weakly (and are therefore likely farther away) tend to relay first, extending coverage with fewer transmissions. But none of that bounds how far a packet propagates; only the hop limit does. Without it, packets would ricochet across the network indefinitely and saturate the shared LoRa airtime, which is a scarce, legally duty-cycle-limited resource in most regions. Capping hops bounds the rebroadcast radius, conserves the airtime budget on congested channels, and keeps latency predictable.

The counterintuitive part: more hops can mean worse reach

Raising the limit extends theoretical reach but multiplies channel utilization: every additional hop means every intermediate node spends airtime re-transmitting the same payload, and on a busy mesh those rebroadcasts collide with fresh traffic. A network of chatty nodes all set to hop limit 7 can perform dramatically worse than the same network at 3, because the medium is jammed with echoes. This is the classic shared-medium lesson — the mesh is a commons, and hop limit is the fence that keeps one packet from grazing the whole pasture. Note also that the hop limit governs relay distance, not delivery guarantees: a packet that runs out of hops simply dies quietly, and only certain traffic types are acknowledged end to end.

Tuning guidance

For most deployments the default 3 covers several kilometers of node-to-node relaying and is the right starting point. Increase it only when you have confirmed dead zones and a sparse network where extra relays genuinely help — a rural corridor of well-spaced nodes is the legitimate use case, a dense urban mesh is not. Before reaching for more hops, fix the physical layer first: elevation, antenna quality, and a solid link budget on the key backbone hops buy more real coverage than any hop-limit setting, and a single well-placed high node can collapse a 5-hop path into 2. Because the setting is part of the LoRa config protobuf, it can be changed locally or via remote admin, and it applies to packets your node originates. Hop limit works hand-in-hand with the channel configuration that defines which nodes can decrypt and forward a given message; for the broader theory of flood-style relaying, see mesh routing.

The hop mechanism also doubles as free diagnostics. Received packets carry their remaining hop count, and clients surface this as a "hops away" figure per node — a live map of your network's depth. If a node you expected to reach directly consistently shows up two hops away, something on the direct path changed: an antenna shifted, foliage grew, a relay went dark. If distant nodes arrive with zero hops remaining, traffic from anything farther is silently dying en route, which is the signature symptom of an under-provisioned limit on a genuinely sparse network. Reading these numbers over a few days tells you whether your mesh needs a higher limit, a better-placed relay, or simply a taller mast — three very different fixes for what feels like the same complaint.

For sovereign communicators building infrastructure-free networks, the hop limit is the knob that balances reach against the health of the shared spectrum — set it with the whole mesh in mind, not just your own node.