Wirehark usb trace des explications

J'essaie de désosser un périphérique USB (HID) et je ne peux pas vraiment comprendre comment ce que je vois sur Wireshark (usbmon + Wireshark sur Linux ou Windows) est lié au protocole USB?. J'ai regardé le protocole USB de www.usb.org.

Que montre Wirehark?

1) Une ligne par paquet? (jeton, données, poignée de main)

2) Une ligne par transaction? (jeton + [données] + poignée de main) (je suppose)

3) Une ligne par transfert de contrôle?

La direction de la transaction est également très étrange (vers / depuis les champs). Au moins, cela ne correspond pas à mes attentes :-) ... Et la partie données de l'énumération, du rapport caché etc ... semble parfois être affichée avec les données de configuration (8 octets) et parfois non ... je ne Je ne sais pas vraiment ce qu'est URB ... il n'y a aucune mention de cela dans le protocole USB pour autant que je puisse voir ... sur le fil de cela ...

Un exemple de ce que je peux voir est donné ci-dessous, que voir ici?.

a) Je n'ai même pas pu trouver bmtype = 0x20 (de la configuration, cadre n ° = 599) dans les spécifications.

b) Parce que j'ai un périphérique HID, j'ai supposé que cela pourrait être une configuration de rapport / fonctionnalité (l'énumération est passée à ce stade). Je pouvais donc être d'accord avec la direction (hôte-> appareil). mais où sont les données? Ou n'y a-t-il pas de phase de données ici? Qu'est-ce que le cadre 600 alors?

c) qu'est-ce que le cadre 600? les données?

d) qu'est-ce que le cadre 601? un état ACK? ... mais alors les données et ACK ont la même source?

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               ............

De toute évidence, il me manque quelque chose. Une explication générale sur la façon dont l'affichage Wirehark se rapporte au protocole et, (sur la base de celui-ci), la signification de la trace ci-dessus est la bienvenue!

J'ai initialement posté ceci sur Stack Overflow, mais on m'a dit que ce n'était pas directement une question de programmation. J'espère que ça va mieux ici.

Un USB URB est comme un paquet IP et un point de terminaison USB est comme un port IP. Les points de terminaison USB 0x00-0x7F sont sur l'hôte, et les points de terminaison 0x80-0xFF sont sur l'appareil (je pense). Par conséquent, le point final code la direction du transfert. lsusbvous montrera quels points de terminaison et quels types de transfert un appareil prend en charge.

Je vais utiliser des "paquets" entre guillemets pour désigner l'unité d'activité que Wireshark capture. Ce ne sont pas littéralement ce qui est envoyé sur le fil. Par exemple, les "paquets" auront des horodatages pour le moment où les transferts ont été lancés, même si cela n'est pas transmis sur le bus USB.

Je pense que l'aspect le plus déroutant du reniflement du protocole USB est que vous voyez deux "paquets" Wireshark pour chaque USB URB. Lorsque l'hôte initie un transfert, c'est un URB_SUBMIT(filtre d'affichage Wireshark usb.urb_type == URB_SUBMIT). Une fois le transfert terminé, il s'agit d'un URB_COMPLETE(filtre d'affichage Wireshark usb.urb_type == URB_COMPLETE)

D'après ce que je peux dire, quand il y a un transfert de l'hôte à l'appareil, le SUBMIT"paquet" contient les données USB réelles transmises. Lorsqu'il y a un transfert de l'appareil vers l'hôte (initié par l'hôte, comme toujours), le COMPLETE"paquet" contient les données USB réelles transmises.

Du point de vue de l'analyse d'un protocole, tous les autres "paquets" sont une distraction OU une erreur URB. Pour filtrer les distractions, j'utilise le filtre d'affichage suivant !(usb.urb_type == URB_SUBMIT && usb.endpoint_number.direction == IN) && !(usb.urb_type == URB_COMPLETE && usb.endpoint_number.direction == OUT)

Je crois que le protocole USB implique une poignée de main et des ACK et des retransmissions, mais tout est géré par le contrôleur hôte et le système d'exploitation n'est pas impliqué. Je ne pense pas, par exemple, que le système d'exploitation garde une trace des accusés de réception ou des retransmissions.

Soit dit en passant, j'utilise la commande suivante pour analyser un protocole. En plus du filtrage ci-dessus, il n'affiche que le numéro de point de terminaison (en décimal) et les données USB. C'est sur une machine GNU / Linux utilisant le périphérique usbmon1 pour renifler, et en supposant que le périphérique USB que je veux surveiller est sur le bus 1 et a l'adresse 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

Les journaux WireShark USB sont effectués au niveau du système d'exploitation. Avec Linux, il est basé sur les données générées par usbmon qui sont basées sur la structure URB interne de Linux décrite ici . Ainsi, la consultation des commentaires et des documents du noyau et de WireShark fournit le meilleur aperçu de ce que c'est.

Ce que j'ai trouvé dans la documentation du noyau, c'est que les paquets sont des structures usbmon suivies des données envoyées et reçues. Voici la structure (copiée d' ici ):

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 */
};