Product: GL.iNet Flint 3 (GL-BE9300)
Firmware: Beta (kernel 5.4.213, IPQ5332 SoC, QCA WiFi stack)
Severity: High – WiFi clients cannot connect, appears as "Wrong Password" even with correct credentials, workaround requires disabling MLO
Date: 2026-02-26
Executive Summary
Three interrelated bugs in the MLO (Multi-Link Operation) implementation cause a cascade from association failure all the way to a complete, unrecoverable system freeze:
| # | Bug | Severity |
|---|---|---|
| 1 | DMS capability rejection corrupts MLO bond-state → "Zombie-Association" → infinite EAPOL loop → WiFi connection failure | High |
| 2 | MLO bond (mld0) cannot be destroyed cleanly → dirty teardown with kernel errors |
Medium |
| 3 | MLO AID manager loses state tracking during teardown | Medium |
Key proof: The DMS error alone is harmless – without MLO active, clients with DMS capability connect successfully. The bug is exclusively triggered by the combination of DMS rejection + active MLO bond-state.
Note: A separate related incident on the same day resulted in a full system freeze caused by an SSID conflict that amplified the EAPOL loop over an extended period. That incident is documented in a separate bug report. This report covers only the MLO/DMS connection failure and dirty teardown.
Environment
| Router | GL.iNet Flint 3, GL-BE9300 |
| Kernel | Linux 5.4.213, ARM64, IPQ5332 SoC (4 cores) |
| WiFi chipsets | QCN9224 (5/6 GHz), QCA5332 (2.4 GHz) |
| MLO config | 3-link: wlan02 (2.4 GHz) + wlan12 (5 GHz) + wlan22 (6 GHz), bond: mld0 |
| Security | WPA2-CCMP (RSN) |
| Confirmed affected clients | Xiaomi POCO M7 Pro 5G (da:66:ee:d7:f3:93), unknown device (62:de:21:52:e4:ec), iPhone (reported, no DMS error in log) |
| Active services | ECM, NSS offload, Netify Agent 5.1.24, NordVPN WireGuard, ZeroTier, Samba 4.18.8 |
Bug 1 – DMS Rejection Corrupts MLO Bond-State ("Zombie-Association" → EAPOL Loop)
Root Cause
When a client advertises DMS (Directed Multicast Service) capability, the QCA driver correctly rejects it – but fails to invalidate the MLO bond-state for that client. The client is accepted into a "Zombie-Association": hostapd proceeds with the EAPOL 4-Way Handshake, but the corrupted bond-state prevents the handshake from ever reaching msg 3/4. hostapd retransmits msg 1/4 indefinitely with no retry-limit, no backoff, and no temporary client ban.
Proof: DMS error alone is harmless without MLO
The same client (da:66:ee:d7:f3:93, POCO M7 Pro 5G) triggers the identical DMS error both with and without MLO active – but the outcome is completely different:
With MLO active → EAPOL loop, never reaches 3/4:
19:02:17 kernel: [ 7909] wlan: [0:E:ANY] ieee80211_recv_asreq: assoc req from dms not-supported sta :62:de:21:52:e4:ec
19:02:17 hostapd: wlan01: STA 62:de:21:52:e4:ec WPA: sending 1/4 msg of 4-Way Handshake
19:02:17 hostapd: wlan01: STA 62:de:21:52:e4:ec WPA: received EAPOL-Key frame (2/4 Pairwise)
19:02:18 hostapd: wlan01: STA 62:de:21:52:e4:ec WPA: sending 1/4 msg of 4-Way Handshake ← retry, stuck
19:02:18 hostapd: wlan01: STA 62:de:21:52:e4:ec WPA: received EAPOL-Key frame (2/4 Pairwise)
19:02:19 hostapd: wlan01: STA 62:de:21:52:e4:ec WPA: sending 1/4 msg of 4-Way Handshake ← retry
19:02:19 hostapd: wlan01: STA 62:de:21:52:e4:ec WPA: received EAPOL-Key frame (2/4 Pairwise)
19:02:20 hostapd: wlan01: STA 62:de:21:52:e4:ec WPA: sending 1/4 msg of 4-Way Handshake ← retry
19:02:20 hostapd: wlan01: STA 62:de:21:52:e4:ec WPA: received EAPOL-Key frame (2/4 Pairwise)
19:02:21 hostapd: wlan01: STA 62:de:21:52:e4:ec IEEE 802.11: disassociated
... client re-associates immediately, entire loop repeats ...
Without MLO active → same DMS error, but handshake completes successfully:
19:18:04 kernel: [ 8856] wlan: [0:E:ANY] ieee80211_recv_asreq: assoc req from dms not-supported sta :da:66:ee:d7:f3:93
19:18:04 hostapd: wlan0: STA da:66:ee:d7:f3:93 WPA: sending 1/4 msg of 4-Way Handshake
19:18:04 hostapd: wlan0: STA da:66:ee:d7:f3:93 WPA: received EAPOL-Key frame (2/4 Pairwise)
19:18:04 hostapd: wlan0: STA da:66:ee:d7:f3:93 WPA: sending 3/4 msg of 4-Way Handshake ← proceeds!
19:18:04 hostapd: wlan0: STA da:66:ee:d7:f3:93 WPA: received EAPOL-Key frame (4/4 Pairwise)
19:18:04 hostapd: wlan0: STA da:66:ee:d7:f3:93 WPA: pairwise key handshake completed (RSN)
19:18:04 dnsmasq: DHCPACK(br-lan) 192.168.8.133 da:66:ee:d7:f3:93 POCO-M7-Pro-5G ✓
User Impact
On the client side this appears as "Wrong Password" or "Authentication failed" – even though the credentials are correct. The actual cause is the corrupted handshake state in the MLO layer, not an incorrect passphrase. Disabling MLO immediately resolves the issue – the same client connects successfully within seconds.
Bug 2 – Dirty MLO Teardown: mld0 Bond Cannot Be Destroyed Cleanly
When MLO is disabled via the web interface to work around Bug 1, the kernel fails to destroy the mld0 bond interface atomically. The sequence shows a clear resource management failure in the osif layer:
19:03:21 kernel: [9878:I:ANY] osif_mldev_remove_mld_osdev: mld0: The mld grp_id is: 0
19:03:21 kernel: Not able to destroy bond netdevice: mld0 as slaves are present
19:03:21 kernel: [9878:E:ANY] osif_destroy_mld_bond: mld0 destroy failed ← bond destroy fails
19:03:21 kernel: [9878:E:ANY] osif_destroy_mld_bond: releasing slave wlan02 ← fallback: manual slave release
19:03:21 kernel: [9878:E:ANY] osif_destroy_mld_bond: releasing slave wlan22
The bond (mld0) attempts to destroy itself while slaves (wlan02, wlan22) are still attached. The driver falls back to forcibly releasing slaves one by one rather than performing an atomic teardown. This is a race condition or incorrect teardown ordering in osif_destroy_mld_bond.
Bug 3 – MLO AID Manager State Loss During Teardown
During the same teardown sequence, the MLO Association ID manager attempts to deinitialize vdev IDs that were never correctly registered:
19:03:22 kernel: [0:E:MLO_MGR] wlan_mlo_vdev_aid_mgr_deinit: ID 0, doesn't have associated AID mgr
19:03:22 kernel: [0:E:MLO_MGR] wlan_mlo_vdev_aid_mgr_deinit: ID 1, doesn't have associated AID mgr
19:03:22 kernel: [0:E:MLO_MGR] wlan_mlo_vdev_aid_mgr_deinit: ID 2, doesn't have associated AID mgr
19:03:22 kernel: [0:E:MLO_MGR] wlan_mlo_vdev_aid_mgr_deinit: ID 3, doesn't have associated AID mgr
All four vdev IDs (0–3) report missing AID managers. This indicates the AID management state was never correctly initialised for these vdevs, or was already lost during the Zombie-Association phase, pointing to a deeper flaw in the QCA MLO resource allocation lifecycle.
Confirmed Affected Clients
| Device | MAC | DMS error in log | Behaviour with MLO | Behaviour without MLO |
|---|---|---|---|---|
| Xiaomi POCO M7 Pro 5G | da:66:ee:d7:f3:93 |
 confirmed |
