802.11s mesh on OpenWrt: wpad preparation, configuration, and peer checks

802.11s is a Layer 2 mesh: nodes can see one another as if they were connected to one switch, while DHCP, routing, or Batman/OLSR sits above it. I check the driver and wpad first; a mesh interface alone does not mean every radio supports mesh point mode.¹

Prerequisites and limits

The source records reliable operation with OpenWrt 19.07 and later when the hardware/driver supports it and wpad-mesh-openssl (or an equivalent) is installed. It also records an ARP relay issue in 19.07.4 that made Mesh Points reliable only within range of a Mesh Portal. I therefore verify the release and topology before production use.

All nodes need the same channel, mesh ID, and password. If another routing protocol such as OLSR will run above the mesh, set option mesh_fwding '0'; clients reach the network by bridging the ap and mesh interfaces according to the local design.

Remove and install wpad

Depending on whether the image has wpad-mini or wpad-basic, remove the installed package and install the mesh variant:

# opkg remove wpad-mini
# opkg remove wpad-basic

# opkg install wpad-mesh-openssl

Configure wireless

The source interface uses radio0, network mesh, mesh mode, a mesh ID, and a PSK. your-secret-password is a placeholder; I replace it with a private value at deployment time and never commit a real secret:¹

config wifi-iface 'mesh'
        option network 'mesh'
        option device 'radio0'
        option mode 'mesh'
        option mesh_id 'your-mesh-name' # anything, this connects the nodes into one mesh (plus the password if there's any)
        option encryption 'psk2/aes' # or 'none'
        option key 'your-secret-password'

Inspect mesh parameters with:

# iw dev <devname> get mesh_param

After editing /etc/config/wireless, reinitialize Wi-Fi and watch the log and station dump:

# wifi
# logread -l 20 -f
# iw dev wlan0 station dump

Check hardware support

iw list must show mesh point under Supported interface modes. The source gives two valid interface-combination examples; both matter because different radios permit AP + mesh point with different channel/BI limits:

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

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

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 }
...

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

If mesh point is absent, stop and choose a supported driver/radio rather than forcing the configuration.

Use the command line

The source CLI branch creates mesh0 on phy0, confirms it, brings it up, and assigns example address 10.0.0.1:¹

iw phy phy0 interface add mesh0 type mp mesh_id mymesh

ifconfig -a | grep mesh0

     mesh0      Link encap:Ethernet  HWaddr 00:18:39:14:48:B5

ifconfig mesh0 up

ifconfig mesh0 10.0.0.1

For a real deployment, replace the address with the Layer 3 design; assigning the same address to multiple nodes creates a conflict.

Verify peers and mesh paths

Inspect stations and mesh paths with:

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

The example includes signal, TX bitrate, counters, mesh plink: ESTAB, and llid/plid. I use these fields to confirm a peer link, then measure throughput and latency at the actual locations; ESTAB alone does not guarantee a fast backhaul.

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

Block one peer

When a MAC must be isolated, the source notes that iw-full may be needed, then uses:

iw dev $MESH_IFACE station set $MAC_TO_BLOCK plink_action block

mesh plink:        BLOCKED

Verify with the station dump above. To reopen the peer:

iw dev $MESH_IFACE station set $MAC_TO_UNBLOCK plink_action open

The source notes that plink_action is not persisted across every reconnect. This is runtime state, not a durable ACL.

Final checks and recovery

I test every node with wired and wireless clients, inspect the bridge, DHCP, channel, encryption, logs, and the path to the Mesh Portal. If the configuration removes management access, restore /etc/config/wireless from console or failsafe; do not copy radio/port mappings from another model.

Sources