frame start byte (0x80 or 0x88) matter when collecting CSI on NEXU5

[yujianyuanhaha]

greetings,

Recently I notice get the code after run ./makecsiparams matter, especially set the frame-starting-byte ,for example, as None, 0x88, 0x80.

In my NEXSUS:

1. set with None, collected CSI package ~600 per second, 80M fully used (see waveform attached below, and the waterfall)

2. set with 0x80, collected CSI package ~40 per second, only 20M used (see waveform attached below, and the waterfall)

3. set with 0x88, collected CSI package failed, the tcpdump with stuck at 0 package collected

In another post Why use frames starting with 0x88 @jlinktu mention 0x88 stand for QoS and 0x80 for beacon frames. For WiFi sensing the environment, does they make different regard the CSI waveform ? (it looks to me it matters) Is there anywhere I can reference to so I can try many other frame starting byte?

Additionally, as I carefully check data format description, I found statement "... followed by the six byte source mac address as well as the two byte sequence number of the Wi-Fi frame that triggered the collection of the CSI contained in this packet. ... " does not match what I observe. i.e. I check the two byte right after Mac address, from a 0x80 filtered .pcap file. But I see the frame-header-byte (in red color) change over package and is not a constant.

Let me know if I get it wrong or any other any idea. @jlinktu @zeroby0

Best.

Jet

[zeroby0]

The payload starts with four magic bytes 0x11111111, followed by the six byte source mac address as well as the two byte sequence number of the Wi-Fi frame that triggered the collection of the CSI contained in this packet. The next two bytes contain core and spatial stream number where the lowest three bits indicate the core and the next three bits the spatial stream number, e.g. 0x0019 (0b00011001) means core 0 and spatial stream 3

• 11 11 11 11 is magic number
• a8 5e 45 88 1a d4 is mac id
• c0 76 is frame number
• 18 00 is core and spatial stream
• 2a e0 is the chanspec

None of these is the Frame header. Frames are one more layer below Ethernet, and don't show up in Wireshark. The first byte of that frame is what we are using in filtering. This wiki page shows what that byte represents: https://en.wikipedia.org/wiki/802.11_Frame_Types

46 shows how to get the first byte (Frame Control): https://github.com/seemoo-lab/nexmon_csi/pull/46/commits/7e3f9f720e1eb12ef11afd855515981d5a3b715b

Frames starting with 0x80 are beacon frames, and will always be 20 MHz. They announce the presence of the router, and should be discovered by 20MHz, 40MHz, and 80MHz capable devices, so they are at the 'lowest common denominator' at 20 MHz.

Frames starting with 0x88 are QoS frames. I don't know if they use different modulation than Data frames. If they do, then the CSI will change. I can collect CSI even when using 0x88, but not nearly as much as using None. It probably depends on how your router is configured.

[yujianyuanhaha]

hi @zeroby0

thanks for your kind rely. And just to be clear, I focus on the "two byte sequence number of the Wi-Fi frame that triggered the collection of the CSI ", not exact frame header.

What confuse me is frame number c0 76 is NOT constant even if I apply the 0x80.

Best

Jet

[zeroby0]

It's the sequence number of the frame. Like: frame 1 frame 2 frame 3 . . frame 1000

That's what c076 is. It's the 49270th frame emitted by your router. Next frame will be c077 or 49271.

0x80 is the first byte of the MAC frame. Inside the MAC frame, an ethernet packet is embedded. Inside Ethernet, IP packet is embedded. Inside IP is a UDP packet. Wireshark only let's you see Ethernet, IP, and UDP/TCP. MAC Frames can't be seen in wireshark.

Look at this link: https://www.geeksforgeeks.org/ieee-802-11-mac-frame/

0x80 is the first byte in the Frame Control field. Ethernet is embedeed in the Data field.

To be fair, the wording in layout description is confusing. Every WiFi frame going in that channel triggers CSI collection. If the frame doesn't have given Mac ID or doesn't start with given byte, then the CSI collection is skipped.

That 2 byte SC field in the picture is called Sequence Control. That's what is copied over into the two bytes you're seeing, not FC. 0x80 is FC, c076 is SC.

[yujianyuanhaha]

@zeroby0 wow, thank for your kindly reply. I check my 0x80 .pcap file and it does match what you said, the two byte is FC and increase over packages index.

