Understanding a USB 'sniff'

[ethrbunny]

I trying to recreate some IO from a HID based phone monitor. Im using HIDAPI on Linux.

Watching the device IO (on a windows machine) in USBLyzer I can see where the PC application sends an occasional 8 byte packet with a call to 'Class Interface' and then 'Set Report'.

Two questions:

1) What is the 'Class Interface' request type?
2) How do I tell if the 'Set Report' call is a 'hid_send_feature_report' or a 'hid_get_feature_report'.

Also - the device sends Interrupt Transfers every 15 msec even when there isn't an app communicating with it. I'm trying to use 'hid_read' or 'hid_read_timeout' to get these messages but I don't seem to have the knack of it yet. (These are empty for the most part. Once the windows app connects these packets will occasionally have some data) They are coming from Interface 3 and Endpoint 81. When I tried this same process using LIBUSB I needed to specify this information. Am i missing some step in HIDAPI where these values are used?

Im starting to suspect that I may have the notion of 'in' and 'out swapped w/re USBLyzer data. Events that are reported from the device seem to show up as 'out' on endpoint 0. Is it possible that all the 15msec activity Im seeing is actually the PC sending and the device ignoring?

Any suggestions are appreciated.

[Jan Axelson]

The reprt type is in wValue of the Setup packet.

Class interface is a request defined in a class spec for an interface. In thiscase, HID interface.

The HID drivet polls the interrupt IN endpoint for report data. If no report, the endpoint returns nak.

[ethrbunny]

Would the interrupt packets every 15 mSec be device to PC or the other way? They are marked as 'in' so I had been assuming that meant 'device to pc' but I can't seem to get my code to find these.

[Tsuneo]

Hi ethrbunny,

I remember that USBlyzer indicates the transfer direction exactly at its I/O column.
"in" at this column means device --> host transfer.
You may confirm it with the endpoint address at C:I:E (Config:Interface:Endpoint) column.
A transfer for an IN endpoint (ex. 0x81) should be "in".

USBlyzer (and most of sniffers) records two lines per single transfer,
1) when a transfer request is issued by a PC driver to Windows USBDI (USB system driver).
2) when the request completes, either successfully or in error.
USBlyzer indicates this pair at Seq field of the completion line, like 0030-0028

Here is a screenshot of USBlyzer log on their web site.
You'll see these explanation on this screenshot.
http://www.usblyzer.com/img/screenshots/capture-list-bg.png

Ah, software sniffers, including USBlyzer, can't see NAKing at endpoint, because it is handled directly by hardwares of both sides. If you see successful completion on a sniffer, the device really returns the data to the host.

Tsuneo

[ethrbunny]

Ok - so at least Im trying the IO in the appropriate direction. Thank goodness for small favors.

In the USBLyzer log Im seeing an 'in' Interrupt Transfer every 15 msec of 0 length. Its coming from context 1, Interface 3, Endpoint 81.

Every 90 mSec I get an Interrupt Transfer from the same location with length 8 and contents '03 13 01 00 00 00 00 00'.

I'm trying to use the HIDAPI to read these. I have a device handle that lets me get the manufacturer string, serial #, etc so I'm pretty confident that I'm talking to the correct device. Unf when I try to use an asynchronous read like 'hid_read_timeout' (with a 15 msec timeout) I get nothing but zero length packets.

If I change my reads to blocking and use 'hid_read' I get the same frequency of packets but all are still zero length.

I've tried using LibUSB as well but the results are the same. Suggestions on where to look to understand what step I've missed?

[Tsuneo]

Using a Linux sniffer, confirm that the device would be working in the same way as on Windows.

Virtual USB Analyzer
http://vusb-analyzer.sourceforge.net

Tsuneo