Wi-Fi Mesh and EasyMesh Explained: Backhaul, Steering and Security

A Wi-Fi mesh is a set of access points that act as one network, carry traffic between themselves over a backhaul link and steer clients to the best node. Wi-Fi EasyMesh is the Wi-Fi Alliance standard that lets a controller and agents from different makers share one mesh. Securing it means WPA3, a protected backhaul and updates on every node.

This post goes one level deeper than our Wi-Fi generations explainer, which covers the radios, and our home router build explainer, which covers the box. Here we stay on the system of boxes: what separates a mesh from a repeater, what the EasyMesh controller and agent roles do, how backhaul choice sets your real throughput, how 802.11k, 802.11v and 802.11r turn steering into a negotiation rather than a shove, how new nodes are onboarded with Wi-Fi Easy Connect or WPS, what IEEE 802.11s defines, and how to lock the whole thing down. The step by step section builds a small mesh with open source firmware and checks roaming and backhaul with standard Linux tools.

Key takeaways

• A repeater retransmits on the same radio, so every hop costs airtime. A mesh adds a backhaul, channel planning and client steering. Wired access points remain the fastest and most predictable option when you can run cable.
• Wi-Fi EasyMesh defines two logical roles: a Multi-AP Controller decides and Multi-AP Agents run the radios. Control messages ride on IEEE 1905.1, an abstraction layer over Wi-Fi, Ethernet, powerline and coax. Unlike proprietary mesh, certified nodes from different makers can join one network.
• Backhaul choice dominates throughput. A single radio shared between clients and backhaul roughly halves usable capacity per wireless hop; a dedicated backhaul radio or an Ethernet cable avoids that.
• Steering uses three IEEE amendments. 802.11k lets the network tell a client about neighbours and ask for radio measurements. 802.11v lets an access point suggest a move with a BSS Transition Management request. 802.11r (Fast BSS Transition) shortens the key handshake on each roam.
• Clients can ignore 802.11v suggestions. Older steering approaches that disconnect a client to force a move are disruptive and should be a last resort.
• Wi-Fi Easy Connect, built on the Device Provisioning Protocol (DPP), onboards devices by scanning a QR code or tapping NFC and uses public key cryptography. The WPS PIN method has a long history of brute force weaknesses; disable it.
• IEEE 802.11s, ratified in 2011, defines a standard mesh basic service set with its own peering, security and path selection. Linux supports it, and open source firmware uses it for wireless backhaul.
• Secure a mesh like a network of small servers: WPA3 on fronthaul and backhaul, separate SSIDs or VLANs for guests and IoT, no management interfaces on the WAN, and firmware updates on every node, not just the main router.

What a mesh Wi-Fi system is, and how it differs from a repeater, an extender and wired access points

The words get used loosely in product marketing, so it helps to define them by what the hardware actually does with each packet.

Repeaters and extenders

A repeater, also sold as a range extender, associates to your main router as a client and rebroadcasts a network of its own. The classic single radio repeater receives a frame from the router and transmits it to the client on the same channel. Wi-Fi is half duplex on a channel: only one transmitter can use the airtime at a time. So every frame crosses the same channel twice, and the airtime for one client transfer is roughly doubled. The repeater has no view of the rest of the network. It does not plan channels, does not tell clients when a better access point is nearby, and usually runs its own management page and its own firmware update cycle.

Dual band extenders receive on one band and transmit on the other, which avoids the self contention, but they remain independent devices with their own settings and updates.

Mesh systems

A mesh system is a set of access points managed as one network. The defining features are:

1. One logical network. The same SSID and security settings are pushed to every node from a central place, either a controller node, a cloud service or both.
2. A backhaul plane. Nodes carry client traffic between each other and towards the gateway over a backhaul link. That link can be a dedicated radio, a radio shared with clients, or Ethernet.
3. Coordination. The system chooses channels for each node, measures link quality, and steers clients between nodes and bands.
4. One update model. Firmware and configuration changes roll out to all nodes from one place.

Most consumer "mesh" products actually build a tree: each satellite picks one upstream and traffic flows up and down it. IEEE 802.11s, covered later, defines a true multi path mesh; EasyMesh lets the controller decide which backhaul links exist.

Wired access points

Wired access points connect each access point to a switch over Ethernet, often powered by Power over Ethernet. The backhaul is the cable, so wireless airtime is spent only on clients. In enterprise networks a controller or cloud service manages the access points and runs the same 802.11k, 802.11v and 802.11r roaming features covered below. Several mesh products also support "wired backhaul", which turns them into wired access points while keeping the mesh management.

The rule of thumb that falls out of this: cable where you can, wireless backhaul where you cannot, and a repeater only as a stopgap.

What Wi-Fi EasyMesh is, and how it differs from proprietary mesh

