Date: Tue, 23 Oct 2007 17:07:32 -0200 From: AT Matik <asstec@matik.com.br> To: freebsd-mobile@freebsd.org Subject: Re: Problems running ath with bgscan enabled Message-ID: <200710231707.33542.asstec@matik.com.br> In-Reply-To: <471E218F.4060907@errno.com> References: <20071022151927.5BCC54500E@ptavv.es.net> <471E218F.4060907@errno.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 nee= d? > > 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=20 wlan_scan_monitor loading manually but this thing seems vanished?=20 Then I like to add, I guess you won't like it so much but I have abandoned= =20 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 l= ong=20 time to come back (either in a/b/g), so I guess Kevin's WPA thing might=20 suffer same. =20 Sometimes it can be forced with "ifconfig ath ssid whatever up" or sometime= s=20 adding mode. Specially in 11b environments with ath_rate_sample the card=20 suddenly tries 11g and get disconnected, even when 11b was set. Sometimes i= t=20 does not come back at all and only a reboot solves it so I guess something = at=20 hal level wrong? This last thing is happening only with 7 and I never had i= t=20 with releng_6 The disconnect happens normally after a beacon miss and sometime in idle st= ate=20 when the noise level goes up or when the AP is more busy and does not respo= nd=20 as usual releng_6 is kind more stable but 7 is really nervous and get me off n times= a=20 day, with _onoe I stay always connected and get higher throughput any time. Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200710231707.33542.asstec>