search

seemoo-lab / nexmon_csi

Channel State Information Extraction on Various Broadcom Wi-Fi Chips
302 stars 121 forks source link

Nexus 6P unable to get data packet only #232

Open haochenku opened 3 years ago

haochenku commented 3 years ago

Dear all, I am trying to get a stable streaming of 80MHz CSI measured. One way we found is to use Ping apps. However, we tried all combinations of -b 0x08, -b 0x80, -b 0x88 . But we still could not detect the CSI. However, we verified that we can detect beacon only and if we remove -b parameter, we can detect the 80MHz CSI. But in this case, there are so many useless 20MHz CSI detected. So I am wondering if there is a clean way to detect the 80MHz CSI stream.

mzakharo commented 3 years ago

beacons are transmitted at 20Mhz, hence your 80Mhz capture has lots of 'useless' data in it.

Unfortunately, nexmon does not capture CSI on all WiFi traffic. Many packets/packet types, even though they are visible by the same nexmon device in sniffer/monitoring mode, would nevertheless not output any corresponding CSI.

0x88 is capturing 80Mhz QoS packets, and to trigger those with ping, I found some routers would behave different from others. You can send a ping with different payload lengths, and higher ping payload size generally leads to higher chance CSI will be captured by nexmon. This payload size that triggers nexmon seems to be dependent on router manufacturer/config. In some extreme cases, I have seen some routers send 10+ 0x88 packets for 1 ping packet, probably due to some strange QoS configuration. On another extreme, some routers would never send 0x88 packet along with ping, no matter what payload size you pick.

If you have full control of the TX (router/AP), then with some trial and error, you can come up with a working setup at 80Mhz. If dont have control over router/AP, unfortunately, I found only beacons are a reliable source of capture, limited to 20MHz.

haochenku commented 3 years ago

@mzakharo Thank you so much. I have increased the payload to 1200 on Asus 86U, that does not work. I will try more to figure it out. Is there any plan to improve this in the future? BTW, so far it seems the WiFi cannot do normal communication after the hacking. Is this correct understanding? If not, what will be the command to connect to AP for communication? Could we do it dynamically switching between monitoring mode and client mode?

haochenku commented 3 years ago

Hi @mzakharo another question I have is that are we sure in multi-core case, the core 0 CSI will always come first and then followed by the core 1 CSI decoded from the same frame?

mzakharo commented 3 years ago

There is a way to get CSI and normal/client mode working at the same time/on the same firmware, but it involves rewriting the D11 patches quite significantly to not use as many 'spare' D11 registers. This limits general purpose usability of the result. Monitor mode (which allows capturing non-associated traffic) itself is compatible with normal/client operation.

mzakharo commented 3 years ago

With enough packet upload errors you can technically get a mismatch. This should be pretty rare. Does SEQ field not help answer this question?

On Wed., Jul. 14, 2021, 17:08 haochenku, @.***> wrote:

Hi @mzakharo https://github.com/mzakharo another question I have is that are we sure in multi-core case, the core 0 CSI will always come first and then followed by the core 1 CSI decoded from the same frame?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/seemoo-lab/nexmon_csi/issues/232#issuecomment-880211337, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEKUO4GPQ2Q4LTKPLQRV6TTXX4F7ANCNFSM5AL77WIQ .

haochenku commented 3 years ago

Not really, the SEQ field is not accurate at all. And sometimes, the seq field will be all zeros for a consecutive time. Is it a bug? I am testing on Nexus 6p. This seq file is the seq for each UDP packet or it is for each MAC/beacon frame?

mzakharo commented 3 years ago

SEQ is from the 802.11 frame, and not all frame types support it. Never had any issues myself, SEQ works well when capturing only beacons.

haochenku commented 3 years ago

@mzakharo Thank you. for beacon SEQ also working well. Then if I remove -b, which captures both beacon and data, it is not working well.

mzakharo commented 3 years ago

When you say "not working well" you actually mean not working how you would like. Seq actually works exactly according to 802.11 spec. You can always add your own seq field into the unused bytes of the CSI header.

On Fri., Jul. 16, 2021, 18:49 haochenku, @.***> wrote:

@mzakharo https://github.com/mzakharo Thank you. for beacon SEQ also working well. Then if I remove -b, which captures both beacon and data, it is not working well.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/seemoo-lab/nexmon_csi/issues/232#issuecomment-881757883, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEKUOZKALTQWPI3Y76S62DTYCZODANCNFSM5AL77WIQ .

haochenku commented 3 years ago

@mzakharo I see. You are right!! Thanks for the reminder. I will keep you posted.