Date: Thu, 14 Oct 2004 09:21:29 -0700 From: Sam Leffler <sam@errno.com> To: Phillip Crumpler <listsubs@crippy.mel.crumpler.com.au> Cc: hackers@freebsd.org Subject: Re: can WEP keys be set without resetting a wireless interface? Message-ID: <416EA789.2010808@errno.com> In-Reply-To: <416E3722.9070705@crippy.mel.crumpler.com.au> References: <416E3722.9070705@crippy.mel.crumpler.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Phillip Crumpler wrote: > Hi hackers, > > Can anyone tell me why setting WEP keys on a wireless interface must > result in the interface being reset? > > I have a wireless authenticator that wants to set random WEP keys and > send them out to connected stations. Setting a key results in the > interface being reset () the ioctl handler return ENETRESET), which > kicks off all of the stations and forces them to reassociate. > > Trying to get around this I just updated the keys directly: > > wk = &ic->ic_nw_keys[nkidx]; > arc4rand(wk->wk_key, wk->wk_len, 0); > > But the moment this happens everyone goes off the air. Of course, that > is the short answer: the interface gets reset because it doesn't work if > it's not :-) > > Can anyone provide a bit more detail or suggest a way around this? The existing API takes a coarse-grained approach to pushing state from the net80211 layer into the driver. That is, when you tweak some parameter in the 802.11 state that might require changing the 802.11 state machine the driver is told to "re-init" so that any changes from the 802.11 layer are pushed down into the driver (and possibly the hardware). This is clearly suboptimal and results in problems like what you see. It is possible for drivers to be more selective in how they treat updates to avoid state machine changes but that gets tedious. What I've done instead is introduce an additional notification mechanism from the net80211 layer to drivers that says "reset your hardware state but don't kick the 802.11 state machine". This eliminates a number of gratuitous state machine changes. For keys and some other state I've also added explicit driver callbacks to bypass both mechanisms. As you've found key state in protocols like WPA and 802.1x (w/o WPA) can change frequently so it's just not feasible to use the coarse-grained notification strategy. The above changes are in the patches I posted yesterday. Sam
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?416EA789.2010808>