2026-06-02

Wireshark USB Filters: Finding the Right Device with USBPcap, usbmon, and Bus Scope

How to filter USB captures by device, endpoint, transfer type, setup packet, interface, and timing when USBPcap or usbmon captures too much traffic.

USB captures can become overwhelming fast. A machine may have a keyboard, mouse, webcam, Bluetooth adapter, storage device, serial adapter, security key, and internal hub active at the same time. When users search for "Wireshark USB filter", "USBPcap filter device", "usbmon filter endpoint", or "how to find my USB device in capture", they usually have the same problem: "the capture contains too much traffic and not enough structure." Bus Scope is built to make USB inspection more direct, but understanding the filtering problem is still useful. Whether the capture comes from USBPcap on Windows, usbmon on Linux, or another USB capture source, the key is to identify the device and then narrow the trace by address, endpoint, transfer type, and control request.

Direct answer: capture from before plug-in, identify the target by VID/PID and descriptors, note its assigned device address, then narrow by usb.device_address, usb.endpoint_address, usb.transfer_type, setup fields, and status. Keep endpoint-zero control traffic and reset/re-enumeration events visible until the device identity and failure boundary are established. A short filter is useful only when it preserves the request, completion, and context that explain the problem.

Start with enumeration

The easiest way to identify a USB device is to capture from plug-in. Enumeration contains descriptors that name the device, vendor ID, product ID, configurations, interfaces, endpoints, and class-specific details.

Look for:

Vendor ID
Product ID
Device descriptor
Configuration descriptor
Interface descriptors
Endpoint descriptors
String descriptors
SET_ADDRESS
SET_CONFIGURATION

If you start capture after the device is already running, you may only see endpoint traffic without the descriptor context. That makes filtering harder because endpoint numbers alone are not enough.

Device address can change

USB device addresses are assigned by the host during enumeration. If the device disconnects and reconnects, the address may change. A filter that worked for the first connection may miss the second connection.

This matters when debugging reset loops. If a device re-enumerates repeatedly, you may need to track multiple addresses in one capture. The product/vendor descriptors reveal that those addresses belong to the same physical device.

Bus Scope can help keep that relationship visible instead of forcing you to mentally stitch together address changes.

Filter by endpoint

After configuration, most data traffic uses endpoints. Endpoint zero is control. Other endpoints may be bulk, interrupt, or isochronous.

Common endpoint meanings:

0x00: control OUT on endpoint zero
0x80: control IN on endpoint zero
0x81: endpoint 1 IN
0x01: endpoint 1 OUT
0x82: endpoint 2 IN
0x02: endpoint 2 OUT

The direction bit matters. 0x81 and 0x01 are not the same endpoint direction. A serial adapter, for example, may use one bulk OUT endpoint for host-to-device data and one bulk IN endpoint for device-to-host data.

Endpoint filters are useful after you already know which endpoint carries the traffic you care about.

Filter by transfer type

Different USB problems live in different transfer types:

Control transfers: descriptors, configuration, class requests, vendor commands.
Bulk transfers: storage, serial data, vendor data, many capture devices.
Interrupt transfers: HID input, status notifications, low-latency reports.
Isochronous transfers: audio, video, time-sensitive streaming.

If a USB serial device opens but sends no data, inspect control transfers for line coding and control line state, then bulk endpoints for payload. If a webcam starts but video is corrupt, inspect isochronous transfers and alternate settings. If a HID device misbehaves, inspect interrupt transfers and report descriptors.

Filtering by transfer type reduces noise while keeping the relevant class of evidence.

Filter by setup packet

Control transfers include setup packets. Setup packets are extremely useful because they identify request direction, type, recipient, request code, value, index, and length.

Important examples include:

GET_DESCRIPTOR
SET_ADDRESS
SET_CONFIGURATION
SET_INTERFACE
CLEAR_FEATURE
HID GET_REPORT
HID SET_REPORT
CDC SET_LINE_CODING
CDC SET_CONTROL_LINE_STATE
Vendor-specific commands

When a device fails during setup, the setup packet often tells you exactly which request triggered the problem.

USBPcap capture selection on Windows

On Windows, USBPcap captures from USB host controllers. If a machine has multiple controllers, choosing the wrong one may produce a capture with no target device traffic.

A practical workflow:

Unplug the target device.
Start capture on the likely controller.
Plug in the device.
Look for enumeration descriptors.
If nothing appears, try another controller capture.
Once the device is found, keep the capture around as a reference.

Bus Scope's value is to make this workflow less opaque: the target is the USB device conversation, not just a huge packet list.

