USBPcap and usbmon debugging: what to collect before blaming firmware

Start with the failure mode

Before capturing, write down the exact failure. Examples:

• Device never enumerates
• Configuration is selected but interface does not start
• HID input report length is unexpected
• Bulk IN endpoint stops responding
• CDC device opens but no data arrives
• Mass Storage command times out
• UVC camera exposes descriptors but preview fails

Different failures require different evidence.

Capture enumeration first

If the device is not recognized correctly, capture from plug-in through configuration. Look for:

• reset
• device descriptor request
• configuration descriptor request
• string descriptor requests
• set address
• set configuration
• interface and endpoint descriptors
• class-specific descriptors

Enumeration bugs often hide in descriptors, not payload data.

Read descriptors like a contract

Descriptors tell the host what the device claims to be. Check:

• bDeviceClass / bInterfaceClass
• idVendor / idProduct
• bcdUSB
• configuration count
• interface count
• endpoint address and direction
• endpoint transfer type
• wMaxPacketSize
• polling interval
• HID report descriptor
• CDC class descriptors
• UVC class descriptors

If the descriptor contract is wrong, the host may behave correctly while the product still fails.

Separate control, interrupt, bulk, and isochronous traffic

Not every transfer means the same thing.

• Control transfers often explain setup and class requests.
• Interrupt transfers often matter for HID devices.
• Bulk transfers often matter for CDC, storage, vendor protocols, and firmware update flows.
• Isochronous transfers often matter for cameras, audio, and real-time media.

A readable timeline should keep these categories visible.

Check setup packets before payloads

For control transfers, inspect the setup packet:

• bmRequestType
• bRequest
• wValue
• wIndex
• wLength

A single wrong wIndex or request direction can explain a failure that looks like a payload problem.

Compare good vs bad hosts

If the device works on one machine and fails on another, capture both. Compare:

• descriptor requests
• selected configuration
• class driver behavior
• endpoint polling interval
• transfer sizes
• timeout patterns
• stall/clear-feature sequences

Do not assume the host with the failure is the only interesting one. The working host is your baseline.

Avoid overclaiming from software captures

USBPcap and usbmon are software-side evidence. They are very useful, but they are not a replacement for a hardware analyzer when the question is electrical timing, signal integrity, low-level bus errors, or power behavior.

Use software captures for:

• enumeration logic
• descriptors
• class requests
• transfer sequence
• payload inspection
• host/device protocol behavior

Use hardware tools when you need electrical truth.

What to send to firmware or support

A useful USB debugging handoff should include:

• OS and kernel/build version
• Device VID/PID
• Firmware version
• Capture source: USBPcap or usbmon
• Failure mode
• Enumeration summary
• Descriptor notes
• Endpoint involved
• Transfer timeline
• Relevant setup packets
• Payload examples if safe
• What changed between good and bad runs

That is much better than "USB does not work".

Where Bus Scope fits

You can capture USB evidence with USBPcap, usbmon, Wireshark, and scripts. The hard part is making the session readable enough for firmware, hardware, and support teams to discuss the same evidence. I build Bus Scope for that workflow. It is a local desktop USB diagnostics workbench for inspecting USBPcap or usbmon evidence, descriptors, endpoints, HID reports, payloads, sessions, filters, and exportable support notes. It is not a professional hardware analyzer replacement for electrical timing or signal integrity. It is for daily software-side USB debugging and handoff.

Disclosure: I build Bus Scope.

Quick checklist

• [ ] Define the exact failure mode
• [ ] Capture from plug-in if enumeration matters
• [ ] Save descriptors
• [ ] Inspect setup packets
• [ ] Separate transfer types
• [ ] Compare good and bad hosts
• [ ] Document OS, firmware, VID/PID
• [ ] Export a readable handoff