Every Wi-Fi disconnection is treated as an authentication error

Bug #615239 reported by Braiam Peguero on 2010-08-09
This bug affects 9 people
Affects Status Importance Assigned to Milestone
Canonical System Image
John McAleely
network-manager (Ubuntu)

Bug Description

Binary package hint: network-manager

I'm using lucid, with the 0.8-0ubuntu3, in a laptop, and is incredible that the nm-applet couldn't diagnostic why the wireless connection was lost and only trow the password prompt when I've lost the signal. nm-applet should see the kern.log or dmesg to react at signal lost. For example, when the kernel try 3 times probe the AP and don't get response nm-applet say The pc are far away from the access point and can not be connected. Please, move close to the access point or try another more near. And by the way, when the authentication fails, or the association.
Architecture: i386
CRDA: Error: [Errno 2] No existe el archivo o directorio
CheckboxSubmission: ee8ebec101005ce57a9c3355b36ca8a7
CheckboxSystem: edda5d4f616ca792bf437989cb597002
DistroRelease: Ubuntu 10.04
 auto lo
 iface lo inet loopback
InstallationMedia: Ubuntu 10.04 LTS "Lucid Lynx" - Release i386 (20100429)
IpRoute: dev wlan1 proto kernel scope link src metric 2 dev wlan1 scope link metric 1000
 default via dev wlan1 proto static
Keyfiles: Error: [Errno 2] No existe el archivo o directorio
Package: network-manager 0.8-0ubuntu3
PackageArchitecture: i386
 PATH=(custom, no user)
ProcVersionSignature: Ubuntu 2.6.32-24.39-generic
 0: phy0: Wireless LAN
  Soft blocked: no
  Hard blocked: no
Tags: lucid
Uname: Linux 2.6.32-24-generic i686

apport information

tags: added: apport-collected
description: updated

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

Thank you for taking the time to report this bug and helping to make Ubuntu better. The issue you are reporting is an upstream one and it would be nice if somebody having it could send the bug to the developers of the software by following the instructions at https://wiki.ubuntu.com/Bugs/Upstream/GNOME. If you have done so, please tell us the number of the upstream bug (or the link), so we can add a bugwatch that will inform us about its status. Thanks in advance.

Changed in network-manager:
status: Unknown → New

Since this bug related to getting better diagnostic/error messages and is more of an improvement to functionality than a bug in it, marking it confirmed/wishlist.

Changed in network-manager (Ubuntu):
status: New → Confirmed
importance: Undecided → Wishlist
Braiam Peguero (braiampe) wrote :

I've thinking about made the changes for the ubuntu package instead from upstream as Gnome guys are so busy attending mayor bugs.

Braiam Peguero (braiampe) wrote :

I've thinking about made the changes for the Ubuntu packages instead the uptream to modify the whole package as the GNOME guys are so busy attending mayors bugs. Maybe I could open a project like "nm-applet-enchantments", but still need some help about understanding the code.


