nRF7002 Callbacks returning wrong interface

[esmart-engineering]

I'm using an STA+AP configuration as well as monitor mode with a custom nrf7002 driver, which currently is working in a basic sense. I have however ran into issues regarding the nrfxlib callbacks that I've built workarounds for but I'm not sure are being addressed yet. They mostly revolve around the callbacks returning the default interface, even though the commands that triggered them were on a different interface. So far I've ran into the issue on `rx_frm_callback_fn`, `chnl_get_callbk_fn`, and `tx_pwr_get_callbk_fn`. 

For `rx_frm_callback_fn`, I'll have monitor mode configured on a second interface, but when packets come in from the callback, they always return the default interface, even though the default interface is in a down state.

For both `chnl_get_callback_fn` and `tx_pwr_get_callbk_fn`, I'm using the get channel and get tx power api functions for the second interface, but the callback will always return the default interface.

While I've gotten around the issue on these callbacks, there may be other ones that have a similar issue.

[Elfving]

Hello,

I'm using an STA+AP configuration as well as monitor mode with a custom nrf7002 driver, which currently is working in a basic sense.

Hehe supporting people creating custom drivers isn't easy. Any particular reason why you didn't want to use the default ones?

Regards,

Elfving

[esmart-engineering]

It's a linux driver and the one Nordic provides has limited functionality. For these particular issues I understand that I most likely won't get a fix. Its mostly bringing attention to the issue in case someone else is running into the problem and for Nordic to at least have the issue on their radar.

[Simonr]

Thank you, this is a good initiative on your end. Let me know if there's anything in specific you need from tech support on this except forwarding this to the development team.

Best regards,

Simon

[esmart-engineering]

I'm doing more work and I'm having some trouble deciphering error codes. I'm trying to get STA+AP to work on different channels. Currently if they are on the same channel (or at least channel 1) sta connects and I'm able to use AP. But if try to change the channels, I start running into error codes.

The specific configuration I'm doing is AP is started on the second interface (open configuration if that matters) using channel 36, then connecting STA on the first interface where the router is set to channel 1, using WPA2. It looks like it finds the router, but fails in authentication. I'm getting following commands and statuses from umac_event_ctrl_process:

Command	status
2	-22
7	-67
7	-67
7	-67
7	-67
7	-67
7	-67
37	-67

Since this is on linux, it tries 2 or 3 times, but the command and statuses are the same for each time. I'm using Network Manager, or `nmcli` and the configuration I'm using works if AP isn't up. 

Any guidance on what could cause these error codes can probably help me figure out why it doesn't seem to work on different channels.

[Simonr]

I will have to take a closer look at this case tomorrow. I'll give some more detailed feedback then.Thank you for your patience!

Best regards,

Simon

[SpeedCrash100]

Hello, I am attempting to set up a simultaneous STA+AP mode but with a newer kernel (6.1).

When operating in AP mode, can you tell me if you managed to ping devices connected to the AP network after establishing a connection with STA virtual interface? For an open and unprotected hotspot, I can successfully pass authorization so on my client indicates as connected but then I experience no data flow; even assigning static IP addresses does not resolve this issue. With a protected network, I cannot proceed beyond the 4-way handshake due this issue.

Were you have same issue or I am doing something wrong with my implementation?