mac80211 regression: doesn't associate automatically

mac80211 regression: doesn't associate automatically

[Holger Schurig]

I'm on wireless-2.6, branch everything, git commit
7446b6c0e3b18fd2c5f9c406bb20841e6193d058

When I insert a b43 based card, I don't get associated
automatically. This happens:


$ # Insert the card
pccard: CardBus card inserted into slot 0
PCI: Enabling device 0000:03:00.0 (0000 -> 0002)
ACPI: PCI Interrupt 0000:03:00.0[A] -> Link [LNKC] -> GSI 11 (level, low) -> IRQ 11
PCI: Setting latency timer of device 0000:03:00.0 to 64
ssb: SPROM revision 1 detected.
ssb: Sonics Silicon Backplane found on PCI device 0000:03:00.0
b43-phy0: Broadcom 4306 WLAN found
b43-phy0 debug: Found PHY: Analog 2, Type 2, Revision 2
b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2050, Revision 2
phy0: Selected rate control algorithm 'simple'

$ ifconfig eth1 up
b43-phy0 debug: Loading firmware version 351.126 (2006-07-29 05:54:02)
b43-phy0 debug: Chip initialized
b43-phy0 debug: 30-bit DMA initialized
b43-phy0 debug: Wireless interface started
b43-phy0 debug: Adding Interface type 2

$ iwconfig eth1 essid BLAHMUMPF
HW CONFIG: channel=1 freq=2412 phymode=2
HW CONFIG: channel=2 freq=2417 phymode=2
HW CONFIG: channel=3 freq=2422 phymode=2
HW CONFIG: channel=4 freq=2427 phymode=2
HW CONFIG: channel=5 freq=2432 phymode=2
HW CONFIG: channel=6 freq=2437 phymode=2
HW CONFIG: channel=7 freq=2442 phymode=2
HW CONFIG: channel=8 freq=2447 phymode=2
HW CONFIG: channel=9 freq=2452 phymode=2
HW CONFIG: channel=10 freq=2457 phymode=2
HW CONFIG: channel=11 freq=2462 phymode=2
HW CONFIG: channel=1 freq=2412 phymode=2

$ iwconfig eth1 key s:11111
b43-phy0 debug: Using hardware based encryption for keyidx: 0, mac: ff:ff:ff:ff:ff:ff

$ iwconfig eth1
eth1      IEEE 802.11g  ESSID:"BLAHMUMPF"
          Mode:Managed  Frequency:2.412 GHz  Access Point: Not-Associated
          Tx-Power=27 dBm
          Retry min limit:7   RTS thr:off   Fragment thr=2352 B
          Encryption key:3131-3131-31
          Link Quality:0  Signal level:0  Noise level:0
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

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.


Note that the same happens if I let Debian manage the card. An excerpt
from my /etc/network/interfaces shows:

allow-hotplug eth1
iface eth1 inet static
        address 10.2.1.3
        netmask 255.255.255.0
        wireless-essid BLAHMUMPF
        wireless-key1 s:11111

(the test above has been made completely manually, without this entry)

Re: mac80211 regression: doesn't associate automatically

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1185 bytes --]

First off, let me state that I don't think this is a regression.

> $ iwconfig eth1 essid BLAHMUMPF
> HW CONFIG: channel=1 freq=2412 phymode=2
[...]

As you can see, it doesn't find anything that matches the current
configuration.

> $ 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.

> 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. :) I'm strongly against changing the behaviour in
mac80211 because wext is sufficiently undefined that once we accept one
of these things we'll have a HUGE mess of code because all sorts of wext
ioctls affect possible association etc.

> Note that the same happens if I let Debian manage the card. An excerpt
> from my /etc/network/interfaces shows:

That sucks, I guess debian's scripts need to be fixed.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: mac80211 regression: doesn't associate automatically

[John W. Linville]

On Thu, Nov 22, 2007 at 02:05:52PM +0100, Johannes Berg wrote:

> > Note that the same happens if I let Debian manage the card. An excerpt
> > from my /etc/network/interfaces shows:
> 
> That sucks, I guess debian's scripts need to be fixed.

