Problems running ath with bgscan enabled

[Sam Leffler]

AT Matik wrote:
> On Tuesday 23 October 2007 14:30:07 Sam Leffler wrote:
>> Kevin Oberman wrote:
>>> 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.
>>
> 
> 
> well, do you know about the stumbler from net80211 tools which asks for 
> wlan_scan_monitor loading manually but this thing seems vanished? 

wlan_scan_monitor never existed.  The complaint about the module not
being present needs to be removed; it's a noop (there is no scanning in
monitor mode, you must fix the channel).

> 
> Then I like to add, I guess you won't like it so much but I have abandoned 
> ath_rate_sample but I'm trying it from time to time

You're free to do what you want.  Every test I've done shows sample
superior to either of the alternatives.  In particular I've run
waterfall tests on a wired testbed with all 3 ath rate control
algorithms and sample is easily the best of the lot.

> 
> Reason is  that ath_rate_sample suddenly disconnect and it needs a pretty long 
> time to come back (either in a/b/g), so I guess Kevin's WPA thing might 
> suffer same.

"suddenly disconnects" means nothing to me.

> 
>    
> Sometimes it can be forced with "ifconfig ath ssid whatever up" or sometimes 
> adding mode. Specially in 11b environments with ath_rate_sample the card 
> suddenly tries 11g and get disconnected, even when 11b was set. Sometimes it 
> does not come back at all and only a reboot solves it so I guess something at 
> hal level wrong? This last thing is happening only with 7 and I never had it 
> with releng_6

sample uses only negotiated rates; what you describe makes no sense but
w/o real information there's little more one can say.  However there was
a bug in sample for a few days (maybe >1 week) that caused it to use
incorrect rate indices but I fixed that; maybe that is what you're
describing (there would have been a console msg about a bogus rate idx).

> 
> The disconnect happens normally after a beacon miss and sometime in idle state 
> when the noise level goes up or when the AP is more busy and does not respond 
> as usual
> 
> releng_6 is kind more stable but 7 is really nervous and get me off n times a 
> day, with _onoe I stay always connected and get higher throughput any time.

Sorry but this really doesn't give me anything to go on and at this time
I don't have time to chase anything but very specific issues.  The time
to bring up vague concerns like this was many months ago.

	Sam