On Wed, 2008-03-05 at 20:53 +0200, Tomas Winkler wrote: > On Wed, Mar 5, 2008 at 8:29 PM, Dan Williams <dcbw@xxxxxxxxxx> 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. Dan -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