As it stands, setting the SSID is the closest thing we have to an
"associate now" trigger.  I would have to advise distros and users to
always set it last in the wireless init, just before running dhclient
or whatever.

John
-- 
John W. Linville
linville@tuxdriver.com

Re: mac80211 regression: doesn't associate automatically

[Pavel Roskin]

On Thu, 2007-11-22 at 08:26 -0500, John W. Linville wrote:

> As it stands, setting the SSID is the closest thing we have to an
> "associate now" trigger.  I would have to advise distros and users to
> always set it last in the wireless init, just before running dhclient
> or whatever.

Maybe mac80211 should have a "grace period" of 0.5 seconds or so to
allow other settings to be set before the scanning starts?  The same
applies to other events causing scanning, such as bringing up the
interface.  It's too short to be noticeable, yet long enough for the
next command to run even on slow systems.

I think setting the key should not cause reassociation if there is an
association.  It can break some schemes where the WEP key changes
periodically on both sides.

-- 
Regards,
Pavel Roskin

Re: mac80211 regression: doesn't associate automatically

[Pavel Roskin]

On Thu, 2007-11-22 at 18:18 -0700, Ehud Gavron wrote:

> 2. dmesg repeats: wlan0: authentication with AP 00:50:bf:b1:da:64 timed out

I think it's an unrelated hardware specific issue.  mac80211 tried to
associate but failed.

-- 
Regards,
Pavel Roskin

Re: mac80211 regression: doesn't associate automatically

[Holger Schurig]

> I think setting the key should not cause reassociation if
> there is an association.

That seems sensible.


I actually think that while it's not associated, it should 
periodically try to associcate with what's currently defined 
(e.g. ESSID, fixed AP mac, key settings etc).

Currently, if I do the following with mac80211/b43:

$ # turn AP off or move into an area where you can't
  receive the AP
$ pccardctl insert
$ ifconfig eth1 up
$ iwconfig eth1 key s:11111
$ iwconfig eth1 essid MUMBLFUTZ
$ # turn AP on or move with the laptop/device into the
  vincinity of an AP

... then I won't get an association at all.

Other drivers that I used in production during the last 5 years 
didn't show that behavior (orinoco_cs, wlags_h1_cs, wlags_h2_cs, 
madwifi). They associated on their own.

However, as mac80211 is currently implemented, it assumes 
a "stationary" WLAN setup and doesn't cope well with scenarios 
where devices move. If it would cope better with such 
situations, then it would also cope with the first problem I 
reported. Because if it would periodically re-scan and try to 
associate, a later submitted or changed WEP key would be taken 
into account and association would have succeeded.

Re: mac80211 regression: doesn't associate automatically

[Pavel Roskin]

On Fri, 2007-11-23 at 09:06 +0100, Holger Schurig wrote:

> I actually think that while it's not associated, it should 
> periodically try to associcate with what's currently defined 
> (e.g. ESSID, fixed AP mac, key settings etc).

What you are asking for is roaming in the kernel.  Orinoco relies on
roaming in the firmware.  MadWifi implemented it in the kernel code, but
it's a heavily over-engineered piece of software and shouldn't be an
example for the kernel drivers.

wpa_supplicant gives you roaming in the userspace.  There are some other
roaming agents available.  Having similar code in the kernel is
debatable, but please realize that you are asking for a feature, not
reporting a bug.

wpa_supplicant may be what you need to solve your roaming problems,
although it doesn't play well with Fedora scripts, and I don't know if
any distro gets networking right.

-- 
Regards,
Pavel Roskin

Re: mac80211 regression: doesn't associate automatically

[Holger Schurig]

> Orinoco relies on roaming in the firmware

And wlags_h1_cs/wlags_h2_cs as well.

libertas_cs has half-baked roaming in firmware and in 
kernel-space, doesn't work very well so far.

Madwifi has code coarse code roaming in the BSD borrowed 
ieee80211 code. It roams only when it lost the association to 
the current AP. But before doing that, it went with it's rate 
down to 1 MBit/s, even when there's a better AP nearby that it 
could use with 11 MBit/s or higher.

