Bug 197319 - wpa_supplicant initialized after network devices
Summary: wpa_supplicant initialized after network devices
Status: CLOSED DUPLICATE of bug 244029
Alias: None
Product: Fedora
Classification: Fedora
Component: wpa_supplicant   
(Show other bugs)
Version: 5
Hardware: All Linux
Target Milestone: ---
Assignee: Dan Williams
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2006-06-30 05:40 UTC by Casey Dahlin
Modified: 2014-06-18 08:46 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-11-13 16:43:06 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
tiny fix to wpa_supplicant init script (1.61 KB, text/plain)
2006-06-30 05:46 UTC, Casey Dahlin
no flags Details
sample patch for ifup-wireless to account for wpa_supplicant (1.52 KB, patch)
2006-07-07 03:03 UTC, John Guthrie
no flags Details | Diff
Small patch to ifup-eth to check for wpa_supplicant (801 bytes, text/plain)
2006-10-11 21:11 UTC, John Guthrie
no flags Details
Patch to allow the $KEY variable in ifup-ethX to take the values 'WPA' or 'WPA2' (1.23 KB, patch)
2007-01-16 18:32 UTC, John Guthrie
no flags Details | Diff

Description Casey Dahlin 2006-06-30 05:40:09 UTC
By default, the init script to start wpa_supplicant is priority 12, and the init
script to start the network is priority 10. The result is any interface set to
initialize on boot that must communicate via WPA will fail to initialize,
because wpa_supplicant is not available to encrypt its dhcp request.

The quickest solution is to change wpa_supplicant's init priority to 9, placing
it immediately before network initialization.

Comment 1 Casey Dahlin 2006-06-30 05:46:25 UTC
Created attachment 131778 [details]
tiny fix to wpa_supplicant init script

Very small change to wpa_supplicant init script. Sets default chkconfig info to
put the script in at priority 9. Install by copying to /etc/rc.d/init.d and
overwriting file. Note that if wpa_supplicant has already been added to any
runlevels when the file is copied, it must be removed and re-added for the
changes to take effect.

Comment 2 Bill Nottingham 2006-06-30 16:41:30 UTC
There is a resetpriorities option to chkconfig that can be used to change the
priorities on installed systems.

Comment 3 Casey Dahlin 2006-06-30 20:43:59 UTC
(In reply to comment #2)
> There is a resetpriorities option to chkconfig that can be used to change the
> priorities on installed systems.

I thought that might be the case. The chkconfig usage mentions the command but
the man page does not. I'll file another bug with the documentation if appropriate.

Comment 4 John Guthrie 2006-07-07 02:59:50 UTC
I found that there is one slight problem with this.  Namely, the wpa_supplicant
runs and initializes the wireless devices as they need to be.  But when
/etc/init.d/network runs, it calls ifup, which calls ifup-eth, which in turn
figures that the device is a wireless device, and then calls ifup-wireless. 
That script then tries to set WEP keys.  If there are no WEP keys in the
ifcfg-{interface_name} file, then ifup-wireless does the following:

iwconfig $DEVICE key off

I.e., it turns off encryption.  Since I am sometimes in a network where the keys
are dynamic, I can't just set WEP keys.  (I don't want to set any keys since
those are supposed to be negotiated by WPA2.)  The end result is that when DHCP
is attempted, there is no encryption, and the interface still fails to come up.
 The ifup-wireless script doesn't seem to make any allowance for WPA/WPA2.

