Re: mac80211 regression: doesn't associate automatically

[Holger Schurig <hs4233@mail.mn-solutions.de>]

> 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 ... :-)