However, in .pcap file collected on ASUS, such two byte does not increase over packages index, it changes each 16 packages. @jlinktu Does it make sense?

Given the fact, @jlinktu could you clear the layout description a little bit, thanks.

Thank again.

Best.

[zeroby0]

@jlinktu Can we change it like this? I think it would be easier to parse. The last row would need editing for the other CSI format.

Bytes	Type	Name	Description
4	uint32	Magic Bytes	0x11111111
6	uint8[6]	Source Mac	Source Mac ID of the WiFi Frame
2	uint16	Sequence Number	Sequence number of the WiFi Frame
2	uint16	Core and Spatial Stream	Lowest 3 bytes indicate the Core, and the next three bits indicate the Spatial Stream number.
2	uint16	Chanspec	Chanspec used during extraction. See nexutil -k.
2	uint16	Chip Version	Chip Version
variable	int16[]	CSI Data	Each CSI sample is 4 bytes with interleaved Int16 Real and Int16 Imaginary. There are bandwidth * 3.2 OFDM subcarriers per channel, and a CSI sample for every subcarrier is present.

[yujianyuanhaha]

@zeroby0 that look great, thanks.

[yjxb1]

有效负载从四个幻字节0x11111111开始，然后是六个字节的源 mac 地址以及触发此数据包中包含的 CSI 集合的 Wi-Fi 帧的 2 字节序列号。接下来的两个字节包含核心和空间流编号，其中最低的三位表示核心，接下来的三位表示空间流编号，例如0x0019 （0b00011001） 表示核心 0 和空间流 3

• 11 11 11 11是幻数
• a8 5e 45 88 1a d4是 Mac ID
• c0 76是帧号
• 18 00是核心流和空间流
• 2a e0是 chanspec

这些都不是 Frame 标头。帧比以太网低一层，不会显示在 Wireshark 中。该帧的第一个字节是我们在过滤中使用的字节。此 wiki 页面显示了该字节所代表的内容：https://en.wikipedia.org/wiki/802.11_Frame_Types

46 显示如何获取第一个字节（帧控制）：7e3f9f7

以 0x80 开头的帧是信标帧，并且始终为 20 MHz。它们宣布路由器的存在，并且应该被支持 20MHz、40MHz 和 80MHz 的设备发现，因此它们在 20 MHz 时处于“最低公分母”。

以 0x88 开头的帧是 QoS 帧。我不知道他们是否使用与数据帧不同的调制。如果他们这样做，那么 CSI 将发生变化。即使使用 0x88，我也可以收集 CSI，但远不如使用 None 那么多。这可能取决于路由器的配置方式。

The payload starts with four magic bytes 0x11111111, followed by the six byte source mac address as well as the two byte sequence number of the Wi-Fi frame that triggered the collection of the CSI contained in this packet. The next two bytes contain core and spatial stream number where the lowest three bits indicate the core and the next three bits the spatial stream number, e.g. 0x0019 (0b00011001) means core 0 and spatial stream 3

• 11 11 11 11 is magic number
• a8 5e 45 88 1a d4 is mac id
• c0 76 is frame number
• 18 00 is core and spatial stream
• 2a e0 is the chanspec

None of these is the Frame header. Frames are one more layer below Ethernet, and don't show up in Wireshark. The first byte of that frame is what we are using in filtering. This wiki page shows what that byte represents: https://en.wikipedia.org/wiki/802.11_Frame_Types

46 shows how to get the first byte (Frame Control): 7e3f9f7

Frames starting with 0x80 are beacon frames, and will always be 20 MHz. They announce the presence of the router, and should be discovered by 20MHz, 40MHz, and 80MHz capable devices, so they are at the 'lowest common denominator' at 20 MHz.

Frames starting with 0x88 are QoS frames. I don't know if they use different modulation than Data frames. If they do, then the CSI will change. I can collect CSI even when using 0x88, but not nearly as much as using None. It probably depends on how your router is configured.

Hello, I have some questions about 0x88 and 0x80. Why does 0x88 capture QoS frames? I checked the 802.11 protocol framework. The binary of QoS frames is 0010 1000. Shouldn't it be 0x28 when converted to hexadecimal? I don’t quite understand why 0x88 corresponds to QoS frames. Did I understand it wrong?

[jlinktu]

I answered you in issue #351