Every Wi-Fi disconnection is treated as an authentication error

apport information

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.

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.

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

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.

Braiam,

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.

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.

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...

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...

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)

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.