Bug 356081 - WLAN can't start on boot
WLAN can't start on boot
Status: CLOSED DUPLICATE of bug 154348
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: initscripts (Show other bugs)
5.0
All Linux
low Severity medium
: ---
: ---
Assigned To: initscripts Maintenance Team
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-10-28 20:02 EDT by Zenon Panoussis
Modified: 2008-12-12 07:51 EST (History)
1 user (show)

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


Attachments (Terms of Use)

  None (edit)
Description Zenon Panoussis 2007-10-28 20:02:02 EDT
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 07:51:17 EST
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 ***

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