Just stating the obvious: If you change host name via DHCP, and initialize the network connection after KDE has started, you are not able to open new windows which might look like network failures (alt-F2 -> check.testhost.org -> no konqueror window is opened). 

Maybe, but that's not the problem. If I open Konqueror with Alt-F2 or from konsole, there is no network connection neighter.

Actually the host I'm now writing from has no internet access through Konqueror.

I remember, that KDE has an offline mode, maybe that's the problem?

The mentioned firmware cannot be shipped with the OSS-version as it is not OSS.
Marcel: Can you provide more information about your setup (`hwinfo --network', `ifconfig', ...).

> I think this is still the WPA_SUPPLIANT problem.
If you referred to an existing bugreport, please state it.

The firmware is on the extra tree on ftp.suse.com

Konqueror Problem seems to be related to KDE Offline mode. If I start the network before I start KDE, then Konqueror goes online. But if I start the network after login to KDE, there is no internet connection with Konqueror.

Network is still startet manually, as network-manager does not work.

Added Adrian to CC, perhaps he knows more:
http://lists.suse.com/archive/suse-kde/2006-Jan/0104.html

Will attach two logfiles. One showing the network-manager messages during connection-attempt. The other one is the syslog in the same time. Connection attempt is through a wireless router, but I don't think this is the problem.

Created attachment 70258 [details]
network manager messages during connection attempt

Created attachment 70259 [details]
Syslog messages during connection attempt

Seems to be the encryption, which doesn't work. Connection to an unencrypted network works. If I setup the password with

iwconfig enc s:foo

which entry is supposed to work?  I tried the working HEX-key, too, but with no success.

Marcel: Try not to address more than one issue in one bug report, this makes the handling very difficult. However this appears to be a problem with NetworkManager, not with KDE.

I'm not so sure this is a networkmanager problem, it might be specific to knetwork manager

Well, (In reply to comment #7)
> Created an attachment (id=70258) [edit]
> network manager messages during connection attempt

This looks like your KWallet isn't properly set up for KNetworkManager.

Please try connecting to the encrypted network manually ("Connect to other wirless network").  I'd be good to have the NetworkManager log (/var/log/NetworkManager) if the attempt failed.

Indeed. I'm on vaccation now, so I can't send you the logs, but I did not enable kwallet. When the kwallet window came up, I just klicked on Next -> Next -> Finish, but I did not set up a password. If set up a password is mandatory, please tell users so.

Actually this should be enough.  You should not be required to set up a password.  Will?

You don't have to set a password on KWallet, no.  Did you choose to use KWallet?  Password storage only works if the wallet is enabled.

See in ~/.kde/share/config/kwalletrc - is Enabled=true?

It's enabled=false. Is there a way, to reenforce the kwallet wizzard? I removed

.kde/share/apps/kwallet
.kde/share/config/kwalletrc
.kde/share/config/knetworkmanagerrc


but knetworkmanager doesn't popup the kwallet dialog anymore. Without the kwallet wizzard I can't reproduce exactly.

I think the wizzard only pop up, if the wallet subsystem is enabled.  Try starting kwalletmanager, right click the tray icon -> "Configure Wallet" -> "Enable the KDE wallet subsystem".

Did some new test with Beta6 Kwallet is ok now. But it´s not the problem anyway. Knetworkmanager and nm-applet both hang on 28%.

They are not able to set up the essid, ap and the passphrase. If I do these things manually, when the knetworkmanager waits at 28%, then it works.

Here a short log from knetworkmanager, further logs as attachment. I do not use
WPA, only 128-bit WEP:

marcel@susibeta6:~> updateNetwork: Found network without device? Bailing out.
org.freedesktop.NetworkManagerInfo already owned.

** (process:6273): CRITICAL **: cipher_wpa_psk_hex_set_we_cipher: assertion `(cipher->we_cipher == NM_AUTH_TYPE_WPA_PSK_AUTO || cipher->we_cipher == IW_AUTH_CIPHER_TKIP) || (cipher->we_cipher == IW_AUTH_CIPHER_CCMP)' failed

** (process:6273): CRITICAL **: cipher_wpa_psk_passphrase_set_we_cipher: assertion `(cipher->we_cipher == NM_AUTH_TYPE_WPA_PSK_AUTO || cipher->we_cipher == IW_AUTH_CIPHER_TKIP) || (cipher->we_cipher == IW_AUTH_CIPHER_CCMP)' failed

** (process:6273): CRITICAL **: nmu_security_serialize_wep_with_cipher: assertion `(auth_alg == IW_AUTH_ALG_OPEN_SYSTEM) || (auth_alg == IW_AUTH_ALG_SHARED_KEY)' failed
Serialization of encryption payload failed (key reply).

Created attachment 71638 [details]
syslog during connection atttempt with some comments

Created attachment 71639 [details]
Output of hwinfo --network

Created attachment 71640 [details]
Some attempts under Gnome with nm-app

ifup-dhcp eth1 works only, after the networkmanager is stopped with
rcnetwork stop


Btw: ESSID is hidden.

Don't know, what I/you did ;-) , but it's working now with beta8. The only thing I did not as before: I was setting up the ESSID and the key within YaST during install. But I removed those settings now and tried it again. And it still works. So this seems to be fixed.

Sorry, I have to reopen:

It does definively not work, if you do not setup the ESSID _and_ the WEP key in YaST. Tried it several times now, and could reproduce this. Install fresh beta8, do not(!) setup the network in YaST and try to connect to a wireless network (WEP) with NetworkManager.

essid is hidden
router does IPv4 only

Here the new log when NetworkManager does not success:
Mar 19 19:52:16 linux-hzst network: Checking for the NetworkManager:
Mar 19 19:52:16 linux-hzst network: Checking for the NetworkManagerDispatcher:
Mar 19 19:52:30 linux-hzst kernel: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
Mar 19 19:52:34 linux-hzst dhclient: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 4
Mar 19 19:52:38 linux-hzst dhclient: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 10
Mar 19 19:52:40 linux-hzst kernel: eth1: no IPv6 routers present
Mar 19 19:52:48 linux-hzst dhclient: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 14
Mar 19 19:52:56 linux-hzst dhclient: caught deadly SIGTERM
Mar 19 19:52:56 linux-hzst dhclient: could not restore resolv.conf: No such file or directory
Mar 19 19:52:57 linux-hzst dhclient: DHCPRELEASE on eth1 to 192.168.0.1 port 67
Mar 19 19:52:57 linux-hzst dhclient: send_packet: Network is unreachable
Mar 19 19:52:57 linux-hzst dhclient: send_packet: please consult README file regarding broadcast address.

Marcel, could you please attach a full log of the connection attempt from /var/log/NetworkManager?  Thanks!

Created attachment 73956 [details]
Network-Manager log

Full Networkmanager log, so it contains also some successful attempts. For the problem described, compare syslog with Networkmanager log on 19:41 till 9:43 and 19:50 until 19:52.

Created attachment 73957 [details]
Full syslogof beta8 

Full syslog for comparison to the networkmanager log.

Thanks for the logs.

You're actually having successful connection attempts?  It works sometimes but not always, correct?

There are DHCP timeouts which might be the reason for your unsuccessful connection attempts.

Updating summary, moving to Beta 8, lowering severity.

I have the same problem with beta8 on a HP compaq nc6120 notebook. I really hope this will be fixed before releasing 10.1. In addition, while trying to get connected via network manager, KNetworkManager crashed at least 3 times, but I'll submit that in a separate report.

(In reply to comment #30)
> I have the same problem with beta8 on a HP compaq nc6120 notebook.

Please specify "same problem".  Does it work sometimes or never?

> In addition, while trying to get connected via network manager, 
> KNetworkManager crashed at least 3 times, but > I'll submit that in a
> separate report.

Yes, please do so!  Assign the bug directly to thoenig@suse.de, thanks.

To #28: I have _no_ successful attempts, if I do not setup the essid and the WEP key in YaST before.

To #30: KNetworkmanager does not crash for me.

(Additional info for #30/#31):
No, I have never been able to connect to my WPA encrypted access point, despite many attempts. Changing encryption to WEP on my WLAN router didn't help either. Connecting to an unencrypted WLAN works ok. I'm at work now, will attach details from /var/log/networkmanager tonight.

Winfried, can you please test with KNetworkManager _and_ with nm-applet?  This helps us to identify whether we're having a problem with NM or with one of the applets.

Wifried, can you also try to setup the card in YaST first. If this helps, than maybe, it's the same bug. You have to call 

rcnetwork restart

afterwards. For me, nm-app or knetworkmanager makes no difference.

No, please do not do this.  We need to get this fixed first with a vanilla setup (NM only).  Otherwise we're raising the amount of possible culprits.  Once this is done, we can try other combinations.

Behaviour with KNetworkManager and nm-applet is the same: a dialog keeps popping up asking to enter the passphrase even though I'm positive I entered the correct one.
I'll attach contents of /var/log/NetworkManager

Created attachment 74064 [details]
Part of /var/log/NetworkManager that I think is most interesting

I will add full contents /var/log/NetworkManager of tonight in next attachment.

Created attachment 74065 [details]
NetworkManager log file while trying to connect to a WPA encrypted WLAN

Log of several attempts to connect to my wpa encrypted WLAN both with KNetworkManager and nm-applet.

Additional note: after a few attempts to connect to the WLAN, my WLAN router seems to crash frequently, as I can't even reach it from wired network anymore then, and have to reset it. This might be a bug in the router (Digiconnect broadband router) but it never happened before. Moreover the same (dual boot) notebook connects fine to the WLAN when running windows.

Looks like both of you hit the DHCP timeout.  Can you please retry with NetworkManager the RPMs from http://nouse.net/projects/NetworkManager/ ?  I've bumped the DHCP timeout value for this build.

(In reply to comment #41)
> Can you please retry with
> NetworkManager the RPMs from http://nouse.net/projects/NetworkManager/ ?  I've
> bumped the DHCP timeout value for this build.
 
These rpms need the following dependencies:
sysconfig >= 0.50.7
NetworkManager-glib = 0.6.1-9

I can't find them on any of the factory repository mirrors. Can you please let me know where I can download them?

Added the missing RPMs to the repository.

Seems to fix the problem for me, but I have to do a clean Install first, to reproduce 100% as I have still those settings within YaST. I also had to reboot the machine before it worked. rcnetwork restart was not enough.

Good news!

Would be great if you could the packages in combination with a vanilla Beta 8.

> I also had to reboot the machine before it worked. rcnetwork restart was not
> enough.

Yes, there were quite some changes wrt dhcdbd.

Perhaps tomorrow or in the late evening. I have much work todo.

Another thing, I detected, that it takes several minutes(!) until it displays the singal strenght. With unencrypted WLAN I did not remark this.

:-( Still doesn´t work for me. 
Settings in router: WPA-PSK, encryption TKIP, preshare key mode ASCII. 
When I connect to this WLAN with KNetworkManager, the progress bar increases until  71%, then KNetworkManager dialog pops up. In "use Encrytpion" frame I choose "WPA Personal" for Encryption.

In the "Advanced Settings" frame, sometimes there is only 1 combobox named "Authentication", where I can choose between "open system" and "shared key" (I choose the latter). 
Sometimes however there is an option "WPA version" (which is greyed out and set to "WPA1") and a combobox "WPA protocol" where I can choose between "Automatic" and "Temporal Key Integrity Protocol (TKIP)" (I choose the latter).

In both cases I never get connected to the WLAN. And router still dies almost every time after trying to connect once or twice to it.

> In the "Advanced Settings" frame, sometimes there is only 1 combobox named
> "Authentication", where I can choose between "open system" and "shared key" (I
> choose the latter). 

This is definitely a bug.  This should _never_ happen as open system/shared key apply to WEP not WPA.

> Sometimes however there is an option "WPA version" (which is greyed out and > 
> set to "WPA1") and a combobox "WPA protocol" where I can choose between
> "Automatic" and "Temporal Key Integrity Protocol (TKIP)" (I choose the
> latter).

It's grayed out because NM already detected that your AP is using WPA1 (not WPA2).

Does it work for you if you choose "Connect to Other Wireless Network" instead of clicking the network in the context menu?

Created attachment 74413 [details]
today's /var/log/NetworkManager

ssid of my WLAN is microschoft-free-network

You're not using the packages from comment #42, are you?  The most promising connection attempt (at 11:59:54, correct WPA settings are being used) ends with

<information> Device 'eth1' DHCP transaction took too long (>25s), stopping it.

To be sure I downloaded the rpms from #42 again and did a forced install followed by a reboot. Then I tried to connect via "Connect to Other Wireless Network", but no luck. In the (attached) log I now see it gives up after 90 secs and then connects to eth0 instead. The router stayed alive this time, so that was not the cause of the time-out.

Created attachment 74434 [details]
connect via "connect to other network" with downloaded rpms

Robert, it looks like at least Marcel has more luck with a bumped DHCP timout.  What should we go for if 25s is not enough?  Radek on NM list reported to require 40s.

Any idea about the association timeout problem (attachment #74434 [details])?

I'd have no problem bumping the timeout to somewhere around 30~40s, if we are seeing that people need the extra time.  Maybe we can take this to the list and see if we can make a bump upstream.  I'll do that right now.

No idea about the association timeout problem -- normally that spells driver problem.  Although the AP crashing is not reassuring.

You should try to fix NetworkManager, not bumping the timeout.

ifup-dhcp _without_ Networkmanager get's connected in 2 Seconds. So I guess this is a problem of NetworkManager, not the WLAN driver or the AP.

(In reply to comment #48)
> > In the "Advanced Settings" frame, sometimes there is only 1 combobox named
> > "Authentication", where I can choose between "open system" and "shared key" > > (I choose the latter). 

> This is definitely a bug.  This should _never_ happen as open system/shared 
> key apply to WEP not WPA.

Winfried, this is fixed in SVN HEAD.  RPMs will be available on http://nouse.net/projects/KNetworkManager/ shortly.  Please open a separate bug if you ever see this again.

Good news, Timo!
Did a fresh install with Beta8 and the new Networkmanager-Packages you provided. Works now without any hacking :-)

If Winfrieds bug is fixed, too, feel free to close this bug.

Hey, perfect.  Thanks a lot for taking your time on testing, Marcel.

I already worried about breaking the sonic wall of 60 comments by tonight ;-)

Winfried, let me know if everything is fine for you so we can resolve this one as fixed.

I didn't try the new KNetworkManager packages yet, but apart from that I still didn't succeed to connect to my WPA WLAN when using networkmanager. But since I also have a problem connecting to my companies WLAN (bug 159812), I am also going to do a fresh install of beta8 instead of an upgrade.

Just submitted to autobuild an NM with a DHCP timeout of 45s.

No change after fresh install of beta 8.
If I'm the only one with this kind of problems, I'm not sure if I should bother you more. It's pretty standard hardware though: HP nc6120 notebook with ipw2200 that's just 4 weeks old and it does connect when running Windows.

Winfried, as Robert just mentioned on bug #159812, NetworkManager 0.6.2 should help.

I'll close this one as fixed.  Please post follow-ups on bug #159812.

Thank you.

Sorry, I have to reopen. Bug was fixed with packages provided by
 http://nouse.net/projects/NetworkManager/
for beta8 but I still have the same problem with a fresh install and rc1. For Details see initial comment on bug #165907. I will try the old packages this evening once more and report then, but NetworkManager is still not able to connect to my WLAN.

Marcel, bug #165907 is not a 'real' NM bug as it is a bug in the way how KDE deals with detecting whether it is on- or offline.

However, as your connection problem (IPW2100 connecting to non-broadcasting networks) remains, I'm closing this one as duplicate of bug #166125.  Please track this issue with this bug.

*** This bug has been marked as a duplicate of 166125 ***