There is code in it which is disabled via "if (0 || ...)" that 
allows for a much smoother roaming, e.g. to scan when the RSSI 
drops below a certain level. Once enabled and after tuning of 
some timeout variables, that roaming code works extremely well. 
Both in a WEP-mode without wpa_supplicant and in WPA/WPA2 mode 
with wpa_supplicant.


> wpa_supplicant gives you roaming in the userspace.

Yeah, I thought in this lines as well. I have no problem putting 
wpa_supplicant on my embedded targets. In fact, it's already 
there, it's currently just used for WPA, not for WEP. However, 
if suddenly NetworkManager would be needed for roaming, then 
from an embedded-usage point of view I wouldn't like that.

I just don't know how good it's roaming code is, e.g. can it 
start to scan for something better if the RSSI drops below some 
threshold?  Does it have a good picture of the ever changing 
situation of AP's signal strength?  This I need to find out :-)

Re: mac80211 regression: doesn't associate automatically

[Dan Williams]

On Fri, 2007-11-23 at 10:03 +0100, Holger Schurig wrote:
> > Orinoco relies on roaming in the firmware
> 
> And wlags_h1_cs/wlags_h2_cs as well.
> 
> libertas_cs has half-baked roaming in firmware and in 
> kernel-space, doesn't work very well so far.
> 
> Madwifi has code coarse code roaming in the BSD borrowed 
> ieee80211 code. It roams only when it lost the association to 
> the current AP. But before doing that, it went with it's rate 
> down to 1 MBit/s, even when there's a better AP nearby that it 
> could use with 11 MBit/s or higher.
> 
> There is code in it which is disabled via "if (0 || ...)" that 
> allows for a much smoother roaming, e.g. to scan when the RSSI 
> drops below a certain level. Once enabled and after tuning of 
> some timeout variables, that roaming code works extremely well. 
> Both in a WEP-mode without wpa_supplicant and in WPA/WPA2 mode 
> with wpa_supplicant.
> 
> 
> > wpa_supplicant gives you roaming in the userspace.
> 
> Yeah, I thought in this lines as well. I have no problem putting 
> wpa_supplicant on my embedded targets. In fact, it's already 
> there, it's currently just used for WPA, not for WEP. However, 
> if suddenly NetworkManager would be needed for roaming, then 
> from an embedded-usage point of view I wouldn't like that.

The problem is, roaming and choosing which AP/BSSID to connect to is
pretty complicated.  It depends on user preferences, scan results, RSSI,
and other stuff like that.  It depends on having the necessary security
information (keys, PIN, EAP certs, etc) available.  wpa_supplicant must
run as root to be able to drive the wifi device, and many of these
settings are user-specific; so there has to be some mechanism to push
those settings down to wpa_supplicant.

You could potentially use wpa_supplicant to do what you want, based on
network block priorities and turning network blocks on/off dynamically
through the control interface.  Right now, NetworkManager just pushes
_one_ network to wpa_supplicant, the network NM wants to association
with.  I can imagine further down the line pushing more of the decisions
onto wpa_supplicant.  But wpa_supplicant seems (to me) to still have
quite a few assumptions about static configuration, which is
traditionally how it's been used.  In any case, the trend with NM is
pushing more and more of the Wifi stuff down to wpa_supplicant and to
make NetworkManager be more of a policy engine that handles many
different device types, from wired to wireless to GSM/CDMA broadband
cards to Bluetooth DUN.

Dan

Re: mac80211 regression: doesn't associate automatically

[Holger Schurig]

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

Re: mac80211 regression: doesn't associate automatically

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1974 bytes --]

[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 #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: mac80211 regression: doesn't associate automatically

[Holger Schurig]

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

Re: mac80211 regression: doesn't associate automatically

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 81 bytes --]

[what's so hard about copying me?]

Bottom line is, I don't care.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: mac80211 regression: doesn't associate automatically

[Holger Schurig]

> Bottom line is, I don't care.

So much I figured out by myself.


Maybe you can show me a non-mac80211 driver that behaves in the 
same way as mac80211?  In other words, a driver where you can do

ifconfig eth1 up
iwconfig eth1 essid SOMESSID
iwconfig eth1 key s:11111

and where, as in mac80211, you don't get an association (assuming 
that the AP is set up accordingly). If you can show me 5 
drivers, than I'm willing to assume that there is no regression.


