объяснения трассировок usb wireshark

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

что показывает wireshark?

1) одна строка на пакет? (токен, данные, рукопожатие)

2) одна строка на транзакцию? (токен + [данные] + рукопожатие) (мое предположение)

3) одна линия в управление перевод?

направление транзакции тоже очень странное (поля to / from). По крайней мере, это не соответствует моим ожиданиям 🙂 ... И часть данных перечисления, спрятанного рапорта etc... кажется, иногда отображается с данными настройки (8 байт), а иногда нет... Я действительно не знаю, что такое URB... там нет упоминания об этом в протоколе usb, насколько я мог видеть... Мне кажется, что трассировка wireshark/usbmon на более высоком уровне стека и пытается вывести то, что было бы быть на проводе от этого...

пример того, что я вижу ниже, что мы видим здесь?.

a) я даже не мог найти bmtype=0x20 (настройки, кадра нет=599)в спецификациях.

b) поскольку у меня есть скрытое устройство, я предположил, что это может быть конфигурацией отчета/функции (перечисление передается на этом этапе). Поэтому я мог согласиться с направлением (хост- > устройство). но где же эти данные? Или здесь нет фазы данных? Что же такое кадр 600?

c) что рамка 600? данные?

d) что такое кадр 601? в подтверждение статуса?... но тогда данные и 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               ............

очевидно, я что-то упускаю. Общее объяснение о том, как дисплей wireshark относится к протоколу и, (основанный на нем), смысл вышеупомянутой трассировки приветствуется!

Я изначально разместил это в Stack Overflow, но мне сказали, что это не вопрос программирования. Надеюсь, здесь будет лучше.

10
задан heavyd
13.03.2023 14:53 Количество просмотров материала 2925
Распечатать страницу

2 ответа

USB-устройство УРБ-как IP-пакет и USB-конечная точка, как IP-порт. Конечные точки USB 0x00-0x7F находятся на хосте, а конечные точки 0x80-0xFF находятся на устройстве (я думаю). Таким образом конечная точка кодирует направление передачи. lsusb покажет вам, какие конечные точки и какие типы передачи поддерживает устройство.

Я буду использовать "пакеты" в кавычках для обозначения единицы активности, которую захватывает wireshark. Это не буквально то, что посылают по проводам. Например, "пакеты" будут иметь метки времени, когда были инициированы передачи, даже если это не передается по шине USB.

Я думаю, что самый запутанный аспект обнюхивать протокол USB является то, что вы видите два Wireshark "пакеты" для каждого USB URB. Когда хост инициирует некоторую передачу, это URB_SUBMIT (Wireshark display filter usb.urb_type == URB_SUBMIT). Когда передача завершена, это URB_COMPLETE (Wireshark display filter 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_number.direction == IN) && !(usb.urb_type == URB_COMPLETE && usb.endpoint_number.direction == OUT)" -Tfields -e usb.endpoint_number -e usb.capdata

9
отвечен Gus 2023-03-14 22:41

журналы USB WireShark сделаны на уровне ОС. С Linux его на основе данных, которые генерирует usbmon, который основан на внутренней структуре URB Linux описано здесь. Таким образом, просмотр комментариев и документов kernel и WireShark дает лучшее представление о том, что это такое.

что я нашел из ядра Docs является то, что пакеты 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 */
};
2
отвечен tannewt 2023-03-15 00:58

Постоянная ссылка на данную страницу: [ Скопировать ссылку | Сгенерировать QR-код ]

Ваш ответ

Опубликуйте как Гость или авторизуйтесь

Имя
Вверх