From owner-freebsd-mobile@FreeBSD.ORG Tue Oct 23 19:09:41 2007 Return-Path: Delivered-To: freebsd-mobile@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A37E116A419 for ; Tue, 23 Oct 2007 19:09:41 +0000 (UTC) (envelope-from asstec@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.freebsd.org (Postfix) with ESMTP id 3362B13C48A for ; Tue, 23 Oct 2007 19:09:40 +0000 (UTC) (envelope-from asstec@matik.com.br) Received: from ap-h.matik.com.br (ap-h.matik.com.br [200.152.83.36]) by msrv.matik.com.br (8.14.1/8.13.1) with ESMTP id l9NJ7k1H019219; Tue, 23 Oct 2007 17:07:46 -0200 (BRT) (envelope-from asstec@matik.com.br) From: AT Matik Organization: Infomatik To: freebsd-mobile@freebsd.org Date: Tue, 23 Oct 2007 17:07:32 -0200 User-Agent: KMail/1.9.7 References: <20071022151927.5BCC54500E@ptavv.es.net> <471E218F.4060907@errno.com> In-Reply-To: <471E218F.4060907@errno.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200710231707.33542.asstec@matik.com.br> X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on msrv.matik.com.br X-Virus-Status: Clean Cc: Subject: Re: Problems running ath with bgscan enabled X-BeenThere: freebsd-mobile@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile computing with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2007 19:09:41 -0000 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