WiFi scan while connected

[Remi.G]

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.

[Simonr]

Thanks again Remi

We see that CCA is continuously busy on this channel for some reason and suspect some non-Wi-Fi interference on that channel is causing this. So the next step would be to capture raw data on this channel for further analyze. Can you try using the attached radio test hex file and get captures of what's going on here with an nRF7002 DK:

Config 1: Repeat the below commands 5 times and get terminal logs for analysis. Note that 16k samples will be logged to the terminal every run, indicating the channel state:
wifi_radio_test init 165
wifi_radio_test rx_lna_gain 0
wifi_radio_test rx_bb_gain 25
wifi_radio_test rx_capture_length 16000
wifi_radio_test rx_cap 0

Config 2: Repeat the below commands 5times and get terminal logs for analysis. note that 16k samples will be logged to the terminal for every run, indicating the channel state.

wifi_radio_test init 165
wifi_radio_test rx_lna_gain 0
wifi_radio_test rx_bb_gain 10
wifi_radio_test rx_capture_length 16000
wifi_radio_test rx_cap 0

Best regards,

Simon

radio_test.hex

[Remi.G]

Here are the logs. All runs for a configuration in the same file, separated by boot message. I reset the DK between each run.

radio_test_chan_165_bb_gain_25.txt : the first experiment

radio_test_chan_165_bb_gain_25.txt

radio_test_chan_165_bb_gain_10.txt: the second experiment

radio_test_chan_165_bb_gain_10.txt

For comparison, I also did a single run with gains 25 and 10 on channel 161, which does not have the scanning issue:

radio_test_chan_161.txt

On channel 165 with 25 gain, I see a lot of 800 and 7FC in the data, which looks like saturation? Gain 10 seems to be in range.

Channel 161 is much lower magnitude.

So there may be a jammer at 165? I turned off all the wireless I could find, used some metal shielding, and even tried connecting the DK to a different laptop in case there was PC noise coupling through USB. Same results. That implies the noise may be coming from the nRF7002-DK itself? It also happens on our own board (I didn't run radio test, but scan fails), maybe due to similar RF design? I don't have a 5GHZ spectrum analyzer, unfortunately. Or is it possible that there's a tuning issue when the firmware accesses channel 165?

I could try buying another nRF7002-DK to see if it behaves differently. Is there a newer version of HW after v1.0.2? The product page doesn't specify.

Independent of whatever is jamming channel 165, this is still a scanning firmware issue, right? A jammed channel shouldn't be able to hang the device.