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 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.
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.
A prerequisite to adding this would be to add wpa_supplicant.
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.
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
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!
*** Bug 191486 has been marked as a duplicate of this bug. ***
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!
This is still a live issue with FC5 - it shouldn't be assigned to the legacy project.
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.
*** Bug 356081 has been marked as a duplicate of this bug. ***
*** Bug 244029 has been marked as a duplicate of this bug. ***
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
*** Bug 520269 has been marked as a duplicate of this bug. ***
That sort of patch does nothing for synchronization of the negotiation, etc. Which makes it a pretty bad interface.
*** Bug 548814 has been marked as a duplicate of this bug. ***
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
I don't see how this solves the issues mentioned in comment #17.
You mean that dhclient starts to connect wpa_supplicant?
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.
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.
(see comment #12 for my original comment on this same issue)
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.
What is the current state of this? Any fixes in F13/14?
Created attachment 452585 [details] New version of WPA-patch for F13 Adapted for F13.
(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.
There already is support for split secrets, FWIW.
Where?
See network-functions:source_config(), particularly the bit about keys-$DEVNAME.
(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?
That's using NetworkManager.
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?
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
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.