[sane-devel] SniffUSB: URB direction and TransferFlags IN/OUT confusion

[Pierre Willenbrock]

Gernot Hassenpflug schrieb:
> On Thu, Feb 25, 2010 at 7:05 PM, Pierre Willenbrock
> <pierre at pirsoft.dnsalias.org> wrote:
>> Gernot Hassenpflug schrieb:
>>> On Thu, Feb 25, 2010 at 1:05 AM, m. allan noah <kitno455 at gmail.com> wrote:
>>> /../
>>> Are endpoints apart from the default 0x00000000 able to have both IN
>>> and OUT now? Or did I misunderstand the log file (and spike4 output
>>> also)?
>>
>> The bulk endpoints are either in or out. The type is encoded (iirc) in
>> bit7 of the endpoint number, 1 means in, 0 means out. usbsnoop always
>> dumps the buffer when a request goes down to the device, even when it is
>> about to be overwritten.
> 
> Hello Pierre, thank you for that. And especially for the tip on where
> usbsnoop sits: without thinking I'd assumed I was seeing communication
> between Host and Function (device), but now that I have gotten through
> about 1/3 of the USB 2.0 spec document (after reading most of the USB
> tutorials I could find) I have to realize I don't know what I am
> looking at exactly!
> 
>>>>> 2)  snoop headings like ">>>  URB 16 going down  >>>" and  "<<<  URB
>>>>> 16 coming back  <<<" are both followed by: /../
>>
>> This is just the USB Request Block(URB) that goes down to the lower
>> levels of the usb stack and coming back from there. It is just the same
>> URB going through usbsnoop in different directions, as evidenced by the
>> same URB number. Remember that usbsnoop sits in the stack and acts like
>> a filter, and that urb processing happens asynchronously.
> 
> OK, I'll post again after I digest that, and more specs, to figure out
> when the host is talking to the function (device). I see from the
> specs that there is also a hub between the two, but as far as I can
> tell it should be transparent to sniffusb.
> 
> Recap: the host has buffers, the function (device) has endpoints. The
> endpoints (except default) have to be configured before being used (I
> see that info fine in the sniff logs), and they are unidirectional
> (except default which is bi-directional). Some URBs show
> TransferBuffer length but no data, but I guess I will examine the spec
> docs and log further to find out what I am missing in understanding.
> 
> Thanks for the useful comments and helpful tips so far everyone,

The stuff around the URBs is not exactly part of the specs, it is merely
a good way to handle usb communication.

What happens is this: The device driver(mass-storage driver, hid-driver
etc) sends requests that go to the host controller driver that tells the
host controller to make it happen. For that, the information in the URB
is used to create a request structure and put it into one of the queues
of the host controller. Later, the host controller tells its driver that
this request has been worked on. The host controller driver then
modifies the URB accordingly(status codes, data received) and sends it
back to the driver.

On Windows, in between the host controller and the driver, there can be
"filters", and that is the place where usbsnoop hooks into.

The above information is mostly from memory of my little excursions into
why SnoopyPro stops working when packets are > 1024(or so) bytes.

I hope this helps you understand how the operating system side of things
work.

Regards,
  Pierre