nRF7002 STA+AP with Different Channels

[esmart-engineering]

I have a linux driver that uses nRF7002 am able to have both STA+AP. The issue I'm running into is that when I have STA up, AP MUST be the same channel, and vice versa. I have 2 questions.

1. Can the nrf7002 be setup to use different frequency channels

2. If it can, what am I missing to make this work. I've attached a debug log that starts with "Start ap" and ends with it failing and reverting back to STA mode.

Fullscreen AP_DifferentChannel.txt Download

[13280.179247] nrf_wifi_cfg80211_start_ap: Entry
[13280.179509] hal_rpu_cmd_process_queue: writing command
[13280.180015] umac_cmd_cfg: Command 5 sent to RPU stat=0
[13280.180195] hal_rpu_cmd_process_queue: writing command
[13280.181434] hal_rpu_cmd_process_queue: writing command
[13280.182551] umac_event_ctrl_process: Event 292 received from UMAC
[13280.182578] nrf_wifi_cmd_callbk_fn: cmd=5 status=0
[13280.182596] umac_event_ctrl_process: Event 292 processed
[13280.182754] hal_rpu_cmd_process_queue: writing command
[13280.183519] hal_rpu_cmd_process_queue: writing command
[13280.184273] hal_rpu_cmd_process_queue: writing command
[13280.185014] hal_rpu_cmd_process_queue: writing command
[13280.185747] hal_rpu_cmd_process_queue: writing command
[13280.186811] hal_rpu_cmd_process_queue: writing command
[13280.187773] umac_cmd_cfg: Command 13 sent to RPU stat=0
[13280.189350] umac_event_ctrl_process: Event 292 received from UMAC
[13280.189384] nrf_wifi_cmd_callbk_fn: cmd=13 status=-16
[13280.189401] umac_event_ctrl_process: Event 292 processed
[13280.295084] nrf_wifi_cfg80211_del_sta: deleting null reason=2 subtype=12
[13280.295333] hal_rpu_cmd_process_queue: writing command
[13280.295835] umac_cmd_cfg: Command 20 sent to RPU stat=0
[13280.296138] nrf_wifi_cfg80211_mgmt_tx: Sending frame to RPU: intf=1 cookie=5 (0x5) wait_time=0 no_ack=0 flags=0 params=0
[13280.296550] hal_rpu_cmd_process_queue: writing command
[13280.297815] hal_rpu_cmd_process_queue: writing command
[13280.297920] umac_event_ctrl_process: Event 292 received from UMAC
[13280.297959] nrf_wifi_cmd_callbk_fn: cmd=20 status=0
[13280.297977] umac_event_ctrl_process: Event 292 processed
[13280.298346] umac_cmd_cfg: Command 30 sent to RPU stat=0
[13280.299530] umac_event_ctrl_process: Event 273 received from UMAC
[13280.299570] umac_event_ctrl_process: Event 273 processed
[13280.402682] nrf_wifi_cfg80211_mgmt_tx: cookie 5 response not received (100ms)
[13280.403188] nrf_wifi_cfg80211_del_key: Entry
[13280.403411] hal_rpu_cmd_process_queue: writing command
[13280.404164] hal_rpu_cmd_process_queue: writing command
[13280.404678] umac_cmd_cfg: Command 7 sent to RPU stat=0
[13280.404977] nrf_wifi_cfg80211_del_key: Entry
[13280.405147] hal_rpu_cmd_process_queue: writing command
[13280.406442] hal_rpu_cmd_process_queue: writing command
[13280.407070] umac_event_ctrl_process: Event 292 received from UMAC
[13280.407129] nrf_wifi_cmd_callbk_fn: cmd=7 status=-2
[13280.407162] umac_event_ctrl_process: Event 292 processed
[13280.407366] umac_cmd_cfg: Command 7 sent to RPU stat=0
[13280.407815] nrf_wifi_cfg80211_del_key: Entry
[13280.408242] hal_rpu_cmd_process_queue: writing command
[13280.409519] umac_event_ctrl_process: Event 292 received from UMAC
[13280.409566] nrf_wifi_cmd_callbk_fn: cmd=7 status=-2
[13280.409580] hal_rpu_cmd_process_queue: writing command
[13280.409583] umac_event_ctrl_process: Event 292 processed
[13280.410096] umac_cmd_cfg: Command 7 sent to RPU stat=0
[13280.410519] nrf_wifi_cfg80211_del_key: Entry
[13280.410976] hal_rpu_cmd_process_queue: writing command
[13280.412233] umac_event_ctrl_process: Event 292 received from UMAC
[13280.412285] nrf_wifi_cmd_callbk_fn: cmd=7 status=-2
[13280.412303] umac_event_ctrl_process: Event 292 processed
[13280.412344] hal_rpu_cmd_process_queue: writing command
[13280.412854] umac_cmd_cfg: Command 7 sent to RPU stat=0
[13280.413620] nrf_wifi_cfg80211_mgmt_tx: Sending frame to RPU: intf=1 cookie=6 (0x6) wait_time=0 no_ack=0 flags=0 params=0
[13280.413918] hal_rpu_cmd_process_queue: writing command
[13280.414841] umac_event_ctrl_process: Event 292 received from UMAC
[13280.414878] nrf_wifi_cmd_callbk_fn: cmd=7 status=-2
[13280.414896] umac_event_ctrl_process: Event 292 processed
[13280.415810] hal_rpu_cmd_process_queue: writing command
[13280.416282] umac_cmd_cfg: Command 30 sent to RPU stat=0
[13280.417490] umac_event_ctrl_process: Event 273 received from UMAC
[13280.417541] umac_event_ctrl_process: Event 273 processed
[13280.522652] nrf_wifi_cfg80211_mgmt_tx: cookie 6 response not received (100ms)
[13280.523751] hal_rpu_cmd_process_queue: writing command
[13280.524429] umac_cmd_cfg: Command 37 sent to RPU stat=0
[13280.524651] hal_rpu_cmd_process_queue: writing command
[13280.525793] umac_cmd_cfg: Command 29 sent to RPU stat=0
[13280.525817] nrf_wifi_cfg80211_chg_vif: Entry
[13280.525833] nrf_wifi_cfg80211_chg_vif: Changing intf 1 wdev=2 to 2, state=0
[13280.525857] nrf_wifi_fmac_chg_vif: sending command
[13280.526165] hal_rpu_cmd_process_queue: writing command
[13280.526272] umac_event_ctrl_process: Event 292 received from UMAC
[13280.526310] nrf_wifi_cmd_callbk_fn: cmd=37 status=0
[13280.526328] umac_event_ctrl_process: Event 292 processed
[13280.526738] umac_cmd_cfg: Command 16 sent to RPU stat=0
[13280.526763] nrf_wifi_cfg80211_chg_vif: Waiting for response from RPU (change VIF) intf=

