AP drops STA data frames for ~130-170ms after 4-way handshake completes (ath9k_htc, mt76; not brcmfmac)

[Devin Wittmayer]

On Mon, 2026-08-31 at 07:47 +0200, Thomas Hilber wrote:
> Done, and it does not hold here. The window is filled correctly and my
> stall happens anyway.

Welp, that kills it, and TID 0 on its own is enough. I read too much into
one capture.

Your question first, and the answer is half unhelpful. I can't check
whether my slow cycles survive a session where the SSN does arrive,
because I can't reproduce the slow cycles any more. Cleaning up the
harness took the effect with it. My traffic had been going over loopback,
and my timing metric merged the stall into the reassociation gap. Thirty
five associations on the MT7922 across both bands since, nothing in your
range at all. So treat my 27-in-95 from the 30th as unreliable until I can
produce it again.

What I can do is make your window happen deliberately.

I built stock mt76 with a module parameter that sleeps inside set_key, so
a key install takes as long as I like. Same binary both arms, the only
difference is a number I echo into sysfs. The station is on a different
driver, so the delay only hits the AP.

  keydelay_ms=0     key install   1.1 ms
  keydelay_ms=150   key install 155.3 ms

With the delay, all nine associations took 103 to 184 ms before traffic
passed again. Without it, seven of nine were back inside 78 ms.

The reason it works is that mac80211 calls the driver before the key is
reachable. In ieee80211_key_replace, enable_hw_accel runs first and the
rcu_assign_pointer that publishes the key to the RX path runs after it. So
while set_key is blocked, the AP has no key in hardware and none in
software either. It is deaf, not slow.

And yes, the MT7922 does give me a monitor interface on its own phy with
hostapd running, same as yours. So I captured air and the AP's netdev
together through an induced window. Across four windows the station put
21, 26, 25 and 25 data frames on air and the netdev saw 7, 24, 13 and 24.
In a quiet 200 ms a second later, nothing is lost at all.

Which says your 22.2 ms isn't evidence against a deaf window. Frames in
the window are dropped, not delayed, so anything timed at the netdev can
only be timing the survivors. Yours would look fast for the same reason
mine does.

So the measurement worth making is your key install.

  echo 1 > /sys/kernel/tracing/events/mac80211/drv_set_key/enable
  echo 1 > /sys/kernel/tracing/events/mac80211/drv_return_int/enable

Pair each set_key with the next return on the same pid. Near 134 ms and
it's ath9k_htc's key path. A few ms like mine and it isn't, and your
two-mechanisms reading is probably right.

Assuming CCMP, two things you can skip. The key writes take the else
branch in ath_hw_set_keycache_entry and batch into one WMI multi-write,
not six round trips. And the buffer enable and flush around them are a
paired inc/dec, so nothing sits unflushed. TKIP takes a different branch.

Thanks for the monitor-on-the-same-phy trick. That'll save people a run.

Devin