Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

This site requires JavaScript to be enabled to function correctly, please enable it.

Bug 154348
- Adds support for WPA (Wi-Fi Protected Access) to the ifup* and ifdown* series of scripts located in /etc/sysconfig/network-scripts/.

Summary:Adds support for WPA (Wi-Fi Protected Access) to the ifup* and ifdown* series...

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:

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.

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.

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!

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!

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.

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.

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.

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

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.

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.

(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.

(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.

(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.

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?

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?

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.

Note

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