nm-applet silently timesout on long 'WPA/WPA2 Personal' password input

[Etienne Papegnies]

1)
ouroumov@Edge:~/Desktop$ lsb_release -rd
Description: Ubuntu 16.04 LTS
Release: 16.04

2)
apt-cache policy is unable to locate the package.

3)
Upon entering a long WPA/WPA2 Personal password after clicking the network icon in the top right panel, the connection should be added to network-manager, even if typing the password takes a while.

4)
If typing the password takes longer than ~25 seconds, upon clicking the "Connect" button in the password prompt dialog: nothing happens

Steps to reproduce:

- Install Ubuntu MATE 16.04 LTS (possibly other Ubuntu flavours using nm-applet too)
- Run normal post-install full system update and reboot
- Click the network icon in the top right corner of the default panel layout
- Select from the Wi-Fi network list a network using WPA/WPA2 Personal
- Enter the password, wait 30 seconds to click 'connect'

Note:

While this issue might seem trivial (using 'System -> Preferences -> Internet and Network -> Network Connections' allows one to correctly save the password) (and quickly copy/pasting the password from a text file works too) it is a serious usability problem for many people in France.

The default home router Wi-Fi setup in France is WPA/WPA2 Personal with a random 26-character hexadecimal password. It takes a while to type.

[Sebastien Bacher (seb128)]

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.

[Etienne Papegnies (etienne-papegnies)]

Reported upstream @ https://bugzilla.gnome.org/show_bug.cgi?id=767321

[Sebastien Bacher (seb128)]

thanks

[Etienne Papegnies (etienne-papegnies)]

@Tony Espy: did you report this against Ubuntu Proper?
I'd like to watch for that SRU.
Also, shouldn't importance be at least "High" since #1589489 and #1593686 are High/Critical?

[Aron Xu (happyaron)]

Should be mitigated in yakkety in 1.2.4 by upstream commit 6eca877ffd90de472806ac28dc5313bb8ac57523 as suggested in https://bugzilla.gnome.org/show_bug.cgi?id=767321#c32

[Etienne Papegnies (etienne-papegnies)]

Hello Aron Xu
Sorry for reopening this, but does this mean this is a "Won't Fix" in Xenial?
I'm asking because with Fix Released status this bug report is no longer visible. :/

[Aron Xu (happyaron)]

@etienne-papegnies, no, the plan is SRU all 1.2.x series to Xenial, so it's not Won't Fix, but rather I cannot open a separate task for xenial at the moment (someone with proper permission may help).

[Etienne Papegnies (etienne-papegnies)]

Thank you very much for the reply.
I was worried because I had a hard time finding this report when I attempted to set Bug #1619967 as a duplicate of this one.

[Etienne Papegnies (etienne-papegnies)]

@happyaron, network-manager-gnome version in Xenial is now 1.2.6-0ubuntu0.16.04.2

I've confirmed that the mitigation (longer timeout) is now in effect.