An IEEE 802.11s mesh has many applications, from small home and offices to enterprise level applications. A small mesh network can be an excellent solution for placing remote Access Points (APs) throughout an area where running cables is impractical. In a mesh network:

• APs communicate with each other using their own wireless channel instead of cabling.
• When properly configured, APs automatically find each other and determine the best way to transmit information between stations.

The purpose of this topic is to provide the necessary information for setting up an IEEE 802.11s mesh and to provide the necessary concepts, setup information and troubleshooting methods so that a set of OpenWrt routers can be used in a mesh configuration.

IEEE 802.11 is an open standard that defines how wireless devices can interconnect to form a wireless LAN mesh network within the existing IEEE 802.11 wireless framework. The current version is IEEE 802.11-2020, and this version has also been published as ISO/IEC/IEEE 8802-11:2022. The version implemented in the Linux kernel, and therefore used in OpenWrt, is based on IEEE 802.11-2016. The first release of mesh networking in IEEE standards was IEEE 802.11s-2011, which was soon superseded by IEEE 802.11-2012. The “s” was the amendment letter to the previous version of IEEE 802.11, hence the name IEEE 802.11s. Key features include:

• Standardized, flexible, and scalable solution for wireless mesh networking
• Supports dynamic, self-healing, and multi-hop network typologies
• Requires only one station to be physically connected to the Internet (though larger networks often have more)
• Operates at OSI Level-2 using unique MAC addresses to communicate between stations

Historical information can be found on Wikipedia; 802.11s.

Some examples of applications of an IEEE 802.11s mesh are:

• Home and office networks
• Community networks
• Smart sites
• Event connectivity

These are some extensions to OpenWrt's implementation of IEEE 802.11s:

• Mesh11sd: a shell script daemon to assist in the setup and maintenance of a group of mesh stations
• OpenWISP: is an open-source network management system designed to manage and automate various aspects of IT network deployment, monitoring, and management. It is built on top of OpenWrt
• Layer 2 Support Packages:
  • B.A.T.M.A.N.-Advanced (batman-adv)
• Layer 3 Support Packages:
  • B.A.T.M.A.N. (Better Approach To Mobile Adhoc Networking)
  • BIRD (BIRD Internet Routing Daemon)
  • OLSR (Optimised Link State Routing)

For consistency, the terms and definitions used on this page are those used in the IEEE 802.11 standards. This will hopefully eliminate ambiguities and allow ease of additional research to other sources of information. To start, the first term is that IEEE 802.11s mesh points or nodes are called stations, also known as STAs. A self-contained set of mesh stations is known at as a Mesh Basic Service Set or by the abbreviation MBSS. Here are the main types of stations that often make up a small to medium-sized MBSS.

• Mesh Point (MP): Mesh Points form the backbone of the mesh network by relaying data and participating in path selection. A mesh point is a basic station in the mesh network that is capable of establishing wireless mesh links with other MPs. MPs can relay frames to other MPs and participate in the mesh path selection protocol, thereby helping to create and maintain the mesh network topology.
• Mesh Portal (MPP): A mesh portal is a specialized station that connects the mesh network to other types of networks, such as Ethernet or another 802.11 network. In OpenWrt, MPPs serve as gateways, allowing data to flow between the mesh network and external networks. This is crucial for providing Internet access or integrating the mesh network with other network infrastructures.
• Mesh Access Point (MAP): A mesh access point is similar to a Mesh Point (MP) but combines both mesh networking capabilities and traditional access point services. It can connect regular Wi-Fi clients (stations) to the mesh network, effectively acting as a bridge between client devices and the mesh infrastructure. MAPs are useful for extending network coverage and integrating client devices into the mesh.

^ ^

• This page provides basic information on the learning, installation and setup of an IEEE 802.11s mesh on OpenWrt without additional mesh utilities. The Mesh11sd package is not required to effectively setup a basic IEEE 802.11s mesh. This is not meant as a criticism of Mesh11sd; only to remedy incorrect information that is out there stating it is a requirement.
• The Mesh11sd package is a shell script daemon that's meant to be a quicker and easier way to set up and maintain an IEEE 802.11s mesh in OpenWrt. For full details of the Mesh11sd package and ways to rapidly install your mesh, see: mesh11sd and 802.11s Rapid Deployment. Do not install Mesh11sd if you are planning upon using B.A.T.M.A.N., B.A.T.M.A.N.-Advanced, or OLSR.
• If you are looking for a solution to enable your user devices to only seamlessly roam from one access point to another in your home, you need to enable 802.11r Fast Transition to your Access Point channels.
• Unless explicitly stated, commercially available mesh stations do not comply with IEEE 802.11s features. You cannot expect that an OpenWrt IEEE 802.11s mesh station will have all of the features of a commercial mesh station or vice-versa. You also should not expect to mix OpenWrt IEEE 802.11s stations with commercially available stations.

