bug in scanning logic?

[Chinchilla, Angie V]

Hi Jouni/others,

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)

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

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

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,
Angie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.shmoo.com/pipermail/hostap/attachments/20120211/9b79fd7d/attachment.htm