Bug 244029 - wpa_supplicant does not work on boot
wpa_supplicant does not work on boot
Status: CLOSED DUPLICATE of bug 154348
Product: Fedora
Classification: Fedora
Component: wpa_supplicant (Show other bugs)
rawhide
All Linux
medium Severity low
: ---
: ---
Assigned To: Dan Williams
: Reopened
: 197319 245462 248448 linwille@redhat.com 375721 385191 425021 426648 430176 (view as bug list)
Depends On:
Blocks: 373961
  Show dependency treegraph
 
Reported: 2007-06-13 09:35 EDT by Andrew Gormanly
Modified: 2008-12-12 07:54 EST (History)
18 users (show)

See Also:
Fixed In Version: 0.5.7-20.fc8
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-12-12 07:54:35 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
trivial patch that changes chkconfig order and makes wpa_supplicant wait (652 bytes, patch)
2007-06-13 09:35 EDT, Andrew Gormanly
no flags Details | Diff

  None (edit)
Description Andrew Gormanly 2007-06-13 09:35:03 EDT
Description of problem:
In F7 /etc/rc5.d wpa_supplicant is started after network, which produces no
network connection because the client is unauthenticated when it tries to DHCP.

Version-Release number of selected component (if applicable):
wpa_supplicant-0.5.7-3.fc7.x86_64

How reproducible:
Every time

Steps to Reproduce:
1. Boot
2.
3.
  
Actual results:
Network comes up

Expected results:
Network interface has no associated IP address

Additional info:
Moving the start order of wpa_supplicant to be before network, and adding the -w
flag in the init script, fixes this.  I've made a simple patch to show the
necessary trivial changes.
Comment 1 Andrew Gormanly 2007-06-13 09:35:03 EDT
Created attachment 156873 [details]
trivial patch that changes chkconfig order and makes wpa_supplicant wait
Comment 2 Casual J. Programmer 2007-06-18 02:29:09 EDT
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!


Comment 3 Peter Bieringer 2007-06-18 14:58:57 EDT
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
Comment 4 Dan Williams 2007-06-19 12:54:00 EDT
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.
Comment 5 Casual J. Programmer 2007-06-19 14:08:59 EDT
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.

Comment 6 Dan Williams 2007-06-19 14:22:10 EDT
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?
Comment 7 Casual J. Programmer 2007-06-19 15:57:50 EDT
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.
Comment 8 Peter Bieringer 2007-06-19 17:56:18 EDT
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.
Comment 9 Casual J. Programmer 2007-06-20 00:26:39 EDT
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
 
Comment 10 Peter Bieringer 2007-06-20 02:04:15 EDT
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.
Comment 11 Casual J. Programmer 2007-06-20 03:32:07 EDT
Thanks for the explanation :-)


