802.11s Wireless Mesh Networking

802.11s is an open standard for connecting wireless devices without having to set up infrastructure. It operates on Layer 2 and makes sure that all nodes can see each other on a bridged Layer 2 network (as if they were all plugged into a switch). Any Layer 3 infrastructure will work on top of this.

Packages to enhance the basic layer 2 802.11 mesh have been developed, particularly where multiple Internet gateways and partial cabled backhaul are required. These enhanced packages are targeted more for large infrastructure scenarios eg. local community through to city scale, rather than a typical home mesh application.

See:
batman
mesh11sd
olsr

In contrast, a basic 802.11s mesh can serve as a simple “One Hop Wifi Extender” in a home environment without any enhanced packages.

A mesh network is a multi point to multi point layer 2 mac-routing backhaul used to interconnect mesh peers. Mesh peers are generally non-user devices, such as routers, access points, CPEs etc..

A normal user device, such as a phone, tablet, laptop etc., cannot connect to a mesh network. Instead, connection is achieved via a mesh gateway, a special type of mesh peer.

If you are looking for a solution to enable your user devices to seamlessly roam from one access point to another in your home, you need 802.11r (roaming), not 802.11s.

It is unfortunate that some manufacturers have used the word “Mesh” for marketing purposes to describe their non-standard, closed source, proprietary “roaming” functionality and this causes great confusion to many people when they enter the world of international standards and open source firmware for their network infrastructure.

1. The accepted standard for mesh networks is ieee802.11s.
2. The accepted standard for fast roaming of user devices is ieee802.11r.

These are two completely unrelated standards.

802.11s works reliably with all current OpenWrt versions,including over the air encryption, assuming that there is hardware/driver support. The package wpad-mesh-mbedtls (or equivalent) is required for this.

An 802.11s interface requires numerous operational parameters to be set AFTER the interface has come up and established itself as a part of the mesh. Some SoC combinations do not establish the mesh interface quickly enough, so many of these operational parameters may fail to be implemented.

However, for single hop Wifi extender use, additional parameters do not need to be set for this very basic but useful mode.

Historically, the inability to set required mesh parameters in the wireless configuration (due to the interface not yet being established) was interpreted by some as an “ARP relay bug” as the layer 2 (mac routing) network would never become active between all mesh nodes at the same time.

The mesh11sd package was developed to allow all available mesh parameters to be correctly and dynamically set.

An 802.11s mesh backhaul can be rapidly deployed by taking advantage of the OpenWrt Firmware Selector (or the Image Builder) and the Mesh11sd package.

See:

802.11s Rapid Deployment

Support for 802.11s (type mesh) depends on wireless driver. Most up to date open source drivers work. Note that some drivers may advertise they support mesh but have problems with it.

For example, as of Dec 2023, the ath10k-ct wireless driver used in NETGEAR R7800 and other devices with Qualcomm Atheros QCA988x chips doesn't support mesh very well, resulting in errors and random dropping of wireless interfaces (issue report). It is recommended that you use firmware selector to request a custom firmware build that removes the -ct module (ex: kmod-ath10k-ct) and the -ct firmware (ex: ath10k-firmware-qca9984-ct) and replaces them with the non-ct versions (ex: kmod-ath10k and ath10k-firmware-qca9984) to get reliable mesh support.

Use the following to determine if your hardware supports 802.11s mesh.

iw list | grep "Supported interface modes" -A 9

...
      Supported interface modes:
                 * IBSS
                 * managed
                 * AP
                 * AP/VLAN
                 * WDS
                 * monitor
                 * mesh point
                 * P2P-client
		 * P2P-GO
...

Example: ath9k in router

iw list
...
valid interface combinations:
		 * #{ managed, WDS } <= 2048, #{ AP, mesh point } <= 8, #{ P2P-client, P2P-GO } <= 1, #{ IBSS } <= 1,
		   total <= 2048, #channels <= 1, STA/AP BI must match
		 * #{ IBSS, AP, mesh point } <= 1,
		   total <= 1, #channels <= 1, STA/AP BI must match, radar detect widths: { 20 MHz (no HT), 20 MHz }
...

Example: ath9k_htc USB Stick

iw list
...
valid interface combinations:
		 * #{ managed, P2P-client } <= 2, #{ AP, mesh point, P2P-GO } <= 2,
		   total <= 2, #channels <= 1
...

If you want to run an encrypted mesh, you must install a version of wpad that supports mesh encryption.

At the time of writing, either the full or mesh-capable version of wpad is required.

Examples:

• wpad-mesh-mbedtls # The basic version + mesh support.
• wpad-mbedtls # The full large version.
• wpad-mesh-openssl
• wpad-openssl
• wpad-mesh-wolfssl
• wpad-wolfssl

Installing support for Mesh Encryption: It is necessary to remove the non-mesh version of wpad, depending which one is installed by default. You can find out which one you have in the Luci Web Interface with the System→Software Menu, Update Lists..., then type in the Filter: 'wpad'. Whichever one says Installed is the one you have. Remove it and then Install.. the -mesh variant.

Or with the following commands:

opkg list-installed wpad*

Now install the mesh-supporting version matching the one you had from the list above:

opkg update
opkg install ...

Notes:

