nexmonster / nexmon_csi

Channel State Information for Raspberry Pi. Use the pi-5.10.92 branch.
https://github.com/nexmonster/nexmon_csi/tree/pi-5.10.92
60 stars 26 forks source link

Setting up Rx and Tx #30

Open t5670116 opened 2 years ago

t5670116 commented 2 years ago

hi @zeroby0 , I am interested in obtaining a CSI due to my research. I currently have the firmware installed on an ASUSU RT-AC86U and was able to run /jffs/tcpdump -i eth6 dst port 5500 and get the pcap file. But I am not sure where this pcap file is the CSI of the communication from where to where.

I have two ASUSU RT-AC86U and I would like to communicate between them to get the CSI.

Please help me.

t5670116 commented 2 years ago

hi @zeroby0 ,

I would like to know how to specify the acquiring terminal using tcpdump.

My thinking is that I can specify the transmitter to get the CSI by specifying the Mac address.

Thank you in advance.

zeroby0 commented 2 years ago

Heyo!

But I am not sure where this pcap file is the CSI of the communication from where to where.

The firmware captures all packets in the air it sees. If you're capturing on channel 36, all WiFi packets on channel 36 are eligible for capturing, regardless of where they're going or where they're from.

This is normal behavior in normal WiFi too. Your WiFi card has to listen to all the packets in it's channel, there's no other way of knowing if a packet is meant for it. The card then drops packets it has no interest in - like packets that are meant for other devices.

You can use the MacID, and First Byte filters on makecsiparams if you're only interested in some kinds of packets. If the captured packet doesn't match the filters, it's CSI is dumped instead of being sent to the kernel and then to tcpdump.

In practice, though, the CSI recorder misses observing some packets in the air. Partly because CSI recording is stopped when CSI of a packet is being copied from the WiFi chip to the kernel, so some packets are lost.

I have two ASUSU RT-AC86U and I would like to communicate between them to get the CSI.

You can't use a device running Nexmon_CSI to communicate. You can only passively listen to packets in the air. I heard you can do packet injection with Nexmon firmware (Nexmon and Nexmon_CSI are different), but you can't do transmission and CSI capturing on one device.

My thinking is that I can specify the transmitter to get the CSI by specifying the Mac address.

That's correct!

Don't use the -b 0x88 flag btw. It limits you to only listening to broadcast packets - which are frequently only 20 MHz and are not beamformed.


I strongly recommend skimming through the issues and pull requests on this repo and the main repo. And then read the Nexmon_CSI paper. That's how I learned everything I know about Nexmon_CSI 😆

t5670116 commented 2 years ago

Thank you for your very clear explanation. Thanks to you I was able to acquire the CSI data.

I want to get the CSI of a communication using two 4×4 ASUSU RT-AC86U. So I used mcp -c 36/80 -C 1×f -N 1×f -m mac to run CSI.

But when the value of core is 2 or 3, the value of CSI is zero. Please let me know if there is a solution or if my method is incorrect.

Also, is it correct that core represents the receiving router's antenna and N represents the transmitting router's antenna? スクリーンショット 2022-06-28 104023

t5670116 commented 2 years ago

Don't use the -b 0x88 flag btw. It limits you to only listening to broadcast packets - which are frequently only 20 MHz and are not beamformed.

I want to send a ping from my PC to the ASUSU RT-AC86 router and intercept it by the RT-AC86 router with firmware installed.

In that case, can I use -b 0x88 to intercept only the ping communication?

zeroby0 commented 2 years ago

In that case, can I use -b 0x88 to intercept only the ping communication?

There's more packet types in the 0x88 class, so it's not only ping packets.

Also, for some reason, my devices seem to send ping packets as data instead of control packets.

But when the value of core is 2 or 3, the value of CSI is zero.

I don't know why CSI of core 2 and 3 is always 0. Maybe rt-ac86u only has a dual core processor.

Also, is it correct that core represents the receiving router's antenna and N represents the transmitting router's antenna?

I think it's the actual processor cores. And N is the antennas. Of the receiving device.

t5670116 commented 2 years ago

Thank you very much.

I am aware from the 99 comments and 175 comments here that each core (Rx antenna) and each "spatial stream" (Tx antenna) and if you select a particular core, it means you are using the antenna associated with that core.

It appears that the rt-ac86u only has a dual core processor as you mentioned. In that case how would you use the 4 antennas on the receiving side of the rt-ac86u?

I want to output the CSI value of 4(Rx antennas) x 4(Tx antennas) x subcarriers

I am counting on you. Best regards.

スクリーンショット 2022-06-29 162655

t5670116 commented 2 years ago

@zeroby0 Hello.

I have discovered my mistake. The CSI value is 0 when the value of the spatial stream is 2 or 3, not the core.

/usr/sbin/wl -i eth6 monitor 1 If I use tcpdum to get CSI without this command, I can get 4x4 values.

Do you have any idea why the CSI value is 0 when the value of the spatial stream (N) is 2 or 3 and how to solve this?

/usr/sbin/wl -i eth6 monitor 1 What is this command doing? Also, what does the value obtained using tcpdum without this command represent?