IRP information: 0x01, Direction: PDO -> FDO URB Function: URB_FUNCTION_CONTROL_TRANSFER (0x0008) IRP information: 0x00, Direction: FDO -> PDOįrame 62: 36 bytes on wire (288 bits), 36 bytes captured (288 bits)Īrrival Time: 00:49:17.478230000 Pacific Standard Time URB Function: URB_FUNCTION_CLASS_INTERFACE (0x001b) IRP USBD_STATUS: USBD_STATUS_SUCCESS (0x00000000) Here's an example that corresponds with the one above (I re-did the first test).įrame 61: 36 bytes on wire (288 bits), 36 bytes captured (288 bits)Įncapsulation type: USB packets with USBPcap header (152)Īrrival Time: 00:49:17.477649000 Pacific Standard Time but as part of the URB_CONTROL in from the device, which is very peculiar (and apparently is not really what's happening on the wire). and there I see the those exact bytes, along with other unique patterns corresponding to the other requests I so far have only been able to view in USBlyzer.Īnd so I searched for that same hex data in Wireshark and also found. That all said, I got curious and looked at the actual PCAP file in a hex editor. Neither that traffic nor that data is in the Wireshark output. Clearly it's going through the USBPcap driver. The raw data (e.g., 40 23 94 84 94 84 94 27) appears to be what I expect (the format of the data is unclear but it's not compressed and varies in a way that strongly suggests it's exactly what I'm looking for).

URB Function URB_FUNCTION_CONTROL_TRANSFER

Wireshark usb interrupt