Bug 244029
Summary: | wpa_supplicant does not work on boot | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Andrew Gormanly <a.gormanly> | ||||
Component: | wpa_supplicant | Assignee: | Dan Williams <dcbw> | ||||
Status: | CLOSED DUPLICATE | QA Contact: | |||||
Severity: | low | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | rawhide | CC: | ade.rixon, casualprogrammer, cdahlin, dedourek, dr, fche, jerry.levan, jos, lemenkov, martinthain99, mdc1, miles, nnm.one, pb, rsandu2004, scottro11, sergei.litvinenko, ziotibia1 | ||||
Target Milestone: | --- | Keywords: | Reopened | ||||
Target Release: | --- | ||||||
Hardware: | All | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | 0.5.7-20.fc8 | Doc Type: | Bug Fix | ||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2008-12-12 12:54:35 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Bug Depends On: | |||||||
Bug Blocks: | 373961 | ||||||
Attachments: |
|
Description
Andrew Gormanly
2007-06-13 13:35:03 UTC
Created attachment 156873 [details]
trivial patch that changes chkconfig order and makes wpa_supplicant wait
Very good hint, works perfectly for me. Only flaw is: the line - daemon $prog -c $conf $INTERFACES $DRIVERS -B should read - daemon $prog -c $conf $interfaces $drivers -B as in the original /etc/init.d/wpa_supplicant (0.5.7-3) file, this is in error. Thanks for pointing this out! I can confirm that this is working: adding option "-w" to wpa_supplicant and changing chkconfig option to "09 91" See also https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=197319 It can't start before network, because it's in /usr, and that means that network-mounted-usr will break wpa_supplicant... What's the problem with it starting _after_ network, really? It shouldn't matter when it starts up as long as the INTERFACE and DRIVER are correct. As pointed out in the discussion in Bug 197319 wpa_supplicant will not associate when key is set to "off". While experimenting with this, I could connect with WPA_SUPPLICANT at boot time ONLY when Network had associated with some WEP network beforehand. If network does not associate, key is set to off and wpa_supplicant does nothing. As I pointed out in Comment #2 the solution suggested in Comment #1 works nicely on boot. There remain problems with switching between networks, but they may well be driver related. So where you get your conviction that it can't start before network comes from is questionnable. Just try it out. Not sure why in a final release an experimental driver has to be incorporated. Intels states at their website at http://intellinuxwireless.org/index.php?p=iwlwifi NOTE: The iwlwifi driver is a development driver. If you are looking for a fully validated and stable driver, please visit the Intel Customer Support download page. The ipw3945 seemed to work pretty well lately. key being off doesn't have much to do with wpa_supplicant, since wpa_supplicant can certainly do all the WEP setup irregardless of whether or not the network scripts have. If you put "wep_key0" and "wep_tx_keyidx" in the wpa_supplicant config file, it'll connect to that WEP network when it finds it from a scan. I'm saying that wpa_supplicant doesn't _need_ to start before network, for two reasons. #1 that it just doesn't need to, and #2 that it's in /usr, and on a network-mounted-usr system, it'll break because /usr isn't mounted until _after_ network starts. I might add though that most people using network-mounted-usr probably aren't using wireless, so that's not as important. However, I'm not going to change the package without a clear reason why starting it after network won't work. iwlwifi isn't quite ready yet and so using it as a basis for testing isn't appropriate; it's got driver/stack bugs that make the tests pretty much invalid. What does you wpa_supplicant.conf look like? Well, something is definitely wrong with the setup of wireless as is. For me the case is clear, I do what serves my purpose ( Comment #1 ). The question remains for you and the Fedora team how you are going to attract Notebook users if wireless doesn't work right. As far as I understand Intels website, iwlwifi is what Fedora calls iwl3945. ( Though this has nothing to do with this issue, it still seems to add instabilities. ) My wpa_supplicant.conf reads: ctrl_interface=/var/run/wpa_supplicant ctrl_interface_group=wheel update_config=1 network={ ssid="any" key_mgmt=NONE disabled=1 } network={ ssid="my wpa ap" psk=myscrambledsecret proto=RSN key_mgmt=WPA-PSK pairwise=CCMP disabled=0 } network={ ssid="my wep ap" key_mgmt=NONE wep_key0="mysecretwep128key" disabled=1 } I can connect to any AP in sight with wpa_supplicant and wpa_gui (hence update_config=1, and all settings are provided by wpa_gui). It works also when network starts first, but not during boot ( dhclient times out, no NTP sync ). Only exception: when network associates to the wep ap during boot, wpa_supplicant takes over seamless. Hope this helps. In reply to https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=244029#c4, 2 issues are rising up here: 1) if wpa_supplicant can't be started before S10network, then perhaps my prior solution (pointed out in https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=197319#c13) would fit better, here start of wpa_supplicant is trigged during initializing a wireless interface (proper work proven around 2 months) 2) if start of wpa_supplicant prior to S10network is prohibited because of absence of /usr, then in principle this produce a henn-egg problem at all, because in theory it can happen that NFS mount is done via a wireless interface with WPA protection...so to catch this case, wpa_supplicant stuff has to move to /{bin,sbin} instead. Re: comment #8 2) As I pointed out before, this does not seem to be a valid assumption. After fixing boot logging ( see bugs 163461 and 151238 ) I can now show you my boot.log: Jun 20 06:14:15 workstation6l syslog: syslogd startup succeeded Jun 20 06:14:15 workstation6l syslog: klogd startup succeeded Jun 20 06:14:18 workstation6l kudzu: succeeded Jun 20 06:14:19 workstation6l cpuspeed: succeeded Jun 20 06:14:20 workstation6l iptables: succeeded Jun 20 06:14:20 workstation6l iptables: succeeded Jun 20 06:14:21 workstation6l wpa_supplicant: wpa_supplicant startup succeeded Jun 20 06:14:22 workstation6l network: Bringing up loopback interface: succeeded Jun 20 06:14:25 workstation6l NET[2065]: /sbin/dhclient-script : updated /etc/resolv.conf Jun 20 06:14:25 workstation6l network: Bringing up interface wlan0: succeeded Jun 20 06:14:25 workstation6l auditd: auditd startup succeeded Jun 20 06:14:26 workstation6l restorecond: restorecond startup succeeded Jun 20 06:14:26 workstation6l irqbalance: irqbalance startup succeeded Jun 20 06:14:26 workstation6l mcstrans: mcstransd startup succeeded Jun 20 06:14:26 workstation6l rpcbind: rpcbind startup succeeded Jun 20 06:14:26 workstation6l setroubleshoot: setroubleshootd startup succeeded Jun 20 06:14:27 workstation6l nfslock: rpc.statd startup succeeded Jun 20 06:14:28 workstation6l rpcidmapd: rpc.idmapd startup succeeded Jun 20 06:14:28 workstation6l messagebus: messagebus startup succeeded Jun 20 06:14:29 workstation6l openct: Initializing OpenCT smart card terminals: succeeded Jun 20 06:14:29 workstation6l bluetooth: hcid startup succeeded Jun 20 06:14:29 workstation6l bluetooth: sdpd startup succeeded Jun 20 06:14:30 workstation6l netfs: Mounting other filesystems: succeeded Jun 20 06:14:30 workstation6l pcscd: pcscd startup succeeded Jun 20 06:14:30 workstation6l hidd: hidd startup succeeded Jun 20 06:14:31 workstation6l winbind: winbindd startup succeeded Jun 20 06:14:31 workstation6l autofs: Load autofs4 succeeded Jun 20 06:14:32 workstation6l autofs: automount startup succeeded Jun 20 06:14:32 workstation6l rc: Starting autofs: succeeded Jun 20 06:14:32 workstation6l acpid: acpid startup succeeded Jun 20 06:14:32 workstation6l hplip: hpiod startup succeeded Jun 20 06:14:33 workstation6l hplip: hpssd.py startup succeeded Jun 20 06:14:33 workstation6l snmpd: snmpd startup succeeded Jun 20 06:14:34 workstation6l cups: cupsd startup succeeded Jun 20 06:14:35 workstation6l sshd: succeeded Jun 20 06:14:35 workstation6l xinetd: xinetd startup succeeded Jun 20 06:14:45 workstation6l ntpd: succeeded Jun 20 06:14:45 workstation6l ntpd: ntpd startup succeeded Jun 20 06:14:46 workstation6l sendmail: sendmail startup succeeded Jun 20 06:14:46 workstation6l sendmail: sm-client startup succeeded Jun 20 06:14:46 workstation6l nasd: nasd startup succeeded Jun 20 06:14:46 workstation6l ConsoleKit: ConsoleKit startup succeeded Jun 20 06:14:47 workstation6l crond: crond startup succeeded Jun 20 06:14:47 workstation6l smolt: succeeded Jun 20 06:14:47 workstation6l xfs: xfs startup succeeded Jun 20 06:14:48 workstation6l smb: smbd startup succeeded Jun 20 06:14:48 workstation6l anacron: anacron startup succeeded Jun 20 06:14:48 workstation6l atd: atd startup succeeded Jun 20 06:14:49 workstation6l dhcdbd: dhcdbd startup succeeded Jun 20 06:14:50 workstation6l yum-updatesd: yum-updatesd startup succeeded Jun 20 06:14:52 workstation6l avahi-daemon: S98avahi-daemon startup succeeded Jun 20 06:14:55 workstation6l haldaemon: haldaemon startup succeeded Jun 20 06:14:58 workstation6l smartd: smartd startup succeeded Re: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=244029#c9 Sure does it work (like here also), but as mentioned in https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=244029#c4, the startup sequence must take care, that it can happen, that /usr is mounted as network file system. This means until S25netfs is started, all commands used in initscripts have to be located in /bin or /sbin. wpa_supplicant is currently located at /usr/sbin/wpa_supplicant. So best way would be to put wpa_supplicant to /sbin. Thanks for the explanation :-) The issue still exists on on F8, and here another issue rises up after applying the workaround, at least driver "madwifi" requires now a running messagebus, but this is started not until S27 (it requires e.g. $syslog). So the issue get's now a little more complicated. Imho, following needs to be fixed: messagebus must be start at S08 (possible, is located in /bin) wpa_supplicant must be still moved to /sbin, then starting at S09 FYI: network is starting at S10 Perhaps (r)syslog should start as S07... Current F8 versions: wpa_supplicant-0.5.7-15.fc8 dbus-1.1.2-7.fc8 I've changed the start priorities according to upper shown values, afterwards the wifi works fine using WPA. @owner: please change version of this bug to "F8" and perhaps also the severity to "medium", because noone taked care about this issue switching from F7 to F8. *** Bug 197319 has been marked as a duplicate of this bug. *** *** Bug 245462 has been marked as a duplicate of this bug. *** *** Bug 248448 has been marked as a duplicate of this bug. *** *** Bug 375721 has been marked as a duplicate of this bug. *** Whilst this is being sorted out I have got my wpa_supplicant to come up at boot by using a workaround which adds the following 4 lines to /etc/rc.local /bin/sleep 1 /sbin/service wpa_supplicant start /bin/sleep 2 /sbin/dhclient eth1 By the time I have completed login to kde the wireless link is up. However it would be nice to have this long-standing issue resolved. YMMV *** Bug 337001 has been marked as a duplicate of this bug. *** Hello, I have a very annoying issue about the wireless interface (Broadcom Corporation Dell Wireless 1390 WLAN Mini-PCI Card) not starting at boot on a Dell Inspiron 1520 notebook. Part of it seems to be related to this bug (please see bugs #373961 and #337001 for full details). Regarding wpa_supplicant, here's the exact message I get at boot: Starting wpa_supplicant: /etc/wpa_supplicant/wpa_supplicant.conf, , dbus_bus_get[ctrl_iface_dbus]: No such file or directory. Failed to initialize wpa_supplicant. In the mean time, I use the following procedure to start wireless: - enter X startx - become root su - - manually restart wpa_supplicant after system initialization service wpa_supplicant restart - manually launch wlassistant to authenticate through WPA2 and get IP address from DHCP wlassistant Is there any canonical fix for all this, please ? I'm using Fedora 8. Thanks a lot, Răzvan Hello, Just to say that the manual procedure described in comment #19 fails (in wlassistant stage) if NetworkManager and NetworkManagerDispatcher run in background while performing this... Răzvan Note that the startup flags of wpa_supplicant can be customized by changing /etc/sysconfig/wpa_supplicant to be whatever you want them to be. If you need it to wait for interfaces, add the -w option to the command line there. If you would like to turn off the D-Bus interface functionality, take out the -u. In comment 21 I presume you meant to refer to /etc/init.d/wpa_supplicant? Making it wait sounds like a good plan - but ideally it should wait and then use dbus - so if this functionality does work then this would solve the problem. This is going on since June 2007, all that users want is connect to their AP during boot. Don't you think you are getting carried away guys? A practical solution was offered in comment #1, why don't you just implement it for the sake of users not interested in the religious aspects of Fedora/Linux ? I have just tried the "solution" offered in #1 with a fully up to date f8 system - and it does not work! The dbus error still happens during boot and wpa_supplicant does not start. Yes this needs to be fixed but there is clearly a lot more that has happened since the original OP's report which seems not to have been investigated to the point where there is a real solution yet. I can confirm that the latest update (wpa_supplicant.i386-1:0.5.7-16.fc8) still gives the dbus error message when booting, however my wireless connects to my AP without any problem. confirm the problem, too! :( :( What's the current status of this bug - why it's so hard just to change order of startup scripts? Fedora-provided wpa_supplicant completely useless in case of DHCP in protected wireless networks right now. I have also tried wpa_supplicant-0.5.7-17.fc8 in updates testing this morning and this also fails to fix the problem. It is worth noting that in my case there is an error message that appears during boot but this does not result in any line in /var/log/messages. However I have previously posted a screen image in https://bugzilla.redhat.com/show_bug.cgi?id=375721 see Comment #1 in this bz for what it still looks like during boot. This should refer to the bz reported in the line above of course! This bug prevents a network-manager-less, hard-coded wireless network from working. Should it be reassociated with fedora 8 to get some more action? Yes, this was already requested in Comment #11 If you wish to use wpa_supplicant at boot time, please remove the "-u" flag /etc/init.d/wpa_supplicant. A future update will move the -u flag from /etc/init.d/wpa_supplicant to an option in /etc/sysconfig/wpa_supplicant instead, which is the right place for local system modification. Does that sound acceptable? *** Bug 385191 has been marked as a duplicate of this bug. *** whenever it finishes, please test: http://koji.fedoraproject.org/koji/taskinfo?taskID=271866 - Add logrotate config file (rh #404181) - Add new LSB initscript header to initscript with correct deps (rh #244029) - Move other runtime arguments to /etc/sysconfig/wpa_supplicant (In reply to comment #34) > If you wish to use wpa_supplicant at boot time, please remove the "-u" flag > /etc/init.d/wpa_supplicant. [...] > Does that sound acceptable? That removes the dbus dependency, and works. However, it does not appear to solve the reverse ordering of /etc/init.d/network vs. /etc/init.d/wpa_supplicant. No, it won't do that. But with the dynamic LSB provides/requires which I built in comment #36, there might not be a way to do that. Does the LSB stuff allow specifying an init dependency (in this case in network) which might not exist on the system? If the network initscript wer modified to depend on $wpa_supplicant but the wpa_supplicant RPM was not installed, what happens? This also doesn't touch on the problem of wpa_supplicant being in /usr/sbin and being a dependency of the network scripts, which of course totally breaks network mounted /usr. But we've sort of agreed that the network mounted /usr case is _not_ one we are going to continue working around. It'll just break and it'll be up to those people to fix stuff up. (In reply to comment #38) > No, it won't do that. But with the dynamic LSB provides/requires which I built > in comment #36, there might not be a way to do that. Does the LSB stuff allow > specifying an init dependency (in this case in network) which might not exist on > the system? If the network initscript wer modified to depend on $wpa_supplicant > but the wpa_supplicant RPM was not installed, what happens? > There is a Should-start dependancy directive that will do just what you want. However none of the LSB deps will be respected until we get some new init code in place (I'm working on that myself :) ) Oh. The patch you linked enforces the dependencies. Sorry for the confusion (I'm working on a prcsys replacement for parallelizing bootup, so depsolving is only one facet). Well, if the network scripts could _conditionally_ start wpa_supplicant, provided it were available, that would be fine. If Should-start does that, then problem solved (except for network mounted /usr people). From http://refspecs.freestandards.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/initscrcomconv.html Should-Start: boot_facility_1 [boot_facility_2...] facilities which, if present, should be available during startup of this service. This allows for weak dependencies which do not cause the service to fail if a facility is not available. The service may provide reduced functionality in this situation. Conforming applications should not rely on the existence of this feature. wpa_supplicant-0.5.7-19.fc8 has been pushed to the Fedora 8 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update wpa_supplicant' The wpa_supplicant-0.5.7-19.fc8 still fails for me on boot. The following is what is showing up on /var/log/wpa_supplicant.log: Could not acquire the system bus. Could not acquire the system bus. I seemed to have found a fix to get wpa_supplicant to boot. I went into /etc/rc5.d and changed the start priority of wpa_supplicant from S26 to S29, message bus is set at S27. The reason wpa_supplicant was not finding the system bus on boot was because it was not started yet, at least that was the case for my system. I hope this helps. I just installed wpa_supplicant-0.5.7-19.fc8 - looks like this bug still exists: [root@Sulaco rc.d]# chkconfig --del wpa_supplicant [root@Sulaco rc.d]# chkconfig --del messagebus [root@Sulaco rc.d]# chkconfig --del network [root@Sulaco rc.d]# chkconfig --add messagebus [root@Sulaco rc.d]# find -name *mess*|sort ./init.d/messagebus ./rc0.d/K73messagebus ./rc1.d/K73messagebus ./rc2.d/S27messagebus ./rc3.d/S27messagebus ./rc4.d/S27messagebus ./rc5.d/S27messagebus ./rc6.d/K73messagebus [root@Sulaco rc.d]# chkconfig --add wpa_supplicant [root@Sulaco rc.d]# find -name *wpa*|sort ./init.d/wpa_supplicant ./rc0.d/K74wpa_supplicant ./rc1.d/K74wpa_supplicant ./rc2.d/K74wpa_supplicant ./rc3.d/S26wpa_supplicant ./rc4.d/S26wpa_supplicant ./rc5.d/S26wpa_supplicant ./rc6.d/K74wpa_supplicant [root@Sulaco rc.d]# chkconfig --add network [root@Sulaco rc.d]# find -name *netw*|sort ./init.d/network ./rc0.d/K90network ./rc1.d/K90network ./rc2.d/S10network ./rc3.d/S10network ./rc4.d/S10network ./rc5.d/S10network ./rc6.d/K90network [root@Sulaco rc.d]# It's clear that messagebus still started *after* wpa_supplicant. Network started before wpa_supplicant also, so encrypted wi-fi-connections are fubared completely. Changing /etc/init.d/wpa_supplicant according to this comment from Reindl Harald ( https://bugzilla.redhat.com/show_bug.cgi?id=385191#c10 ) fixes issue with messagebus. Network still starts earluer than wpa_supplicant. I just added "Required-Start: wpa_supplicant" to /etc/init.d/network script, and everything works fine. *** Bug 426648 has been marked as a duplicate of this bug. *** *** Bug 425021 has been marked as a duplicate of this bug. *** @peter: don't want to add Required-Start: for network because not all configurations need it, and it'll fail if wpa_supplicant isn't installed. Instead, there's apparently a tag that suggests that network start wpa_supplicant if it's installed. Please test http://koji.fedoraproject.org/koji/taskinfo?taskID=309411 and see how it works WRT initscript start priorities. Will push this as an update to F8-updates-testing when it's built. Yes, now it works and WLAn will be connected at boot-time The change from "$messagebus" to "messagebus" as i reuqestet at https://bugzilla.redhat.com/show_bug.cgi?id=385191 does the trick wpa_supplicant-0.5.7-20.fc8 has been pushed to the Fedora 8 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update wpa_supplicant' Just tested this version - it does indeed now work now, and wpa_supplicant starts up normally and without error with chkconfig wpa_supplicant on selected before reboot. This is excellent and congratulations on fixing this long standing problem. Further testing reveals that it does work fine with the ipw2200 driver in my Dell D610. It also works with the rt73usb driver from the in-kernel rt2x00 module for the Edimax usb wireless dongle running in an Amilo D6800 laptop. However for a third machine (Samsung Q35) running the iwl3945 in-kernel driver the wpa_supplicant will only run from boot if the -u flag is removed from /etc/sysconfig/wpa_supplicant I will test this further but this is the only case which fails on tests so far. I just tested this. Although wpa_supplicant started without error, my wireless interface wouldn't get an address until, after startup, I ran dhclient on it. However, this is definitely better--at one point, I'd had to rearrange S10Network, S12wpa_supplicant and S27messagebus. At present, I can leave messagebus alone, but I have to (for a small home network) reverse the order of S10 and S12 for it to work. (This is with the 2200 Intel card.) I can confirm https://bugzilla.redhat.com/show_bug.cgi?id=244029#c56, which does not really help me in default configuration, I have also to change the priorites of wpa_supplicant from 28 to 09 (before network). Regarding https://bugzilla.redhat.com/show_bug.cgi?id=244029#c51, why not simply put a minor extension into ifup-wireless, which starts the wpa_supplicant if needed? Add a simple WPA=yes to ifcfg-<interface> and check this value in ifup-wireless. This works well as I've tested some months ago. On #56 - yes you need dhclient - I added "dhclient eth1" (or whichever wireless interface for the machine) to /etc/rc.local and it is fine. I'm sure that will work, since it's what I did manually. I'll give it a shot tonight, and as this thread is already quite long, will only report back if it doesn't work. Thanks. wpa_supplicant-0.5.7-20.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report. Hello, It seems it still doesn't work for me, on a Dell Inspiron 1520 ( http://www.smolts.org/show?UUID=38d4ab1d-340f-40c5-b104-1b7cf81bc966) Both eth0 and wlan0 are configured via System -> Administration -> Network to start at boot and should take IP address via DHCP. wlan0 says FAIL during boot. Wireless Acces Point is a D-Link DWL-G700AP, configured with WPA2 and preshared key. Is there any "canonical" written procedure to configure wireless links on Fedora 8 ? I will double-check... SO is Fedora 8 + all updates, as of January 08, 2008. Regards, Răzvan Razvan: wpa_supplicant has nothing to do with system-config-network and ifup/ifdown, so it shouldn't be relevant to your problem. There are a few ways to configure wireless, using NetworkManager, using system-config-network + ifup/ifdown, and by using wpa_supplicant directly. In reply to #61 i it is any help Răzvan my setup procedure is at http://www-users.york.ac.uk/~mdc1/fedora_wireless.html Hello, Thank you, Mike, for the detailed procedure in comment #63 ! However, I didn't managed to automatically start wpa_supplicant on my Dell Inspiron 1521... Hardware configuration is given in comment #61. Below are my relevant configuration files: /etc/sysconfig/wpa_supplicant # Use the flag "-i" before each of your interfaces, like so: # INTERFACES="-ieth1 -iwlan0" INTERFACES="-iwlan0" # Use the flag "-D" before each driver, like so: # DRIVERS="-Dwext" DRIVERS="-Dwext" # Other arguments # -u Enable the D-Bus interface (required for use with NetworkManager) # -f Log to /var/log/wpa_supplicant.log OTHER_ARGS="-u -f" /etc/sysconfig/network-scripts/ifcfg-wlan0 # Please read /usr/share/doc/initscripts-*/sysconfig.txt # for the documentation of these parameters. TYPE=Wireless DEVICE=wlan0 HWADDR=00:1c:26:54:9e:86 BOOTPROTO=dhcp DHCP_HOSTNAME=host.example.com ONBOOT=no USERCTL=yes IPV6INIT=no PEERDNS=yes ESSID=mynetwork CHANNEL=6 MODE=Managed PEERNTP=no /etc/rc.d/rc.local #!/bin/sh # # This script will be executed *after* all the other init scripts. # You can put your own initialization stuff in here if you don't # want to do the full Sys V style init stuff. touch /var/lock/subsys/local /bin/sleep 1 /sbin/service wpa_supplicant start /bin/sleep 2 /sbin/dhclient wlan0 /etc/wpa_supplicant/wpa_supplicant.conf ctrl_interface=/var/run/wpa_supplicant ctrl_interface_group=wheel eapol_version=1 ap_scan=1 fast_reauth=1 network={ ssid="mynetwork" key_mgmt=WPA-EAP proto=WPA RSN pairwise=CCMP TKIP group=CCMP TKIP psk="mypasswd" priority=1 } The AP is configured for WPA2 with PSK. When I do "service wpa_supplicant restart", I get: [root@mazarin ~]# service wpa_supplicant restart Stopping wpa_supplicant: [ OK ] Starting wpa_supplicant: /etc/wpa_supplicant/wpa_supplicant.conf, -iwlan0, -Dwextioctl[SIOCSIWAUTH]: Operation not supported WEXT auth param 4 value 0x0 - [ OK ] The connection *does* work with the manual procedure I've described in comment #19. Regards, Răzvan One thing worth trying is to change the line OTHER_ARGS="-u -f" to OTHER_ARGS="-f" i.e. remove the -u flag in /etc/sysconfig/wpa_supplicant For my iwl3945 machine I also get an operation not supported message when I start wpa_supplicant, but it does work despite the message. For this machine I do remove the -u flag and it then works. Try this - it might work for you also. Hello, I've tried the one suggested in comment #65, it does'nt work, at least on my Dell Inspiron 1520. Bref: On the Dell Inspiron 1520, wireless networking *does work*, but it requires a manual restart of wpa_supplicant, using wlassistant and *no* NetworkManager. This reflects the state of facts for Fedora 8 + online updates as for February 3, 2008. Regards, Răzvan Don't know why this bug was closed - tyhis issue still exists. *** Bug 430176 has been marked as a duplicate of this bug. *** These tickets are also interesting https://bugzilla.redhat.com/show_bug.cgi?id=154348 https://bugzilla.redhat.com/show_bug.cgi?id=356081 Are you using the 'network' service or NetworkManager? (In reply to comment #70) > Are you using the 'network' service or NetworkManager? service 'network' [petro@Sulaco devel]$ grep chkconfig /etc/init.d/{network,messagebus,wpa_supplicant} /etc/init.d/network:# chkconfig: - 10 90 /etc/init.d/messagebus:# chkconfig: 345 22 85 /etc/init.d/wpa_supplicant:# chkconfig: - 23 88 [petro@Sulaco devel]$ So what's your /etc/wpa_supplicant/wpa_supplicant.conf file say, and what is your /etc/sysconfig/wpa_supplicant file contain? [petro@Sulaco devel]$ sudo cat /etc/wpa_supplicant/wpa_supplicant.conf ctrl_interface=/var/run/wpa_supplicant ctrl_interface_group=wheel network={ ssid="Nostromo" scan_ssid=1 key_mgmt=WPA-PSK pairwise=TKIP psk=<some_chars_and_numbers> } [petro@Sulaco devel]$ sudo cat /etc/sysconfig/wpa_supplicant INTERFACES="-iwlan0" DRIVERS="-Dwext" [petro@Sulaco devel]$ Ok, now we need the logs from wpa_supplicant. Can you add "-dddt -f /var/log/wpa_supplicant.log" to OTHER_ARGS in /etc/sysconfig/wpa_supplicant, reboot, wait a bit, then attach /var/log/wpa_supplicant.log? I'll do, but what good is it? It's clearly seen that network starts earlier than wpa_supplicant, and fails getting IP via DHCP in protected wi-fi network. Thus far, I see the only solution - we should change wpa_supplicant script in order to start earlier than network (as it proposed many times)... or we should finally switch to Upstart :) BTW are any reasons which prevents you from changing # chkconfig: - 23 88 to # chkconfig: - 9 88 (In reply to comment #75) > I'll do, but what good is it? > > It's clearly seen that network starts earlier than wpa_supplicant, and fails > getting IP via DHCP in protected wi-fi network. This is the order it *should* be, see below... > Thus far, I see the only solution - we should change wpa_supplicant script in > order to start earlier than network (as it proposed many times)... or we should > finally switch to Upstart :) It's been proposed many times, and rejected many times, because wpa_supplicant has dependencies on other services that start later than 9. > > BTW are any reasons which prevents you from changing > > # chkconfig: - 23 88 > > to > > # chkconfig: - 9 88 Where does D-Bus start at? It's 22. Thus, the supplicant has to start after D-Bus, because a user can use the '-u' option which requires D-Bus. The solution is really to not make the supplicant a service at all. You either use NetworkManager in which case things start up correctly, and we *correctly* integrate the supplicant into the network scripts, which has been detailed in the bug this is duped against. *** This bug has been marked as a duplicate of bug 154348 *** |