• State Not Answered
  • Replies 8 replies
  • Subscribers 70 subscribers
  • Views 362 views
  • Users 0 members are here
Attachments (1) Download All
Nordic Case Info
  • Case ID: 333087
Options

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=

Parents
  • 0

    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

  • 0 in reply to Simonr

    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.

Reply
  • 0 in reply to Simonr

    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.

Children
No Data
Related