[PATCH 03/18] wpa_supplicant: Don't stop conn. radio work on DEAUTH

[Jouni Malinen]

On Tue, Sep 06, 2016 at 09:47:35AM +0300, andrei.otcheretianski at intel.com wrote:
> If DEAUTH event is received while authenticating, wpas_connection_failed()
> is invoked cancelling the radio work. However, the flow might continue
> calling sme_disassoc_while_authenticating() which leaves the wpa_supplicant
> in the AUTHENTICATING state,  thus allowing the continuation of the connection
> flow (without radio work protection) in case AUTH frame is received.
> 
> This issue was seen during EAPOL connection, when the client starts the fast
> association in wpas_wps_eapol_cb, where the following race occurs:
> 
> 1. DEAUTH after initial EAPOL HS
> 2. Start fast associate and send AUTH
> 3. DEAUTH event rebound from kernel -> wpas_connection_failed() is called,
>    stopping the connect radio work
> 4. SCAN is started
> 5. AUTH is received, and the connection flow is continued without
>    radio work protection
> 6. SCAN_RESULTS received in the middle of association.
> 7. Failure in wpa_driver_nl80211_check_bss_status due to
>    state mismatch - > DEAUTH with reason code 2.

Would you be able to share a debug log showing such a case?

> Fix this by not calling wpas_connection_failed() in step 4, if the
> wpa_supplicant is in authenticating state and using SME (same conditions
> that result in calling sme_disassoc_while_authenticating()).

This does not sound correct.. sme-connect radio work should not be left
running if a new connection is needed. In addition, it looks like
wpa_supplicant_event_disassoc_finish() could call
wpa_supplicant_connect() after that and that would result in another
sme-connect radio work being added when trying to associate again.

It sound like step 5 might need to add a new sme-connect radio work
instead.

-- 
Jouni Malinen                                            PGP id EFC895FA