FS#13299 - [initscripts] /etc/rc.d/network WIRELESS_TIMEOUT check doesn't work all the time
Attached to Project:
Arch Linux
Opened by Aaron Griffin (phrakture) - Monday, 16 February 2009, 04:10 GMT
Last edited by James Rayner (iphitus) - Tuesday, 02 March 2010, 10:07 GMT
Opened by Aaron Griffin (phrakture) - Monday, 16 February 2009, 04:10 GMT
Last edited by James Rayner (iphitus) - Tuesday, 02 March 2010, 10:07 GMT
|
Details
The current wireless implementation in /etc/rc.d/network
uses $(iwgetid $INTERFACE -ar) to check if it is associated
with an AP before continuing. Apparently this doesn't work
all the time. I know Thomas reported it being
quasi-functional for him, and for me my wireless appears to
NEVER associate with an AP until dhcp is run.
I'm not sure of a proper fix for this, but I would recommend removing this check completely, and just relying on WIRELESS_TIMEOUT for the sleep. I have commented the AP check out on my machine and it works great. |
This task depends upon
There's two downsides to disabling the check:
- It means that association may go longer than necessary
- People will receive DHCP fail messages when they're really having association problems, due to incorrect key, essid, range, etc.
I'll make some changes to the present wireless code, making the check "opt out".
I'd like to try and move to the wpa_supplicant/dbus based wireless as soon as I can, it _shouldn't_ have these sorts of problems, though I really have no idea. The code's written, its working, I just need to package it and put it in testing. I'll do that now.
What driver? I'm guessing this is your Thinkpad?
I still think this is odd behaviour, so maybe an option to opt-out, or opt-in of the check?
If I do the following:
ifconfig wlan0 up
iwconfig wlan0 essid foobar
...wait for some time...
iwgetid wlan0 -ar
I get the invalid MAC address... always. I never get an AP listed. I ran it in a loop sleeping 1 second in-between and never got a valid AP. However, dhcpcd works fine.
While I agree that this is broken, the check is also broken if it requires an AP before running dhcpcd. The DHCP request will fail on its own if there is no AP, so I wonder why this check is even needed. Perhaps if the next step (dhcp or whatever) fails, THEN we could check to see if there's an AP so we can output an informational message.
For the record - this has actually never worked for me - using either ndiswrapper, madwifi, or ath5k (current)
Just checking, it does show an AP after dhcp has worked?
Could you please give netcfg in [core] a test and see if it is also affected? /etc/network.d/examples/wep.example is the appropriate example config. If it also fails, could you comment out the line that includes "wep_check" in /usr/lib/network/wireless.subr and replace it with sleep 20?
Thanks!
I have tomato firmware, set wireless to WEP, 64bit. I'm borrowing my girlfriend's eeePC which has ath5k, ubuntu, 2.6.27, dhclient
Case 1 - fail
rmmod ath5k; modprobe ath5k;
iwconfig wlan0 essid rayner key 017CF3C0EE
iwgetid wlan0 -ra reports 00:00:00:00:00:00.
dhclient brings the interface up, allowing it to associate and then get an IP.
Case 2 - works
rmmod ath5k; modprobe ath5k;
ifconfig wlan0 up (or ip link set wlan0 up)
iwconfig wlan0 essid rayner key 017CF3C0EE
iwgetid wlan0 -ra reports the AP mac correctly.
The interface is already up, allowing ath5k to associate before dhcp.
In /etc/rc.d/network, It does not do ifconfig wlan0 up/ip link set wlan0 up before attempting to set wireless settings.
This does not affect my ieee80211 stack based ipw2100 as ifconfig up/down does not enable/disable the driver/hardware in any way.
The ifconfig up as suggested _should_ fix any issue. The check was failing because the device had not been brought up, and thus had not associated. Without the check, DHCP was bringing the interface up and allowing it to associate.
--
Hatem
In my testing on similar hardware adding "ifconfig up" fixes it. It makes sense too.
This saturday is "bug day", so ping me then and I will do more vigorous testing if you want it
The original bug was due to the wireless check, trying to see if an access point has associated with the interface. And from my understanding this only happens when settling with IP addresses (I believe that the protocol, but I need to double check).
Now what in the patch I did is split up the check such that it was done after the IF UP line. Thus only checking if the association occurred after settling on the ip address :)
I kinda like the patch - James, what do you think?
This patch resolved a really annoying bug for me. Provided it meets with you approval, I would really love to see this merged into [core].
The proposed patch is a "workaround". Using dhcpcd/ifconfig to bring the interface up later on when it should be explicitly done beforehand, and then moving the check out of logical sequence.
That's what I think. *shrug*
Solved by adding "/sbin/ifconfig $wlan_${1} up" between the iwconfig and the sleep command
Solved by adding "/sbin/ifconfig $wlan_${1} up" between the iwconfig and the sleep command
The patch (I am sure you noticed) is for the init script, which is used to bring up the interface. As Thomas mentioned, this is the "only proper implementation".
To associate with an accesspoint you need to use the iface. if the iface is down the check will most certainly fail. If the iface is up, then the check will have a purpose.
iwconfig will still work fine if the interface is not up. So rather than calling ifconfig, iwconfig, and ifconfig again, this patch maintains the exact same order (iwconfig, ifconfig). It just moves the check until after ifconfig is called to bring up the device.
My only qualm is that now the check is being called for all interfaces, without a check to see if it is a wireless interface first.
Presently, iwconfig is run, there's a 2 second sleep (or more) to allow for association, and then ifconfig/dhcp runs. On cards affected by this bug that 2 second sleep does nothing, as the device has not been brought up.
Hatem: Presently iwconfig is only called if someone configures a wlan_ line. Whether you think two calls the ifconfig is ideal or not, it is the proper implementation.
a) It breaks out the check, which is nice.
b) Does the check AFTER dhcp/ifconfig/whatever is run, not before
See, if this check was done AFTER dhcp, this problem never ever would have appeared. As I said, commenting the check out works completely fine for me. My interface works perfectly, but the check was aborting early. Not only does it address the problem, but it also addresses the REASON the problem existed in the first place.
If you're going to add an "ifconfig up" in there, that's fine. BUT, please at least move the check much later, as this patch does.
I have acquired a ZyDAS WLA-54L WiFi and it doesn't work with /etc/rc.d/network, because "ifconfig wlan0 up" has to be run for it to associate. Could someone please apply the patch, upon which everybody seemed to agree long ago?
--- network 2009-05-20 22:33:54.984146784 +0300
+++ /etc/rc.d/network 2009-05-20 22:34:33.589417597 +0300
@@ -38,6 +38,7 @@
eval iwcfg="\$wlan_${1}"
[ "$iwcfg" = "" ] && return 0
+ /sbin/ifconfig $iwcfg up
/usr/sbin/iwconfig $iwcfg
[[ -z "$WIRELESS_TIMEOUT" ]] && WIRELESS_TIMEOUT=2
sleep $WIRELESS_TIMEOUT
I think the reason the patch you mentioned was not applied is that it causes "ifconfig wlan up" to be called more than once (exactly two times). This is somewhat of a hack. If you see the patch I posted a while back, it calls only modifies the order in which things happen and does not introduce such hacks.
I am not sure why its taking this long, due to this delay I have noticed that Arch maybe bleeding edge with respect to packages, but they are quite slow at actually fixing things :(. I have currently moved away from Arch, I may come back later to see if things have changed.
Many wireless cards will not begin authenticating and will not begin associating until the device has been brought up. Notably all the mac80211 based drivers. As a result the association check will always fail on these devices.
Have a look at this logfile from wpa_supplicant. Line 10. The first thing it does after loading it's configuration is to bring the device up. First bringing the device up is neccesary for association. And association is necessary for further configuration.
Phrakture or anyone with initscripts commit access, could you merge the attached patch?
The patch is made with just a "diff oldfile newfile". Anyone know of a howto for making the git style patches?
I merged in James' change (simply adding an ifconfig up at the top of the ifup function)
It will be in the next initscripts package
From git HEAD:
$ grep "\<up\>" network
/sbin/ifconfig $ifname up
# bring up bridge interfaces
# bring up ethernet interfaces
# bring up bond interfaces
# bring up routes
ifconfig is called twice, yes, but the "up" simply brings the interface up so we can associate properly
So has this acceptable fix been merged yet? It sounds like there was resolution, but the merging to initscripts might not have happened yet.
http://projects.archlinux.org/initscripts.git/commit/?id=ac3baddf04b62e4bb55f7a2d0d34d78191ac815d
If folks haven't been having this problem anymore since the 2009.08-1 initscripts release, can we call this fixed?