WireShark riporta le spiegazioni

Sto cercando di decodificare un dispositivo USB (HID) e non riesco davvero a capire come ciò che vedo su WireShark (USBmon + WireShark su Linux o Windows) si collega al protocollo USB ?. Ho esaminato il protocollo USB da www.usb.org.

Cosa mostra WireShark?

1) Una riga per pacchetto? (token, dati, stretta di mano)

2) Una riga per transazione? (token + [dati] + stretta di mano) (la mia ipotesi)

3) Una linea per trasferimento di controllo?

Anche la direzione della transazione è molto strana (da / verso i campi). Almeno, non corrisponde alle mie aspettative :-) ... E la parte dei dati dell'enumerazione, il rapporto nascosto ecc ... a volte sembra essere visualizzata con i dati di installazione (8 byte) e qualche volta no ... so davvero cosa sia URB ... non c'è menzione di ciò nel protocollo USB per quanto ho potuto vedere ... Mi sembra che la traccia di wirehark / usbmon ad un livello di stack più alto e cerchi di dedurre cosa sarebbe sul filo da quello ...

Di seguito è riportato un esempio di ciò che posso vedere, cosa vediamo qui?

a) Non sono riuscito a trovare nemmeno bmtype = 0x20 (del setup, frame No = 599) nelle specifiche.

b) Poiché ho un dispositivo HID, ho pensato che potesse essere una configurazione di report / funzionalità (l'enumerazione viene passata in questa fase). Quindi potrei essere d'accordo con la direzione (host-> dispositivo). ma dove sono i dati? O non ci sono fasi di dati qui? Cos'è quindi il frame 600?

c) cos'è il frame 600? i dati?

d) cos'è il frame 601? uno stato ACK? ... ma poi i dati e ACK hanno la stessa fonte?

No.     Time        Source                Destination           Protocol Length Info
    599 67.996889   host                  2.0                   USB      36     URB_CONTROL out

Frame 599: 36 bytes on wire (288 bits), 36 bytes captured (288 bits)
USB URB
    USBPcap pseudoheader length: 28
    IRP ID: 0xfffffa800a1e2610
    IRP USBD_STATUS: USBD_STATUS_SUCCESS (0x00000000)
    URB Function: URB_FUNCTION_CLASS_DEVICE (0x001a)
    IRP information: 0x00, Direction: FDO -> PDO
    URB bus id: 1
    Device address: 2
    Endpoint: 0x00, Direction: OUT
    URB transfer type: URB_CONTROL (0x02)
    Packet Data Length: 8
    Control transfer stage: Setup (0)
    [Response in: 601]
    [bInterfaceClass: Unknown (0xffff)]
URB setup
    bmRequestType: 0x20
        0... .... = Direction: Host-to-device
        .01. .... = Type: Class (0x01)
        ...0 0000 = Recipient: Device (0x00)
    bRequest: 0
    wValue: 0x0000
    wIndex: 0
    wLength: 16

0000  1c 00 10 26 1e 0a 80 fa ff ff 00 00 00 00 1a 00   ...&............
0010  00 01 00 02 00 00 02 08 00 00 00 00 20 00 00 00   ............ ...
0020  00 00 10 00                                       ....

No.     Time        Source                Destination           Protocol Length Info
    600 67.997889   2.0                   host                  USB      44     URB_CONTROL out

Frame 600: 44 bytes on wire (352 bits), 44 bytes captured (352 bits)
USB URB
    USBPcap pseudoheader length: 28
    IRP ID: 0xfffffa800a1e2610
    IRP USBD_STATUS: USBD_STATUS_SUCCESS (0x00000000)
    URB Function: URB_FUNCTION_CONTROL_TRANSFER (0x0008)
    IRP information: 0x01, Direction: PDO -> FDO
    URB bus id: 1
    Device address: 2
    Endpoint: 0x00, Direction: OUT
    URB transfer type: URB_CONTROL (0x02)
    Packet Data Length: 16
    Control transfer stage: Data (1)
    [Request in: 599]
    [Time from request: 0.001000000 seconds]
    [bInterfaceClass: Unknown (0xffff)]
CONTROL response data

0000  1c 00 10 26 1e 0a 80 fa ff ff 00 00 00 00 08 00   ...&............
0010  01 01 00 02 00 00 02 10 00 00 00 01 05 04 0d 56   ...............V
0020  fb 82 c0 1d 10 18 cc 02 00 00 00 01               ............

No.     Time        Source                Destination           Protocol Length Info
    601 67.997889   2.0                   host                  USB      28     GET STATUS Status

Frame 601: 28 bytes on wire (224 bits), 28 bytes captured (224 bits)
USB URB
    USBPcap pseudoheader length: 28
    IRP ID: 0xfffffa800a1e2610
    IRP USBD_STATUS: USBD_STATUS_SUCCESS (0x00000000)
    URB Function: URB_FUNCTION_CONTROL_TRANSFER (0x0008)
    IRP information: 0x01, Direction: PDO -> FDO
    URB bus id: 1
    Device address: 2
    Endpoint: 0x00, Direction: OUT
    URB transfer type: URB_CONTROL (0x02)
    Packet Data Length: 0
    Control transfer stage: Status (2)
    [Request in: 599]
    [Time from request: 0.001000000 seconds]

