debcrafters-packages team mailing list archive
-
debcrafters-packages team
-
Mailing list archive
-
Message #07066
[Bug 2122458] Re: Password re-entry popup does not appear on incorrect password entry with WPA3 networks
** 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 scenario where (last state == AUTHENTICATING, current state ==
+ DISCONNECT, "sae" as network type) is 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 proposed patch limits this occurrence by only showing the prompt if
this cycle happens twice, which is sufficient to nearly totally
eliminate the false positives in my testing so far.
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 unexpected behavior
seems to be purely cosmetic. From my discussions with NM upstream, there
really is not any higher level of precision we can get from
wpa_supplicant, due to their upstream not merging patches that would
expose the failure reason over dbus for NM to read - so this might be
the most precise approach we can get.
[ Other Info ]
Upstream patch: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2282
Impacts Noble, Plucky, Questing
Likely impacts Jammy (to be confirmed)
** 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.
The scenario where (last state == AUTHENTICATING, current state ==
DISCONNECT, "sae" as network type) is 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 proposed patch limits this occurrence by only showing the prompt if
this cycle happens twice, which is sufficient to nearly totally
eliminate the false positives in my testing so far.
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 unexpected behavior
seems to be purely cosmetic. From my discussions with NM upstream, there
really is not any higher level of precision we can get from
wpa_supplicant, due to their upstream not merging patches that would
expose the failure reason over dbus for NM to read - so this might be
the most precise approach we can get.
+ I believe this (theoretically possible, but not yet observed) quirk is
+ preferable to the user not being able to see a re-entry popup *at all*
+
[ Other Info ]
Upstream patch: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2282
Impacts Noble, Plucky, Questing
Likely impacts Jammy (to be confirmed)
** 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.
The scenario where (last state == AUTHENTICATING, current state ==
DISCONNECT, "sae" as network type) is 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 proposed patch limits this occurrence by only showing the prompt if
this cycle happens twice, which is sufficient to nearly totally
eliminate the false positives in my testing so far.
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 unexpected behavior
seems to be purely cosmetic. From my discussions with NM upstream, there
really is not any higher level of precision we can get from
wpa_supplicant, due to their upstream not merging patches that would
expose the failure reason over dbus for NM to read - so this might be
the most precise approach we can get.
I believe this (theoretically possible, but not yet observed) quirk is
- preferable to the user not being able to see a re-entry popup *at all*
+ preferable to the user never being able to see a re-entry popup *at all*
[ Other Info ]
Upstream patch: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2282
Impacts Noble, Plucky, Questing
Likely impacts Jammy (to be confirmed)
** 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.
The scenario where (last state == AUTHENTICATING, current state ==
DISCONNECT, "sae" as network type) is 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 proposed patch limits this occurrence by only showing the prompt if
this cycle happens twice, which is sufficient to nearly totally
eliminate the false positives in my testing so far.
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 unexpected behavior
seems to be purely cosmetic. From my discussions with NM upstream, there
really is not any higher level of precision we can get from
wpa_supplicant, due to their upstream not merging patches that would
expose the failure reason over dbus for NM to read - so this might be
the most precise approach we can get.
I believe this (theoretically possible, but not yet observed) quirk is
preferable to the user never being able to see a re-entry popup *at all*
+ until they forget the saved profile.
[ Other Info ]
Upstream patch: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2282
Impacts Noble, Plucky, Questing
Likely impacts Jammy (to be confirmed)
** 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.
+ very niche scenarios.
- The scenario where (last state == AUTHENTICATING, current state ==
+ The conditional where (last state == AUTHENTICATING, current state ==
DISCONNECT, "sae" as network type) is 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.
+ goes out of range or down, meaning the password request could
+ theoretically be brought up in this state as well, which does not make
+ sense.
The proposed patch limits this occurrence by only showing the prompt if
this cycle happens twice, which is sufficient to nearly totally
- eliminate the false positives in my testing so far.
+ eliminate the false positives in my testing so far, and is typical of an
+ incorrect password attempt (since multiple re-authentications will
+ typically happen in a row).
- 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 unexpected behavior
- seems to be purely cosmetic. From my discussions with NM upstream, there
- really is not any higher level of precision we can get from
- wpa_supplicant, due to their upstream not merging patches that would
- expose the failure reason over dbus for NM to read - so this might be
- the most precise approach we can get.
+ In a test of an older version of the patch, where I could force the
+ password prompt to appear on AP disconnect, 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 unexpected behavior would be purely cosmetic if it did occur with my
+ latest revision.
- I believe this (theoretically possible, but not yet observed) quirk is
- preferable to the user never being able to see a re-entry popup *at all*
- until they forget the saved profile.
+ From my discussions with NM upstream[0], there really is not any higher
+ level of precision we can get from wpa_supplicant, due to their upstream
+ not merging patches that would expose the failure reason over dbus for
+ NM to read - so this might be the most precise approach we can get.
+
+ I believe this (theoretically possible, but not yet observed) cosmetic
+ quirk is preferable to the user never being able to see a re-entry popup
+ *at all* until they forget the saved profile.
[ Other Info ]
Upstream patch: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2282
Impacts Noble, Plucky, Questing
Likely impacts Jammy (to be confirmed)
+
+ [0]
+ https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2230#note_3091605
** 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.
The conditional where (last state == AUTHENTICATING, current state ==
DISCONNECT, "sae" as network type) is this same scenario if a WPA3 AP
goes out of range or down, meaning the password request could
theoretically be brought up in this state as well, which does not make
sense.
The proposed patch limits this occurrence by only showing the prompt if
this cycle happens twice, which is sufficient to nearly totally
- eliminate the false positives in my testing so far, and is typical of an
- incorrect password attempt (since multiple re-authentications will
- typically happen in a row).
+ eliminate the false positives on AP disconnect in my testing so far, but
+ is typical of an incorrect password attempt (since multiple re-
+ authentications will typically happen in a row).
In a test of an older version of the patch, where I could force the
password prompt to appear on AP disconnect, 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 unexpected behavior would be purely cosmetic if it did occur with my
latest revision.
From my discussions with NM upstream[0], there really is not any higher
level of precision we can get from wpa_supplicant, due to their upstream
not merging patches that would expose the failure reason over dbus for
NM to read - so this might be the most precise approach we can get.
I believe this (theoretically possible, but not yet observed) cosmetic
quirk is preferable to the user never being able to see a re-entry popup
*at all* until they forget the saved profile.
[ Other Info ]
Upstream patch: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2282
Impacts Noble, Plucky, Questing
Likely impacts Jammy (to be confirmed)
[0]
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2230#note_3091605
--
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.
The conditional where (last state == AUTHENTICATING, current state ==
DISCONNECT, "sae" as network type) is this same scenario if a WPA3 AP
goes out of range or down, meaning the password request could
theoretically be brought up in this state as well, which does not make
sense.
The proposed patch limits this occurrence by only showing the prompt
if this cycle happens twice, which is sufficient to nearly totally
eliminate the false positives on AP disconnect in my testing so far,
but is typical of an incorrect password attempt (since multiple re-
authentications will typically happen in a row).
In a test of an older version of the patch, where I could force the
password prompt to appear on AP disconnect, 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 unexpected behavior would be purely cosmetic if it
did occur with my latest revision.
From my discussions with NM upstream[0], there really is not any
higher level of precision we can get from wpa_supplicant, due to their
upstream not merging patches that would expose the failure reason over
dbus for NM to read - so this might be the most precise approach we
can get.
I believe this (theoretically possible, but not yet observed) cosmetic
quirk is preferable to the user never being able to see a re-entry
popup *at all* until they forget the saved profile.
[ Other Info ]
Upstream patch: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2282
Impacts Noble, Plucky, Questing
Likely impacts Jammy (to be confirmed)
[0]
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2230#note_3091605
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/2122458/+subscriptions
References
