Bug 230838

At first, could you please try moving the old configuration file (.kde/share/config/knetworkmanagerrc) out of the way, setup the network again and reboot? Although, the update case should be working.

Please let me know if this helps.

Also, is it possible that you have a YaST configuration file for the given network in /etc/sysconfig/network/ifcfg-* ?

I don't have access to the computer atm, I'll post detailed description asap (during first week in 2007). That's why I'm leaving this as needinfo.

(In reply to comment #1)
> At first, could you please try moving the old configuration file
> (.kde/share/config/knetworkmanagerrc) out of the way, setup the network again
> and reboot? Although, the update case should be working.

I didn't do update but new installation, so this shouldn't be the case.

> Also, is it possible that you have a YaST configuration file for the given
> network in /etc/sysconfig/network/ifcfg-* ?
> 

I don't know, I changed nothing in yast during installation. I'll check it ASAP.

BTW Happy New Year ;))

(In reply to comment #2)

> I don't have access to the computer atm, I'll post detailed description asap
> (during first week in 2007). That's why I'm leaving this as needinfo.

OK.

> I didn't do update but new installation, so this shouldn't be the case.

OK.
 
> I don't know, I changed nothing in yast during installation. I'll check it
> ASAP.

If you didn't do anything at installation time there should not be a ifcfg-* file for your network either ;-)
 
> BTW Happy New Year ;))

Thanks!  Same to you :-)

well, I reinstalled the notebook and I'm unable to reproduce this bug anymore. So hopefuly I did something wrong last time...

BTW yast automatically detected my wifi (ipw2200bg) and made default dhcp 
configured setup - so the file in /etc/sysconfig/network exists even though I changed nothing during installation

Thanks for the information, Lukas.

Closing as INVALID.

Hello again,

I am reopening this bug since I get the very same behavior again now. I reinstalled the boxed version of 10.2 only two weeks ago and have all patches installed. Same happens with a newly added user, too, so no config problem afaict.

The wireless nic is NOT configured with YAST. I use WPA as encryption: the key is obviosly stored in the wallet correctly but knetworkmanager still keeps asking for the key. Deleting the entry from the wallet makes no difference, too.

Created attachment 122428 [details]
screenshot with both the wallet and knetworkmanager

Forgot to mention that the wallet is requested to be opened properly (does not count for the cases when it is done as described in bug #206641 -- which is very often...).

Additional comment: does not only happen with WPA passwords but also with WEP keys, too.

And stupid forgot to mention that the latest update for knetworkmanager on openSUSE 10.2 does NOT fix this issue.

What makes the problem an ugly one is that it works sometimes, and sometimes it doesn't...

Daniel, is it right that you get asked for the KWallet password and afterwards (a few seconds later?) you get asked for a new key through the KNetworkManager dialog?

Please attach the relevant part of /var/log/NetworkManager when you have this weird behavior.

Thanks.

Yes, this is the exact behavior. But when I look in kwalletmanager right then, the password is clearly there.

My current suspect is the "Automatic" setting. The WLAN router supports both WPA and WPA2 and both TKIP and AES (dd-wrt v23sp2 on a Linksys WRT54GSv1.1). So one could think that leaving that decision up to knetworkmanager should work but I found that when telling it to specifically use WPA with TKIP it works much better. Connection works fine now (that is, not counting the race now and then when DCOPserver instead of knetworkmanager tries to access the wallet, as in bug #206641 :)

I will add the corresponding log files asap. Just be informed that it also happens with a WEP-ASCII secured network.

Created attachment 129840 [details]
about 600 lines /var/log/NetworkManager

Hi, I am currently at my parents place, with a WPA/TKIP secured network. Fortunately my sisters laptop has just recently experienced the problem again: knetworkmanager keeps asking for the password again and again albeit it is perfectly stored in the wallet. As it seems to me knetworkmanager actually does read it fine, too, but something else blocks the connection so it plays dumb and asks for a new password.

Sorry that I am attaching such a long part of the log file, I was just unsure if you can maybe extract more information that way. The weird behavior is definitely seen at the end of the log but afaict there have been disconnections earlier already which my sister did not notice because she was working...

Ok, the log contains many messages like "disconnected during association, asking for new key".

In this case NetworkManager assumes that the given key is wrong and thus requests a new key from the user. Therefore KNetworkManager works as designed. For tracking the issue further down we need to find out why the association fails. Please post the output of "nm-tool" and "iwlist ath0 scan" with the network you're trying to connect to in range.

Created attachment 130059 [details]
output of nm-tool, run as normal user

Created attachment 130061 [details]
output of iwlist eth1 scan, run as root

Unfortunately I can no longer provide that information with the Atheros based wireless nic of my sister since she is back at work again.

It happend to me, too, yesterday so maybe this is helpful, nevertheless.

Thanks Daniel. 
So the problem exists with both cards, the ipw2100 and the Atheros based one? Does it sometimes work or does it ever fail?

Yes, the symptoms definitely exist with both cards. Fortunately it does not happen all the time so this will be hard to debug (as most NetworkManager bugs), I am afraid.

Do you see the same behavior when connecting manually through the "Connect to other Wireless Network..."? And does it work when choosing the appropriate entry in the context menu? Or do you have the same symptoms there too?

I can connect manually, and afaict it works equally good or bad as the automatic connect or when I select the network in the knetworkmanager menu. 

I very rarely get this disconnect and password question when the connection is idle for some longer time -- albeit I never had to enter the passphrase >10 times in a row as on my sisters laptop yesterday in order to reestablish the connection.

But usually, typically and most often it occurs right after reboot and login and thus when KNM tries to automatically connect. Nevertheless I do not see any difference between the different connection option since *if* I am asked to reenter the password it does not help to select the respective network form the menu in KNM.

Additional remark on the subject of this bug: I am not sure if this bug is really only connected to WPA networks... I am seeing this behavior on the laptop of my girl-friend, too, with a WEP/ASCII WLAN. She knows the password by heart by now but it still is very annoying. It does not happen all the time, though, so it seems to be very much the same issue.

Tambet, will NM eventually support to retry a wireless connection a few times before asking the user for a new key?

For KNM we can simply show the "old" key in the appropriate editbox so that the user only has to click on "connect" when he is sure the key is correct. This way we will keep the possibility to provide a new key when KNM is asked for one.

Tambet, can you please provide the info requested in comment #21?
Thanks.

Probably not. The reason for this is that there is no return status from the association (with WEP) - NM sends the authentication information to the AP and starts DHCP request. If that times out, NM makes an assumption the provided authentication information was wrong and asks the user for new credentials. Doing it multiple times would take a very long time. If you can come up with a solution, feel free to suggest it to the upstream NM maintainer as I need his approval for every commit.

Closing as WONTFIX as KNM can not decide whether the key is wrong or association failed due to another reason and therefore has to ask for a new key.