Wireshark-USB-Filter: Das richtige Device finden mit USBPcap, usbmon und Bus Scope

USB-Captures können schnell überwältigend werden. Eine Maschine kann gleichzeitig eine Tastatur, Maus, Webcam, Bluetooth-Adapter, Storage-Device, Serial-Adapter, Security-Key und einen internen Hub aktiv haben. Wenn Nutzer nach "Wireshark USB filter", "USBPcap filter device", "usbmon filter endpoint" oder "how to find my USB device in capture" suchen, haben sie meist dasselbe Problem: "Der Capture enthält zu viel Traffic und nicht genug Struktur." Bus Scope ist gebaut, um USB-Inspektion direkter zu machen, aber das Verständnis des Filter-Problems ist trotzdem nützlich. Ob der Capture von USBPcap unter Windows, usbmon unter Linux oder einer anderen USB-Capture-Quelle kommt, der Schlüssel ist, das Device zu identifizieren und den Trace dann nach Adresse, Endpoint, Transfer-Typ und Control-Request einzuengen.

Mit Enumeration starten

Der einfachste Weg, ein USB-Device zu identifizieren, ist, ab dem Anstecken zu capturen. Enumeration enthält Deskriptoren, die das Device benennen: Vendor-ID, Product-ID, Konfigurationen, Interfaces, Endpoints und klassenspezifische Details.

Achten Sie auf:

• Vendor-ID
• Product-ID
• Device-Deskriptor
• Configuration-Deskriptor
• Interface-Deskriptoren
• Endpoint-Deskriptoren
• String-Deskriptoren
• SET_ADDRESS
• SET_CONFIGURATION

Starten Sie den Capture, nachdem das Device bereits läuft, sehen Sie möglicherweise nur Endpoint-Traffic ohne Deskriptor-Kontext. Das macht Filterung schwerer, weil Endpoint-Nummern allein nicht reichen.

Device-Adresse kann sich ändern

USB-Device-Adressen werden vom Host während der Enumeration zugewiesen. Trennt sich das Device und reconnectet, kann sich die Adresse ändern. Ein Filter, der für die erste Verbindung funktioniert, kann die zweite verfehlen.

Das zählt beim Debuggen von Reset-Loops. Re-enumeriert ein Device wiederholt, müssen Sie möglicherweise mehrere Adressen in einem Capture verfolgen. Die Product/Vendor-Deskriptoren zeigen, dass diese Adressen zum selben physischen Device gehören.

Bus Scope hilft, diese Beziehung sichtbar zu halten, statt Sie zu zwingen, Adress-Wechsel mental zusammenzunähen.

Nach Endpoint filtern

Nach der Konfiguration nutzt der meiste Daten-Traffic Endpoints. Endpoint Null ist Control. Andere Endpoints können Bulk, Interrupt oder Isochronous sein.

Häufige Endpoint-Bedeutungen:

• 0x00: Control-OUT auf Endpoint Null
• 0x80: Control-IN auf Endpoint Null
• 0x81: Endpoint 1 IN
• 0x01: Endpoint 1 OUT
• 0x82: Endpoint 2 IN
• 0x02: Endpoint 2 OUT

Das Richtungs-Bit zählt. 0x81 und 0x01 sind nicht dieselbe Endpoint-Richtung. Ein Serial-Adapter nutzt zum Beispiel einen Bulk-OUT-Endpoint für Host-to-Device-Daten und einen Bulk-IN-Endpoint für Device-to-Host-Daten.

Endpoint-Filter sind nützlich, nachdem Sie bereits wissen, welcher Endpoint den Traffic trägt, der Sie interessiert.

Nach Transfer-Typ filtern

Verschiedene USB-Probleme leben in verschiedenen Transfer-Typen:

• Control-Transfers: Deskriptoren, Konfiguration, Klassen-Requests, Vendor-Kommandos.
• Bulk-Transfers: Storage, Serial-Daten, Vendor-Daten, viele Capture-Devices.
• Interrupt-Transfers: HID-Input, Status-Notifications, Low-Latency-Reports.
• Isochronous-Transfers: Audio, Video, zeitkritisches Streaming.