Comment 12 Peter Bieringer 2007-11-11 13:35:36 EST
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.
Comment 13 Dan Williams 2007-11-13 11:43:07 EST
*** Bug 197319 has been marked as a duplicate of this bug. ***
Comment 14 Dan Williams 2007-11-13 11:43:17 EST
*** Bug 245462 has been marked as a duplicate of this bug. ***
Comment 15 Dan Williams 2007-11-13 11:43:23 EST
*** Bug 248448 has been marked as a duplicate of this bug. ***
Comment 16 Dan Williams 2007-11-13 11:43:36 EST
*** Bug 375721 has been marked as a duplicate of this bug. ***
Comment 17 Mike Cohler 2007-11-13 12:20:13 EST
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
Comment 18 Răzvan Sandu 2007-11-15 14:40:52 EST
*** Bug 337001 has been marked as a duplicate of this bug. ***
Comment 19 Răzvan Sandu 2007-11-15 14:56:19 EST
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
Comment 20 Răzvan Sandu 2007-11-15 15:29:00 EST
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
Comment 21 Dan Williams 2007-11-15 15:45:27 EST
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.
Comment 22 Mike Cohler 2007-11-15 17:41:56 EST
In comment 21 I presume you meant to refer to /etc/init.d/wpa_supplicant?
Comment 23 Mike Cohler 2007-11-15 17:52:17 EST
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.
Comment 24 Casual J. Programmer 2007-11-15 18:08:16 EST
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 ?
Comment 25 Mike Cohler 2007-11-15 18:51:45 EST
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. 
Comment 26 Jackie 2007-11-15 22:46:50 EST
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. 
Comment 27 Kevin P. 2007-11-16 04:54:41 EST
confirm the problem, too! :( :( 
Comment 28 Peter Lemenkov 2007-11-16 05:46:20 EST
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.
Comment 29 Mike Cohler 2007-11-16 07:05:23 EST
I have also tried wpa_supplicant-0.5.7-17.fc8 in updates testing this morning
and this also fails to fix the problem.
Comment 30 Mike Cohler 2007-11-16 09:55:56 EST
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. 
Comment 31 Mike Cohler 2007-11-16 10:02:21 EST
This should refer to the bz reported in the line above of course!
Comment 32 Frank Ch. Eigler 2007-12-02 14:48:41 EST
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?
Comment 33 Daniel Roesen 2007-12-02 15:35:41 EST
Yes, this was already requested in Comment #11
Comment 34 Dan Williams 2007-12-03 09:57:30 EST
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?
Comment 35 Dan Williams 2007-12-03 13:54:36 EST
*** Bug 385191 has been marked as a duplicate of this bug. ***
Comment 36 Dan Williams 2007-12-03 14:33:12 EST
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
Comment 37 Frank Ch. Eigler 2007-12-04 11:31:22 EST
(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.
Comment 38 Dan Williams 2007-12-04 12:10:24 EST
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.
Comment 39 Casey Dahlin 2007-12-04 15:03:05 EST
(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 :) )
Comment 40 Casey Dahlin 2007-12-04 15:05:12 EST
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).
Comment 41 Dan Williams 2007-12-04 15:31:30 EST
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).
Comment 42 Casey Dahlin 2007-12-04 15:46:57 EST
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.
Comment 43 Fedora Update System 2007-12-07 16:31:18 EST
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'
Comment 44 Jackie 2007-12-08 12:38:02 EST
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.
Comment 45 Jackie 2007-12-09 12:10:40 EST
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.
Comment 46 Peter Lemenkov 2007-12-23 11:51:33 EST
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.
Comment 47 Peter Lemenkov 2007-12-23 12:04:03 EST
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.
Comment 48 Peter Lemenkov 2007-12-23 12:09:38 EST
I just added "Required-Start: wpa_supplicant" to /etc/init.d/network script, and
everything works fine. 
Comment 49 Bill Nottingham 2007-12-23 23:19:55 EST
*** Bug 426648 has been marked as a duplicate of this bug. ***
Comment 50 Dan Williams 2007-12-24 17:34:04 EST
*** Bug 425021 has been marked as a duplicate of this bug. ***
Comment 51 Dan Williams 2007-12-24 17:39:22 EST
@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.
Comment 52 Reindl Harald 2007-12-26 07:33:25 EST
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
Comment 53 Fedora Update System 2007-12-28 12:15:32 EST
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'
Comment 54 Mike Cohler 2007-12-28 14:53:20 EST
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.
Comment 55 Mike C 2007-12-29 11:27:03 EST
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.
Comment 56 Scott Robbins 2007-12-30 21:17:04 EST
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.)

Comment 57 Peter Bieringer 2007-12-31 04:07:34 EST
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.
Comment 58 Mike C 2007-12-31 07:25:06 EST
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.
Comment 59 Scott Robbins 2007-12-31 07:39:46 EST
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.
Comment 60 Fedora Update System 2008-01-06 20:20:11 EST
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.
Comment 61 Răzvan Sandu 2008-01-08 14:21:39 EST
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
Comment 62 Dan Williams 2008-01-08 15:19:56 EST
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.
Comment 63 Mike C 2008-01-08 15:57:05 EST
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
Comment 64 Răzvan Sandu 2008-01-15 15:25:14 EST
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
Comment 65 Mike C 2008-01-16 05:16:11 EST
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.

Comment 66 Răzvan Sandu 2008-02-03 05:08:02 EST
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
Comment 67 Peter Lemenkov 2008-12-11 16:12:10 EST
Don't know why this bug was closed - tyhis issue still exists.
Comment 68 Peter Lemenkov 2008-12-11 16:15:26 EST
*** Bug 430176 has been marked as a duplicate of this bug. ***
Comment 69 Peter Lemenkov 2008-12-11 16:21:14 EST
These tickets are also interesting

https://bugzilla.redhat.com/show_bug.cgi?id=154348
https://bugzilla.redhat.com/show_bug.cgi?id=356081
Comment 70 Dan Williams 2008-12-11 16:26:25 EST
Are you using the 'network' service or NetworkManager?
Comment 71 Peter Lemenkov 2008-12-11 16:35:15 EST
(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]$
Comment 72 Dan Williams 2008-12-11 16:43:45 EST
So what's your /etc/wpa_supplicant/wpa_supplicant.conf file say, and what is your /etc/sysconfig/wpa_supplicant file contain?
Comment 73 Peter Lemenkov 2008-12-11 16:56:16 EST
[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]$
Comment 74 Dan Williams 2008-12-11 17:55:08 EST
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?
Comment 75 Peter Lemenkov 2008-12-12 04:10:35 EST
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
Comment 76 Dan Williams 2008-12-12 07:54:35 EST
(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 ***

Note You need to log in before you can comment on or make changes to this bug.