[WiFiCx][WiFi][Windows-Driver] Is there a way to disable host-based roaming and let the Wi-Fi firmware roam on its own?
Hi all,
We are developing a Windows Wi-Fi driver for a FullMAC chipset and would like to understand what Windows supports for firmware-controlled roaming.
Background (Linux behavior we want to match):
On Linux, the FullMAC driver advertises that the firmware can roam (WIPHY_FLAG_SUPPORTS_FW_ROAM, reported to wpa_supplicant as NL80211_ATTR_ROAM_SUPPORT). wpa_supplicant then sets WPA_DRIVER_FLAGS_BSS_SELECTION and skips its own roaming and background scanning. The firmware decides when to roam and which AP to pick, using its own RSSI trigger and delta. After the roam, the driver reports it to the stack (cfg80211_roamed). The host is involved only for security steps that need it, such as SAE authentication and the 4-way handshake after the roam.
What we found in the Windows docs:
- OID_WDI_TASK_ROAM is issued by the host (Microsoft component). The host supplies a preferred BSS list, and the adapter may reprioritize it or complete without roaming.
- NDIS_STATUS_WDI_INDICATION_ROAMING_NEEDED lets the firmware ask the host to start a roam, and the host may or may not act on it.
- The ConnectBSSSelectionOverride station capability appears to let the adapter choose its own BSS instead of using only the host-provided list.
- The WiFiCx sample driver (Windows-driver-samples/network/wlan/wificx) does not implement WDI_TASK_ROAM.
We could not find any documented capability, TLV, or setting that tells Windows to leave roaming to the firmware.
Questions:
- Is there any supported option in WiFiCx to disable host-initiated roaming and let the firmware roam autonomously?
- If the firmware roams on its own, what indications should it send so Windows handles it correctly (for example disassociation, then association result, then link state change)? Will Windows treat this as a disconnect and reconnect, or can it be handled as a roam within the same connection?
- How should the host be involved afterwards for SAE and the 4-way handshake (or FT) when the firmware has already roamed?
- If this is not supported, what is the recommended way to get firmware-driven roaming behavior? Would ConnectBSSSelectionOverride together with controlling when ROAMING_NEEDED is sent be the intended approach?
Windows version: Windows 11 IoT Enterprise 2022
Thanks in advance for any guidance or pointers to documentation.