13.10: Multiple network manager authentication dialogs for saved network

Bug #1224040 reported by Steve Magoun
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
network-manager (Ubuntu)
In Progress
Medium
Mathieu Trudel-Lapierre

Bug Description

I'm using 13.10 on a Dell XPS13. Network Manager will sometimes put up multiple (10+) authentication dialogs asking me for the password to reconnect to my wireless network. Network Manager already knows the password for the network, and automatically joins the network after reboot/resume/etc.

I think there are 2 issues:
1) Network Manager asks for the password even though it already knows the password
2) Network Manager puts up too many dialogs (this issue is reported elsewhere, for example bug 1059529)

Steps to reproduce:
1) Connect to a wireless network
2) Leave the machine idle for awhile
3) Unlock the machine from the lock screen

Expected results:
After unlocking the machine, the desktop and all windows are onscreen. There are no authentication dialogs from network manager

Actual results:
After unlocking the machine, the desktop and all windows are onscreen. There are 10+ authentication dialogs from network manager

Regression info: I thought this was fixed in 12.10/13.04 but it's happening for me in 13.10.

ProblemType: Bug
DistroRelease: Ubuntu 13.10
Package: network-manager 0.9.8.0-0ubuntu20
ProcVersionSignature: Ubuntu 3.11.0-5.11-generic 3.11.0
Uname: Linux 3.11.0-5-generic x86_64
ApportVersion: 2.12.1-0ubuntu3
Architecture: amd64
Date: Wed Sep 11 14:11:40 2013
DistributionChannelDescriptor:
 # This is a distribution channel descriptor
 # For more information see http://wiki.ubuntu.com/DistributionChannelDescriptor
 canonical-oem-somerville-precise-amd64-20120703-2
IfupdownConfig:
 auto lo
 iface lo inet loopback
InstallationDate: Installed on 2012-11-29 (286 days ago)
InstallationMedia: Ubuntu 12.04 "Precise" - Build amd64 LIVE Binary 20120703-15:08
IpRoute:
 default via 10.0.1.1 dev wlan0 proto static
 10.0.1.0/24 dev wlan0 proto kernel scope link src 10.0.1.55 metric 9
 10.0.3.0/24 dev lxcbr0 proto kernel scope link src 10.0.3.1
 192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1
MarkForUpload: True
NetworkManager.state:
 [main]
 NetworkingEnabled=true
 WirelessEnabled=true
 WWANEnabled=true
 WimaxEnabled=true
SourcePackage: network-manager
UpgradeStatus: Upgraded to saucy on 2013-07-19 (54 days ago)
nmcli-dev:
 DEVICE TYPE STATE DBUS-PATH
 wlan0 802-11-wireless connected /org/freedesktop/NetworkManager/Devices/0
nmcli-nm:
 RUNNING VERSION STATE NET-ENABLED WIFI-HARDWARE WIFI WWAN-HARDWARE WWAN
 running 0.9.8.0 connected enabled enabled enabled enabled disabled

Revision history for this message
Steve Magoun (smagoun) wrote :
Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

Confirming/Triaged.

Seems like there are still some issues with asking for the wifi password and possibly a race between NM getting that information and when the keyring is ready to hand over the information; this is the only way it could work sometimes after a reboot.

Changed in network-manager (Ubuntu):
status: New → Triaged
importance: Undecided → Medium
Changed in network-manager (Ubuntu):
status: Triaged → In Progress
assignee: nobody → Mathieu Trudel-Lapierre (mathieu-tl)
Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

Part of the problem is not going to be fixed now: some of it is in network-manager-applet, which should somehow watch for pending activations and properly close the auth dialog, maybe, if it's possible. This is what is going to fix the *no* auth dialogs from NetworkManager on the screen.

NetworkManager itself appears to be resetting the number of retries for *all* "failed" connections regardless of what the cause for failure was, even if that failure was caused by missing secrets (what seems to be causing the prompt for entering the password again).

Now, this particular issue can come from buggy drivers which would pass the secret wrong or otherwise fail to connect to an access-point with an unusual or plain incorrect return code. We can't really account for these without special casing each driver. However, I was able to reproduce the issue and write a patch that seems to properly fix the authentication cases where the password in "incorrect" in NM or otherwise refused by the AP. When a connection fails because of missing secrets (e.g the user was prompted but never answered), the connection is properly marked as failed; then, after 5 minutes the connections that are failed because of "missing secrets" don't have their retries set back to 0 like the other failed connections, but rather will wait until an agent registers, at they should.

There is a test package being built at https://launchpad.net/~mathieu-tl/+archive/ppa/+sourcepub/3776171/+listing-archive-extra (my PPA). Please give it a shot and let me know if this fixes the issue acceptably.

Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

Found a master bug for this, will mark as a duplicate.

Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

Marking as a duplicate of bug 912702

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.