The Linux kernel began incorporating support for the IEEE 802.11s standard around 2008. OpenWrt began integrating the Linux kernel code for IEEE 802.11s shortly after the standard was officially released in 2011. Where hardware and driver support existed, OpenWrt versions 19.07 and later provided full support for 802.11s, including features for authentication and encryption.

The Standard for mesh networks used by OpenWrt is IEEE 802.11-2016. The current standards are: US: IEEE-802.11-2020, International: ISO IEC IEEE 08802-11-2022, and of course, the UK: BS ISO IEC IEEE 08802-11-2022.

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. 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-wolfssl
• wpad-wolfssl
• wpad-mesh-openssl
• wpad-openssl

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 (meaning nothing was trimmed to reduce its size) and have 802.11k/v/r/w and 802.11s support.

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 mesh stations as it uses reactive routing as there's no central entity that proactively maintains routes. To make your MBSS more responsive to larger number of nodes, a root station needs to be defined. Usually the root station is the one providing access to the outside internet. Defining a root station allows for proactive routing, where a central entity proactively maintains routes between stations and is done by defining the `mesh_hwmp_rootmode` option. The different modes above define the mechanisms used in reactive and proactive routing.

The `mesh_hwmp_rootmode` setting is not available in LUCI but can be set in the `/etc/config/wireless file` . The setting is an integer with possible values of 0 (default), 2, 3, or 4. The following is a brief definition of the `mesh_hwmp_rootmode` possible settings:

• Mode `0` (not Root): This is default mode OpenWrt and ensures that the mesh point does not engage in any root-specific activities. Mode `0` stations respond to root stations PREQs (Path Requests) with PREPs, (Path Responses). A Mode `0` station will store paths derived from PREQ it has received and PREPs from PREQs it has sent out
• Mode `2` (Root with PREQ announcements only): This mode informs other mesh points of its presence as a root station managing paths. It does this by sending out PREQs (Path Requests) but does not respond to PREQs with PREPs from other stations.
• Mode `3` (Root with PREQ announcements and responds to other PREQs with PREPs): This mode periodically sending PREQ messages, to determine mesh station paths. It will also respond to PREQs from other stations with PREPs.
• Mode `4` (Root Proactive RANN announcements in addition to PREQ announcements PREP responses): A RANN message includes information such as the root station's address, a sequence number (to prevent routing loops and ensure the freshness of the information), and other metrics that can help in routing decisions.

Either Mode 3 or Mode 4 would be acceptable.

        ...
        option mesh_hwmp_rootmode '4'
        ...

The next important change you should make to this same portal and root station is `mesh_gate_announcements` which is used to enable or disable the announcement of a mesh gateways. This setting is important for informing other mesh stations about the presence of gateways that can provide access to external networks, such as the Internet. Only mesh stations that provide connectivity to external networks should have `mesh_gate_announcements` set to '1' so that regular mesh stations discover and maintain routes to the gateways, ensuring that traffic destined for external networks is efficiently routed. The default is `0`. The Mesh Portal (MPP) needs `mesh_gate_announcements` set to `1`.

        ...
        option mesh_gate_announcements '1'
        ...

Your pertinent section of your file should no look something like this:

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'
        option mesh_hwmp_rootmode '3'
        option mesh_gate_announcements '1'

Other options that can manually be set in the /etc/config/wireless file for your mesh are below.

Note: As time permits, the definitions of these options will be added.

