[PATCH] Clear pmksa cache for deauth with reason code 2

[Yu, Xiaona]

Hi Chien,
Thanks, i understand what you said, per wifi standard IEEE 802.11 2020, Section 12.6.10.3, for this case, AP shall send assoc reject with status code 53.
But I found that some APs(not only one) always send deauth with reason code 2 for the first join after AP restart, the second join would send assoc reject with status code 53 and deauth with reason code 2.
We have experienced this issue with some APs, like ASUS TUF3600, ASUS-TUF-AX3000 V2, TP-LINK Archer-AX1800, TP-LINK Archer AXE75, BUFFALO WXR-5700AX7S/N, ...
What's interesting is Huawei B535-333, it would send Associate response with status code 0 then Disassociate with reason code 2 for this case.

In IEEE Std 802.11-2016, 9.4.1.7, Table 9-45, reason code 2 is INVALID_AUTHENTICATION, and means "Previous authentication no longer valid".
See this comment, looks like this response also makes sense, because the last authentication used was no longer valid.
We will keep this workaround in our codebase, it is also possible to make supplicant more robust and without side effects, such as missing assoc response but receiving deauth/disassoc.
Also will try to report this case to the AP vendor, thanks.

Thanks.

BR,
Xiaona Yu

-----Original Message-----
From: Chien Wong <m at xv97.com> 
Sent: Sunday, November 23, 2025 6:21 PM
To: Yu, Xiaona <yxiaona at amazon.com>
Cc: hostap at lists.infradead.org
Subject: RE: [EXTERNAL] [PATCH] Clear pmksa cache for deauth with reason code 2

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.



On Fri, 21 Nov 2025 15:27:28 +0800, Xiaona Yu wrote:
> In WPA3 connection, when receiving deauth with reason code 2, 
> wpa_supplicant should clear the PMKSA cache.
>
> but this PMKSA cache is invalid at this time, the AP will reject to 
> connect and send a deauth frame with reason code 2

Why? Any reference? The association rejection with status code
53(STATUS_INVALID_PMKID) is well defined behavior for AP notifying that it does not have the PMK. And this is what hostap/wpa_supplicant does. See IEEE 802.11 2020, Section 12.6.10.3. But for the mentioned deauth mechanism, where is it defined?

It sounds like you've encountered a buggy AP that does not properly implement SAE or PMK Caching.
Maybe it's best to report this issue to the AP vendor for them to fix, or just keep this workaround in your codebase?

Regards,
Chien Wong