I am testing a custom usb data logger hardware by running a long term test. My tests have been failing due to USB communication issues after 15 odd hours so I decided to investigate. I have Wireshark running to log all the USB traffic to see if I can spot something. The traffic rate is a measly 2 or 3 packets a second so this works well.
In my setup, I had 3 similar devices connected to the same USB Bus and nothing else. My basic setup without any test devices connected looks like this
All my test devices are connected to the first free hub so that no other traffic is captured. I have noticed that during enumeration, INTERRUPT transfers are issued to the HUB. The HUB then answers with two bytes of data. These appear in Frames 42, 55, 65, 83, 93, 103, 121, 129, 135, 145 and 155. All these are in rsponse to a request. Can someone tell me how to interpret these bytes?
A request issued in Frame 26 looks like this
No. Time Source Destination Protocol Length Info
26 18.934026 host 2.1.1 USB 27 URB_INTERRUPT in
Frame 26: 27 bytes on wire (216 bits), 27 bytes captured (216 bits) on interface \.\USBPcap2, id 0
USB URB
[Source: host]
[Destination: 2.1.1]
USBPcap pseudoheader length: 27
IRP ID: 0xfffffa8004886010
IRP USBD_STATUS: USBD_STATUS_CANCELED (0xc0010000)
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: 2
Device address: 1
Endpoint: 0x81, Direction: IN
URB transfer type: URB_INTERRUPT (0x01)
Packet Data Length: 0
[Response in: 42]
[bInterfaceClass: Hub (0x09)]
The corresponding response in Frame 42 looks like this
No. Time Source Destination Protocol Length Info
42 18.934026 2.1.1 host USB 29 URB_INTERRUPT in
Frame 42: 29 bytes on wire (232 bits), 29 bytes captured (232 bits) on interface \.\USBPcap2, id 0
USB URB
[Source: 2.1.1]
[Destination: host]
USBPcap pseudoheader length: 27
IRP ID: 0xfffffa8004886010
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: 2
Device address: 1
Endpoint: 0x81, Direction: IN
URB transfer type: URB_INTERRUPT (0x01)
Packet Data Length: 2
[Request in: 26]
[Time from request: 0.000000000 seconds]
[bInterfaceClass: Hub (0x09)]
Leftover Capture Data: 0400
A bigger problem is that a request is issued in Frame 160. This is not answered till Frame 369069 which arrives around 15 hours after the tests have started. These response frames lead the USB port to reset which causes my USB communication to break down.
While I am extending my PC software to check for such resets, I would like to know what is causing such long delays and if I should wait for the hub to respond before I start any other activity on it?
