can WEP keys be set without resetting a wireless interface?
sam at errno.com
Thu Oct 14 09:21:14 PDT 2004
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
The above changes are in the patches I posted yesterday.
More information about the freebsd-hackers