[WiFi][Windows Driver][WiFiCx] WiFiCx sends DOT11_RESET instead of WDI_TASK_CONNECT after successful scan

Question

We are developing a Windows Wi-Fi driver for our WLAN chipset using WiFiCx.

Our driver is able to:

• Successfully initialize the firmware.
• Receive scan requests from WiFiCx.
• Perform scanning and return the scan results.
• Notify WiFiCx of scan completion by sending NDIS_STATUS_WDI_INDICATION_SCAN_COMPLETE.
• Display the discovered networks correctly in the Windows Wi-Fi UI.

The issue occurs when we attempt to connect to an open network.

Instead of issuing the expected WDI_TASK_CONNECT request, WiFiCx consistently sends a DOT11_RESET command to the driver.

From the driver logs, the scan operation completes successfully, the scan results are reported correctly, and the NDIS_STATUS_WDI_INDICATION_SCAN_COMPLETE indication is sent before the connection attempt. However, immediately after the user initiates a connection, WiFiCx sends DOT11_RESET instead of WDI_TASK_CONNECT.

We would like to understand:

1. Under what conditions does WiFiCx issue a DOT11_RESET instead of a WDI_TASK_CONNECT request?
2. Are there any mandatory indications, task completions, or driver state transitions that must occur after scan completion before WiFiCx will issue a connect request?
3. Is there any common reason why WiFiCx would reset the adapter even though the scan task appears to have completed successfully?

Any guidance on the expected WiFiCx state machine or debugging steps would be greatly appreciated.

Answer 1

Hi Aswin Sankesh G S

Based on the documented WiFiCx flow, DOT11_RESET is not normally issued before every connection attempt. If WiFiCx sends OID_WDI_TASK_DOT11_RESET instead of OID_WDI_TASK_CONNECT, it typically indicates that the port is not in a valid state for connection or that WiFiCx detected an inconsistency and is resetting the adapter.

I would verify:

1. The scan task is fully completed with the correct completion status and transaction ID.
2. All required BSS entry indications are valid and contain the information needed for a connectable network.
3. The port returns to the expected idle/ready state after SCAN_COMPLETE and is not left in a scanning or error state.
4. ETW/WPP traces for WLAN/WiFiCx immediately before the reset to identify any validation or state-machine failures.

Since the SSIDs appear in the Windows Wi-Fi UI, scan reporting is at least partially working, but malformed/incomplete BSS data or an unexpected port state can still cause WiFiCx to issue a reset instead of a connect request.

---

If this answer was helpful, please click "Accept Answer" and vote for it. If you have additional questions regarding this answer, please click "Comment".

Note: Please follow the steps outlined in our documentation to enable email notifications if you wish to receive notifications regarding this discussion.