Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
Next revisionBoth sides next revision
docs:guide-user:network:wifi:mesh:80211s [2024/06/19 18:47] – [The Wireless UCI Config File] bluewavenetdocs:guide-user:network:wifi:mesh:80211s [2024/09/03 12:40] – [IEEE 802.11s Wireless Mesh Networking] Add warning bluewavenet
Line 1: Line 1:
-====== 802.11s-Based Wireless Mesh Networking ======+====== IEEE 802.11s Wireless Mesh Networking ======
  
-[[wp>IEEE 802.11s|802.11s]] is an open standard for connecting wireless devices without having to set up infrastructure. It operates on [[wp>Data_link_layer|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 [[wp>Network_layer|Layer 3]] infrastructure will work on top of this. 
  
-Packages to enhance the basic layer 2 802.11 mesh with sophisticated layer 3 support have been developed, particularly where multiple Internet gateways and partial cabled backhaul are required (eg Batman, Bird, OLSR etc.). These enhanced packages are targeted more for large infrastructure scenarios eg. city scale, rather than a typical home mesh application. In contrast, a basic 802.11s mesh serves all scenarios from home mesh through to high resilience neighbourhood WISP applications.+<WRAP center round alert 60%> 
 +**WARNING! This document contains many errors and misconceptions.\\ 
 +Many paragraphs are produced using an online LLM and added without any verification**
  
-===== What is a Mesh? =====+</WRAP> 
 +  
 +===== Preface ===== 
 +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 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. 
 +===== Introduction ===== 
 +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.11s: An Open Standard for Wireless Mesh Networks ==== 
 +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; [[wp>IEEE 802.11s|802.11s]]. 
 +==== Applications and Extensions ==== 
 +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: 
 +  * [[docs:guide-user:network:wifi:mesh:mesh11sd|Mesh11sd:]] a shell script daemon to assist in the setup and maintenance of a group of mesh stations 
 +  * [[https://openwisp.org/|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: 
 +    * [[docs:guide-user:network:wifi:mesh:batman|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) 
 +==== Concepts & Terminology ==== 
 +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 **STA**s.  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. 
 +  -  
 +^ {{:media:ieee-80211s-terms-a-mesh-portal-mpp-connects-to-the-wired-internet-a-mesh-point-mp.png?direct&700|}} ^ 
 +| https://www.researchgate.net/publication/3200401_The_IEEE_80211s_Extended_Service_Set_Mesh_Networking_Standard | 
 +==== Caveats ===== 
 +  * 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: [[:docs:guide-user:network:wifi:mesh:mesh11sd]] and [[docs:guide-user:network:wifi:mesh:rapiddeployment|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 [[docs:guide-user:network:wifi:roaming|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. 
 +  
 +====== IEEE 802.11s Mesh on OpenWrt ======
  
-A mesh network is a multi point to multi point layer 2 mac-routing backhaul used to interconnect mesh peersMesh peers are generally non-user devicessuch as routers, access points, CPEs etc..+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 existedOpenWrt versions 19.07 and later provided full support for 802.11s, including features for authentication and encryption.
  
-A normal user device, such as a phone, tablet, laptop etc., cannot connect to a mesh networkInsteadconnection is achieved via a mesh gatewaya special type of mesh peer.+The Standard for mesh networks used by OpenWrt is IEEE 802.11-2016.  The current standards are: US: IEEE-802.11-2020International: ISO IEC IEEE 08802-11-2022and of course, the UK: BS ISO IEC IEEE 08802-11-2022.
  
-===== Are you sure you want a mesh? ===== 
-If you are looking for a solution to enable your user devices to only [[docs:guide-user:network:wifi:roaming|seamlessly roam from one access point to another in your home, you need 802.11r (roaming) support]], 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. 
-// 
  
-  - The accepted standard for mesh networks is ieee802.11s. +===== Verifying IEEE 802.11s Support on Router =====
-  - The accepted standard for fast roaming of user devices is ieee802.11r. +
- +
-These are two completely unrelated standards.   +
- +
-===== 802.11s Mesh ===== +
-802.11s works reliably with OpenWrt 19.07 and later, including authentication and encryption, assuming that there is hardware/driver support, the ''wpad-mesh-openssl'' (or equivalent) and the ''mesh11sd'' packages have been installed. +
-See also: [[docs:guide-user:network:wifi:mesh:mesh11sd|The Mesh11sd Project]] +
- +
-An 802.11s interface requires numerous operational parameters to be set **AFTER** the interface has come up and established itself as part of the mesh. +
- +
-The mesh11sd package monitors and dynamically sets and resets these required mesh parameters. +
- +
-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. +
- +
-===== 802.11s Rapid Deployment ===== +
- +
-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: +
- +
-[[docs:guide-user:network:wifi:mesh:rapiddeployment|802.11s Rapid Deployment]] +
- +
-===== Verifying Wireless Driver Support =====+
  
 :!: 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. :!: 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.
Line 83: Line 102:
 ===== Installation & Configuration ===== ===== Installation & Configuration =====
  
-If you want to run an encrypted mesh, you must install a version of ''wpad'' that supports mesh encryption. +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.
- +
-At the time of writing, either the full or mesh-capable version of ''wpad'' is required.+
  
 Examples: Examples:
-  * ''wpad-mesh-openssl'' # The basic version + mesh support. +  * ''wpad-mesh-mbedtls'' # The basic version + mesh support. 
-  * ''wpad-openssl'' # The full large version.+  * ''wpad-mbedtls'' # The full large version.
   * ''wpad-mesh-wolfssl''   * ''wpad-mesh-wolfssl''
   * ''wpad-wolfssl''   * ''wpad-wolfssl''
-  * ''wpad-mesh-mbedtls'' +  * ''wpad-mesh-openssl'' 
-  * ''wpad-mbedtls''+  * ''wpad-openssl''
  
 **Installing support for Mesh Encryption:** **Installing support for Mesh Encryption:**
Line 127: Line 144:
 **Configuring Mesh Networking within the LuCI Web Interface:** **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\\ +//**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.**//+This is because LuCI creates a static config and mesh11sd dynamically manages the mesh config.//
  
   - Go to ''Network->Wireless''   - Go to ''Network->Wireless''
Line 135: Line 152:
   - Select ''LAN'' for the ''Network''.   - Select ''LAN'' for the ''Network''.
   - ''Interface Configuration->Wireless Security'', choose 'WPA3-SAE' and put in a password to be shared among your mesh nodes.   - ''Interface Configuration->Wireless Security'', choose 'WPA3-SAE' and put in a password to be shared among your mesh nodes.
-  - ''Save'' 
-  - ''Network->Interfaces->Devices->br-lan->Configure->Advanced Device Options'', Enable STP. See [[https://forum.openwrt.org/t/wds-network-setting-stp-right/186173/14|Setting STP Right]]\\ 
   - ''Save''   - ''Save''
   - Now ''Save & Apply''   - 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\\+**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).\\ 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.**//+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.\\
  
 ==== The Wireless UCI Config File ==== ==== The Wireless UCI Config File ====
Line 189: Line 204:
 Every device you want to participate in the mesh must be configured in the same way ie same mesh_id, same channel, same key. 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. +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.
-But an organic, autonomously self managing mesh network of many meshnodes requires additional configuration.+
  
-==== Mesh11sd - Setting Parameters and Options ==== +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:
- +
-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. +
-Rebootingrestarting 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:+
  
 +  * **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.
 <code> <code>
-opkg update +        ... 
-opkg install mesh11sd+        option mesh_hwmp_rootmode '4' 
 +        ...
 </code> </code>
 +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`.
 +<code>
 +        ...
 +        option mesh_gate_announcements '1'
 +        ...
 +</code>
 +Your pertinent section of your file should no look something like this:
 +<code>
 +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'
 +</code>       
 +Other options that can manually be set in the /etc/config/wireless file for your mesh are below.
  
-For full details of the Mesh11sd package see+**Note:** As time permits, the definitions of these options will be added. 
-[[:docs:guide-user:network:wifi:mesh:mesh11sd]]+  *     **''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
  
 ===== Verify the Mesh Network is Working ===== ===== Verify the Mesh Network is Working =====
- +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%%''
-Use the ''iw'' command to display peer links or a table of reachable nodes in your mesh+
 <code> <code>
-iw dev $MESH_IFACE station dump +iw dev <devname> station dump 
-iw dev $MESH_IFACE mpath dump+iw dev <devname> mpath dump
 </code> </code>
  
 Example: Example:
-<code>iw dev $MESH_IFACE station dump+<code>iw dev <devname> station dump
     Station 00:15:6d:84:14:10 (on mesh)     Station 00:15:6d:84:14:10 (on mesh)
          inactive time:  1320 ms          inactive time:  1320 ms
Line 247: Line 305:
 </code> </code>
  
 +===== iw dev <IFACE> mpath dump =====
 +
 +
 +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.
 +
 +
 +==== iw dev <IFACE> station dump ====
 +
 +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
  
 ===== More resources & background ===== ===== More resources & background =====
-  * [[docs:guide-user:network:wifi:mesh:mesh11sd|Mesh11sd Project:]] on the OpenWrt Wiki 
   * [[http://www.cwnp.com/wp-content/uploads/pdf/802.11s_mesh_networking_v1.0.pdf|Old but useful historic information:]] from CWNP   * [[http://www.cwnp.com/wp-content/uploads/pdf/802.11s_mesh_networking_v1.0.pdf|Old but useful historic information:]] from CWNP
   * [[https://wireless.wiki.kernel.org/en/developers/Documentation/ieee80211/802.11s|Old but useful introduction to the 802.11s standard:]] from kernel.org   * [[https://wireless.wiki.kernel.org/en/developers/Documentation/ieee80211/802.11s|Old but useful introduction to the 802.11s standard:]] from kernel.org
-  * [[https://www.youtube.com/watch?v=vVoZppb_FR0 | A very outdated and somewhat misleading video that nevertheless serves as a basic introduction to 802.11s mesh networking: ]] on Youtube+  * [[https://www.youtube.com/watch?v=vVoZppb_FR0 | A basic but outdated introduction to setting up a IEEE 802.11s mesh with OpenWrt: ]] on Youtube 
 +  * [[https://openwisp.io/docs/dev/tutorials/mesh.html|Tutorial for setting up, managing and monitoring an 802.11s mesh network with OpenWISP]], a centralized controller for OpenWrt
  • Last modified: 2024/09/23 17:13
  • by taylorkline