AP drops STA data frames for ~130-170ms after 4-way handshake
Devin Wittmayer
lucid_duck at justthetip.ca
Sun Aug 30 12:00:28 PDT 2026
On Sun, 2026-08-30 at 12:42 +0200, Thomas Hilber wrote:
> It goes with it, and it takes the whole effect with it.
Thanks for running that. Six of 216 against 292 of 302 does not need
arguing.
I have it on an MT7922 built to your AP2 spec: 27 of 95 associations hold
134 to 189 ms after the handshake, which is your 130 to 170.
They are held, not dropped. On a slow cycle my station's attempts go out
every 5 ms for 150 ms and none of them reaches the access point's
interface, until fourteen arrive within sixteen microseconds of each other
and every one is answered. Across the capture the station retransmitted
three of 110, so they were arriving all along.
A monitor radio says why. Over twenty-five associations, every request to
open a block acknowledgement session declared a starting sequence number
of zero, and zero never arrived under any of them: the first frame after
the request was one, two, three or seven. In fourteen of them the station
had already sent zero before it asked for the session.
So the reorder window opens on a sequence the station will not send. The
first slot can never be filled, everything queues behind it, and the
release timer is what eventually lets go.
Worth a look in your own captures: the starting sequence number in the
request against the sequence number of the first frame after it.
Devin
More information about the Linux-mediatek
mailing list