USBPcap vs. usbmon: Den richtigen USB-Capture-Pfad für Felddiagnose wählen

USB-Diagnose beginnt oft mit einer Plattform-Frage: "Capturen wir unter Linux oder Windows? Die Antwort zählt, weil der Capture-Pfad unterschiedlich ist. Linux nutzt üblicherweise usbmon. Windows nutzt üblicherweise USBPcap. Beide können nützliche Felddiagnose unterstützen, aber sie kommen mit unterschiedlichen Setup-Annahmen, Berechtigungen, Treiber-Verhalten und Fehlermodi." Schnelle Antwort: "Nutzen Sie USBPcap, wenn der Bug nur auf einem Windows-Host, Treiber-Stack oder Kunden-Maschine reproduziert. Nutzen Sie usbmon, wenn Sie eine Linux-Lab-Maschine kontrollieren, weniger Setup-Reibung brauchen oder wiederholbare Captures von CI-Benches und Embedded-Validation-Systemen wollen. Nutzen Sie beide, wenn Windows und Linux uneinig sind – diese Uneinigkeit ist oft die Evidence."

Was zuerst capturen

Filtern Sie nicht zu früh aggressiv. Für USB-Firmware-Arbeit sollte der erste Capture Enumeration und den ersten App-Level-Transfer nach der Konfiguration enthalten. Starten Sie, nachdem das Gerät bereits konfiguriert ist, verpassen Sie möglicherweise den exakten Deskriptor- oder Klassen-Request, der den Fehler erklärt.

Minimum-Evidence:

• Connect / Reset / Reattach-Timing
• Device-, Configuration-, Interface-, Endpoint-, BOS-, HID-, CDC-, MSC- oder Vendor-Deskriptoren
• Setup-Paket-Felder für Control-Transfers
• Endpoint-Adresse, Richtung und Transfer-Typ
• Status / Stall / Timeout / Short-Packet-Marker
• Roh-Payload-Bytes für den fehlgeschlagenen Transfer
• Host-Plattform und Treiberbindungs-Kontext

Der wichtige Punkt ist nicht, welche Plattform "besser" ist. Der wichtige Punkt ist, ob der Capture genug Evidence bewahrt, um das Device-Verhalten zu erklären.

Was ein USB-Capture bewahren muss

Für Firmware- und Hardware-Debugging behält ein nützlicher Capture:

• Bus- und Device-Kontext
• Endpoint-Adresse und Richtung
• Transfer-Typ
• Setup-Paket-Felder
• Deskriptor-Antworten
• Status- und Error-Indikationen
• Roh-Payload-Bytes
• Timing-Reihenfolge
• genug Metadaten, um Pakete einem Gerät zuzuordnen

Ohne diese Struktur wird ein Capture zu einem Byte-Dump, der in einem Support-Case schwer zu verteidigen ist.

Linux usbmon

Unter Linux legt usbmon USB-Traffic aus dem Kernel offen. Es ist für Firmware-Teams nützlich, weil Linux oft in Labs, CI-Benches und Embedded-Validation-Umgebungen verfügbar ist. Es vermeidet auch einige Windows-Treiberbindungs-Komplexität, wenn das Ziel ist, Enumeration und Transfers zu beobachten.

Typischer Setup-Check:

sudo modprobe usbmon
ls /sys/kernel/debug/usb/usbmon

Kann das Capture-Tool usbmon nicht sehen, prüfen Sie, ob debugfs gemountet ist und der Benutzer Berechtigung hat, die Monitor-Endpoints zu lesen. Behandeln Sie einen Berechtigungs-Fehler nicht als "kein USB-Traffic"; es bedeutet nur, dass der Host die Capture-Quelle nicht exponiert hat.

Typische Linux-Fragen:

• Hat der Benutzer Berechtigung zum Capturen?
• An welchem Bus ist das Gerät?
• Ist die Enumeration vor der Konfiguration gestoppt?
• Kommen klassenspezifische Requests an?
• Bewegen Endpoints nach der Konfiguration Daten?

Zeigt Linux saubere Enumeration und Transfers, scheitert aber Windows, ist der nächste Verdächtige möglicherweise Windows-Treiberbindung, INF-Setup, USBPcap-Installation oder Klassen-Kompatibilität.

Windows USBPcap

Unter Windows ist USBPcap ein üblicher Capture-Treiber-Pfad für USB-Traffic. Er ist wertvoll, weil viele Kunden Device-Issues nur auf Windows-Hosts reproduzieren. Wenn das Produkt ein Firmware-Device ist, kann das Ignorieren von Windows-Evidence den eigentlichen Feld-Fehler verfehlen.

Das Windows-spezifische Risiko ist der Capture-Scope. USBPcap capturt von einem ausgewählten Root-Hub. Ist das Gerät an einem anderen Controller oder Hub, kann der Capture perfekt leer sein, während das Gerät anderswo aktiv ist. Bestätigen Sie den Root-Hub, bevor Sie schließen, dass die Firmware still ist.

Typische Windows-Fragen:

• Ist USBPcap installiert und aktiv?
• Welcher Root-Hub sollte capturt werden?
• Hat das Gerät den erwarteten Treiber gebunden?
• Ist die Enumeration abgeschlossen, bevor die App das Device geöffnet hat?
• Gibt es Klassen-Requests oder Bulk/Interrupt-Transfers nach dem Binding?

Windows-Captures sind besonders nützlich, wenn das Issue nur mit einem bestimmten Treiber-Stack oder einer App-Umgebung auftritt.

Captures vergleichen, nicht kollabieren

Verhält sich dasselbe USB-Gerät unter Linux und Windows unterschiedlich, ist dieser Unterschied Evidence. Kollabieren Sie das nicht in "USB ist flaky". Vergleichen Sie:

• Deskriptor-Requests
• gewählte Konfiguration
• klassenspezifische Requests
• Endpoint-Traffic nach Setup
• Error-Statuses
• Timing rund um Reset und Reattach

Der Vergleich kann zeigen, dass die Firmware plattformsensitiv ist, dass ein Host einen Deskriptor ablehnt, den ein anderer toleriert, oder dass die App-Layer bereits nach erfolgreichem USB-Setup scheitert.

Wo Bus Scope passt

Bus Scope ist eine USB-Capture- und Inspektions-Workbench, die um Evidence gebaut ist. Sie ist kein generischer Netzwerk-Analysator und versucht nicht, jede Protokoll-Domain zu absorbieren. Ihre Aufgabe ist es, USB-Captures einfacher zu inspizieren, zu filtern, zu speichern und zu erklären.

Für usbmon- und USBPcap-Workflows hilft Bus Scope Teams:

• Capture-Adapter und Device-Kontext identifizieren
• Setup-Pakete und Deskriptoren inspizieren
• klassen-relevante Evidence dekodieren, wo unterstützt
• Rohbytes mit interpretierten Feldern verbunden halten
• .bscope-Sessions für Replay und Handoff speichern

Sagt der Feld-Report "Gerät scheitert unter Windows, läuft unter Linux", sollte der nächste Schritt nicht Raten sein. Es sollte Vergleichen von Capture-Evidence sein.