[please make sure to copy me on replies] > 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". Exactly. So I argue we're free to chose. > 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. Which is crap. > > 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. Bzzt. You're operating on wrong premises. It doesn't matter! Nothing in wext gives you the promise that this works! > 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: [drivers snipped] Actually, all of these drivers misbehave because they allow you to associate to a network that has encryption enabled even if you haven't set a key! > 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. Again, you're operating on the premise that what some drivers do defines wext. That's thankfully untrue and since wext doesn't define behaviour, the mac80211 behaviour is well in line. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