Öffnet sich ein USB-Serial-Device, sendet aber keine Daten, prüfen Sie Control-Transfers für Line-Coding und Control-Line-State, dann Bulk-Endpoints für Payload. Startet eine Webcam, aber Video ist korrupt, prüfen Sie Isochronous-Transfers und Alternate-Settings. Verhält sich ein HID-Device falsch, prüfen Sie Interrupt-Transfers und Report-Deskriptoren.

Filtern nach Transfer-Typ reduziert Rauschen und behält die relevante Klasse von Evidence.

Nach Setup-Paket filtern

Control-Transfers enthalten Setup-Pakete. Setup-Pakete sind extrem nützlich, weil sie Request-Richtung, Typ, Empfänger, Request-Code, Value, Index und Länge identifizieren.

Wichtige Beispiele:

• 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-Kommandos

Scheitert ein Device während des Setups, sagt das Setup-Paket oft genau, welcher Request das Problem ausgelöst hat.

USBPcap-Capture-Auswahl unter Windows

Unter Windows capturt USBPcap von USB-Host-Controllern. Hat eine Maschine mehrere Controller, kann die Wahl des falschen einen Capture ohne Target-Device-Traffic erzeugen.

Ein praktischer Workflow:

1. Target-Device ausstecken.
2. Capture auf wahrscheinlichem Controller starten.
3. Device anstecken.
4. Nach Enumeration-Deskriptoren suchen.
5. Erscheint nichts, anderen Controller-Capture versuchen.
6. Sobald das Device gefunden ist, Capture als Referenz behalten.

Bus Scopes Wert ist es, diesen Workflow weniger opak zu machen: Das Target ist die USB-Device-Konversation, nicht nur eine riesige Paket-Liste.

usbmon-Capture unter Linux

Unter Linux legt usbmon USB-Bus-Traffic offen. Die Bus-Nummer zählt. Ein als Bus 003 Device 012 gelistetes Device gehört in diesem Moment zu Bus 3. Nach Reconnect kann sich die Device-Nummer ändern.

Der nützlichste Capture startet vor dem Anstecken, weil die Enumeration die Device-Identität offenbart. Blockiert eine Berechtigung den Capture, lösen Sie das zuerst; sonst sehen Sie möglicherweise nur App-Level-Fehler und nie USB-Evidence.

Häufige Filter-Fehler

Vermeiden Sie diese Fehler:

• erst nach dem Fehler filtern und die Enumeration verpassen.
• annehmen, dass die Device-Adresse über Reconnects stabil ist.
• Endpoint-Richtung verwechseln.
• Endpoint-Null-Control-Traffic ignorieren.
• nur auf Payload-Pakete schauen und Klassen-Requests verpassen.
• alle Vendor-Specific-Requests als Rauschen behandeln.
• Resets und Fehler zu früh rausfiltern.
• Hub- und Port-Kontext ignorieren.

Ein sauberer Filter ist nur nützlich, wenn er den Fehler bewahrt.

Was in einem Untersuchungs-Capture zu behalten ist

Für einen Report, den Sie mit einem Firmware-, Treiber- oder QA-Team teilen können, behalten Sie:

• die initiale Enumeration.
• die Target-Device-Deskriptoren.
• die vom Host gewählte Konfiguration und das Interface.
• die Klassen- oder Vendor-Specific-Requests vor dem Fehler.
• den Endpoint-Traffic, der in den Fehler verwickelt ist.
• das Reset-, Stall-, Timeout- oder Disconnect-Event.
• genug Timing-Kontext, um zu zeigen, ob der Fehler sofort, idle-bezogen oder last-bezogen ist.

Diese Evidence ist stärker als ein Screenshot von "device not recognized".

Enddiagnose

USB-Filterung bedeutet nicht nur, Rauschen zu verstecken. Sie bedeutet, die Paket-Sequenz zu bewahren, die den Fehler erklärt. Starten Sie mit Enumeration, identifizieren Sie das Device, folgen Sie Adress-Wechseln, engen Sie nach Endpoint und Transfer-Typ ein und halten Sie Control-Requests sichtbar.

Bus Scope soll diesen Workflow unterstützen: Finden Sie die echte USB-Konversation schnell und inspizieren Sie dann die Bus-Level-Evidence, die erklärt, warum das Device läuft, stalled, resettet oder verschwindet.