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.

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% threshold. Above that level, collisions increase sharply 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. 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

Open the Meshtastic app and navigate to Channel → Utilization. If utilization is above 25% and rising when no one is actively sending, something is re-broadcasting excessively.
Check the node list for any duplicate node names or IDs that might indicate a misconfigured clone.
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 → Device → 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 or ~~ROUTER_CLIENT (deprecated; use ROUTER or REPEATER instead).~~ROUTER_CLIENT.