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

[Thomas Hilber <thomas.hilber@enxio.de>]

On Sun, 2026-08-30 at 12:00 -0700, Devin Wittmayer wrote:
> Worth a look in your own captures: the starting sequence number in the
> request against the sequence number of the first frame after it.

Done, and it does not hold here. The window is filled correctly and my
stall happens anyway.

First, in case it is useful to anyone: I have only the one radio, and it
is the access point under test. It turns out ath9k_htc will give you a
monitor interface on the same phy while hostapd is running on it:

  iw dev wlan1 interface add mon0 type monitor

No second radio needed. (Use "iw dev <dev>", not "iw phy phyN" - rmmod
plus modprobe renumbers the phy, which cost me a run.)

Air capture and the AP's netdev, captured together, so the sequence
numbers and the stall are measured on the same associations:

                        station side          TID 0     SSN      seq==SSN
                                            sessions  declared   arrived
  nohwcrypt=0    5.36 attempts, 134.9 ms       259     0 in all   256/259
  nohwcrypt=1    1.01 attempts,   3.8 ms       348     0 in all   345/348

n=249 and n=342 cycles respectively. Of the 256 arrivals under hardware
crypto, 237 were fresh transmissions rather than retries.

So on this hardware the reorder window opens on zero, zero arrives, and
the 134.9 ms is still there. Whatever holds my frames, it is not a slot
that can never be filled.

One thing that did reproduce your signature, and then disqualified
itself. My station opens three sessions per association, TIDs 0, 5 and 7.
TID 0 carries the traffic. TID 7 declares SSN=2, the first frame to
arrive under it is seq 0, and the declared SSN never arrives in about 97%
of sessions - exactly what you describe. But it is 251/259 under hardware
crypto and 340/348 under software crypto: the same mismatch, at the same
rate, in the arm that has no stall at all. So the pattern is real here
and simply does not track the symptom.

I would not lean on my TID 7 numbers anyway. It carries 538 frames
against 3116 on TID 0, and if my station keeps one sequence counter
across TIDs rather than one per TID, a per-TID comparison there is
meaningless. TID 0 is the measurement I trust.

I also timed the first frame of each cycle from the air to the AP's
netdev: 22.2 ms median with hardware crypto against 2.4 ms with
software. The right direction, but an order of magnitude short of the
135 ms, so the frames are not simply being held for the whole window
either.

Which leaves the two of us with different mechanisms producing timings
that look alike. Mine responds to one module parameter and does not
involve a reorder hole; yours involves a reorder hole on a part that has
no such parameter to test. It may be that a missing first frame is
sufficient but not necessary, and that hardware key install can also
stall delivery some other way.

If your MT7922 will hand you a monitor interface on its own phy the way
ath9k_htc does, the cheap check on your side is whether your slow cycles
survive a session where the declared SSN *does* arrive. If they do, we
are looking at one mechanism with two symptoms; if they never do, we
have two.

Captures available if anyone wants them.

Thomas