Problems running ath with bgscan enabled

[Sam Leffler]

Kevin Oberman wrote:
>> Date: Sun, 21 Oct 2007 19:38:56 -0700
>> From: Sam Leffler <sam at errno.com>
>> Sender: owner-freebsd-mobile at freebsd.org
>>
>> AT Matik wrote:
>>     
>>> On Saturday 20 October 2007 22:30:32 Kevin Oberman wrote:
>>>   
>>>       
>>>> My bgscan interval was the default 300 and almost every 5 minutes I
>>>> would lose connectivity, often for over a minute. When I made the
>>>> association between the bgscan interval and the drop-outs, I did an
>>>> "ifconfig ath0 -bgscan" and things stabilized immediately. No further
>>>> problems.
>>>>
>>>> ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413)
>>>> ath0: <Atheros 5212> mem 0xb4000000-0xb400ffff irq 11 at device 2.0 on
>>>> pci11 ath0: mac 5.9 phy 4.3 radio 3.6
>>>>
>>>> This is really not acceptable for default behavior as it won't be clear
>>>> to many how to fix it. Is it expected or is something wrong?
>>>>
>>>>     
>>>>         
>>> I believe it is so but as you already did, when you like to associate only to 
>>> the AP of your wpa config you should set -bgscan and eventually 'roaming 
>>> manual' also, if I am not wrong this is described in ifconfig's manpage
>>>
>>>   
>>>       
>> wpa_supplicant works fine w/ bgscan.  When the bgscan's complete 
>> wpa_supplicant receives an event and retrieves the scan results.  It 
>> then decides whether or not to roam.  There is no need to manually 
>> configure the device.
>>
>> OTOH the scanning+roaming code in wpa_supplicant is very simplistic and 
>> I don't have a lot of experience with how well it does roaming.  I 
>> believe it will only join ap's that are listed in the config file so it 
>> shouldn't roam arbitrarily.  Without a log it's virtually impossible to 
>> comment on reports/complaints.  And even w/ a wpa_supplicant log it's 
>> also useful to understand if there are other events that trigger 
>> scanning and/or roaming--like beacon miss events.  Hence the need for 
>> logs and statistics.
>>     
>
> Exactly what statistics should I be collecting? I am assuming scan, but
> is there anything else? assoc? Or is there some other statistic you need?
>   
You said bgscan was causing interruptions in service.  To diagnose why 
you need to see whether you are not re-joining the same ap for some 
reason.  This can possibly happen because wpa_supplicant decides to roam 
(or net80211 in case you are not using wpa_supplicant) or because some 
event occurs to trigger a scan (e.g. a beacon miss).  A wpa_supplicant 
log would likely be a first place to start.  Past that you can turn on 
scan+roam debug msgs in net80211 w/ wlandebug.  Otherwise you should 
look for beacon miss events that can trigger net80211 state changes; 
these are shown with wlandebug +state.  Everything that you can observe 
with in-kernel debugging should also be counted in a statistic reported 
by wlanstats.  So, as I said, you can either collect logs or you should 
be able to collect stats to help see what is happening.  Sometimes stats 
are insufficient and you need logs.

Diagnosis at the driver level is usually warranted only if you cannot 
see what you need at the higher levels.  Remember that turning on too 
much debug info can affect realtime behaviour and alter operation of the 
system.

FWIW my typical test for bgscan is to do something like this:

1. associate to an ap
2. ping host on the wired side of the ap
3. wait for bg scan to kick in

If things are working correctly you should see no lost ping packets.  
You will see a short spike in the rtt for ping packets but bgscan should 
either be canceled or suppressed so long as there is network traffic.

    Sam