nm-tray silently fails with wifi password outside of IEEE specification

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/1865949

I tested this on a new daily install using the 20200303 install media. I never received a connection success message. I received a nm-tray message indicating the connection was lost to my wireless network every time I tried to connect using the wrong passphrase. As noted, I was able to delete the connection or edit the passphrase using the right-click "edit connections" option.

@Dan, I just tried the same 20200303 Lubuntu image on a Ryzen 5 machine. It had the same behavior as reported on the old Toshiba. I click on nm-tray, choose my wifi access point, enter an incorrect passphrase. Nothing happens. No message that the connection was attempted/failed. That access point is then in the "known connections." Clicking it does nothing (no error).

It sounds like we're having different experiences. Did you test the Lubuntu daily image? Maybe it's specific to that (since it happens for me on two different laptops)? If I can provide more info, I'm happy to.

Thank you for taking the time to report this issue and helping to make Ubuntu better.

I just tested the daily (20200303) on 'live'
sony vaio ultrabook (i5-9400u, 4gb, intel haswell-ULT)
and got a "Connection Lost" top right when an incorrect password was used (WPA2, hidden).

The incorrect password was saved in Network Connections before any checking is performed. To me the box is a data entry box & at worst may only trip newbies who hopefully will be following documentation (https://manual.lubuntu.me/stable/3/3.1/3.1.5/nm-tray.html)

When the invalid password is changed to the correct password, instead of the "Connection Lost" I get a "Connection Established" prompt.

To me all messages seemed clear.

However I didn't evaluate the documentation I made reference to.
@MarkF do we need better documentation? or can you suggest improvements? as many that's our problem.

@Chris, I'm not having the same experience as you. I enter an invalid passphrase, nothing happens. No connection-lost msg. And, it saves the failed connection. The only msg I see is when I fix the password and it connects successfully.

It doesn't appear to be machine dependent (although, both the old Toshiba and the new Ryzen 5 use Atheros wifi. Could nm-tray interact differently than that? Is there some debugging I could enable to provide more info about what's happening?).

FYI: I have a Ryzen 3 with intel wireless. I booted the Lubuntu 20200303 image on it. Same behavior. There's no progress or error message about being unable to connect. I don't know why my experience is different on 3 computers than you guys'.

I've verified the iso checksum. The file-verification at bootup shows no errors.

I also tried on and found them the same as sony ultracrap
lenovo thinkpad sl510 (c2d-t6570, 2gb ram, i915)
lenovo thinkpad x201 (i5-m520, 4gb, i915)

Steps I do
- Boot daily 'live'
- right click `nm-tray` on panel select Edit.Connections
- Network.Connections window appears. I click + to add
- Select Connection.Type Wifi, hit Create