EAPOL loop, no connection | Connects successfully |
| Unknown device | 62:de:21:52:e4:ec |
confirmed |
EAPOL loop, no connection | Not tested |
| iPhone (model unconfirmed) | fe:77:19:22:cc:36 |
 not seen |
Connection issues reported | Connects successfully |
The iPhone connects without a DMS error in the post-MLO-disable log, suggesting its connection issues may be related to Bug 2/3 (dirty teardown leaving inconsistent state) rather than Bug 1 directly.
Steps to Reproduce
Bug 1 (EAPOL loop / connection failure):
- Enable MLO on GL-BE9300 (5 GHz + 6 GHz active,
mld0bond up) - Attempt to connect a device that advertises DMS capability (POCO M7 Pro 5G confirmed)
- Observe
ieee80211_recv_asreq: assoc req from dms not-supported stain kernel log - Observe infinite 1/4 → 2/4 → 1/4 → 2/4 loop in hostapd log, client shows "Wrong Password"
- Disable MLO – same device connects immediately
Bug 2/3 (dirty teardown):
- With MLO active, trigger Bug 1 or simply disable MLO via the web interface
- Observe
osif_destroy_mld_bond: mld0 destroy failedandwlan_mlo_vdev_aid_mgr_deinit: doesn't have associated AID mgrin kernel log
Expected vs. Actual Behaviour
| Expected | Actual | |
|---|---|---|
| DMS-unsupported client with MLO active | Rejected cleanly with Status Code 43 (Unsupported Capability), bond-state cleared | Zombie-Association: client accepted into corrupted state, infinite EAPOL loop, "Wrong Password" on client |
| DMS-unsupported client without MLO | Same clean rejection with Status Code 43 | Works correctly – handshake completes (confirms bug is MLO-specific) |
| MLO disable/teardown | Atomic: bond destroyed, slaves released, state cleared in one operation | Bond destroy fails, slaves released manually via error-path fallback, AID manager state lost |
Suggested Fixes
1. Fix DMS rejection to invalidate MLO bond-state (Bug 1 – primary fix)
When ieee80211_recv_asreq rejects a DMS association, the MLO bond-state for that STA must be fully cleared before hostapd proceeds. The current path accepts the client into hostapd with a corrupted bond reference. The fix should ensure osif_mld_unmap_link_dev is called for the STA before returning from the DMS rejection path.
2. Implement EAPOL retry-limit with temporary client ban (Bug 1 – safety net)
Even if Bug 1 is not immediately fixed, hostapd must not retry msg 1/4 indefinitely. After N failed handshakes (e.g. 5), call ap_sta_disconnect() and add the MAC to a temporary deny-list (60 s). Relevant config: wpa_ptk_rekey=60.
3. Fix MLO bond teardown ordering (Bug 2)
osif_destroy_mld_bond must detach all slaves before attempting to destroy the bond netdevice. The current code attempts bond_destroy while slaves are still present and falls back to manual release only after failure. The slave detach loop should be the first step, not the error recovery path.
4. Fix MLO AID manager lifecycle (Bug 3)
wlan_mlo_vdev_aid_mgr_deinit should only be called for vdev IDs that were successfully registered. The missing AID manager errors suggest the init/deinit lifecycle is not properly tracked, likely related to the same Zombie-Association state corruption in Bug 1.
Workaround
Disable MLO (and optionally 6 GHz) in the GL-BE9300 web interface. DMS-capable clients then connect successfully as shown in the logs. This is a significant capability regression for a Wi-Fi 7 router but is currently the only stable configuration.
