Capture with Wireshark using Sniffle plugin freezes on Linux about sniffle HOT 22 CLOSED

After the first time the sniffer is used, it saves the settings from the first run. To change the settings on subsequent runs, click the gear icon to the left of the Sniffle capture device on the Wireshark start screen.

from sniffle.

Thanks for picking this up, I've created a new VM to confirm in my environment (different from original post):

• Xubuntu 22.04.4 LTS (as a VMware 17.5.1 Guest inside a Windows 11 host)
• Wireshark 3.6.2 (Git v3.6.2 packaged as 3.6.2-2)
• Sniffle 1.8 expanded from .zip (from the release Version 1.8)
• LAUNCHXL-CC26X2R1 with sniffle_cc2652r1.out (from the release Version 1.8)
• LAUNCHXL-CC26X2R1 with firmware_3.0.0.28_fastuart.bin applied
• Using the instructions from the README.md with the symlink approach

In that initial setup, starting Wireshark with the capture plugin showed the "Couldn't run /usr/bin/dumpcap in child process. Permission denied" error dialog (same as @jsmif showed in #52 (comment)).

Fixed this with: sudo chmod +x /usr/bin/dumpcap and Wireshark happily started to capture the packets.

So I can confirm that the issue has been resolved in Sniffle 1.8 as long as the user sets the permissions on dumpcap correctly, which might be environment specific. Perhaps that can be added to the README.md as a hint.

from sniffle.

When you say it "freezes", do you mean the Wireshark program freezes, or it just fails to capture anything?

from sniffle.

Both: wireshark freezes and it appears not to capture anything in the process.

I'll clean my virtual machine and replay my steps to provide some more details of what is happening.

from sniffle.

I've re-installed Wireshark and ensured that the previous ~/.config/wireshark/ was removed in between.

I then tested that Wireshark could load a Sniffle captured PCAP just fine.

Then I used the following to install the Sniflle plugin for Wireshark (and checked that sniffle_extcap.py is executable):

mkdir -p ~/.config/wireshark/extcap/
ln -s ~/Sniffle/python_cli/sniffle_extcap.py ~/.config/wireshark/extcap

Then started Wireshark from the command-line with --log-level info to see if I could spot some errors. The "Sniffle BLE sniffer: sniffle" interface shows under the Capture options. When I start the Capture with sniffle in this fresh mode, it shows:

So far, so good; except that the Sniffer serial port needs to be changed AFAIK; and I wanted to capture the communications of a specific BLE device using MAC filter; so I changed those in the dialog:

After clicking on Start, it freezes showing the following (the console shows the info log):

Trying to close the Wireshark application shows:

from sniffle.

With debug log level, the console from which Wireshark is started shows:

from sniffle.

Thanks for the detailed report, I will look into this.

from sniffle.

Ah, and when the first freeze has been seen: the dialog to configure the Sniffle capture isn't shown. It tries to start a capture right away. As the debug console output shows, it appears to take the inputs from the previous run. Perhaps this is due to me not being that familiar with Wireshark... maybe this behavior is expected and I don't know how to re-enter the Sniffle dialog.

from sniffle.

At least on KDE Neon (based on Ubuntu 22.04) with Wireshark 3.6.2, capture is working fine for me. All I did to install was:

mkdir -p ~/.config/wireshark/extcap/
ln -s $(pwd)/sniffle_extcap.py ~/.config/wireshark/extcap

I then launched Wireshark, clicked the gear icon beside Sniffle to bring up capture settings, picked the right serial port, and captured. It worked fine, and adding a MAC filter also worked fine for me.

I'm still looking into what could be going wrong for your setup.

from sniffle.

You can also try setting the SNIFFLE_LOG_FILE environment variable before launching Wireshark to capture extra logs (see https://github.com/nccgroup/Sniffle/blob/master/python_cli/sniffle_extcap.py#L79)

from sniffle.

You can also try setting the SNIFFLE_LOG_FILE environment variable before launching Wireshark to capture extra logs (see https://github.com/nccgroup/Sniffle/blob/master/python_cli/sniffle_extcap.py#L79)

Is it worked @mdxs ?

from sniffle.

Actually didn't get to check... for what I needed to do I could use command line capture. Then used Wireshark to examine the PCAPs and I was happy enough.

Sorry for not reporting back earlier. As I noted in my original post, I was using a Linux VM guest on a Windows host. So I blamed my issue a bit on that configuration. Not sure if I will get back to this anytime soon.

from sniffle.

@sultanqasim I can confirm I see the same freezing behavior when trying to use wireshark (but it works fine via CLI).

I suspected it was because I was using an old Ubuntu 20.04 VM with Wireshark 3.2.3. However, I switched to a pretty fresh Ubuntu 22.04 VM which didn't have Sniffle installed. I installed it and confirmed I could sniff from the command line:

Then I did sudo apt-get install wireshark which yields the same version 3.6.2 and did the same setup of

mkdir -p ~/.config/wireshark/extcap/
ln -s $(pwd)/sniffle_extcap.py ~/.config/wireshark/extcap

I see the interface fine and configure the interface as follows:

However, when I hit Start, I see no packets, and eventually I get the Wireshark-isn't-responding notification:

from sniffle.

@jsmif did you try with /dev/ttyACM0 instead of /dev/ttyACM1? Usually ttyACM0 is the Sniffle serial port, and ttyACM1 is the XDS110 debugger control port.

from sniffle.

@sultanqasim sorry for not clarifying. I had other stuff plugged in to my box, so I am sure that ACM1 was the correct serial port. I also checked it with the -s option on the CLI (which I should have shown, but I forgot to re-take a screenshot.)

I now have more stuff plugged in and a changed BDADDR, but here's CLI confirmation on ACM2...

With continued failure within GUI on ACM2

from sniffle.

@sultanqasim OK, I just had an idea that perhaps if it didn't work in the GUI but did in the CLI, it could be because of wireshark's permissions. So I ran wireshark as root from the CLI with "sudo wireshark", and then got the extcap folder, /usr/lib/x86_64-linux-gnu/wireshark/extcap, and then copied all the files in there.

And now the capture works from within root-launched wireshark!

When I installed Wireshark I'm 90% sure I selected the "allow other unprivileged users to capture pcaps" option, so I don't think that's the issue... but still it seems like it has something to do with Wireshark permissions. Is there anything special about that you did for your Wireshark install? (E.g. maybe you installed from source instead of from apt?)

from sniffle.

Oh, that certainly helps narrow down the cause. What are the udev rules you have set up for the Launchpad's USB UART? Can your user account access the tty (without sudo)? I have udev rules set up to allow accessing the tty as my regular user account.

Perhaps I should update the documentation to make this clear, and add some error handling and reporting to the Wireshark plugin in case of permission errors.

from sniffle.

I don't know what udev rules are or how to set them, so the VM is just default. So no, I can't access the serial port without sudo. So yes, if there's some commands that you ran to allow for serial access from the user by default, that's probably it, and adding those to the instructions would be appreciated. (And I'll give them a try once available even though I have the workaround now.)

from sniffle.

I don't know what udev rules are or how to set them, so the VM is just default. So no, I can't access the serial port without sudo. So yes, if there's some commands that you ran to allow for serial access from the user by default, that's probably it, and adding those to the instructions would be appreciated. (And I'll give them a try once available even though I have the workaround now.)

Ah, well that explains it. Udev rules (typically located in /etc/udev/rules.d/) can be used to specify file permissions for access to USB devices, among other things. Typically you specify the USB VID, PID, permissions, and associated group (for example plugdev). People often write their own custom udev rules, or use rules defined by the device manufacturer. I'll share the udev rules I use in a bit.

from sniffle.

For reference, these are the udev rules written by TI that are installed with UniFlash at /etc/udev/rules.d/71-ti-permissions.rules:

SUBSYSTEM=="usb",ENV{DEVTYPE}=="usb_device",ATTRS{idVendor}=="0403",ATTRS{idProduct}=="a6d0",MODE:="0666"
SUBSYSTEM=="usb",ENV{DEVTYPE}=="usb_device",ATTRS{idVendor}=="0403",ATTRS{idProduct}=="a6d1",MODE:="0666"
SUBSYSTEM=="usb",ENV{DEVTYPE}=="usb_device",ATTRS{idVendor}=="0403",ATTRS{idProduct}=="6010",MODE:="0666"
SUBSYSTEM=="usb",ENV{DEVTYPE}=="usb_device",ATTRS{idVendor}=="0403",ATTRS{idProduct}=="bcd9",MODE:="0666"
SUBSYSTEM=="usb",ENV{DEVTYPE}=="usb_device",ATTRS{idVendor}=="0403",ATTRS{idProduct}=="bcda",MODE:="0666"
SUBSYSTEM=="usb",ENV{DEVTYPE}=="usb_device",ATTRS{idVendor}=="1cbe",ATTRS{idProduct}=="00fd",MODE:="0666"
SUBSYSTEM=="usb",ENV{DEVTYPE}=="usb_device",ATTRS{idVendor}=="1cbe",ATTRS{idProduct}=="00ff",MODE:="0666"
SUBSYSTEM=="usb",ENV{DEVTYPE}=="usb_device",ATTRS{idVendor}=="0451",ATTRS{idProduct}=="bef1",MODE:="0666"
SUBSYSTEM=="usb",ENV{DEVTYPE}=="usb_device",ATTRS{idVendor}=="0451",ATTRS{idProduct}=="bef2",MODE:="0666"
SUBSYSTEM=="usb",ENV{DEVTYPE}=="usb_device",ATTRS{idVendor}=="0451",ATTRS{idProduct}=="bef3",MODE:="0666"
SUBSYSTEM=="usb",ENV{DEVTYPE}=="usb_device",ATTRS{idVendor}=="0451",ATTRS{idProduct}=="bef4",MODE:="0666"
SUBSYSTEM=="usb",ENV{DEVTYPE}=="usb_device",ATTRS{idVendor}=="0451",ATTRS{idProduct}=="c32a",MODE:="0666"
SUBSYSTEM=="usb",ENV{DEVTYPE}=="usb_device",ATTRS{idVendor}=="0451",ATTRS{idProduct}=="c31a",MODE:="0666"
ATTRS{idVendor}=="0451",ATTRS{idProduct}=="bef0",ENV{ID_MM_DEVICE_IGNORE}="1"
ATTRS{idVendor}=="0c55",ATTRS{idProduct}=="0220",ENV{ID_MM_DEVICE_IGNORE}="1"
KERNEL=="ttyACM[0-9]*",MODE:="0666"

from sniffle.

I investigated this issue and figured out the cause. As described in https://gitlab.com/wireshark/wireshark/-/issues/18501, Wireshark freezes when the control pipes are not opened. Previously, the extcap script was only opening the control pipes after successfully validating the arguments and opening the packet FIFO. Opening the packet FIFO would fail if the user doesn't have the right permissions for dumpcap (i.e. isn't a member of the wireshark group). Thus, Wireshark would freeze when attempting Sniffle extcap capture with either dumpcap permissions or invalid arguments to Sniffle.

I solved this issue in 713d5a9 by reordering the opening of pipes, so that the control pipes are opened first, and the UI can present errors to the user.

from sniffle.

OK, FWIW I can confirm that once I copied the udev rules from /etc/udev/rules.d/71-ti-permissions.rules in the VM were TI stuff was installed, to the VM where wireshark was installed, after I rebooted I could launch it and get the different permissions error (thus implying the udev rules were working):

So then I can confirm:

0. I had selected for non-root users to be able to sniff packets at wireshark install time
1. My user wasn't added to the wireshark group
2. dumpcap was set to permissions root:wireshark 754, so it would not be executable by anyone except wireshark group users
3. before I noticed that, I just did what was recommended here, and did a "sudo chmod +x /usr/bin/dumpcap"
4. With that change, I could now run Wireshark as an unprivileged user and see packets from Sniffle fine!

I didn't try updating Sniffle to pick up that latest change though, so I can't confirm if that would have been sufficient by itself to avoid the UI freeze.

from sniffle.