Wi-Fi passphrase limit introduced in OTA-11

fwiw I am connecting with a 27 character passphrase on WPA

FWIW after various problems trying to get my turbo connected to a local hotspot here it suddenly started working only to stop working during one of the landings for OTA11 (I'm not here all the time so I did not notice it immediately).

The password is 40 characters long and I can no longer get turbo to connect even with a complete reflash.

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

This only started for me after having done a reset to factory settings just now with OTA 11 connecting fine since its release some time back. Phone: BQ Aquaris E5, Router Fritz!Box 7362 SL.

The reset phone would not connect to the wlan it had been on since the day i bought it a year back. Only changing the pass phrase to a shorter one enabled me to connect eventually.

This sounds like a timeout issue in the comms between the secret agent (the program that presents the dialog to the user) and indicator-network.

Agreeing with Pete, this morning i was having trouble connecting to my wifi that uses a very long and random password until i copied and pasted it so on next dialog i could just paste it (and then it worked) (FWIW i *think* i may have similar issues in the desktop too)

same thing here, since my upgrade to OTA11 and after a wipe flash, I am not able to connect to my home wifi, the password is 27 long on WEP,
I was able to get it back into working order after flashing to an earlier revision (OTA10),

My hypothesis is that the upgrade of network-manager to 1.2, which included a port from dbus-glib to gdbus, could have accidentally introduced timeouts to the method invokations from network-manager to the secret agent. Someone probably needs to check out that bit of code and see if a longer timeout can be set.

See bug #1589489 and dupe at bug #1589630, both logs show no agents were available which would be consistent with that theory

I just confirmed that this is a regression is caused by the final deprecation of dbus-glib in NM 1.2x, and it's replacement by gdbus. As part of this work, the code which requests secrets from a secret-agent, now uses code generated from the introspection XML to make the actual DBus method call. As this generated function doesn't have a parameter to allow the client to specify a timeout, the default ( ~25s ) gets used. This contrasts to the old code which explicitly specified a 120s timeout as a parameter to dbus_g_proxy_begin_call_with_timeout().

So, if the user types the passphrase ( or 64-char hex key ) in < ~25s, the connection should work. The maximum length passphrase ( repeating blocks of '1234567890' ) is ~40 characters before the timeout makes it impossible to type anything longer.

An upstream bug had been reported and is currently in-progress:

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

Currently the only workaround for this is to manually update the system connection file for the AP with the psk and restart the device. It then should be possible to tap the access point in the WiFi list, and as long as the passphrase is correct in the connection file, NM should reconnect to the network automatically when available. You can accomplish this by stopping NM on the device and editing the connection file directly, or copying the connection file from the device, editing, and pushing it back ( via adb ). System connection files are found in the directory /etc/NetworkManager/system-connections.

I've verified with a krillin running OTA11 that passphrases up to 63 characters work correctly once they've been pre-populated in a connection file. I haven't yet verified a 64-character hex key, but will make sure this is tested as well before we release the final fix.

Tony, if I remember correctly, gdbus proxies all inherit from the GDBusProxy class. I *think* you should be able to use the method g_dbus_proxy_set_default_timeout(...) on the proxy instance you use to talk to the secret agent, so that all subsequent IPC method calls use the larger timeout. I would also suggest a much larger timeout than 2 minutes.

Hmm, merge this with bug 1588126 / bug 1589489?