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

[senthil.balasubramanian at netgear.com]

Thanks for your review, Jouni — you've caught two over-claims in the
commit message that I need to walk back, and raised one architectural
alternative worth considering. Responses inline.

On Fri, May 29, 2026 at 06:48:58AM -0700, Jouni Malinen wrote:
> 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.

Fair point — but two things would need to be true for the "promote on
encrypted Data" recovery to actually rescue the STA in the case we
observed:

  (i)  hostapd would need code that doesn't exist today — a path that
       re-promotes a STA to WLAN_STA_ASSOC on successful decrypt of a
       Data frame after the (Re)Association tracking has given up.
       In the current code, hostapd_drv_sta_remove() has already been
       called by the time any subsequent Data frame would arrive, so
       there is no per-STA crypto context left in the driver and the
       frame is dropped before any "promote" logic could see it.

  (ii) the STA->AP uplink would need to deliver that Data frame.  In
       the observed case the uplink is exactly the side that failed —
       that is what produced ack=0 in the first place.  Every
       subsequent STA->AP frame shares the same uplink budget (FCC
       LPI client EIRP capped at AP EIRP - 6 dB on 6 GHz, plus
       smaller STA antenna at 6 GHz wavelength, plus STA PA back-off
       for thermal/battery reasons), so the AP very often does not
       receive an encrypted Data frame from the STA either, and the
       trigger for any "promote" path never arrives.

The AP->STA direction is the one that still works in this RF
asymmetry — that's exactly what made the STA decode the (Re)Assoc
Response we then failed to get ACKed.  So an AP-initiated
Deauthentication has a real chance of reaching the STA; a
STA-initiated "prove I'm alive" frame does not.

The case we hit is a 5 GHz -> 6 GHz FT-SAE roam, so PTK derivation
completed during the FT Authentication exchange and TK was installed
on both sides before the (Re)Association Request was even sent — so
the "TK already valid" precondition you mention holds.  But the
uplink-asymmetry argument above is what makes the encrypted-Data
recovery path unhelpful here even if it existed.

> 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.

Correct — I should not have written "silently dropped".  When the AP
does receive a Class 3 frame from a STA without an association entry,
it sends Deauthentication and the STA recovers. That mechanism is what
makes the existing sta_remove path tolerable in the symmetric-link case.

The reason it does not help in the asymmetric-link case is the same as
above:  the AP never receives the triggering Class 3 frame, because
the STA's uplink is the side that's failing.  So the Class-3-response
Deauthentication is never generated and the desync persists.

I'll reword that paragraph to:  "On a symmetric link the AP's existing
Class-3-frame response would deauthenticate the STA on its first data
frame and the STA would recover.  On the asymmetric path described
above, the AP does not receive that data frame, so the Class-3
response never fires."

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

My commit log in this place is sloppy and I'll drop it.

The honest argument for the patch is simpler:

  - The Class-3 recovery does not fire on an asymmetric path, because
    the AP receives no frame from the STA to respond to.
  - The AP->STA direction still works — the STA decoded the
    (Re)Assoc Response just fine; only the L2 ACK failed.
  - One AP-initiated Deauthentication is much more likely to reach
    the STA than waiting indefinitely for an STA->AP frame that the
    AP cannot receive.

> 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?

Same answer:  in the asymmetric case the AP does not receive the
triggering Data frame, so no response Deauth is generated.  In the
symmetric case this patch is largely a no-op — the explicit Deauth
and the Class-3-response Deauth would both put the STA back to
state 1; the second one is redundant but not harmful (except additional
airtime for the deauth frame) since the STA is already moving to
unauthenticated state.

> What do you mean with this being "benign" and not tearing down any
> association state?

That wording was wrong — Deauthentication is by definition a teardown
of both authentication and association state on the receiver.

What I meant was:  in the case where the STA never received the
(Re)Association Response, the STA is still in its prior state
(post-Authentication, not yet associated).  The Deauthentication
takes that STA back to unauthenticated. So the Deauthentication does
not regress anything; it just makes the STA's recovery deterministic
instead of waiting on a timeout.

I'll reword to:  "If the STA never received the (Re)Association
Response (or) AP couldn't hear the ACK for Re-Assoc response that it
has sent, the Deauthentication takes the STA from its post-
Authentication state back to unauthenticated.  This is the same end
state the STA would have reached anyway after timing out its
(Re)Association attempt; the Deauthentication just gets it there
faster."

Happy to spin v2 with the commit-message fixes if that's acceptable, or
take a different approach if you prefer.

Thanks again for the review and great to talk to you after Atheros/QCA days.

--
Senthil Balasubramanian
This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately.