WPA3-SAE & WPA2-PSK mode connections does not succeed after wrong key attempt

Affected images versions

• not relevant (explain why)
• see the table below (list the build id and the apt or ostree deployment of the tested images in the appropriate cells)

Type	Arch	v2021	v2022	v2023dev2
minimal/fixedfunction	amd64
minimal/fixedfunction	armhf
minimal/fixedfunction	arm64
target/hmi	amd64
target/hmi	armhf			20220902.0018
target/hmi	arm64
basesdk	amd64
sdk	amd64
nfs	amd64
nfs	armhf
nfs	arm64
lxc	amd64
lxc	armhf
lxc	arm64
image-builder
package-source-builder

To find the build id and the variant type you can:

• derive it from the image name
  • for instance, with the apertis_ostree_v2022pre-fixedfunction-amd64-uefi_20211031.0425.img.gz image the build id is 20211031.0425, the variant is fixedfunction the deployment type is ostree
• obtain it from /etc/os-release using the BUILD_ID and VARIANT_ID keys

Unaffected images versions

• all versions up to XXX (replace XXX with the build id of the most recent Apertis images where this bug cannot be reproduced)
• not relevant (new feature enabled on v2023dev releases)

Testcase

https://qa.apertis.org/testcases/v2023dev3/wifi-wpa3-sae-accesspoint-setup.html https://qa.apertis.org/testcases/v2023dev3/wifi-wpa2-psk-accesspoint-setup.html

Steps to reproduce

Execute the above testcase On the SDK side when prompted to enter the password enter an incorrect password Try to reconnect and give the correct password

Expected result

Connection should succeed the second time when the correct password is given

Actual result

Connection fails when the correct password is given the second time.

Reproducibility

How often the issue is hit when repeating the test and changing nothing (same device, same image, etc.)?

Put the ✅ in the most appropriate entry:

1. always

Impact of bug

High

Attachments

wifi-wpa3-sae.txt wpa2-psk.txt

Root cause

When the connection attempt was with “wrong passphrase”, if wpa_supplicant reports some other error message other than “INCORRECT KEY”, then connman consider it as generic failure and will not take new wifi key anymore until some internal timeout completed or ignition cycle When Wpa_supplicant reports “INCORRECT KEY” error message? Only when EAPOL handshake fails reported otherwise it reports other error types e.g. reports “de-authentication reason 3” and “Authentication timeout”. The WPA_supplicant reports is dependent with phone’s implementation of their authentication sequence, and actual timing of runtime events, hence the device dependent and dynamic behaviour The connman should recover from the error case with next attempt with new wifi key (robustness improvement):

Outcomes

TBD

Management data

This section is for management only, it should be the last one in the description.

/cc @andrunko @em @sagar @sudarshan @wlozano @adalessandro

Phabricator link: https://phabricator.apertis.org/T9217