It would be easy to fix this by doing a check for a running wpa_supplicant
process, and then run the WEP key set up only if such a process is not running.
I am attaching a sample patch to illustrate this.  There may be other, better
methods, and we may want to protect more items in ifup-wireless this way. 
(Conceivably, we could check for the existence of wpa_supplicant at the start of
ifup-wireless, and if wpa_supplicant is running, then don't do anything.)

Comment 5 John Guthrie 2006-07-07 03:03:40 UTC
Created attachment 132038 [details]
sample patch for ifup-wireless to account for wpa_supplicant

This patch to ifup-wireless will keep ifup-wireless from clobbering encryption
settings that may have been put in place by wpa_supplicant.  (This assumes that
wpa_supplicant has been set to run before /etc/rc.d/init.d/network.)

Comment 6 Andrew Benham 2006-08-17 10:13:39 UTC
I moved S12wpa_supplicant to S09wpa_supplicant, and then changed the daemon
options in /etc/init.d/wpa_supplicant from -B to -Bw

Might be better to set "OPTIONS=-B" in /etc/sysconfig/wpa_supplicant and do
     daemon $prog -c $conf $INTERFACES $DRIVERS $OPTIONS
in /etc/init.d/wpa_supplicant, then users can tweak the RPMs config file and
not get stuffed when upgrading.

I've left the WEP keys in the appropriate profile files to avoid the above problem.

Comment 7 John Guthrie 2006-10-11 21:11:35 UTC
Created attachment 138279 [details]
Small patch to ifup-eth to check for wpa_supplicant

I know this might be late for the current product cycle, but the change made
above isn't quite sufficient as it turns out, even with the -B flag.  The
problem lies in the ifup-eth and ifup-wireless scripts.  In ifup-eth, we have
the following lines:

# is the device wireless? If so, configure wireless device specifics
is_wireless_device ${DEVICE} && . ./ifup-wireless

So even if we have wpa_supplicant already running, then the script
ifup-wireless gets run.  Now if we inside of ifup-wireless, we find several
things to set ESSID, CHANNEL, and static WEP keys.  Even if we are trying to
run wpa_supplicant using WPA/WPA2.  So whether or not I have a static WEP key
set, the session key that wpa_supplicant has established is going to get
written over, and my networking goes nowhere.  All of this happens and then
dhclient tries to find a server and amusment follows.... ;-)

What I have done, is I have added a check to make certain that wpa_supplicant
isn't running before trying to run ifup-wireless.  See the attched patch file. 
Realistically, there's no need to run ifup-wireless if wpa_supplicant is
running, since wpa_supplicant can handle static WEP.  I don't know if this
patch is the most elegant way to accomplish this goal, but it certainly seems
to work.  This along with the patch above changing the relative boot order of
wpa_supplicant and network should give us what we want I think.


Comment 8 John Guthrie 2006-11-07 19:48:45 UTC
Just as a note, this problem is still occuring in FC6.  wpa_supplicant starts,
and then the ifup-wireless script clobbers any WPA encryption that gets set up.

Comment 9 Pavel Polischouk 2006-11-13 19:07:33 UTC
Adding the line


into /etc/sysconfig/network-scripts/keys-ethX

