On Tue, Sep 06, 2016 at 09:47:35AM +0300, andrei.otcheretianski@xxxxxxxxx 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 _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
