Following up on a bug I reported a few weeks ago (MLO bond-state corruption / EAPOL loop). The bss_transition=0 workaround from that thread is still holding, this is a separate issue I noticed today while watching the logs.
Related thread: https://forum.gl-inet.com/t/bug-report-gl-be9300-mlo-bond-state-corruption-causes-eapol-loop/67353/15
With MLO active, one of my MLO-capable clients is stuck in a continuous associate/deauth cycle across band interfaces. No crash, no EAPOL loop — just bouncing for hours:
16:59:35 wlan1: STA a2:d0:89:2d:32:cf associated, handshake completed
17:00:05 wlan0: STA a2:d0:89:2d:32:cf deauthenticated due to inactivity (timer DEAUTH/REMOVE)
17:00:42 wlan0: STA a2:d0:89:2d:32:cf associated again, full handshake again
17:01:12 wlan1: STA a2:d0:89:2d:32:cf deauthenticated due to inactivity (timer DEAUTH/REMOVE)
17:10:40 wlan1: STA a2:d0:89:2d:32:cf associated again
...
Ran from 16:59 to 17:34 without stopping. From the user side the device stays "connected" the whole time, but every 10–30 minutes it's doing a full 4-way handshake in the background.
What I think is happening: MLO clients get registered on multiple band interfaces simultaneously, and the per-interface inactivity timer sees the non-active links as idle and kicks them. The client reconnects immediately and the loop starts again. If that's right, the inactivity timer shouldn't fire per-interface for MLO clients — it should only run at MLD level.
Side effect I noticed: this is probably also why MLO-capable clients don't stay stably on 6E even when they support it. The Meta Quest 3 in my setup was briefly visible on wlan12 + wlan22 (MLO active), then dropped to wlan2 (6 GHz non-MLO), then eventually ended up on wlan1 (5 GHz). The interface bouncing makes it hard for the client to maintain a stable link preference.
Happy to share full logs. Flagging this separately since it's a different failure mode from the EAPOL loop, but likely the same root area — MLO state management at the driver level.