fixes the "killing the encryption" problem without modifying any stock scripts
like ifup-wireless. Setting the key to 000000000 instead of disabling encryption
altogether doesn't disrupt wpa_supplicant operation. 000000000 seems to be the
reserved key value during authentication phase (correct me if I'm wrong). This
setting works with xsupplicant (WEP+TKIP) as well.

Comment 10 John Guthrie 2007-01-16 18:32:43 UTC
Created attachment 145714 [details]
Patch to allow the $KEY variable in ifup-ethX to take the values 'WPA' or 'WPA2'

So it turns out that for a while there, setting


did the trick, but now something has changed, I don't know if it was the kernel
or the wireless-tools package, but now when I set $KEY as above, I get a WEP
key of all zeroes after the ifup scripts have run, not a WPA/WPA2 key.	This,
of course, breaks the encryption again.  If I leave $KEY unset, then the
ifup-wireless script unsets all encryption, so that is not an option.  Instead,
I came up with a different idea:  if $KEY is set to either the string 'WPA' or
the string 'WPA2', then don't touch the encryption at all.  Since, 'W' and 'P'
are not valid hexadecimal characters, we know that these strings can't be WEP
keys in hex format.  We also know that they can't be WEP keys in passphrase
format, since those have to be either 5 or 13 characters, IIRC.  Thus, if we
see these phrases in $KEY, then we know we shouldn't be doing anything even
touches WEP.  This also has the benefit of not depending on wpa_supplicant, so
a different program, such as xsupplicant, could be used if one so wished.

I am attaching a patch to change ifup-wireless to accomplish this.  This patch
assumes that one is using the current ifup-eth script from the distribution, so
don't apply any of my previous patches to that script.	My patch only checks
for $KEY and $KEY1, since from what I've been able to test here at home, $KEY2,
$KEY3, $KEY4 don't seem to have any effect on WPA/WPA2.  I have tested this
script and it seems to work as desired.

Right now, there is no difference between setting $KEY to 'WPA' or 'WPA2', but
they are both allowed should we need to distinguish between them in the future.
 In order for this to really be effective, we will probably need to fix the
system-config-network* package.  This is because right now, this configuration
option has no coupling that I know of to whether or not wpa_supplicant is
actually running.  That is, a user must turn on both this option *and*
wpa_supplicant to get WPA to work.  Being who I am, this doesn't bother me at
all.  But it is a place for improvement in the user-interface.

Any comments?

Comment 11 John Guthrie 2007-01-16 18:35:28 UTC
I forgot to mention that the previous patch was against an FC6 machine.  I don't
know if FC5 is having the same problem for a KEY of all zeroes.

Comment 12 Wolfgang Rupprecht 2007-03-04 01:20:43 UTC
I changed the starting order number from 12 to 9 by editing the
chkconfig line for /etc/init.d/wpa_supplicant and then re-ran
"chkconfig wpa_supplicant on".

     emacs /etc/init.d/wpa_supplicant 
     < chkconfig:   - 12 88
     > chkconfig:   - 9 88

This same fix is needed for fc5 and fc6.

Can someone please commit this or something similar that fixes the
problem?  This bug has been NEW/HIGH for 8 months now.

Comment 13 Peter Bieringer 2007-03-19 21:30:15 UTC
About the wpa_supplicant start's too late there is an additional issue: if WLAN
device is not present on boot (e.g. plugged-in on PCMCIA later) wpa_supplicant
won't start at all

My current workaround is to disable autostart of wpa_supplicant and add an
extension to ifup-wireless:

--- ifup-wireless.orig  2007-03-19 21:27:53.000000000 +0100
+++ ifup-wireless       2007-03-19 21:29:22.000000000 +0100
@@ -97,3 +97,7 @@
     # use any essid
     iwconfig $DEVICE essid any >/dev/null 2>&1
+if [ "$WPA" = "yes" -a ! -f /var/lock/subsys/wpa_supplicant ] ; then
+    service wpa_supplicant start

Also I set WPA=yes to related ifcfg-$device
Perhaps one could also the KEY variable for that, but then the ifup-wireless
script needs more patching.

BTW: my system is FC6

Comment 14 Wolfgang Rupprecht 2007-06-02 19:58:48 UTC
I'd like to underscore Peter's fix to ifup-wireless.  Without realizing he
already figured this out I was investigating why a wpa_supplicant started before
the networking code was no longer associating correctly under fedora-7.  It
appears that wpa_supplicant now loops between "associating" and "failed"
endlessly if it is started before the nework interface is brought up.  Starting
wpa_supplicant after init.d/network causes the dhclient call inside the network
script to fail, so this isn't an option either.  The simplest fix was to start
wpa_supplicant from the end of ifup-wireless.  For the record I'll include my
hack.  (I think Peter's is cleaner though.)  One interesting side effect is that 
the association under fc6, when I started wpa_supplicant before the network
bringup, was relatively slow.  It would take 10-15 seconds for ath0 to come up. 
Now the association and dhclient getting an ip address is lightning fast.  The n
network startup works so much better now.  This is clearly where wpa_supplicant
startup should be.

# wsrcc start
if [ ! -S /var/run/wpa_supplicant/$DEVICE -a \
   -f /etc/sysconfig/network-scripts/ifcfg-$DEVICE ]
    . /etc/sysconfig/network-scripts/ifcfg-$DEVICE
    wpa_supplicant -c /etc/wpa_supplicant/wpa_supplicant.conf \
# wsrcc end

Comment 15 Casual J. Programmer 2007-06-16 09:07:36 UTC
This has been reported almost a year ago against fc5 it is still not fixed in f7
and status is still "NEW" although above various remedies have been suggested.
What's wrong here ?

Comment 16 Casual J. Programmer 2007-06-18 07:19:54 UTC
To me this looks like a duplicate of Bug 244029, the solution suggested by
Andrew works perfectly for me.

Comment 17 Peter Bieringer 2007-06-18 18:58:03 UTC
I can confirm that the hint in
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=244029 works perfectly by
adding option "-w" to wpa_supplicant and changing chkconfig option to "09 91"

Comment 18 Dan Williams 2007-11-13 16:43:06 UTC

*** This bug has been marked as a duplicate of 244029 ***

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