CHROMIUMOS: wpa_supplicant: Honor initial bgscan timer

CHROMIUMOS: wpa_supplicant: Honor initial bgscan timer

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)

TEST=Rerun repeatedly on Google-A, etc for 3 days
BUG=chromium-os:5458

[Sam Leffler, 2010-08-07 18:53:07]

Not sure this is a good solution to the problem.  If the signal of the selected
AP is so low that we immediately trigger a scan to look for something better
then we might've been better off scanning a bit longer before joining this bss. 
Also this event may indicate our low signal threshold is too low and we should
fix/improve that (I've said before I think it must be relative to the noise
floor and not a fixed value as it is now).  Finally bgscan should not interrupt
normal communication so if it does then that's the root cause and changing the
initial scan interval just means we'll join the wrong bss and dwelling there
longer than we should.

Are we missing a better bss in our scans?  Is the signal threshold too low?  I
think we know the mac80211/ath9k bgscan implementation is busted.

[Paul Stewart, 2010-08-07 23:55:08]

Excellent points, Sam.  What I observed is a call to notify_signal_change with
an "above" value of 0, which appears to be some sort of upstream signal from
MLME which may not be correct.  I could trace it backwards through
nl80211_cqm_event(), but assumed that it would be okay to have a short period of
time shortly after the COMPLETED state where we weren't so jumpy.

On 2010/08/07 18:53:07, Sam Leffler wrote:
> Not sure this is a good solution to the problem.  If the signal of the
selected
> AP is so low that we immediately trigger a scan to look for something better
> then we might've been better off scanning a bit longer before joining this
bss. 
> Also this event may indicate our low signal threshold is too low and we should
> fix/improve that (I've said before I think it must be relative to the noise
> floor and not a fixed value as it is now).  Finally bgscan should not
interrupt
> normal communication so if it does then that's the root cause and changing the
> initial scan interval just means we'll join the wrong bss and dwelling there
> longer than we should.
> 
> Are we missing a better bss in our scans?  Is the signal threshold too low?  I
> think we know the mac80211/ath9k bgscan implementation is busted.

[Sam Leffler, 2010-08-08 01:50:28]

Your change may just defer the inevitable and force the station to hang out
on the channel longer than it should.  I'm curious what the scan results
show for the scan used to join the bss and the subsequent bgscan (I've got
logs from my SF studies that show the same behaviour and can check them).
 Also we need to understand why the dhcp packets are lost as this is
fundamental breakage.  The dhcp replies should be unicast so buffered by the
ap and retrieved by the station when it returns to the bss channel.

-Sam

On Sat, Aug 7, 2010 at 4:55 PM, <pstew@chromium.org> wrote:

> Excellent points, Sam.  What I observed is a call to notify_signal_change
> with
> an "above" value of 0, which appears to be some sort of upstream signal
> from
> MLME which may not be correct.  I could trace it backwards through
> nl80211_cqm_event(), but assumed that it would be okay to have a short
> period of
> time shortly after the COMPLETED state where we weren't so jumpy.
>
>
> On 2010/08/07 18:53:07, Sam Leffler wrote:
>
>> Not sure this is a good solution to the problem.  If the signal of the
>>
> selected
>
>> AP is so low that we immediately trigger a scan to look for something
>> better
>> then we might've been better off scanning a bit longer before joining this
>>
> bss.
>
>> Also this event may indicate our low signal threshold is too low and we
>> should
>> fix/improve that (I've said before I think it must be relative to the
>> noise
>> floor and not a fixed value as it is now).  Finally bgscan should not
>>
> interrupt
>
>> normal communication so if it does then that's the root cause and changing
>> the
>> initial scan interval just means we'll join the wrong bss and dwelling
>> there
>> longer than we should.
>>
>
>  Are we missing a better bss in our scans?  Is the signal threshold too
>> low?  I
>> think we know the mac80211/ath9k bgscan implementation is busted.
>>
>
>
>
> http://codereview.chromium.org/3020075/show
>

[Sam Leffler, 2010-08-09 22:41:59]

per-private discussion we'll apply this band-aid now while we work on the
underlying issues

[Paul Stewart, 2010-08-12 17:11:12]

Does this imply ell gee tee em?

On 2010/08/09 22:41:59, Sam Leffler wrote:
> per-private discussion we'll apply this band-aid now while we work on the
> underlying issues

[Sam Leffler, 2010-08-12 17:13:20]

Sorry, yes.  LGTM

On Thu, Aug 12, 2010 at 10:11 AM, <pstew@chromium.org> wrote:

> Does this imply ell gee tee em?
>
>
> On 2010/08/09 22:41:59, Sam Leffler wrote:
>
>> per-private discussion we'll apply this band-aid now while we work on the
>> underlying issues
>>
>
>
>
> http://codereview.chromium.org/3020075/show
>