[PATCH 1/2] WPA: destroy PMKSA entry when clearing due to EAPOL-Start

[Derrick Pallas]

Specifically, we see the following interaction:

	Reassociation Request ->
	                      <- Reassociation Response
	                      <- EAPOL-Key 1/4
	        EAPOL-Key 2/4 ->
	          EAPOL-Start ->
	                      <- EAPOL-Key 3/4
	        EAPOL-Key 4/4 ->
	          EAPOL-Start ->
	                      <- EAP-Identity Request
	                      <- EAP-Identity Request
	                      <- EAP-Identity Request
	                      <- EAP-Identity Request
	                      <- EAP-Identity Request
	                      <- EAP-Identity Request
	                      <- Disassociate

By the time we process the spurious EAPOL-Start, we have already processed
2/4 and queued 3/4.  The client responds but we receive 4/4 in an invalid
state and the client refuses to respond to EAP-Identity.

We have seen clients that enter this state, eventually disassociate, but
retry only to enter this state again.  Instead, actually destroy the PMKSA
so that on the next association attempt the broken supplicant has a cleaner
slate.  A future commit will address the unnecessary EAP-Identity Requests
prior to Disassociation.

The supplicants we've seen with this bad behavior have only broken
sporadically when waking up and the core issue has been dubbed Groggy
Supplicant Syndrome.

Thanks to Jenny Lin, Abhinav Acharya, & Eric Maassmann for helping debug
this.

Signed-off-by: Derrick Pallas <pallas at meraki.com>
---
 src/ap/wpa_auth.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/ap/wpa_auth.c b/src/ap/wpa_auth.c
index 863ae83..8110cd7 100644
--- a/src/ap/wpa_auth.c
+++ b/src/ap/wpa_auth.c
@@ -3927,6 +3927,8 @@ int wpa_auth_sta_clear_pmksa(struct wpa_state_machine *sm,
 {
 	if (sm == NULL || sm->pmksa != entry)
 		return -1;
+	if (sm->wpa_auth->pmksa)
+		pmksa_cache_free_entry(sm->wpa_auth->pmksa, sm->pmksa);
 	sm->pmksa = NULL;
 	return 0;
 }
-- 
2.10.2