NetworkManager 0.7 fails to use my saved keys

[fringd]

Binary package hint: network-manager

I'm Using Ubuntu Intrepid Ibex Alpha 6 with Network Manager 0.7
Installed: 0.7~~svn20080908t183521+eni0-0ubuntu4

Network Manager will occasionally "forget" what my key is to my home wireless network.

It will prompt me for the key even though seahorse can still clearly see the key happily stored, and nm-applet still has access to it.

Network Manager should not prompt the user for a key that it already has, ever. (maybe unless it explains that the key seems wrong and asks would you like to enter a new key) nm has been doing this or something like this for a long time. it's very vexing and counterintuitive.

this will often happen when i have just
1) logged off and logged back on
2) come back from suspend
3) disabled networking and then enabled networking
4) lost connection due to weak signal

none of these things causes it to happen reliably however...

My signal is somewhat weak where i usually sit... maybe this is part of it? even so i expect network-manager to say "signal weak" not "give me that passphrase you just gave me like 10 times"

here is some info from syslog around when it happened

Sep 30 21:08:53 tortoise NetworkManager: <info> (eth1): supplicant connection state change: 0 -> 2
Sep 30 21:08:53 tortoise NetworkManager: <info> (eth1): supplicant connection state change: 2 -> 4
Sep 30 21:08:53 tortoise NetworkManager: <info> (eth1): supplicant connection state change: 4 -> 0
Sep 30 21:09:08 tortoise NetworkManager: <info> eth1: link timed out.
Sep 30 21:09:18 tortoise NetworkManager: <info> Activation (eth1/wireless): association took too long.
Sep 30 21:09:18 tortoise NetworkManager: <info> (eth1): device state change: 5 -> 6
Sep 30 21:09:18 tortoise NetworkManager: <info> Activation (eth1/wireless): asking for new secrets
Sep 30 21:09:21 tortoise NetworkManager: <info> (eth1): supplicant connection state change: 0 -> 2
Sep 30 21:09:53 tortoise NetworkManager: <info> (eth1): supplicant connection state change: 2 -> 0
Sep 30 21:09:58 tortoise NetworkManager: <info> (eth1): supplicant connection state change: 0 -> 2

network manager should be more careful about assuming that a network key is bad. perhaps there needs to be a prompt that asks if the user wants to change or delete a network key that isn't working... as it is, once nm decides the
key is no good, it is very stubborn

Sep 30 21:13:39 tortoise NetworkManager: <info> Activation (eth1) Stage 1 of 5 (Device Prepare) started...
Sep 30 21:13:39 tortoise NetworkManager: <info> Activation (eth1) Stage 2 of 5 (Device Configure) scheduled...
Sep 30 21:13:39 tortoise NetworkManager: <info> Activation (eth1) Stage 1 of 5 (Device Prepare) complete.
Sep 30 21:13:39 tortoise NetworkManager: <info> Activation (eth1) Stage 2 of 5 (Device Configure) starting...
Sep 30 21:13:39 tortoise NetworkManager: <info> (eth1): device state change: 4 -> 5
Sep 30 21:13:39 tortoise NetworkManager: <info> Activation (eth1/wireless): access point 'Auto Leesys' has security, but secrets are required.
Sep 30 21:13:39 tortoise NetworkManager: <info> (eth1): device state change: 5 -> 6
Sep 30 21:13:39 tortoise NetworkManager: <info> Activation (eth1) Stage 2 of 5 (Device Configure) complete.
Sep 30 21:13:40 tortoise NetworkManager: <info> (eth1): supplicant connection state change: 2 -> 0
Sep 30 21:13:45 tortoise NetworkManager: <info> (eth1): supplicant connection state change: 0 -> 2

a lot of keys are big long strings of numbers that users DO NOT remember. It's very vexing to have to go and find them again and again. this severely sours the experience. wicd does not do this, so i know that better is possible.

[Alexander Sack (asac)]

do you try to use system settings?

[Patrick Wagstrom (pridkett)]

I'm also experiencing the same error using NetworkManager 0.7 on Ubuntu 8.10 with an atheros card. Oddly enough, it even comes up when NetworkManager sees that I have a wired network connection. However, this does not happen 100% of the time which makes it very difficult to track down.

[Alecz20 (alexguzu)]

Trying to use "System setting" is affected by another bug, where the "check" is not remembered. Only if the other option, "Connect automatically" is also changed, will the "System setting" be remembered.

Using the "System setting" (in the above manner), solves the problem with the password request, but it still does not connect to the wireless network

Syslog excerpt:

Dec 13 01:55:11 alex-laptop NetworkManager: <info> Activation (eth1/wireless): association took too long.
Dec 13 01:55:11 alex-laptop NetworkManager: <info> (eth1): device state change: 5 -> 9
Dec 13 01:55:11 alex-laptop NetworkManager: <info> Activation (eth1) failed for access point (Matrix)
Dec 13 01:55:11 alex-laptop NetworkManager: <info> Marking connection 'Auto Matrix' invalid.
Dec 13 01:55:11 alex-laptop NetworkManager: <info> Activation (eth1) failed.
Dec 13 01:55:11 alex-laptop NetworkManager: <info> (eth1): device state change: 9 -> 3
Dec 13 01:55:11 alex-laptop NetworkManager: <info> (eth1): deactivating device (reason: 0).

Network manager also shows about 40% signal strength.

[Mackenzie Morgan (maco.m)]

It's possible that due to the weak signal it *thinks* the key is being rejected and so is prompting as if the passphrase was incorrect. Can you try moving closer to the access point, then see if you can still reproduce it?

[Alecz20 (alexguzu)]

I am unable to reproduce this anymore. One of the reasons is that I connect via a cable now.
On the few occasions that I connected wirelessly, it worked perfectly.

[Mackenzie Morgan (maco.m)]

Thank you
 status fixreleased