nRF7002 STA+AP with Different Channels

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.

[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=

  • Hi

    There's a lot of theory behind this question, and after discussing this with a colleague here in tech support it seems like we need to involve the development team to get a concrete reply here.

    From what we're able to glean, a network interface can't operate as both SAP and STA, and thus this would be a no altogether, based on the following line:

    • A network interface can operate in either SAP mode or Station mode, but not in both modes simultaneously.

    Please explain how you mean you're able to use it both as an access point and station on your end exactly so that I can go to the experts with a more direct question. EIther way, the channel switching you request is not supported in the Zephyr SDK and I don't see how it would be possible either.

    Best regards,

    Simon

  • To be clear, this is the current state of our usage for nrf7002:

    • We are creating a Linux driver, which does not use zephyr at all. The majority of the documentation online is centered around zephyr which has very little use to us.
    • We do use a slightly outdated version of nrfxlib at the moment, specifically commit 2fe3e82 made on march 14 2024, with modifications to make it work on our version of linux and our use case
    • Your above quote states that an interface (singular) cannot operate as both an AP and STA, but we are using multiple virtual interfaces on a single nrf7002. The chip and firmware supports this, and if configured correctly does work. We've been able to route traffic from the AP to the STA interface and have tested with video and calling.

    Currently our issues with this setup is as follows:

    • Configuring STA to connect to a wifi network, and configuring the AP to start on the same channel works. As long as both are using the same channel we haven't seen any issues.
    • If STA is configured to connect to a wifi network on channel 1, and AP is configured on channel 6, or channel 36 (for 5GHz), then starting the AP returns a -16 status, and the AP does not start at all.

    My specific question is: Is it at all possible to get both STA and AP running on two different channels?

    There is no concrete documentation on whether it is possible or not, and if it is feasible I need to know how. I've combed pretty much all the available documentation for the chip and haven't found anything that can answer my question. I'm looking for any technical advice or documentation to answer this.

  • Hi

    A statement from one of our devs:

    Since the nRF70 series devices have a single radio, multi-channel operation is not possible, so the behavior you describe is expected.

    Best regards,

    Simon

Related