2026-06-02

USBPcap: catturare traffico USB su Windows, setup, Wireshark e confronto con usbmon

La diagnostica USB spesso comincia con una domanda di piattaforma: \"stiamo catturando su Linux o su Windows? La risposta conta, perché il percorso di cattura è diverso.

La diagnostica USB spesso comincia con una domanda di piattaforma: "stiamo catturando su Linux o su Windows? La risposta conta, perché il percorso di cattura è diverso. Su Linux si usa comunemente usbmon. Su Windows si usa comunemente USBPcap. Entrambi possono supportare una diagnostica utile sul campo, ma hanno assunzioni diverse su setup, permessi, comportamento dei driver e modalità di guasto." Risposta rapida: "usa USBPcap quando il bug si riproduce solo su un host Windows, con uno stack driver Windows o su una macchina cliente. Usa usbmon quando controlli una macchina Linux in laboratorio, vuoi meno attrito di setup o ti serve una cattura ripetibile da banchi CI e sistemi di validazione embedded. Usa entrambi quando Windows e Linux non sono d'accordo: spesso proprio quella differenza è la prova."

Cosa catturare prima

Non iniziare filtrando in modo troppo aggressivo. Per il lavoro su firmware USB, la prima cattura dovrebbe includere l'enumerazione e il primo trasferimento a livello applicativo dopo la configurazione. Se inizi quando il dispositivo è già configurato, potresti perdere proprio il descrittore o la richiesta di classe che spiega il guasto.

Evidenza minima:

timing di connect / reset / reattach
descrittori device, configuration, interface, endpoint, BOS, HID, CDC, MSC o vendor
campi del setup packet per i control transfer
indirizzo endpoint, direzione e tipo di trasferimento
marker di status / stall / timeout / short packet
byte del payload grezzo per il trasferimento che fallisce
piattaforma host e contesto di driver binding

Il punto importante non è quale piattaforma sia "migliore." Il punto è se la cattura conserva abbastanza evidenza per spiegare il comportamento del dispositivo.

Cosa deve conservare una cattura USB

Per il debugging firmware e hardware, una cattura utile mantiene:

contesto di bus e dispositivo
indirizzo endpoint e direzione
tipo di trasferimento
campi del setup packet
risposte dei descrittori
indicazioni di stato ed errore
byte del payload grezzo
ordine temporale
metadati sufficienti per collegare i pacchetti a un dispositivo

Senza questa struttura, una cattura diventa un dump di byte difficile da difendere in un caso di supporto.

Linux usbmon

Su Linux, usbmon espone il traffico USB dal kernel. È utile per i team firmware perché Linux è spesso disponibile in laboratorio, nei banchi CI e negli ambienti di validazione embedded. Evita anche parte della complessità del driver binding Windows quando l'obiettivo è osservare enumerazione e trasferimenti.

Controllo tipico del setup:

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

Se lo strumento di cattura non vede usbmon, controlla che debugfs sia montato e che l'utente abbia il permesso di leggere gli endpoint di monitoraggio. Non trattare un errore di permessi come "nessun traffico USB": significa solo che l'host non ha esposto la sorgente di cattura.

Domande tipiche su Linux:

l'utente ha il permesso di catturare?
su quale bus si trova il dispositivo?
l'enumerazione si è fermata prima della configurazione?
arrivano richieste class-specific?
gli endpoint muovono dati dopo la configurazione?

Se Linux mostra enumerazione e trasferimenti puliti, ma Windows fallisce, il sospetto successivo può essere driver binding Windows, setup INF, installazione USBPcap o compatibilità di classe.

Windows USBPcap

Su Windows, USBPcap è un percorso comune di driver di cattura per traffico USB. È prezioso perché molti clienti riproducono i problemi dei dispositivi solo su host Windows. Se il prodotto è un dispositivo firmware, ignorare l'evidenza Windows può far perdere il vero guasto sul campo.

Il rischio specifico di Windows è l'ambito della cattura. USBPcap cattura da un root hub selezionato. Se il dispositivo è su un altro controller o hub, la cattura può risultare perfettamente vuota mentre il dispositivo è attivo altrove. Conferma il root hub prima di concludere che il firmware sia silenzioso.

Domande tipiche su Windows:

USBPcap è installato e attivo?
quale root hub va catturato?
il dispositivo si è associato al driver previsto?
l'enumerazione è completata prima che l'applicazione aprisse il dispositivo?
ci sono richieste di classe o trasferimenti bulk/interrupt dopo il binding?