Wi-Fi EasyMesh is a Wi-Fi Alliance certification program and specification for networks that use multiple access points. The Wi-Fi Alliance describes it as bringing "a standards-based approach to Wi-Fi networks that utilize multiple APs" and lists these capabilities for home and small office networks: more capacity when operating in Wi-Fi 6 and Wi-Fi 6E, flexible placement of multiple access points, onboarding and configuration using QR codes through Wi-Fi Easy Connect, prioritising low latency applications and guiding devices to the best connection, and scalability "by enabling the addition of Wi-Fi EasyMesh APs from multiple vendors".

The technical specification behind the certification is called the Multi-AP specification. The open source prplMesh project describes itself as "an open-source, carrier-grade and certifiable implementation of the WiFi Alliance's Multi-AP specification" covering both the agent and the controller.

The controller and agent roles

EasyMesh splits a mesh into logical functions, not boxes:

• Multi-AP Controller. The brain. It discovers the topology, holds the network configuration (SSIDs, credentials, security mode, which networks are fronthaul and which are backhaul), pushes that configuration to agents, collects measurements, decides on channel plans and asks agents to steer clients. There is one active controller per EasyMesh network. It usually runs on the gateway, but it is a software role and can run elsewhere.
• Multi-AP Agent. The hands. An agent runs on every node with radios, including the gateway itself. It operates the fronthaul access points that clients join and the backhaul access points that other nodes join, reports link metrics and client capabilities to the controller, and carries out steering and channel decisions.
• Fronthaul BSS. The network clients see, such as your home SSID.
• Backhaul BSS and backhaul STA. A backhaul BSS is an access point interface meant only for other mesh nodes. A new node connects to it with a backhaul station (STA) interface, which is just a Wi-Fi client inside the node.

IEEE 1905.1, the control plane underneath

EasyMesh does not invent its own transport. Controller and agents exchange control messages over IEEE 1905.1. The standard's overview says it "defines an abstraction layer for multiple home network technologies", naming IEEE 1901 powerline, IEEE 802.11 Wi-Fi, IEEE 802.3 Ethernet and MoCA coaxial networking, and it is extensible to other links. 1905.1 messages are called CMDUs (control message data units) and carry TLVs. EasyMesh defines its own message types and TLVs on top of that layer for topology discovery, access point autoconfiguration, channel preference and selection, link metric queries, client capability queries and steering requests. Because 1905.1 sits above the link, the same control plane works whether a node is joined over a Wi-Fi backhaul or a cable.

What EasyMesh looks like in hostapd

hostapd, the open source access point daemon used in most Linux based routers, carries Multi-AP support, and its sample configuration file is a compact map of the EasyMesh concepts:

• multi_ap sets the role of each access point interface: 1 for a backhaul BSS, 2 for a fronthaul BSS, 3 for both, and 0 (the default) to disable Multi-AP.
• multi_ap_backhaul_ssid and multi_ap_backhaul_wpa_passphrase define the backhaul credentials. According to the file, these "are passed in WPS M8 instead of the normal (fronthaul) credentials if the Enrollee has the Multi-AP subelement set." In other words, a new node that identifies itself as a Multi-AP agent during WPS receives the backhaul network, not the home network.
• multi_ap_profile declares support for "Multi-AP profile 1" or "profile 2" as defined in the EasyMesh specification, with profile 2 as the default.
• multi_ap_vlanid sets a VLAN ID that is "used to update Default IEEE 802.1Q Setting". This is the hook for traffic separation, which keeps guest or other networks on their own VLAN across the backhaul.
• multi_ap_client_disallow lets an access point refuse backhaul stations of a given profile.

That is the radio side. The controller and agent logic, the 1905.1 messaging and the steering decisions live in a separate daemon such as prplMesh, which drives hostapd underneath.

How EasyMesh differs from proprietary mesh

Most mesh products in shops today use the maker's own control protocol, cloud service and phone app. That has upsides: the maker tunes steering for its own hardware, and one app manages everything. It also has costs. Nodes from one maker generally cannot join another maker's mesh. If the maker stops issuing updates for one model, the whole system is stuck on that firmware or must be replaced. The cloud account becomes part of your security boundary.

EasyMesh changes the interoperability question. In an EasyMesh network a broadband provider's gateway can run the controller and a retail extender from another maker can join as an agent, provided both are certified. That is why broadband providers have been the main drivers: they ship the gateway and want to add extenders without locking themselves to one supplier. The prplMesh README lists prplWrt and RDK-B, two open source gateway software stacks used by broadband providers, as its initial targets.

What EasyMesh does not standardise is the intelligence. The prplMesh README notes the reference implementation "will leave ample room for differentiation, for example for proprietary IP algorithms making intelligent decisions for the whole Multi-AP network." Two certified controllers can make very different steering decisions. Interoperable messages are not the same thing as identical behaviour.

How backhaul works, and how it affects throughput

