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

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

Parents Reply
  • 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

Children
  • 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?

  • 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

  • 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

  • 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

  • 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?

Related