Re: Problems running ath with bgscan enabled

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? 

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

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.

   
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

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.



João







A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura.
Service fornecido pelo Datacenter Matik  https://datacenter.matik.com.br
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-mobile
To unsubscribe, send any mail to "[email protected]"