Invalid FTE when using 802.11r FT-over-the-air on NWA50AX

Hi all,

we have been trying to get 802.11r with FT-over-the-air to work. On our Linksys WRT1900ACS, we didn't have any issues in OpenWRT 22.03.2, but on ZyXel NWA50AX, we keep getting errors. When doing roam <bssid> on wpa_cli, we get the following error:

> roam b8:ec:a3:e3:c0:eb

<3>SME: Trying to authenticate with b8:ec:a3:e3:c0:eb (SSID='xxx' freq=2437 MHz)
<3>Trying to associate with b8:ec:a3:e3:c0:eb (SSID='xxx' freq=2437 MHz)
<3>CTRL-EVENT-ASSOC-REJECT bssid=b8:ec:a3:e3:c0:eb status_code=55
<3>SME: Deauth request to the driver failed

Status code 55 means "Invalid FTE". We have confirmed that the station is receiving reassociation response frames with this status code.

We tried the following things:

  • Different stations
  • Different access points of the same model
  • Changing the channel of the AP
  • Upgrading wpad-basic-wolfssl
  • Using hostapd instead of wpad-basic-wolfssl

We also tried decreasing to 0, but there there still little debug output so we didn't get any related information from there.

Has anyone ever encountered this issue before or any idea where the error might come from?

My guess would be that the devices are using different SoCs. The Linksys uses Marvell, while the ZyXel uses Mediatek. The drivers aren’t playing well with each other it seems. BUT, I am no expert on these matters (regarding SoCs and drivers) and could very well be horribly wrong. Hopefully someone more knowledgeable could chime in. I only use devices with Qualcomm and have never experienced an issue setting up FT with them, which is why I assume what I do seeing that deauth request to the driver failed.

Thanks for the fast reply! Just to clarify: We are not letting APs of different manufacturers talk to each other. Instead, we set up two identical APs and enable FT-OTA. We are roaming with regular consumer hardware, e.g. an Intel Corporation Wi-Fi 6 AX201.

Weirdly, FT-OTA does not fail consistently. Instead, it seems to fail when executing roam <bssid> for the first time, connecting back to the original AP. Afterwards, FT-OTA succeeds.

That is strange. Ultimately, it is up to the device when it wants to roam. For iOS devices, -70db seems to raise the flag on whether they want to hop or stay. There are other packages, like DAWN, where you can setup kick parameters on the AP’s, but that’s a whole other animal to introduce.

We are initiating our roams using wpa_supplicant with the roam command. We are testing using this command (which worked on other APs), so we don't think our device is an issue in this case.

The issue could be related to this post: