debcrafters-packages team mailing list archive

[Mitchell Augustin <2122458@xxxxxxxxxxxxxxxxxx>]

>From e9b4ed1d44b9dcece8f51afc4706e1165859642f Mon Sep 17 00:00:00 2001
From: Mitchell Augustin <mitchell.augustin@xxxxxxxxxxxxx>
Date: Tue, 9 Sep 2025 13:57:16 -0500
Subject: [PATCH] Show incorrect password re-entry prompt for WPA3-SAE networks

---
 src/core/devices/wifi/nm-device-wifi.c | 35 +++++++++++++++++++++++++-
 1 file changed, 34 insertions(+), 1 deletion(-)

diff --git a/src/core/devices/wifi/nm-device-wifi.c b/src/core/devices/wifi/nm-device-wifi.c
index b890b11052..1adb39a306 100644
--- a/src/core/devices/wifi/nm-device-wifi.c
+++ b/src/core/devices/wifi/nm-device-wifi.c
@@ -2385,6 +2385,38 @@ need_new_wpa_psk(NMDeviceWifi              *self,
     return FALSE;
 }
 
+static gboolean
+need_new_wpa3_secret(NMDeviceWifi              *self,
+                     NMSupplicantInterfaceState old_state,
+                     int                        disconnect_reason,
+                     const char               **setting_name)
+{
+    NMSettingWirelessSecurity *s_wsec;
+    NMConnection              *connection;
+    const char                *key_mgmt = NULL;
+
+    g_return_val_if_fail(setting_name, FALSE);
+
+    connection = nm_device_get_applied_connection(NM_DEVICE(self));
+
+    g_return_val_if_fail(connection, FALSE);
+
+    s_wsec = nm_connection_get_setting_wireless_security(connection);
+    if (s_wsec)
+        key_mgmt = nm_setting_wireless_security_get_key_mgmt(s_wsec);
+
+    /* Handle SAE (WPA3) connections */
+    if (g_strcmp0(key_mgmt, "sae") == 0) {
+        /* A bad password with WPA3 will cause the supplicant to disconnect
+        during the authentication phase */
+        if (old_state != NM_SUPPLICANT_INTERFACE_STATE_AUTHENTICATING)
+            return FALSE;
+
+        *setting_name = NM_SETTING_WIRELESS_SECURITY_SETTING_NAME;
+        return TRUE;
+    }
+}
+
 static gboolean
 handle_8021x_or_psk_auth_fail(NMDeviceWifi              *self,
                               NMSupplicantInterfaceState new_state,
@@ -2402,7 +2434,8 @@ handle_8021x_or_psk_auth_fail(NMDeviceWifi              *self,
     g_return_val_if_fail(req != NULL, FALSE);
 
     if (need_new_8021x_secrets(self, old_state, &setting_name)
-        || need_new_wpa_psk(self, old_state, disconnect_reason, &setting_name)) {
+        || need_new_wpa_psk(self, old_state, disconnect_reason, &setting_name)
+        || need_new_wpa3_secret(self, old_state, disconnect_reason, &setting_name)) {
         nm_act_request_clear_secrets(req);
 
         _LOGI(LOGD_DEVICE | LOGD_WIFI,
-- 
2.43.0

** Description changed:

  SRU Justification:
  
  [ Impact ]
  
  Users who input an incorrect password to a WPA3-SAE Wi-Fi network will
  not receive a prompt to enter a new password when the authentication
  fails - instead, the connection will fail silently, and the user will
  need to "forget" the saved profile and try a fresh connection attempt.
  
  [ Test Plan ]
  
  1. Set up a WPA3-SAE access point
  2. On your test device, attempt to connect to the WPA3-SAE access point with the wrong password
  
  Expected behavior: User should be presented with a dialog to re-enter the password
  Actual behavior (without patch): The connection attempt will fail silently, and the user is never presented with an option to re-enter the password. As a result, they must forget the saved connection profile and try a fresh connection attempt.
  
  [ Fix ]
  
  Add a new function need_new_wpa3_secret(), invoked via handle_8021x_or_psk_auth_fail(), that will prompt for a new secret if a disconnection occurs after the wpa_supplicant AUTHENTICATING state.
  (This is needed since the current source is only adapted to WPA2, where authentication will fail during the 4-way handshake - whereas with WPA3-SAE, it can fail during the AUTHENTICATING state)
  
  [ Where problems could occur ]
  
  Valid connection attempts to WPA3 networks should not be impacted by
  this change, since it only impacts the code path for authentication
  failures.
  
  However, the new user experience could be slightly unexpected in some
  very niche scenarios - for example, if a system has multiple saved
  (working) wifi profiles, and they attempt to connect to a WPA3 one with
  the wrong password, they might not be used to it prompting them for the
  password and waiting for input if they are used to it silently failing
  and falling back to the next valid network.
  
+ With this current approach (last state == AUTHENTICATING, current state == DISCONNECT, "sae" as network type are the key conditionals), we hit this same scenario if a WPA3 AP goes out of range or down, meaning the password request is brought up in this state as well, which does not make sense.
+ The good thing is that I was able to confirm that with another available network in the area, the DUT will still continue scanning and eventually remove the dead WPA3 network, which will allow the DUT to reconnect to the other good network in the background - so the issue seems to be purely cosmetic. However, I will still discuss with networkmanager upstream to see if there's any info we can get from wpa_supplicant to limit when this check executes.
+ 
  [ Other Info ]
  Upstream patch: TBD
  
  Impacts Noble, Plucky, Questing
  
  Likely impacts Jammy (to be confirmed)

-- 
You received this bug notification because you are a member of
Debcrafters packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/2122458

Title:
  Password re-entry popup does not appear on incorrect password entry
  with WPA3 networks

Status in network-manager package in Ubuntu:
  In Progress
Status in network-manager source package in Noble:
  New
Status in network-manager source package in Plucky:
  New
Status in network-manager source package in Questing:
  In Progress

Bug description:
  SRU Justification:

  [ Impact ]

  Users who input an incorrect password to a WPA3-SAE Wi-Fi network will
  not receive a prompt to enter a new password when the authentication
  fails - instead, the connection will fail silently, and the user will
  need to "forget" the saved profile and try a fresh connection attempt.

  [ Test Plan ]

  1. Set up a WPA3-SAE access point
  2. On your test device, attempt to connect to the WPA3-SAE access point with the wrong password

  Expected behavior: User should be presented with a dialog to re-enter the password
  Actual behavior (without patch): The connection attempt will fail silently, and the user is never presented with an option to re-enter the password. As a result, they must forget the saved connection profile and try a fresh connection attempt.

  [ Fix ]

  Add a new function need_new_wpa3_secret(), invoked via handle_8021x_or_psk_auth_fail(), that will prompt for a new secret if a disconnection occurs after the wpa_supplicant AUTHENTICATING state.
  (This is needed since the current source is only adapted to WPA2, where authentication will fail during the 4-way handshake - whereas with WPA3-SAE, it can fail during the AUTHENTICATING state)

  [ Where problems could occur ]

  Valid connection attempts to WPA3 networks should not be impacted by
  this change, since it only impacts the code path for authentication
  failures.

  However, the new user experience could be slightly unexpected in some
  very niche scenarios - for example, if a system has multiple saved
  (working) wifi profiles, and they attempt to connect to a WPA3 one
  with the wrong password, they might not be used to it prompting them
  for the password and waiting for input if they are used to it silently
  failing and falling back to the next valid network.

  With this current approach (last state == AUTHENTICATING, current state == DISCONNECT, "sae" as network type are the key conditionals), we hit this same scenario if a WPA3 AP goes out of range or down, meaning the password request is brought up in this state as well, which does not make sense.
  The good thing is that I was able to confirm that with another available network in the area, the DUT will still continue scanning and eventually remove the dead WPA3 network, which will allow the DUT to reconnect to the other good network in the background - so the issue seems to be purely cosmetic. However, I will still discuss with networkmanager upstream to see if there's any info we can get from wpa_supplicant to limit when this check executes.

  [ Other Info ]
  Upstream patch: TBD

  Impacts Noble, Plucky, Questing

  Likely impacts Jammy (to be confirmed)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/2122458/+subscriptions