[PATCH 1/2] SME: Fall back from PMKSA caching if the AP rejects it with deauthentication

[Louis Kotze]

On Tue, Jul 28, 2026 at 12:33:58PM +0300, Jouni Malinen wrote:
> That's quite unfortunate AP behavior. Reason code 9 is completely
> incorrect in this case since there is an authentication from the Open
> System authentication exchange that happens just before this association
> attempt. Is that AP not sending Association Response frame at all? If
> so, it feels like it is just not moving the STA into authenticated state
> based on the (admittedly pointless) Authentication frame exchange for
> the PMKSA caching case with SAE.

No Association Response frame at all. From one of the captures, with the
timestamps relative to the Authentication frame exchange completing:

  +0.000000  wlan0: SME: Authentication response: peer=ec:75:0c:74:4b:77
             auth_type=0 auth_transaction=2 status_code=0
  +0.000310  nl80211: Association request sent successfully
  +0.031022  nl80211: Drv Event 20 (NL80211_CMD_DEL_STATION)
  +0.592647  nl80211: Drv Event 39 (NL80211_CMD_DEAUTHENTICATE)
             wlan0:  * reason 9 (STA_REQ_ASSOC_WITHOUT_AUTH)

The Open System exchange completes with status code 0, nothing comes back
for the Association Request frame, and the deauthentication arrives 0.6
seconds later. That matches your reading.

> Are there any known deployed APs using a different reason code value or
> could this be made applicable only with that value 9?

I only have this one AP, so I cannot say anything about other
deployments. In my captures it is reason code 9 every time: 26
deauthentications from the AP, all reason code 9, all received in
WPA_ASSOCIATING. The only other reason codes in those logs are seven
locally generated reason 3 and a single reason 1 received in
WPA_ASSOCIATED, neither of which is this sequence.

Restricted to reason code 9 in v3.

> Why does this include WPA_AUTHENTICATING state? I would like to do this
> only for the known sequence of (Re)Association Request frame getting
> rejected with a Deauthentication frame using reason code 9.

No good reason, it was defensive. Removed in v3, so only WPA_ASSOCIATING
matches.

> That aa == NULL case must not be included since that would flush PMKSA
> cache entries for all BSSs in the ESS based on a single unprotected
> frame from one AP.

Agreed. v3 returns without touching the cache when the address is not
known.

That fallback came from sme_event_assoc_reject(), which still has it. The
trigger there is an Association Response frame rather than an unprotected
Deauthentication frame, so it is a weaker case, but let me know if you
want a patch for it.

v2 crossed with this review and carried the same code as v1, sorry about
the noise. v3 follows with the changes above.

Thanks,
Louis