So far I haven't seen one non-mac80211 driver that did not 
associate with this sequence.

Re: mac80211 regression: doesn't associate automatically

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 2162 bytes --]

So since you felt it was necessary to attack my sanity, let me reply
once more.

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

It is. It isn't compatible to how you expect wext to behave or how some
other driver authors wanted wext to behave with their drivers. But since
wext never specified how this should work we can rightfully claim wext
compatibility. Show documents, comments in the code, anything that backs
up your claim. The only thing you've shown so far is stuff that is just
as well within spec because spec says nothing and deviates from how we
interpret the non-existent spec.

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

I'm sure that softmac behaves the way I claimed, so bcm43xx would.

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

Yes. But what you *are* saying that we should make that the wext
specification by requiring everybody else who wants to implement wext to
behave that way too. I'm merely questioning that based on the fact that
wext doesn't define this and it is *much* easier and nicer to implement
it the way we currently do.

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

It *does* matter because the only thing tools and people using the tools
can rely on is what is defined rather than "happens to work with driver
XY so it must be right"

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: mac80211 regression: doesn't associate automatically

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 462 bytes --]


> It *does* matter because the only thing tools and people using the tools
> can rely on is what is defined rather than "happens to work with driver
> XY so it must be right"

In fact, the *ONLY* think wext defines (via iwconfig's man page) is that
setting an AP mac address forces association. Everything else is being
nice. Hence, to be absolutely compatible you should *always* issue
"iwconfig <dev> ap any" after setting configuration.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: mac80211 regression: doesn't associate automatically

[Holger Schurig]

> In fact, the *ONLY* think wext defines (via iwconfig's man
> page) is that setting an AP mac address forces association.
> Everything else is being nice. Hence, to be absolutely
> compatible you should *always* issue "iwconfig <dev> ap any"
> after setting configuration.

What you describe is the law, but not the life. Get a grip. It 
starts to be comical.

In real life, "iwconfig XXX AP YYY" is VERY seldom used. For a 
start, it would disable roaming.

Re: mac80211 regression: doesn't associate automatically

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 556 bytes --]


> > In fact, the *ONLY* think wext defines (via iwconfig's man
> > page) is that setting an AP mac address forces association.
> > Everything else is being nice. Hence, to be absolutely
> > compatible you should *always* issue "iwconfig <dev> ap any"
> > after setting configuration.
> 
> What you describe is the law, but not the life. Get a grip. It 
> starts to be comical.
> 
> In real life, "iwconfig XXX AP YYY" is VERY seldom used. For a 
> start, it would disable roaming.

Nope. My command line said "any" for a reason.

joahnnes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: mac80211 regression: doesn't associate automatically

[Holger Schurig]

> > 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.
>
> It *does* matter because the only thing tools and people using
> the tools can rely on is what is defined rather than "happens
> to work with driver XY so it must be right"

So, things brings me to a weird conclusion:

a) earlier you said that in WEXT, the only command that is 
defined to get you an association is the "iwconfig XXX ap YYY" 
command.

b) you also say that tools should only rely on things that are 
defined

If I accept both sentences as valid, I must conclude that 
mac80211 is faulty. It happens that mac80211 triggers an 
association to an access-point also by the "iwconfig XXX essid 
YYYY" command. This is not defined. Hey, wait a minute. mac80211 
is not allowed to do ANYTHING that is undefined, because tools 
can only rely on defined things. So mac80211 is faulty. Crap, 
ditch it.

I hope you get that somehow this is not only weird, it's 
unhelpful. Maybe now you can understand why I see thinking in 
the lines of "only what has defined is right and everything else 
is wrong" isn't helpful at all.

Re: mac80211 regression: doesn't associate automatically

[Will Dyson]

On Nov 22, 2007 11:19 AM, Holger Schurig <hs4233@mail.mn-solutions.de> wrote:

