nm-applet loses right to access keyring after long hibernation and has no way to restore access

I also have this problem on a ThinkPad T40 with Gutsy and an Intel Pro Wireless 2100B card.

Thank you for taking the time to report this bug and helping to make Ubuntu better. The issue that you reported is one that should be reproducible with the live environment of the Desktop CD of the development release - Hardy Heron. It would help us greatly if you could test with it so we can work on getting it fixed in the next release of Ubuntu. You can find out more about the development release at http://www.ubuntu.com/testing/ . Thanks again and we appreciate your help.

We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks again!.

fyi: I had this problem on Gutsy, but since I upgraded to Hardy it hasn't appeared anymore.

I am experiencing this on Hardy as well. After resuming from hibernate, especially if I've connected to another network in the meantime, I enter my login password once to unlock the screen, then nm-applet asks for it again in order to unlock the keyring and supply my WPA key. I do not believe this is a dupe of 157511, since that is referring to the WPA key, NOT the login password. They are different issues.

could you check intrepid/jaunty and report whether this issue is still valid in NM 0.7?

I think the original issue seems to be fixed. If you still see a similar issue check i nsyslog whether the connect fails. If thats the case NM re-asks for a password as it assumes that it might be wrong - especially when using wep encryption NM cannot tell whether password is wrong or you just got a driver/network timeout.

#7: You're misreading the bug report. The problem isn't that the network fails to connect and asks for the _network_ password. It asks for the user's _login_ password to use gnome-keyring's default keyring to _look up_ the network password before trying to connect. That bug, which is the bug originally reported above, still exists in Karmic.

See bug #34898. gdm uses a pam module to unlock the default gnome-keyring keyring on login. gnome-screensaver should do the same thing when the user enters their password to unlock the screen. That would solve this bug.

Both /etc/pam.d/gdm and /etc/pam.d/gnome-screensaver contain:
auth optional pam_gnome_keyring.so

However, only the former contains:
session optional pam_gnome_keyring.so auto_start

That's how it should be according to the documentation:
http://live.gnome.org/GnomeKeyring/Pam

Is gnome-keyring-daemon supposed to be killed on hibernate? If that's the case, then it should be sufficient to append auto_start to the end of the auth line in /etc/pam.d/gnome-screensaver, since that pam module checks if the keyring daemon is already running and doesn't start it again if it is.

Seems possibly related to bug #150432, though neither of the reasons the commenters there stated for gnome-keyring-daemon dying on hibernate seem to be true for me.

After a little investigation, it seems gnome-keyring-d _isn't_ dying on hibernate, at least not always. So either it's dying sporadically for some reason, or there's some other reason why that line in gnome-screensaver's PAM config (which should unlock the default keyring) doesn't prevent network-manager from thinking the keyring is still locked.

Thank you for your bug report. This bug has been reported to the developers of the software. You can track it and make comments at: https://bugzilla.gnome.org/show_bug.cgi?id=603626

Thank you for taking the time to report this bug and helping to make Ubuntu better. We are sorry that we do not always have the capacity to look at all reported bugs in a timely manner.
There have been many changes in Ubuntu since the last comment and your problem may have been fixed with some of the updates. It would help us a lot if you could test the current Ubuntu version (10.10). If you can test it, and it is still an issue, we would appreciate if you could upload updated logs by running apport-collect <bug #>, and any other logs that are relevant for this particular issue.

Has anyone had this problem recently?