[PATCH] P2P: Ignore the DEAUTH event from cfg80211 incase of locally generated disconnect

[Jouni Malinen]

On Tue, May 28, 2013 at 07:11:03PM +0530, jithu Jance wrote:
> With the fast association enabled supplicant, I see an additional
> disassoc issue while doing a P2P/WPS connection. When EAP-FAILURE
> happens, the DEAUTH event from cfg80211 is received after supplicant has
> moved to ASSOCIATING state. 

It looks like this is handled with mac80211-based drivers (or well,
anything where wpa_supplicant SME is used) since
sme_disassoc_while_authenticating() allows the new connection attempt to
continue in such a case.

> The wpa_supplicant_deauthenticate function sends disconnect command down
> to the cfg80211/driver, generates the DEAUTH event locally and then
> starts the connect process. Since now the supplicant has fast
> association enabled, it moves to ASSOCIATING state pretty fast. Hence
> the DEAUTH event from cfg80211 stack (as a result of nl80211_disconnect)
> is received mostly after the supplicant has moved to ASSOCIATING state.
> This results in an ASSOCIATING -> DISCONNECTED state change
> unnecessarily. 
> 
> Is it safe to ignore this DEAUTH event since the
> wpa_supplicant_deathenticate function already generated a local DEAUTH
> event?

Yes and that is already done with some drivers.

> I have generated a patch adding an additional arg to
> wpa_drv_deauthenticate ignore the deauth event. I haven't changed the
> driver_* files other than driver_nl80211.c since I am not sure whether
> changing the wpa_driver_ops interface is the right way. If the changes
> are fine, I can generate a fresh patch including other driver_* files.

I would prefer to do this without changing the wpa_driver_ops API since
that type of changes are inconvenient for number of driver_*
implementations and different branches pulling in changes from
hostap.git.

If a wpa_driver_ops change is really needed, that should be a new
function that can either be used as a replacement for the old ones or
can be separately indicate to ignore the next disconnection event from
the current AP. Actually even better would be to just handle this
automatically within driver_nl80211.c. It should be clear there that
cfg80211 will send a disconnection event after disconnection request.
Such an event could be ignored if we have already started new connection
process. I did actually do something quite similar yesterday for FT:
http://w1.fi/gitweb/gitweb.cgi?p=hostap.git;a=commitdiff;h=add9b7a46a017d0fe3089247f98e5a67dbc250a5

-- 
Jouni Malinen                                            PGP id EFC895FA