FLINT 4 MLO 4.11 Beta bug - device lost association when adding new device to network

Router
1

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

2

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; 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.

3

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:

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.

4

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.