Bug 112977

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.