nccgroup / Sniffle

A sniffer for Bluetooth 5 and 4.x LE
https://www.nccgroup.trust/us/our-research/sniffle-a-sniffer-for-bluetooth-5/?research=Public+tools
GNU General Public License v3.0
870 stars 130 forks source link

Master branch works with -s /dev/ttyUSB0 but fails with -s /dev/serial/by-id/<long Sonoff name> #93

Closed jsmif closed 3 months ago

jsmif commented 3 months ago

Reflash Sonoff with

sudo python3 cc2538-bsl.py -p /dev/serial/by-id/usb-ITead_Sonoff_Zigbee_3.0_USB_Dongle_Plus_55ca6286e3e4f4fba5d0448333fa99fc-if00-port0 --bootloader-sonoff-usb -ewv ~/Downloads/sniffle_cc1352p1_cc2652p1_1M.hex
<cut>
Writing 360448 bytes starting at address 0x00000000
Write 104 bytes at 0x00057F980
    Write done                                
Verifying by comparing CRC32 calculations.
    Verified (match: 0x26e6c6f2)

Run sniff_receiver as:

sudo python3 sniff_receiver.py -s /dev/ttyUSB0

That works.

Run sniff_receiver as:

sudo python3 sniff_receiver.py -s /dev/serial/by-id/usb-ITead_Sonoff_Zigbee_3.0_USB_Dongle_Plus_55ca6286e3e4f4fba5d0448333fa99fc-if00-port0 

That just never outputs anything.

Any idea why it doesn't like the long-but-unique form? (I think this is a regression probably introduced into just the master branch, because I know I have some other system which uses the long form fine.)

sultanqasim commented 3 months ago

Strange, I’m not sure why that happens. Could you try a previously tagged release instead of the current master branch to see if the same thing occurs? I’m away from my computer at the moment but I can try later when I have a chance.

jsmif commented 3 months ago

OK, I tried the 1.10.0 and 1.9.3 tags, but they actually exhibit the same behavior. I thought it was perhaps the OS being an issue since I'm using Ubuntu 24.04 and the known-working-with-long-form host is Ubuntu 22.04. But no, I have a separate Ubuntu 22.04 VM which I could try on, and on that too both master and those two tags work for the short form and fail for the long form.

FWIW both

sudo screen /dev/ttyUSB0 921600

and

sudo screen /dev/serial/by-id/usb-ITead_Sonoff_Zigbee_3.0_USB_Dongle_Plus_55ca6286e3e4f4fba5d0448333fa99fc-if00-port0 921600

Show valid well-formed base64 data, and I was using a dongle specifically reflashed to the "1M" sonoff firmware so I could just test the default behavior with no changes to the sniffle_hw.py.

So I went and grabbed the dongle from the Ubuntu 22.04 system where the long form works. The box is at commit 01e064bf0201bfa18bf3932a1c56778fe98cee1c. The dongle is running the 2M firmware with the following diff (because I don't know which case is the one I should change away from 921600)

--- a/python_cli/sniffle/sniffle_hw.py
+++ b/python_cli/sniffle/sniffle_hw.py
@@ -97,9 +97,11 @@ class SniffleHW:
                 if serport is None:
                     raise IOError("Sniffle device not found")
                 else:
-                    baud = 921600
+#                    baud = 921600
+                    baud = 2000000
         elif is_cp2102(serport):
-            baud = 921600
+#            baud = 921600
+            baud = 2000000

When I then check out that commit, and make that change, the Ubuntu 22.04 VM works with the long form of the serial path fine.

sultanqasim commented 3 months ago

Ah, that gives me a good pointer to what's happening. The is_cp2102 function will return False if the supplied serial port path is not the canonical path to the dongle (i.e. /dev/ttyUSB0). Is /dev/serial/by-id/usb-ITead_Sonoff_Zigbee_3.0_USB_Dongle_Plus_55ca6286e3e4f4fba5d0448333fa99fc-if00-port0 a symlink to /dev/ttyUSB0? If so, I can change the code to follow symlinks.

jsmif commented 3 months ago

Yep, it's a symlink

sultanqasim commented 3 months ago

Try now with (with bf91946cf54d8186682f8ba6ae48179da93a351d)

jsmif commented 3 months ago

Yep, works now. Thanks!