> > And this bit of info might be ESSID, wep key, wpa key, on > > some drivers even rate or b/g limitations. > > Which is crap. Crap or not, this is the way it used to work. If mac80211 would have ditched wext and would be using nl80211, I wouldn't object. But it claims to be wext-compatible, but it isn't. > 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! Wrong. I'm not aware (from those 6) that behaves that way. When I just enter "iwconfig eth1 essid MUMBLEFUTZ", no key, and then look at "iwconfig eth1", then I don't see a MAC address of the AP. For me this is clearly a sign that they don't behave as you claimed. > > 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. Wrong. Not "some", but "many" drivers did this, not some. I think orinoco_cs were used a lot in older days. And madwifi still get's used a lot. Also I have never said that anything is defined here, or please show me the sentence where I wrote this. I just wrote that implicitly a number of drivers behave the way. Face it or not, not everything in life is defined. Nowhere is defined how bees behave, and yet they behave in uniform, somewhat predicatable ways. So please stop this discussion about defined or not defined. mac80211 behaves out-of-the-order compared to older drivers. No matter if this behavior was formally defined or not. - 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