usbmon capture on Linux

On Linux, usbmon exposes USB bus traffic. The bus number matters. A device listed as Bus 003 Device 012 belongs to bus 3 at that moment. After reconnect, the device number may change.

The most useful capture starts before plug-in, because enumeration reveals the device identity. If permission blocks capture, solve that first; otherwise you may only see application-level failure and never see USB evidence.

Common filtering mistakes

Avoid these mistakes:

Filtering only after the failure, missing enumeration.
Assuming device address is stable across reconnects.
Confusing endpoint direction.
Ignoring endpoint zero control traffic.
Looking only at payload packets and missing class requests.
Treating all vendor-specific requests as noise.
Filtering out resets and errors too early.
Ignoring the hub and port context.

A clean filter is useful only if it preserves the failure.

What to keep in an investigation capture

For a report you can share with a firmware, driver, or QA team, keep:

The initial enumeration.
The target device descriptors.
The configuration and interface selected by the host.
The class or vendor-specific requests before failure.
The endpoint traffic involved in the failure.
The reset, stall, timeout, or disconnect event.
Enough timing context to show whether the failure is immediate, idle-related, or load-related.

That evidence is stronger than a screenshot of "device not recognized."

Final diagnosis

USB filtering is not just about hiding noise. It is about preserving the packet sequence that explains the failure. Start from enumeration, identify the device, follow address changes, narrow by endpoint and transfer type, and keep control requests visible.

Bus Scope is meant to support that workflow: find the real USB conversation quickly, then inspect the bus-level evidence that explains why the device works, stalls, resets, or disappears.

Wireshark USB display-filter building blocks

Wireshark's current USB display-filter reference includes fields such as:

Filter field	Meaning	Practical use
`usb.device_address`	Host-assigned device address	Isolate one enumeration instance
`usb.idVendor`	Vendor ID	Confirm identity in descriptors
`usb.idProduct`	Product ID	Confirm identity in descriptors
`usb.endpoint_address`	Endpoint address including direction	Follow one data pipe
`usb.endpoint_address.number`	Endpoint number	Group IN/OUT variants by number
`usb.endpoint_address.direction`	Endpoint direction	Separate host-to-device and device-to-host
`usb.transfer_type`	URB transfer type	Select control, bulk, interrupt, or isochronous work
`usb.setup.bRequest`	Control request code	Find a specific setup operation
`usb.setup.wValue`	Setup value	Find descriptor type/index or request-specific value
`usb.setup.wIndex`	Setup index	Find interface, endpoint, language, or request-specific context
`usb.setup.wLength`	Requested data length	Detect length disagreement
`usb.urb_status`	URB completion status	Find non-success completions
`usb.request_in` / `usb.response_in`	Related frame references	Follow request/response pairing

Field availability and numeric values depend on Wireshark version, capture backend, and packet type. Use field-name autocomplete and inspect a representative frame before turning an example into a team runbook.

Build filters in layers

Do not begin with one giant expression. Add one constraint at a time and observe what disappears.

Layer 1: prove device identity

Capture enumeration and locate usb.idVendor and usb.idProduct. These descriptor fields identify the device, but later data frames may not repeat them. Note the assigned usb.device_address.

Conceptual filter:

usb.idVendor == 0x1234 && usb.idProduct == 0x5678

Use it to find the descriptor, not as the only filter for the whole session.

Layer 2: follow the assigned address

After the host assigns address 7:

usb.device_address == 7

If the device resets and returns as address 9, this filter will miss the new instance. Keep enumeration visible or combine the relevant addresses after verifying they belong to the same physical device.

Layer 3: follow one endpoint

For endpoint 0x81:

usb.device_address == 7 && usb.endpoint_address == 0x81

That isolates endpoint 1 IN. Endpoint 0x01 is endpoint 1 OUT and must not be treated as equivalent.

Layer 4: find a setup request

For a request code known to the device or class:

usb.device_address == 7 && usb.setup.bRequest == 0x09

The numeric meaning depends on request type and recipient. Keep bmRequestType, wValue, wIndex, and wLength beside it; bRequest alone can be ambiguous across standard, class, and vendor requests.

Layer 5: find failure status

Use usb.urb_status to inspect completion status, but first learn how the current backend represents success and errors. Preserve the matching request and neighboring events. A list of failed completions without their submissions often removes the evidence needed for diagnosis.

Filtering recipe by USB class

