Hide Forgot
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.
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.
There is a resetpriorities option to chkconfig that can be used to change the priorities on installed systems.
(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.
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.)
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.)
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.
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. JTG
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.
Adding the line KEY=000000000 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.
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 KEY=0000000000 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?
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.
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.
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 fi + +if [ "$WPA" = "yes" -a ! -f /var/lock/subsys/wpa_supplicant ] ; then + service wpa_supplicant start +fi 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
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 ] then . /etc/sysconfig/network-scripts/ifcfg-$DEVICE wpa_supplicant -c /etc/wpa_supplicant/wpa_supplicant.conf \ -i$DEVICE -D$WSRCC_WPA_DRIVER -B fi # wsrcc end
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 ?
To me this looks like a duplicate of Bug 244029, the solution suggested by Andrew works perfectly for me.
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"
*** This bug has been marked as a duplicate of 244029 ***