Final Update: Workaround confirmed — bss_transition=0 on all interfaces
After further testing, setting bss_transition=0 on all six interfaces resolves both issues completely.
Apply the fix:
bash
uci set wireless.wifi2g.bss_transition='0'
uci set wireless.wlanmld2g.bss_transition='0'
uci set wireless.wifi5g.bss_transition='0'
uci set wireless.wlanmld5g.bss_transition='0'
uci set wireless.wifi6g.bss_transition='0'
uci set wireless.wlanmld6g.bss_transition='0'
uci commit wireless
wifi reload
Confirmed results with MLO active:
-
POCO M7 Pro 5G connects on 2.4 GHz — no more EAPOL loop -
Lenovo Tab P11 Pro connects on 5 GHz — no more wlan12 reject loop
Important: all six interfaces must be set together.
When we initially only set bss_transition=0 on the 2.4 GHz interfaces (wifi2g + wlanmld2g), the Lenovo Tab P11 Pro broke: it was getting authenticated on wlan12 (the MLO 5 GHz link) but immediately disassociated with no EAPOL, repeating three times before giving up — and never falling back to wlan0 (2.4 GHz). The Lenovo is not a WiFi 7 / MLO-capable device and relies on the regular wlan1 interface. With inconsistent bss_transition values across the MLO bundle, it could not associate on any interface at all.
Setting all six interfaces to bss_transition=0 resolved both the POCO EAPOL loop and the Lenovo association failure simultaneously. Full MLO functionality on 5/6 GHz is preserved.
This remains a workaround. The root cause is a driver-level bug in the interaction between MLO bond-state, BSS Transition Management, and DMS-not-supported clients. A proper fix requires a Qualcomm driver update.