Device case	Start with	Then narrow to	Keep visible
HID missing reports	Enumeration and HID report descriptor	Interrupt IN endpoint and report ID/length	Class setup and idle/protocol requests
CDC COM port issue	CDC interfaces and functional descriptors	`SET_LINE_CODING`, `SET_CONTROL_LINE_STATE`, bulk endpoints	Notification endpoint and re-enumeration
Mass-storage timeout	Interface and bulk endpoints	Command/status traffic and non-success status	Reset recovery and clear-halt requests
UVC video dropout	UVC descriptors and alternate settings	Isochronous endpoint and packet status	Probe/commit and `SET_INTERFACE`
Vendor control failure	Device identity and endpoint zero	Request code, value, index, length, payload	Submission/completion pair

This approach avoids applying a storage filter to a CDC case or hiding the control request that enabled an isochronous endpoint.

Submission and completion pairing

Software USB capture describes host-stack work, often with separate submission and completion records. A diagnosis should answer:

which request was submitted;
which completion belongs to it;
how long the operation took;
what status returned;
how many bytes were requested and completed;
where the data appears;
whether a reset, cancellation, or disconnect interrupted the pair.

Wireshark exposes related-frame references on supported data. In Bus Scope, keep the selected transfer, setup fields, raw bytes, status, and surrounding timeline together. The goal is the same: avoid interpreting one half of a transaction as the entire event.

Example: CDC serial device opens but sends no data

Capture from plug-in.
Identify CDC communication and data interfaces.
Confirm bulk IN and OUT endpoint addresses.
Locate SET_LINE_CODING.
Locate SET_CONTROL_LINE_STATE and inspect DTR/RTS values.
Follow the bulk OUT endpoint for host payload.
Follow the bulk IN endpoint for device response.
Search for stall, timeout, reset, or disconnect around the first missing completion.
Compare with a known-good open/send/receive cycle.

Do not jump directly to the bulk endpoint. The missing data may be a consequence of an earlier class-control request or driver state.

Example: device address changes during a reset loop

Create an address timeline:

Time	Address	Identity evidence	Outcome
Start	0/default	Initial descriptor request	Device detected
Enumeration 1	7	VID/PID and strings	Configuration begins
Failure	7	Stall/reset/disconnect	Address lost
Enumeration 2	9	Same VID/PID/serial or port context	Same physical device returns

Filter each address only after establishing the relationship. A persistent port path, serial string, descriptors, timing, and physical test action help; address alone does not.

The reset-loop troubleshooting guide covers the broader diagnosis.

Capture health before filter confidence

A perfect filter cannot recover traffic that was never captured. Check:

correct USBPcap controller or usbmon bus;
backend permissions;
capture start before plug-in;
buffer or dropped-event warnings;
retained payload settings;
timestamp continuity;
actual reproduction window.

If the known trigger produces no traffic, clear the filter and verify capture health before concluding the device sent nothing.

Turn a filter into a reproducible case

Record:

host and capture backend;
device identity and firmware build;
capture start boundary;
trigger action;
filter or query;
first divergent frame/event;
matching request/completion;
raw bytes and decoded fields;
known-good comparison;
remaining unknowns.

Bus Scope Community supports JSON/text export for evidence handoff. Optional editions add .bscope session save/open and HTML/PDF reports. Choose the path documented on the Bus Scope license page rather than assuming every output belongs to the free edition.

Questions and answers

How do I analyze USB traffic in Wireshark?

Capture through an appropriate backend, start before plug-in, identify VID/PID and the assigned address, then filter by device, endpoint, transfer type, setup fields, and status while preserving related context.

Why does my device filter stop working after reconnect?

The host can assign a new device address after re-enumeration. Find the new descriptors, verify identity, and update the address filter.

Should I filter by VID and PID?

Use VID/PID to identify descriptor frames. Later transfers may not carry those fields, so follow the assigned device address and endpoint after identity is established.

What is the difference between `0x81` and `0x01`?

Both use endpoint number 1, but 0x81 is IN and 0x01 is OUT because bit 7 encodes direction.

Why should endpoint zero stay visible?

Endpoint zero carries control transfers for enumeration, class setup, configuration, feature control, and vendor requests. The data-endpoint symptom may begin with a failed control request.

Can Bus Scope use USBPcap and usbmon captures?

Bus Scope uses USBPcap on Windows and usbmon on Linux for its live host-visible USB workflow. Follow the platform capture setup before filtering.

When is a hardware analyzer required?

Use hardware when the unresolved question needs on-wire transaction, timing, or electrical evidence that host capture does not contain.

Related guides

Continue with the same-language pages below. They cover adjacent stages without changing the canonical owner of this topic: