[PATCH] Use SA Query for 4-way handshake timeout

[Otcheretianski, Andrei]

> 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