Bugzilla – Bug 112977
wpa_supplicant version too old and does not work with ifplugd
Last modified: 2006-02-13 16:35:22 UTC
The 0.3.9 version of wpa_supplicant in beta3 does not properly support ap_scan (according to the developer) and thus cannot support multiple "network" blocks in the config. This makes the wireless card pretty useless for 90% of corporate users who use the wireless both at work and at home. Mine is upgraded to 0.4.4, supports ap_scan=2, has two network blocks, one LEAP the other WEP, and works perfectly. I will be filing a second bug regarding incompatability between wpa_supplicant and ifplugd.
Is is API compatible? Does the update need changes to other software? It's quite late to change this. Joe, what is your opinion?
I know nothing of the API, specifically. Beyond fixing the existing 9.3 bug in ifup-wireless-wpa (which is already fixed for 10.0), I changed nothing when I installed 0.4.4 from tarball. I know it's late - but it's a rather important functionality issue, IMHO. In order to use more than one network block in the config, you really must have ap_scan=2 working the way it is supposed to. Otherwise, wpa_supplicant will attempt to use only the first network block in the config, and ignore the rest. When that doesn't work, it fails. [Now if I could just figure out the solution to the ifplugd problem, I'd have it made ;-) ]
Correction - ifup scripts look for a .pid file in /var/run/wpa_supplicant. 0.4.4 only puts a socket there. I had to comment out the search for a .pid file from the ifup scripts. So yes, there is a small repurcussion, but AJ, I really believe this is important.
wpa_supplicant (also 0.4.4) writes a pid file when called with -P option. I'm running wpa_supplicant 0.4.4 on two test machines now, and it seems not to break anything. It does not need any changes, too, so I think a switch would be possible. But I'm not really convinced this is needed. That ap_scan=2 now supports multiple networks is really useful, no doubt, but having multiple network sections is not a must-have IMHO. Do you have setup where you definitely need ap_scan=2? However, before we make decision I'd like to do more test, especially test all drivers support by wpa_supplicant with the new version to make sure it does not break something. I hope to get that done this weekend.
According to it's author, multiple networks won't work unless ap_scan is working properly, and it doesn't work properly in the 0.3.x versions. That's directly from him. Unless we are willing to presume that our laptop users will only connect to one network, we should have this. As we are now using wpa_supplicant for everything wireless (unlike in 9.3, where you had to ask for it specifically, in 10 you have to tell it NOT to use it, right?), I can soon see a need for YaST to be able to set up wpa_supplicant.conf for multiple networks. That will never happen with 0.3.x. Although I hate to refer to that company from Redmond, this is much easier there. We need to make ours just as easy, and the shift to wpa_supplicant is a good step in that direction, but only if setting up for multiple networks is made easy and solid. Although my testing is limited (and not a proper regression test), I have so far had smooth sailing (and speedier association) in 9.3 and in 10.0
Joe, do you have a package so that I can help testing with my one testmachine?
I'm coming in late to this discussion, but, I support 5 Hospitals, and work from Home, and right now, I can't get plain WEP to work with ndiswrapper, much less more than one network. If I can't get this to work on multiple networks, yes, it would be a showstopper. I'd sure like to know how to tell it NOT to use WPA supplicant with my home network.
Supporting multiple wireless networks in the interface configuration would be nice, no doubt, but it's not a showstopper. In fact, you can configure multiple networks in 10.0 for devices working with wpa_supplicant, but not with YaST, you have to edit the ifcfg-file manually. And it won't give you full roaming support yet, in fact, it only works if you have the same fixed IP in every network. The whole topic needs further work. The usage of wpa_supplicant for configuration which do not require it can be prevented by adding PREFER_WPA_SUPPLICANT='no' to the ifcfg-file or to /etc/sysconfig/network/wireless, the latter case acts globally. If there is a concrete problem with ndiswrapper please open a separate bugzilla entry for it.
I've tested now wpa_supplicant 0.4.4 with nearly all WLAN cards I have available. I tried connections with WPA-PSK, WPA-EAP, WEP, and no encryption, and multi network configurations with different scanmodes, and I have to admit, it looks good, I encountered no problems. So I don't object against updating anymore.
Thanks JG. BTW, I don't have fixed IP in multiple networks and my 0.4.4 does fine. DHCP in each network. 0.4.4 even does my work LEAP smoothly. I think we all agree that YaST needs additional work to fully enable what wpa_supplicant can do. But moving 10.0 to 0.4.4 is a great first step.
Is this closed now?
Yes.
Beta 4, wpa_supplicant 0.4.4, all freshly installed today. /etc/sysconfig/network/scripts/ifup-wireless, around line 570-576 Even with /etc/wpa_supplicant.conf, listed in ifcfg-wlan as WIRELESS_WPA_CONF="/etc/wpa_supplicant.conf", ifup-wireless is writing and using /var/run/wpa_supplicant-$INTERFACE.conf, which has only one line. Very similar problem as existed in 9.3 (an "fi" was in the wrong place).
Tested it also with Beta4, works for me. Please attach you ifcfg-file.
Hmm....would it matter that the ifcfg-wlan is 0600? (-rw-------, I can never remember the numericals correctly, even after all these years).
Created attachment 49040 [details] wlan ifcfg
Comment 17: This is intended. The ifcfg-file may contain secret keys (WEP or WPA), and therefore it shouldn't be world readable. Comment 18: Hm, can't reproduce it with your ifcfg-file either. Are you sure the generated wpa_supplicant.conf isn't a left-over one? And please run 'ps xa | grep wpa_supplicant' after ifup. It should show which config file gets used actuallay.
The ps aux is how I knew that wpa was using the wrong config file. This is an absolutely fresh install. I hadn't "tinkered" with the scripts or anything before this failed. In order to get this to work, I had to do this at line 573 in ifup-wireless: #WPA_SUPP_CONF="/var/run/wpa_supplicant-$INTERFACE.conf" WPA_SUPP_CONF="/etc/wpa_supplicant.conf" So I can say with 100% certainty that the script was executing that line, meaning that "if [ -n "$WIRELESS_WPA_CONF" ];" at line 565 had failed it's test. The /var/run file was being created on the fly with each ifup, and destroyed with ifdown. It does not exist at other times. Can't be a leftover - this is a fresh install, not an upgrade.
Sorry, still can't reproduce it. Could you place the lines set -x exec 1> /tmp/ifup.log 2>&1 at the beginning of ifup-wireless, restart the interface, and attach /tmp/ifup.log afterwards, please?
Are you some kind of magician? Now the bloody thing is using the correct config! Unfortunately, it's not associating.
Created attachment 49102 [details] log of ifup-wireless
A little bit of /var/log/messages. Note the "Canceling scan request" Sep 7 13:54:40 linux logger: wpa_driver_wext_set_key: alg=0 key_idx=1 set_tx=0 seq_len=0 key_len=0 Sep 7 13:54:40 linux logger: wpa_driver_wext_set_key: alg=0 key_idx=2 set_tx=0 seq_len=0 key_len=0 Sep 7 13:54:40 linux logger: wpa_driver_wext_set_key: alg=0 key_idx=3 set_tx=0 seq_len=0 key_len=0 Sep 7 13:54:40 linux logger: EAPOL: External notification - portEnabled=0 Sep 7 13:54:40 linux logger: EAPOL: External notification - portValid=0 Sep 7 13:54:40 linux logger: Setting scan request: 0 sec 0 usec Sep 7 13:54:40 linux logger: State: DISCONNECTED -> SCANNING Sep 7 13:54:40 linux logger: Trying to associate with SSID 'AirnetL' Sep 7 13:54:40 linux logger: Cancelling scan request Sep 7 13:54:40 linux logger: WPA: clearing own WPA/RSN IE Sep 7 13:54:40 linux logger: Automatic auth_alg selection: 0x4 Sep 7 13:54:40 linux logger: Overriding auth_alg selection: 0x4 Sep 7 13:54:40 linux logger: WPA: clearing AP WPA IE Sep 7 13:54:40 linux logger: WPA: clearing AP RSN IE Sep 7 13:54:40 linux logger: WPA: clearing own WPA/RSN IE Sep 7 13:54:40 linux logger: No keys have been configured - skip key clearing Sep 7 13:54:45 linux logger: wpa_driver_wext_set_droioctl[SIOCSIWENCODEEXT]: Invalid argument Sep 7 13:54:51 linux logger: WEXT auth param 6 value 0x4 - ioctl[SIOCSIWAUTH]: Invalid argument Sep 7 13:54:56 linux logger: ioctl[SIOCSIWENCODEEXT]: Invalid argument BTW, why the ext driver? When I installed 0.4.4 on 9.3, the driver was named ipw.
logs keep showing it trying to associate with AirnetL using an AP of all 00's. Yet, wpa_cli -iairnet , scan_results shows multiple AP's for AirnetL, none of which are all 00's.
Update: Home works OK. wext driver is the only one that works in 10 (in 9.3 I used ipw successfully). At work, LEAP, it talks to an AP, verifies my ID/Pass, and negotiates the WEP key. Then it just stops. No ip address, no nothing. logs and wpa_cli show it continuously trying to associate with both networks. Again, this is AFTER verification of id/pass and negotiation of WEP key.
OK, let's back up a second, to give you all the information I can. 9.3, manually updated the wpa to 0.4.4, driver used by wpa is ipw. Works smooth and clean. Fresh install 10.0, grab ipw driver from ftp site (gwdg, IIRC) since it isn't in the distro, use configs for wpa and ifcfg from 9.3 build (I saved them). In 10.0 b4, wpa is told to use wext as it's driver. Home WEP works fine, work stops after key negotiation, debug (and wpa_cli) says timed out waiting authentication. Edited ifup-wirelss to use ipw driver instead of wext: neither home nor work works. In each case, it fails to find/load the key, either LEAP negotiated (at work) or from the wpa_supplicant.conf (for home WEP). So I put it back to wext. For both work and home, occassionally the entire OS locks up hard when I run ifup. Can't do debugging: when I say locked up, I mean it! No clue why. I'm wondering - perhaps the firmware is the real problem? Is this the same firmware we used in 9.3? (I don't have a 9.3 available to look at right now). I will do anything you ask in order to solve this. I feel responsible, especially since I'm the one who talked you guys into upgrading to 0.4.4.
Created attachment 49266 [details] ifup log for total lockup This is one taken when a total lockup happened.
Notes from ipw2100.sf.net: NOTE: In order to upgrade to 1.1.1 you must now obtain the ieee80211 subsystem separately from http://ieee80211.sf.net * Moved ieee80211 subsystem into its own object * Added WE-18 support. This allows the use of -Dext with wpa_supplicant > 0.4.x (thanks to Hong Liu) * Fixed #339 problem with iwconfig set/get txpower (thanks to Hong Liu) * Fixed #598 problem when with error messages when module loaded with 'disable=1' (thanks to Hong Liu) * Fixed #640 problem with 'iwlist retry' now showing min/max retry * Fixed #653 compilation problem against kernel patched with Software Suspend 2.1.8.7 (thanks to Henrik Brix Andersen) * Fixed #655 WPA disabled due to lack of CONFIG_IEEE80211_WPA_MODULE checking * Fixed #715 problem with network monitor is broken due to netif_carrier_on is not called in ipw2100_open (thanks to Ben Osheroff) * Fixed compatibility with wpa_supplicant and the new -Dipw interface (that included a fix for 64-bit compatibility) * Cleanup: replace indent space with tab, code reformat, etc * memcpy parameters cleanup (thanks to akamatsu) * Make needlessly global code static and remove unused IPW_DEBUG_ENABLED (thanks to Adrian Bunk) * Make two functions static and remove pci.h from #include (thanks to Adrian Bunk) * Fix few typos/thinkos, remove ugly macro and fix types passed to pci_set_power_state (thanks to Pavel Machek) * Invasive cleanups for X__ prefixes (thanks to Pavel Machek) * Kill unused KILL_CHECK_THRESOLD and KERNEL_SYSCALLS (thanks to Pavel Machek) * Changed the Makefile to share as much between the two IPW projects as possible Note the multiple fixes involving wpa_supplicant. I will try this firmware on Monday.
Whoops. . . you named yours differently, but looks liek it's already 1.1.2
Jonathan, are there still open issues? I'm using WPA-EAP with ipw2200 on 10.0 regularly with no problems, so I'd like to close this one.
For me, it is still an issue. I've given up on using it for LEAP and gone to using Windows XP if I need to connect via wireless at work. Worked perfectly for multiple network configs in 9.3 (manually upated to 0.4.4). 10.0 frech install has LEAP problems and problems with multiple network definitions in /etc/wpa_supplicant. Do we drop it? I don't know - does SuSE have any developers left in this area?
The multiple network issue is becoming less of an issue with the use of SCPM. Don't ask why I never thought of it before. I'm going to re-test LEAP at work tomorrow and either give you more info or I will concur with closing this. This system is a 10.0 updated using apt-get and the following apt repositories from gwdg: rpmkeys base java update extra packman security kde openoffice Maybe the LEAP will work now ;-)
Still have troubles in 10.0, which, according to the Intel folks, is using a version of ipw2100 module which has known failings. 1.1.3+ have fixed them. I have updated my kernel to KOTD using apt, and now get LEAP, WEP, multiple networks, etc. Since I don't expect you folks to up the kernel levels for a stable release like 10.0, I guess we should just mark this as WONTFIX and move on to 10.1 and newer kernels with ipw2100 1.1.3 or better.