can WEP keys be set without resetting a wireless interface?

[Sam Leffler]

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