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

[Jouni Malinen]

On Tue, Nov 25, 2025 at 04:24:16PM +0000, Yu, Xiaona wrote:
> 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.

I've been a bit hesitant on adding this particular change since it could
result in undesired behavior through flushing of PMKSA cache entries for
all APs in the network based on a frame that is not protected. That
said, the cases based on more explicit indication using status code 53
in an Association Response frame are not really protected either.

I'll limit the scope of PMKSA cache flushing to apply only to the
current AP instead of the full ESS. This makes it somewhat easier to
accept this type of a workaround that is proposed in the patch here.

I would like to understand what exactly the APs are doing. Are you
saying that they actually accept the association first with an
Association Response frame status code 0 and then send a
Deauthentication frame with reason code 2? Or they do not reply to the
Association Request frame at all and instead, just sent that
Deauthentication frame?

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

As far as the protocol is concerned, the Open Authentication used before
association would remain valid even if the AP were to reject the
association due to not recognizing the PMKID that identifies the PMKSA
cache entry.

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

The patch here proposed the PMKSA cache entries to be flushed regardless
of when the disconnection happens as long as the association was
attempted to be started using PMKSA caching for SAE. At minimum, this
should be limited to cases where the PMKSA caching clearing failed,
i.e., this should not be done if a 4-way handshake has been completed
successfully. In addition, this flushing should be limited to a single
BSS (using the wpa_sm_pmksa_cache_flush_addr() function that I'm about
to add). With those changes, I might consider applying this to
hostap.git if it is clear that such misbehaving APs are still in use.

-- 
Jouni Malinen                                            PGP id EFC895FA