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)
On Fri, 2007-11-23 at 14:34 -0500, Will Dyson wrote:
> On Nov 23, 2007 7:48 AM, Johannes Berg <[email protected]> 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
> 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.
> 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.
[what's so hard about copying me?]
Bottom line is, I don't care.
johannes
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
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
> 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
> 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
> > 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
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
> 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
> * 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.
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
> 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;
> }
>
> 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. :-)
> > 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.
> 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.
On Nov 24, 2007 4:36 PM, Johannes Berg <[email protected]> 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
> 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 :-)
> 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 ... :-)
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
[email protected]
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
> 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.
> 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).
On Nov 23, 2007 7:48 AM, Johannes Berg <[email protected]> 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
[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
> > 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
> > 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.
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
On Nov 22, 2007 11:19 AM, Holger Schurig <[email protected]> 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