network-manager forgets my password when an error occurs

[peridot]

My home wifi is slightly flaky, and stops working when there's a lightning storm or excessive traffic. It comes back after a while. But in the meantime, network-manager can still identify it but can no longer connect.

What happens: For some reason network-manager decides this means the password must have changed and prompts me for a new one, forgetting the old. This does not work, of course, and it means that network-manager can't reconnect automatically when the wifi starts working again; in fact it can't even tell me whether it is working again, and it forces me to dig up the password I use.

What should happen: The dialog box that comes up contains an error message. It offers "Retry", "Change Password", and "Cancel". Ideally the error message would contain some sort of information about what went wrong, perhaps including a "more information" section that lets me see detailed technical information. I realize getting this extra information can be a problem, since the network system is running as root, but at least it would be nice if network-manager did not assume that the network had changed its password, and especially if it didn't forget my old password.

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: network-manager-gnome 0.9.4.1-0ubuntu2
ProcVersionSignature: Ubuntu 3.2.0-23.31-lowlatency 3.2.14
Uname: Linux 3.2.0-23-lowlatency x86_64
ApportVersion: 2.0.1-0ubuntu8
Architecture: amd64
Date: Fri Jun 8 21:08:06 2012
EcryptfsInUse: Yes
IfupdownConfig:
 auto lo
 iface lo inet loopback
InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Release amd64 (20101007)
IpRoute:
 default via 192.168.2.1 dev eth0 proto static
 10.0.3.0/24 dev lxcbr0 proto kernel scope link src 10.0.3.1
 169.254.0.0/16 dev eth0 scope link metric 1000
 192.168.2.0/24 dev eth0 proto kernel scope link src 192.168.2.13 metric 1
NetworkManager.state:
 [main]
 NetworkingEnabled=true
 WirelessEnabled=true
 WWANEnabled=true
ProcEnviron:
 LANGUAGE=en_CA:en
 TERM=xterm-256color
 PATH=(custom, user)
 LANG=en_CA.UTF-8
 SHELL=/bin/bash
SourcePackage: network-manager-applet
UpgradeStatus: Upgraded to precise on 2012-04-27 (42 days ago)
nmcli-dev:
 DEVICE TYPE STATE DBUS-PATH
 eth0 802-3-ethernet connected /org/freedesktop/NetworkManager/Devices/1
 wlan0 802-11-wireless connecting (need authentication) /org/freedesktop/NetworkManager/Devices/0
nmcli-nm:
 RUNNING VERSION STATE NET-ENABLED WIFI-HARDWARE WIFI WWAN-HARDWARE WWAN
 running 0.9.4.0 connected enabled enabled enabled enabled disabled

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Michael Löffler (michaelloeffler)]

It's an even more general issue I think. The problem is, whenever anything goes wrong in the connection process, nm-applet asks the user for a password. It makes no difference, whether the wifi went down completely, the dhcp server didn't respond or anything else happened. Most of the times, it totally makes no sense, to ask the user for a new password. A clear error message with the reason for the connection problem, or the possibility to provide manual network configuration e.g. if dhcp fails, would be much better.

I'm travelling a lot and use new wifis nearly every day. Lots of them are badly maintained hotel or restaurant wifis. Given correct credentials, most connection problems are cause by bad connectivity, someone switching of the wifi unexpectedly, or by problems with the DHCP server on the router. While of course nothing helps against the first, just setting the IP address manually to something like 192.168.1.... sometimes does the job. So if there would be some proper exception handling for the connection process, a menu to enter configuration settings manually could be provided, or some configurations could be tried out automatically, even if DHCP setup fails.

And for bad connectivity or network shutdowns, this could be handled by retries with increased timeout and clear error messages, finally switching to other networks if available, without disturbing the user with a password dialogue. For the inexperienced user this is just totally misleading and keeps him retrying, while there is no hope for cure for the connection at all.