Bug 356081

Summary: WLAN can't start on boot
Product: Red Hat Enterprise Linux 5 Reporter: Zenon Panoussis <redhatbugs>
Component: initscriptsAssignee: initscripts Maintenance Team <initscripts-maint-list>
Status: CLOSED DUPLICATE QA Contact: Brock Organ <borgan>
Severity: medium Docs Contact:
Priority: low    
Version: 5.0CC: dcbw
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-12-12 12:51:17 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:

Description Zenon Panoussis 2007-10-29 00:02:02 UTC
Description of problem:
If a WLAN interface uses WPA it won't start on boot bcause wpa_supplicant is not
up yet. As a result, various services that require an active network connection
(e.g. ntp) fail as well.

Version-Release number of selected component (if applicable):
8.45.14.EL-1.el5.centos.1, but I think it's identical to RHEL in the affected
parts. 

How reproducible:
Always.

Additional info:
See also bug #244029. Here's an alternative solution It won't work if /usr isn't
mounted, but it's better than nothing:

--- ifup-wireless.orig  2007-10-29 00:57:52.000000000 +0100
+++ ifup-wireless       2007-10-29 00:58:09.000000000 +0100
@@ -88,6 +88,11 @@
     iwpriv $DEVICE $IWPRIV
 fi

+if [ "$WPA" = "yes" -a -x /usr/sbin/wpa_supplicant ]; then
+    kill -9 `ps aux |grep wpa_supplicant |grep i$DEVICE |awk '{print $2 }'` &>
/dev/null
+    /usr/sbin/wpa_supplicant -B -Dwext -i$DEVICE
-c/etc/wpa_supplicant/wpa_supplicant.conf -d -w
+fi
+
 # ESSID need to be last : most device re-perform the scanning/discovery
 # when this is set, and things like encryption keys are better be
 # defined if we want to discover the right set of APs/nodes.

Comment 1 Dan Williams 2008-12-12 12:51:17 UTC
Any solution to this issue should be done as detailed in comment #12 of bug #154348; and will have to end up in Fedora first before getting into RHEL...

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