Imagine a network where no single device matters more than any other. Where you can unplug a router, knock over an antenna, or lose an entire building’s worth of equipment — and the network simply routes around the damage, finds new paths, and keeps working. Where adding a new node makes the network stronger, not just bigger. Where no corporation, no government, and no single point of failure stands between you and the person you are trying to reach.
This is mesh networking, and it is the most important topology in the alternative networking toolkit.
In Chapter 2, we built local area networks — self-contained, useful, but fundamentally limited to a single location. A LAN in your house cannot talk to a LAN in your neighbor’s house unless someone builds a bridge between them. And if that bridge fails, the two networks are isolated again. Mesh networking dissolves this limitation. In a mesh, every node is both an endpoint and a relay. Data hops from device to device, finding whatever path is available, adapting in real time to changes in the network’s shape. The mesh is not a fixed structure — it is a living, self-organizing organism that grows, shrinks, and reconfigures itself as conditions change.
This is not a theoretical curiosity. Community mesh networks serve tens of thousands of people in cities and rural areas around the world. Disaster response teams deploy mesh networks within hours of arriving at a crisis zone. Off-grid communities use mesh to share a single internet connection — or no internet connection at all — across kilometers of terrain. Mesh networking is the technology that turns a collection of isolated nodes into a unified, resilient network.
This chapter covers the theory behind mesh networking, the routing protocols that make it work, the real-world firmware and software projects you can deploy today, and the practical details of building, tuning, monitoring, and troubleshooting mesh networks in the field. By the end, you will understand not just how mesh works, but when it is the right choice — and equally important, when it is not.
A mesh network is a network topology in which each node can communicate with multiple other nodes directly, and data is relayed hop-by-hop from source to destination through intermediate nodes. Unlike a star topology (where everything connects to a single central point) or a tree topology (where devices connect through a hierarchy of switches and routers), a mesh has no center and no hierarchy. Every node is a peer. Every node is a potential relay.
The defining property of mesh networking is multi-hop forwarding: when node A wants to send data to node F, but A can only directly reach nodes B and C, the mesh figures out that A can reach F through B → D → F (or through C → E → F, or through any other available path). This is done automatically by the mesh routing protocol, with no manual configuration required from any human.
Three core principles distinguish mesh networks from other topologies:
Self-organizing. When a new node is powered on within range of an existing mesh, it discovers its neighbors, announces itself, and integrates into the network. No administrator needs to assign routes, configure forwarding tables, or update a central controller. The mesh protocol handles all of this autonomously.
Self-healing. When a node fails, moves out of range, or a link degrades, the mesh detects the change and recalculates routes. Traffic that was flowing through the failed node is rerouted through alternative paths — often within seconds, sometimes within milliseconds. This is the mesh’s most celebrated property, and it is what makes mesh networking so valuable for resilient and alternative networks.
Decentralized. There is no master node, no central controller, no single point of failure. Every node runs the same routing protocol and participates equally in the routing process. You can remove any single node from the mesh (or any two nodes, or any three) and the mesh continues to function, provided alternative paths exist.
In theoretical networking, a full mesh is a topology where every node has a direct link to every other node. In a network of $n$ nodes, a full mesh requires $\frac{n(n-1)}{2}$ links. For 5 nodes, that is 10 links. For 10 nodes, 45 links. For 100 nodes, 4,950 links. Full mesh topologies provide maximum redundancy — if any link fails, every node can still reach every other node directly — but the number of links grows quadratically, making full mesh impractical for anything larger than a handful of nodes.
What we actually build in practice is a partial mesh: each node connects to some other nodes, not all of them. The routing protocol’s job is to find paths through this partial mesh so that every node can reach every other node, even if they are not directly connected. The art of mesh network design is choosing node placement and antenna configuration so that the partial mesh provides enough redundancy for self-healing without requiring so many links that the radio spectrum is overwhelmed.
A useful mental model is to think of a partial mesh as a graph where nodes are vertices and radio links are edges. The mesh is functional as long as this graph is connected — meaning there is at least one path between every pair of nodes. The mesh is resilient when the graph is biconnected — meaning you can remove any single node and the remaining graph is still connected. Network designers aim for biconnectivity as a minimum; truly critical deployments aim for higher connectivity, where multiple simultaneous failures can be tolerated.
Mesh protocols operate at different layers of the networking stack, and this choice has profound implications for how the mesh behaves.
A Layer 2 mesh operates at the data link layer, forwarding Ethernet frames based on MAC addresses. From the perspective of every device connected to the mesh, all nodes appear to be on the same local network — as if they were all plugged into one enormous switch. The most prominent Layer 2 mesh protocol is BATMAN-adv (Better Approach To Mobile Ad-hoc Networking — Advanced). Layer 2 meshes are beautifully simple to use: devices get IP addresses from a single DHCP server, mDNS discovery works across the mesh, and applications that expect a flat LAN work without modification. The downside is scalability — broadcasting a frame to every node on a large Layer 2 mesh generates significant overhead.
A Layer 3 mesh operates at the network layer, routing IP packets based on IP addresses. Each node (or each local network behind a node) has its own IP subnet, and the mesh routing protocol determines how to forward packets between subnets. Babel, OLSR (Optimized Link State Routing), and BMX7 are Layer 3 mesh protocols. Layer 3 meshes scale better because they can aggregate routes and limit broadcast traffic, but they are more complex to configure — each node needs its own subnet, and services that rely on LAN-level discovery (like mDNS or SSDP) do not work across the mesh without additional configuration.
For small community networks (under 50 nodes), Layer 2 mesh with BATMAN-adv is often the simplest and best choice. For larger deployments, a Layer 3 protocol like Babel provides better scalability. Some projects, like LibreMesh, use both simultaneously — BATMAN-adv for local mesh segments and a Layer 3 protocol for routing between segments.
The alignment between mesh networking and the goals of alternative networks is almost perfect:
No infrastructure dependency. A mesh network can be built entirely from consumer hardware. No cell towers, no fiber optic cables, no ISP contracts. A few routers on rooftops, powered by solar panels if necessary, and you have a network.
Community ownership. Each node in a mesh is typically owned and maintained by a different person or household. There is no central operator who can raise prices, change terms of service, or sell your data. The network belongs to the people who build it.
Incremental growth. You do not need to build the entire network at once. Start with two nodes. Add a third when a neighbor gets interested. Add a fourth when someone across the street sees the benefit. Each new node extends coverage and adds redundancy. The network grows organically.
Censorship resistance. With no central point of control, a mesh network is extraordinarily difficult to censor or shut down. An authority would need to physically seize or jam every single node — a logistical impossibility for any mesh of meaningful size.
Disaster resilience. When commercial infrastructure fails, a mesh network built from devices with battery backup or solar power can continue operating. Even if half the nodes are destroyed, the mesh reconfigures around the damage and continues to provide connectivity to the surviving nodes.
In a conventional network, routing is relatively straightforward. Your home router has a simple rule: send everything to the ISP’s gateway. The ISP’s router has routes learned from the global BGP (Border Gateway Protocol) routing table. The path from your device to any destination is determined by a hierarchy of increasingly knowledgeable routers.
In a mesh, there is no hierarchy. Every node needs to figure out how to reach every other node, using only information it can gather from its neighbors. The network topology changes constantly as nodes join, leave, move, or experience varying signal quality. The routing protocol must continuously adapt, using minimal bandwidth for its own control messages while finding paths that are reasonably efficient.
This is a genuinely hard problem, and decades of research have produced three fundamental approaches: proactive, reactive, and hybrid routing.
Proactive routing protocols maintain routes to all destinations at all times, whether or not those routes are currently needed. Every node periodically broadcasts information about the links it can see, and all nodes use this information to build and maintain a complete picture of the network topology.
The advantage is speed: when a node needs to send data, the route is already computed and ready. There is zero delay for route discovery. The disadvantage is overhead: even when no data is being sent, the network is consuming bandwidth with routing protocol messages. In a large mesh with many nodes and frequent topology changes, this overhead can become significant.
OLSR (Optimized Link State Routing Protocol) is the classic proactive mesh routing protocol, defined in RFC 3626. Each node periodically broadcasts HELLO messages to discover its neighbors and TC (Topology Control) messages to disseminate link state information throughout the network. OLSR’s key optimization is the concept of MultiPoint Relays (MPRs): instead of every node rebroadcasting TC messages (which would flood the network), each node selects a subset of its neighbors as MPRs, and only MPR nodes rebroadcast. This significantly reduces overhead while still ensuring that link state information reaches every node.
OLSR works well in networks with moderate size and moderate mobility. It has been widely deployed in community mesh networks, including early deployments of Freifunk. However, its convergence time after topology changes can be slow (several seconds to tens of seconds), and its overhead scales with the square of the network size in the worst case.
Reactive routing protocols do not maintain routes in advance. Instead, they discover routes on-demand, only when a node actually needs to send data to a particular destination. When node A wants to reach node F, it floods the network with a route request. When node F (or a node that knows a route to F) receives the request, it sends a route reply back to A. The discovered route is cached and used until it breaks, at which point a new route discovery is triggered.
The advantage is efficiency in sparse traffic: if most nodes rarely communicate with most other nodes, reactive routing avoids the overhead of maintaining unused routes. The disadvantage is latency: the first packet to a new destination is delayed while route discovery takes place. In a large mesh, route discovery can take hundreds of milliseconds or even seconds.
AODV (Ad-hoc On-demand Distance Vector), defined in RFC 3561, is the classic reactive protocol. It uses route request (RREQ) flooding, route reply (RREP) unicasting, and route error (RERR) messages to discover and maintain routes. AODV is simple and well-understood but suffers from high latency for route discovery in large networks and does not adapt well to link quality variations.
Hybrid routing protocols combine proactive and reactive elements. Typically, they maintain proactive routes within a local neighborhood (where routing overhead is small) and use reactive discovery for distant destinations (where maintaining proactive routes would be wasteful).
The Zone Routing Protocol (ZRP) is the canonical hybrid approach. Each node proactively maintains routes within a configurable zone radius (measured in hops) and uses reactive discovery for destinations outside its zone. The zone radius can be tuned: a larger zone means faster routing but more overhead, while a smaller zone means less overhead but higher route discovery latency for distant destinations.
BATMAN-adv (Better Approach To Mobile Ad-hoc Networking — Advanced) deserves special attention because it is the most widely deployed mesh protocol in community networks. Developed by the Freifunk community in Germany, BATMAN-adv is a proactive Layer 2 mesh protocol implemented as a Linux kernel module.
What makes BATMAN-adv special is its approach to route quality. Unlike traditional link-state protocols that broadcast full topology information, BATMAN-adv uses a decentralized algorithm where each node periodically broadcasts originator messages (OGMs). These OGMs are rebroadcast by neighboring nodes, with each node tracking how many OGMs from each originator it receives via each neighbor. The neighbor through which the most OGMs arrive is selected as the best next-hop for that originator. This is an elegantly simple heuristic: the path through which the most OGMs survive is likely the highest-quality path.
BATMAN-adv operates entirely at Layer 2, encapsulating Ethernet frames within its own transport protocol. This means devices on a BATMAN-adv mesh can use standard DHCP, mDNS, ARP, and any other LAN protocol without modification. A device on one end of the mesh can discover and communicate with a device on the other end as if they were plugged into the same switch.
Key features of BATMAN-adv include:
The current version, BATMAN-adv v5, uses a revised protocol (BATMAN V) that replaces OGM-based throughput estimation with ELP (Echo Location Protocol) for neighbor discovery and OGMv2 for global route dissemination. ELP actively probes link quality, providing more accurate throughput estimates than the passive OGM counting of earlier versions.
Babel (RFC 8966) is a distance-vector routing protocol designed for mesh networks. It operates at Layer 3, routing IP packets between subnets. Babel is notable for its simplicity, its strong theoretical foundations, and its excellent performance in both wired and wireless networks.
Babel works by having each node announce the destinations it can reach and the cost of reaching them. Neighbors receive these announcements, add the cost of the link to the announcing neighbor, and re-announce the destinations with the updated cost. Through this process, every node converges on a routing table that reflects the best paths through the network.
What makes Babel special among distance-vector protocols is its feasibility condition, derived from the EIGRP (Enhanced Interior Gateway Routing Protocol) algorithm. Babel will not adopt a route that could create a routing loop, even temporarily. This means Babel converges quickly and never causes count-to-infinity problems — a classic failure mode of simpler distance-vector protocols like RIP.
Babel also handles link quality elegantly. It supports multiple metrics — including ETX (Expected Transmission Count), which measures the number of transmissions needed to successfully deliver a packet across a link — and can route based on whichever metric is most appropriate for the network.
Babel is used by the Althea community ISP project and is supported by LibreMesh. Its implementation in the babeld daemon is compact, well-tested, and actively maintained.
IEEE 802.11s is an amendment to the Wi-Fi standard that adds mesh networking capabilities directly into the 802.11 protocol. Instead of requiring a separate mesh protocol running on top of Wi-Fi, 802.11s integrates mesh functionality at the MAC layer.
802.11s defines a Mesh Basic Service Set (MBSS) where stations (called mesh points) communicate directly with each other without an access point. The routing protocol used by 802.11s is HWMP (Hybrid Wireless Mesh Protocol), which — as the name suggests — is a hybrid protocol combining proactive tree-based routing with reactive on-demand route discovery.
In theory, 802.11s should be the standard way to build Wi-Fi mesh networks. In practice, it has had a complicated history. Support across different Wi-Fi chipsets is inconsistent, performance has often lagged behind dedicated mesh protocols like BATMAN-adv, and the standard’s complexity has deterred some implementers. The Linux kernel includes an 802.11s implementation in the mac80211 subsystem, and it works reasonably well with supported hardware (primarily Qualcomm Atheros chipsets), but BATMAN-adv remains more popular in community mesh deployments.
That said, 802.11s has one significant advantage: it does not require a separate protocol stack. Any device with a compatible Wi-Fi chipset and a modern Linux kernel can join an 802.11s mesh without installing additional software. For simple deployments where ease of setup is paramount, 802.11s is worth considering.
Choosing a mesh routing protocol depends on your deployment’s size, requirements, and the hardware you have available. Here is a comparison of the most relevant protocols:
| Feature | BATMAN-adv | Babel | OLSR | 802.11s (HWMP) |
|---|---|---|---|---|
| Layer | 2 | 3 | 3 | 2 |
| Type | Proactive | Distance-vector | Link-state (proactive) | Hybrid |
| Implementation | Linux kernel module | Userspace daemon | Userspace daemon | Linux kernel (mac80211) |
| Scalability | ~200 nodes | ~500+ nodes | ~100–200 nodes | ~32 nodes (spec limit) |
| Convergence | Fast (seconds) | Fast (sub-second) | Moderate (seconds) | Moderate |
| Configuration | Minimal | Moderate | Moderate | Minimal |
| Link quality | ELP probing (v5) | ETX, RTT metrics | ETX via plugins | Airtime link metric |
| IPv6 support | Yes (transparent) | Native | Via OLSRv2 | Yes |
| Community adoption | Freifunk, LibreMesh | Althea, LibreMesh | Early Freifunk, OLPC | Limited |
| Best for | Small/medium community mesh | Larger networks, multi-gateway | Legacy deployments | Simple setups, compatible hardware |
Before discussing specific mesh firmware projects, we need to talk about OpenWrt — the open-source Linux-based operating system for embedded devices that underlies virtually every serious community mesh deployment.
OpenWrt replaces the factory firmware on consumer routers with a full-featured Linux distribution. This matters enormously for mesh networking because consumer router firmware simply does not support mesh protocols. Your ISP-provided router cannot run BATMAN-adv or Babel. It cannot be configured as a mesh node. It is designed for one purpose — connecting a household to an ISP — and that is all it will ever do.
OpenWrt changes this. With OpenWrt, a $30 consumer router becomes a fully programmable Linux computer with Wi-Fi radios, Ethernet ports, and the ability to run any networking software. OpenWrt’s package manager (opkg) provides pre-compiled packages for BATMAN-adv, Babel, OLSR, 802.11s, and dozens of other networking tools. Its configuration system (UCI) provides a consistent interface for managing all aspects of the device’s operation.
The most commonly used routers for mesh deployments include:
When selecting hardware for mesh, prioritize: (1) confirmed OpenWrt support, (2) at least two radios (one for mesh backhaul, one for client access), (3) sufficient RAM (128 MB minimum, 256 MB preferred), and (4) sufficient flash storage (16 MB minimum for OpenWrt with mesh packages).
Commotion Wireless was a project of the Open Technology Institute (part of the New America Foundation) that aimed to make mesh networking accessible to non-technical community organizers. Commotion provided a customized firmware based on OpenWrt that preconfigured mesh networking using OLSRd, along with tools for network planning, deployment, and management.
Commotion was used in several notable deployments, including the Red Hook WiFi project in Brooklyn, New York — a community mesh network that proved its value during Hurricane Sandy in 2012 when it provided the only functioning communication infrastructure in the neighborhood after commercial internet and cell service were destroyed.
The Commotion project officially ended active development in 2016, but its code and documentation remain available, and its design principles influenced subsequent projects. Commotion’s most important contribution was demonstrating that mesh networks could be deployed and maintained by ordinary community members, not just network engineers.
LibreMesh is the most actively maintained community mesh firmware project. Like Commotion, it is based on OpenWrt, but it takes a more modular and flexible approach. LibreMesh automatically configures mesh networking on compatible routers with minimal user intervention, using a combination of BATMAN-adv (for Layer 2 mesh) and Babel (for Layer 3 routing between mesh clouds).
LibreMesh’s key innovation is its automatic network segmentation. Rather than putting all nodes on a single flat Layer 2 mesh (which would not scale), LibreMesh creates localized Layer 2 segments (using BATMAN-adv) and interconnects them via Layer 3 routing (using Babel). This provides the simplicity of Layer 2 mesh locally while maintaining the scalability of Layer 3 routing globally.
Features of LibreMesh include:
LibreMesh is used by community networks across Latin America, Southern Europe, and increasingly in Africa and Asia. Its documentation is available at libremesh.org, and its development is coordinated through the AlterMundi organization.
Althea takes a fundamentally different approach to mesh networking: it adds economic incentives. In an Althea network, nodes pay each other for forwarding traffic, with payments flowing automatically via cryptocurrency microtransactions. A node that provides internet access earns money from nodes that consume it. A node that relays traffic between other nodes earns a small fee for each packet forwarded.
This sounds exotic, but it solves a real problem. In traditional community mesh networks, the person who provides the internet uplink bears the cost for the entire network. As the network grows, this becomes unsustainable. Althea’s payment system distributes costs proportionally: you pay for the bandwidth you use, and the payment is split among all the nodes that help carry your traffic.
Althea uses the Babel routing protocol with a custom metric that incorporates price as well as link quality. Traffic is routed along the lowest-cost path, which is typically the path with the best combination of quality and price. Payment channels are managed on the Ethereum blockchain (or compatible networks), and nodes settle their balances periodically.
Althea is not the right fit for every community — the cryptocurrency component adds complexity, and some communities prefer a purely cooperative model. But for communities where sustainable funding for internet access is a challenge, Althea provides a compelling model.
For your first mesh network, simplicity is more important than performance. You want hardware that is cheap, well-supported, and easy to replace if something goes wrong. Here is a minimal shopping list for a three-node mesh:
Option A: Budget indoor mesh (~$75 total)
Option B: Outdoor-capable mesh (~$300 total)
For learning purposes, Option A is ideal. Three small routers on a table, within radio range of each other, let you experiment with mesh protocols without climbing on any roofs.
The following walkthrough assumes you have already flashed OpenWrt onto your routers. If you have not, consult the OpenWrt wiki (openwrt.org) for device-specific flashing instructions — the process varies by hardware model.
Once OpenWrt is running, SSH into each router and install the required packages:
opkg update
opkg install batctl kmod-batman-adv
Now configure the mesh interface. On each node, edit /etc/config/network to add a BATMAN-adv interface:
config interface 'bat0'
option proto 'batadv'
option routing_algo 'BATMAN_V'
option aggregated_ogms '1'
option bridge_loop_avoidance '1'
option distributed_arp_table '1'
option fragmentation '1'
option hop_penalty '15'
Next, configure a Wi-Fi interface for the mesh backhaul. Edit /etc/config/wireless:
config wifi-iface 'mesh_radio0'
option device 'radio0'
option mode 'mesh'
option mesh_id 'my-mesh-network'
option network 'bat0'
option encryption 'sae'
option key 'your-mesh-password-here'
option mesh_fwding '0'
Setting mesh_fwding to 0 is important: it disables 802.11s’s built-in forwarding and lets BATMAN-adv handle routing instead. The mode 'mesh' creates an 802.11s interface, but we are using it purely as a transport layer for BATMAN-adv.
Create a bridge that includes both the mesh and the LAN ports, so that devices plugged into any node’s Ethernet ports can reach each other across the mesh:
config interface 'lan'
option type 'bridge'
option proto 'static'
option ipaddr '10.10.0.1'
option netmask '255.255.0.0'
list ports 'bat0'
list ports 'eth0'
Assign each node a unique IP address on the same subnet (e.g., 10.10.0.1, 10.10.0.2, 10.10.0.3). Then restart networking:
/etc/init.d/network restart
With all three nodes configured and powered on, they should discover each other automatically. Verify the mesh is working with batctl:
# List discovered mesh neighbors
batctl neighbors
# Show originator table (all known mesh nodes)
batctl originators
# Ping another mesh node
batctl ping <mac-address-of-remote-node>
# Trace the route to a remote node
batctl traceroute <mac-address-of-remote-node>
If everything is working, you should see all three nodes in the originator table from any node. You should be able to ping any node from any other node, even if they are not direct neighbors (provided a multi-hop path exists).
The real test of a mesh network is not whether it works — it is whether it heals. Set up a simple test:
ping 10.10.0.3Now try a more interesting test. Place all three nodes within range of each other (a triangle topology: A — B — C — A). Ping from A to C. The mesh will choose the best path — probably the direct link from A to C. Now degrade that link (move node C farther from A, or place an obstruction between them). Watch the mesh switch to routing through B. This is self-healing in action.
You can monitor the switchover in real time:
# Watch the routing table update live
watch -n 1 batctl originators
The TQ (Transmission Quality) column shows BATMAN-adv’s quality metric for each path. When the direct link to C degrades, you will see the TQ for the direct path decrease and the TQ for the path through B increase. When the path through B becomes better, BATMAN-adv switches to it automatically.
Here is the uncomfortable truth about mesh networks that every honest guide must tell you: every hop costs you throughput. On a typical Wi-Fi mesh using a single radio, throughput is approximately halved with each hop, because the radio at each intermediate node must receive a packet and then retransmit it — and it cannot do both at the same time on the same channel.
The math is straightforward. If your Wi-Fi link achieves 100 Mbps between directly connected nodes, then:
This is a fundamental property of single-radio mesh networks, and no protocol can fully overcome it. The mitigation strategies are:
Dual-radio nodes. Use one radio for mesh backhaul (inter-node traffic on 5 GHz) and a separate radio for client access (on 2.4 GHz). Since the two radios operate on different frequencies, they can transmit simultaneously, significantly reducing the per-hop throughput penalty.
Channel diversity. In networks with many nodes, assign different channels to different links so that nearby nodes are not competing for the same airtime. This requires careful planning and is more effective with directional antennas.
Wired backbone. Where possible, connect mesh nodes with Ethernet cables. Wired links do not suffer from the half-duplex limitation of wireless and provide full-speed forwarding. BATMAN-adv seamlessly integrates wired and wireless links, automatically preferring wired paths when they offer better performance.
Each hop adds latency — typically 1–5 ms per wireless hop in uncongested conditions, potentially much more under load. For basic web browsing and messaging, this is imperceptible. For real-time applications like voice and video calls, latency becomes noticeable beyond 3–4 hops.
The key metric is not raw latency but jitter — the variation in latency over time. Mesh networks tend to have higher jitter than conventional networks because route changes cause temporary latency spikes, and wireless medium contention introduces variable queuing delays. Quality of Service (QoS) configuration and traffic shaping can help, but some jitter is inherent to wireless mesh architecture.
import subprocess
import re
import statistics
def measure_mesh_latency(target, count=50):
"""Measure latency and jitter to a mesh node."""
result = subprocess.run(
["ping", "-c", str(count), "-i", "0.2", target],
capture_output=True, text=True
)
times = [
float(m.group(1))
for line in result.stdout.splitlines()
if (m := re.search(r"time=([\d.]+)", line))
]
if not times:
return None
return {
"min_ms": min(times),
"max_ms": max(times),
"avg_ms": statistics.mean(times),
"jitter_ms": statistics.stdev(times),
"loss_pct": (1 - len(times) / count) * 100,
}
In a mesh network with multiple nodes, channel planning is critical for performance. If all nodes use the same channel, they share the same airtime and each node’s transmissions interfere with nearby nodes’ transmissions — even nodes that are not directly communicating with each other.
For 2.4 GHz, the only non-overlapping channels are 1, 6, and 11 (in North America and most of the world). With only three non-overlapping channels, a dense 2.4 GHz mesh quickly runs into interference. This is one reason why mesh backhaul should use 5 GHz whenever possible.
For 5 GHz, the situation is much better. There are up to 25 non-overlapping 20 MHz channels (depending on regulatory domain and whether DFS channels are available). With 40 MHz channel widths, you have roughly 12 non-overlapping channels. With 80 MHz widths, about 6. The wider the channel, the higher the throughput per link but the fewer channels available for spatial diversity.
A practical channel planning strategy for a small mesh:
The ideal mesh has nodes that are close enough to maintain strong links but far enough apart to provide meaningful coverage extension. If nodes are too close together, you waste resources without extending coverage. If they are too far apart, link quality suffers and the mesh becomes fragile.
Rules of thumb for node spacing:
Node placement is more art than science. Rooftops and elevated positions dramatically improve range. Avoiding obstructions between nodes (especially metal structures, dense foliage, and wet surfaces) is critical. A node mounted at 10 meters height on a mast will outperform a node at 2 meters height by a factor that often exceeds the difference between cheap and expensive radio hardware.
Moving a mesh network outdoors transforms it from an interesting experiment into genuine infrastructure — but outdoor deployment brings a host of challenges that indoor networks never face. Water is the enemy of electronics, and the combination of rain, humidity, condensation, and temperature cycling will destroy unprotected equipment in weeks.
Enclosures. At minimum, outdoor nodes need IP65-rated enclosures (dust-tight, protected against water jets). For permanent installations, IP67 (temporary submersion) or NEMA 4X (corrosion-resistant) enclosures provide better long-term protection. Many outdoor-rated network devices (like the Ubiquiti UniFi AC Mesh or MikroTik SXTsq) come in their own weatherproof housings.
Cable entry. Every cable that enters an enclosure is a potential water ingress point. Use weatherproof cable glands, drip loops (a U-shaped loop in the cable below the enclosure that prevents water from running down the cable into the enclosure), and seal all connections with self-amalgamating silicone tape or dielectric grease.
Ventilation vs. sealing. Electronics generate heat, and a sealed enclosure in direct sunlight can reach temperatures that damage components. Some enclosures include Gore-Tex vents that allow air exchange while blocking water. Alternatively, mount enclosures in shaded locations or use sun shields.
Lightning protection. Outdoor antennas are lightning rods. Install a grounded surge protector (also called an Ethernet lightning arrester) on every cable that enters a building. Ground the mast, the surge protector, and any metal enclosures to a proper earth ground. This will not protect against a direct strike, but it will handle the induced surges from nearby lightning that are far more common and destructive to electronics.
For truly off-grid mesh deployments — mountaintop relay nodes, rural installations without electricity, disaster response — solar power is the standard solution. A mesh node can run on surprisingly little power, making solar a practical and cost-effective option.
Power budget calculation. A typical OpenWrt router consumes 5–15 watts. With a safety margin for cloudy days, plan for:
A complete solar-powered mesh node can be built for $150–250 in addition to the networking equipment. For relay nodes in critical locations, the investment pays for itself by enabling connectivity that would otherwise require running power cables — often a far more expensive proposition.
def solar_node_sizing(
device_watts=12,
hours_per_day=24,
sun_hours=4,
cloudy_days=3,
battery_voltage=12,
efficiency=0.85
):
"""Calculate solar panel and battery for a mesh node."""
daily_wh = device_watts * hours_per_day
panel_watts = daily_wh / (sun_hours * efficiency)
battery_ah = (daily_wh * cloudy_days) / (
battery_voltage * 0.5 # 50% depth of discharge
)
return {
"daily_consumption_wh": daily_wh,
"panel_watts": round(panel_watts),
"battery_ah": round(battery_ah),
"estimated_cost_usd": round(
panel_watts * 1.2 + battery_ah * 3.5 + 35
),
}
Antenna choice and placement have more impact on mesh network performance than any other single factor — more than radio hardware, more than routing protocol, more than firmware version.
Omnidirectional antennas radiate in all directions (horizontally) and are the default for mesh nodes that need to communicate with multiple neighbors in various directions. Most mesh routers include built-in omnidirectional antennas. External omnidirectional antennas mounted on masts provide better range than built-in antennas by getting the antenna above obstructions.
Directional antennas focus energy in a specific direction, providing much greater range at the cost of a narrower coverage area. A sector antenna (typically 60–120° beam width) is useful for covering a specific area — a valley, a street, a campus. A dish or panel antenna (5–30° beam width) is used for long-distance point-to-point links between mesh nodes.
For a typical community mesh, the pattern is:
Height is king. Every meter of antenna height you gain is worth more than any antenna upgrade. Radio signals follow approximately line-of-sight paths (with some diffraction around obstacles), and an antenna at 10 meters height can see over fences, hedges, parked trucks, and single-story buildings that would completely block a signal at 2 meters. Before buying a more powerful antenna, try mounting the one you have higher.
What range can you realistically expect from a mesh node? The answer depends on so many variables — antenna height, antenna gain, transmit power, channel width, radio technology, terrain, foliage, weather, interference — that any specific number must be taken with a healthy grain of salt. But for planning purposes:
| Scenario | Typical Range |
|---|---|
| Indoor, through walls (2.4 GHz, omnidirectional) | 10–30 m |
| Indoor, through walls (5 GHz, omnidirectional) | 5–15 m |
| Outdoor, urban (2.4 GHz, omnidirectional, rooftop) | 100–300 m |
| Outdoor, urban (5 GHz, omnidirectional, rooftop) | 50–200 m |
| Outdoor, suburban (5 GHz, directional, rooftop) | 500 m–2 km |
| Outdoor, rural LOS (5 GHz, high-gain directional) | 2–10 km |
| Outdoor, rural LOS (purpose-built PtP link) | 10–30+ km |
LOS = Line of Sight. Range drops dramatically without it. Even partial obstructions — a single tree, a building corner — can reduce range by 50% or more.
For mesh planning, use the lower end of these ranges as your planning assumption. A mesh that works at the edge of its range in good weather will fail in rain, fog, or when trees grow leaves in spring. Build in margin.
A mesh network without monitoring is a network that will eventually fail without anyone noticing until users complain. In a community mesh with dozens or hundreds of nodes spread across a neighborhood, knowing which nodes are up, which links are degraded, and where congestion is occurring is not optional — it is essential for maintaining a reliable network.
Meshviewer is a web-based tool developed by the Freifunk community for visualizing mesh network topology. It displays an interactive map showing all mesh nodes, the links between them, link quality metrics, and node status. Nodes are plotted on a geographic map (if GPS coordinates are configured) or displayed as a force-directed graph.
Meshviewer gets its data from nodes running the respondd daemon, which provides node information (name, hardware, firmware version, uptime, client count) and neighbor information (link quality, throughput) in a structured format. A central server collects this data and serves it to the Meshviewer web application.
Setting up Meshviewer requires three components:
For smaller networks, the data collector and web server can run on a Raspberry Pi connected to the mesh.
NetJSON is a data interchange format based on JSON designed to describe network topologies, device configurations, and monitoring data. It provides a standardized way for mesh networking tools to share data, replacing the ad-hoc data formats that each project historically invented.
NetJSON defines several document types:
The netjsonconfig library (for OpenWrt) and the OpenWISP network management platform both use NetJSON, making it possible to build monitoring and management systems that work across different mesh protocols and firmware.
For smaller mesh networks, or as a supplement to full-featured monitoring tools, a simple Python script can provide effective health monitoring. The following script pings all nodes in a mesh, checks response times, and alerts on failures:
import subprocess
import json
import time
from datetime import datetime
MESH_NODES = {
"gateway": "10.10.0.1",
"relay-north": "10.10.0.2",
"relay-south": "10.10.0.3",
"community-center": "10.10.0.4",
}
def check_node(name, ip, timeout=2):
"""Ping a mesh node, return status dict."""
result = subprocess.run(
["ping", "-c", "3", "-W", str(timeout), ip],
capture_output=True, text=True,
)
alive = result.returncode == 0
latency = None
if alive:
for line in result.stdout.splitlines():
if "avg" in line:
latency = float(line.split("/")[4])
return {"node": name, "ip": ip,
"alive": alive, "latency_ms": latency}
def mesh_health_report():
"""Generate a health report for all mesh nodes."""
report = {
"timestamp": datetime.now().isoformat(),
"nodes": [],
}
for name, ip in MESH_NODES.items():
status = check_node(name, ip)
report["nodes"].append(status)
symbol = "✓" if status["alive"] else "✗"
lat = (f'{status["latency_ms"]:.1f}ms'
if status["latency_ms"] else "N/A")
print(f" {symbol} {name:20s} {ip:15s} {lat}")
down = [n for n in report["nodes"] if not n["alive"]]
if down:
names = ", ".join(n["node"] for n in down)
print(f"\n ⚠ ALERT: {len(down)} node(s) down: "
f"{names}")
return report
Run this script periodically with cron or a systemd timer, and write the results to a log file. For more sophisticated monitoring, extend the script to check link quality (via batctl or SNMP), track trends over time, and send alerts via email or a messaging bot when nodes go down.
For larger deployments, SNMP (Simple Network Management Protocol) provides a standardized way to collect metrics from network devices. OpenWrt includes an SNMP agent (snmpd) that can expose interface statistics, CPU load, memory usage, and other system metrics.
Combined with a monitoring platform like Prometheus (with the SNMP exporter), Zabbix, or LibreNMS, SNMP enables comprehensive monitoring dashboards, historical trend analysis, and automated alerting. This is overkill for a three-node test mesh but essential for a 50-node community deployment.
The hidden node problem is one of the most pernicious issues in wireless mesh networks. It occurs when two nodes that cannot hear each other both try to communicate with a common neighbor simultaneously. Because neither node can detect the other’s transmission, standard collision avoidance (CSMA/CA) fails, and both transmissions collide at the common neighbor.
Imagine three nodes in a line: A — B — C, where A and C are out of range of each other. Both A and C want to send to B. A listens for transmissions, hears nothing (because C is too far away to hear), and begins transmitting. Simultaneously, C listens, hears nothing (because A is too far away), and also begins transmitting. Both signals arrive at B at the same time and are garbled.
The 802.11 protocol includes RTS/CTS (Request to Send / Clear to Send) as a mitigation: before transmitting, a node sends a short RTS frame. The receiver responds with a CTS frame, which is heard by all neighbors and tells them to stay quiet. However, RTS/CTS adds overhead and does not completely solve the problem when hidden nodes exist at multiple hops.
In practice, the hidden node problem manifests as unexplained packet loss and throughput degradation in mesh networks where nodes have varying ranges. Mitigation strategies include careful node placement to minimize hidden node scenarios, using directional antennas to reduce the range of interference, and configuring RTS/CTS thresholds in the Wi-Fi driver.
Mesh networks do not scale linearly. As the number of nodes grows, routing overhead grows, broadcast traffic grows, and the probability of interference and collision increases. The practical limits depend on the protocol and deployment:
For larger networks, the solution is hierarchical design: divide the network into smaller mesh segments (or “clouds”) connected by Layer 3 routing. This is exactly what LibreMesh does, and it is the pattern used by large community networks like Guifi.net.
Mesh networks present unique security challenges:
Traffic forwarding. Every node in a mesh forwards traffic for other nodes. A compromised or malicious node can inspect, modify, or drop forwarded traffic. End-to-end encryption (TLS, WireGuard, SSH) protects the content of communications, but a malicious node can still perform traffic analysis (observing who communicates with whom) and selective dropping (degrading service for targeted nodes).
Routing manipulation. A malicious node can inject false routing information, advertising itself as the best path to all destinations (a black hole attack) or selectively dropping packets after attracting traffic (a gray hole attack). Most mesh protocols have limited defenses against these attacks. Babel supports cryptographic authentication of routing messages (HMAC), which prevents external attackers from injecting routes but does not protect against compromised nodes that possess the authentication key.
Wireless eavesdropping. Mesh backhaul traffic is transmitted over the air and can be received by anyone within radio range. Encrypting the mesh backhaul (using SAE/WPA3 for the mesh Wi-Fi interface) protects against passive eavesdropping but does not protect against nodes within the mesh that must decrypt traffic to forward it.
The fundamental security model for mesh networks is: trust the mesh for connectivity, but not for confidentiality. Encrypt all sensitive traffic end-to-end, use VPNs for internet access through the mesh, and treat the mesh like a public network — because, architecturally, that is what it is.
Mesh networking has genuine limitations, and intellectual honesty requires acknowledging when other topologies are superior:
When you need maximum throughput. A wired point-to-point connection will always outperform a multi-hop wireless mesh. If your primary need is moving large amounts of data between two fixed locations, a direct Ethernet run, a fiber link, or a dedicated wireless bridge will serve you far better than a mesh.
When you have very few nodes. A mesh with two nodes is just a point-to-point link with extra protocol overhead. The mesh concept only becomes useful with three or more nodes, and the self-healing property only becomes meaningful with four or more (since you need at least two paths between any pair of nodes).
When all traffic goes to one destination. If every node in your network primarily communicates with one central server (e.g., an internet gateway), a hub-and-spoke topology is more efficient. The mesh’s strength — multiple paths between arbitrary pairs of nodes — is wasted if all traffic flows to and from a single point. In this case, a wireless bridge or a point-to-multipoint (PtMP) setup will provide better performance.
When strict latency requirements exist. Real-time applications that require consistently low latency — industrial control systems, live audio mixing, certain financial applications — are poorly served by mesh networks. The variable latency, jitter, and occasional route reconvergence of mesh networks are incompatible with hard real-time requirements.
When budget is extremely tight and coverage is more important than resilience. A single high-power access point on a hilltop can cover the same area as 10 mesh nodes at one-tenth the cost. If resilience (the ability to survive node failures) is not a priority, simpler topologies are cheaper.
The right question is never “should I build a mesh?” but “what problem am I solving, and is mesh the best tool for that problem?” Mesh networking is superb for resilience, community ownership, incremental deployment, and decentralized control. It is mediocre to poor for raw throughput, strict latency, and cost efficiency when resilience is not required.
This chapter has covered the essential theory and practice of mesh networking:
Mesh networking is not a panacea. It will not give you gigabit speeds across a city. It will not replace a well-designed wired backbone. It will not magically secure your communications. But for its intended purpose — building resilient, community-owned, decentralized networks that grow organically and heal themselves when things break — it remains the most powerful topology in the alternative networking arsenal.
In the next chapter, we step beyond infrastructure entirely and explore ad-hoc and peer-to-peer networks — architectures that form spontaneously between devices, require no pre-existing infrastructure at all, and represent the most radically decentralized approach to networking.
| ← Previous: Local Area Networks | Table of Contents | Next: Ad-Hoc and Peer-to-Peer Networks → |