> If I accept both sentences as valid, I must conclude that
> mac80211 is faulty. It happens that mac80211 triggers an
> association to an access-point also by the "iwconfig XXX essid
> YYYY" command. This is not defined. Hey, wait a minute. mac80211
> is not allowed to do ANYTHING that is undefined, because tools
> can only rely on defined things. So mac80211 is faulty. Crap,
> ditch it.

Hi Holger,

I understand you are frustrated, but your tone is not helping to make
this a productive discussion. Please keep in mind that fixing this
stuff is not anybody's day job right now.

Also, are you sure you understand completely what is going on? As far
as I can see, the Debian wireless-tools ifup script (package version
29-1) *is* setting the key before it sets the essid. In fact, setting
the ssid and key both happen in a pre-up script, which is run before
the interface is even brought up.

So it should be working for you, based on that. What version of the
package do you have?

Johannes,

It doesn't look like it should be so hard to make setting the key
trigger association. And I don't think that if we allow setting the
key to trigger association, that it obligates us to reassociate on
every other event that could effect it. As you said, wext spec is
silent on this matter.

It does seem silly to set the key after the essid, but unless it
really hurts elsewhere, we can be liberal in what we accept.

My (probably wrong, compile-tested only, for review only) patch to
implement this:

I know it is word-wrapped by Gmail. Sorry, I'm late to a family event as-is.