Backhaul is the link that carries traffic from a satellite node back towards the gateway. Its capacity, and whether it competes with clients for airtime, sets the ceiling for every device on that node.

Shared band wireless backhaul

The cheapest design uses the same radio, and often the same channel, for both client traffic and backhaul. A dual band node that serves clients on 2.4 GHz and 5 GHz and also uses 5 GHz to reach the gateway is in this category. Every frame from a 5 GHz client goes over the air twice on the same channel: client to node, then node to gateway. The two transmissions cannot overlap.

Worked example. Suppose the 5 GHz link between a satellite and the gateway sustains 600 Mbit/s of real TCP throughput in a clear test, and a client next to the satellite could also manage 600 Mbit/s to it. On a shared channel, each byte uses airtime on both hops, so the best case for that client end to end is about 600 / 2 = 300 Mbit/s. Add a second wireless hop on the same channel (client, node B, node A, gateway) and the ceiling falls to about 600 / 3 = 200 Mbit/s, before counting retries and contention from other clients. These are rule of thumb figures, but the shape is real: each same channel hop divides capacity.

Dedicated band wireless backhaul

Tri band and quad band mesh nodes add a radio, usually a second 5 GHz radio or a 6 GHz radio, reserved for backhaul. Clients use the other radios. Now the backhaul hop and the client hop run on different channels in parallel.

Worked example. A node has a client radio that delivers 600 Mbit/s and a dedicated backhaul radio that delivers 900 Mbit/s to the gateway. The client's ceiling is now the smaller of the two, 600 Mbit/s, not half of it. If four clients on that node each pull 200 Mbit/s, the client radio is saturated at 600 to 800 Mbit/s of offered load while the backhaul still has headroom. The bottleneck has moved to the client side, which is where you want it.

The 6 GHz band, opened for unlicensed use in many countries and used by Wi-Fi 6E and Wi-Fi 7, is attractive for backhaul because it has wide channels and less legacy traffic, but it also attenuates more through walls. A 6 GHz backhaul between nodes two rooms apart can be excellent; the same link through a concrete floor may fall back to 5 GHz. Wi-Fi 7 Multi-Link Operation can bond links on several bands into one logical link, which mesh products use for backhaul resilience; see our Wi-Fi 7 MLO security explainer for how multi link devices, their addresses and WPA3 work.

Wired (Ethernet) backhaul

