MeshCore Routing: Flood-First, Direct-Route-After

Path-Based

This Routing:page RREQdescribes andMeshCore's RREProuting mechanism as verified from docs/packet_format.md in the official MeshCore repository. Note: earlier versions of this page incorrectly used AODV terminology (RREQ/RREP). MeshCore does not use that terminology or protocol.

How MeshCore Routing Actually Works

MeshCore path-based routing isuses a fundamentalflood-first, architecturaldirect-route-after departuremechanism:

from

Step 1: Flood Routing (First Message)

When a node sends a message to a destination it has no path for, the floodingpacket modeluses usedROUTE_TYPE_FLOOD. byEvery Meshtasticrepeater andin manyrange other low-power mesh networks. Understandingre-broadcasts the mechanics of route discovery through the Route Requestpacket (RREQ)subject andto Routeflood Reply (RREP) messages is essential for diagnosing connectivity issues, planning repeater deployments, and understanding network behaviour under load.

Flooding vs. Path-Based Routing: The Fundamental Contrast

Flooding (Meshtastic Model)

In a pure flooding model, every node that receives a packet retransmits it. The packet propagates outward through the network like ripples from a stone dropped in water. Every node within radio range of any retransmitter eventually receives a copy.limits). The destination node receives the message afterthrough somewhatever number of hops; all intermediate nodes receive and retransmitpath it whetherarrived oron.

not

Step they2: arePath on the optimal path.Return

The broadcastdestination amplificationnode factorresponds forby floodingsending isback approximatelya NPAYLOAD_TYPE_PATH transmissionspacket. perThis packet contains the complete list of repeaters through which the original flooded message inarrived. anThe N-nodepath networktravels before duplicate suppression. In dense networks this creates a broadcast storm: airtime is consumed by redundant retransmissions on overlapping frequencies, dramatically reducing effective throughput. Meshtastic mitigates this with duplicate packet filtering by hash, a hop limit field, and role-based forwarding, but the fundamental characteristic remains that every message propagatesback to the entireoriginal reachable mesh regardless of destination.sender.

Path-BasedStep 3: Direct Routing (MeshCoreSubsequent Model)Messages)

MeshCoreArmed discoverswith athe learned path, the sender now uses ROUTE_TYPE_DIRECT for subsequent messages. The packet embeds the repeater list, and only those specific pathrepeaters betweenforward sourceit. andAll destinationother beforerepeaters transmittingignore data,the thenpacket sendsentirely.

data

Why onlyThis alongIs thatMore path.Efficient TheThan controlPure overheadFlooding

of

RREQAfter andthe RREPinitial is incurred once per route discovery;flood, all subsequent messages toin thea sameconversation destinationuse travel only the path nodes. Nodes not on the path do not retransmit data frames at all. This is conceptually similar to AODV (Ad hoc On-Demand Distance Vector)direct routing in— 802.11dramatically wirelessless meshchannel networks,airtime adapted for LoRa constraints: low data rate, half-duplex operation, and high collision sensitivity.

Route Request (RREQ)

A Routebusy Requestnetwork iswith broadcastmany whenestablished conversations generates far less channel overhead than a sourcepure nodeflood wantsmesh toPath reachre-learning happens automatically if a destinationdirect-routed formessage which it has no route cache entry. The RREQ frame contains:

Source address: 4-byte identifier of the originating node Destination address: 4-byte identifier of the target node Sequence number: monotonically increasing counter used to detect and discard duplicate RREQs at any forwarding node Hop count: incremented by each intermediate node to limit RREQ propagation range Path accumulator: each forwarding node appends its own 4-byte address, building a record of the path from source to current forwarder

The RREQ is broadcast by the source; intermediate repeaters receive it, check their duplicate-suppression cache for this sequence numberfails (discarding if already seen), increment the hop count, append their address to the path accumulator, and rebroadcast. This controlled flood continues until the RREQ reaches the destination or the hop limit is exhausted. Only repeaters forward RREQs; client nodes in default configuration do not.

Route Reply (RREP)

When the destination node receives a RREQ, it generates a Route Reply sent unicastfalls back to theflood)

source along

Route theTypes reverseReference

oftheRoute TypeWhen Used ROUTE_TYPE_FLOODInitial contact; all group/channel messages ROUTE_TYPE_DIRECTPoint-to-point after path accumulatedis known ROUTE_TYPE_TRANSPORT_FLOODFlood with regional transport code ROUTE_TYPE_TRANSPORT_DIRECTDirect-routed with regional transport code

Source: docs/packet_format.md in the RREQ. This is the key efficiency distinction: the RREQ floods outward, but the RREP travels only the discovered path.

The RREP frame contains the original source address, the responding node address, the full ordered path sequence, and the route lifetime. Each intermediate node on the return path receives the RREP, installs the route entry in its local route table, and forwards the RREP to the next hop toward the source. By the time the RREP reaches the original source, every node along the path has a route entry for this source-destination pair, enabling them to forward subsequent data frames without broadcasting.

Route Table Maintenance

Everyofficial MeshCore repeaterrepository. maintainsVerified a route table mapping destination addresses to next-hop addresses and full path records. Entries include: destination address, next hop address, full path, sequence number of the most recent RREQ or RREP that established this route, timestamp of last use, and route metric (currently hop count; RSSI-weighted metrics are possible in future versions).2026-05-03.

Route tables are stored in RAM and are lost on reboot. After a repeater restarts, active node communication repopulates the route table through normal RREQ/RREP traffic. The main impact of a repeater restart is a brief period of elevated RREQ traffic as all routes through that repeater must be rediscovered.

Route Expiry and Rediscovery

Routes expire after a configured lifetime of inactivity. Expiry prevents the route table from growing unboundedly and ensures that routes to nodes that have moved or gone offline are eventually flushed. When a source node wants to send a message and the route has expired or was never established, it initiates a new RREQ cycle, typically buffering the outbound data frame for immediate transmission after the RREP is received and the route is installed.

What Happens When a Repeater on a Cached Route Goes Offline

When a repeater in the middle of an established route powers down, moves out of range, or fails:

Immediate delivery failure. The first data frame sent along the now-broken route will not be acknowledged. The sending node waits for an ACK timeout. RERR generation. The node adjacent to the failure (whose next-hop is now unreachable) generates a Route Error (RERR) message identifying the failed link and sends it upstream toward the original source. Route invalidation. Nodes that receive the RERR remove the affected route from their tables. RREQ retrigger. If the source still has data to send, it immediately initiates a new RREQ for the destination. If an alternate path exists through a different repeater, the RREQ succeeds and routes around the failure. Recovery time. Approximately: ACK timeout plus RERR propagation time plus new RREQ/RREP round-trip time. With typical LoRa parameters this is on the order of 10 to 60 seconds depending on hop count and airtime per packet.

If no alternate path exists, the RREQ will time out without a RREP. The source retries a configured number of times, then reports the destination as unreachable. The destination remains unreachable until the repeater comes back online or a new repeater providing an alternate path joins the mesh. This underlines the importance of path diversity: critical links should have at least two independent repeater paths, and repeater placement should treat route redundancy as a first-class requirement.