MeshCore routing algorithms
Discover how MeshCore messages first reach destinations through flood discovery, then often move through a learned path for follow-up traffic.
How does a message find its way through the mesh network?
In a mesh network there is no central router that determines which route a message should take. Instead, MeshCore uses intelligent routing algorithms that ensure messages automatically find the most efficient route to their destination.
Key difference from generic mesh explanations: MeshCore clients do not repeat. Forwarding is done by repeaters (and room servers with repeat enabled).
MeshCore can use flood routing for initial discovery, then learn path information from delivery reporting so later unicast traffic can be forwarded more directly.
How MeshCore Routing Actually Works
MeshCore combines discovery flood behavior with path-based forwarding for follow-up traffic:
Initial flood for reachability
When no path is known yet, traffic can be flooded through repeaters so a destination can still be reached.
Clients do not repeat
MeshCore clients are not forwarding nodes. Repeater behavior lives at repeater/room-server level.
Path learning after delivery
After a successful delivery, path information can be reported back (which repeaters were traversed), giving a known route for later traffic.
Targeted forwarding for follow-up traffic
Later unicast traffic can then follow known repeater paths instead of broad flood behavior every time.
Discovery and Path-Based Forwarding
In practice, MeshCore routing is usually a two-phase flow:
Step 1: First message via discovery flood
A client sends traffic. Repeaters provide discovery coverage so the destination can be reached when no route is known yet.
Step 2: Delivery and return path information
After delivery, the destination can return path context, allowing a known repeater route for subsequent messages.
Step 3: Follow-up traffic on known path
Subsequent unicast messages can be forwarded more directly through the learned repeater path.
Step 4: Fallback when paths break
If a known path fails, MeshCore can fall back to discovery/flood behavior to find a usable route again.
Important MeshCore Interpretation Points
To describe MeshCore accurately, keep these points explicit:
- • Clients do not repeat: forwarding behavior is repeater-side.
- • Flood is mainly for discovery: follow-up traffic does not need full flood every time.
- • Path information is learned: delivery context can guide later forwarding.
- • Fallback remains available: discovery flood can be used again if paths break.
Hops and Limits in MeshCore
Internal firmware bound
According to MeshCore FAQ references, firmware has an internal maximum of 64 hops.
Repeater flood bounding
Repeaters can constrain flood behavior with `set flood.max`, tuned for your network goals.
Retries on broken path
The value 3 is often referenced for retry behavior on broken paths, not as a universal default hop limit.
Practical framing
A practical MeshCore summary is to use documented protocol limits and tune repeater forwarding for local conditions:
Firmware internal: max 64 hops Repeater tuning: set flood.max <value> Path break: retry behavior up to 3 attempts
This keeps the page aligned with MeshCore behavior instead of generic or Meshtastic-like managed flooding descriptions.
Advantages of MeshCore routing
Self-organizing
No configuration needed. Nodes automatically find the best routes without central control.
Energy-efficient
Because clients do not repeat and follow-up traffic can be more path-directed, airtime and power use are easier to control.
Robust against failure
If one route fails, messages automatically find an alternative path through the network.
Scalable range
Adding well-placed repeaters improves resilience and usable reach without centralized infrastructure.
Simple protocol
Combining discovery flood with learned-path forwarding stays understandable without fully static routing tables.
No single point of failure
No central router means there is no single point that can crash the entire network.
Routing Configuration Examples
Practical tuning should focus on documented repeater behavior:
CLI: Enable repeater forwarding
Forwarding belongs on repeaters. Ensure repeat is explicitly enabled on repeater nodes:
set repeat on
CLI: Tune flood boundaries
Constrain flood behavior at repeater level according to your topology:
set flood.max <value>
Validate path-based behavior
Confirm that follow-up unicast uses learned repeater paths, with discovery flood as fallback when required.
1) Send initial message (discovery) 2) Inspect delivery/path context 3) Send follow-up message to same destination
Frequently asked questions about routing
Is MeshCore purely a flooding system?
No. Flood behavior is used for discovery/reachability, then MeshCore can use learned path information for more targeted follow-up forwarding.
Do all MeshCore nodes repeat traffic?
No. MeshCore clients do not repeat. Forwarding is handled by repeaters (and room servers with repeat enabled).
Is a low fixed hop claim a safe general statement?
No. MeshCore references typically mention an internal firmware bound of 64 hops. The value 3 is associated with retry behavior on broken paths, not a universal default hop limit.
Where does `set flood.max` fit in?
`set flood.max` is repeater-level flood tuning. It does not change the core explanation that follow-up traffic can be path-directed after discovery.
Should this page claim RSSI/SNR forwarding priority as MeshCore fact?
Only if you can point to current official MeshCore documentation for that exact behavior. Otherwise keep the wording limited to documented routing behavior.
What is the safest one-line summary?
MeshCore is not "always flood everything": it combines discovery flood with learned-path forwarding through repeaters for follow-up traffic.
MeshCore Routing Explained Correctly
The core model is: clients do not repeat, discovery can use flood behavior, and follow-up traffic can be sent more directly over learned repeater paths.