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

[Otcheretianski, Andrei]

> -----Original Message-----
> From: Jouni Malinen [mailto:j at w1.fi]
> Sent: Sunday, September 25, 2016 22:15
> To: Otcheretianski, Andrei <andrei.otcheretianski at intel.com>
> Cc: hostap at lists.infradead.org
> Subject: Re: [PATCH 03/18] wpa_supplicant: Don't stop conn. radio work on
> DEAUTH
> 
> 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?

Unfortunately I can't find the logs for this scenario now. This patch was sitting in our internal tree for quite a long period.
I'll try to reproduce, but I'm travelling now, so it can take some time.

> 
> > 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.

I don't think it's a new connection. After processing the DEAUTH we are left in  >= WPA_AUTHENTICATING state (by sme_disassoc_while_authenticating()). So it doesn't sound correct to not have a radio work at this state.

> 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.
> 

Since wpas is in AUTHENTICATING state, I think wpa_supplicant_connect() would just exit without doing anything.
Also, scheduling another radio work might introduce its own races, as it can be delayed by other activities that required the radio.

> It sound like step 5 might need to add a new sme-connect radio work
> instead.
> 
> --
> Jouni Malinen                                            PGP id EFC895FA