Meshtastic Hop Limits and Rebroadcasting Explained

How far packets are allowed to propagate, which nodes relay them and why larger values can reduce reliability.

The hop limit is a packet’s relay budget. Each time an eligible node rebroadcasts the packet, the remaining value is reduced. A larger value can reach farther through a chain, but it also exposes a larger part of the network to the packet and its duplicates. It is not a transmit-power setting and does not improve a weak first link.

Current Meshtastic documentation permits a maximum of 7 and defaults to 3, with explicit guidance that 3 is enough for most applications. A public network should treat that default as an engineering constraint to test around, not a low value to maximize.

What a hop means

A direct sender-to-receiver link uses no intermediate relay. If one other node repeats the packet, that path contains one relay hop. The hop limit determines how many forwarding stages are allowed before propagation stops.

The setting attached to a transmitted packet is not a promise that exactly that many relays will occur. Managed flooding, duplicate suppression and actual radio reach determine which nodes participate.

Why more hops can make delivery worse

Each relay occupies airtime and creates another collision opportunity. A high hop limit can spread ordinary local traffic across an entire region, where it competes with position, telemetry and messages that actually need long paths. Hidden nodes may transmit simultaneously because they cannot hear one another.

Retries and acknowledgements add further traffic. Once utilization rises, increasing hops can reduce the probability that any one packet survives.

Use edge exceptions, not blanket inflation

Meshtastic’s configuration tips recommend changing hop count only where necessary, especially at network edges, rather than raising it on central nodes. This contains the impact of a special long path.

Before changing it, use traceroute, controlled tests and coverage observations. If an endpoint needs four relays every day, consider whether one better intermediate site could shorten and stabilize the route.

Rebroadcast modes

ALL is the normal default and can relay compatible packets beyond the node’s own decryptable channels. LOCAL_ONLY limits forwarding to traffic on local configured channels. KNOWN_ONLY further restricts traffic to node numbers present in the local database. CORE_PORTNUMS_ONLY filters non-core applications, while NONE is available only for certain non-relaying roles. REPEATER can use ALL_SKIP_DECODING.

These modes are policy tools, not simple performance buttons. LOCAL_ONLY can protect a private installation from foreign traffic but also removes it from shared public forwarding.

Roles and rebroadcast priority

Ordinary CLIENT nodes already rebroadcast. CLIENT_MUTE listens and transmits its own traffic without contributing general relays. ROUTER and REPEATER are privileged and should be scarce. SENSOR and TRACKER can use specialized power behavior and may be configured not to relay.

A stationary device is not automatically infrastructure, and infrastructure is not automatically a router. Assign the role that matches a verified network requirement.

Public-network recommendation

Start at maximum hops 3, default rebroadcast behavior and CLIENT for most devices. Make exceptions in writing: which path requires them, what measurement justified them and when they will be reviewed.

If congestion appears, reduce excessive automatic broadcasts and privileged relays before breaking the region into incompatible settings. The aim is useful delivery, not the largest theoretical propagation radius.

Diagnosing before increasing hops

First determine whether the destination is heard at all. If the first relay never receives the packet, adding hops changes nothing. Then examine whether a candidate path exists, whether nodes use compatible radio settings and whether a restrictive rebroadcast mode blocks the traffic. Only after those checks should an extra hop be tested.

Compare delivery across several times and directions. A single successful traceroute is useful evidence but not proof of a stable path. Congestion and propagation can change the result.

Containment as a design principle

Local conversations should remain local enough that distant users retain capacity. Hop limits are the principal boundary on a flood, while rebroadcast modes define which traffic a node is willing to carry. Communities should choose these values with both coverage and containment in mind.

A central high site deserves the most conservative settings because it reaches the largest collision domain. Edge nodes are safer places to test a narrowly justified exception.

How these settings work together

No setting should be evaluated in isolation. A slower preset increases packet airtime; a larger hop limit multiplies that airtime across more relays; frequent position and telemetry packets create a permanent load; and privileged repeaters can produce additional copies. Conversely, a well-sited node using ordinary CLIENT behavior may extend the mesh effectively without special privileges.

For a public deployment, document the complete profile and the reason for every exception. Test delivery in both directions, during quiet and busy periods, and retain a way to reverse remote changes. Revisit the profile as the network grows.

Related configuration guides

Official sources

Meshtastic firmware and documentation change over time. Confirm setting names, defaults and regional requirements in the current official documentation before changing live infrastructure.