diff --git a/net/mac80211/ieee80211_ioctl.c b/net/mac80211/ieee80211_ioctl.c
index 503b64a..6ce79e4 100644
--- a/net/mac80211/ieee80211_ioctl.c
+++ b/net/mac80211/ieee80211_ioctl.c
@@ -839,6 +839,7 @@ static int ieee80211_ioctl_siwencode(struct net_device *dev,
 	int idx, i, alg = ALG_WEP;
 	u8 bcaddr[ETH_ALEN] = { 0xff, 0xff, 0xff, 0xff, 0xff, 0xff };
 	int remove = 0;
+	int ret;

 	sdata = IEEE80211_DEV_TO_SUB_IF(dev);

@@ -864,11 +865,16 @@ static int ieee80211_ioctl_siwencode(struct
net_device *dev,
 		return 0;
 	}

-	return ieee80211_set_encryption(
+	ret = ieee80211_set_encryption(
 		dev, bcaddr,
 		idx, alg, remove,
 		!sdata->default_key,
 		keybuf, erq->length);
+	if (ret)
+		return ret;
+
+	ieee80211_sta_req_auth(dev, &sdata->u.sta);
+	return 0;
 }


@@ -1015,6 +1021,7 @@ static int ieee80211_ioctl_siwencodeext(struct
net_device *dev,
 	struct ieee80211_sub_if_data *sdata = IEEE80211_DEV_TO_SUB_IF(dev);
 	struct iw_encode_ext *ext = (struct iw_encode_ext *) extra;
 	int uninitialized_var(alg), idx, i, remove = 0;
+	int ret;

 	switch (ext->alg) {
 	case IW_ENCODE_ALG_NONE:
@@ -1052,11 +1059,16 @@ static int ieee80211_ioctl_siwencodeext(struct
net_device *dev,
 	} else
 		idx--;

-	return ieee80211_set_encryption(dev, ext->addr.sa_data, idx, alg,
+	ret = ieee80211_set_encryption(dev, ext->addr.sa_data, idx, alg,
 					remove,
 					ext->ext_flags &
 					IW_ENCODE_EXT_SET_TX_KEY,
 					ext->key, ext->key_len);
+	if (ret)
+		return ret;
+
+	ieee80211_sta_req_auth(dev, &sdata->u.sta);
+	return 0;
 }

-- 
Will Dyson

Re: mac80211 regression: doesn't associate automatically

[Holger Schurig]

> Also, are you sure you understand completely what is going on?

That Debian was not able to set the script might really be a 
different problem.

> As far as I can see, the Debian wireless-tools ifup script
> (package version 29-1) *is* setting the key before it sets the
> essid. In fact, setting the ssid and key both happen in a
> pre-up script, which is run before the interface is even
> brought up.

Yes, Debian /etc/network/if-pre-up.d/wireless-tools first sets 
all stuff up, then calls iwconfig essid, and only then brings 
the interface up.

So you're right, the "doesn't associate" problem is not Debian's 
fault (I actually never suspected Debian to be faulty, it worked 
flawless all the time and I haven't changed anything there).

Now I disabled Debians startup scripts and did the thing 
manually. And voila, it doesn't work when done manually.


As it stands, I now have two sequences that doesn't associate 
with mac80211/b43:


Debian's sequence:

$ pccardctl insert
$ iwconfig eth1 key:11111
$ iwconfig eth1 essid MUMBLEFUTZ
$ ifconfig eth1 up

My older sequence:

$ pccardctl insert
$ ifconfig eth1 up
$ iwconfig eth1 essid MUMBLEFUTZ
$ iwconfig eth1 key:11111




Litte side note: with the first sequence, after about a minute 
the driver scans and associates anyway:

10:27:50.846680   eth1     Set Encryption key:****-****-**
10:27:55.440949   eth1     Set ESSID:"MUMBLEFUTZ"
10:29:06.047881   eth1     Scan request completed
10:29:06.064521   eth1     Custom driver 
event:ASSOCINFO(ReqIEs=...)
10:29:06.064550   eth1     New Access Point/Cell 
address:00:13:19:80:DA:30

While I find the timeout of a minute way too high (especially for 
a moving environment, e.g. storage warehouse), it's better than 
nothing.

The second sequence doesn't associate at all, not even after five 
minutes.


Again, both (!) sequences work with several non-mac80211-drivers 
that I used in production during the last 5 years. And I'm still 
inclined to call this a regression: things that used to work 
stopped working.

Re: mac80211 regression: doesn't associate automatically

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 2544 bytes --]


> It doesn't look like it should be so hard to make setting the key
> trigger association. And I don't think that if we allow setting the
> key to trigger association, that it obligates us to reassociate on
> every other event that could effect it. As you said, wext spec is
> silent on this matter.
> 
> It does seem silly to set the key after the essid, but unless it
> really hurts elsewhere, we can be liberal in what we accept.
> 
> My (probably wrong, compile-tested only, for review only) patch to
> implement this:

I don't think this can work because when say wpa_supplicant changes the
key the last thing we want is to have that cause a reconsideration of
which AP we're associated with. Or even a disassoc/reassoc cycle.

> I know it is word-wrapped by Gmail. Sorry, I'm late to a family event as-is.
> 
> diff --git a/net/mac80211/ieee80211_ioctl.c b/net/mac80211/ieee80211_ioctl.c
> index 503b64a..6ce79e4 100644
> --- a/net/mac80211/ieee80211_ioctl.c
> +++ b/net/mac80211/ieee80211_ioctl.c
> @@ -839,6 +839,7 @@ static int ieee80211_ioctl_siwencode(struct net_device *dev,
>  	int idx, i, alg = ALG_WEP;
>  	u8 bcaddr[ETH_ALEN] = { 0xff, 0xff, 0xff, 0xff, 0xff, 0xff };
>  	int remove = 0;
> +	int ret;
> 
>  	sdata = IEEE80211_DEV_TO_SUB_IF(dev);
> 
> @@ -864,11 +865,16 @@ static int ieee80211_ioctl_siwencode(struct
> net_device *dev,
>  		return 0;
>  	}
> 
> -	return ieee80211_set_encryption(
> +	ret = ieee80211_set_encryption(
>  		dev, bcaddr,
>  		idx, alg, remove,
>  		!sdata->default_key,
>  		keybuf, erq->length);
> +	if (ret)
> +		return ret;
> +
> +	ieee80211_sta_req_auth(dev, &sdata->u.sta);
> +	return 0;
>  }
> 
> 
> @@ -1015,6 +1021,7 @@ static int ieee80211_ioctl_siwencodeext(struct
> net_device *dev,
>  	struct ieee80211_sub_if_data *sdata = IEEE80211_DEV_TO_SUB_IF(dev);
>  	struct iw_encode_ext *ext = (struct iw_encode_ext *) extra;
>  	int uninitialized_var(alg), idx, i, remove = 0;
> +	int ret;
> 
>  	switch (ext->alg) {
>  	case IW_ENCODE_ALG_NONE:
> @@ -1052,11 +1059,16 @@ static int ieee80211_ioctl_siwencodeext(struct
> net_device *dev,
>  	} else
>  		idx--;
> 
> -	return ieee80211_set_encryption(dev, ext->addr.sa_data, idx, alg,
> +	ret = ieee80211_set_encryption(dev, ext->addr.sa_data, idx, alg,
>  					remove,
>  					ext->ext_flags &
>  					IW_ENCODE_EXT_SET_TX_KEY,
>  					ext->key, ext->key_len);
> +	if (ret)
> +		return ret;
> +
> +	ieee80211_sta_req_auth(dev, &sdata->u.sta);
> +	return 0;
>  }
> 

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: mac80211 regression: doesn't associate automatically

[Will Dyson]

On Nov 23, 2007 7:48 AM, Johannes Berg <johannes@sipsolutions.net> wrote:

> I don't think this can work because when say wpa_supplicant changes the
> key the last thing we want is to have that cause a reconsideration of
> which AP we're associated with. Or even a disassoc/reassoc cycle.

Ah, yes dynamic WEP (or does wpa also go through those ioctls?). Thanks.

-- 
Will Dyson

Re: mac80211 regression: doesn't associate automatically

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 474 bytes --]


On Fri, 2007-11-23 at 14:34 -0500, Will Dyson wrote:
> On Nov 23, 2007 7:48 AM, Johannes Berg <johannes@sipsolutions.net> wrote:
> 
> > I don't think this can work because when say wpa_supplicant changes the
> > key the last thing we want is to have that cause a reconsideration of
> > which AP we're associated with. Or even a disassoc/reassoc cycle.
> 
> Ah, yes dynamic WEP (or does wpa also go through those ioctls?). Thanks.

Yup, WPA does too.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: mac80211 regression: doesn't associate automatically

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1550 bytes --]


> So, things brings me to a weird conclusion:
> 
> a) earlier you said that in WEXT, the only command that is 
> defined to get you an association is the "iwconfig XXX ap YYY" 
> command.

Yes, but you're assuming "YYY" is a MAC address while in fact it can
have two special meanings, "any" and "off", see the iwconfig man page.

> If I accept both sentences as valid, I must conclude that 
> mac80211 is faulty. It happens that mac80211 triggers an 
> association to an access-point also by the "iwconfig XXX essid 
> YYYY" command. This is not defined. Hey, wait a minute. mac80211 
> is not allowed to do ANYTHING that is undefined, because tools 
> can only rely on defined things. So mac80211 is faulty. Crap, 
> ditch it.

Nope, this isn't what I said either. You've (I guess intentionally or by
just being too set into your line of thinking and not accepting any of
my arguments) managed to misunderstand me *COMPLETELY*.

You said, paraphrasing: I have a mac80211 _bug_, it's crap because it
doesn't support this use case I dug out and that happens to work with
some other drivers.

I said: It's not a bug.

You understood: Johannes hates me, he thinks mac80211 is buggy, and he
also thinks mac80211 should only do what he thinks wext defines.

See?

I wouldn't even object to making mac80211 try to associate when a key is
set, if you can make a clean enough patch (which I doubt). I do object
to calling this a bug because it's not, it's in line with what wext
users can rightfully expect.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: mac80211 regression: doesn't associate automatically

[Holger Schurig]

> Yes, but you're assuming "YYY" is a MAC address while in fact
> it can have two special meanings, "any" and "off", see the
> iwconfig man page.

Oh sorry, that was an oversight of me. Thanks for clarification.


> You understood: Johannes hates me, he thinks mac80211 is
> buggy, and he also thinks mac80211 should only do what he
> thinks wext defines.

Hate is too strong a word here :-)   I don't have feelings 
towards you (in person), but I perceiving you as one that is 
just "talking things away". And that is what I didn't liked, 
made me frustrated and shooting over the top.

Anyway, I want to drop that now.




Is my second sequence "which I dug out" also not a problem?

$ pccardctl insert
$ iwconfig eth1 key s:11111
$ iwconfig eth1 essid MUMBLEFUTZ
$ ifconfig eth1 up

This sequence is basically what Debian executes at "ifup eth1" 
time when no wpa_supplicant is used. And it doesn't lead to an 
association, not even to a scanning (according to iwevent) when 
used with mac80211/b43.

I hope that is a bug that is more difficult to talk away. :-)

Re: mac80211 regression: doesn't associate automatically

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1050 bytes --]


