rtw89: 8922a hw_scan on an MLO association blacks out traffic ~3 s per scan (45-62% loss under load, AP kicks STA with DISASSOC_LOW_ACK)
Hi Ping-Ke,
On an RTL8922AU station associated to a Wi-Fi 7 AP MLD, every full hw_scan takes the link off-channel for about 3.3 s essentially contiguously, with roughly 2 s of completely dead downlink per scan. Under moderate load with a periodic background scan this costs 45-62% of the traffic, and the AP sometimes deauthenticates the station with reason 34 (DISASSOC_LOW_ACK) a few seconds into the first scan. The same client and the same scan are fine on a non-MLO association, and an Intel client is fine on the same AP MLD, so the failure needs the rtw89 + MLO combination. Evidence below; I can provide full captures.
Environment
-----------
- RTL8922AU (USB 0bda:8912), firmware 0.35.80.3 (8ef4f0cf), cmd version 1, rtw8922a_fw-4.bin from linux-firmware 20260622.
- Driver: rtw89 out-of-tree USB snapshot r1868 (morrownr; the scan-offload H2C code matches current wireless-next). Kernel 7.1.3.
- AP: TP-Link Deco BE65 v2 (Qualcomm), EHT AP MLD, 5+6 GHz.
- Association: EHT160, tested both single-link (5 GHz) and EMLSR dual-link (5+6 GHz anchor on 6 GHz). Same behavior.
- Test: iperf3 UDP downlink to the STA, full "iw dev wlan0 scan trigger" every 5-8 s, loss measured at the STA; AP-side per-station tx_errors read from the AP where available.
The differential (three-way control, 2026-06-19 campaign)
---------------------------------------------------------
Identical 100 Mbit/s downlink + full scan every 5 s, 60 s per cell:
- rtw89 on the AP MLD (EHT160): 62.3% loss (repeats 60.4, 61.8),
AP tx_errors +282k, ~2 s dead downlink on EVERY one of 12 scans.
- Intel AX210 on the SAME AP MLD,
same channel, same test: 3.5% loss, tx_errors +4.7k,
0 dead seconds.
- Same rtw89 client on a non-MLO
AP (Archer AX20, HE80), same
driver and scan: 5.0% loss, no blackout.
- No-scan controls on all cells: ~0% loss.
- A short scan (single channel, or
8 non-DFS 5 GHz channels) on the
AP MLD link: 4.9-6.9% loss, 0 dead seconds.
So off-channel DURATION is the driver: the full-scan ~3.3 s excursion is what kills the link, and only on the MLO association. The loss is direction-symmetric (uplink also loses ~62%, with AP tx_errors not moving, so this is not just an AP buffering question; the station is simply away too long in one stretch).
Still present on current firmware (2026-07-10)
----------------------------------------------
Re-ran on fw 0.35.80.3 / driver r1868 / EMLSR dual-link, 18 Mbit/s downlink, full scan every 8 s, 40 s:
- Control (no scans): 0.0% loss.
- Run 1: 27.2% loss, and the AP deauthenticated the
station with reason 34 (DISASSOC_LOW_ACK) about 3 s into the first scan.
- Run 2: 45.3% loss across 5 scans.
Why this looks like a firmware scan-scheduling issue on MLO
-----------------------------------------------------------
The BE scan-offload design should protect an associated link: the driver requests opmode=RTW89_SCAN_OPMODE_INTV with an op-channel revisit interval, num_opch=1 and txnull=1, and I confirmed with an instrumented H2C builder that this is armed with the correct link BSSID. RTW89_OFF_CHAN_TIME should cap contiguous off-channel time at about 100 ms. The C2H LEAVE/ENTER notifications do arrive at the driver during the scan. Yet the observed result on the MLO association is a ~3.3 s contiguous blackout per scan, as if the op-channel revisits do not give the link usable airtime.
Two more over-the-air observations (AX210 in monitor mode):
- The station's PM=1 nullfuncs are visible and roughly double during scan periods, so PM signaling is not absent. But the AP sets TIM for this station in only ~59 of ~624 beacons during the test, versus ~98 of ~632 for the AX210 under the same load, and its tx_errors climb throughout: the doze windows evidently do not line up with the actual off-channel excursions.
- As an experiment I had the driver send an additional PM=1 nullfunc at each LEAVE_OP and PM=0 at ENTER_OP: downlink loss dropped from ~37% to 0% and the AP buffered correctly. Not a viable fix (it fights the firmware's own scan-time PM handling and eventually destabilizes the connection), but it shows well-timed PM framing fully protects the downlink on this AP.
Questions for the firmware team
-------------------------------
1. On an MLO/EMLSR association, does the BE scan-offload firmware actually perform the periodic op-channel revisit (INTV opmode) during a full multi-band scan, or does it batch the whole scan as one long excursion?
2. Is the per-excursion txnull PM frame sent at the right time and on the right link for an MLD association (and with the associated link address)?
3. Is there anything the driver should be doing differently for MLO scans (splitting the channel list, different opch policy) that would bound the off-channel time?
Practical impact: any periodic background scan (wpa_supplicant or NetworkManager bgscan, roaming scans) triggers this; on APs with an aggressive low-ack policy it escalates to the AP kicking the station mid-scan.
I am happy to share the full capture campaign (client iperf3 JSON, monitor-mode pcaps, AP-side tx_errors series, per-second traces), the H2C instrumentation patch, and to test debug firmware or patches on this setup.
Best regards,
Louis Kotze