- In fields of first open Wi-Fi tab, I change connection name (pyramid), add SSID matching my network, move down to Device and select my wlp5s0 (device name varies)
- Switch to Wi-Fi.Security field and choose WPA2 Personal, then enter my password with an extra 'd' (so it's wrong)
- click SAVE

On bottom panel I then left-click `nm-tray` and select my created 'pyramid' connection name, after a very short while top right I get a Connection.Lost ballon/notification.

(I later changed the saved pyramid removing the extra d & repeat connecting, this time it's a connection.established message).

Does what I've described here match what you are doing???

If it doesn't, can you please describe what you do, so I can try what you do differently. (hopefully you can follow this)

I left click on nm-tray, choose my wifi access point, enter an incorrect passphrase.

Maybe the difference is that you're using a hidden ssid, and have to go to network connections to get the job done? I'm doing the more normal(?) choice of available access points from nm-tray. I only right-click to go fix the saved connection (that never connected, and never gave an error msg).

I can add a new connection manually with the wrong password and it fails. The icon in the system tray changes to grey with three white horizontally-arranged dots and then returns to the grey rectangle with a white x in the lower right hand corner. A notification displays that the connection is lost.

This is also the same experience I have if I first select the connection from the list of options before first manually adding it.

If I then manually edit to the right password, the process repeats but ends in the icon turning into the full white icon and a notification that the connection is established.

BTW you can see the logs of networking with `journalctl -u NetworkManager`. In fact, you may want to follow this the `journalctl -f -u NetworkManager`.

I just booted Lubuntu 20200303 (same LiveUSB I've been testing throughout all this). I started journalctl. I then clicked nm-tray, clicked the access point, and this is what appeared:

================ start
Mar 04 07:02:44 lubuntu NetworkManager[1632]: <info> [1583305364.9596] device (wlp4s0): Activation: starting connection 'ACCESS-POINT' (981d3413-9bc9-4463-8f74-8e44666d437f)
Mar 04 07:02:44 lubuntu NetworkManager[1632]: <info> [1583305364.9597] audit: op="connection-add-activate" uuid="981d3413-9bc9-4463-8f74-8e44666d437f" name="ACCESS-POINT" pid=2278 uid=999 result="success"
Mar 04 07:02:44 lubuntu NetworkManager[1632]: <info> [1583305364.9600] device (wlp4s0): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'managed')
Mar 04 07:02:44 lubuntu NetworkManager[1632]: <info> [1583305364.9604] manager: NetworkManager state is now CONNECTING
Mar 04 07:02:44 lubuntu NetworkManager[1632]: <info> [1583305364.9608] device (wlp4s0): state change: prepare -> config (reason 'none', sys-iface-state: 'managed')
Mar 04 07:02:44 lubuntu NetworkManager[1632]: <info> [1583305364.9613] device (wlp4s0): Activation: (wifi) access point 'ACCESS-POINT' has security, but secrets are required.
Mar 04 07:02:44 lubuntu NetworkManager[1632]: <info> [1583305364.9613] device (wlp4s0): state change: config -> need-auth (reason 'none', sys-iface-state: 'managed')
Mar 04 07:02:44 lubuntu NetworkManager[1632]: <warn> [1583305364.9632] device (wlp4s0): no secrets: No agents were available for this request.
Mar 04 07:02:44 lubuntu NetworkManager[1632]: <info> [1583305364.9632] device (wlp4s0): state change: need-auth -> failed (reason 'no-secrets', sys-iface-state: 'managed')
Mar 04 07:02:44 lubuntu NetworkManager[1632]: <info> [1583305364.9638] manager: NetworkManager state is now DISCONNECTED
Mar 04 07:02:44 lubuntu NetworkManager[1632]: <warn> [1583305364.9651] device (wlp4s0): Activation: failed for connection 'ACCESS-POINT'
Mar 04 07:02:44 lubuntu NetworkManager[1632]: <info> [1583305364.9656] device (wlp4s0): state change: failed -> disconnected (reason 'none', sys-iface-state: 'managed')
================ end

No msg appeared on the desktop. The failed connection was saved as a "known connection." Clicking that in nm-tray produces the same output (but still no msg on the screen).

It's doing this on 3 different laptops so far. Maybe I have a bad ISO. I can try this again with the next daily image I test.

It sounds like the saving a bad connection isn't a problem. The silent manner is a problem. But, I'm the only person experiencing that. I can't think of how that could be possible expect for me having a fouled ISO. (But, the checksum matches. The startup file-validation routine says no errors were found.).

I changed a wifi network to be not-hidden, booted sl510 again using current daily, and get balloons telling me 'lost.connection', or if deleted & enter the correct password 'connection.established', ie. exactly what Walter describes (where balloon=notification).

On the discourse thread (https://discourse.lubuntu.me/t/testing-20-04-daily/749/41) you mention testing Xubuntu; I take it 20.04 daily which I suspect rules out base of system. Next time I'd suggest looking at networking logs as per Walter's suggestion in #10 but I'm out of ideas sorry.

@Chris, I did add the log info in #11 (one before yours).

I do see a "connection established" balloon when I use the correct passphrase. But, I don't see a failure balloon when I use the wrong passphrase.

I have to believe it's something screwy with my iso, how it was burned. Something that isn't caught by the file-validation process on startup of the LiveUSB. I'll try it again tomorrow with 20200304.

I can't think of any explantion for why I'm seeing this on 3 laptops, and three people aren't.

@Chris, can you be more specific about what you did to get the failure balloon? Did you left click nm-tray, click the non-hidden SSID, type a bad password?

This bug report is a little confusing because that's what I reported. But, there's a lot of examples about it working differently if accessed in different ways. I'm wondering if we're talking about different things? (That's the only other possible way I can think that I'd have the same experience on 3 different machines. But, 3 people have a different experience. So, I wanted to absolutely make sure about that.).

FYI: I booted 20200303 Lubuntu daily on a i7-2630QM 2.0ghz; NVIDIA GeForce GT540M 2GB; Intel Centrino 6230 (Dell XPS L502X laptop). It has the same behavior I reported in this bug.

In an hour or two I will try 20200404. I'm hoping this is just a glitch in the copy I have (but, I did burn it to USB twice. It's hard to believe there's a problem in that regard. As mentioned previously, I visually verified the checksum of the .iso file.).

> In an hour or two I will try 20200404. I'm hoping this is just a glitch in the copy I have

Maybe it's because you're using Lubuntu in a time machine? XD

Are you sure you have notifications on????? There is an icon for it in the system tray. Unless you removed it or silenced it.

The log output seems totally normal. It only tries once.

Good news. I found the problem. It's entirely related to passphrase length.

- If I type a passphrase less than 8 characters long: I get the behavior I reported (it appears nothing happens, no activity indicator, no balloon error msg, nothing in the msg tray. But, the failed connection is saved as a known connection.).

- If I type a passphrase 8 characters long, the nm-tray icon changes to something like an ellipsis (indicating activity). Then I get the expected balloon "disconnected" msg, and an alert in the tray's messages icon.

I should have thought about this last night. I was testing almost all the *buntu daily images. Because I was obsessed with this topic concerning Lubuntu, I played with those "nm-tray" equivalents to see how they behave. I *did* notice last night (in more than one distro) that they had an edit check when entering the passphrase. The "connect" button was grayed out until 8 characters were typed. I wondered how they knew my access point's passphrase was 8 characters long. (I thought there was some kind of negotiation occurring with my access point as I typed.).

It sounds like this 8-character requirement is at the Ubuntu base level. But, the other distros are handling it better? Lubuntu's lm-tray accepts anything, and does nothing with it (except saving it. Clicking that saved "known connection" similarly does nothing.).

FWIW: I'm currently running Kubuntu 19.10 as my desktop. I tried to connect to an access point using a 6-character passphrase. It too won't proceed. So, this doesn't appear to be new (I never knew Ubuntu enforced a passphrase limit. Is that something it should do?). My guess is Lubuntu 19.10 has this same behavior. Probably nobody ever tried less than 8 characters?

This is not a limit of Ubuntu. It's a limit of the IEEE standard on WPA2. See here:
https://serverfault.com/questions/164930/can-a-wpa-key-be-shorter-than-8-characters