0000  1c 00 10 26 1e 0a 80 fa ff ff 00 00 00 00 08 00   ...&............
0010  01 01 00 02 00 00 02 00 00 00 00 02               ............

Ovviamente mi manca qualcosa. Una spiegazione generale su come il display WireShark si collega al protocollo e, (basato su di esso), il significato della traccia sopra è accolto favorevolmente!

Originariamente l'ho pubblicato su Stack Overflow, ma mi è stato detto che non era direttamente una domanda di programmazione. Spero che vada meglio qui.

Un URB USB è come un pacchetto IP e un endpoint USB è come una porta IP. Gli endpoint USB 0x00-0x7F si trovano sull'host e gli endpoint 0x80-0xFF si trovano sul dispositivo (credo). Pertanto, l'endpoint codifica la direzione del trasferimento. lsusbti mostrerà quali endpoint e quali tipi di trasferimento supporta un dispositivo.

Userò "pacchetti" tra virgolette per indicare l'unità di attività catturata da WireShark. Questi non sono letteralmente ciò che viene inviato sul filo. Ad esempio, i "pacchetti" avranno i timestamp per l'inizio dei trasferimenti, anche se questo non viene trasmesso sul bus USB.

Penso che l'aspetto più confuso di sniffare il protocollo USB sia che vedi due "pacchetti" di Wireshark per ogni USB URB. Quando l'host avvia un trasferimento, si tratta di un URB_SUBMIT(filtro di visualizzazione di Wireshark usb.urb_type == URB_SUBMIT). Al termine del trasferimento, si tratta di un URB_COMPLETE(filtro di visualizzazione di Wireshark usb.urb_type == URB_COMPLETE)

Da quello che posso dire, quando c'è un trasferimento dall'host al dispositivo, il SUBMIT"pacchetto" contiene i dati USB effettivi trasmessi. Quando c'è un trasferimento dal dispositivo all'host (avviato dall'host, come sempre), il COMPLETE"pacchetto" contiene i dati USB effettivi trasmessi.

Dal punto di vista dell'analisi di un protocollo, tutti gli altri "pacchetti" sono una distrazione O un errore URB. Per filtrare le distrazioni, uso il seguente filtro di visualizzazione !(usb.urb_type == URB_SUBMIT && usb.endpoint_number.direction == IN) && !(usb.urb_type == URB_COMPLETE && usb.endpoint_number.direction == OUT)

Credo che il protocollo USB implichi alcuni handshaking, ACK e ritrasmissioni, ma tutto questo è gestito dal controller host e il sistema operativo non è coinvolto. Non credo, ad esempio, che il sistema operativo tenga traccia dei riconoscimenti o delle ritrasmissioni.

A proposito, sto usando il seguente comando per analizzare un protocollo. Oltre a eseguire il filtro sopra, visualizza solo il numero di endpoint (in decimale) e i dati USB. Questo è su una macchina GNU / Linux che usa il dispositivo usbmon1 per annusare, e supponendo che il dispositivo USB che voglio monitorare sia sul bus 1 e abbia l'indirizzo 11.

tshark -i usbmon1 -Y "usb.device_address == 11 && !(usb.urb_type == URB_SUBMIT && usb.endpoint_address.direction == IN) && !(usb.urb_type == URB_COMPLETE && usb.endpoint_address.direction == OUT)" -Tfields -e usb.endpoint_address -e usb.capdata

I registri USB di WireShark vengono eseguiti a livello di sistema operativo. Con Linux si basa sui dati generati da usbmon che si basano sulla struttura URB interna di Linux qui descritta . Quindi, guardando i commenti e i documenti del kernel e di WireShark si ottiene la migliore visione di cosa si tratti.

Quello che ho trovato dai documenti del kernel è che i pacchetti sono strutture usbmon seguite dai dati inviati e ricevuti. Questa è la struttura (copiata da qui ):

struct usbmon_packet {
    u64 id;         /*  0: URB ID - from submission to callback */
    unsigned char type; /*  8: Same as text; extensible. */
    unsigned char xfer_type; /*    ISO (0), Intr, Control, Bulk (3) */
    unsigned char epnum;    /*     Endpoint number and transfer direction */
    unsigned char devnum;   /*     Device address */
    u16 busnum;     /* 12: Bus number */
    char flag_setup;    /* 14: Same as text */
    char flag_data;     /* 15: Same as text; Binary zero is OK. */
    s64 ts_sec;     /* 16: gettimeofday */
    s32 ts_usec;        /* 24: gettimeofday */
    int status;     /* 28: */
    unsigned int length;    /* 32: Length of data (submitted or actual) */
    unsigned int len_cap;   /* 36: Delivered length */
    union {         /* 40: */
        unsigned char setup[SETUP_LEN]; /* Only for Control S-type */
        struct iso_rec {        /* Only for ISO */
            int error_count;
            int numdesc;
        } iso;
    } s;
    int interval;       /* 48: Only for Interrupt and ISO */
    int start_frame;    /* 52: For ISO */
    unsigned int xfer_flags; /* 56: copy of URB's transfer_flags */
    unsigned int ndesc; /* 60: Actual number of ISO descriptors */
};