From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 14 16:21:14 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2CCCC16A4CE for ; Thu, 14 Oct 2004 16:21:14 +0000 (GMT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 78F5643D58 for ; Thu, 14 Oct 2004 16:21:13 +0000 (GMT) (envelope-from sam@errno.com) Received: from [66.127.85.93] ([66.127.85.93]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id i9EGL6Wi009073 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Oct 2004 09:21:07 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <416EA789.2010808@errno.com> Date: Thu, 14 Oct 2004 09:21:29 -0700 From: Sam Leffler Organization: Errno Consulting User-Agent: Mozilla Thunderbird 0.8 (Macintosh/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Phillip Crumpler References: <416E3722.9070705@crippy.mel.crumpler.com.au> In-Reply-To: <416E3722.9070705@crippy.mel.crumpler.com.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 15 Oct 2004 12:14:56 +0000 cc: hackers@freebsd.org Subject: Re: can WEP keys be set without resetting a wireless interface? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2004 16:21:14 -0000 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