Author Topic: Hid transfer  (Read 14416 times)

AshAll

  • Member
  • ***
  • Posts: 9
Hid transfer
« on: May 06, 2011, 04:35:18 pm »
Hi everybody,

I am working on a HID project, based on the software protocol analyzer (source USB), pc get the IN packet data before URB init, is this possible?

Can software protocol analyzer make this kind of mistake?

Thanks much for your input!

Ashall

Tsuneo

  • Frequent Contributor
  • ****
  • Posts: 145
Re: Hid transfer
« Reply #1 on: May 07, 2011, 03:27:32 pm »
Isn't it "USBINT", instead of "URB init"?

On SourceUSB log, USBINT tag stands for USB Internal Ioctl.

I believe any sniffer can't catch "URB init". WDM drivers (including HID class driver) apply UsbBuildInterruptOrBulkTransferRequest() macro to initialize a URB. This macro just fills members of URB structure, but it doesn't issue any IRP.

Tsuneo

AshAll

  • Member
  • ***
  • Posts: 9
Re: Hid transfer
« Reply #2 on: May 10, 2011, 02:14:22 pm »
Hi, Tsuneo,

Thank you for your response. The "URB init" I was talking about is the dark blue "URB" item in the log view. Sometimes when I just start the PC program, the first item I got for a interrupt in transfer is a SUCCESS for an IN transfer (light blue). Then it is followed by a dark blue URB IN for the same Irp(the URB init" I am talking about), then a pending URB (URB*) for the same Irp.

How can this be possible?

In general, is the dark URB IN Irp initiated by the HID device?

Thanks much!

Ashall

Tsuneo

  • Frequent Contributor
  • ****
  • Posts: 145
Re: Hid transfer
« Reply #3 on: May 10, 2011, 10:55:58 pm »
Ah, I see.
The sniffer puts these lines on its log at the moment of each event
- dark blue URB tag, when the upper driver sends URB query to lower USB system driver (USBDI).
- light blue URB* tag, when USBDI replies with pending.
- light blue URB tag, when USBDI replies with completion.

HID class driver sequentially pushes two independent URBs to the host controller's queue (TD/qTD list) at its start up, to guarantee 1ms (for FS, or 125 us for HS) interval. These two URBs are identified with its IRP address (Irp Request column). These two URBs are pended until device returns interrupt IN transfer.
On the sniffer log,

- dark URB:   URB1 query
- light URB*: URB1 pending
- dark URB:   URB2 query
- light URB*: URB2 pending

When an interrupt transfer comes from device, the first URB on the queue completes. The sniffer reports light-blue URB completion line. HID class driver immediately processes this URB, and it puts another URB using the same IRP. And then, the sniffer puts dark-blue URB and URB*.

- light URB:  URB1 completion
- dark URB:   URB1 query
- light URB*: URB1 pending

When next interrupt transfer comes, the URB on the queue responds. HID class driver processes this URB in the same way as the first URB.

- light URB:  URB2 completion
- dark URB:   URB2 query
- light URB*: URB2 pending

These sequences continue, using URB1 and URB2 alternately.
In this way, you see completion - "init" - pending group on the log.

Tsuneo
« Last Edit: May 10, 2011, 11:48:12 pm by Tsuneo »