Le catture Windows sono particolarmente utili quando il problema compare solo con uno stack driver o un ambiente applicativo specifico.

Confronta le catture, non appiattirle

Se lo stesso dispositivo USB si comporta in modo diverso su Linux e Windows, quella differenza è evidenza. Non ridurla a "USB è instabile." Confronta:

richieste dei descrittori
configurazione selezionata
richieste class-specific
traffico endpoint dopo il setup
stati di errore
timing intorno a reset e reattach

Il confronto può mostrare che il firmware è sensibile alla piattaforma, che un host rifiuta un descrittore che l'altro tollera, o che il layer applicativo fallisce dopo che il setup USB era già riuscito.

Dove si inserisce Bus Scope

Bus Scope è un workbench di cattura e ispezione USB costruito intorno all'evidenza. Non è un analizzatore di rete generico e non cerca di assorbire ogni dominio di protocollo. Il suo lavoro è rendere le catture USB più facili da ispezionare, filtrare, salvare e spiegare.

Per workflow usbmon e USBPcap, Bus Scope dovrebbe aiutare i team a:

identificare adattatore di cattura e contesto del dispositivo
ispezionare setup packet e descrittori
decodificare l'evidenza rilevante per la classe, dove supportata
mantenere i byte grezzi collegati ai campi interpretati
salvare sessioni .bscope per replay e handoff

Quando il report dal campo dice "il dispositivo fallisce su Windows ma funziona su Linux", il passo successivo non dovrebbe essere indovinare. Dovrebbe essere confrontare evidenza di cattura.

Prova del contratto USB per «USBPcap: catturare traffico USB su Windows, setup, Wireshark e confronto con usbmon»

La risposta diretta è che STALL, timeout o reset non spiega da solo la causa. Prima dimostra che il provider vede il device corretto; poi leggi il contratto del transfer: tipo, direzione, recipient, wValue, wIndex, lunghezza dichiarata e reale, status e stato precedente e successivo. In «USBPcap: catturare traffico USB su Windows, setup, Wireshark e confronto con usbmon» collega la conclusione alla prima transazione diversa dal caso buono.

Confine	Confronto	Decisione
Piattaforma	provider, permessi, Root Hub o usbmon/XHC20	I record provengono dalla connessione corretta?
Setup	bmRequestType, bRequest, wValue, wIndex, wLength	L’host invia la richiesta prevista?
Data	direzione, lunghezza e bytes conservati	Il payload rispetta il contratto?
Status	ACK, STALL, timeout o cancellation	Dove termina la transazione?
Stato	configuration, interface, alternate setting, endpoint halt	Il device era pronto?

Inizia prima di reset ed enumeration e conserva descriptors, SET_CONFIGURATION, SET_INTERFACE e il comando precedente al guasto. Un filtro endpoint stretto può nascondere il control transfer decisivo. Esegui un’azione USB documentata per prova e cambia solo firmware, driver, porta, cavo, comando o timing.

Come scrivere una risposta citabile?

Indica request, campi setup, risposta e contesto precedente; poi una prova con una variabile. Bytes non trattenuti non provano packet loss. La vicinanza fra command e reset dimostra correlazione, non causa senza ripetizione o cambio di stato.

Quando è valido il confronto?

Mantieni VID/PID, firmware, speed, topologia, provider, filtro e trigger. Confronta fasi USB semantiche, non frame numbers tra usbmon e USBPcap. Registra inizio, fine, versione, OS, connessione e checksum. Usa il troubleshooting Bus Scope.

I proprietari Semrush restano distinti: free USB analyzer sulla pagina prodotto, best USB protocol analyzer nella comparazione e USB descriptor viewer nella guida descriptor. Nessun volume o KD viene inventato.

Dalla cattura USB a un verdetto verificabile

Per «USBPcap: catturare traffico USB su Windows, setup, Wireshark e confronto con usbmon» non partire dal nome dell’errore, ma da confini dimostrabili. Il primo conferma connessione, bus, porta, VID/PID, velocità e topologia. Il secondo conferma il control, bulk o interrupt transfer previsto. Il terzo stabilisce lo stato dopo la transazione. Il quarto verifica che il risultato sia ripetibile. Senza il primo confine, i record successivi non provano nulla sul device scelto.

1. Provare il punto di cattura

