[BUG] BE9300 — MLO unusable on FW 4.9, bss_transition=0 workaround does not help (dms not-supported)

Hello,

Follow-up to the now-closed thread on the BE9300 MLO / EAPOL loop (link: [BUG REPORT] GL-BE9300 – MLO Bond-State Corruption causes EAPOL Loop - #16 by Maeddes). I tested the bss_transition=0 workaround from that thread and want to report that it does not resolve the issue on my setup — the MLO SSID remains unusable for every client I tried.

Setup:

GL-BE9300 (Flint 3), firmware 4.9., kernel 5.4.213
Dual SSID: one MLO, one legacy. MLO on 6 GHz, 320 MHz.
The legacy (non-MLO) SSID works fine for all devices. The problem is limited to the MLO SSID.

Workarounds tested, none fixed it:

bss_transition=0 on the MLO 6 GHz interface only → no change.
ieee80211k=0 added → no change.
bss_transition=0 on all 6 active interfaces (wifi2g/5g/6g + wlanmld2g/5g/6g), applied and confirmed via uci get, wifi reload done → still no change.

Result: every client I tested fails to connect to the MLO SSID. On the client side it shows as "wrong password" (even though the password is correct). Clients tested include a MediaTek MT7925 (Wi-Fi 7), a Samsung Fold 6 (Qualcomm 6E), and other Windows machines. All end up having to use the legacy SSID instead.

Logs — the handshake never completes. Association succeeds, then the 4-way handshake loops on 2/4 and the client is disassociated after a few seconds, repeating indefinitely:

ieee80211_recv_asreq: assoc req from dms not-supported sta :XX:XX:...
WPA: sending 1/4 → received 2/4 → sending 1/4 → ... → disassociated

The recurring assoc req from dms not-supported kernel error appears on the failing association attempts. I also see repeated ieee80211_recv_probereq: Not responding to Broadcast ML probe request during connection attempts.

Summary: the bss_transition=0 workaround (single interface, all interfaces, and combined with ieee80211k=0) does not make the MLO SSID usable here. The dms not-supported reject at association time appears to be the blocker, which is below the BTM layer the workaround addresses — pointing to a driver-level (Qualcomm) issue in the MLO association path rather than something fixable in config.

Reverted to stock config for now and using the legacy SSID. Happy to provide full logread, run test builds, or capture anything else useful. Is a fix planned in an upcoming firmware/driver update?

Thanks!