seemoo-lab / nexmon_csi

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

CSI traffic stops on Nexus 6P #45

Open mzakharo opened 4 years ago

mzakharo commented 4 years ago

I am using Nexus 6P, and capturing CSI from a router (mac filter, but no byte filter). Everything works fine, until I try to capture a burst of traffic to another connected client, then, CSI capture stops, and I have to wlan0 down/up to get it running again.

Behavior looks suspiciously similar to #41, however, I cannot confirm, since I do not see any debug files in /sys/kernel/debug/ieee8011/phy0 , nor can I apply a A-MSDU filter from RPI , since 4358 patch addresses are different.

It would be nice to try and see if fix that worked for RPI could work here. Can someone shed some light on how to find the equivalent of 0x1B6B02 and 0x1B6B1E addresses in 4358 firmware?

Alternatively, what steps can I take to try and debug this?

jlinktu commented 4 years ago

Addresses for the 6P would be 0x1A6D22 and 0x1A6D2C.

jlinktu commented 4 years ago

For Nexus 5 addresses are 0x19B1A6 and 0x19B1B0. Instead of using a Bpatch you could also just nop the instruction as there's a fitting Branch after it anyways.

__attribute__((at(0x19B1A6, "", CHIP_VER_BCM4339, FW_VER_6_37_32_RC23_34_43_r639704)))
__attribute__((at(0x1B6B02, "", CHIP_VER_BCM43455c0, FW_VER_7_45_189)))
__attribute__((at(0x1A6D22, "", CHIP_VER_BCM4358, FW_VER_7_112_300_14)))
__attribute__((naked))
void
nop_wlc_monitor_amsdu(void)
{
    asm(
        "nop\n"
        "nop\n"
    );
}
mzakharo commented 4 years ago

Thank you very much for the help. These patches do not seem to be helping on Nexus 6P though -> behavior unchanged, still freezes occasionally on external wifi traffic.

Is there the equivalent of forensics debugfs on Android 8.1 Nexus 6P, to see if the firmware has any messages/traces to report?

mzakharo commented 4 years ago

Looking at the firmware log, and adding some print statements inside pkt_buf_get_skb , it seems the party stops around the same time I see a request for 1920 bytes from a function @ 0x1b803b (according to link register). @jlinktu : do you happen to know what part of the microcode is executing around this address?