nrf70 raw packet send fails silently with FC=0x0803 or if changing channel just prior to send?

[BrianW]

Using nrf5340 with nrf70 on a custom board, using NCS 2.9.0 (and I can't/won't update to 3.2.x as the nrfx4 update breaks all my code) 

I want to use the wifi interface to send raw wifi network packets (both in associated and non-associated modes).

I have the nrf70 blob configured to use the bin that is good for both STA and RAW modes:

(in sysbuild.conf SB_CONFIG_WIFI_NRF70_SYSTEM_WITH_RAW_MODES=y and in prj.conf CONFIG_NRF70_RAW_DATA_TX=y)

I have avoided the memory issue I reported here:

 nrf70 raw packet sending causes network memory loss from sysheap 

by opening and closing the socket every time I want to send my raw packet (instead of keeping it open all the time)

Now when I send my raw packet it works unless:

1/ I just changed the channel (when not in associated mode) : packet silently dropped

I want to send the packet on channels 1, 4  and 11 for example. The channels are in an array and I have a loop, which changes the channel to the next one, then does the sendto().

channel set request:

            _ctx.ccx_channel_index = (_ctx.ccx_channel_index+1) % nChans;

            // Set channel to tx on

            struct wifi_channel_info channel_info = {0};

            channel_info.oper = WIFI_MGMT_SET;

            channel_info.if_index = net_if_get_by_iface(iface);

            channel_info.channel = _ccx_channels[_ctx.ccx_channel_index];

            if ((ret = net_mgmt(NET_REQUEST_WIFI_CHANNEL, iface, &channel_info, sizeof(struct wifi_channel_info)))!=0) {

                log_cpwrn("netwifi:ccx_init:channel set to %d nok (%d, %d), continuing", _ccx_channels[_ctx.ccx_channel_index], ret, errno);

            }

- the channel change request returns OK every time (ret=0)

- the subsequent sendto of the packet says it was sent ok

But no packets are ever is seen on the air:

Except the very first one ie when it was already on the desired channel). And indeed, if I change the channel array so it is in fact always the same channel (ie instead of {1, 4, 11} I have {4, 4, 4} then it works fine (I see 3 packets all on channel 4)

Any ideas why changing the channel just before sending breaks the send?

PS> If I change the code to switch the channel AFTER the send, and then wait till the next timer pop to send on it (so the channel change happens with a certain delay (3s in my test) before the sendto()), then this works!

2/ my packet wants to have its frame control field equal to 0x0803 (byte swapped on the air), ie data packet, with DS of 3 : packet silently dropped

In the raw frame wifi header (from the raw tx sample) I set:

.frame_control = htons(0x0803),

With this fc, my packet is NEVER sent (there is no error return from the sendto(), but packet is never on the air)

If I use fc=0x4000 (probe request) its fine. fc=0x8000 (beacon frame) its fine. fc=0x0800 (data frame, DS status=00) then its fine too.

Why does the wifi driver silently drop this packet?

Thanks!

FYI: I'm using wireshark with a Netgear A6210 usb wifi stick on Windows 11 to do the radio packet capture (only does 1 channel at a time, but it works in Monitor mode!) 

[BrianW]

hi

while they are looking at it, it would also be very useful to remove the restriction that raw packets can only be sent on the same channel as the associated AP...

For wifi RTLS, the device is often both associated with an AP (for comms) and also needs to 'blink" with raw packets on multiple channels (for RTLS location).

thanks

Brian

[Håkon Alseth]

Hi Brian,

 

Thank you for your patience in this matter. The team has acknowledged the issue, but I unfortunately am not able to give you a detailed timeline for when this will be addressed.

If this is a feature that is critical for your project, please send me a direct message, and I will share with you the contact details of the regional sales manager for your area.

 

Kind regards,

Håkon

[BrianW]

Quick update :

1/ I have got the send with fc=0x0803 to work (problem actually related to the wifi sniffer driver I was using on Windows).

2/ Issue with changing channel just before the send still is present (for all fc values); my workaround of changing the channel after the send (to be ready for the next slot) is ok for now but prevents me sending a 'blink group' ie multiple packets, each one immediately after the other, on different channels

3/ it would still be very desirable to be able to send the raw packets on any channel, even when associated with an AP.

any news from the dev team?

[Håkon Alseth]

Hi Brian,

 

Thank you for updating 

BrianW said:

1/ I have got the send with fc=0x0803 to work (problem actually related to the wifi sniffer driver I was using on Windows).

R&D just finished testing, and confirmed that the payload was sent on-air, as you also verified.

BrianW said:

2/ Issue with changing channel just before the send still is present (for all fc values); my workaround of changing the channel after the send (to be ready for the next slot) is ok for now but prevents me sending a 'blink group' ie multiple packets, each one immediately after the other, on different channels

3/ it would still be very desirable to be able to send the raw packets on any channel, even when associated with an AP.

Since you were able to work around this issue, I did report it; but it was not given high priority to look at as the main issue was blocking you.

I will create feature requests for these, but I would strongly recommend that you pursue these two topics with your regional sales manager, especially if this is a pressing matter for your application.

 

Kind regards,

Håkon