📣 Bug Report: 802.11r breaks MLO on GL.iNet BE9300 (Wi‑Fi 7, QCN9224)

Router
1

Dear GL.iNet Team,

I’ve identified a reproducible issue on the GL.iNet BE9300 (IPQ5332 + QCN9224 Wi‑Fi 7) where enabling 802.11r Fast Transition on MLO SSIDs causes the entire Wi‑Fi 7 subsystem to fail. This results in the MLO bond interface (mld0) being destroyed, hostapd failing to start, and the main SSID disappearing from the air.

Below is a clean summary of the problem, how to reproduce it, and the logs that confirm the failure.

:puzzle_piece: Summary of the Issue

When 802.11r is enabled on Wi‑Fi 7 MLO interfaces, the BE9300:

  • fails to initialize MLO VAPs (wlanmld2g, wlanmld5g, wlanmld6g)

  • destroys the MLO bond interface (mld0)

  • repeatedly tears down and recreates Wi‑Fi radios

  • fails to start hostapd for MLO interfaces
    → Failed to connect to hostapd - wpa_ctrl_open: No such file or directory

  • triggers subsystem restarts (SSR events)

  • leaves only simple non‑MLO SSIDs (e.g., IoT network) active

Disabling 802.11r immediately restores normal operation.

:test_tube: How to Reproduce

  1. Configure BE9300 with:

    • MLO SSIDs on 2.4/5/6 GHz (wlanmld*)

    • WPA3‑SAE

    • VLAN 10

    • 802.11k/v enabled

    • (optional) guest SSIDs — these do not cause issues

  2. Enable 802.11r on the MLO SSIDs.

  3. Restart Wi‑Fi:

    Code

    /etc/init.d/network restart

  4. Observe:

    • MLO SSID disappears

    • only IoT/non‑MLO SSIDs remain visible

    • logs show MLO bond teardown and hostapd failures

:stop_sign: Actual Behavior

From the logs:

  • MLO bond destroyed

    mld0: Destroying bond as no slaves are present

  • hostapd fails to start

    Failed to connect to hostapd - wpa_ctrl_open: No such file or directory

  • MLO VAPs fail to initialize

    ol_ath_vdev_set_intra_bss: vdev is NULL!

  • Subsystem restarts

    ol_ath_wifi_ssr: SSR event

  • Peer table overflow when 802.11r is enabled

    Host Requested 1058 peers. FW Supports 290 peers

With 802.11r disabled, all MLO interfaces come up cleanly and the SSID is visible on all bands.

:check_mark: Expected Behavior

  • MLO bond (mld0) should remain stable

  • All MLO VAPs should initialize

  • hostapd should create control sockets for all interfaces

  • SSID should be visible on 2.4/5/6 GHz

  • No SSR events or VDEV failures

:compass: Workaround

  • Disable 802.11r on Wi‑Fi 7 MLO SSIDs

  • 802.11r works fine on Wi‑Fi 6 APs (non‑MLO)

  • All other features (MLO, VLAN, guest networks, 802.11k/v) work normally

:folded_hands: Request

Could you please investigate compatibility between:

  • 802.11r Fast Transition

  • MLO (Multi‑Link Operation)

  • QCN9224 firmware on BE9300

This appears to be a firmware/driver issue rather than a configuration problem.

I can provide full logs, configs, and additional testing if needed.

Thanks!

Regards,

percy

2

Hmm,

I'm not a expert and also used some AI but I think the awnser of AI is not wrong this time, because it was kind of expected what I thought initially.

MLO can use multiple bands at once, however 802.11r is not designed to roam over multiple bands at the same time, maybe with a hack but that is against the wifi standard.

Basicly MLO is not compatible with fast roaming or mutually exclusive.

Also another incompatibility is that MLO is designed for WPA3 initially when roaming was more designed for wpa2 atleast at the design times.

This is half true, generally this is exactly the problem with todays device and router implementations today, some work and hack around something and some strictly follow the standard, and sometimes the implementations are written without a official standard thats also possible, you could expect this to see on early wifi 7 adopted devices.

I know that for multi psk and wpa3/sae the mac option is enforced as a standard requirement by the wifi alliance thats another example why wpa3 tend to be much stricter than wpa2.

But also why some things won't work on wpa2 or vice versa on wpa3, and I think this is what the AI tried to explain with that.

Honestly I think the real problem is atleast that is how I look to it, is for the wifi alliance is to bring back sense back in all those 802.11 options which are not compatible anymore on wpa3 but also are not compatible to wpa2.

It becomes a configuration nightmare and nobody knows anymore what settings are compatible with the wifi standard old vs new.

1 Like
3

Hi

Could you please clarify:

  1. What is the firmware version? You can find it under Admin Panel > System > Upgrade.
  2. How did you enable 802.11r on the MLO? If possible, please provide us the command or configuration.
4

This is my understanding also, WPA3 is required for MLO and 802.11r has a much much smaller benefit in a WPA3 environment. There is an improvement but it’s minor compared to WPA2 as WPA3 already has much faster roaming. With MLO/WPA3 it shouldn’t 802.11r isn't really need to be enabled to achieve similar roaming to WPA2 with 802.11r.

802.11r causes so many compatibility issues generally it’s not really recommended for WPA2 either in many cases, at least not in a home/soho environment.

2 Likes