> As you can see, it doesn't find anything that matches the > current configuration. Right. And correct behavior. > > $ iwconfig eth1 key s:11111 > > b43-phy0 debug: Using hardware based encryption for keyidx: > > 0, mac: ff:ff:ff:ff:ff:ff > > You've now enabled a key, but not told it to associate using > that key. Wrong, because of an false assumption. On first sight, you might be right. I haven't told to associate. But at the second sight, there is no EXPLICIT iwconfig-based way to say "now associate". For 6 drivers (see below) the "iwconfig XXX key YYY" command is an IMPLICIT way to say "try to associate with what you know so far. That's because those drivers have a heuristic like "If I'm not successfully associated yet, then I try to associate whenver I get a new bit of info". And this bit of info might be ESSID, wep key, wpa key, on some drivers even rate or b/g limitations. It's mac80211 that falsely thinks "iwconfig XXX essid" is the only (!) command that triggers an association. Something that is nowhere seen in "man iwconfig". Before many commands did trigger an association, e.g. "iwconfig essid", "iwconfig key", "iwconfig ap" and also several ioctl's used only by wpa-supplicant. > > As you can see, I'm not associated. However, this sequence > > used to work with non-mac80211 based WLAN drivers. However, > > I can actually associate if I reverse the essid/key, e.g. > > first set the key, then the ssid. > > Can't say that matters since wext is actually sufficiently > undefined to allow both behaviours. :) Wrong. Of course I can say that the ESSID,KEY sequence used to work with non-mac80211 based WLAN drivers. Because it worked. I have proof that it worked. I might not be able to say that it worked for *ALL* non-mac80211 based WLAN drivers. But I haven't said that. And as of now, I can say that 6 drivers didn't care if I first feed the ESSID and the the WEP KEY: * orinoco_cs works that way * ipw2200 (in kernel) also * wlags49_h1_cs (an out-of-kernel driver) also * wlags49_h2_cs also * bcm43xx (sucky in many ways) worked too * libertas_cs/usb8xxx (in kernel) also * madwifi also One can say that if so many drivers behave identically, then this is a behavior that many users assume. And, oh, by the way, many distros. It's the behavior of mac80211 with wext-compatibilty layer that behaves unusually or out-of-the-order. > That sucks, I guess debian's scripts need to be fixed. No, it doesn't. it worked for many years with various WLAN cards. How should Debian suck if it doesn't work when done manually? In this case: what sucks is in the eye of the beholder. Surely your own baby never sucks, compared with other babies. However, some other moms and fathers might say that the baby that is out-of-the-order sucks. But then, ALL babies suck (breast, thumbs) during their first months ... :-) - 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
