Date: Mon, 15 Oct 2007 11:42:23 -0700 From: Sam Leffler <sam@errno.com> To: Kevin Oberman <oberman@es.net> Cc: freebsd-mobile@freebsd.org Subject: Re: Odd error messages on wireless 11a connection Message-ID: <4713B48F.7050608@errno.com> In-Reply-To: <20071015175520.7F9964500E@ptavv.es.net> References: <20071015175520.7F9964500E@ptavv.es.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Kevin Oberman wrote: >> Date: Mon, 15 Oct 2007 10:20:09 -0700 >> From: Sam Leffler <sam@errno.com> >> >> Sam Leffler wrote: >> >>> Kevin Oberman wrote: >>> >>>> I am at a major networking conference and my wireless, while working, is >>>> logging lots of errors that I don't understand at all. >>>> >>>> +update_stats: bogus ndx0 7, max 7, mode 1 >>>> >>>> Can anyone explain what these are? Do I need to be concerned? >>>> >>>> Atheros 5212 on FreeBSD current as of Oct. 5, i386, single processor >>>> system. ath0: <Atheros 5212> mem 0xb4000000-0xb400ffff irq 11 at >>>> device 2.0 on pci11 >>>> ath0: [ITHREAD] >>>> ath0: using obsoleted if_watchdog interface >>>> ath0: Ethernet address: 00:14:a4:60:f2:e3 >>>> ath0: mac 5.9 phy 4.3 radio 3.6 >>>> >>>> >>> Update your ath driver. You've found an ap that is beaconing a >>> "pureg" rate set and a recent change to the sample rate code broke that. >>> >> Actually your interface is marked "pureb" and the ap is sending an 11g >> rate set but the answer is the same--update ath_rate/sample.c. >> > > OK. I updated and no longer am seeing the messages. Thanks! > > One issue...I booted with WPA DHCP and the system skipped the higher > priority 11a net and associated with the b/g net. I did a 'list aps' and > only saw 2 APs, both 11g. I know that there should have been more, so I > did a 'scan' and all the rest appeared, including the 11a APs. (Total of > 8 APs, 4 11b/g and 4 11a.) The supplicant now associated with the 11a > net and my system is running MUCH better! > > Any idea if this is a timing issue? Any way to improve the initial scan? > > Thanks again for the very fast responses. > Scanning is always a balancing act between speed and accuracy. The usual way to improve the latter is to dwell longer on a channel. I don't recall if the dwell time is a sysctl knob; it's not settable via ifconfig. OTOH w/ bgscan and roaming you should quickly find a good ap to use. Sam
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4713B48F.7050608>