• mesh_fwding: controls whether the mesh station will forward packets not destined for it. Setting mesh_fwding to 0 disables this behaviour, meaning that the station will only handle its own traffic and will not forward packets from other stations. This should only be set to 0 for some specific reason and only if any of the other mesh access points don't need to hop through this router to get to the mesh portal. For example, a low bandwidth router set up as a NAS (Network Attached Storage) device can use this setting to insure other traffic doesn't burden this device.
• mesh_rssi_threshold: is used to define the minimum signal strength (RSSI, Received Signal Strength Indicator) that a mesh station requires to establish and maintain a link with another mesh station. If the signal strength of a potential link falls.
• ifname
• macaddr
• dtim_period
• wpa_group_rekey
• max_inactivity
• max_listen_interval
• disassoc_low_ack
• network
• mesh_hwmp_rootmode
• mesh_ttl: is the mesh Time-To-Live value controlling the number of hops a mesh packet can traverse in the network. TTL settings (this one and the next) are used to limit the number of hops a packet can take before being discarded, preventing packets from circulating indefinitely and potentially causing network congestion. With small personal mesh systems of less than 10 stations, this can be a small value, something no larger than 3 to 5 unless you have your mesh stations all in a single line requiring more hops.
• mesh_element_ttl: is the parameter that determines the mesh management frames Time-To-Live (TTL) hops. Management frames are used for mesh routing and control purposes within the mesh network. Again, for small personal mesh systems of less than 10 stations, this can be a small value, something no larger than 3 to 5 unless you have an unusual arrangement of your mesh stations. mesh_element_ttl applies to management frames used for network control and routing information dissemination, while mesh_ttl applies to data frames carrying actual user data.
• mesh_retry_timeout
• mesh_confirm_timeout
• mesh_holding_timeout
• mesh_sync_offset_max_neighor
• mesh_max_peer_links
• mesh_hwmp_active_path_timeout
• mesh_gate_announcements
• mesh_max_retries
• mesh_hwmp_max_preq_retries specifies the maximum number of times a mesh point (MP) will retry sending a Path Request (PREQ) message when trying to establish or update a route to another mesh point. For small to medium sized networks (up to 20 stations), 1 to 2 retries should to be sufficient.
• mesh_max_peer_links: determines the maximum number of peer links (connections between mesh stations) that a single mesh station can establish. This parameter's role is in managing the connectivity and performance of the mesh network, especially as the network size and complexity increases. For a small to medium sized network (up to 20 stations), a setting of 3 to 5 peer links per station should be sufficient. A moderate number of peer links ensures reliable connectivity without overloading more distant individual stations.
• mesh_path_refresh_time
• mesh_hwmp_active_path_timeout
• mesh_hwmp_confirmation_interval
• mesh_gate_announcements
• mesh_hwmp_rann_interval
• mesh_hwmp_root_interval
• mesh_hwmp_active_path_to_root_timeout

These are some commands that are useful for debugging and monitoring the status and performance of your mesh network. For <devname>, use the 'Interface Name' of your mesh channel. An example is phy1-mesh0

iw dev <devname> station dump
iw dev <devname> mpath dump

Example:

iw dev <devname> 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

This displays information about the all the active mesh paths to which the originating station is connected. Each line represents a route within the mesh network to reach a specific destination. IFACE is the Interface Name of your mesh channel. This is a brief explanation of the fields:

• Destination MAC Address: For each mesh path, it shows the MAC address of the destination station within the mesh network.
• Next Hop MAC Address: Displays the MAC address of the next hop station to reach the destination station. This is the station to which the device will forward packets to reach the final destination. If the destination and next hop MAC addresses are the same, the stations are communicating directly with no hops.
• IFACE: stands for Interface and is name of the network interface through which the mesh path is established on the device is being used for the given mesh path.
• SN: stands for Sequence Number and the output is the sequence number of the last packet received from the destination node over the mesh path. The sequence number is used in routing protocols to maintain the order of packets and to identify the most recent updates
• Metric: Provides the metric for each path, which is a numerical value representing the “cost” of the path. Lower metrics generally indicate better paths.
• QLEN: stands for Queue Length and indicates the number of packets currently queued for transmission to the specified destination over the mesh path.
• EXPTIME: stands for “Expiration Time which indicates the remaining time (in milliseconds) before the mesh path entry is considered expired and removed from the path table if it is not refreshed. If a mesh path is not actively used or updated, its expiration time decreases, and once it reaches zero, the path will be discarded.
• DTIM period: is a Delivery Traffic Indication Message (DTIM) is a specific type of traffic indication message used to manage power saving features to inform mesh stations of buffered broadcast and multicast messages waiting to be delivered. This ensures that all mesh stations are synchronised and know when to wake up to receive these messages. The ‘DTIM period’ is the interval time at which the DTIMs are sent in TUs, where a TU is defined as 1024 microseconds.
• DRET: stands for “Destination Retrieval Error Time.” This field indicates the time (in milliseconds) since the last destination retrieval error occurred for this mesh path.
• Flags: Shows various flags associated with each path, For the OpenWrt IEEE 802.11s implementation, these are defined as:
  • 0x01: The path is active.
  • 0x02: the discovery process is running for this mesh path
  • 0x04: the mesh path contains a valid destination sequence number
  • 0x08: the mesh path has been manually set and should not be modified
  • 0x10: the mesh path can has been resolved
  • 0x20: there is an unsent path request for this destination already queued up, waiting for the discovery process to start.
  • 0x40: the mesh path has been deleted and should no longer be used
  • 0x80: unassigned