When a node has an Ethernet port and a cable to the gateway or a switch, the backhaul becomes the cable. A gigabit link offers about 940 Mbit/s of TCP goodput in each direction at the same time, with no airtime cost, no interference and very low jitter. Both EasyMesh (through 1905.1, which treats Ethernet as just another link) and most proprietary systems support wired backhaul. Two things to check: that the node really switched to the cable (the status page or the controller's topology view should say so), and that you have not created a loop by also leaving a wireless backhaul active on a design that does not run a loop prevention protocol.

Backhaul options compared

How band steering and client steering work

Steering is the mesh trying to get each client onto the right node and the right band. The hard part is that the client, not the network, decides when to roam. A phone in your pocket chooses an access point using its own logic and its own view of signal strength. The network can only advise, or refuse.

Band steering

Band steering nudges dual band clients from 2.4 GHz to 5 GHz or 6 GHz, which usually have more capacity. Older techniques were informal: the access point delays or withholds probe responses on 2.4 GHz to a client it has seen on 5 GHz, hoping the client picks 5 GHz. This works on some clients and confuses others. Standards based steering uses the same 802.11v mechanism as node steering, described below.

802.11k: telling clients what is nearby

IEEE 802.11k, Radio Resource Measurement, lets an access point and a client exchange measurements. The two features that matter for mesh are:

• Neighbor reports. A client asks its access point for a list of nearby access points in the same network, with channel and capability information. Instead of scanning every channel to find candidates, it can check a short list. That shortens the scan before a roam.
• Beacon reports. The access point asks a client to measure the beacons it can hear and report the signal strength of each. This gives the controller the client's view of the network, which is the view that actually matters for steering decisions.

In hostapd, the open source access point daemon used by most Linux based routers, these are switched on with rrm_neighbor_report=1 and rrm_beacon_report=1.

802.11v: suggesting a move

IEEE 802.11v, Wireless Network Management, includes BSS Transition Management (BTM). An access point sends a BTM request to a client listing one or more preferred target access points. The client replies with a BTM response that accepts or rejects. Flags in the request can say "disassociation imminent", meaning the access point intends to drop the client soon, which makes compliance more urgent. In hostapd, bss_transition=1 advertises support, and the hostapd_cli bss_tm_req command can send a request by hand for testing.

A BTM request is advice. A client in the middle of a call may reasonably prefer a slightly weaker signal to a roam, and say no.

802.11r: making the roam itself fast

IEEE 802.11r, Fast BSS Transition (FT), shortens the authentication and key exchange when a client moves between access points in the same mobility domain. Without it, a WPA2 or WPA3 Personal roam means a full new association and four way handshake; on networks with 802.1X authentication it can mean a full EAP exchange to a RADIUS server, which can take hundreds of milliseconds. With FT the key hierarchy is split: a top level key (PMK-R0) is derived once, and per access point keys (PMK-R1) are derived and shared among the access points in the mobility domain, so the client and the new access point can build session keys in the reassociation exchange itself.

FT can run "over the air", where the client talks directly to the target access point, or "over the DS" (distribution system), where the client sends FT messages through its current access point. In hostapd, ieee80211r=1 turns it on, mobility_domain must match on all nodes, and the key holder settings (nas_identifier, r0kh, r1kh, or ft_psk_generate_local=1 for PSK networks) tell the nodes how to get keys to each other.

The trade-offs of steering

Two practical warnings. First, some older or embedded clients cannot join a network that advertises FT, because they mis-handle the new information elements. If you have such devices, put them on a separate SSID without 802.11r. Second, roaming handshakes are security protocols, and they have had bugs. The KRACK research by Mathy Vanhoef of KU Leuven, published in 2017, showed that key reinstallation affected the WPA2 four way handshake and also the group key, PeerKey, TDLS and Fast BSS Transition handshakes. The researchers explain that attacking the FT handshake let them decrypt and forge packets sent towards the client, and that the attacks did not recover the network password. Patches to clients and access points fixed it, and hostapd still documents configuration workarounds for related station side bugs. Our KRACK explainer covers the mechanism. The lesson for a mesh: every node that terminates FT handshakes needs the fix, which is one more reason the update model matters.

How new mesh nodes are onboarded, and the risks of each method

Adding a node to a mesh means giving it the backhaul credentials, so it can join, and the network configuration, so it can serve clients. How that secret moves is the onboarding problem.

Wi-Fi Easy Connect and the Device Provisioning Protocol

The Wi-Fi Alliance describes Wi-Fi Easy Connect as "standardized mechanisms to simplify the provisioning and configuration of Wi-Fi devices", using a QR code, an NFC tag or device information downloaded from the cloud. The underlying protocol is the Device Provisioning Protocol (DPP).

DPP has two roles. A configurator (often a phone app or the mesh controller) provisions an enrollee (the new node or device). Each enrollee has a bootstrapping public key, printed as a QR code on the label or exchanged over NFC or Bluetooth. Scanning the code gives the configurator the enrollee's public key out of band. The two then run an authentication exchange based on that key, and the configurator sends a signed configuration object (a "connector") that the device uses to join. In EasyMesh, the Wi-Fi Alliance highlights QR code onboarding through Easy Connect as the way to add new agents.

The security properties come from the public key: an attacker who did not see the QR code cannot impersonate the enrollee, and nothing like a short PIN can be guessed over the air. The risks are physical and procedural: a label that is photographed or swapped before installation, a configurator app with weak protection, and devices that also fall back to weaker methods if DPP fails.

hostapd and wpa_supplicant implement DPP; the README-DPP file in the hostap source tree shows the configurator, bootstrapping and authentication commands.

WPS push button and PIN

Wi-Fi Protected Setup (WPS) predates DPP. In push button configuration (PBC), you press a button on the router and then on the new device, and the router hands over the network credentials. hostapd's WPS documentation notes that after the button press "the client has two minutes to complete WPS negotiation". In PIN mode, the device or router has an eight digit PIN.

hostapd's own README is blunt about both: the use of "the PIN and especially PBC mechanisms for authenticating the initial key setup is not very secure", so WPS may not suit environments that cannot allow outsiders a chance to join during setup.

The PIN method has the worse record. In late December 2011, researcher Stefan Viehböck published a brute force weakness in the external registrar PIN exchange: the protocol's error responses reveal whether each half of the PIN is right, so an attacker in range can search the halves separately rather than the whole PIN. The CERT Coordination Center tracked it as VU#723755, NVD lists it as CVE-2011-5053 (published 6 January 2012), and US-CERT alert TA12-006A said most access points that support WPS were affected and that an attacker within radio range could recover the WPA password. The fix was firmware that locks out repeated failures, and the standing advice is to disable the PIN method.

Push button mode does not have the PIN weakness, but anyone in range during the window can join, and on some devices WPS stays enabled after setup. This matters for mesh because WPS is also a node onboarding path: as shown above, hostapd's Multi-AP support hands backhaul credentials to a new agent inside the WPS exchange. A WPS session that a stranger completes gives that stranger the backhaul, not just the guest network.

Phone apps and cloud onboarding

Proprietary mesh products usually onboard nodes through the maker's phone app, over Bluetooth or a temporary setup network, and the maker's cloud. The security model is the maker's, documented or not, and the cloud account that owns the mesh becomes a high value credential that needs a unique password and multi factor authentication.

Onboarding methods compared

What IEEE 802.11s defines, and where it is used in open source firmware

IEEE 802.11s is the amendment that added mesh networking to the 802.11 standard. It defines a mesh basic service set (MBSS) in which mesh stations form peer links with each other and forward frames across multiple hops at layer 2. Its main parts are:

• Mesh peering management. Stations discover each other by a shared mesh ID and profile in beacons, then open peer links. With security, they use Simultaneous Authentication of Equals (SAE), the same password based exchange that later became the basis of WPA3 Personal, and an Authenticated Mesh Peering Exchange (AMPE) to set up keys.
• Path selection. The mandatory default is the Hybrid Wireless Mesh Protocol (HWMP), which combines on demand route discovery with optional proactive tree building towards a root. Its default metric is the airtime link metric, which estimates how much airtime it costs to send a frame over each link.
• Frame forwarding. 802.11s frames carry a mesh control field and can use extra address fields so a frame can travel through several mesh stations.
• Interworking. A mesh gate connects the mesh to other networks, such as a wired LAN.

The open80211s project, which wrote the Linux implementation, explains the motivation: the original 802.11 standard provided a WDS frame format for multi hop networking but did not define the procedures, so "many proprietary 802.11 multi-hop solutions appeared". 802.11s fills that gap with a new mesh BSS and, in the project's words, covers "interworking, MAC, security, and path selection". The project dates ratification to September 2011, and the IEEE 802.11 timeline shows the amendment superseded in 2012 when it was folded into IEEE 802.11-2012.

On Linux, HWMP behaviour is tunable through mesh parameters. The open80211s HOWTO shows, for example, setting the mesh parameter mesh_hwmp_rootmode=2 together with mesh_gate_announcements=1 (with iw <interface> set mesh_param) to make a gate node announce itself so all nodes proactively build paths to it, and it warns that gates add management and data traffic overhead, so keep their number low.

In practice, 802.11s is a backhaul technology. Clients such as phones and laptops do not join an 802.11s mesh; they join a normal access point on a mesh node, and the nodes use 802.11s among themselves. Linux implements 802.11s in its mac80211 stack, often called open80211s, and the iw tool can create mesh point interfaces. OpenWrt, the open source router firmware, supports 802.11s through wpad (its packaged build of hostapd and wpa_supplicant) for encrypted meshes, and some community setups run a separate layer 2 routing protocol, batman-adv, over 802.11s links. Community mesh networks and hobbyist builds use this stack; most commercial mesh products use their own protocols or EasyMesh.

802.11s versus EasyMesh

They are not competitors so much as different layers. 802.11s is a link layer mesh: nodes find each other and route frames automatically, with no central controller. EasyMesh is a management system: a central controller configures nodes and decides on backhaul links and steering, and the backhaul itself is ordinary Wi-Fi client to access point links (or Ethernet). EasyMesh does not require 802.11s.

Timeline: the standards behind mesh and roaming

Dates for IEEE documents come from the 802.11 working group's official timeline page, which records when each amendment was approved and when a later revision superseded it.

How to secure a mesh

A mesh is several small Linux computers with radios. Treat each node as part of your attack surface.

Use WPA3 on fronthaul and backhaul

WPA3 Personal replaces the WPA2 pre-shared key handshake with SAE, which resists offline dictionary attacks against a captured handshake. Use WPA3 Personal or WPA3 transition mode on client networks, and WPA3 (or a long random WPA2 key if a node cannot do WPA3) on the backhaul network. Turn on Protected Management Frames (802.11w), which WPA3 requires; it stops forged deauthentication and disassociation frames from kicking clients off. Our WPA2 versus WPA3 guide covers the handshake changes and transition mode trade-offs, and how to secure a wireless network covers the wider control set.

Protect the backhaul SSID with care. On EasyMesh and many proprietary systems it is a hidden network with its own credentials. Anyone who learns those credentials can join the backhaul as if they were a mesh node.

Separate guest and IoT networks, and keep them separate across the backhaul

A guest SSID that is isolated on the main router but bridged straight onto the LAN at a satellite node is not isolated. Check that guest and IoT networks are carried as separate VLANs or tunnels across the backhaul, and test isolation from a client on each node, not just the gateway. EasyMesh added a traffic separation feature for this purpose in later releases; in an open source build you configure it yourself with VLANs and firewall zones.

Update firmware on every node

The most common mesh security failure is uneven patching. The gateway updates; the satellite in the garage has run the same firmware for four years. Prefer systems that update all nodes together, check each node's version after every update, and retire nodes that no longer receive updates. Firmware on these devices bundles a Linux kernel, a Wi-Fi driver stack, hostapd or a derivative, a web server, and dozens of other open source components; a vulnerability in any of them affects every node that runs it. Our home router build explainer walks through how that firmware is assembled and updated, and the home router security checklist turns it into a list you can work through.

Close the management plane

• Do not expose any node's web interface, SSH or remote management on the WAN.
• Change default administrator credentials on every node; on open source builds, use SSH keys.
• If the system uses a cloud account, protect it with multi factor authentication; that account can usually change every setting.
• Disable WPS PIN everywhere and WPS push button when you are not using it.
• Disable UPnP unless something needs it, and review port forwards.
• Put node management addresses on a management VLAN or at least not on the guest network.

NIST SP 800-153, though written in 2012, still frames this well: secure the whole lifecycle of WLAN components, keep configurations standardised, and monitor for rogue and misconfigured devices.

Step by step: build a small mesh with open source firmware and check it

This walkthrough uses OpenWrt on two or three supported routers, with an 802.11s encrypted backhaul and 802.11r, 802.11k and 802.11v on the client network. It assumes a recent OpenWrt release with the full wpad package (not the basic one), because SAE and mesh need it. The hostapd option names are taken from hostapd's own sample configuration. OpenWrt translates its UCI wireless options into hostapd settings, and its option names and package manager have changed between releases, so check them against the OpenWrt wireless documentation for the release you run. After the OpenWrt steps there is a short plain Linux variant that uses iw and hostapd directly.

Warning. Flashing router firmware can brick a device and wipes its settings. Confirm the exact hardware model and revision on the OpenWrt table of hardware before downloading an image, back up the stock firmware if the device allows it, and keep a wired connection to the router during the flash.

Step 1: install the right packages

On each node, over SSH:

# Replace the basic wpad with the full build (needed for SAE, 802.11s and 802.11r)
opkg update
opkg list-installed | grep wpad
opkg remove wpad-basic-mbedtls   # use the name the previous command printed
opkg install wpad-mbedtls
opkg install iw-full

Newer OpenWrt releases replace opkg with the apk package manager. On those, the equivalent is apk update, apk del for the basic package and apk add for the full one. Package names can also differ by TLS library, so list what is installed before removing anything.

Step 2: plan addresses and channels

• Node A is the gateway: it runs DHCP, DNS and the firewall.
• Nodes B and C are satellites: set a static LAN address in the same subnet, disable their DHCP server, and point their gateway and DNS at node A.
• Pick one 5 GHz channel for the mesh backhaul and set it identically on every node. 802.11s peers must share a channel.

Step 3: configure the 802.11s backhaul

In /etc/config/wireless on every node, add a mesh interface on the 5 GHz radio:

config wifi-iface 'mesh0'
	option device 'radio1'
	option mode 'mesh'
	option mesh_id 'home-backhaul'
	option encryption 'sae'
	option key 'a-long-random-passphrase-for-the-backhaul'
	option network 'lan'
	option mesh_fwding '1'
	option mesh_rssi_threshold '0'

Apply with wifi reload. With network 'lan', the mesh interface joins the LAN bridge, so client traffic on node B or C crosses the mesh to node A at layer 2.

Step 4: configure the client network with fast roaming

On every node, the client SSID must have the same name, the same security settings and the same mobility domain:

config wifi-iface 'home'
	option device 'radio1'
	option mode 'ap'
	option ssid 'Home'
	option encryption 'sae-mixed'
	option key 'your-client-network-passphrase'
	option network 'lan'
	option ieee80211w '1'
	option ieee80211r '1'
	option mobility_domain 'a1b2'
	option ft_over_ds '0'
	option ft_psk_generate_local '1'
	option ieee80211k '1'
	option bss_transition '1'

sae-mixed is WPA3 transition mode, so WPA2 only clients can still join; use sae alone if all your clients support WPA3. ieee80211k turns on the 802.11k radio measurement features (neighbor and beacon reports) and bss_transition turns on 802.11v BSS Transition Management. ft_over_ds '0' keeps Fast Transition over the air only; hostapd's default is FT over the DS enabled, and over the air is the simpler path to debug. ft_psk_generate_local matters most: hostapd's documentation says it "avoids use of PMK-R1 push/pull from other APs with FT-PSK networks" because each access point already has the PSK, so you do not need to configure key holder lists between nodes. Repeat the block for the 2.4 GHz radio if you serve clients there.

For reference, the same client network expressed directly in hostapd.conf on a plain Linux access point looks like this. Every option name below appears in hostapd's sample configuration:

interface=wlan0
bridge=br0
ssid=Home
wpa=2
wpa_key_mgmt=SAE FT-SAE
sae_password=your-client-network-passphrase
rsn_pairwise=CCMP
ieee80211w=2
# 802.11r Fast BSS Transition
mobility_domain=a1b2
ft_over_ds=0
ft_psk_generate_local=1
# 802.11k radio measurement
rrm_neighbor_report=1
rrm_beacon_report=1
# 802.11v BSS Transition Management
bss_transition=1

ieee80211w=2 makes Protected Management Frames required, which WPA3 Personal needs. To keep WPA2 clients, use wpa_key_mgmt=WPA-PSK FT-PSK SAE FT-SAE with ieee80211w=1 and a wpa_passphrase, which is transition mode.

Step 5: check the mesh peers and paths

# Mesh peer links: look for "mesh plink: ESTAB" and a healthy signal
iw dev mesh0 station dump

# Forwarding paths through the mesh
iw dev mesh0 mpath dump

# Mesh parameters in effect
iw dev mesh0 get mesh_param

station dump shows signal strength, transmit and receive bit rates and the expected throughput per peer. mpath dump lists each destination, the next hop and the path metric.

Step 6: measure backhaul throughput

Install iperf3 on two nodes, or on node A and a wired laptop behind node B:

# On node A
iperf3 -s

# On node B (or a laptop plugged into node B)
iperf3 -c 192.168.1.1 -t 30
iperf3 -c 192.168.1.1 -t 30 -R   # reverse direction

Run it once with no clients on node B and once while a client streams on the same 5 GHz radio. The drop between the two runs is your shared band backhaul cost from the worked example above.

Step 7: check client roaming

On a Linux laptop, watch the roam happen:

# Which access point am I on, at what signal and rate?
iw dev wlan0 link

# Live events: associations, roams and disconnections
iw event -t

# With wpa_supplicant, check the key management in use (look for FT-SAE or FT-PSK)
wpa_cli -i wlan0 status

Walk from node A towards node B. iw dev wlan0 link should show the BSSID change, and wpa_cli status should show an FT key management suite if fast transition is active. On the access point side:

# Clients on this node
hostapd_cli -i phy1-ap0 all_sta

# Suggest that a client move to node B (testing only)
hostapd_cli -i phy1-ap0 bss_tm_req <client-mac> pref=1 neighbor=<node-b-bssid>,0,0,36,7

The interface name varies by release; iw dev lists them. If the client accepts, its next iw dev wlan0 link shows node B.

Plain Linux variant: an open 802.11s mesh in a lab

If you have two Linux machines with Wi-Fi adapters whose drivers support mesh point mode (iw list shows "mesh point" under supported interface modes), you can see 802.11s peering without any router firmware. The Linux wireless documentation gives the pattern:

# On each machine: add a mesh point interface with the same mesh ID
sudo iw phy phy0 interface add mesh0 type mp mesh_id labmesh
sudo ip link set mesh0 up
sudo ip addr add 10.99.0.1/24 dev mesh0   # use 10.99.0.2 on the second machine

# Peers with the same mesh ID form peer links automatically
iw dev mesh0 station dump
ping -c 3 10.99.0.2
iw dev mesh0 mpath dump

The documentation notes that mesh point interfaces start on channel 1 by default and automatically try to create peer links with other mesh points that share the mesh ID. This mesh is unencrypted, so use it only in a lab, away from real traffic. For an encrypted mesh, run wpa_supplicant in mesh mode with SAE, which is what OpenWrt's encryption 'sae' on a mesh interface does for you.

Step 8: check isolation and management exposure

• From a guest client on each node, try to reach the LAN address of node A and another LAN device. Both should fail.
• From outside your network, confirm no node answers on its web or SSH port.
• On each node, run cat /etc/openwrt_release and confirm all nodes run the same, supported release.

Repeater, proprietary mesh, EasyMesh and wired access points compared

Here is how the four approaches compare on the questions that usually decide a purchase or a design.

Common mistakes

1. Placing satellites where the signal is already poor. A mesh node must sit where it has a good link to its upstream, typically halfway between the gateway and the dead zone, not inside the dead zone.
2. Assuming the mesh uses the cable. Plugging in Ethernet does not always switch the backhaul. Check the topology view.
3. Leaving WPS on. Especially the PIN method. Turn it off after setup and check again after firmware updates.
4. Guest networks that leak at satellites. Test isolation from each node.
5. Updating only the gateway. Every node runs firmware with its own vulnerabilities.
6. Forcing 802.11r on every SSID. Some older clients fail on FT networks. Keep a non FT SSID for them.
7. Overly aggressive steering. Low RSSI kick thresholds disconnect clients in the middle of calls. Start with 802.11k/v only, then tune.
8. Mixing channels on an 802.11s backhaul. Peers must share the channel; automatic channel selection on one node breaks the mesh.
9. Reusing the client passphrase for the backhaul. A guest who learns the client key should not be able to join the backhaul.
10. Ignoring end of support. A mesh kit with one model out of support needs a plan, not a hope.

FAQ

Is mesh Wi-Fi better than a range extender?

For most homes, yes. A mesh coordinates channels, steers clients and, with dedicated or wired backhaul, avoids the halving of throughput that a single radio extender causes. An extender can still be a cheap fix for one dead spot.

What is the difference between EasyMesh and a normal mesh system?

EasyMesh is a Wi-Fi Alliance certified standard, so a controller and agents from different makers can work together. Proprietary mesh systems use their own control protocol and usually only accept nodes from the same maker.

Can I mix mesh nodes from different brands?

Only if they all support the same mesh standard, in practice Wi-Fi EasyMesh, and are certified. Proprietary systems from different makers do not join each other's mesh.

Does wired backhaul make a mesh faster?

Usually much faster. An Ethernet backhaul frees the radios for clients and removes airtime contention, interference and most of the latency of a wireless hop.

What do 802.11k, 802.11v and 802.11r do?

802.11k shares neighbour lists and measurements, 802.11v lets an access point suggest a better access point, and 802.11r makes the key handshake during a roam fast. Together they make roaming quicker and better informed.

Should I turn on 802.11r?

Turn it on if your clients support it, particularly for voice and video calls. If some devices fail to connect, give them a separate SSID without 802.11r.

Is WPS safe to use for adding mesh nodes?

Disable the WPS PIN method. Push button mode is safer but lets anyone nearby join during the window. Wi-Fi Easy Connect with a QR code is the better option where supported.

What is IEEE 802.11s used for?

It defines a standard multi hop mesh at the Wi-Fi link layer. Open source firmware such as OpenWrt uses it to build encrypted wireless backhaul between nodes; clients connect to normal access points on top.

Does a mesh network need WPA3?

It should use WPA3 wherever all devices support it, on both client and backhaul networks, with Protected Management Frames on. Use WPA3 transition mode only while older devices remain.

How do I keep a mesh secure over time?

Update every node, check versions after updates, keep management off the WAN, protect any cloud account with multi factor authentication, separate guest and IoT networks, and replace nodes that no longer get updates.

Where Safeguard fits

Safeguard does not configure, scan or manage routers, mesh nodes, firmware images or radio settings, and nothing in this post depends on it. The connection is indirect. Mesh firmware is built from open source components such as the Linux kernel, hostapd and wpa_supplicant, and open source projects such as prplMesh; and teams that build products around networks (a controller app, provisioning scripts, a self hosted management container, a firmware build pipeline) carry the same open source dependency risk as any other software team. That is where Safeguard's dependency scanning, policies and remediation apply: to the code and images you build and ship, not to the boxes on your shelf.

So supply chain hygiene still matters here, one step removed: a mesh node is only as patched as the open source wireless stack inside it, and the tools you write to manage a network pull dependencies like any other project. The section below describes how Safeguard closes the gap for the software you build; its fork and patch flow is early access.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The Safeguard CLI demo is a real terminal session: you ask it to fix a vulnerable dependency, it reads the finding and the advisory, asks before each command, edits the manifest, runs the install and the tests with your approval, and pushes nothing. The same flow applies to a mesh controller app or provisioning tool you maintain.

Click through it at your own pace, or open it full screen.

The local runner demo sets up a runner on your own machine, approves it with a device code, then scans from the terminal. If you build firmware or network tooling on a build host you control, this is how scans run there without sending your source anywhere else.

Click through it at your own pace, or open it full screen.

The Claude demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude may use. Network engineers who already ask an assistant about hostapd options can ask, in the same place, which of their projects carry a vulnerable component.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Wi-Fi Alliance: Wi-Fi EasyMesh
• Wi-Fi Alliance: Wi-Fi Easy Connect
• Wi-Fi Alliance: Wi-Fi EasyMesh Specification
• Wi-Fi Alliance: Wi-Fi Alliance introduces Wi-Fi CERTIFIED WPA3 security, 25 June 2018
• prplMesh README, GitLab
• prplMesh README, archived GitHub repository
• IEEE 1905.1, IEEE Standard for a Convergent Digital Home Network for Heterogeneous Technologies (IEEE Xplore)
• hostapd.conf, hostap source tree (Android mirror)
• README-DPP, hostap source tree (Android mirror)
• README-WPS, hostap source tree (Android mirror)
• NIST SP 800-153: Guidelines for Securing Wireless Local Area Networks
• Linux wireless documentation: iw
• IEEE 802.11 Working Group: official timelines of 802.11 standards
• open80211s HOWTO (Linux 802.11s implementation)
• KRACK Attacks: Breaking WPA2 by forcing nonce reuse (Mathy Vanhoef)
• CISA alert TA12-006A: Wi-Fi Protected Setup (WPS) Vulnerable to Brute-Force Attack
• NVD: CVE-2011-5053, WPS PIN external registrar brute force

Last reviewed: 23 October 2026. Wi-Fi Alliance programs and OpenWrt option names change between releases; check the pages above for the version you actually run.