Bug 154348

Summary: Adds support for WPA (Wi-Fi Protected Access) to the ifup* and ifdown* series of scripts located in /etc/sysconfig/network-scripts/.
Product: [Fedora] Fedora Reporter: Inertia <technoyippie>
Component: initscriptsAssignee: Lukáš Nykrýn <lnykryn>
Status: CLOSED EOL QA Contact: Brock Organ <borgan>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: agilmore, a.gormanly, clodoaldo.pinto.neto, david, dcbw, initscripts-maint-list, jfrieben, mattdm, mdevaev, mike, pb, psimerda, redhatbugs, roth, rtc, shinkoi2005, yates
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: All   
OS: Linux   
URL: http://www.ces.clemson.edu/linux/auto_connect.shtml
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-08-11 23:41:52 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Attachments:
Description Flags
Adds support for WPA.
none
Patch to spec file to enable WPA (requires previous patch)
none
Updated initscript patch
none
Updated spec file patch
none
Patch for Fedora 12
none
Patch for Fedora 12 with wpa_supplicant state checks
none
New version of WPA-patch for F13 none

Description Inertia 2005-04-10 14:14:25 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050323 Firefox/1.0.2 Fedora/1.0.2-1.3.1

Description of problem:
The (to be attached) patch adds support for WPA (Wi-Fi Protected Access) to the ifup* and ifdown* scripts located in /etc/sysconfig/network-scripts/.  The patch is quite small, since it does not modify any of the existing gui tools such as system-config-network.  Until system-config-network is updated, users wishing to use this feature would have to manually modify ifcfg-* scripts.

The intent is to add support for WPA in steps:
1. add support to the initscripts (this patch)
2. update system-config-network to reflect the new functionality

This patch is based on information provided at the URL:
http://www.ces.clemson.edu/linux/auto_connect.shtml


Version-Release number of selected component (if applicable):
initscripts-7.93.7-1

How reproducible:
Always

Steps to Reproduce:
Not applicable.

Actual Results:  Not applicable.

Expected Results:  Not applicable.

Additional info:
Comment 1 Inertia 2005-04-10 14:35:59 EDT
Created attachment 112927 [details]
Adds support for WPA.

This is the patch described in the bug report.	It should apply cleanly to the
initscripts-7.93.7 and the current (at this time) CVS.
Comment 2 Inertia 2005-04-10 14:47:33 EDT
Created attachment 112928 [details]
Patch to spec file to enable WPA (requires previous patch)

This is a patch to the spec file for initscripts-7.93.7; I hope this will make
it easier to verify and/or integrate the previous patch.
Comment 3 Bill Nottingham 2005-04-11 16:28:17 EDT
A prerequisite to adding this would be to add wpa_supplicant.
Comment 4 Andrew Gilmore 2005-05-07 11:57:41 EDT
Created attachment 114122 [details]
Updated initscript patch

The first version of this patch applied with fuzz, so I fixed that.

Further, I changed the ifdown-wireless script to call wpa_cli terminate instead
of killall wpa_supplicant. This uses the wpa_supplicant tools the way they were
intended, and also removes the need to separately remove the
/var/run/wpa_supplicant directory.
Comment 5 Andrew Gilmore 2005-05-07 12:00:46 EDT
Created attachment 114123 [details]
Updated spec file patch

Deleted the now unnecessary rm of the patch created ifdown.orig.

Depends on the previous patch to work
Comment 6 Andrew Gilmore 2005-05-07 12:03:03 EDT
We need WPA support in Fedora Core, but I'm not sure whether xsupplicant or
wpa_supplicant would be the better choice. I have tested the wpa_supplicant from
atrpms, and it works well with WPA-PSK.

Share and Enjoy!
Comment 7 Miloslav Trmač 2006-05-30 09:39:32 EDT
*** Bug 191486 has been marked as a duplicate of this bug. ***
Comment 8 Matthew Miller 2006-07-10 19:15:44 EDT
Fedora Core 3 is now maintained by the Fedora Legacy project for security
updates only. If this problem is a security issue, please reopen and
reassign to the Fedora Legacy product. If it is not a security issue and
hasn't been resolved in the current FC5 updates or in the FC6 test
release, reopen and change the version to match.

Thank you!
Comment 9 David Anderson 2006-07-13 11:03:15 EDT
This is still a live issue with FC5 - it shouldn't be assigned to the legacy 
project.
Comment 10 Carl Roth 2006-11-15 16:31:22 EST
These patches still have two issues with FC5/FC6:

 * Any encrption key supplied by wpa_supplicant is erased by ifup-wireless.  The
key management code in ifup-wireless should be stubbed out of wpa_supplicant is
being used.  I've worked around this by setting "KEY=on" in the ifcfg file, but
this is a hack.

 * is_wireless_device() returns true (an invalid result) for non-existent