You're welcome to work on improvements to NM, nm-applet, and other items in the stack. The only thing is that these things would really benefit from being tested and getting some feedback from upstream, so I'd encourage you to bring up your ideas for discussion on the NetworkManager mailing list (http://mail.gnome.org/mailman/listinfo/networkmanager-list). You also probably don't need a separate project for it (though you can create one if you want). One final thing you might want to look into is checking whether the changes wouldn't fit better in wpasupplicant than in NetworkManager. Please don't hesitate to contact me on IRC in #nm on Freenode or by email if you want to discuss these further.

Changed in network-manager:
importance: Unknown → Wishlist
Changed in network-manager:
status: New → Incomplete
Changed in network-manager:
status: Incomplete → Invalid
Thomas Hood (jdthood) on 2012-06-24
summary: - N. M. should have better wifi diagnostic.
+ NM should respond more intelligently to Wi-Fi disconnection
Changed in network-manager:
importance: Wishlist → High
status: Invalid → New
summary: - NM should respond more intelligently to Wi-Fi disconnection
+ Every Wi-Fi disconnection is treated as an authentication error
Selene ToyKeeper (toykeeper) wrote :

Any reason why this bug is marked as wishlist?

It has been failing for many years, and continues to be somewhere between an inconvenience and a headache. I keep running into it lately because it breaks automated tests or makes them unreliable.

Andrea Bernabei (faenil) wrote :

any update on this?

This is quite annoying especially on phone devices.
When you leave a WiFi an NM tries to reconnect and fails because it's too far, it treats that as an auth error, that prompts a UI dialog on your phone, asking for WiFi password.

That's already not ideal, but there's more: since it failed connecting, NM won't reconnect to that WiFi again when you go back into the same WiFi area, unless you explicitly ask it to...

Andrea Bernabei (faenil) wrote :

Another usecase when this behaviour is bad for UX:

I once connected to an AP created by a friend of mine with his iPhone, the AP name was "iPhone"...
now it seems whenever I go close to a person who has an iPhone hotstop active, the device tries to connect, fails, and when I'm back home I find the UI dialog asking for the password for "iPhone" AP...

Changed in network-manager:
status: New → Confirmed
Changed in canonical-devices-system-image:
assignee: nobody → John McAleely (john.mcaleely)
importance: Undecided → High
milestone: none → backlog
status: New → Confirmed
Andrea Bernabei (faenil) wrote :

Is there anything we can do to help upstream with this? Upstream does not seem to have a plan to fix this (the linked gnome bug was last updated 3 years ago)

tags: added: connectivity
Phill (phill.l) wrote :

There is a potential security issue here.

Whenever a legitimate program is seen asking for a password as the result of an automatic operation people come to think of it as normal. This undermines the suspicion that we would otherwise encourage in people to help them avoid scams and malicious software.

A more serious security issue arises if you are using a normal user account and the connection in question is shared. In this case you get a second dialogue box asking for an administrator password for privilege escalation. In this case we have users socially engineered to provide privilege escalation to any user-space program that impersonates this bug.

I think it would be preferable that it didn't ask for a password (even if we know that's what's wrong) and just retried from time-to-time. If the user wants to remedy the situation they can just go through what they did first time they connected, at least then they expect to be asked for a password so no harm is done.

Observations based on 16.04.

Even it is annoying to be asked for a password when not editing the network settings.
Just ignoring the failure and searching for another network is the best thing to do when an access point cannot be connected to.

Probably we could have some settings where we could choose to do the following things
 - Pin the client to a specific host (MAC address where authentication was done with and not allowing to connect to different hardware, probably a good idea for most home networks, but will most likely not work with networks like FreeWifi)
 - Prefer the authenticated host when available, but do not pin the client to it.
 - Connect to any host with matching SSID with no preference.
This setting is necessary for each authenticated SSID, so that we can configure our home network different from the FreeWifi used everywhere else.

Pinning the client to an access point could improve security a bit as it prevents connecting to another (malicious?) access point with the same SSID without user's knowledge.
A malicious access point could be used for man-in-the-middle attacks.

But it is not impossible to clone an access point with the same MAC, but those cloned access points would then probably interfere with each other if they are near to each other.
That would make a man-in-the-middle attack a bit harder.

We could keep a list of hardware where authentication was rejected, so that we won't keep on trying to reconnect with a wrong password.
But we should keep on retrying, if the fault was a connection fault only, but not a reject due to wrong credentials.

Probably in NM we should have a menu entry "Reconnect" which deletes the list of wrong password access points and tries to reconnect to the already authenticated access point.
If matching access points exist and reconnecting fails for all available access points, we should get an error message with an OK button (default) and a button "enter new credentials" to get a password dialog to enter a new password.

But the user should get these dialogs only when actively editing the network preferences and trying to reconnect, but not when just using the network.

Changed in network-manager:
status: Confirmed → Incomplete
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

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