NM loses connection and can't reconnect; "No keyring secrets" -- Intel PRO/Wireless 2200BG ipw2200

Bug #1073662 reported by Wolf Rogner
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
network-manager (Ubuntu)
New
Undecided
Unassigned

Bug Description

Whenever a new wireless router comes up, network manager tries to reconnect. It does not succeed.

The nm-applet reports:

** Message: No keyring secrets found for rsb/802-11-wireless-security; asking user.

(nm-applet:11812): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed

There is no key in the keyring store.
However on boot, the connection is established

So there are several questions:

1. Where is the WLAN credential stored that is generated using the network manager connection dialog
2. Why does the nm-applet look for the key in the keyring
3. Why is the WLAN credential not stored there

ProblemType: Bug
DistroRelease: Ubuntu 12.10
Package: network-manager 0.9.6.0-0ubuntu7
ProcVersionSignature: Ubuntu 3.5.0-18.29-generic 3.5.7
Uname: Linux 3.5.0-18-generic i686
ApportVersion: 2.6.1-0ubuntu6
Architecture: i386
Date: Wed Oct 31 18:29:44 2012
IfupdownConfig:
 # interfaces(5) file used by ifup(8) and ifdown(8)
 auto lo
 iface lo inet loopback
InstallationDate: Installed on 2012-10-26 (5 days ago)
InstallationMedia: Ubuntu 12.10 "Quantal Quetzal" - Release i386 (20121017.2)
IpRoute:
 default via 10.1.0.254 dev eth1 proto static
 10.0.0.0/8 dev eth1 proto kernel scope link src 10.1.0.199 metric 9
 169.254.0.0/16 dev eth1 scope link metric 1000
MarkForUpload: True
NetworkManager.state:
 [main]
 NetworkingEnabled=true
 WirelessEnabled=true
 WWANEnabled=true
 WimaxEnabled=true
SourcePackage: network-manager
UpgradeStatus: No upgrade log present (probably fresh install)
nmcli-con:
 NAME UUID TYPE TIMESTAMP TIMESTAMP-REAL AUTOCONNECT READONLY DBUS-PATH
 Wired connection 1 df03d4ed-6f6a-404d-82b6-242fbe8e6896 802-3-ethernet 1351703962 Mit 31 Okt 2012 18:19:22 CET yes no /org/freedesktop/NetworkManager/Settings/1
 rsb 690f1d18-c26e-4abd-91da-2dc1d35fdea3 802-11-wireless 1351704562 Mit 31 Okt 2012 18:29:22 CET yes no /org/freedesktop/NetworkManager/Settings/0
nmcli-dev:
 DEVICE TYPE STATE DBUS-PATH
 eth1 802-11-wireless connected /org/freedesktop/NetworkManager/Devices/1
 eth0 802-3-ethernet unavailable /org/freedesktop/NetworkManager/Devices/0
nmcli-nm:
 RUNNING VERSION STATE NET-ENABLED WIFI-HARDWARE WIFI WWAN-HARDWARE WWAN
 running 0.9.6.0 connected enabled enabled enabled enabled disabled

Revision history for this message
Wolf Rogner (war-rsb) wrote :
Revision history for this message
Wolf Rogner (war-rsb) wrote :

I forgot:

This happens on a fresh install of Ubuntu 12.10

Revision history for this message
Wolf Rogner (war-rsb) wrote :

Q2 and Q3 answered:

The wireless connection was available to everyone. Thus the credentials are not stored in my own keyring.

I will observ if the issue reappears now.

If so and reconnection works, the issue lies within nm-applet trying to access root keyring credentials

Revision history for this message
Wolf Rogner (war-rsb) wrote :

Just checked with my main machine.

The wlan connection is global here but the credentials are in my key store and this machine is not susceptible to network outage.

So there must be some other reason

Revision history for this message
Wolf Rogner (war-rsb) wrote :

The issue reappears consequently and cannot be solved with a workaround like in 12.04 (restart network connection manager).

The driver is ipw2200

On iwl4965 and wl the issue does not appear.

Revision history for this message
Thomas Hood (jdthood) wrote :

Are the credentials in a file in /etc/NetworkManager/system-connections/ ?

summary: - network manager looses connection, reconnect not possible
+ NM loses connection and can't reconnect; "No keyring secrets" -- Intel
+ PRO/Wireless 2200BG ipw2200
Revision history for this message
Wolf Rogner (war-rsb) wrote :

Yes in clear text
However, entering the credentials in the dialog does not help either.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.