Date: Wed, 26 Jul 2006 13:28:12 -0700 From: Sam Leffler <sam@errno.com> To: freebsd-stable@freebsd.org Subject: Re: "scan stuck" with if_iwi(4) Message-ID: <44C7D05C.8000408@errno.com> In-Reply-To: <20060726181534.GD5856@osgiliath.opasia.dk> References: <20060720224632.GB31459@osgiliath.brixandersen.dk> <44C00B40.2010901@errno.com> <20060726144058.GD3077@osgiliath.opasia.dk> <44C793DB.5090900@errno.com> <20060726163017.GB5856@osgiliath.opasia.dk> <44C7AF68.3090109@errno.com> <20060726181534.GD5856@osgiliath.opasia.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
Henrik Brix Andersen wrote: > On Wed, Jul 26, 2006 at 11:07:36AM -0700, Sam Leffler wrote: >> Sure, it was for others. > > Ah :) > >> Which version are you looking at? The numbers in iwi are from the code >> in linux-2.6.17; maybe it's been changed again in the code on >> sourceforge? > > I was looking in the ipw2200.h header file from ipw2200-1.1.2 - but > the values are the same in version 1.1.1 of the driver, which is > present in linux-2.6.17. > > #define IPW_MB_ROAMING_THRESHOLD_DEFAULT 8 > #define IPW_MB_DISASSOCIATE_THRESHOLD_DEFAULT 3*IPW_MB_ROAMING_THRESHOLD_DEFAULT If I recall the first is used to trigger a bg scan to look for a better ap. If that fails and the 2nd number is seen then the driver shuts down. So I guess this amounts to disconnecting from the current ap on the 2nd number but I'm not sure how you can do the bg scan and still get the firmware to keep counting up to the larger number (it resets it's internal counter on channel change from what I recall). But it's been a while. Regardless you've got a knob now so you can set it to whatever you want. You shouldn't be missing beacons in such large numbers; it's a likely indicator of some other problem but since we don't know what exactly a bmiss means it's hard to say (e.g. the firmware may report a bmiss when the rssi of the received beacon frame is below a threshold in which case there may be a problem with the threshold setting). > >> The one thing the linux driver does differently is scan for a new ap >> _before_ roaming which the current net80211 code cannot do. >> Unfortunately the code to do that has been sitting outside the tree >> for a long time and it's unclear if it'll ever come in... > > Oh? Sounds interesting, where can I find these patches? The work has always been in perforce.freebsd.org; look in the sam_wifi branch. The code will not hit head until folks show up to fix legacy drivers that use net80211. I got stuck holding the bag when I committed the wpa support and it ain't going to happen again. Sam
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44C7D05C.8000408>