Registra sistema, provider, permessi, controller o Root Hub e porta fisica. Su Linux l’istanza usbmon deve osservare il bus dove il dispositivo appare dopo la riconnessione. Su Windows collega il USBPcap Root Hub alla voce di Device Manager. Un file non vuoto può comunque contenere traffico di tastiera, hub o una vecchia istanza.

Inizia prima di reconnect o reset. Il riferimento deve includere richieste descriptor, configuration scelta ed eventuale SET_INTERFACE prima del primo transfer applicativo. Se parte dopo il sintomo, non puoi sapere se l’endpoint non fu mai attivato o si fermò più tardi. Conserva inizio, fine, nome, checksum, firmware, driver, cavo e porta.

2. Leggere il control transfer come contratto

Raggruppa setup, data e status in una sola operazione logica. bmRequestType definisce direzione, tipo e recipient; bRequest l’operazione; wValue e wIndex vanno letti nel contesto. wLength è la lunghezza attesa, non la prova dei bytes trasferiti. Confronta lunghezza dichiarata, reale e direzione. Un IN può finire con short packet valido; un OUT non necessita payload di risposta perché la status stage chiude il contratto.

Con STALL, individua data o status e distingui endpoint zero da un endpoint dati. Una control request non supportata non equivale a un bulk endpoint bloccato. Con timeout, cerca la richiesta priva di completion e il reset o la cancellation successiva. Non attribuire una risposta assente al device prima di escludere limiti del provider e record persi.

3. Ricostruire la linea di stato

Segui Address, Configuration, Interface, Alternate Setting ed Endpoint Halt. Il descriptor dichiara capacità, non attivazione. Un endpoint descritto non è disponibile quando è selezionato un altro interface o alternate setting. Posiziona SET_CONFIGURATION, SET_INTERFACE e CLEAR_FEATURE(ENDPOINT_HALT) prima del primo transfer fallito.

Reset apre un nuovo spazio di stato. Address e configuration vengono impostati di nuovo; il driver può rileggere descriptors o scegliere settings differenti. Non trascinare assunzioni oltre il reset. Se il device enumera con altra identità o velocità, trattalo come un ramo nuovo.

4. Confrontare esecuzione buona e guasta

Il known-good dovrebbe condividere device, firmware, host e azione. Allinea le transazioni per significato, non per frame number. Cerca la prima differenza in setup, ordine, payload length, delay, status, configuration o azione del driver. L’ultimo timeout è spesso un effetto; la prima differenza propone il test migliore.

Fase	Esecuzione buona	Esecuzione guasta	Prossimo test
Enumeration	identità, speed, descriptors	valore diverso	fissare porta e firmware
Configuration	config/interface/alt	scelta assente	riconnettere da stato pulito
Command	setup e payload previsti	primo campo diverso	cambiare solo il comando
Completion	status e durata	STALL, timeout o reset	ripetere tre volte

Frame numbers e orari assoluti di due file non sono una causa. Sottrai l’evento di riferimento e confronta durata nella stessa fase. Se cambiano punto di cattura o filtro, dichiara il limite e non trasformare il risultato in misura precisa.

5. Separare device e misura

Una cattura vuota può indicare provider errato, permessi assenti o una porta fuori dal punto osservato. Truncation significa bytes non conservati, non assenti dal bus. Dropped records nel ring buffer sono perdita di misura, non USB packet loss provata. Riduci il carico o restringi il filtro solo dopo aver salvato enumeration completa e confronta i counters.

Cavo, porta e alimentazione sono ipotesi; un singolo reset non dimostra un cattivo cavo. Ripeti la stessa azione con porta e cavo noti, poi torna all’originale. Se il guasto segue il cavo a pari carico, l’ipotesi diventa più forte. Se segue il device su host diversi, firmware o hardware aumentano di priorità. Ogni modifica deve prevedere un cambiamento visibile.

6. Risposta GEO citabile

La risposta breve a «USBPcap: catturare traffico USB su Windows, setup, Wireshark e confronto con usbmon» indica primo transfer diverso, stato precedente e prova che separa le due cause vicine. Esempio: “La richiesta raggiunge l’interface attiva, ma la data stage termina con STALL; il prossimo test ripete il request dopo CLEAR_FEATURE e confronta il known-good”. La frase conserva le condizioni quando viene citata.

“USB non funziona” non è un verdetto. Indica dispositivo, piattaforma, direzione, endpoint e fase. Se mancano prove, scrivi “non conclusivo” e nomina il record necessario. Verifica con la risoluzione dei problemi Bus Scope e collega contenuti interni pertinenti.