search

seemoo-lab / nexmon_csi

Channel State Information Extraction on Various Broadcom Wi-Fi Chips
314 stars 122 forks source link

Is there any requirement for the frame to get its CSI extracted? #194

Open DennisHerell opened 3 years ago

DennisHerell commented 3 years ago

I've successfully used nexmon CSI in RPi 3B+ to collect csi from my AP beacon and QoS data signal in 5GHz Bandwidth. However, I've noticed that when I collect from the beacon frame of my AP in 2.4 GHz bandwidth, no CSI are being extracted. (QoS data frame still get its CSI extracted. It's not a case of the frame not being sent or detected, as using tcpdump I can see the frame are received by my RPi. In the screenshot, the left show the pcap of the beacon frame in 2.4 GHz, so I can confirm the frame is being received. However, unlike the pcap on the right, there's no UDP packet containing CSI received. Screenshot from 2021-03-08 14-32-31

On the other hand, QoS data from both band can be received just fine. This really confused me, and become a problem as I'm trying to implement a transmitter and the CSI from my transmitter frame does not get its csi extracted. Does anyone know why this happen? Thanks!

zeroby0 commented 3 years ago

The -b 0x88 in the makecsiparams example is responsible. It allows only packets whose first byte is 0x88 to get extracted. Remove it, and you'll get all frames.

Change it to one of the numbers here to extract only that type of frame: https://en.wikipedia.org/wiki/802.11_Frame_Types

DennisHerell commented 3 years ago

Thanks for the response, I am aware of the filter using the -b, in those capture I filter for beacon frame by setting -b0x80 so that should not be the case though. I also don't think there's a problem with my device on 2.4 GHz specifically, as I managed to extract CSI from QoS data in both bands.

yujianyuanhaha commented 3 years ago

@DennisHerell I recall I meet the same issue ... I just go with those type I can get.

haochenku commented 3 years ago

HI @zeroby0 do you know what is the -b parameter if I only want to capture the Ping packet? I tried both 0x88, 0x80, 0x08. seems not working

zeroby0 commented 3 years ago

Hey @haochenku

Yeah I have no luck with that either: https://github.com/seemoo-lab/nexmon_csi/issues/119

The -b parameter only filters the first byte of the wlan packet, which indicates the Frame Type of the packet. Inside this WLAN packet is IP packet, and inside the IP packet, can be either TCP, or UDP, or ICMP. Ping is a type of ICMP packet.

So if you have to identify a ping packet, you have to look deep inside the packet's structure. I don't know the exact position inside the packet, and I'm not sure if it's constant or can change across packets.

Last summer, I changed the firmware to send me the first ~40 bytes or so of the packet instead of CSI so that I can inspect the packets and see where the ICMP header is. I also used the Nexmon Monitor mode. But instead of getting regular packets, I was able to only sniff WLAN Beacon packets, and nothing else. You can get the code in this branch.

There's another complication to all of this. For sake of example, let's say the ICMP header is at position 30 inside the packet. I need to access it and compare it with the value expected for ping packets. But some packets are smaller that 30 bytes, so if I write packet[30] in my code, it causes an out of bounds error. I don't know how the firmware handles errors, but it doesn't send that packet from the chip to the kernel and to tcpdump, so I cannot inspect packets shorter than 30 bytes.

It's still an incredibly interesting problem nonetheless. I'm currently looking for PhD programs, so I don't have the time to work on it right now (side note, if you know about a good PhD program, I'd love to hear! :), but I want to make another attempt at it in the future.