| Message ID | 20240903000009.632642-1-james.herbert@morsemicro.com |
|---|---|
| State | Changes Requested |
| 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
On Sun, Sep 15, 2024 at 08:43:20AM +0000, Otcheretianski, Andrei wrote: > > 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. As far as the question about use of SA Query procedure is concerned, a non-AP STA can initiate SA Query procedure for any reason at any point in time in an association where PMF has been negotiated, so there is not really any issue with the proposed patch from that view point. It might make sense to accept unprotected Deauthentication and Disassociation frames at the beginning of an association if no protected frame has been received from the AP yet. There might not be a convenient mechanism for determining that detail at the moment, but that would be kind of nice information to make available in the kernel interface.. Already available information for this could be the combination of the M4 not being reported as having been ACKed and only a small period of time having been passed from the STA having transmitted it.
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(-)