[PATCH 2/2] WPA: disassociate client on invalid EAP-Key state

[Derrick Pallas]

A previous commit addressed broken supplicants in Disassociation loops by
destroying PMKSAs when receiving a spurious EAPOL-Start.  After that change,
the STA recovers and Associates after a full EAP.  The Disassociation does
not happen until after multiple EAP-Identity requests are ignored by the
STA, which takes more than a minute.

This change shortens that recovery time to a few seconds by proactively
Disassociating the STA when it receiving EAPOL-Key 2/4 or 4/4 in an invalid
state.  The supplicants we've seen with this bad behavior have only broken
sporadically when waking up, so a few seconds is reasonable.  Consequently,
the core issue has been dubbed Groggy Supplicant Syndrome.

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 8110cd7..39fbf6c 100644
--- a/src/ap/wpa_auth.c
+++ b/src/ap/wpa_auth.c
@@ -1174,6 +1174,7 @@ continue_processing:
 					 "received EAPOL-Key msg 4/4 in "
 					 "invalid state (%d) - dropped",
 					 sm->wpa_ptk_state);
+			wpa_sta_disconnect(wpa_auth, sm->addr);
 			return;
 		}
 		break;
@@ -1184,6 +1185,7 @@ continue_processing:
 					 "received EAPOL-Key msg 2/2 in "
 					 "invalid state (%d) - dropped",
 					 sm->wpa_ptk_group_state);
+			wpa_sta_disconnect(wpa_auth, sm->addr);
 			return;
 		}
 		break;
-- 
2.10.2