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

Hi,

When an AP runs on a mac80211 SoftMAC driver, data frames sent by a
freshly associated station are acknowledged at the MAC layer but never
reach the network stack for ~130-170ms after the WPA2 4-way handshake
has completed. The same station against FullMAC APs shows no such gap.

Because the frames are hardware-ACKed, the station receives no
backpressure and TCP cannot detect the loss; a dropped SYN therefore
costs a full initial RTO (~1.3s) rather than a retransmit.


Test setup
----------

One station, five APs, measured one at a time, everything else held
constant: same SSID, same WPA2-PSK passphrase, channel 11, hw_mode=g,
ieee80211n=1, 20MHz, hostapd v2.10, AP bridged to the wired LAN. The
station associates, sends one short TCP request, disconnects and deep
sleeps, repeating about once per second, so every cycle is a fresh
association. 100-140 cycles per AP. No other stations associated.

  AP  radio                    driver              kernel
  --  -----------------------  ------------------  -----------------
  1   Espressif ESP32 softAP   vendor stack        (ESP-IDF v5.5.5)
  2   MediaTek MT7986          mt76      SoftMAC   6.12.51
  3   Broadcom CYW43455        brcmfmac  FullMAC   6.18.39
  4   Atheros AR9271 (USB)     ath9k_htc SoftMAC   6.18.39
  5   Atheros AR958x           ath9k     SoftMAC   excluded, see below

Station: ESP32-C5, ESP-IDF v5.5.5.

APs 3 and 4 are the *same machine, same kernel, same hostapd binary,
same bridge, same channel*, differing only in radio and driver.


Results
-------

"attempts" is the number of TCP connect() attempts the station needed
before one succeeded; it retries every 30ms. Time is the median from
association to a completed TCP handshake.

  AP  driver              n    attempts   assoc->connected
  --  ------------------  ---  --------   ----------------
  1   vendor (FullMAC)    132     1.00           2.7 ms
  3   brcmfmac (FullMAC)  140     1.01           4.8 ms
  4   ath9k_htc (SoftMAC) 105     5.04         134   ms
  2   mt76 (SoftMAC)      118     6.19         168   ms

Association itself is 23-30ms on all four; the entire difference is in
how long the AP takes to start passing the station's data frames.


Air trace
---------

Captured with a separate monitor-mode radio (AR9271 on an unrelated
host), against AP2. Times relative to the station's Assoc Request:

    +0.0 ms   ASSOC-REQ    from STA
    +3.2 ms   ASSOC-RESP   to STA
    +7.8 ms   EAPOL        from STA      (4-way)
   +12.5 ms   EAPOL        from STA
   +15.1 ms   DATA (enc)   from STA      <- ACKed by AP
   +45.2 ms   DATA (enc)   from STA      <- ACKed
   +76 / +105 / +135 / +165 ms           <- ACKed (BlockAck)
  +178.1 ms   DATA (enc)   to STA        <- first downlink; SYN-ACK

Every one of those uplink data frames is acknowledged. None of them
appears on the AP's netdev: tcpdump on the AP interface sees no TCP SYN
until roughly the +165ms frame.

Corresponding hostapd -dd output for the same association:

  .697155  AP-STA-CONNECTED
  .697237  nl80211: Set STA flags ... flags_or=0x1
  .698663  IEEE 802.1X: authorizing port
  .698795  WPA: pairwise key handshake completed (RSN)
  .698816  EAPOL-4WAY-HS-COMPLETED

The port is authorized 0.2ms before the handshake-complete line, so
hostapd is not the one holding the frames back. Association to
EAPOL-4WAY-HS-COMPLETED is a median of 70.7ms (n=229).

There is no group-key handshake in these logs, and the behaviour is
unchanged with RADIUS accounting absent from the configuration.


Why this looks like mac80211 rather than one driver
---------------------------------------------------

Two SoftMAC drivers from unrelated vendors (ath9k_htc, mt76) both show
it; two FullMAC/firmware-offloaded stacks (brcmfmac, Espressif) both do
not. The AP3/AP4 pair isolates this to the radio and driver with
everything else identical.

That suggests the pairwise key becomes usable for RX some time after
hostapd authorizes the controlled port, rather than atomically with it.
I have not instrumented the kernel, so the split above is inference
from black-box behaviour, not from code inspection - happy to run
whatever tracing would settle it.


Anticipated objection
---------------------

The station does transmit its first data frame ~3ms after sending EAPOL
4/4, i.e. before the AP has finished installing the key. That is legal,
and more importantly the AP acknowledges those frames, so the station
has no way to learn they were discarded. FullMAC APs carry the very
same frames from the very same station without loss.


AP5 excluded
------------

The AR958x card came up in regulatory domain 00 advertising 30 dBm;
"iw reg set DE" corrected it to 20 dBm. Even then, association and the
4-way handshake succeed while no data frame ever reaches the netdev, so
that card looks miscalibrated and is not reported as a data point.


Reproducing
-----------

Any station that sends immediately on association will show it. The
metric that makes it obvious is "TCP connect attempts before success"
with a short (20-40ms) per-attempt timeout; with a normal blocking
connect it is masked as a single ~1.3s stall, which is how it went
unnoticed here for a long time.

Happy to provide pcaps, full hostapd -dd logs, or to test patches.

I am not subscribed to the list; please keep me on Cc for replies.

Thanks,
Thomas Hilber