• Hop Count: Indicates the number of hops to the destination station.
• Path Change: This field displays the number of changes in the path used to reach a destination in the mesh network since startup. This number is an indicator of the stability of the mesh network. A high number of path changes may indicate instability or fluctuating link quality, while a low PATH_CHANGE number indicates a stable network.

This command provides information about the stations that are currently connected to the the specified wireless interface <IFACE> of the station from which you ran the command. <IFACE> is the Interface Name of your mesh channel.

• Station: The first line of the groups of output is the MAC address of each connected station (station).
• inactive Time: The amount of time since the last activity (e.g., data transmission) was detected from the station.
• tx/rx bytes:, tx/rx packets:, tx retries:, tx failed, and rx drop misc: The number of bytes and packets received rx bytes, rx packets the number of bytes and packets transmitted tx bytes, tx packets, retries in packets tx retries, failed in packets tx failed, and received packets dropped rx drop misc from each station.
• last ack signal: and avg signal avg: The last and average received signal strength signal levels for each station expressed in dBm. This indicates the quality of the connection with the station.
• Toffset: the difference in timing in microseconds between the originating mesh point (MP) and the mesh stations within the mesh network. Does not appear to be functional in OpenWrt 23.05.
• tx bitrate: The bit rate in megabits per second at which data is being transmitted to the other stations
• tx duration: the total time, in microseconds, that the mesh station has spent transmitting data to the specific peer station. It effectively measures how much airtime has been consumed by transmissions from the originating mesh point to the peer station. This metric can help in assessing the load or usage of the wireless link between the two mesh points
• rx bitrate: The bit rate megabits per second at which data is being received from the station.
• rx duration: the total time, in microseconds, that the mesh station has spent receiving data from the specific peer station. It effectively measures how much airtime has been consumed by transmissions from the peer station point to the originating mesh. This metric can help in assessing the load or usage of the wireless link between the two mesh points
• last ack signal: the signal strength of the most recent acknowledgment (ACK) frame received from the connected station (or peer) in the mesh network
• avg ack signal: the average signal strength of (ACK) frames received from the connected station (or peer) in the mesh network
• airtime weight: is a relative parameter that shows how the available transmission time (airtime) is allocated among different stations in a mesh network. This value determines the relative priority of a station when competing for airtime. Stations with higher airtime weights are given more priority in accessing the medium, which can result in more bandwidth or reduced latency for those stations. The default value is 256; I don’t know how this can be set.
• mesh llid: stands for Mesh Local Link Identifier. The LLID is a unique identifier used in IEEE 802.11s mesh networks to distinguish between different links within a mesh path. It is used for the management of the mesh paths and communication between mesh stations.
• mesh plid: stands for Mesh Peer Link Identifier. The PLID is a unique identifier assigned to the peer link between two mesh stations (nodes) in an IEEE 802.11s mesh network. It is used to manage and identify the specific link between two mesh points.
• “Mesh Plink” stands for Mesh Peer Link and indicates the state of the peer link between two mesh stations (nodes) in the IEEE 802.11s mesh network. The status field can have several possible states, each representing a different phase or condition of the link between mesh points:
  • LISTEN: The mesh point is in the initial phase of trying to establish a peer link with another mesh point. It is listening for beacons or probes from other stations to initiate a connection.
  • OPN_SNT (Open Sent): The mesh point has sent an open frame to another station, signaling its intent to establish a peer link. The station is waiting for a response from the peer to proceed with the link establishment.
  • OPN_RCVD (Open Received): The mesh point has received an open frame from another station, indicating that the peer is attempting to establish a link. The station will typically respond to this request to continue the peering process.
  • CNF_RCVD (Confirm Received): The mesh point has received a confirmation frame from the peer, confirming that the link has been established on the other end. The mesh point will now finalize the link establishment on its side.
  • ESTAB (Established): The peer link is fully established and operational. This is the desired state, indicating that the connection between the two mesh points is active and functioning correctly. Data can now be exchanged between the stations over this link.
  • HOLDING: The mesh point is temporarily holding off further attempts to establish a peer link, usually due to a previous failure or an ongoing process that prevents immediate reconnection. This state is a temporary pause before attempting to establish the link again.
  • BLOCKED: The peer link is blocked, either due to a configuration issue, an administrative decision, or some form of error. The stations will not attempt to establish a peer link in this state, and no data will flow between them.
