First I thought this was a bug with wpa_supplicant, thus I posted is a bug decription upstream:http://hostap.epitest.fi/bugz/show_bug.cgi?id=358. Further testing led to the following: With a 2.6.32 kernel the net.wlan0 script starts wpa_supplicant and wpa_cli as expected. Booting a 2.6.33 or higher kernel the script doesn't start the wpa_supplicant or wpa_cli, but it starts ifplugd on my wireless device (surprising?). I have not changed any configuration, just dual boot wirth the different kernels. I tested this with wpa_supplicant 0.6.9 0.7.1 and 0.7.2, 2.6.32-r7(gentoo), 2.6.32.9(vanilla), 2.6.33(gentoo) and 3.6.34(drm-radeon-testing branch by airlied). This may affect baselayout or ifplugd, but I'm not sure, thus I chose Application as Component. Best regards Jan Bücken Reproducible: Always Steps to Reproduce: 1. Boot 2.6.32 kernel: wpa_supplicant is started with net.wlan0 script 2. Boot >=2.6.33 kernel: wpa_supplicant doesn't start with the script but ifplugd does...
Uninstalled ifplugd, now I get: #/etc/init.d/net.wlan0 restart * Stopping wlan0 * Bringing down wlan0 * Shutting down wlan0 ... [ ok ] * Starting wlan0 * Configuration not set for wlan0 - assuming DHCP * Bringing up wlan0 * dhcp * Running dhcpcd ... wlan0: dhcpcd 4.0.15 starting wlan0: waiting for carrier wlan0: timed out
Hello Jan, please comment a `emerge --info` so that we see the baselayout version you use and such things. You might want to temper with rc_depend_strict and rc_hotplug in /etc/rc.conf, but that only applies to baselayput-2 afaik. I've net.wlan0 in the defaukt runlevel and it "complains" about wlan0 `started but inactive`. The content of your /etc/conf.d/net might be usefull to. Thanks, Michael
Created attachment 234373 [details] emerge --info
Created attachment 234375 [details] /etc/conf.d/net
Hello Michael, > I've net.wlan0 in the defaukt runlevel and it "complains" about wlan0 `started > but inactive`. With rc-status I found out that I never add net.wlan0 to any runlevel, but it has been started on boot. Now I add it to the runlevel "default", but it makes no difference to the problem.
Ok, so this is a baselayout-1 system. Did you accidentally add a `need net` service to the boot runlevel? net should be started in the default runlevel. Can I ask for the output of `rc-status --all`, please?
Created attachment 234385 [details] rc-status --all >Can I ask for the output of `rc-status --all`, please? Here it is.
(In reply to comment #6) > Ok, so this is a baselayout-1 system. > Did you accidentally add a `need net` service to the boot runlevel? I believe not that one of the services in "boot" needs net (except net.lo?), but could it be similar to this bug: http://bugs.gentoo.org/show_bug.cgi?id=224639 ?
I have the same problem with baselayout-2.0.1 and gentoo-sources-2.6.34. Starting /etc/init.d/net.wlan0 starts either iwconfig if wireless-tools is installed, otherwise dhcpcd is tried directly. wpa_supplicant does work manually, though. Can I provide additional information?
I did a kernel regression test. This commit changes the behaviour of gentoo between 2.6.32 and 2.6.33 (for me): commit 3d23e349d807177eaf519d444677cee86b1a04cf Author: Johannes Berg <johannes@sipsolutions.net> Date: Tue Sep 29 23:27:28 2009 +0200 wext: refactor Refactor wext to * split out iwpriv handling * split out iwspy handling * split out procfs support * allow cfg80211 to have wireless extensions compat code w/o CONFIG_WIRELESS_EXT After this, drivers need to - select WIRELESS_EXT - for wext support - select WEXT_PRIV - for iwpriv support - select WEXT_SPY - for iwspy support except cfg80211 -- which gets new hooks in wext-core.c and can then get wext handlers without CONFIG_WIRELESS_EXT. Wireless extensions procfs support is auto-selected based on PROC_FS and anything that requires the wext core (i.e. WIRELESS_EXT or CFG80211_WEXT). Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com> drivers/net/wireless/Kconfig | 29 +- drivers/net/wireless/hostap/Kconfig | 2 + drivers/net/wireless/ipw2x00/Kconfig | 5 + drivers/net/wireless/orinoco/Kconfig | 2 + include/net/cfg80211.h | 6 +- include/net/iw_handler.h | 14 +- include/net/net_namespace.h | 2 +- include/net/wext.h | 49 +- net/core/net-sysfs.c | 6 +- net/socket.c | 4 +- net/wireless/Kconfig | 50 +- net/wireless/Makefile | 8 +- net/wireless/core.c | 14 +- net/wireless/ibss.c | 10 +- net/wireless/mlme.c | 2 +- net/wireless/nl80211.c | 4 +- net/wireless/scan.c | 6 +- net/wireless/sme.c | 12 +- net/wireless/wext-core.c | 1063 ++++++++++++++++++++ net/wireless/wext-priv.c | 248 +++++ net/wireless/wext-proc.c | 155 +++ net/wireless/wext-spy.c | 231 +++++ net/wireless/wext.c | 1775 ---------------------------------- 23 files changed, 1850 insertions(+), 1847 deletions(-)
Created attachment 234945 [details] git bisect log between 2.6.32 (good) and 2.6.33 (bad)
This has to be reported upstream since it is not related to gentoo-sources explicitely :) Please open a bug on http://bugzilla.kernel.org and post here the link of the upstream bug Thank you for you time on performing a git bisect . It will be really helpfull to upstream developers
(In reply to comment #12) > This has to be reported upstream since it is not related to gentoo-sources > explicitely :) IMHO, this is a gentoo bug, because gentoo does not start the correct script anymore! It seems to me that gentoo "believe" that "wlan0" is an ethernet device, and not an wirless device. Thus gentoo starts ifplugd and not wpa_supplicant. It is not a kernel bug if they change their architecture. The driver (ath5k) works with iwconfig/ifconfig.
Further informations: Tried drm-radeon-testing (based on 2.6.35-rc3, don't think that stable vanilla behaves different) As I said, ifplugd is started on wlan0 instead of wpa_supplicant and dhcpd. Kernel log says: ifplugd(wlan0): Initialization complete, link beat not detected. Now I started the wpa_supplicant manually and enabled a network: Surprisingly ifplugd now detects a link beat and tries to start wpa_supplicant, too! But now two wpa_supplicant are running and thus, wlan0 gets a connect and disconnect event alternating (this bug can be reproduced with to instances of wpa_supplicant on a 2.6.32). Thus I restarted wlan0 with the init script and killed ifplugd with $iflugd -i wlan0 -k Then started wpa_supplicant again and tried to connect, but I had to run $dhcpd wlan0 extra, otherwise I did not get an IP. With this set-up, wlan works. Thus two questions rise up: Is it corecct that ifplugd starts on wlan devices (does not make sense for me)? Is it possible to force link beat detection on wirless devices? (This could be a workaround, since ifplugd seems to start the right things after link beat detection)
(In reply to comment #12) > This has to be reported upstream since it is not related to gentoo-sources > explicitely :) I also do not think this is a kernel bug. As I said, I can start wpa_supplicant and dhcpcd manually and everything works fine. I am also on a baselayout-2 system and not on baselayout-1. I assume that the way wireless devices are reported in the kernel has changed. This is probably an openrc bug? I will provide additional information if you tell me what you need. This is quite annoying, since I have to start the network manually on every boot and many services cannot start due to the unsatisfied net dependency. Perhaps there is a kernel configuration option which needs to be set in order for openrc to properly detect the wireless device?
Sorry, about the noise, I probably have been hit by bug #277594 instead. I will check this tonight.
yeah, sorry, I obviously commented on the wrong bug, so ignore everything I said here. My problem is solved using the workaround from bug #277594.
I'm having this problem too. Under gentoo-sources-2.6.32, "net.wlan0 start" starts wpa_supplicant as expected: * Starting wlan0 * Starting wpa_supplicant on wlan0 ... [ ok ] * Starting wpa_cli on wlan0 ... [ ok ] [ ok ] * Backgrounding ... But with gentoo-sources-2.6.33+, it tries to run netplug (which should never happen with a wireless interface), and wpa_supplicant never gets started: * Starting wlan0 * Starting netplug on wlan0 ... [ ok ] * Backgrounding ... and I wind up with two netplugd processes running. Killing the new netplugd process and manually starting wpa_supplicant and dhcpcd gets me a working network. I'm using baselayout-1, like Jan Buecken, but I have netplug installed instead of ifplugd.
NEW INFO: sysfs is involved: In bug #277594 , comment 277594#c18 Denis decribe a workaround. The problem is: /lib/rcscripts/net/wpa_supplicant.sh looks in function wpa_supplicant_exists for an entry in /proc/net/wireless but its empty, or it looks for /sys/class/net/$1/wireless but this directory was not generatet on my system. Thus, Denis workaround to use /proc/net/dev instead /proc/net/wireless fixed it. But the real fix should be that sysfs / ath5k or whatever creates the wirless directory in /sys/class/net/wlan0/. I'll find out if this file exists with the 2.6.32 kernel.
(In reply to comment #19) > But the real fix should > be that sysfs / ath5k or whatever creates the wirless directory in > /sys/class/net/wlan0/. > > I'll find out if this file exists with the 2.6.32 kernel. > No, the wireless file does not exist with 2.6.32.9 vanilla. But /proc/net/wireless has the wlan0 entry.
Denis just posted a second (IMHO better) workaround: Turning on CONFIG_WIRELESS_EXT_SYSFS kernel option works for me (then you don't need to edit /lib/rcscripts/net/wpa_supplicant.sh) But the kernel-help says that CONFIG_WIRELESS_EXT_SYSFS is deprecated. Is it now a problem with wpa_supplicant, kernel or gentoo that /proc/net/wireless is empty? Should the wpa_supplicant.sh script check /proc/net/dev? What is a real fix and not a workaround (with deprecated files...)? greetings
This workaround did the trick for me. Thanks! (Now I can continue installing Gentoo on my computer :) (In reply to comment #21) > Denis just posted a second (IMHO better) workaround: > > Turning on CONFIG_WIRELESS_EXT_SYSFS kernel option works for me > (then you don't need to edit /lib/rcscripts/net/wpa_supplicant.sh) > > But the kernel-help says that CONFIG_WIRELESS_EXT_SYSFS is deprecated. > > Is it now a problem with wpa_supplicant, kernel or gentoo that > /proc/net/wireless is empty? > Should the wpa_supplicant.sh script check /proc/net/dev? > What is a real fix and not a workaround (with deprecated files...)? > > greetings >
(In reply to comment #21) > Denis just posted a second (IMHO better) workaround: > > Turning on CONFIG_WIRELESS_EXT_SYSFS kernel option works for me > (then you don't need to edit /lib/rcscripts/net/wpa_supplicant.sh) > > But the kernel-help says that CONFIG_WIRELESS_EXT_SYSFS is deprecated. > > Is it now a problem with wpa_supplicant, kernel or gentoo that > /proc/net/wireless is empty? Has nothing to do with wpa_supplicant, nor the kernel. The wpa_supplicant.sh script mentioned above is checking for the deprecated /proc/net/wireless, so that's where the problem is. Wicd on Launchpad confirmed this as well: https://bugs.launchpad.net/wicd/+bug/415719/comments/5. I'm way too lazy to find the kernel diff on it. Another workaround, is to put the following in /etc/conf.d/net, so it starts cause you called -D wired, and added another -D with the actual driver you need. Here, wpa_supplicant moves on to use the nl80211 for example: wpa_supplicant_wlan0="-D wired -D nl80211"
Yet another workaround here (the cleanest of all mentioned imho): add "!plug" into the modules line in the /etc/conf.d/net In my case I changed from modules_wlan0="wpa_supplicant" to modules_wlan0="wpa_supplicant !plug" enjoy!
Pretty sure that this is a duplicate of #311803.
UNLESS... and I strongly recommend this: we make this bug specifically for baselayout-1, because #311803 is specifically baselayout-2. And I would love to see baselayout-1 fixed. In which case this bug's summary should probably be changed to: sys-apps/baselayout-1: wpa_supplicant.sh fails to find wireless interface on >=gentoo-sources-2.6.33 A little bit long, but I think it's appropriate. And best of all, I think the fix is trivial: the script just has to look for the "phy80211" directory in addition to "wireless" and "wiphy" in /sys/class/net/<if>. Thanks to Jan Buecken for shedding most of the light on that. What do the rest of you (especially baselayout team) think?
Sorry for the noise, but actually the summary should be: sys-apps/baselayout-1: wpa_supplicant.sh fails to find nl80211 interface on >=gentoo-sources-2.6.33 Since it can of course find interfaces that have Wireless Extensions enabled.
Just encountered this after changing from ipw2200 to ath9k. The problem is that /proc/net/wireless is not populated until after the interface is associated and not just ifconfig up'd AFIACT. Adding "phy80211" to wpa_supplicant.sh fixes issue for me.
(In reply to comment #26) > UNLESS... and I strongly recommend this: we make this bug specifically for > baselayout-1, because #311803 is specifically baselayout-2. And I would love > to see baselayout-1 fixed. In which case this bug's summary should probably be > changed to: > > sys-apps/baselayout-1: wpa_supplicant.sh fails to find wireless interface on > >=gentoo-sources-2.6.33 > This bug is independent from the baselayout version. It should appear on baselayout-1 and 2. Thus bug #311803 could be a dublicate from this bug or from bug #277594. Note that 277594 and this bug are independent!
(In reply to comment #29) > > This bug is independent from the baselayout version. It should appear on > baselayout-1 and 2. Thus bug #311803 could be a dublicate from this bug or from > bug #277594. Note that 277594 and this bug are independent! I think it is dependent on baselayout-1, because baselayout-2 uses openrc scripts that look for phy80211, not wiphy, which works for kernel >=2.6.33. I'm not quite sure what is going on in #311803 because as I pointed out in that bug, wpa_supplicant does start. #277594 may actually be a bug in wpa_supplicant but probably needs to be retested with the latest packages. Now that I've looked at a bunch of wpa_supplicant/baselayout bugs, I think this one is actually a duplicate of #307191.
(In reply to comment #30) > Now that I've looked at a bunch of wpa_supplicant/baselayout bugs, I think this > one is actually a duplicate of #307191. Yes, seems to be the same reason. > I'm not quite sure what is going on in #311803 because as I pointed out in > that bug, wpa_supplicant does start. I'm on baselayout-2 now, but I remember that wpa_supplicant started without the init script. I had to start it by hand with the command. But wpa_supplicant didn't work, the deamon was listet in (h)top. *** This bug has been marked as a duplicate of bug 307191 ***
