USBPcap vs usbmon : choisir un chemin de capture USB pour le diagnostic terrain

Le diagnostic USB commence souvent par une question de plateforme: "capturons-nous sous Linux ou sous Windows ? La réponse compte car le chemin de capture est différent. Linux utilise couramment usbmon. Windows utilise couramment USBPcap. Les deux peuvent supporter des diagnostics terrain utiles, mais ils viennent avec des hypothèses de configuration, permissions, comportement de pilote et modes de défaillance différents." Réponse rapide: "utilisez USBPcap quand le bug ne se reproduit que sur un hôte, une pile de pilotes ou une machine client Windows. Utilisez usbmon quand vous contrôlez une machine de laboratoire Linux, avez besoin de moins de friction de configuration, ou voulez une capture répétable depuis des benches CI et des systèmes de validation embarquée. Utilisez les deux quand Windows et Linux sont en désaccord — ce désaccord est souvent la preuve."

Que capturer d'abord

Ne commencez pas par filtrer trop agressivement. Pour le travail firmware USB, la première capture doit inclure l'énumération et le premier transfert au niveau applicatif après la configuration. Si vous commencez après que le périphérique est déjà configuré, vous pouvez manquer le descripteur exact ou la requête de classe qui explique la défaillance.

Preuves minimales :

• timing de connexion / reset / rattachement
• descripteurs périphérique, configuration, interface, endpoint, BOS, HID, CDC, MSC ou vendor
• champs du setup packet pour les transferts de contrôle
• adresse d'endpoint, direction et type de transfert
• marqueurs status / stall / timeout / paquet court
• octets de payload bruts pour le transfert défaillant
• contexte de plateforme hôte et de liaison de pilote

Le point important n'est pas de savoir quelle plateforme est « meilleure ». Le point important est de savoir si la capture préserve assez de preuves pour expliquer le comportement du périphérique.

Ce qu'une capture USB doit préserver

Pour le débogage firmware et hardware, une capture utile conserve :

• contexte bus et périphérique
• adresse et direction d'endpoint
• type de transfert
• champs du setup packet
• réponses de descripteurs
• indications de statut et d'erreur
• octets de payload bruts
• ordre de timing
• assez de métadonnées pour relier les paquets à un périphérique

Sans cette structure, une capture devient un dump d'octets difficile à défendre dans un cas de support.

Linux usbmon

Sous Linux, usbmon expose le trafic USB depuis le noyau. C'est utile pour les équipes firmware car Linux est souvent disponible dans les laboratoires, benches CI et environnements de validation embarquée. Cela évite aussi une partie de la complexité de liaison de pilotes Windows quand l'objectif est d'observer l'énumération et les transferts.

Vérification de configuration typique :

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

Si l'outil de capture ne peut pas voir usbmon, vérifiez que debugfs est monté et que l'utilisateur a la permission de lire les endpoints monitor. Ne traitez pas un échec de permission comme « pas de trafic USB » ; cela signifie seulement que l'hôte n'a pas exposé la source de capture.

Questions Linux typiques :

• l'utilisateur a-t-il la permission de capturer ?
• sur quel bus est le périphérique ?
• l'énumération s'est-elle arrêtée avant la configuration ?
• les requêtes spécifiques à la classe arrivent-elles ?
• les endpoints déplacent-ils des données après la configuration ?

Si Linux montre une énumération et des transferts propres, mais que Windows échoue, le suspect suivant peut être la liaison de pilote Windows, la configuration INF, l'installation USBPcap ou la compatibilité de classe.

Windows USBPcap

Sous Windows, USBPcap est un chemin de pilote de capture courant pour le trafic USB. C'est précieux car beaucoup de clients ne reproduisent les problèmes de périphérique que sur des hôtes Windows. Si le produit est un périphérique firmware, ignorer les preuves Windows peut faire manquer la vraie défaillance terrain.

Le risque spécifique Windows est la portée de capture. USBPcap capture depuis un concentrateur racine sélectionné. Si le périphérique est sur un autre contrôleur ou hub, la capture peut être parfaitement vide pendant que le périphérique est occupé ailleurs. Confirmez le concentrateur racine avant de conclure que le firmware est silencieux.

Questions Windows typiques :

• USBPcap est-il installé et actif ?
• quel concentrateur racine faut-il capturer ?
• le périphérique s'est-il lié au pilote attendu ?
• l'énumération s'est-elle terminée avant que l'application n'ouvre le périphérique ?
• y a-t-il des requêtes de classe ou des transferts bulk/interrupt après la liaison ?

Les captures Windows sont particulièrement utiles quand le problème apparaît seulement avec une pile de pilotes ou un environnement applicatif spécifique.

Comparer les captures, ne pas les fusionner

Si le même périphérique USB se comporte différemment sur Linux et Windows, cette différence est une preuve. Ne la réduisez pas à « USB est flaky ». Comparez :

• requêtes de descripteurs
• configuration sélectionnée
• requêtes spécifiques à la classe
• trafic d'endpoint après setup
• statuts d'erreur
• timing autour du reset et du rattachement

La comparaison peut montrer que le firmware est sensible à la plateforme, qu'un hôte rejette un descripteur que l'autre tolère, ou que la couche applicative échoue après que le setup USB ait déjà réussi.

Où Bus Scope s'inscrit

Bus Scope est un atelier de capture et d'inspection USB construit autour des preuves. Ce n'est pas un analyseur réseau générique et il n'essaie pas d'absorber tous les domaines de protocole. Son job est de rendre les captures USB plus faciles à inspecter, filtrer, enregistrer et expliquer.

Pour les flux usbmon et USBPcap, Bus Scope doit aider les équipes à :

• identifier l'adaptateur de capture et le contexte du périphérique
• inspecter les setup packets et descripteurs
• décoder les preuves pertinentes par classe quand c'est supporté
• garder les octets bruts liés aux champs interprétés
• enregistrer les sessions .bscope pour rejeu et transmission

Quand le rapport terrain dit « le périphérique échoue sur Windows mais marche sur Linux », l'étape suivante ne devrait pas être le tâtonnement. Elle devrait être la comparaison des preuves de capture.