My node is flooding the channel with repeated messages

My node is flooding the channel with repeated messages

If you notice unusually high channel utilization, see the same message appear many times in quick succession, or other mesh users report your node is hammering the airwaves, your node may be contributing to a flooding condition. Here is how to understand it, diagnose it, and fix it. (Note: the role and menu details below are Meshtastic-specific. If you run a MeshCore repeater that is over-flooding, MeshCore repeaters use selective/path-based forwarding rather than managed flooding - reduce duty cycle and how often the node broadcasts its position/adverts to cut congestion.)

Is flooding always a problem?

Some re-broadcasting is normal and intentional in a mesh network. When a node receives a packet it has not seen before and its hop limit allows, it re-broadcasts so the message can reach nodes that did not hear the original. Meshtastic uses a managed flood routing approach where every ROUTER node re-transmits. What becomes a problem is when the same packet circulates far more times than needed, driving channel utilization above the recommended 25% level. Meshtastic treats roughly 25% as the green/optimal soft ceiling for channel utilization: above it the firmware's contention window scales up and TX is deferred, collisions increase, and overall throughput degrades for every node on the channel.

Common causes

• Two ROUTER nodes in direct line-of-sight of each other: When both nodes hear each other perfectly and both re-broadcast the same packet, they can trigger a forwarding loop if the hop count has not decremented to zero. Each re-broadcast is heard by the other, which may queue another retransmit depending on firmware version.
• Bridge nodes on the same channel: Nodes configured as bridges can inadvertently re-introduce packets to a segment that already received them if the bridge logic is not configured correctly, creating a loop.
• Hop limit set too high: The default hop_limit is 3, meaning a packet can traverse up to 3 intermediate nodes before being dropped (the maximum is 7). If it has been set to 7 or higher, packets live long enough to circle back through the network.
• Multiple nodes with the same node key or ID: Duplicate node identities confuse deduplication logic, causing packets that should be discarded to be treated as new.

How to diagnose

1. Open the Meshtastic app and check your node's channel utilization in its device metrics. If utilization is above 25% and rising when no one is actively sending, something is re-broadcasting excessively.
2. Check the node list for any duplicate node names or IDs that might indicate a misconfigured clone.
3. Temporarily power down nodes one at a time and watch whether utilization drops - this isolates the culprit node.

Fixes

• Reduce hop_limit to 3 (Radio Config → LoRa → Hop Limit). For most deployments, 3 hops is sufficient to cross a well-designed mesh.
• Change ROUTER nodes to CLIENT role for nodes that do not need to relay traffic. CLIENT nodes do not re-broadcast, which dramatically reduces airtime.
• Review bridge node configuration: Ensure bridge nodes have channel isolation configured correctly so they do not echo packets back onto the originating channel.
• Enforce firmware-level deduplication: Keep all nodes on current stable firmware. Older firmware versions had less aggressive deduplication windows.
• Stagger node placement: If two ROUTER nodes are in perfect line-of-sight, consider whether both need to be ROUTERs, or whether one can be demoted to CLIENT.

Keep in mind that each relaying node adds another full transmission of the packet, so total airtime scales with the number of relays (roughly one transmission per relay plus the original), not just with hop count.