wireshark usb відстежує пояснення

Я намагаюся повернути інженеру пристрій usb (HID) і не можу зрозуміти, як те, що я бачу на wireshark (usbmon + wireshark на Linux або windows), стосується протоколу usb ?. Я переглянув протокол usb з www.usb.org.

Що показує проводка?

1) Один рядок на пакет? (маркер, дані, рукостискання)

2) Один рядок на транзакцію? (маркер + [дані] + рукостискання) (моя здогадка)

3) Один рядок на контрольну передачу?

Напрямок транзакції також дуже дивний (до / з полів). Принаймні, це не відповідає моїм очікуванням :-) ... І частина даних перерахунку, прихований звіт тощо ..., здається, іноді відображається з даними про налаштування (8 байт), а колись ні ... я не Насправді я не знаю, що таке URB ... про це у згадуваному протоколі не згадується, наскільки я міг бачити ... Мені здається, що Wireshark / usbmon слід на більш високому рівні стеку і намагається визначити, що було б на дроті від цього ...

Приклад того, що я бачу, наведено нижче, що ми бачимо тут ?.

а) Я навіть не міг знайти bmtype = 0x20 (налаштування, рамка № = 599) у специфікаціях.

b) Оскільки у мене є HID-пристрій, я припускав, що це може бути конфігурація звіту / функції (перерахування передано на цьому етапі). Тож я міг би погодитися з напрямком (хост-> пристрій). але де дані? Або тут немає фази даних? Що таке кадр 600?

в) що таке кадр 600? дані?

г) що таке кадр 601? статус ACK? ... але тоді дані та ACK мають одне джерело?

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

Очевидно, мені щось не вистачає. Загальне пояснення того, як відображення проводів тривалості стосується протоколу, та (на його основі) значення вищенаведеного сліду вітається!

Я оригінально розмістив це на Stack Overflow, але мені сказали, що це не було безпосередньо питанням програмування. Сподіваюся, що тут краще підходить.

USB URB - це як IP-пакет, а кінцева точка USB - як порт IP. Кінцеві точки USB 0x00-0x7F знаходяться на хості, а кінцеві точки 0x80-0xFF - на пристрої (я думаю). Тому кінцева точка кодує напрямок передачі. lsusbпокаже, які кінцеві точки та типи передачі підтримує пристрій.

Я буду використовувати "пакети" в лапках, щоб означати одиницю активності, яка захоплює проводку. Це не буквально те, що надсилається по дроту. Наприклад, "пакети" матимуть часові позначки при ініціюванні передачі, навіть якщо це не передається через шину USB.

Я думаю, що найбільш заплутаним аспектом нюхання USB-протоколу є те, що ви бачите два "пакети" Wireshark для кожного USB URB. Коли хост ініціює деяку передачу, це URB_SUBMIT(фільтр відображення Wireshark usb.urb_type == URB_SUBMIT). Коли передача завершиться, це URB_COMPLETE(фільтр відображення Wireshark usb.urb_type == URB_COMPLETE)

З того, що я можу сказати, коли відбувається передача з хоста на пристрій, SUBMIT"пакет" містить фактично передані дані USB. Коли відбувається перехід від пристрою до хоста (ініційований хостом, як завжди), COMPLETE"пакет" містить фактично передані USB-дані.

З точки зору аналізу протоколу, всі інші "пакети" є відволіканням АБО помилкою URB. Щоб відфільтрувати відволікання, я використовую наступний фільтр дисплея !(usb.urb_type == URB_SUBMIT && usb.endpoint_number.direction == IN) && !(usb.urb_type == URB_COMPLETE && usb.endpoint_number.direction == OUT)

Я вважаю, що протокол USB передбачає деяке рукостискання, ACK та повторну передачу, але це все обробляється хост-контролером, а ОС не бере участь. Я не думаю, що, наприклад, ОС відслідковує підтвердження чи повторну передачу.

До речі, я використовую наступну команду для аналізу протоколу. На додаток до фільтрації вище, вона відображає лише кінцеву точку (у десятці) та дані USB. Це на машині GNU / Linux, яка використовує пристрій usbmon1 для нюхання, і припускаючи, що USB-пристрій, який я хочу контролювати, знаходиться на шині 1 і має адресу 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

USB-журнали WireShark робляться на рівні ОС. Для Linux це базується на даних, які генерує usbmon, що базується на внутрішній структурі URB Linux, описаній тут . Отже, переглядаючи коментарі та документи ядра та WireShark, можна найкраще зрозуміти, що це таке.

Що я знайшов у документах ядра, це те, що пакети - це структури usbmon, за якими слід відправляти та отримувати дані. Це структура (скопійована звідси ):

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