1

Good Day-

I have captured via Wireshark some data and am attempting to understand it as well as the communication protocol for USB.

This one capture contains the sequence 02010c, which tells me the firmware version of a particular target. Wireshark says the request is in an earlier sequence- but I am not understanding where in that particular request is the actual 'request'. So I believe I am having trouble understanding how the URBs are working.

Frame 32625: 91 bytes on wire (728 bits), 91 bytes captured (728 bits) on interface wireshark_extcap1928, id 0
    Interface id: 0 (wireshark_extcap1928)
    Encapsulation type: USB packets with USBPcap header (152)
    Arrival Time: May  8, 2020 14:02:24.741579000 Eastern Daylight Time
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1588960944.741579000 seconds
    [Time delta from previous captured frame: 0.000943000 seconds]
    [Time delta from previous displayed frame: 0.000943000 seconds]
    [Time since reference or first frame: 141.773912000 seconds]
    Frame Number: 32625
    Frame Length: 91 bytes (728 bits)
    Capture Length: 91 bytes (728 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: usb]
USB URB
    [Source: 3.12.1]
    [Destination: host]
    USBPcap pseudoheader length: 27
    IRP ID: 0xffffd50384c4da20
    IRP USBD_STATUS: USBD_STATUS_SUCCESS (0x00000000)
    URB Function: URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER (0x0009)
    IRP information: 0x01, Direction: PDO -> FDO
        0000 000. = Reserved: 0x00
        .... ...1 = Direction: PDO -> FDO (0x1)
    URB bus id: 3
    Device address: 12
    Endpoint: 0x81, Direction: IN
        1... .... = Direction: IN (1)
        .... 0001 = Endpoint number: 1
    URB transfer type: URB_INTERRUPT (0x01)
    Packet Data Length: 64
    [Request in: 32618]
    [Time from request: 0.008964000 seconds]
    [bInterfaceClass: HID (0x03)]
Leftover Capture Data: 7e107bff000882000302010c003500000000000000000000…

The request that is referenced:

Frame 32618: 27 bytes on wire (216 bits), 27 bytes captured (216 bits) on interface wireshark_extcap1928, id 0
    Interface id: 0 (wireshark_extcap1928)
    Encapsulation type: USB packets with USBPcap header (152)
    Arrival Time: May  8, 2020 14:02:24.732615000 Eastern Daylight Time
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1588960944.732615000 seconds
    [Time delta from previous captured frame: 0.000033000 seconds]
    [Time delta from previous displayed frame: 0.000033000 seconds]
    [Time since reference or first frame: 141.764948000 seconds]
    Frame Number: 32618
    Frame Length: 27 bytes (216 bits)
    Capture Length: 27 bytes (216 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: usb]
USB URB
    [Source: host]
    [Destination: 3.12.1]
    USBPcap pseudoheader length: 27
    IRP ID: 0xffffd50384c4da20
    IRP USBD_STATUS: USBD_STATUS_SUCCESS (0x00000000)
    URB Function: URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER (0x0009)
    IRP information: 0x00, Direction: FDO -> PDO
        0000 000. = Reserved: 0x00
        .... ...0 = Direction: FDO -> PDO (0x0)
    URB bus id: 3
    Device address: 12
    Endpoint: 0x81, Direction: IN
        1... .... = Direction: IN (1)
        .... 0001 = Endpoint number: 1
    URB transfer type: URB_INTERRUPT (0x01)
    Packet Data Length: 0
    [Response in: 32625]
    [bInterfaceClass: HID (0x03)]

I've read a number of different examples on in, out, transfer packets. I'm just failing to see how this is working.

Is it as simple as... there's another pair of packets further up(down?) that is sending a command to the end point, and the machine is sitting there waiting to respond with an 'in' request from the host to let it know to send the data?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.