Are the first 2 bytes 64d0 in the example wrong?

[zhgao2020]

Hi,

Thanks for your great contribution to bridging the mobile phones and wireless networks. We are undergraduate students in a lab from Fudan University in China, who has been following your paper Shadow Wi-Fi: Teaching Smartphones to Transmit Raw Signals and to Extract Channel State Information to Implement Practical Covert Channels over Wi-Fi on mobisys 2018 since it was published. We found some difficulty when redoing your open-sourced codes and would be highly appreciated if you can help us.

In your example, we found it a little confusing that echo "64d0010080000000ffffffffffff001122334455" | xxd -r -p | base64

We checked the codes in this repository and Nexmon (the prerequisite of CSI extractor), specifically in file channels.c, ioctl.c, etc. Our conclusion is that the first byte (the first two digits of Hex) describes the frequency (whether 2G or 5G) and bandwidth, while the second byte describes which channel to use. Therefore, it should be d064 instead of 64d0 to represents channel 100 and 80MHz bandwidth in 5 GHz.

We double checked it in another repository _mobisys2018_nexmon_software_definedradio, where the chenspec = 1001. In mode -s426, 1001 is calculated by a define CH20MHZ_CHSPEC(channel): the first byte 10 means 0x1000 (bandwidth = 20MHz) or 0x0000 (2 GHz) and the second byte 01 means the channel is 1. In mode -s427, 1001 is directly set in the myframe.sh by matlab program generate_frame.m.

In addition, we cannot understand why there's -xxx after the command tcpdump instead of -xx, whose means we cannot find on the Internet.

Thanks a lot!

[DanielAW]

You are right, the first 2 bytes channel specification needs to be flipped, I just fixed the README.