search

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
61 stars 26 forks source link

Cant find expected Mac Addresses in csi data #59

Closed Akshay94 closed 12 months ago

Akshay94 commented 12 months ago

I installed this repo on 2 of my raspberry pi 4Bs and generated a pcap file using default configs mentioned in the usage section here. But when i analyze it, I am not able to see any of the Mac addresses of my devices, (phone, laptop, etc) in the udp data. I realize that there is a possibility that the mac addresses may belong to my neighbors. But i scanned for a minute or so and none of the entries were my phone or computer or my friend's computer. See screenshot below

Screenshot 2023-11-17 at 2 21 47 PM

A Little Clarification

I realize that in the latest nexmon update the mac address begins from the 3rd byte in the udp payload unlike the older version in which it began from the 5th byte. But by looking at different packets, the 4th byte is always 80 or 08 which is strange and makes it seem it must not bw part of the mac address. Additionally after looking around a little bit more, I found that one of the mac is the xfinitywifi that is open. Seen in the screenshot below. The mac address marked in the below screenshot is that of xfinitywifi as i verified it in wifi commection settings of my laptop also (see next screenshot also). It verifies that the mac address, still indeed, begins from the 5th byte and not the 3rd byte. But why is that so? And mainly i want to know why am i unable to see my devices' laptops of phones macs? Is it a 2.4G/5G thing? Lastly I note that some of the mac addresses that i collected are have common sections, which is also weird. (fa:aa:a0:ac:e2:f0, ec:aa:a0:ac:e2:f0, 02:aa:a0:ac:e2:f0, fe:aa:a0:ac:e2:f0 - all show up) (variants of the xfinity wifi also show up - ea:79:0a:f0:c5:c1, ee:79:0a:f0:c5:c1, f2:79:0a:f0:c5:c1, f6:79:0a:f0:c5:c1, f8:79:0a:f0:c5:c1)

Screenshot 2023-11-17 at 4 46 20 PM Screenshot 2023-11-17 at 4 49 35 PM
Akshay94 commented 12 months ago

@zeroby0

zeroby0 commented 12 months ago

They'll only show up if they are operating in the wireless channel your nexmon_csi is listening to :)

The common parts in the mac addresses of multiple devices is the OUI prefix. Devices from the same manufactures typically have the same OUI prefix

Akshay94 commented 12 months ago

that solves the problem, I was, indeed, looking at the wrong channel numbers. thanks @zeroby0

Akshay94 commented 12 months ago

@zeroby0 what are the units of these CSI values. Are these power values? or intensity? or raw amplitude? of the emwave..

zeroby0 commented 12 months ago

CSI is a ratio, so I don't think it has any units or dimensions. If you're using https://github.com/nexmonster/nexcsi, running unpack will return the CSI as a complex number. You can get amplitude and phase of CSI from that.

Akshay94 commented 12 months ago

Ok, so the amplitude and phase is that of the em waves? @zeroby0

zeroby0 commented 12 months ago

No, of the CSI.

Refer to "Mathematical Description" in https://en.wikipedia.org/wiki/Channel_state_information and the free your csi paper. CSI is the channel matrix.

Akshay94 commented 12 months ago

I see. Thanks I have another query if you've got the time to answer. I have two raspi 4Bs setup with nexmon. I want to collect CSI data in close quarters, like sender and reciever half a meter apart. Since the wlan0 of Raspi is blocked for CSI capturing, I cant route packets to it as it is not assigned an IP even. So that would mean that the CSI-capturing-Raspi is not the receiver? And that the receiver has to be some other device necessarily? And what would you suggest as the transmitter? And overall, what would you suggest my experimental setup be for my situation described above. which devices should i use for tx and rx and CSI collection (if it has to be apart from rx)? (I have 2 Raspis, a laptop, an iPhone and a router) We can take this conversation elsewhere, if you feel so. @zeroby0