> Is my second sequence "which I dug out" also not a problem?

I have to admit I missed that.


> I hope that is a bug that is more difficult to talk away. :-)

Heh. I'll give my best ;)

> $ pccardctl insert
> $ iwconfig eth1 key s:11111
> $ iwconfig eth1 essid MUMBLEFUTZ
> $ ifconfig eth1 up
> 
> This sequence is basically what Debian executes at "ifup eth1" 
> time when no wpa_supplicant is used. And it doesn't lead to an 
> association, not even to a scanning (according to iwevent) when 
> used with mac80211/b43.

Yeah, I've been bitten by that too. It's pretty tough actually but
*should* be doable though I would much prefer to set it only after the
interface is up I can see... Thing is that before the iface is up the
interface mode isn't set in stone. So things like

iwconfig eth1 blabla
iwconfig eth1 mode monitor
iwconfig eth1 mode managed
ip link set eth1 up

can probably never work properly. In any case, we ought to fix this
though right now I don't know what the best way would be.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: mac80211 regression: doesn't associate automatically

[Will Dyson]

On Nov 24, 2007 4:36 PM, Johannes Berg <johannes@sipsolutions.net> wrote:

> Yeah, I've been bitten by that too. It's pretty tough actually but
> *should* be doable though I would much prefer to set it only after the
> interface is up I can see... Thing is that before the iface is up the
> interface mode isn't set in stone. So things like
>
> iwconfig eth1 blabla
> iwconfig eth1 mode monitor
> iwconfig eth1 mode managed
> ip link set eth1 up
>
> can probably never work properly. In any case, we ought to fix this
> though right now I don't know what the best way would be.

