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 :)

basically:

cat UsbSnoop.log | perl spike4.pl > UsbSnoop.out

then look at the .out file.

allan

On Wed, Feb 24, 2010 at 10:54 AM, Gernot Hassenpflug
<aikishugyo at gmail.com> wrote:
> Dear all,
> ?I am trying to analyse the CanoScan 8800F SniffUSB 2.0 results (WinXP
> Pro in VMware) and am confused by a few things.
>
> 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.
>
> 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.
>
> 3) sometimes there is a value for TransferBufferLength but no apparent
> data, like for URB16 below:
>
> ? ?[670492 ms] ?>>> ?URB 16 going down ?>>>
> -- URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER:
> ?PipeHandle ? ? ? ? ? = 85afcb24 [endpoint 0x00000007]
> ?TransferFlags ? ? ? ?= 00000002 (USBD_TRANSFER_DIRECTION_OUT,
> USBD_SHORT_TRANSFER_OK)
> ?TransferBufferLength = 00000010
> ?TransferBuffer ? ? ? = 00000000
> ?TransferBufferMDL ? ?= 84d316b0
> ? ?00000000: f3 20 00 00 00 00 00 00 00 00 00 00 00 00 00 10 ? <-
> data corresponding to TransferBufferLength
> ?UrbLink ? ? ? ? ? ? ?= 00000000
> [670493 ms] UsbSnoop - MyInternalIOCTLCompletion(ed926126) :
> fido=85a0d810, Irp=85dbee28, Context=86185b00, IRQL=2
> [670493 ms] ?<<< ?URB 16 coming back ?<<<
> -- URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER:
> ?PipeHandle ? ? ? ? ? = 85afcb24 [endpoint 0x00000007]
> ?TransferFlags ? ? ? ?= 00000002 (USBD_TRANSFER_DIRECTION_OUT,
> USBD_SHORT_TRANSFER_OK)
> ?TransferBufferLength = 00000010 ?<- length, but no apparent data to be seen.
> ?TransferBuffer ? ? ? = 00000000
> ?TransferBufferMDL ? ?= 84d316b0
> ?UrbLink ? ? ? ? ? ? ?= 00000000
> [670494 ms] UsbSnoop - FilterDispatchAny(ed925fd2) :
> IRP_MJ_INTERNAL_DEVICE_CONTROL
> [670494 ms] UsbSnoop - FdoHookDispatchInternalIoctl(ed9261ea) :
> fdo=84c4da90, Irp=85dbee28, IRQL=0
> [670494 ms] ?>>> ?URB 17 going down ?>>>
>
> I am happy to see that the SniffUSB is showing me the device Vid, Pid and Rid:
>
> [621 ms] ?>>> ?URB 1 going down ?>>>
> -- URB_FUNCTION_GET_DESCRIPTOR_FROM_DEVICE:
> ?TransferBufferLength = 00000012
> ?TransferBuffer ? ? ? = 8605a808
> ?TransferBufferMDL ? ?= 00000000
> ?Index ? ? ? ? ? ? ? ?= 00000000
> ?DescriptorType ? ? ? = 00000001 (USB_DEVICE_DESCRIPTOR_TYPE)
> ?LanguageId ? ? ? ? ? = 00000000
> [622 ms] UsbSnoop - MyInternalIOCTLCompletion(ee652126) :
> fido=00000000, Irp=849ee720, Context=84b2ab00, IRQL=2
> [623 ms] ?<<< ?URB 1 coming back ?<<<
> -- URB_FUNCTION_CONTROL_TRANSFER:
> ?PipeHandle ? ? ? ? ? = 85d1e908
> ?TransferFlags ? ? ? ?= 0000000b (USBD_TRANSFER_DIRECTION_IN,
> USBD_SHORT_TRANSFER_OK)
> ?TransferBufferLength = 00000012
> ?TransferBuffer ? ? ? = 8605a808
> ?TransferBufferMDL ? ?= 84b22bb8
> ? ?00000000: 12 01 00 02 00 00 00 40 a9 04 01 19 01 01 01 02
> ? ?00000010: 00 01
> ?UrbLink ? ? ? ? ? ? ?= 00000000
> ?SetupPacket ? ? ? ? ?=
> ? ?00000000: 80 06 00 01 00 00 12 00
> [624 ms] UsbSnoop - FilterDispatchAny(ee651fd2) : 
> IRP_MJ_INTERNAL_DEVICE_CONTROL
> [624 ms] UsbSnoop - FdoHookDispatchInternalIoctl(ee6521ea) :
> fdo=86133d08, Irp=849ee720, IRQL=0
>
> I will compare this information with that from a working SANE scanner,
> my N1240U, and try to learn from the source code for that backend.
> Best regards,
> Gernot Hassenpflug
>
> --
> sane-devel mailing list: sane-devel at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/sane-devel
> Unsubscribe: Send mail with subject "unsubscribe your_password"
> ? ? ? ? ? ? to sane-devel-request at lists.alioth.debian.org



-- 
"The truth is an offense, but not a sin"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: spike4.pl
Type: application/octet-stream
Size: 1680 bytes
Desc: not available
URL: 
<http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20100224/ca6d740b/attachment.obj>

Reply via email to