# FLINT 4 MLO 4.11 Beta bug - device lost association when adding new device to network **URL:** \ **Category:** Router\ **Created:** [October 2, 2026, 8:37pm UTC](https://forum.gl-inet.com/t/flint-4-mlo-4-11-beta-bug-device-lost-association-when-adding-new-device-to-network/71764 "2026-10-02T20:37:14Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![Slighting](https://forum-assets.gl-inet.com/letter_avatar_proxy/v4/letter/s/f1d935/32.png) [@Slighting](https://forum.gl-inet.com/u/Slighting)\ **Post date:** [October 2, 2026, 8:37pm UTC](https://forum.gl-inet.com/t/flint-4-mlo-4-11-beta-bug-device-lost-association-when-adding-new-device-to-network/71764/1 "2026-10-02T20:37:14Z")
Claude summary after some extensive troubleshooting: These logs change the picture. The device at 96:55:11:36:99:17 isn't the iPhone at all. The DHCP lines at the end show it's **-s-Tab-S7-F** , a Samsung tablet. I misread that earlier when I called it the phone's link address. What the logs actually show looks like the tablet's reconnection wiping out the iPhone's association. **What happened, step by step:** 1. **21:08:56:** The tablet starts a normal SAE (WPA3) authentication. The router has never seen it before (`wcid=4095` means no existing entry). 2. Instead of creating a fresh entry, the router **deletes the iPhone's MLD entry** (`mld_entry_del ... ae:c4:fd:25:e6:f0`), re-creates it, and attaches the tablet's link to it (`mld(sta_idx=0,addr=ae:c4:fd:25:e6:f0) acquired!!`). As far as the router is concerned, the tablet is now part of the iPhone's multi-link association. 3. The tablet's association request carries no MLO information, which makes sense since it isn't an MLO device. The router rejects it as inconsistent: `PeerAssocReqMloCapSanity: mlo-capability(1) changed (invalid)`. 4. **21:08:59:** The tablet gives up and sends a deauthentication. The router tears down that merged entry, and **the iPhone's MLD entry goes with it** (`mld_entry_del ... ae:c4:fd:25:e6:f0`). No deauthentication is ever sent to the iPhone. 5. The tablet retries, gets rejected once (status 53, invalid PMKID), then connects cleanly as an ordinary non-MLO client at 21:09:03. 6. The iPhone is left believing it's associated while the router has no record of it. Your `ip neigh` result of `FAILED` for 192.168.8.234 confirms the router can no longer reach it. This looks like a firmware bug in the router's MLO client tracking. When the tablet connected, it was matched to an existing MLD slot (`sta_idx=0`) that belonged to the iPhone. It isn't the iPhone's fault, and MLO is very much a factor, just not in the way either of us first expected. **What to do next:** 1. **Try to reproduce it.** Once the iPhone is reconnected (toggling its Wi-Fi is fine now, since you have the evidence), confirm it's online, then turn the tablet's Wi-Fi off and on. Watch `logread -f` for an `mld_entry_del` of ae:c4:fd:25:e6:f0 when the tablet joins. If it happens again, you have a reliable reproduction. 2. **Check the soundbar.** Your soundbar drops may be the same bug. Grep the logs for the soundbar's MAC address and look for its MLD entry being deleted at the moment some other device connects. That would also explain why the drops seemed random. 3. **Work around it for now.** The most practical option is a separate SSID with MLO disabled for non-MLO devices like the tablet, so they never touch the MLO client table. Alternatively, disable MLO entirely until there's a fix. Check whether GL.iNet has newer firmware for the GL-BE14000. 4. **Report it to GL.iNet.** Send them this log excerpt along with the 19:09 iPhone join. The key evidence is the iPhone's `mld_entry_del` being triggered by an authentication from a different, non-MLO MAC address, followed by the `PeerAssocReqMloCapSanity` error ---
**Author:** ![AI\_bot](https://forum-assets.gl-inet.com/letter_avatar_proxy/v4/letter/a/ecccb3/32.png) [@AI\_bot](https://forum.gl-inet.com/u/AI_bot)\ **Post date:** [October 2, 2026, 8:37pm UTC](https://forum.gl-inet.com/t/flint-4-mlo-4-11-beta-bug-device-lost-association-when-adding-new-device-to-network/71764/2 "2026-10-02T20:37:56Z")
Treat this as a suspected MLO driver/firmware issue rather than a confirmed bug until it reproduces. Capture one clean test: reconnect the iPhone, note the client MAC addresses and timestamp, toggle only the tablet’s Wi‑Fi, and verify whether the same iPhone MLD entry is deleted and the iPhone becomes unreachable without receiving a deauthentication. This distinguishes a repeatable cross-client teardown from unrelated roaming or rekeying. Please send the exported router log, exact 4.11 beta build number, and client OS versions privately to **[support@gl-inet.com](mailto:support@gl-inet.com)**; redact unrelated identifiers and do not publish the full log. Disabling MLO entirely is the safest temporary workaround—the proposed separate non-MLO SSID may not isolate the underlying driver station table. > **This reply was generated by AI. Please verify its accuracy.** > > GL.iNet Technical Support reviews and responds to relevant threads on business days. Please allow time for a staff response. ---
**Author:** ![Slighting](https://forum-assets.gl-inet.com/letter_avatar_proxy/v4/letter/s/f1d935/32.png) [@Slighting](https://forum.gl-inet.com/u/Slighting)\ **Post date:** [October 3, 2026, 7:01am UTC](https://forum.gl-inet.com/t/flint-4-mlo-4-11-beta-bug-device-lost-association-when-adding-new-device-to-network/71764/3 "2026-10-03T07:01:56Z")
Had a similar issue this morning when running a 6ghz channel analysis scan in Luci. Both wifi 6/7 devices connected to MLO lost association and had to bounce their wifi connection to get connectivity back and complete a fresh handshake… see claude analysis of logs below: The second log answers both questions. LuCI is causing the problem, and the router then handles the Mac's reconnect badly. ### Why the 6GHz scan never shows results The scan does finish at the driver level. Each 6GHz sweep ends with `scan_ch_restore ... Total BSS[01]` and `cfg80211_scan_done`. Straight after that, every time, there's: ```auto wappd: [NL80211][wapp_process_scan_result.2430]: wdev not found ``` So the radio scans channels 1–233, finds one network, and the results get lost on the way back to userspace. LuCI never receives anything, gives up waiting, and starts a new scan. That's the "just keeps scanning" you saw. The log shows full 6GHz sweeps at 07:50:52, 07:51:57, 07:52:17, 07:52:42 and 07:55:49, each one taking the 6GHz radio off-channel for about 10 seconds. The 5GHz scan at 07:50:17 found 16 networks and LuCI displayed them, so the problem is specific to 6GHz. It looks like a bug in GL's MediaTek driver or firmware in how 6GHz scan results are reported. Nothing in your configuration would cause it. **Practical upshot:** close that LuCI tab. While it's open it re-runs a disruptive scan every 20–30 seconds that will never succeed. The result it does get, a single BSS, also tells you 6GHz is effectively empty where you are. ### Why the Mac got stuck and needed a Wi-Fi toggle The Mac is `ca:f0:a6:6f:f7:79`, the "Mac" at 192.168.8.237. During the 07:55:49 scan: 1. **6GHz went away** , so the Mac tried to move to 5GHz (`rai2`). It used a cached PMKID, a saved key that lets it skip the full password handshake. 2. **The router didn't have a matching cached key.** It logged `PMKSA cache not match (SAE/PSK)` and rejected the Mac with status 53 (invalid PMKID). That part is normal; the Mac should simply redo the full WPA3 (SAE) handshake. 3. **The router then broke that handshake.** The Mac sent its first SAE message and the router replied. Then hostapd immediately logged `disassociated` and the driver sent `deauth ... reason=2`. The Mac's follow-up SAE messages arrived after its entry had been deleted, and were dropped (`seq=2 ... wcid=4095` at 07:55:51, :52, :53). 4. **The same thing happened on 6GHz** at 07:55:58: status 53, SAE starts, deauth reason 2, and the late messages dropped at 07:56:00–02. 5. The Mac then gave up. Nothing worked until 07:57:12, when you toggled Wi-Fi. That triggered a fresh full SAE handshake, which succeeded. Steps 3–4 look like a firmware bug. After rejecting a stale PMKID, the router tears down the full re-authentication it should be allowing. The scan is what forces the Mac to roam and hit this path, but any band switch between 5GHz and 6GHz could trigger it. ### What I'd do - **Stop using 6GHz channel analysis.** It can't currently work and it disrupts 6GHz clients every time it runs. - **Reduce cross-band roaming on the Mac.** MLO appears to be on: `rai2` and `rax2` share the MLD address `ee:90:15:d5:06:42`, and your iPhone connects as an MLO client. You could give 6GHz its own SSID, or try disabling MLO in the GL admin panel. Either should cut down on the Mac bouncing between bands with a stale cached key. - **Clear the Mac's cached credentials.** In Wi-Fi settings, forget the network and rejoin it. - **Check for a GL.iNet firmware update.** If there isn't one, it's worth reporting the `wdev not found` 6GHz scan issue and the status-53-then-deauth-reason-2 sequence to GL, with these log excerpts. One more thing from this log: at 07:47:19 every client on every band was deauthenticated at once (`MacTableResetNonMapWdev ... Send DeAuth`). That came from a Wi-Fi config reload: the country code was reapplied as GB and the channel lists were rebuilt. If you saved a setting in LuCI around then, that explains it. It's a separate event from the scan drops. This log covered a lot of ground. If you dig further into the MLO or roaming behaviour, starting a fresh chat with just the relevant log section will keep things focused. ---
**Author:** ![AI\_bot](https://forum-assets.gl-inet.com/letter_avatar_proxy/v4/letter/a/ecccb3/32.png) [@AI\_bot](https://forum.gl-inet.com/u/AI_bot)\ **Post date:** [October 3, 2026, 7:02am UTC](https://forum.gl-inet.com/t/flint-4-mlo-4-11-beta-bug-device-lost-association-when-adding-new-device-to-network/71764/4 "2026-10-03T07:02:37Z")
This provides a second, distinct trigger, but the exact cause should still be treated as unconfirmed. The most useful comparison is one manual 6 GHz scan with MLO enabled versus the same test after disabling MLO and rebooting. If clients fail only with MLO enabled, that isolates the MLO reconnection path; if they also fail without MLO, the problem is more likely the 6 GHz scan/radio handling itself. Avoid leaving the LuCI scan page open if it repeatedly starts new sweeps. Please add the exact scan start time and a redacted log covering roughly one minute before the scan through the successful reconnection to the same support report previously recommended. Include the exact 4.11 beta build number and note whether each client received an explicit deauthentication or merely became unreachable. Until this is reviewed, avoid 6 GHz channel analysis on an active network and use disabled MLO as the safer workaround. > **This reply was generated by AI. Please verify its accuracy.** > > GL.iNet Technical Support reviews and responds to relevant threads on business days. Please allow time for a staff response. ---
**Author:** ![charles2](https://forum-assets.gl-inet.com/letter_avatar_proxy/v4/letter/c/9dc877/32.png) [@charles2](https://forum.gl-inet.com/u/charles2)\ **Post date:** [October 21, 2026, 10:47am UTC](https://forum.gl-inet.com/t/flint-4-mlo-4-11-beta-bug-device-lost-association-when-adding-new-device-to-network/71764/6 "2026-10-21T10:47:46Z")
Hi, Thank you for the detailed report and for sharing your findings. Regarding Issue 1, we haven't been able to reproduce the issue in our local testing so far. Could you please help us clarify a few details? 1. Had you ever changed the MLO Wi-Fi band combination on the Flint 4 (for example, from 5 GHz + 6 GHz to 2.4 GHz + 5 GHz)? 2. Is the issue consistently reproducible whenever a new device joins the MLO network, or does it occur intermittently? 3. Does rebooting the Flint 4 restore the affected device's connection? 4. If the issue occurs again, could you please export the complete System Log from the Flint 4 and send it to us via private message? * * * Regarding Issue 2, we were able to reproduce the issue locally when scanning 6 GHz channels in LuCI's Channel Analysis. Our initial findings suggest a compatibility issue between the MTK SDK wireless driver and LuCI's Channel Analysis function. As this LuCI functionality is not actively maintained and falls outside our current maintenance scope, we may not be able to provide a fix ourselves. For now, we recommend avoiding 6 GHz channel scans in LuCI, as they may interrupt existing wireless connections. Thank you for your patience and assistance.