Managed flooding, duplicate suppression, acknowledgements and why Meshtastic is not a route-table mesh.
Meshtastic is commonly described as a mesh network, but that phrase can create the wrong mental model. Nodes do not normally calculate and maintain one optimal end-to-end route like an IP routing protocol. Most Meshtastic traffic uses managed flooding: eligible nodes that hear a packet may rebroadcast it until its hop allowance is exhausted.
The word managed matters. Nodes wait for a contention period before relaying. A more distant node that received a weaker signal can get an earlier opportunity, while nearer nodes suppress their own duplicate transmission after hearing that relay. This probabilistic behavior extends reach without requiring every node to repeat every packet.
A broadcast begins
The sender transmits a packet with a hop limit. Nearby compatible radios receive it. If the remaining limit and local role permit rebroadcasting, they prepare to relay after a delay. When one node relays, other candidates that recognize the duplicate can stand down.
The process repeats outward until the hop limit reaches zero. Nodes may still receive and process a zero-hop packet, but it is not propagated again.
Why weaker reception can relay first
The contention window incorporates received signal-to-noise ratio. A node farther from the sender will often see a lower SNR and can relay earlier. If closer nodes hear that copy, they suppress their own retransmission. This favors geographic progress rather than simply choosing the first or strongest neighbor.
It is not a guaranteed geographic route. Terrain, hidden transmitters, collisions and asymmetric links can produce multiple copies or different paths on successive messages.
Routers and repeaters change the balance
ROUTER and REPEATER roles have privileged rebroadcast behavior. They can relay with higher priority and may retransmit even after hearing another copy. That is useful only when the privileged node occupies a genuinely strategic position. Many privileged nodes increase duplicates and contention.
A public mesh should not make every fixed or solar node a router. CLIENT nodes already participate in managed flooding. Role is about behavior, not prestige.
Direct messages and acknowledgements
A direct message still travels across the shared mesh and may use multiple relays. Delivery acknowledgement can confirm that the destination received it, but retries and acknowledgements also consume airtime. A successful route today is not a permanent stored path.
Traceroute is an investigative feature rather than the routing engine. It records the path taken by the first traceroute request that reaches the destination; another packet may take another path or arrive in duplicate.
Encryption does not necessarily stop relaying
With default rebroadcast behavior, nodes sharing radio settings can relay packets from other messaging channels even when they cannot decrypt them. This is how private groups can use common infrastructure. Operators can restrict this with LOCAL_ONLY, KNOWN_ONLY or other rebroadcast modes where supported, but doing so changes the node’s contribution to the wider mesh.
Radio compatibility therefore defines the potential relay population; messaging keys define who can read content.
Implications for network design
Place nodes to create useful radio paths, keep hop limits restrained and reserve privileged roles for tested backbone locations. If delivery is poor, inspect the physical path and signal quality before increasing the flood radius.
Because flooding consumes shared capacity across an area, a regional mesh scales through disciplined traffic and good topology—not by treating every additional node as a conventional routed access point.
An example across a valley
Imagine Alice below a ridge, one ordinary node on the ridge and Bob in the next valley. Alice’s packet reaches the ridge node, which rebroadcasts it with one fewer hop available. Bob receives that copy. No route was installed beforehand, and the ridge node does not become Alice’s permanent next hop. If another elevated node is available tomorrow, contention and reception conditions may produce a different first successful path.
If several ridge nodes hear Alice, the node with the more useful distant reception may relay first while the others suppress duplicates. Hidden-node conditions can still produce more than one copy, which receivers identify and discard.
What routing cannot guarantee
Managed flooding provides resilience without central control, but it cannot guarantee latency, capacity or a symmetric path. A can hear B does not prove B can hear A; transmit power, antenna patterns and local noise may differ. Acknowledgements help verify a particular delivery but do not reserve future capacity.
This is why maps should distinguish observed links from inferred coverage. A visible node list is evidence of reception, not a complete routing table.
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
- Choosing the Right Meshtastic LoRa Preset
- Meshtastic Channels, Encryption and Private Groups
- Meshtastic Hop Limits and Rebroadcasting Explained
- Meshtastic Network Capacity and Congestion
- Position, Telemetry and Node Information Broadcast Intervals
- Public Meshtastic Network Etiquette
- Recommended Settings for a Public Meshtastic Network
Official sources
- Meshtastic LoRa configuration
- Meshtastic radio settings and preset table
- Meshtastic channel configuration
- Meshtastic mesh broadcast algorithm
- Meshtastic device roles and rebroadcast modes
- Meshtastic configuration tips
- Meshtastic position configuration
- Meshtastic telemetry configuration
Meshtastic firmware and documentation change over time. Confirm setting names, defaults and regional requirements in the current official documentation before changing live infrastructure.
