| Message ID | 20240903000009.632642-1-james.herbert@morsemicro.com |
|---|---|
| State | New |
| Headers | show |
| Series | Use SA Query for 4-way handshake timeout | expand |
> When an AP fails to receive message 4 of the 4-way handshake, the station > has completed association but the AP has not. The AP sends an unprotected > deauth frame to the station with a reason code of > WLAN_REASON_4WAY_HANDSHAKE_TIMEOUT, > but the station's WPA state is WPA_COMPLETED so it ignores unprotected > deauth frames that do not have a reason code of > WLAN_REASON_CLASS2_FRAME_FROM_NONAUTH_STA or > WLAN_REASON_CLASS3_FRAME_FROM_NONAUTH_STA. The station > becomes stuck in an invalid state. > > Add WLAN_REASON_4WAY_HANDSHAKE_TIMEOUT to the list of reason > codes for deauth frames that can be verified by using SA Query. > This violates the spec. Please refer to chapter "11.13 SA Query procedures" in IEEE P802.11-REVme(tm)/D5.0. "[..]If a non-AP and non-PCP STA that has an SA with its AP or PCP for an association that negotiated management frame protection receives an (#2128)individually addressed unprotected Deauthentication or Disassociation frame with reason code INVALID_CLASS2_FRAME or INVALID_CLASS3_FRAME from the AP or PCP, the non-AP and non-PCP STA may use this as an indication that there might be a mismatch in the association state between itself and the AP or PCP. In such a case, the non-AP and non-PCP STA's SME may initiate the SA Query procedure with the AP or PCP to verify the validity of the SA by issuing one MLME-SA-QUERY.request primitive every dot11AssociationSAQueryRetryTimeout TUs until a matching MLME-SA-QUERY.confirm primitive is received or dot11AssociationSAQueryMaximumTimeout TUs from the beginning of the SA Query procedure has passed [...]" Andrei
Andrei Otcheretianski, Our interpretation of "11.13 SA Query procedures" in IEEE P802.11-REVme(tm)/D5.0 is that a STA may use SA Query in response to an unprotected Deauthentication or Disassociation frame with reason code INVALID_CLASS2_FRAME or INVALID_CLASS3_FRAME, but other uses where there might be a mismatch in the association state between itself and the AP or PCP are not precluded. Is that not the case? If it is not, how would you propose to resolve this condition? --- wpa_supplicant/sme.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/wpa_supplicant/sme.c b/wpa_supplicant/sme.c index 9b083cddd..6a335b5cb 100644 --- a/wpa_supplicant/sme.c +++ b/wpa_supplicant/sme.c @@ -3497,7 +3497,8 @@ void sme_event_unprot_disconnect(struct wpa_supplicant *wpa_s, const u8 *sa, if (!ether_addr_equal(sa, wpa_s->bssid)) return; if (reason_code != WLAN_REASON_CLASS2_FRAME_FROM_NONAUTH_STA && - reason_code != WLAN_REASON_CLASS3_FRAME_FROM_NONASSOC_STA) + reason_code != WLAN_REASON_CLASS3_FRAME_FROM_NONASSOC_STA && + reason_code != WLAN_REASON_4WAY_HANDSHAKE_TIMEOUT) return; if (wpa_s->sme.sa_query_count > 0) return;
> > Is that not the case? If it is not, how would you propose to resolve this > condition? > I think if the STA didn't get an ACK for M4 (or any other message) it should handle this by properly maintaining its internal state, rather than relying on some specific reason code from the AP, as different AP's may behave differently. Andrei
diff --git a/wpa_supplicant/sme.c b/wpa_supplicant/sme.c index 9b083cddd..6a335b5cb 100644 --- a/wpa_supplicant/sme.c +++ b/wpa_supplicant/sme.c @@ -3497,7 +3497,8 @@ void sme_event_unprot_disconnect(struct wpa_supplicant *wpa_s, const u8 *sa, if (!ether_addr_equal(sa, wpa_s->bssid)) return; if (reason_code != WLAN_REASON_CLASS2_FRAME_FROM_NONAUTH_STA && - reason_code != WLAN_REASON_CLASS3_FRAME_FROM_NONASSOC_STA) + reason_code != WLAN_REASON_CLASS3_FRAME_FROM_NONASSOC_STA && + reason_code != WLAN_REASON_4WAY_HANDSHAKE_TIMEOUT) return; if (wpa_s->sme.sa_query_count > 0) return;
When an AP fails to receive message 4 of the 4-way handshake, the station has completed association but the AP has not. The AP sends an unprotected deauth frame to the station with a reason code of WLAN_REASON_4WAY_HANDSHAKE_TIMEOUT, but the station's WPA state is WPA_COMPLETED so it ignores unprotected deauth frames that do not have a reason code of WLAN_REASON_CLASS2_FRAME_FROM_NONAUTH_STA or WLAN_REASON_CLASS3_FRAME_FROM_NONAUTH_STA. The station becomes stuck in an invalid state. Add WLAN_REASON_4WAY_HANDSHAKE_TIMEOUT to the list of reason codes for deauth frames that can be verified by using SA Query. Signed-off-by: James Herbert <james.herbert@morsemicro.com> --- wpa_supplicant/sme.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)