[Simonr]

Hi

This log doesn't give a lot of information in terms of error codes or where it actually is failing from what I can see, as it only reports what it is doing, and not the callbacks from any functions failing. Have you been able to figure out what function/process that is actually failing on your end, and what channels are you trying to use exactly, one 5GHz and one 2.4GHz? I can't think of why it shouldn't be able to use different channels for STA and AP as long as you switch between the two when needed.

My first guess would be that the STA is taking up the radio on its allocated channel so you're not able to disable the radio to switch channel and allow the AP to run, but we would need some error codes from the logger to be able to tell anything here.

Best regards,

Simon

[SpeedCrash100]

There are info in these logs: [13280.189384] nrf_wifi_cmd_callbk_fn: cmd=13 status=-16. I've tried to do the about a same with nrf7002. (vif 0 - AP 2.4 GHz 1 channel, vif 1 - STA 5 GHz 36 channel). And got the same: umac_event_ctrl_process: Command 13 -> status -16.
Command 13 is START_AP that's means I cannot even see AP. -16 is probably EBUSY?. This is starting point where it goes wrong.

[esmart-engineering]

Sorry, I had to add a callback for commands to fix a diferent issue, but there's usually a "umac_event_ctrl_process: %d cmd -> status %d" log line from event.c in nrfxlib, which is now replaced with "nrf_wifi_cmd_callbk_fn: cmd=%d status=%d" callback log line. The error is -16 when starting ap while a second interface (STA) is already up and on a different channel. Once the start_ap fails, everything past that begins to fail for ap functionality. If I turn off STA, I can run the same start ap command and it will work, so its just the STA interface causing problems.

So if I'm understanding right, I need to disable any current interfaces before starting AP, and then turn them on again after. If I do it that way then AP should be able to control the radio, correct?

I wasn't sure how radio sharing worked on the chip, but it sounds like its done manually through NRF_WIFI_UMAC_CMD_SET_CHANNEL commands, correct?

I'll try this method unless its wrong, but I'm working on different issue so it won't be testing it for another day.

[Simonr]

Hi

Just for reference, the AP + STA simultaneously is not yet supported as per the SoftAP documentation page here: https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/protocols/wifi/sap_mode/sap.html#supported_functionality_and_limitations, so we don't have any specific suggestions on how to implement this yet.

Best regards,

Simon

[esmart-engineering]

I've tried using both a combination of 2.4 and 5 GHz channels, and channels in the same band (channel 1 and 6 is my common goto). I've looked into what I could do to manually channel switch, but it seems I would probably have to bring down the vif I'm not using, switch channels, and then bring on the new interface, and do that continuously for multichannel to work.

I was wondering if there's any support within the firmware for this? I know STA+AP isn't supported in zephyr's SDK, but it is supported by the firmware if you use multiple virtual interfaces, as long as they are on the same channel, at least that's what I've confirmed. I just need to know if firmware is capable of rapid channel switching in a way that's usable. I can attempt to implement rapid channel switching but it seems like if it's done on the host side it will greatly impact performance and it would just make more sense for the firmware to handle this.