How mesh routing works

The problem a mesh has to solve

In a mesh, any node may relay traffic for any other. A packet from A to B might cross one hop or ten, and the topology changes whenever someone switches a node off, a tree grows leaves, or a link fades. Three broad approaches exist:

Real systems mix these. Several of the LoRa systems below start with a flood and then remember what they learnt.

Hop count and link quality

The simplest metric is hop count: prefer the path with the fewest relays. It is cheap to compute and often wrong on radio, because a single poor hop can be slower and lossier than two good ones.

Link-quality metrics try to fix this. A well-known example is ETX (expected transmission count): the average number of transmissions needed to get a packet across a link, so a lossy link scores worse than a clean one. A route's cost is then the sum over its links.

What the protocol sources say:

• OLSRv2 "supports link metrics beyond hop count" and selects the route with the minimum sum of link metrics (RFC 7181).
• B.A.T.M.A.N. nodes broadcast originator messages; early versions judged links by packet loss, and B.A.T.M.A.N. V uses a throughput-based metric (Wikipedia).

We did not find ETX named in the protocol documents we read, so the examples above are the sourced claims; ETX is explained here as a general concept.

Routing protocol families

OLSRv2 (link-state). A proactive, table-driven protocol for mobile ad hoc networks. It uses multipoint relays (MPRs): "only the flooding MPRs of a router will retransmit messages received from that router". This keeps flooded control messages from multiplying across every node (RFC 7181).

Babel (distance-vector). Designed for wired and wireless meshes, with sequence-numbered routes to avoid loops. RFC 8966 says it "strongly limits the frequency and duration of routing pathologies such as routing loops and black-holes during reconvergence". It sends more periodic traffic than an event-driven protocol such as OSPF. RFC 8966 (January 2021) replaced RFC 6126 and RFC 7557.

B.A.T.M.A.N. and batman-adv. Nodes broadcast originator messages (OGMs). Each node tracks only the direction from which the best OGMs arrived and forwards accordingly, so nobody holds a full map. batman-adv works at layer 2: it presents a virtual interface and "transparently transports Ethernet packets". It has been in the Linux kernel since 2.6.38. Note that we could not read the primary open-mesh.org documentation (it sat behind a bot wall), so details such as the transmit-quality calculation are not covered here.

How each named network routes

Meshtastic: managed flooding

Meshtastic nodes rebroadcast a packet until its hop limit runs out. The limit "can't be greater than 7. Default is 3 which should be fine for most applications." Before rebroadcasting, a node listens briefly. The contention window is small for low-SNR (more distant) signals, so farther nodes tend to rebroadcast first, which extends coverage with fewer redundant transmissions. ROUTER and ROUTER_LATE roles rebroadcast even when they hear others relay.

For direct messages the docs describe next-hop routing (documented as v2.6 and later). After a flooded delivery succeeds, the relay that carried the response is remembered and used instead of flooding, falling back to managed flooding if that fails. Broadcasts always flood. Reliable broadcasts are sent up to 3 times in total and reliable direct messages up to 5.

MeshCore: flood to discover, then direct

MeshCore separates roles. Only repeaters and room servers with repeating switched on retransmit; companion (client) devices deliberately do not. Group channels use flood routing only. For a direct message, the first message floods; the destination returns a delivery report carrying the repeater path, and later messages use that direct path. Repeaters can cap flood spread with a setting. The firmware allows up to 64 hops with 1-byte path hashes, 32 with 2-byte hashes and 21 with 3-byte hashes.

Reticulum: announces and path tables

Reticulum has no IP-style addresses. Destinations are 16-byte hashes derived from truncated SHA-256. A destination makes itself known by sending an announce, which propagates through transport nodes and is forwarded up to 128 hops by default; where bandwidth is scarce, announces for the closest destinations get priority. "No single node in a Reticulum network knows the complete path to a destination": each transport node only records the most direct way to move a packet one hop closer. Packets carry no source addresses (see privacy and encryption).

NYC Mesh: BGP outward, OSPF inward

According to NYC Mesh's current wiki overview, BGP connects the internal network to the Internet, while OSPF carries "all internal networking, including Supernodes to Hubs, Hubs to Rooftops, Rooftops to Rooftops, VPNs, and most on-prem hosted services". Older revisions of the wiki are reported to describe BGP between hubs and BMX6 on older OpenWrt nodes (circa 2015); we only saw that in a search snippet and treat it as legacy. See NYC Mesh.

Freifunk: batman-adv and Gluon

Gluon is "a modular framework for creating OpenWrt-based firmware images for wireless mesh nodes" and ships a batman-adv package; several German Freifunk communities use it. B.A.T.M.A.N. itself was developed by the German Freifunk community. See Freifunk.

Guifi.net: BGP at the backbone

A Freifunk Google Summer of Code report from 2014 describes a backbone of supernodes running dynamic routing, with client routers in an access layer. BGP is the main protocol, with mesh clouds running BMX6; OSPF and OLSR also appear. Treat that as a historical description, not current configuration. See Guifi.net.

An illustration

Flooding (Meshtastic broadcast, hop limit 3)

 A ──► B ──► C ──► D ──► E

 A sends with hop limit 3
       B relays (limit now 2)
             C relays (limit now 1)
                   D relays (limit now 0)
                         E receives it with limit 0 and does not rebroadcast

Flood-then-direct (MeshCore direct message)

 1. A floods the first message via repeaters R1..Rn
 2. B's delivery report carries the repeater path back
 3. Later messages follow A ► R2 ► R5 ► B only

Routing protocol (OSPF / batman-adv style)

 Every router holds a cost to each destination
 and forwards to the best neighbour; no flooding of user data

Why this matters for what you can build

Flooding is simple and robust when traffic is light, which is why it suits low-rate LoRa meshes: see LoRa vs Wi-Fi mesh. It does not scale well, since every extra relay spends scarce airtime. Networks that carry broadband traffic need routing protocols that avoid sending user data everywhere. To choose between the approaches in practice, start with which mesh is right for you.