** 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 Ubuntu Touch seeded 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : [email protected] Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