• mesh airtime link metric: is a value used to evaluate the quality of a link between two mesh stations in terms of how much airtime (radio time) is required to successfully transmit data over that link. It is calculated based on several factors, including the transmission rate, the error rate, and the overhead associated with managing the wireless link. The lower the score, the better. High values (above 500, for example) may be due to weak signal strengths between stations or interference affecting transmissions.
• mesh connected to gate: reflects whether the mesh station is to connect to a gateway, which provides access to external networks, such as the Internet. This is determined internally by the HWMP either by checking its local forwarding table for an active route or through through Root Announcement messages from other stations announcing themselves as a gate.
• mesh connected to auth server: This option involves connecting the mesh network to an authentication server, which is used to manage and enforce security policies within the network. The authentication server verifies the identity of devices attempting to join the mesh, ensuring that only authorized devices are allowed access
• mesh local PS mode: This setting indicates whether the mesh node is actively participating in power-saving operations The possible modes for mesh local PS mode” include:
  • ACTIVE: The peer is not in power-saving mode and is fully operational.
  • LIGHT SLEEP: The peer is in a light power-saving state.
  • DEEP SLEEP: The peer is in a deep power-saving state.
  • UNKNOWN: The power-saving status of the peer is not known or not applicable
• mesh peer PS mode: refers to the power-saving mode of a remote peer link in the mesh network. This setting indicates the power-saving status of a peer node that is part of the mesh network. Refer to mesh local PS mode for possible modes.
• mesh non-peer PS mode: This setting indicates the power-saving status of devices that are not directly peered with the mesh node but are within the network’s vicinity. Refer to mesh local PS mode for possible modes.
• authorized: whether the station is authorized to associate and fully participate in the MBSS to fully participate in the network
• authenticated: whether the peer has completed the authentication process which is is a security measure that verifies the identity of the peer before it can join the MBSS
• associated: whether the peer is currently associated and is able to communicate with other devices within that MBSS.
• preamble: the preamble mode used by the peer, which can be either “long” or “short.” The preamble helps synchronize the transmission and reception of data. For OpenWrt, this defaults to the legacy setting of long.
• WMM/WME: Wi-Fi MultiMedia and Wireless Multimedia Extensions is a feature that provides Quality of Service (QoS) capabilities in Wi-Fi networks. It prioritizes traffic to improve the performance of applications such as voice, video, and audio streaming. In the station dump, it indicates whether the station supports WMM/WME
• MFP: stands for Management Frame Protection and is a security feature that protects management frames in Wi-Fi networks from being tampered with to prevent certain types of attacks, such as deauthentication attacks. The output indicates whether the station supports this feature.
• TDLS peer: indicates whether the station has established or can establish a direct link with another device using TDLS (Tunneled Direct Link Setup)
• DTIM period: is a Delivery Traffic Indication Message (DTIM) is a specific type of traffic indication message used to manage power saving features to inform mesh stations of buffered broadcast and multicast messages waiting to be delivered. This ensures that all mesh stations are synchronised and know when to wake up to receive these messages. The ‘DTIM period’ is the interval time at which the DTIMs are sent in TUs, where a TU is defined as 1024 microseconds.
• beacon interval: refers to the time interval between beacon frames transmitted by a wireless access point or mesh node. This interval is measured in units of 1.024 milliseconds. The beacon interval can be set between 15 and 65535 units, with a default value of 100 units, which corresponds to approximately 102.4 milliseconds.
• connected time: the duration for which a device has been connected to the network in seconds
• associated at boottime: the time in seconds since the station being listed in the iw dev <dev_name> station dump output first became associated with the station from which the command is being run. It helps in understanding how soon after booting the station from which the command is run ;connected to the other stations in the MBSS.
• associated at: the time when the device was associated with the network, typically represented in milliseconds since the Unix Epoch (The Unix Epoch is defined as 00:00:00 Coordinated Universal Time (UTC) on January 1, 1970, excluding leap seconds)
• current time: the current time in milliseconds since the Unix Epoch, providing a reference point for calculating duration like connected time or for synchronizing events

• Old but useful historic information: from CWNP
• Old but useful introduction to the 802.11s standard: from kernel.org
• A basic but outdated introduction to setting up a IEEE 802.11s mesh with OpenWrt: on Youtube
• Tutorial for setting up, managing and monitoring an 802.11s mesh network with OpenWISP, a centralized controller for OpenWrt