blocked by key handshake fail - Iphone 16 - IOS

Zyxel_Melen

Hi @venom

Thanks for your update! We will wait for your next update and keep clarifing this issue.

venom

—download by Zyxel Melen—

Hello @Zyxel_Melen
I have the same problem after resetting the network settings and with the Zyxel APs in WPA3.
Test 2 doesn't seem necessary because I only use an SSID on Zyxel AP
For test 3, I downloaded the debug, see attached
The screenshot shows the times with errors.

Thanks

Zyxel_Melen

Hi @venom

Thanks for the file. We are investigating on it and will update you once I have further information.

venom

Hello @Zyxel_Melen
For several weeks now, I have been testing the connection on my phone to a new SSID that I created on my Zyxel WiFi access points.
The result was satisfactory at first, but over time the problem has returned, and I regularly experience disconnections/reconnections on my WiFi.
How can we continue the debug?

Thanks

Zyxel_Melen

Hi @venom

Thanks for the diagnostic file. Below is what we found and the suggestion:

The 2.4Ghz association is successful, only 5GHz encounter the connectivity issue when station roaming. (Refer to the picture you attached, hostapd events can also see the same behavior)

• 2.4 GHz connection is normal: The STA first connects on 2.4 GHz and completes the 4-Way Handshake.
• Intra-roam to 5 GHz: The STA then attempts to roam from 2.4 GHz to 5 GHz (same ESS, different BSSID), where rapid disconnects occur.

Key Observations:

• On the 5 GHz BSSID, the STA’s (Re)AssocReq includes a PMKID to use PMKSA caching, but no matching PMKSA entry exists on this BSSID:
  • WPA: No PMKSA cache entry found for SAE
  • WPA/RSN information element rejected (res 11)
• Because there is no usable cache and the STA does not fall back to SAE authentication (no SAE commit/confirm observed), the AP correctly terminates the attempt and clears state (Disassoc/Deauth):
  • Delete station …
  • … IEEE 802.11: disassociated
• This repeats: the STA keeps presenting PMKID on 5 GHz, the AP rejects per spec, resulting in a “PMKID presented → no PMKSA → reject” loop. (See the attached image for provement)

Conclusion:

• AP behavior is correct: When a Assoc carries a PMKID but the target BSSID has no corresponding PMKSA, the AP must reject and clear state to avoid inconsistent security context.
• STA behavior is abnormal: When switching to a different BSSID under WPA3-SAE, the STA should fall back to SAE authentication to derive a fresh PMK/PMKSA for that BSSID. In this case, the STA keeps trying PMKSA instead of running SAE, leading to disconnects.

Suggestions:

1. Have the client “Forget this network” and reconnect to 5GHz (forces SAE rather than reusing an old PMKID).
2. Update the client’s Wi-Fi driver/firmware and OS version.
3. Short-term validation options: Enable only one band to avoid BSSID switching during diagnosis. In other words, create two SSID, SSID2.4G and SSID5G, and each SSID only uses the specific band that matches the SSID's name.

Overall, this case is caused by the client not falling back to SAE on the 5 GHz BSSID under WPA3-SAE. The AP’s handling is compliant and correct.

Please feel free to let us know if there is any further assistance we can help with.