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

[Pierre Willenbrock]

Gernot Hassenpflug schrieb:
> On Thu, Feb 25, 2010 at 1:05 AM, m. allan noah <kitno455 at gmail.com> wrote:
>> Attached is a copy of a script I wrote that clears up these verbose
>> logs. I don't know if it is the most recent version, I cannot reach my
>> development machine, and i just found this copy with google :)
> 
> Thanks for that, I had seen it but since I haven't grokked the basics
> yet, I was using the messy output.
> 
>> cat UsbSnoop.log | perl spike4.pl > UsbSnoop.out
> 
> Very nice & clean indeed.
> 
> I am still confused on the questions below, while reading more to see
> if the answers appear:
> 
>>> 1) there are 4 endpoints:
>>>    *　0x00000000 which has both IN and OUT version;
>>>    *   0x00000007 which is a bulk type, seems to be for OUT only;
>>>    *   0x00000088 which is a bulk type, seems to be for both IN and OUT;
>>>    *   0x00000089 which is an interrupt type, seems to be for both IN and OUT.
>>>   whereas I thought only endpoint 0x00000000 can have both IN and OUT
>>> use, while all other endpoints are either IN or OUT, but not both.
> 
> 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.

> 
>>> 2)  snoop headings like ">>>  URB 16 going down  >>>" and  "<<<  URB
>>> 16 coming back  <<<" are both followed by:
>>>      TransferFlags        = 00000002 (USBD_TRANSFER_DIRECTION_OUT,
>>> USBD_SHORT_TRANSFER_OK)
>>>     whereas I thought that "down" means the endpoint must be "OUT"
>>> direction, and "back" must be "IN" direction.
> 
> So I expected a URB "coming back" to contain a TransferFlags with
> DIRECTION_IN, but often it has instead DIRECTION_OUT. Is that
> relevant?

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.

Regards,
  Pierre