bug in scanning logic?

Jouni Malinen j at w1.fi
Sun Feb 12 07:05:44 EST 2012


On Sat, Feb 11, 2012 at 01:08:09AM +0000, Chinchilla, Angie V wrote:
> Looking for some input here... I'm trying to figure out a scanning issue. I'm trying to figure out why a full scan happens just before a P2P client connects to a P2P GO, after WPS-SUCCESS.
> 
> Looking at the code I can see there is a variable wpa_s->wps_freq that looks like maybe it was intended to catch this situation and handle it with just a scan on that frequency, in the function wpa_supplicant_optimize_freqs(). (~line 336 in scan.c)

Yes, wps_freq was indeed an optimization for post-WPS scan

> Unfortunately, as far as I can tell, wps_freq will never be set to a value other than 0 for this code path.

It used to be in 2010.. ;-)

> wpas_wps_eapol_cb() sets wps_freq, by setting it to wpa_s->assoc_freq. (wpa_supplicant.c, ~line 90)
> 
> Unfortunately, wpas_wps_eapol_cb() resets wpa_s->assoc_freq to 0 just before that, in the code path:
> 
> wpas_wps_eapol_cb()(wpa_supplicant.c, ~line 82)
> calls wpa_supplicant_deauthenticate()
> calls wpa_supplicant_clear_connection()
> calls wpa_supplicant_mark_disassoc()
> which sets wpa_s->assoc_freq=0

This is an old regression from late 2010.. wpa_s->assoc_freq was not
cleared in wpa_supplicant_mark_disassoc() when the post-WPS scan
optimization was added.

It's a pity that there is still no automated testbed for finding this
type of issues more quickly taken into account how much effort I put in
optimizing the P2P connection times.. When I last looked at the
connection times, we were still having issues with mac80211 dropping the
first EAPOL frame in the association and that resulted in five second
extra time. That was pretty effective in hiding this scanning
regression.

> Can we just move "wpa_s->wps_freq  = wpa_s->assoc_freq;" above wpa_supplicant_deauthenticate() in this case? (so, to line 90, for example).
> 
> I can also write a patch that does that but this seemed to need more words than a simple patch could provide... the real question I guess is how was this intended to work and would such a fix cause it to work properly?

Thanks for finding and reporting this! It's a bit safer not to set
wpa_s->wps_freq before the possible return statement, so I fixed this by
using a local copy of assoc_freq. This brings back the join-a-group case
from 2.6 seconds to 0.7 seconds in a mac80211_hwsim test.

-- 
Jouni Malinen                                            PGP id EFC895FA


More information about the HostAP mailing list