Wext_send_mgnt - sending layer2 packets MAC header Sequence Control / Sequence Number not coming through

Hi,

Using wext_send_mgnt to send layer2 packets for RTLS (before authenticating and associating with an AP). Sending standard packets starting 4 address MAC header (802.11 frame types - Wikipedia) + content.
Packets are being sent out, APs are seeing them, but seems the Sequence Number which is coming from Sequence Control field is not coming through - always get Sequence Number of 0 or 1.
I am beginning to suspect wext_send_mgnt is somehow altering the Sequence Control field. Is this at all possible?
When I print the raw bytes passed to this function, bytes are correct:

0803 0000 014096000003 C4CB6B26FF21 000000000000 803D 000000000000 000C0B 0C01 020779000200000000

“803D” is the Sequence Control (in little endian):
0x3D80

I see the correct data being forwarded down the line, but wrong Sequence Control, and that in turn makes Sequence Number which derives from Sequence Control to be wrong…

int wext_send_mgnt(const char *ifname, char *buf, __u16 buf_len, __u16 flags);
this function has “flags” parameter. We are passing 0 for lack of any documentation. I am wondering what the intentions and possible values are for “flags”, maybe I need to pass value other than 0?..

I am working on true “in the air” packet capture - that will confirm the actual bytes, but i have not been able to do so yet.
Has anyone dealt with sending layer2 packets with this SDK? Anything that I could check to troubleshoot this?

Thanks,
Ivan S.

Hi @airista_islavov , may check with you which dev board are you using? Thank you.

Using EVK-NORA_W306 dev/prototype board from uBlox.
Also ran this on our own tag using RTL8720 chip. same behavior.
We were told by uBlox support that this SQN is overwritten at SDK low level.
We are looking to modify the logic on the receiving/server side end and to not use this SQN as it seems it is impossible to control at firmware level.

If you can provide any way to set this it will help us.

Thanks,
Ivan

Hi @airista_islavov , from your others post, I noticed that you are using ameba-rtos-d sdk. Regarding ameba-rtos-d sdk, it is best to get help from official GitHub. Thank you.