Wireshark USB verfolgt Erklärungen

Ich versuche, ein USB-Gerät (HID) zurückzuentwickeln, und kann nicht wirklich herausfinden, wie sich das, was ich auf Wireshark (USBMON + Wireshark unter Linux oder Windows) sehe, auf das USB-Protokoll bezieht. Ich habe mir das USB-Protokoll von www.usb.org angesehen.

Was zeigt Wireshark?

1) Eine Zeile pro Paket? (Token, Daten, Handshake)

2) Eine Zeile pro Transaktion? (Token + [Daten] + Handschlag) (meine Vermutung)

3) Eine Zeile pro Kontrollübertragung?

Die Richtung der Transaktion ist ebenfalls sehr seltsam (zu / von Feldern). Zumindest entspricht es nicht meinen Erwartungen :-) ... und der Datenteil der Aufzählung, des versteckten Berichts usw. scheint manchmal mit den Setup-Daten (8 Bytes) angezeigt zu werden und manchmal nicht ... ich ziehe an Ich weiß nicht wirklich, was URB ist. Soweit ich sehen konnte, wird dies im USB-Protokoll nicht erwähnt. Es scheint mir, dass Wireshark / USBMmon auf einer höheren Stapelebene verfolgt werden und versucht, daraus abzuleiten, was wäre auf dem Draht davon ...

Ein Beispiel für das, was ich sehen kann, ist unten angegeben. Was sehen wir hier?

a) Ich konnte nicht einmal bmtype = 0x20 (des Setups, Frame No = 599) in den Spezifikationen finden.

b) Da ich ein HID-Gerät habe, habe ich angenommen, dass dies eine Berichts- / Funktionskonfiguration sein könnte (die Aufzählung wird zu diesem Zeitpunkt übergeben). So konnte ich der Richtung zustimmen (Host-> Gerät). aber wo sind die Daten? Oder gibt es hier keine Datenphase? Was ist dann Frame 600?

c) Was ist Frame 600? die Daten?

d) Was ist Frame 601? ein Status ACK? ... aber dann haben die Daten und ACK die gleiche Quelle?

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

Offensichtlich fehlt mir etwas. Eine allgemeine Erklärung, wie sich die Wireshark-Anzeige auf das Protokoll und (basierend darauf) auf die Bedeutung der obigen Spur bezieht, ist zu begrüßen!

Ich habe dies ursprünglich auf Stack Overflow gepostet, aber mir wurde gesagt, dass es sich nicht direkt um eine Programmierfrage handelt. Hoffe es passt hier besser.

Ein USB-URB ist wie ein IP-Paket und ein USB-Endpunkt ist wie ein IP-Port. Die USB-Endpunkte 0x00-0x7F befinden sich auf dem Host und die Endpunkte 0x80-0xFF befinden sich auf dem Gerät (glaube ich). Daher codiert der Endpunkt die Übertragungsrichtung. lsusbzeigt Ihnen, welche Endpunkte und welche Übertragungstypen ein Gerät unterstützt.

Ich werde "Pakete" in Anführungszeichen verwenden, um die Aktivitätseinheit zu bezeichnen, die Wireshark erfasst. Dies ist nicht buchstäblich das, was auf dem Draht gesendet wird. Beispielsweise haben die "Pakete" Zeitstempel für den Zeitpunkt, zu dem Übertragungen initiiert wurden, obwohl dies nicht über den USB-Bus übertragen wird.

Ich denke, der verwirrendste Aspekt beim Schnüffeln des USB-Protokolls ist, dass Sie zwei Wireshark- "Pakete" für jeden USB-URB sehen. Wenn der Host eine Übertragung initiiert, ist dies ein URB_SUBMIT(Wireshark-Anzeigefilter usb.urb_type == URB_SUBMIT). Wenn die Übertragung abgeschlossen ist, ist dies ein URB_COMPLETE(Wireshark-Anzeigefilter usb.urb_type == URB_COMPLETE)

Soweit ich weiß, SUBMITenthält das "Paket" bei einer Übertragung vom Host zum Gerät die tatsächlich übertragenen USB-Daten. Bei einer Übertragung vom Gerät zum Host (wie immer vom Host initiiert) COMPLETEenthält das "Paket" die tatsächlich übertragenen USB-Daten.

Unter dem Gesichtspunkt der Analyse eines Protokolls sind alle anderen "Pakete" eine Ablenkung ODER ein URB-Fehler. Um die Ablenkungen herauszufiltern, verwende ich den folgenden Anzeigefilter !(usb.urb_type == URB_SUBMIT && usb.endpoint_number.direction == IN) && !(usb.urb_type == URB_COMPLETE && usb.endpoint_number.direction == OUT)

Ich glaube, das USB-Protokoll beinhaltet einige Handshakes und ACKs und Neuübertragungen, aber dies alles wird vom Host-Controller erledigt, und das Betriebssystem ist nicht beteiligt. Ich glaube nicht, dass das Betriebssystem beispielsweise die Bestätigungen oder Neuübertragungen verfolgt.

Übrigens verwende ich den folgenden Befehl, um ein Protokoll zu analysieren. Zusätzlich zur obigen Filterung werden nur die Endpunktnummer (in Dezimalzahl) und die USB-Daten angezeigt. Dies ist auf einem GNU / Linux-Computer, der das usbmon1-Gerät zum Schnüffeln verwendet, und unter der Annahme, dass sich das zu überwachende USB-Gerät auf Bus 1 befindet und die Adresse 11 hat.

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

WireShark USB-Protokolle werden auf Betriebssystemebene erstellt. Bei Linux basiert es auf den von usbmon generierten Daten, die auf der hier beschriebenen internen URB-Struktur von Linux basieren . Wenn Sie sich also die Kommentare und Dokumente zu Kernel und WireShark ansehen, erhalten Sie den besten Einblick in das, was es ist.

Was ich aus den Kernel-Dokumenten herausgefunden habe, ist, dass die Pakete usbmon-Strukturen sind, gefolgt von den gesendeten und empfangenen Daten. Dies ist die Struktur (von hier kopiert ):

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