Public bug reported:
[ Impact ]
On a system without a secret agent, such as a headless server,
NetworkManager 1.54.3 can stop reconnecting to Wi-Fi after a single
failed 4-way handshake, even when the stored PSK is correct.
If the supplicant disconnects during the 4-way handshake while the
device is in the CONFIG state, need_new_wpa_psk() treats this as a wrong
PSK for any profile with key-mgmt=wpa-psk and requests new secrets with
REQUEST_NEW. Without an agent this fails with "No agents were available
for this request", the device fails with reason no-secrets, and the
policy blocks the profile from autoconnect. The block has no timer: only
a registering agent, a profile change, a NetworkManager restart or a
manual activation clears it. connection.autoconnect-retries does not
affect it. A handshake can fail for reasons unrelated to the PSK, such
as an access point that stalls or loses power, which is the case the
upstream commit message describes.
We hit this on 2026-10-24 on an Ubuntu 26.04 server whose only network
link is Wi-Fi (Intel BE200). The access point stalled and then lost
power. The server stayed offline for almost ten hours, although that
access point and a second one with the same SSID were back within
minutes. The connection used SAE, and the authentication exchange plus
"PMKSA-CACHE-ADDED" were logged before the association, so the password
had already been verified.
Journal, network-manager 1.54.3-2ubuntu3.1, wpasupplicant
2:2.11-0ubuntu5 (lines shortened, BSSID removed):
15:03:36 wpa_supplicant: wlo1: CTRL-EVENT-DISCONNECTED bssid=<AP> reason=15
15:03:36 NetworkManager: device (wlo1): Activation: (wifi) disconnected
during association, asking for new key
15:03:36 NetworkManager: device (wlo1): no secrets: No agents were
available for this request.
15:03:36 NetworkManager: device (wlo1): state change: need-auth -> failed
(reason 'no-secrets')
After 15:03:40 (supplicant state "inactive") the next NetworkManager
message for wlo1 came at 00:58:54, after a manual "nmcli connection up".
Upstream fixed this in 1.58.0 with MR 2308, "wifi: respect
connection.auth-retry for WPA connections" (merged 2026-02-05). For a
profile that has connected before, a failed handshake now consumes an
authentication retry and NetworkManager retries with the existing
secrets. It only asks for new secrets at the last attempt, and with
connection.auth-retries=0 it never asks. Upstream issue 1316 describes
the same problem.
Ubuntu already carries the related core-add-handlers-
for-{PskMismatch,SaePasswordMismatch}-signal.patch (LP: #2122458).
Commit 746a5902 extends that PskMismatch handler, so this backport
completes the work for the case where the PSK is correct.
Requested commits from MR 2308: a3267aaf, 6dc51ddf, 746a5902 and
b4fc8550 (the man page). All four apply cleanly with "git apply" on top
of the 1.54.3-2ubuntu3.1 source with its 13 patches. I have not built
the package.
[ Test Plan ]
Reproducible in a VM with mac80211_hwsim and hostapd, with no secret
agent running (on Ubuntu Desktop, stop gdm: the greeter registers one).
1. modprobe mac80211_hwsim radios=2; nmcli device set wlan1 managed no
2. Run hostapd on wlan1 with WPA2-PSK and passphrase A.
3. Add a profile on wlan0 with key-mgmt wpa-psk and passphrase A, and connect
once.
4. Restart hostapd with passphrase B.
5. Restart hostapd with passphrase A.
Current result: step 4 ends in "failed (reason 'no-secrets')", and after
step 5 the device stays disconnected until a manual activation. In our
test it was still disconnected after two minutes.
Expected with the fix and connection.auth-retries=0: "retrying
connection" or "reauthenticating connection" instead of "asking for new
key", no no-secrets failure, and a reconnect within seconds after step
5.
Regression check with an agent running: a new profile still prompts at
the first failure, and a connected profile still prompts after a real
passphrase change, after the remaining retries.
[ Where problems could occur ]
Only WPA-PSK authentication failures in the CONFIG state change. For a
profile that has connected before, a real passphrase change now produces
a prompt a few failed attempts later instead of at once, a trade-off
upstream accepted. New profiles keep the current behaviour. Since the
Ubuntu PskMismatch handler is modified, a regression would most likely
show up as a late or missing prompt on WPA2 networks. The 802.1X path
and the SAE password mismatch handler are unchanged.
[ Other Info ]
resolute has 1.54.3-2ubuntu3.1; stonking and tenacious have 1.58.1-1ubuntu3.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2308
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1316
Workaround on 1.54: register any secret agent after the failure, or activate
the connection manually.
** Affects: network-manager (Ubuntu)
Importance: Undecided
Status: New
** Tags: resolute
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2172161
Title:
[SRU] Backport "wifi: use authentication retry mechanism" to resolute:
Wi-Fi stops reconnecting after one failed 4-way handshake when no
secret agent is running
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/2172161/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
