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

[Thomas Hilber]

On Thu, 2026-09-03 at 00:42 -0700, Devin Wittmayer wrote:
> So the measurement worth making is your key install.

Measured. It is not the key path.

Both tracepoints, paired by pid, taken during the same 150s window in which
the stall was being measured on the station side, so these are the same
associations and not a separate run:

                          station side              ath9k_htc set_key
                                                 (drv_set_key -> return)
  nohwcrypt=0   5.01 attempts, 134.4 ms      median 0.418 ms, max 0.663 ms
                n=183 cycles, 98% >1 attempt      n=394, none over 50 ms

  nohwcrypt=1   1.01 attempts,   3.8 ms      median 0.001 ms
                                                  (driver barely involved)

394 key installs, not one above 0.7 ms, while every association in the same
window was losing 134 ms. That is about 320x short of accounting for it, so
by your test the two-mechanisms reading holds.

One caveat I cannot close from here. ath9k_htc is a USB part and set_key
ends in a WMI write, so "drv_set_key returned" is only the driver call
returning. If that write were queued rather than acknowledged, the number
above would be measuring the queueing and not the install. Against that:
0.418 ms is about what a USB control round trip costs, and it is far too
slow to be a memory write, which is what it would look like if nothing went
out to the chip. So I think the key really is in the part when set_key
returns - but I have not read the WMI path to confirm it is synchronous,
and if someone who knows ath9k_htc says otherwise, this measurement is
worth nothing.

You are right about my 22.2 ms and I should not have offered it. Timing
first-frame delivery at the netdev can only ever time the frames that
survived, so it cannot distinguish deaf from slow. It was not evidence,
and I have dropped it.

Your induced window is a much better instrument than anything either of us
had before, and it is worth saying what it does and does not settle. It
shows that a slow key install produces this signature. It does not show
that a slow key install is what produces it on hardware where the install
is fast - and on ath9k_htc it now looks like it isn't. Both can be true.

Thanks also for the retraction on the reorder window; that saved me from
building on it. For what it is worth, my TID 7 sessions still show your
exact mismatch, declared SSN never arriving in about 97% of them - but at
the same rate in the arm with no stall, so it is a real pattern here that
simply does not track the symptom either.

Where that leaves ath9k_htc: association completes, the 4-way handshake
completes, hostapd authorizes the port, the key reaches the chip in under a
millisecond, the block-ack window opens on a sequence the station does send
- and the station's first several frames still do not come back. I am out
of hypotheses that I can test from outside the driver. If anyone on the
ath9k side wants a specific tracepoint or a debug patch exercised, I have a
bench that reproduces this on demand, roughly 250 associations per two
minutes, and I will run whatever you like.

Thomas