[PATCH] wpa_supplicant: Don't try and associate when already associating

Jouni Malinen jkmaline at cc.hut.fi
Sat Apr 29 21:04:07 EDT 2006

On Sat, Apr 29, 2006 at 02:59:16PM +0100, Daniel Drake wrote:

> softmac confuses wpa_supplicant with the following behaviour. This is 
> testing connectivity to an unencrypted network.

> softmac starts authenticating/associating to the requested network
> wpa_supplicant retrieves new scan results (GIWSCAN)
> wpa_supplicant finds desired AP and sets the essid (SIWESSID)
> softmac starts authenticating/associating to the requested network

Thanks for the detailed description.

> The attached patch makes wpa_supplicant not try to associate if it is 
> already in the associating state, which solves the bug.
> I guess the only downside is that if wpa_supplicant ever was to find a 
> 'better' access point from fresh scan results in the WPA_ASSOCIATING 
> state, it would not associate to the 'better' one until the next round 
> of scan results came in. We could extend the wpa_s structure and 
> implement some more advanced logic here - is there any point in doing so?

I think it is worth trying to do this. I committed a change which is
avoiding the new association request only if the selected BSSID differs
from the BSSID of the pending association. This should be enough to
avoid the race condition with SIWESSID and GIWSCAN triggering new
associations, but wpa_supplicant is still updating the AP selection if a
better candidate is available.

Jouni Malinen                                            PGP id EFC895FA

More information about the HostAP mailing list