802.11s Backhaul for Embedded Gateways: Prove Mesh Peering and Route Repair Separately
An established mesh peer proves a local neighbor relationship, not a working path to a remote service. Qualify Linux 802.11s with three synchronized views: peer-link state, the destination’s mesh path and validated application delivery. A route-repair test succeeds only when the intended alternate path carries the required service within the project’s declared limits.
This guide uses Linux 6.12 mac80211 HWMP behavior and wpa_supplicant 2.11 mesh configuration. It excludes consumer products marketed as mesh, ordinary AP roaming, Bluetooth Mesh and alternative path-selection implementations. Driver, firmware, security support and channel permissions must be verified for the actual hardware and deployment jurisdiction. No mesh radios or repair timings were tested here.
Establish the actual mesh implementation
Record the supported mesh-point interface mode, kernel configuration, driver and firmware, mesh identifier, security mode and forwarding configuration. A matching network name or visible neighbor does not establish compatible authenticated peering. Keep the product’s required authentication intact rather than using an open mesh as the final compatibility workaround.
Wpa_supplicant 2.11 distinguishes mesh mode with mode=5 and includes a secured SAE-plus-AMPE example. Its user_mpm setting identifies peering-manager ownership; when AMPE is enabled, the userspace peering manager is always used. Check compiled mesh and SAE support as well as configuration. A parser accepting the profile does not prove that the radio can operate it. wpa_supplicant 2.11, mesh configuration and build options
Document whether a node forwards mesh traffic, serves as a mesh gate, bridges another network or routes IP traffic. Those roles affect the experiment. Start by proving delivery to a mesh-resident endpoint; then add the gateway’s wired or routed service path. Otherwise a broken upstream service can be misclassified as failed mesh repair.
Keep peer and path records in different tables
| Evidence layer | Key | Useful observations |
|---|---|---|
| Peer relationship | Local interface plus neighboring mesh station | Peering state, authentication outcome, link counters |
| Mesh path | Local interface plus destination mesh address | Next hop, active/resolving flags, metric, expiry and queued frames |
| Application service | Operation identity and intended endpoint | Validated completion, timeout, duplicate and delivery-gap results |
Linux 6.12 names established peering NL80211_PLINK_ESTAB. Separately, mesh-path flags distinguish ACTIVE, RESOLVING, RESOLVED and manually FIXED entries. The path sequence number belongs to mesh path-selection state; it is not an application record number. Expiration is reported in milliseconds from the query, so preserve its observation time. Missing fields remain unavailable evidence. Linux 6.12 mesh peer states and path information
A station may have several established neighbors while a particular destination has no usable path. Conversely, an existing path entry can point through a neighbor whose failure has not yet been detected. Avoid treating a single command snapshot as an atomic view of the entire mesh. Timestamp repeated observations and align them with traffic and fault events.
Understand what repair can and cannot promise
In Linux 6.12, mesh_plink_broken() deactivates active non-fixed paths using the failed peer as next hop and sends path-error information. Fixed paths are explicitly excluded from that repair branch. A test using manually installed paths therefore cannot silently inherit the same expectation as dynamic HWMP paths. Linux 6.12 mesh_plink_broken()
For unresolved destinations, the HWMP path can queue frames and start discovery. Discovery uses configured retry limits and increasing timeouts; on exhaustion, pending traffic may be handled through known gates or flushed according to the path state. Queuing is bounded. These mechanisms do not guarantee lossless delivery or a fixed recovery time under every topology and load. Linux 6.12 mesh_nexthop_resolve() and mesh_path_timer()
Separate failure detection from path repair. Powering off a peer creates a physical condition, but the stack still needs evidence that the next hop is unusable. A source-code retry branch cannot establish the target’s detection delay, radio contention or application recovery time.
Run a controlled alternate-path experiment
- Build an observable topology. Use a dedicated four-node arrangement with two candidate paths from A to D: through B and through C. Ensure the intended links exist and document unintended direct links. Do not assume physical placement alone produces the diagram.
- Prove each candidate independently. Before the repair campaign, verify permitted traffic over each intended path under controlled topology conditions. An untested alternate neighbor is not a qualified backup route.
- Record the baseline next hop. With representative traffic running, record A’s path to D, relevant peer states and D’s validated operations. If the implementation chooses C initially, label that actual baseline rather than pretending B is active.
- Remove the observed active intermediate node. Use an authorized power-off or supported interface shutdown in the isolated setup. Record the fault time and what was actually removed. Do not use interference generation or regulatory workarounds.
- Observe detection, discovery and delivery. Capture peer/path transitions where exposed, destination next-hop changes, pending-frame observations and the first validated service response. Preserve missing and late operations, not just successful ones.
- Restore and exercise the controls. Restore the node, then repeat with the other path and a no-alternate-path case. The latter should expose bounded failure reporting rather than a false healthy mesh indicator. Test endpoint failure separately while the mesh path remains usable.
Repeat with the real payload size, cadence and concurrent traffic. Report the maximum observed useful-service gap and the full trial conditions without presenting it as a universal worst-case bound. A path-table update can precede application recovery, and buffered traffic can arrive after its usefulness deadline.
Interpret a hypothetical result
Suppose A retains an established peer with C after B is removed, but its destination path remains resolving and the service times out. That proves surviving adjacency, not successful repair. Check whether C can actually reach D, whether forwarding and authentication agree, and whether discovery results reach A. If the path becomes active through C but only the service beyond D fails, investigate D’s gateway and endpoint path separately.
The proposed campaign was not executed. No command example here claims measured route repair or hardware compatibility. Release with a peer/path/service evidence bundle, exact dynamic-path configuration, tested alternate topology and explicit loss and interruption limits. That turns “self-healing mesh” into a bounded engineering claim that can be inspected and repeated.
