Selected capture options result in empty capture.

[TomasHubelbauer]

Hey, when I run USBPcapCMD.exe it shows me a device called \\.\USBPcap1 which has the device I want to monitor on it:

1 \\.\USBPcap1
  \??\USB#ROOT_HUB30#4&12daa40&0&0#{f18a0e88-c30c-11d0-8815-00a0c906bed8}
    [Port 1] Složené zařízení USB
      Vstupní zařízení USB
        Zařízení klávesnice standardu HID
      Vstupní zařízení USB
        Myš kompatibilní s technologií HID
        Uživatelské zařízení standardu HID
      Vstupní zařízení USB
        Uživatelské zařízení standardu HID
        Uživatelské zařízení standardu HID
        Dodavatelem definované zařízení standardu HID
        Systémový řadič standardu HID
    [Port 3] Podpora tisku přes sběrnici USB
      Brother PT-D600
        Brother PT-D600
    [Port 4] Složené zařízení USB
      Integrated Webcam
    [Port 5] Intel(R) Wireless Bluetooth(R)

(Sorry for Czech, stuck on Windows 10 Home with no option to change display language.)

The Brother PT-D600 printer is what I am looking to inspect.

However, when I run this:

USBPcapCMD.exe -d \\.\USBPcap1 -o - | "C:\Program Files\Wireshark\Wireshark.exe" -k -i -

…it says what it says in the issue title. The options seem to be fine to me - the correct device and no output file. Taken straight from the website.

What can I do to fix this?

[TomasHubelbauer]

This seems to be caused by the o switch. No matter whether I put - or a real file name, it says the same.

[gpotter2]

I'm having the very same bug :/ Windows 10 as well

[Boscop]

I'm getting the exact same error ("Selected capture options result in empty capture"), also using the same command, following this guide: https://blog.sverrirs.com/2016/04/reverse-engineer-usb-protocol.html

But I'm on Windows 8.1

[gpotter2]

I found out that adding the -b parameter allowed to save pcap files with -o.

-o - is still broken

[lilydjwg]

The same happened to me with Windows XP. I downgraded to 1.0.0.7 and that one worked.

[dzgjwb01]

I am also having the same issue with Windows 8.1. I will try downgrading to 1.0.0.7 and see if that fixes it.

[fabriceo]

same problem here on W7 64 I ve tried all 1.2 versions without success and version 1.0.0.7 suggested above seems not anyore compatible with wireshark pcap format... any chance to get an update??

[TomasHubelbauer]

I am wondering the same thing. @desowin is that something that you could see happening in the near future if time allows?

[Jay-Jia]

When I choose the first device to be monitored, and then ctrl+c, my wireless device can't work with my computer anymore. orz

[desowin]

The best way is to use the extcap interface in Wireshark and simply click that through from Wireshark GUI. If you want to capture from all devices on given root hub, add the -A command line parameter.

[desowin]

I have noticed that the multicheck in Wireshark Qt interface is not really working properly. It works fine in the Wireshark Legacy interface (GTK+) in 2.0.16. The GTK+ interface was removed. The "click that through from Wireshark GUI" in Wireshark Qt can lead to Wireshark calling USBPcapCMD with invalid parameters (without supplying --devices argument parameter).

[TomasHubelbauer]

So this is actually a Wireshark issue, right? It seems the Wireshark GitHub mirror doesn't accept issues and I am not willing to sign up for a mailing list, if you are, they have issue reporting info here:

https://www.wireshark.org/docs/wsug_html_chunked/ChIntroHelp.html

[desowin]

~~After investigating it more, it seems that it worked with GTK+ interfacejust by a coincidence. USBPcapCMD always listed devices with {enabled=false} and the comment in wireshark gtk code said: / v->is_default is set when there was {default=true} for this value. / / v->enabled is false for non-clickable tree items ({enabled=false}). /~~

Guess who wrote that comment back in 2014? Yes, it was me.

As it worked "just fine" to me, I assumed everything is ok. However, now I realize that I must have made a bug somewhere in the GTK+ interface implementation as with "{enabled=false}" it is not supposed to display any checkboxes - but it did.

If I manage, next Wireshark and USBPcap version will have it working properly.

EDIT: This got me confused a lot, everything seems fine, check comments below.

[TomasHubelbauer]

Okay, then it seems like something fixable in thus codebase so I will reopen so that you can close when you get around to fixing it. Thanks for looking into this!

[gpotter2]

It would be god-like if there were a dll by then... but I understand that you have other things to do.

Anyways, thanks a lot for coming back on the project !

I am planning to add an UsbPcap integration to scapy as soon as we have it working correctly again...

[desowin]

@gpotter2 In fact a dll with a clean interface would be really good to use in the USBPcamCMD itself. I have rather hard time in going through it now as I am trying to understand what's going on. The CMD code needs major redesign (that's to be done after 1.2.0.4 where the goal is to fix some important problems).

[desowin]

After some more digging, I realized that there are some options with {enabled=true}. And that it is indeed possible to make use of selective filtering of devices in Wireshark Qt interface - only it requires really good understanding of the implementation.

That is, in the devices list the devices with "[X] Friendly Name" where X is an number, are corresponding to actual USB devices which you can filter. Click on this and it becomes highlighted. Note that it is more often than not, really hard to tell from the "Friendly Name" what device it really is. Hence it also lists the children which are logical driver objects - not actual USB devices. As usually these logical driver objects hold more understandable description, they are included in the list. There's a whole lot more of the logical driver objects (non-selectable) than the USB devices (selectable).

Example with picture will make it clear. Assume I want to trace the COM4 which is on Black Magic Probe that I have connected to my laptop.

The actual device I have to select is "[6] Urządzenie kompozytowe USB" (english: "[6] composite USB device"). And it indeed is selectable in Wireshark Qt interface. The number 6 is actually the USB device address (USB host assigned during the enumeration address 6 to the device). Note that if I look at the logical driver objects, it is quite easy to tell what it is - while without this extra information it would be most likely a guessing game.

Note that selecting the logical driver object wouldn't really make much sense here as USBPcap is not centered around the Windows driver development, but is about the USB protocol itself. I know that USBPcap+Wireshark is used for debugging embedded device firmware and/or windows application that talks to said device (just like Wireshark is a godsend when investigating network traffic, Wireshark+USBPcap is helpful when investigating issues related to data that gets passed from Windows application to the USB device). However, I don't really know if anyone uses USBPcap as a helper when writing USB Windows drivers.

[desowin]

One additional note about the screenshot - if you only select the USB hub ("[5] Rodzajowy koncentrator USB") it will only capture the communication with the hub itself, not with the devices that are connected to the hub (unless you select them separately).

[gpotter2]

@desowin Thanks for your answer ! I am really hoping to see a 2.0 version with a nice fancy dull soon :)

I don’t know if it’s possible, but can USBPcap send packets ? scapy is a wireshark-like util which is used a lot to send custom created frames

[desowin]

@gpotter2 No, USBPcap cannot send packets and it's not really supposed to. The easiest way to send custom packets would be to use libusb, but that requires installing the libusb as the USB device driver (replacing the original driver).

[gpotter2]

Got it. Thanks !

[desowin]

It seems that even if you add the -A option and redirect USBPcapCMD stdout to Wireshark, it still won't really work as the AttachConsole() call in attach_parent_console() can reopen redirected stdout. This unwanted stdout change done by AttachConsole() essentially makes Wireshark to not receive the data (it is printed to the console). This behavior is described in https://github.com/rprichard/win32-console-docs#allocconsole-attachconsole-traditional

[Slion]

So it's not possible to start live capture from command line anymore?