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)

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)

[Louis Kotze]

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