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!) 

[Håkon Alseth]

Hi,

 

NCS 2.9.0 (and I can't/won't update to 3.2.x as the nrfx4 update breaks all my code) 

Ideally, to include all fixes up-to-date, it would be preferable to isolate this issue and test it on v3.2.x, as there has been several fixes and improvements wrt. raw mode since the release of v2.9.0.

Would it be possible that you perform these two scenarios on v3.2.1 isolated (ie. without any nrfx drivers etc), to see if the issues still persists?

 

Kind regards,

Håkon

[BrianW]

Håkon Alseth said:

several fixes and improvements wrt. raw mode since the release of v2.9.0

Do any of these fixes related to the problems I have?

Can you give me commit ids for these changes - I could try cherry picking them back to 2.9.0?

Like I say, the changes to 3.2.x are such that we will need to review and change ALL nrfx related code - see this ticket:

 Migration from NCS 2.9.0 to NCS 3.2.1 is hard, not well documented and will break all nrfx code. 

so even if the problem has been fixed on 3.2.1, its not going to help with the customer I have right now...

[Håkon Alseth]

Hi,

 

As initially mentioned, I understand that there are issues wrt. porting; but if you cut-down the sample and isolate the issue, this should be able to run without direct issues towards the problematic components that you list.

It would help greatly to test this on a newer version to see if the changes between your current version, and the latest, improves your scenario. Ie. to see if we are dealing with a known issue, or a completely new one.

Cherry-picking all the fixes has dependencies, so listing each commit will not be applied cleanly. 

 

Kind regards,

Håkon

[BrianW]

Ok. So I tried with the raw_tx_packet sample from NCS 3.2.1 nrf/samples/wifi.

Updated the prj.conf to work with my custom board and added:

CONFIG_RAW_TX_PKT_SAMPLE_INJECTION_ENABLE=y

CONFIG_RAW_TX_PKT_SAMPLE_CONNECTION_MODE=n

CONFIG_RAW_TX_PKT_SAMPLE_INTER_FRAME_DELAY_MS=2000

Test 1 : tx raw packet with fc=0x0803 ie To-DS=1, From-DS=1

In main.c set the packet contents to be:

static struct beacon test_beacon_frame = {

    .frame_control = htons(0x0803),         // data frame, DS AP-AP. Note byte swapped

    .duration = 0x0000,

    .da = {0x01, 0x40, 0x96, 0x00, 0x00, 0x03},

    // Transmitter Address: filled in with our MAC

    .sa = {0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF},

    .bssid = {0x00, 0x00, 0x00, 0x00, 0x00, 0x00},

    .seq_ctrl = 0x0010,

    // Null SSID, no other IEs

    .payload = {

        0x00 ,                                  // Version = 1

        0x0c , 0x01 , 0x0c , 0x01 ,             // tx power=12, channel=1, reg class=12, nburst = 1

        0x02, 0x07, 0x21 , 0x02 , 0x58 , 0x00 , 0x00 , 0x00 , 0x00 ,        // Battery

        0x05, 0x01 , 0x00 ,                     // Emergency, panic button

        0x04 , 0x20 ,                           // Vendor specific, 32 bytes, vendor OUI is 00188e

        0x00, 0x18 , 0x8e , 0x00 , 0x02 , 0x00 , 0x02 , 0x00 , 0x08 , 0x00 , 0x06 , 0x00 , 0x01 , 0x25 , 0x00 , 0x07 ,

        0x00, 0x01 , 0x03 , 0x00 , 0x08 , 0x00 , 0x04 , 0x00 , 0x00 , 0x01 , 0x2c , 0x00 , 0x03 , 0x00 , 0x01 , 0x00

    }

Result: NOK

 - still silently drops this packet with the frame control To-DS and From-DS bits set to 1

Setting frame_control to 0x0800 works, packet seen on air.

Test 2 : setting channel just before sending:

Updated main.c to set the wifi channel from an array of {1,6,11} each time it attempts to tx.

Result : OK

- accepts to tx a packet when channel change done just before the sendto()

So the channel change issue seems to be fixed in 3.2.1, but still doesn't accept the frame control.

a) how can I get the raw packet fixes for channel change in 2.9.0?

b) why won't the raw packet tx accept To-DS/From-DS bits set?

[Håkon Alseth]

Hi,

 

Thank you so much for your patience, and for testing and verifying.

I have added your test sequence to the internal bug tracker, and I will get back to you once R&D has looked into this. That can take a few business days.

 

Kind regards,

Håkon

[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