Hm, works for me. Please attach your ifcfg-file (you can disguise the WEP key 
if you want). 

There is no WEP key in the configuration file, it is configured for public
Hotspots (e.g. T-Mobile, Swisscom-Mobile, ...) in hotels, airports, ...

To reproduce: 
An access-point (essid="home") with WEP-encryption must be reachable.
use the attached config-file (for unencrypted wlan) and use kinternet
1) kinternet -> Dial-in (will not connect without key)
2) kinternet -> Wireless Connection (the "Wireless LAN-Dialog" window opens)
3) select the "Scan for Wireless Networks" tab
4) Start active Scan --> your accesspoint "home" appears in the list (WEP=on)
5) select your accesspoint "home" by left-clicking on the line
6) press the "Connect" button --> the "WEP-Key input dialog" window opens
7) Enter your WEP-Key and select the correct type (in my case "ascii")

SuSE 9.3 --> after some seconds the connection to "home" is established
SuSE 10  --> after some seconds I get an error message:
Connection request to: home failed. You are currently not associated with this
accesspoint. Try again!
  -or-
Connection request to: failed.

the ifcfg-wlan-* is absolutely the same file on suse9.3 and suse10 (it is a
copy) and it is installed on the same Laptop. So, for me it seems that it is a
problem of SuSE10 and not of the configuration or the hardware.

As I already mentioned: when I configure essid and key_0 directly in the
configuration file, it works (suse9.3/10), but when I use kinternet to
interactively set it for the selected accesspoint, it fails with Suse10 (ok with
suse9.3)

PS: it would be nice to have different configurations available (e.g. pwlan,
@home, @office, ...). Maybe to choose via "Provider" or even better, selected
automatically depending on the available essid.

Created attachment 48072 [details]
ifcfg-wlan-id-*

configuration for public wlan (unencrypted)

Maybe wpa_supplicant interferes the kinternet setup. Could you try to first  
shut down the interface before reconfiguring with kinternet ('ifdown ath0')?  

I shut down the interface first, but the problem still exists. (see output at
the end)

I tried to locate which package is the problem. kinternet and cinternet/smpppd
seems to be OK (except smpppd is not stopped with "/etc/init.d/smpppd stop").
The problem is the sysconfig-0.40.1-2 package. When I replace it with the
version from Suse9.3, the connect works as expected!

Let me know if I should modify/replace some scripts to assist you.



------------------------------------------------------------------------
laptop:~ # ifdown ath0
    ath0      device: Atheros Communications, Inc. AR5211 802.11ab NIC (rev 01)
    ath0      configuration: wlan-id-00:05:4e:41:8f:f6
laptop:~ # iwconfig
lo        no wireless extensions.

eth0      no wireless extensions.

ath0      IEEE 802.11  ESSID:""
          Mode:Managed  Frequency:2.412 GHz  Access Point: 00:00:00:00:00:00
          Bit Rate:0 kb/s   Tx-Power:20 dBm   Sensitivity=0/3
          Retry:off   RTS thr:off   Fragment thr:off
          Encryption key:off
          Power Management:off
          Link Quality=0/94  Signal level=-95 dBm  Noise level=-95 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

sit0      no wireless extensions.

laptop:~ # cinternet -i ath0 --start --set-essid=home --set-wep=11234567890123
--keytype=ascii --authmode=open
laptop:~ # iwconfig  ##after some seconds
lo        no wireless extensions.

eth0      no wireless extensions.

ath0      IEEE 802.11  ESSID:""
          Mode:Managed  Frequency:5.745 GHz  Access Point: 00:00:00:00:00:00
          Bit Rate:6 Mb/s   Tx-Power:18 dBm   Sensitivity=0/3
          Retry:off   RTS thr:off   Fragment thr:off
          Encryption key:xxxx-xxxx-xxxx-xxxx-xxxx-xxxx-xx   Security mode:open
          Power Management:off
          Link Quality=0/94  Signal level=-95 dBm  Noise level=-95 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

'--start' applies the interface configuration again, so there is probably   
wpa_supplicant running again. The sysconfig package of 9.3 did not use   
wpa_supplicant for non-WPA connection, so you worked around this problem. I've  
modified kinternet to shut down the interface before applying the new 
configuration, this seem to fix the problem. You can simulate this by calling 
'cinternet -i ath0 --stop' right before clicking 'connect' in kinternet. 

Yes, that works. But I think to modify kinternet is not enough. Also cinternet
is affected:
  cinternet -i ath0 --set-essid=xx --set-wep=xx --keytype=ascii --authmode=open
does not work when wpa_supplicant is already running. But the following works:
  cinternet -i ath0 --stop
  cinternet -i ath0 --set-essid=xx --set-wep=xx --keytype=ascii --authmode=open

But now, you have a new minor problem: The icon of kinternet shows disconnected
(because issued "--stop")

Is it already fixed in Beta4? If yes, I can test it this weekend.

PS: question of design: when you normally use wpa_supplicant also for non-wpa
connections, isn't it better to always stop wpa_supplicant, write a new
wpa_supplicant.conf and restart wpa_supplicant, instead of stopping
wpa_supplicant and using the "old" configuration method here?

Yes, cinternet doesn't stop this automatically. And the icon is wrong, too.  
But it's not critical imho, and it's not very easy to fix. Andreas, can you 
live with it? 
 
It's not fixed in Beta4 yet, sorry. 
 
We do not use wpa_supplicant in any case yet, although with the new 
wpa_supplicant 0.4.4 it may be possible. It would be desirable to use 
wpa_supplicant to reconfigure the interface, but currently kinternet resp. 
smpppd has no idea of it. And probably will never have, as it may get 
obsoleted by NetworkManager. 

I fear we have to live with it.

The right place to fix this is in smpppd. It's not too hard, but they way how 
the connection status is handled in smpppd makes it a bit complicated. As a 
quick hack I could use the AP address the driver shows to check for 
association and set the connection status to connected or disconnected 
accordingly. But this has the disadvantage that a shut down device may be 
still shown as connected, because the driver still has the address of the AP 
it was associated to. May be better than the current state, though. 

Andreas, should I do so? 

Ok.

I think, a good criteria for the connect status is the AP address _AND_ the
IP-address. (sometimes the wlan-connection get lost, but the IP-Address is still
associated)

Connection status is now determined by association status and IP address, 
fixed package submitted.