interfaces like VPNs (tun/tap devices).  Running 'ifup' on a tunnel device will
result in a spurious invocation of wpa_supplicant.
Comment 11 Joachim Frieben 2008-12-04 01:52:56 EST
Now that NM 0.7.0 is able to use ifcfg files to set up networking, this issue has got a higher impact on the usability of F10.
system-config-network currently lacks the possibility to configure WPA/WPA2 which is needed, too.
Comment 12 Dan Williams 2008-12-12 07:49:23 EST
Adding a note from my mail to fedora-devel (Re: WPA without NetworkManager (was: Re: X on tty1 in Rawhide/F10)) about how supplicant integration with initscripts should work...
---------------

> What's wrong with manually editing wpa_supplicant.conf?

Because it's not easily readable from anything but wpa_supplicant, and it's
completely different than the existing ifup/ifdown config system.
System-config-network would have to grow the ability to parse the
wpa_supplicant config file format.  You can't override the variables
from /etc/sysconfig/network if you want to.  There's no separation of
interfaces to allow for multiple connections with two or more wifi cards
with 'ifup number1' and 'ifup number2' independently.

A much better, more integrated and consistent implementation would have
each ifcfg file essentially be a network block in the supplicant config
file.  When you 'ifup my-wpa', the scripts write out a new supplicant
config file using key/value pairs
in /etc/sysconfig/network-scripts/ifcfg-my-wpa and execute a supplicant
based on that, then somehow wait for the supplicant to connect (either with the dbus control interface or the socket control interface), and if no
connection occurs, time out and fail just like DHCP fails.  When you
'ifdown my-wpa', it will terminate the supplicant based on the PID file
written to /var/run/wpa_supplicant-wlan0.pid and clean up the
routing and addresses.

That's what the patch _should_ do.  Just tossing a config file off to
the supplicant is a cop-out half solution.
Comment 13 Dan Williams 2008-12-12 07:51:17 EST
*** Bug 356081 has been marked as a duplicate of this bug. ***
Comment 14 Dan Williams 2008-12-12 07:54:35 EST
*** Bug 244029 has been marked as a duplicate of this bug. ***
Comment 15 Peter Bieringer 2009-11-26 08:57:19 EST
See also https://bugzilla.redhat.com/show_bug.cgi?id=520269
Still happen on F12

BTW: a small patch will solve this issue:

--- ifup-wireless	2008-02-17 13:18:59.000000000 +0100
+++ ifup-wireless	2007-06-10 15:16:07.000000000 +0200
@@ -108,3 +100,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


it need only to add a line

WPA=yes

to ifcfg-WIRELESSINTERFACE
Comment 16 Dan Williams 2009-11-29 17:23:30 EST
*** Bug 520269 has been marked as a duplicate of this bug. ***
Comment 17 Bill Nottingham 2009-11-30 15:35:13 EST
That sort of patch does nothing for synchronization of the negotiation, etc. Which makes it a pretty bad interface.
Comment 18 Bill Nottingham 2009-12-18 13:07:44 EST
*** Bug 548814 has been marked as a duplicate of this bug. ***
Comment 19 Devaev Maxim 2010-02-15 09:19:59 EST
Created attachment 394323 [details]
Patch for Fedora 12

This patch adds support options WPA, WPA_DRIVER WPA_CONF in the scripts and configure network connections. Starting wpa_supplicant is for a specific network interface independently of the others and only on request.

Currently versions: initscripts-9.02.1-1.x86_64, Fedora 12
Comment 20 Bill Nottingham 2010-02-15 10:51:17 EST
I don't see how this solves the issues mentioned in comment #17.
Comment 21 Devaev Maxim 2010-02-15 14:45:12 EST
You mean that dhclient starts to connect wpa_supplicant?
Comment 22 Bill Nottingham 2010-02-15 15:14:38 EST
I don't see how, with that patch, there's any way to ensure that wpa_supplicant actually authenticated correctly before dhclient runs, or gets an error back if wpa_supplicant fails, etc.
Comment 23 Dan Williams 2010-02-15 22:03:33 EST
The patch would need a helper that connected to the wpa_supplicant control socket (or it could poll the D-Bus interface) and then asked the supplicant for the current state (if the supplicant connected really quickly before the helper got spawned) or waited for the state to jump to CONNECTED, and then exited.  Or if it didn't connect before a timeout had passed, exit with error.

But that of course doesn't tell you when the connection drops.  The supplicant will keep retrying the connection, but if some hard failure has happened during the connection it would keep retrying forever, basically.  Until you figured that out and did 'ifdown wlan0'.

At that point, might as well use something like NetworkManager...

Second, WPA_DRIVER is pointless.  The only drivers we should be using is 'wext' until we upgrade wpa_supplicant to the 0.7.x unstable series, at which point we can use 'nl80211' too for devices that use mac80211 underneath.

Third, I've already written about how I feel this should be done.  Using WPA_CONF simply does not integrate well with the Red Hat/Fedora network configuration system.  It essentially points to a lookaside file that does not conform to the format that all other network configuration uses.  Even Debian/Ubuntu can parse /etc/network/interfaces into a suitable wpa_supplicant config file.

