On Sun, 10 Jul 2005 21:13:13 -0700 Steve Calfee wrote:
| > >From: Pete Zaitcev <[EMAIL PROTECTED]>
| > >To: randy_dunlap <[EMAIL PROTECTED]>
| > >Cc: [EMAIL PROTECTED], linux-usb-devel@lists.sourceforge.net
| > >Subject: Re: [linux-usb-devel] Patch to make usbmon to print control
| >setup
| > > packets
|
| > >X-Original-Date: Sun, 10 Jul 2005 13:53:21 -0700
| > >Date: Sun, 10 Jul 2005 13:53:21 -0700
| > >
| > >
| > >On Fri, 8 Jul 2005 01:00:57 -0700, randy_dunlap <[EMAIL PROTECTED]>
| >wrote:
...snip...
| > >What I would really like to see is some sort of parsing of known
| > >things inside the data stream, which is completely opaque for usbmon.
| > >This includes names of known control messages and status replies from
| > >hubs and devices, SCSI commands and replies for storage. This is the
| > >biggest thing USBMon needs (right after I teach it to load and save
| > >the usbmon traces in text file).
| > >
|
| Hi Pete, Randy,
|
| I have an awk program that I use to run through Kitty USB Analyzer html
| pages and decode setup data packets for device, configuration, endpoint
etc.
| generic descriptors, into USB spec type formats. It is table driven and
| could be extended to some of the more difficult descriptors, such as HID
or
| audio etc., but would take an expert in those descriptors.
|
| In any case, if you give me a URL to a few usbmon text dumps, I will try
to
| do a converter to run usbmon output through this AWK decoder program. (I
| don't have a working Linux system right now). If I can do a converter I
| think this GAWK program will help make the usbmon stuff more helpful.
Steve,
That sounds really good (except that I don't know any awk, but maybe it's
a better tool/language for this).
Gawk is great for stuff like this. Many use Perl, but I find that its
complex environment with all its addins makes moving between Linux systems
difficult and moving to say winxp really hard. With Gawk, you just move the
(one!) executable into your path somewhere and a standard awk program will
run anywhere. Its syntax is very C-like but it is interpreted and for
off-line stuff like this is plenty fast.
Here's the one usbmon dump that I generated and used:
http://www.xenotime.net/linux/scripts/usbmon.out
I'll plan to generate some more for both of us to use.
Hi Randy, that dump is helpful. I have a couple of questions on details of
the format:
f09b3a2c 632966030 S Co:000:00 s 00 05 0003 0000 0000 0
f09b3a2c 632966642 C Co:000:00 0 0
f09b3a2c 632996293 S Ci:003:00 s 80 06 0100 0000 0012 18 <
f09b3a2c 632996659 C Ci:003:00 0 18 = 12010002 00000008 f0030461 00010102
0301
f09b3a2c 632996825 S Ci:003:00 s 80 06 0600 0000 000a 10 <
f09b3a2c 632998638 C Ci:003:00 -32 0
f09b3a2c 632998672 S Ci:003:00 s 80 06 0600 0000 000a 10 <
f09b3a2c 633000635 C Ci:003:00 -32 0
f09b3a2c 633000668 S Ci:003:00 s 80 06 0600 0000 000a 10 <
f09b3a2c 633002635 C Ci:003:00 -32 0
f09b3a2c 633002672 S Ci:003:00 s 80 06 0200 0000 0009 9 <
f09b3a2c 633004637 C Ci:003:00 0 9 = 09022000 010100c0 01
Could you please help me understand the format here?
Column1 - some host system memory address, what is it for?
Column2 - some kind of a timestamp?
"S Co:" maybe setup control out?
"S Ci:" maybe setup/control in?
"C Co:" ??
"C Ci:" ??
What other codes are there? Elsewhere I see a "Ii:" maybe interrupt in?
Then 3 digits of device address (in decimal?)
":00" ??? Maybe the endpoint in decimal?
Then "s" to again indicate a setup packet? Followed by 8 bytes from the
setup
packet. The setup packet is in hex as God intended. Then there is another
number,
which seems to be a decimal value of the wLength count for the hex impared?
What does "<" imply?
I would guess that:
"f09b3a2c 633000635 C Ci:003:00 -32 0" indicates a control in with an
error code (-32) and a length of zero? Is there a list of error codes?
The translation of the data is a little harder because USB is little endian
and the bytes of the data packets a built into "words".
For instance on the wire you might see:
SETUP(x2d) addr 0 endp 0 crc5 0x2
DATA0(xc3) 0x00 0x05 0x03 0x00 0x00 0x00 0x00 0x00 crc=0x16eb
ACK(xd2)
And your dump shows:
f09b3a2c 632966030 S Co:000:00 s 00 05 0003 0000 0000 0
f09b3a2c 632966642 C Co:000:00 0 0
Where your dump program translated wValue as little endian for bytes 0x03
0x00.
Now what gets strange is in your dumps of data packets:
f09b3a2c 632996293 S Ci:003:00 s 80 06 0100 0000 0012 18 <
f09b3a2c 632996659 C Ci:003:00 0 18 = 12010002 00000008 f0030461 00010102
0301
Here the data in the setup packet is translated from little endian to a
word, fine.
However the data dump seems to be big endian. For instance it appears on the
wire as:
IN(x69) addr 3 endp 0 crc5 0x15
DATA1(x4b) 0x12 0x01 0x00 0x02 0x00 0x00 0x00 0x08 ....
ACK(xd2)
Apparently there is no indication of data0/data1 or crcs in your data, maybe
they
are generated in H/W on your system.
So if you can clear up the unknowns and where I am wrong, I think I have
enough
info to do the control packet decoders.
Regards ~Steve
-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
