Return-path: Received: from wa-out-1112.google.com ([209.85.146.181]:39282 "EHLO wa-out-1112.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754707AbYCEUuU (ORCPT ); Wed, 5 Mar 2008 15:50:20 -0500 Received: by wa-out-1112.google.com with SMTP id v27so1877176wah.23 for ; Wed, 05 Mar 2008 12:50:18 -0800 (PST) Message-ID: <1ba2fa240803051250g344977f3l6126a179d4504268@mail.gmail.com> (sfid-20080305_205030_837738_F20965DE) Date: Wed, 5 Mar 2008 22:50:17 +0200 From: "Tomas Winkler" To: "Dan Williams" Subject: Re: [PATCH] mac80211: fix races between siwessid and siwencode Cc: "Johannes Berg" , "Joonwoo Park" , linville@tuxdriver.com, linux-wireless@vger.kernel.org In-Reply-To: <1204744764.9378.49.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 References: <1204710009-10040-1-git-send-email-joonwpark81@gmail.com> <1204710843.25502.50.camel@johannes.berg> <1204715825.25502.69.camel@johannes.berg> <1204741740.9378.19.camel@localhost.localdomain> <1ba2fa240803051053j961bf68m605ca3b72cbf1b7b@mail.gmail.com> <1204744764.9378.49.camel@localhost.localdomain> Sender: linux-wireless-owner@vger.kernel.org List-ID: On Wed, Mar 5, 2008 at 9:19 PM, Dan Williams wrote: > > On Wed, 2008-03-05 at 20:53 +0200, Tomas Winkler wrote: > > On Wed, Mar 5, 2008 at 8:29 PM, Dan Williams wrote: > > > On Wed, 2008-03-05 at 12:17 +0100, Johannes Berg wrote: > > > > > > This looks wrong. You could restart association when a key is set but > > > > > > really the race is by design in WEXT so the only way to fix it is to set > > > > > > the key first. > > > > > > > > > > > > > > > > Do you mean fix iwconfig to always do set key before set essid? > > > > > > > > Well, no, I think it's more of a user error, I always do > > > > iwconfig enc ENC; iwconfig essid SSID > > > > in that order. > > > > > > > > > But, doing It cannot solve a race from two seperated iwconfig process, I think. > > > > > (eg: iwconfig essid ESSID; iwconfig enc ENC) > > > > > > > > Yeah, that's pretty ugly to start with. > > > > > > See below for a partial solution; but even with nl80211/cfg80211, if you > > > have more than one process trying to control the wireless card > > > concurrently you have already lost. Don't Do That. > > > > > > > > > > > Moreover, now we just wake auth request task up and return when setting essid. > > > > > Don't we need to wait a moment until the task is scheduled to be > > > > > polite to iwconifg? :) > > > > > > > > I think the only way to properly handle it is to reset the association > > > > state machine when a key is added. Dan, what's the expected behaviour? > > > > > > The best way to implement the WEXT stuff is to have a timeout of about > > > 500ms - 700ms or so to batch WEXT stuff together. Each new WEXT command > > > that comes in before the timeout pushes the timeout back. When the > > > timeout triggers, all the new commands are executed in the driver in the > > > order the driver expects. That fixes most issues with chaining WEXT > > > commands and makes all of these Just Work: > > > > > > iwconfig wlan0 essid foo key 253325353 open channel 11 > > > iwconfig wlan0 key 253325353 open essid foo channel 11 > > > iwconfig wlan0 channel 11 key 253325353 open essid foo > > > > > > Later on if you issue just 'iwconfig wlan0 channel 6' the driver waits > > > 500ms, the timeout triggers, and the driver changes to channel 6 and > > > starts the association process all over with the current settings (keys, > > > BSSID/SSID, bitrate, etc), and issues the SIOCGIWBSSID association event > > > on both success and failure. > > > > > > If you just do 'iwconfig wlan0 rate 11' then of course the driver > > > doesn't need to trigger reassociation after the WEXT command timeout, it > > > just needs to lock the bitrate. > > > > > > The _explicit_ triggers for association/reassociation are setting the > > > BSSID or the SSID. > > > > Currently there is a quite a mess that both BSSID and SSID triggers > > association. > > iwconfig essid AP1 > > iwconfig ap "00:....." - (bssid of myap) > > iwconfig essid AP2 > > > > what will be result of this? will it try to associate with AP1:BSSID > > but AP2 SSID > > In the current, not-timeout situation, the driver would probably attempt > to associate to AP1/any, and be interrupted by the BSSID lock of the > second command, and then try to associate to AP1/00:..., then be > interrupted by the third command. > > Then, it should fail if there is no BSSID "00:..." with an SSID of > "AP2". The user must clear the BSSID lock by doing 'iwconfig ap any' > and then the driver is free to use any BSSID in it's scan list that > matches SSID AP2 and security settings currently configured in the > driver. > > Remember, WEXT commands are _cumulative_ unless cleared by the user. It's mac80211 decision when to start association. I suggest to associate only on SSID command if someone wants to trigger BSSID association it would call SSID ANY call explicitly. This will definitely reduce the mess I'm seeing now. I'm using Fedora 8 for development and I'm still cannot figure what services are trying to access wireless devices but association is always failing because SSID is switched between authentication and association frames. It started to work a bit when I've disabled avahi and disabled dhcp on the device. (dhcp running after association is fine) Thanks Tomas > Dan > > >