What *should* be happening here is that we use the WPA ifcfg keys that we've already defined and that NetworkManager uses, and then parse those into a complete wpa_supplicant config file.  When you 'ifup' that new config file is created and the supplicant is spawned with a pointer to it.  That way when you 'ifup rh-wireless' you'll actually only be connecting to rh-wireless like you expect, instead of some random supplicant config file that has a mishmash of networks.

Seriously, there's a right way to do this that integrates well with the existing ifup/ifdown system and ifcfg files.  And any patch that just takes a path to a supplicant config file is not the right way.
Comment 24 Dan Williams 2010-02-15 22:04:24 EST
(see comment #12 for my original comment on this same issue)
Comment 25 Devaev Maxim 2010-02-16 05:39:04 EST
Created attachment 394500 [details]
Patch for Fedora 12 with wpa_supplicant state checks

I finished checking the status of wpa_supplicant. Now, dhclient does not start until wpa_supplicant has completed its initialization. In addition, I added support for the timeout, the maximum time allowed to run wpa_supplicant. 

No need to use one configuration file for all. Using wpa_supplicant.conf, protected from reading by ordinary users, increase security, and in addition, allows to describe the wpa_supplicant settings in one place. However, the ordinary user it is allowed to see how the network interface is assigned address. Perhaps some options, for example, WPA_DRIVER, in the future could be deleted, but at present many systems they are needed. 

I do not agree with the fact that the patch is not needed. Using NetworkManager in many cases is not justified. I want to be able to configure the network without the use of unnecessary entities. In the end, add this function does not hurt, it is only an alternative way to solve the problem.
Comment 26 Andy Shevchenko 2010-10-10 07:31:58 EDT
What is the current state of this? Any fixes in F13/14?
Comment 27 Devaev Maxim 2010-10-10 07:42:19 EDT
Created attachment 452585 [details]
New version of WPA-patch for F13

Adapted for F13.
Comment 28 Devaev Maxim 2010-10-10 07:47:29 EDT
(In reply to comment #26)
> What is the current state of this? Any fixes in F13/14?

Of course not, Dan Williams believes that only need to use NetworkManager. 

In general, why not give the user to choose how he set up a network? If you shift support WPA on NetworkManager, then exclude from the network scripts other connection types, such as PPPoE. Why PPPoE is implemented, but WPA is not? 

It should be possible to configure the network without NetworkManager.
Comment 29 Devaev Maxim 2010-10-10 07:54:44 EDT
(In reply to comment #23)
> Seriously, there's a right way to do this that integrates well with the
> existing ifup/ifdown system and ifcfg files.  And any patch that just takes a
> path to a supplicant config file is not the right way.

No, its a right way.

Stored passwords should not be accessible to users, but the settings in ifcfg can be read by all. Disable reading permission - not correct, because users may need information about system network configuration. 

Using wpa_supplicant file sharing adds to the settings and passwords. This is almost the same as using /etc/passwd and /etc/shadow.
Comment 30 Bill Nottingham 2010-10-11 12:54:46 EDT
There already is support for split secrets, FWIW.
Comment 31 Devaev Maxim 2010-10-18 10:35:19 EDT
Where?
Comment 32 Bill Nottingham 2010-10-18 11:06:04 EDT
See network-functions:source_config(), particularly the bit about keys-$DEVNAME.
Comment 33 Dan Williams 2010-10-18 13:14:59 EDT
(In reply to comment #29)
> (In reply to comment #23)
> > Seriously, there's a right way to do this that integrates well with the
> > existing ifup/ifdown system and ifcfg files.  And any patch that just takes a
> > path to a supplicant config file is not the right way.
> 
> No, its a right way.
> 
> Stored passwords should not be accessible to users, but the settings in ifcfg
> can be read by all. Disable reading permission - not correct, because users may
> need information about system network configuration. 
> 
> Using wpa_supplicant file sharing adds to the settings and passwords. This is
> almost the same as using /etc/passwd and /etc/shadow.

You put secrets into a keys-wlan0 file, and that file is root-only.  The scripts read that file when you ifup.  Nobody else can read that file.  It's been that way for WEP for years.
Comment 34 Joachim Frieben 2011-03-01 13:49:13 EST
Both F14 and the the current F15 development tree allow to use WPA(2) encrypted access points already during install (and later, too) creating the necessary entries in files like ifcfg-wlan0. This bug should be safe to close then, .. objections?
Comment 35 Bill Nottingham 2011-03-01 14:19:28 EST
That's using NetworkManager.
Comment 36 Peter Backes 2012-04-06 16:45:29 EDT
Dan, in comment 4 of duplicate bug 244029, you wrote

> It can't start before network, because it's in /usr, and that means that
> network-mounted-usr will break wpa_supplicant...

Does UsrMove make things different?
Comment 37 Fedora Admin XMLRPC Client 2013-09-04 10:49:58 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 38 Joachim Frieben 2016-08-11 23:41:52 EDT
Fedora Core 4 changed to end-of-life (EOL) status on 2006-08-07. Fedora Core 4 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug.

Thank you for reporting this bug and we are sorry it could not be fixed.