[PATCH hostap] AP: Send Deauthentication before removing STA on (Re)Assoc Resp ack=0

[Jouni Malinen]

On Fri, May 29, 2026 at 12:04:02PM +0530, Senthil Balasubramanian wrote:
> When the driver reports via TX status that the STA did not acknowledge
> the (Re)Association Response, handle_assoc_cb() calls
> hostapd_drv_sta_remove() without sending any over-the-air notification
> to the STA. This was a reasonable assumption when station and AP power
> budgets were close to symmetric: if the AP did not see the ACK, the STA
> most likely did not receive the Response either, so the STA would time
> out and re-authenticate within a short window.

I'm not actually sure that calling hostapd_drv_sta_remove() here is the
best behavior in all cases.. In particular, if there is already a
valid TK configured and the STA would be authorized and ready to use the
connection, the STA could be marked associated on reception of a
correctly encrypted Data frame.

> This assumption no longer holds on 6 GHz Low Power Indoor (LPI)
> deployments. There the STA EIRP is capped 6 dB below the AP EIRP by
> regulation (FCC and ETSI), and additional asymmetry comes from typical
> laptop/phone antenna gain being lower than the AP's MIMO antenna gain
> at the 6 GHz wavelength, and from STA PA back-off due to thermal and
> battery constraints. The net result is that the AP can reliably reach
> the STA while the STA's frames (including the L2 ACK following the AP's
> (Re)Assoc Response) routinely fall below the AP's effective noise
> floor.
> 
> In this scenario the STA decodes the (Re)Assoc Response and considers
> itself associated, while hostapd silently removes the station entry.
> The two sides remain out of sync until a STA-side timeout
> (implementation-defined, e.g. beacon-loss or null-frame failure)
> eventually fires. During that window the STA's unicast traffic is
> silently dropped at the AP, since there is no association table entry
> to map it to.

AP does not silently drop that traffic; it is sending out a
Deauthentication or Disassociation frame with reason code indicating
Class 3 frame received from not associated STA. That should trigger the
STA to try connection again.

> Address this by sending a Deauthentication frame
> (WLAN_REASON_PREV_AUTH_NOT_VALID) before hostapd_drv_sta_remove() in
> the !ok path of handle_assoc_cb(). The Deauthentication is transmitted
> at the basic rate with the usual MAC-level retries, which gives it a
> materially better chance of reaching the STA than the higher-rate
> (Re)Assoc Response that just failed.

What makes the Deauthentication frame use basic rates and the
(Re)Association Response frame use higher rates?

Why would this additional Deauthentication frame be needed if
Deauthentication frames are already sent as a response to any received
Data frame from that STA when it is not in associated state?

> If the STA never received the
> (Re)Assoc Response at all, the Deauthentication is benign because it
> is a Class 1 frame and does not tear down any association state on
> the STA side.


What do you mean with this being "benign" and not tearing down any
association state? Deauthentication frame is a notification for the
exact purpose of tearing down association (and also authentication)
state on the receiver..

-- 
Jouni Malinen                                            PGP id EFC895FA