bluekitchen / raccoon

Raccoon BLE Sniffer
89 stars 30 forks source link

No output when using Makerdiary Pitaya Go #7

Open CieNTi opened 3 years ago

CieNTi commented 3 years ago

Hi!

I followed your guides with no problem at all until I try to actually sniff packets, moment in which I get nothing.

My config at pyclient/config.py

# Raccoon BLE Sniffer Config

# Output format
# pick one of the following logging formats by uncommenting the format line

# PKLG format minimics HCI data to/from a Bluetooth Controller. It can be opened with Wireshark and Apple's PacketLogger
# format  = 'pklg'

# PCAP format uses Bluetooth BLE Trace format defined by libbt/Ubertooth for use with CrackLE. It can be opened with Wireshark
# format = 'crackle'

# PCAP format uses Bluetooth BLE Trace format defined by Nordic. It can be opened with Wireshark.
format = 'pcap'

# Available Sniffer devices
# List of detected serial ports, please uncomment your Raccoon BLE Sniffer devices
sniffers = [
#   { 'port':'/dev/ttyS0', 'baud':1000000, 'rtscts':1 },  # ttyS0 - PNP0501}
   { 'port':'/dev/ttyACM0', 'baud':1000000, 'rtscts':1 },  # raccoon nrf52840 dongle - USB VID:PID=1915:520F SER=000000000000 LOCATION=2-4.2:1.0}

]

Commands log

If I run raccoon just after plugging the board, I get this:

> 1 $ ./pyclient/raccoon.py 
[+] Config: output trace.pcap (pcap), min rssi -80 dBm
[!] Failed to connect to sniffer at port /dev/ttyACM0 with 1000000 baud
[!] No working sniffer found. Please connect sniffer and/or update config.py

And as soon as I wait just a little, I can connect with no more errors ... but also with no more information:

> 1 $ ./pyclient/raccoon.py 
[+] Config: output trace.pcap (pcap), min rssi -80 dBm

After seeing the commit flow, I will reference both @mringwal and @xiongyihui, as I think they may be the right two to be asked hehehe

Do you have some idea on how to continue? Tell me whatever you need to debug it :)

Thanks a lot in advance

xiongyihui commented 3 years ago

Is it the right serial port? You can run lsusb and dmesg to check if the device is available.

CieNTi commented 3 years ago

I think yes (from the computer point of view at least, I don't know if internally the Pitaya Go is routing a different uart). But here you have both outputs:

dmesg for unplug + plug

[752427.518291] usb 1-1.2: USB disconnect, device number 11
[752428.768723] usb 1-1.2: new full-speed USB device number 12 using ehci-pci
[752428.880033] usb 1-1.2: New USB device found, idVendor=1915, idProduct=520f, bcdDevice= 1.00
[752428.880036] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[752428.880038] usb 1-1.2: Product: raccoon nrf52840 dongle
[752428.880039] usb 1-1.2: Manufacturer: Nordic Semiconductor
[752428.880040] usb 1-1.2: SerialNumber: 000000000000
[752428.880741] cdc_acm 1-1.2:1.0: ttyACM0: USB ACM device

And lsusb output

> 1 $ lsusb
Bus 003 Device 003: ID 5543:0003 UC-Logic Technology Corp. Tablet WP4030U
Bus 003 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 004: ID 058f:6362 Alcor Micro Corp. Flash Card Reader/Writer
Bus 001 Device 012: ID 1915:520f Nordic Semiconductor ASA 
Bus 001 Device 003: ID 046d:c52b Logitech, Inc. Unifying Receiver
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 002: ID 05e3:0616 Genesys Logic, Inc. hub
Bus 004 Device 003: ID 0480:a200 Toshiba America Inc 
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 002 Device 003: ID 05e3:0610 Genesys Logic, Inc. 4-port hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

In case there is doubt I can access the port, I'm using this udev rules that already worked with nRF Connect/Programmer for DFU and with raccoon when opening the port:

> 1 $ cat /etc/udev/rules.d/70-user-serial.rules 
SUBSYSTEMS=="usb", ATTRS{idVendor}=="1915", ATTRS{idProduct}=="520f", MODE="0666"
SUBSYSTEMS=="usb", ATTRS{idVendor}=="1915", ATTRS{idProduct}=="521f", MODE="0666"

By the way: raccoon was also tested from my user, using sudo and from root. All 3 return same data.

xiongyihui commented 3 years ago

It seems it's an issue on Linux. I just tried it on Ubuntu, which doesn't work. On windows, it works.

CieNTi commented 3 years ago

Did you test the full flow (build + DFU + write + raccoon), or board kept the same code and you just tested raccoon?

I want to see if I can assume that my build + DFU + flash + reset is all OK, and only fails python stuff at the end, so I can narrow the debug focus :D

xiongyihui commented 3 years ago

I tested raccoon with another nrf52840 board at my hand. When a serial port is opened on linux, it will receive a few bytes of data from linux before we send anything. This may be the cause

CieNTi commented 3 years ago

I'm just used to C, and to me that is a weird thing to think ... but I never did serial communications with python, so I cannot imagine what is happening there.

In any case, do you think it is possible to ignore that kind of extra stuff at both parties, and "rearm" at some point?

Thanks for your answers and invested time :)

mringwal commented 3 years ago

If you look at the Raccoon python code, it tires to synnc with the dongle : https://github.com/bluekitchen/raccoon/blob/master/pyclient/raccoon.py#L282 Maybe adding more delay or retires can help with this.

SeanBurford commented 3 years ago

I encountered a similar issue. raccoon.py was hanging waiting for the response to the reset request. Disabling modem manager for the USB device fixed it. https://github.com/NordicSemiconductor/nrf-udev has instructions on how to do that.