[PATCH] wpa_supplicant: Honor initial bgscan timer

[Jouni Malinen]

On Thu, Aug 19, 2010 at 08:46:34AM -0700, Paul Stewart wrote:
>     Honor the interval setup in bgscan_simple_init even if we
>     get notified of a signal change.  This prevents the system
>     from doing a bgscan too early after connecting to a network
>     (for example, during DHCP)

What is the actual problem that this tries to address? While background
scan should not really be needed immediately after association in most
cases, it should not really break anything; if it does, the real issue
needs to be understood and fixed.

This change may be a suitable workaround for some cases, but I would
like to understand what the real problem is since there may also be
cases where the bgscan is indeed for a good reason and we should try to
roam instead of hang on trying to complete DHCP through the current AP.

Is the signal change event that you are observing valid? I.e., does it
actually correctly indicate that the signal strength dropped below the
configured threshold? If not, we should rather fix mac80211 not to
generate that event in this case. If the real signal strength is below
the configured threshold, it could be better to make wpa_supplicant
understand that as a special case where the initial signal change event
is skipped. That may be more suitable to be done in driver_nl80211.c,
though, as a special filter for events so that upper layer code will
only get events when the signal strength is indeed changing (or
potentially in mac80211; I haven't checked how exactly this event is
documented or expected to behave at the moment the threshold is set
initially).

If background scanning during authentication and/or DHCP exchange is
causing problems, I would like to see a wireless capture log showing the
frames exchanged between the AP and the client. This should not cause
any packets to be dropped and the only visible effect should be in the
exchange potentially taking some more time due to the extra latency
caused by scanning on other channels. If something goes wrong here, it
should be fixed and if the latency is enough to cause problems for DHCP
(or EAP or 4-way handshake), a better solution would probably be to
modify the background scanning implementation to avoid doing scans
during such operations, if possible. The exact same issue would show up
with any other scan trigger than wpa_supplicant bgscan..

-- 
Jouni Malinen                                            PGP id EFC895FA