WiFi scan while connected

Does the NCS stack + nRF7002 support scanning while connected? I would expect it could, to support handoff, but getting errors.

Using nRF7002-DK and NCS 2.8.0.

Compile the wifi/shell example for nrf7002dk/nrf5340/cpuapp, no other changes.

*** Booting nRF Connect SDK v2.8.0-a2386bfc8401 ***
*** Using Zephyr OS v3.7.99-0bc3393fb112 ***
Starting nrf7002dk with CPU frequency: 128 MHz
[00:00:00.532,226] <inf> wifi_supplicant: wpa_supplicant initialized


uart:~$ wifi connect -s Hizzulon <my AP credentials>
Connection requested
Connected
[00:00:19.725,433] <inf> wpa_supp: MBO: Disable MBO/OCE due to misbehaving AP not having enabled PMF
[00:00:19.726,226] <inf> wpa_supp: wlan0: SME: Trying to authenticate with fc:34:97:af:71:54 (SSID='Hizzulon' freq=5220 MHz)
[00:00:20.086,120] <inf> wpa_supp: wlan0: Trying to associate with fc:34:97:af:71:54 (SSID='Hizzulon' freq=5220 MHz)
[00:00:20.102,874] <inf> wpa_supp: wlan0: Associated with fc:34:97:af:71:54
[00:00:20.103,027] <inf> wpa_supp: MBO: Disable MBO/OCE due to misbehaving AP not having enabled PMF
[00:00:20.103,118] <inf> wpa_supp: wlan0: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
[00:00:20.122,253] <inf> wpa_supp: wlan0: WPA: Key negotiation completed with fc:34:97:af:71:54 [PTK=CCMP GTK=CCMP]
[00:00:20.122,467] <inf> wpa_supp: wlan0: CTRL-EVENT-CONNECTED - Connection to fc:34:97:af:71:54 completed [id=0 id_str=]
[00:00:20.137,420] <inf> net_dhcpv4: Received: 192.168.1.203


uart:~$ wifi status
Status: successful
==================
State: COMPLETED
Interface Mode: STATION
Link Mode: WIFI 6 (802.11ax/HE)
SSID: Hizzulon
BSSID: FC:34:97:AF:71:54
Band: 5GHz
Channel: 44
Security: WPA2-PSK
MFP: Optional
RSSI: -34
Beacon Interval: 100
DTIM: 1
TWT: Supported
Current PHY rate : 26000


uart:~$ wifi scan
Scan requested

[wait ~30 seconds]


Scan request failed (-116)

[wait another ~30 seconds]


[00:01:33.363,311] <err> wifi_nrf: nrf_wifi_fmac_chg_vif_state: RPU is unresponsive for 10 sec
[00:01:33.363,342] <err> wifi_nrf: nrf_wifi_if_stop_zep: nrf_wifi_fmac_chg_vif_state failed
[00:01:33.364,013] <inf> wifi_supplicant: Network interface 1 (0x200013c0) down
[00:01:33.375,396] <inf> wpa_supp: wlan0: CTRL-EVENT-DSCP-POLICY clear_all
[00:01:33.375,854] <inf> wpa_supp: wlan0: CTRL-EVENT-DSCP-POLICY clear_all
[00:01:35.533,050] <inf> wifi_supplicant: Network interface 1 (0x200013c0) up
uart:~$ wifi status
Status: successful
==================
State: DISCONNECTED
uart:~$ 

So the scan fails, but later there's another error that looks like the low-level nRF7002 driver failing and recovering (CONFIG_NRF_WIFI_RPU_RECOVERY is enabled by default).

If scan while connected isn't a supported feature, I would expect it to error immediately, not get into a state where it drops the connection?

A probably related issue: if I issue "wifi connect" with invalid credentials, wifi status is "SCANNING" forever (certainly much longer than the 30 second scan timeout), and later connect requests fail with:

uart:~$ wifi connect <credentials>
Connection requested
[00:01:58.298,828] <inf> wpa_supp: wlan0: CTRL-EVENT-DSCP-POLICY clear_all
[00:01:58.302,124] <inf> wpa_supp: wlan0: Reject scan trigger since one is already pending
[00:01:58.302,246] <wrn> wpa_supp: wlan0: Failed to initiate AP scan
[00:01:58.304,992] <inf> wpa_supp: wlan0: Reject scan trigger since one is already pending
[00:01:58.305,114] <wrn> wpa_supp: wlan0: Failed to initiate AP scan

I need to explicitly do "wifi disconnect" before it will stop scanning and allow another connection. Normally, issuing a connect command while already connected disconnects automatically then initiates the new connection.

  • Thank you for the thorough report Remi, the logs and information has been forwarded to the Wi-Fi team and we're looking into this now. Thank you for the thorough testing on your end! I'll let you know when I hear something, or at the very least by end of week with a status update.

    Best regards,

    Simon

  • Hi

    Unfortunately we don't have a Pixel or Asus AP as the ones you have here, but if you can share a picture of the AP you're using, we will buy the same model to get one in our test lab. We found two models called "Asus ZenWiFi AX" and would like to confirm the exact model you're using first.

    Best regards,

    Simon

  • I'm fairly certain it's the XT8 model, but I am on vacation this week so I can't check the serial number. The XT8 and XT9 look identical, it would be one of those two. I'll confirm when I am back at the end of this week.

    Or, you could buy a Pixel8 in the meantime.

  • Hi again Remi

    Enjoy your vacation then!

    When you get back, please confirm which AP model you're using. Unfortunately the log you've provided doesn't have enough debugging to narrow down what exactly is wrong, but here is a .hex file you can use with some more debugging options enabled you can run on a DK and test when you get back: 5270.zephyr.hex

    For reference, we also tested using a Pixel 7 on our end, but were not able to reproduce with that.

    Best regards,

    Simon

  • Confirmed the AP version: Asus ZenWifi AX XT8 (AX6600).

    https://www.asus.com/networking-iot-servers/whole-home-mesh-wifi-system/zenwifi-wifi-systems/asus-zenwifi-ax-xt8/

    I will try the image on Monday.

1 2 3 4 5 »