Ugh, yeah.

Would "bringing up a STA interface always triggers a scan" be too
horrible of a kludge to contemplate?

-- 
Will Dyson

Re: mac80211 regression: doesn't associate automatically

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 600 bytes --]


> > iwconfig eth1 blabla
> > iwconfig eth1 mode monitor
> > iwconfig eth1 mode managed
> > ip link set eth1 up
> >
> > can probably never work properly. In any case, we ought to fix this
> > though right now I don't know what the best way would be.
> 
> Ugh, yeah.
> 
> Would "bringing up a STA interface always triggers a scan" be too
> horrible of a kludge to contemplate?

Simply triggering a scan won't trigger association either though, will
it? So we'd have to manipulate the mlme state machine too. I don't like
it much but I guess we don't have too much choice.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: mac80211 regression: doesn't associate automatically

[Holger Schurig]

> Simply triggering a scan won't trigger association either
> though, will it? So we'd have to manipulate the mlme state
> machine too. I don't like it much but I guess we don't have
> too much choice.

In my case, an "iwlist eth1 scan" triggers a scan, and also 
always an association. Well, always = three times :-)


Also, there might be some race here. When I turned on my laptop 
and inserted the b43 card freshly, I *DID* get an association 
with my standard Debian script. After

$ pccarcctl eject
$ rmmod b43
$ rmmod ssb
$ pccardctl insert

I needed to trigger a scan.


It might also be the case that in this case the card was by 
change on the frequency of the AP (2.437 MHz).

Re: mac80211 regression: doesn't associate automatically

[Holger Schurig]

> * 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

I found a 7th driver that worked in this way: p54pci.ko

As it stands, I found not a single non-mac80211 WLAN driver where 
the sequence "ifconfig XXX up", "iwconfig XXX essid 
YYYY", "iwconfig XXX key ZZZZ" did get me an association.