1. From September 2019, wpad-openssl or wpad-wolfssl became capable of 802.11s encyption. wpad-mbedtls was added later.
2. The wpad-basic-* versions only have 802.11r and 802.11w support.
3. The wpad-mesh-* versions only have 802.11r/w and 802.11s support.
4. The wpad-* are the full version of wpad and have 802.11k/v/r/w and 802.11s support.
5. The full version of wpad means that nothing was trimmed to reduce its size.

Example of a single command to remove the basic wpad and replace it with mesh:

WARNING: You must reboot or restart the wpad service before the new wpad version will become active.

opkg update && opkg install wpad-mesh-mbedtls --download-only && opkg remove wpad-basic-mbedtls && opkg install wpad-mesh-mbedtls --cache . && rm *.ipk

Configuring Mesh Networking within the LuCI Web Interface:

WARNING: Do not configure mesh networking using LuCI if you are also running mesh11sd in auto_config mode
This is because LuCI creates a static config and mesh11sd dynamically manages the mesh config.

1. Go to Network→Wireless
2. Click 'Add' on either the 2.4 or 5gz Wifi bands
3. Interface Configuration→General Setup→Mode Select: '802.11s', and put in a 'Mesh ID' value to be shared among your nodes, for the name of your mesh.
4. Select LAN for the Network.
5. Interface Configuration→Wireless Security, choose 'WPA3-SAE' and put in a password to be shared among your mesh nodes.
6. Save
7. Now Save & Apply

WARNING: STP has no effect on a mesh network as layer 2 traffic is inserted into the mesh backhaul after STP processing in the bridge interface
Bridge loops WILL occur if you have any non-mesh segments in the backhaul (eg ethernet links), or have multiple mesh backhauls (eg 2.4GHz AND 5GHz).
To prevent mesh bridge loops and support non-mesh backhaul segments or multiple mesh backhauls you must either run mesh11sd or create your own nftables bridge ruleset to drop looping packets.

WARNING: Do not configure mesh networking by editing the /etc/config/wireless file if you are also running mesh11sd in auto_config mode.
This is because /etc/config/wireless is a static config and mesh11sd dynamically manages the mesh config.

The /etc/config/wireless file should have a mesh section added along these lines:

config wifi-iface 'mesh'
        option device 'radio0'
        option disabled '0'
        option mode 'mesh'
        option ifname 'mesh0'
        option network 'lan'
        option mesh_id 'my-mesh-id'
        option encryption 'sae' # or 'none' if you do not want encryption
        option key 'your-secret-password'

Note: option network 'lan' bridges the the 'mesh' interface to the 'lan'.

This configuration should be sufficient to bring up the mesh network so you can now reinitialize wifi and see if it worked:

wifi
iw dev mesh0 info

You should see an output similar to:

Interface mesh0
	ifindex 10
	wdev 0x3
	addr 12:34:56:78:9a:bc
	type mesh point
	wiphy 0
	channel 2 (2417 MHz), width: 20 MHz, center1: 2417 MHz
	txpower 28.00 dBm
	multicast TXQ:
		qsz-byt	qsz-pkt	flows	drops	marks	overlmt	hashcol	tx-bytes	tx-packets
		0	0	129166	0	0	0	0	9107016		129167

Every device you want to participate in the mesh must be configured in the same way ie same mesh_id, same channel, same key.

This wireless UCI configuration may be sufficient for a “mesh” of two or possibly three meshnodes that are fairly close together. But an organic, autonomously self managing mesh network of many meshnodes requires additional configuration.

There are many mesh parameters available, some of which are essential for a reliable mesh network.

The majority of these however, require the mesh interface to be up and established before setting.

If these parameters were to be set in the wireless UCI config file, they would fail, as of course the wireless UCI config is used to start/restart the wireless system and the mesh interface only becomes established after UCI has completed its tasks.

Parameters can be set manually using the IW utility, but any settings done this way will only persist as long as the mesh interface is up. Rebooting, restarting the network, or reinitializing the wireless interface (“wifi” command) will set parameters back to default.

For permanently setting parameters, the Mesh11sd package should be installed:

opkg update
opkg install mesh11sd

For full details of the Mesh11sd package see: mesh11sd

Use the iw command to display peer links or a table of reachable nodes in your mesh

iw dev $MESH_IFACE station dump
iw dev $MESH_IFACE mpath dump

Example:

iw dev $MESH_IFACE station dump
    Station 00:15:6d:84:14:10 (on mesh)
         inactive time:  1320 ms
         rx bytes:   352
         rx packets: 4
         tx bytes:   174
         tx packets: 2
         signal:     -61 dBm
         tx bitrate: 1.0 MBit/s
         mesh llid:  32577
         mesh plid:  15969
         mesh plink: ESTAB
    Station 00:15:6d:84:14:09 (on mesh)
         inactive time:  3370 ms
         rx bytes:   1064
         rx packets: 12
         tx bytes:   545
         tx packets: 7
         signal:     -53 dBm
         tx bitrate: 1.0 MBit/s
         mesh llid:  41036
         mesh plid:  24435
         mesh plink: ESTAB

• Mesh11sd Project: on the OpenWrt Wiki
• Old but useful historic information: from CWNP
• Old but useful introduction to the 802.11s standard: from kernel.org
• A very outdated and somewhat misleading video that nevertheless serves as a basic introduction to 802.11s mesh networking: on Youtube