Filtres USB Wireshark : trouver le bon périphérique avec USBPcap, usbmon et Bus Scope

Les captures USB peuvent devenir écrasantes rapidement. Une machine peut avoir un clavier, une souris, une webcam, un adaptateur Bluetooth, un périphérique de stockage, un adaptateur série, une clé de sécurité et un hub interne actifs en même temps. Quand les utilisateurs cherchent « Wireshark USB filter », « USBPcap filter device », « usbmon filter endpoint » ou « how to find my USB device in capture », ils ont généralement le même problème: "la capture contient trop de trafic et pas assez de structure." Bus Scope est construit pour rendre l'inspection USB plus directe, mais comprendre le problème de filtrage reste utile. Que la capture vienne d'USBPcap sur Windows, d'usbmon sur Linux ou d'une autre source de capture USB, la clé est d'identifier le périphérique puis de restreindre la trace par adresse, endpoint, type de transfert et requête de contrôle.

Commencer par l'énumération

La façon la plus simple d'identifier un périphérique USB est de capturer depuis le branchement. L'énumération contient des descripteurs qui nomment le périphérique, le vendor ID, le product ID, les configurations, interfaces, endpoints et détails spécifiques à la classe.

Cherchez :

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

Si vous démarrez la capture après que le périphérique tourne déjà, vous ne verrez peut-être que le trafic d'endpoint sans le contexte des descripteurs. Cela rend le filtrage plus dur car les numéros d'endpoint seuls ne suffisent pas.

L'adresse du périphérique peut changer

Les adresses de périphérique USB sont attribuées par l'hôte pendant l'énumération. Si le périphérique se déconnecte et se reconnecte, l'adresse peut changer. Un filtre qui marchait pour la première connexion peut manquer la seconde connexion.

Cela compte pour le débogage des reset loops. Si un périphérique se ré-énumère en boucle, vous pouvez avoir besoin de suivre plusieurs adresses dans une seule capture. Les descripteurs product/vendor révèlent que ces adresses appartiennent au même périphérique physique.

Bus Scope aide à garder cette relation visible au lieu de vous forcer à reconstituer mentalement les changements d'adresse.

Filtrer par endpoint

Après la configuration, la plupart du trafic de données utilise des endpoints. L'endpoint zéro est control. Les autres endpoints peuvent être bulk, interrupt ou isochrone.

Significations courantes des endpoints :

• 0x00 : control OUT sur l'endpoint zéro
• 0x80 : control IN sur l'endpoint zéro
• 0x81 : endpoint 1 IN
• 0x01 : endpoint 1 OUT
• 0x82 : endpoint 2 IN
• 0x02 : endpoint 2 OUT

Le bit de direction compte. 0x81 et 0x01 ne sont pas la même direction d'endpoint. Un adaptateur série, par exemple, peut utiliser un endpoint bulk OUT pour les données hôte-vers-périphérique et un endpoint bulk IN pour les données périphérique-vers-hôte.

Les filtres d'endpoint sont utiles une fois que vous savez quel endpoint porte le trafic qui vous intéresse.

Filtrer par type de transfert

Différents problèmes USB vivent dans différents types de transferts :

• Transferts control : descripteurs, configuration, requêtes de classe, commandes vendor.
• Transferts bulk : stockage, données série, données vendor, beaucoup de périphériques de capture.
• Transferts interrupt : entrée HID, notifications de statut, rapports basse latence.
• Transferts isochrones : audio, vidéo, streaming sensible au timing.

Si un périphérique série USB s'ouvre mais n'envoie pas de données, inspectez les transferts control pour le line coding et l'état des lignes de contrôle, puis les endpoints bulk pour le payload. Si une webcam démarre mais que la vidéo est corrompue, inspectez les transferts isochrones et les alternate settings. Si un périphérique HID se comporte mal, inspectez les transferts interrupt et les descripteurs de rapport.

Filtrer par type de transfert réduit le bruit tout en gardant la classe de preuve pertinente.

Filtrer par setup packet

Les transferts control incluent des setup packets. Les setup packets sont extrêmement utiles car ils identifient la direction de la requête, le type, le destinataire, le code de requête, la valeur, l'index et la longueur.

Exemples importants :

• 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
• Commandes vendor-specific

Quand un périphérique échoue pendant le setup, le setup packet vous dit souvent exactement quelle requête a déclenché le problème.

Sélection de capture USBPcap sous Windows

Sous Windows, USBPcap capture depuis les contrôleurs hôtes USB. Si une machine a plusieurs contrôleurs, choisir le mauvais peut produire une capture sans trafic du périphérique cible.

Un flux pratique :

1. Débranchez le périphérique cible.
2. Démarrez la capture sur le contrôleur probable.
3. Branchez le périphérique.
4. Cherchez les descripteurs d'énumération.
5. Si rien n'apparaît, essayez une autre capture de contrôleur.
6. Une fois le périphérique trouvé, gardez la capture comme référence.

La valeur de Bus Scope est de rendre ce flux moins opaque : la cible est la conversation USB du périphérique, pas juste une énorme liste de paquets.

Capture usbmon sous Linux

Sous Linux, usbmon expose le trafic du bus USB. Le numéro de bus compte. Un périphérique listé comme Bus 003 Device 012 appartient au bus 3 à ce moment-là. Après reconnexion, le numéro de périphérique peut changer.

La capture la plus utile démarre avant le branchement, car l'énumération révèle l'identité du périphérique. Si une permission bloque la capture, résolvez-la d'abord ; sinon vous ne verrez que la défaillance applicative et jamais la preuve USB.

Erreurs de filtrage courantes

Évitez ces erreurs :

• Filtrer seulement après la défaillance, en manquant l'énumération.
• Supposer que l'adresse du périphérique est stable entre les reconnexions.
• Confondre la direction de l'endpoint.
• Ignorer le trafic de contrôle de l'endpoint zéro.
• Ne regarder que les paquets de payload et manquer les requêtes de classe.
• Traiter toutes les requêtes vendor-specific comme du bruit.
• Filtrer les resets et erreurs trop tôt.
• Ignorer le contexte de hub et de port.

Un filtre propre n'est utile que s'il préserve la défaillance.

Que garder dans une capture d'investigation

Pour un rapport partageable avec une équipe firmware, pilote ou QA, gardez :

• L'énumération initiale.
• Les descripteurs du périphérique cible.
• La configuration et interface sélectionnées par l'hôte.
• Les requêtes spécifiques à la classe ou vendor avant la défaillance.
• Le trafic d'endpoint impliqué dans la défaillance.
• L'événement de reset, stall, timeout ou déconnexion.
• Assez de contexte de timing pour montrer si la défaillance est immédiate, liée à l'inactivité, ou liée à la charge.

Cette preuve est plus forte qu'une capture d'écran de « device not recognized ».

Diagnostic final

Le filtrage USB n'est pas qu'une question de masquer le bruit. C'est préserver la séquence de paquets qui explique la défaillance. Commencez par l'énumération, identifiez le périphérique, suivez les changements d'adresse, restreignez par endpoint et type de transfert, et gardez les requêtes de contrôle visibles.

Bus Scope est censé supporter ce flux : trouver rapidement la vraie conversation USB, puis inspecter la preuve au niveau bus qui explique pourquoi le périphérique marche, stall, reset ou disparaît.