ReadME of Linux USB Logger 0.6
******************************
------------------------------
Changelog 0.6:

- view log option
- library dependencies check
- 32Bit version added
------------------------------
------------------------------
Changelog 0.5:

- code clean up
- less cpu power need

------------------------------

1) Application only works with root privileges (sudo ./usblogger)

2) Logs are saved in /tmp/

3) Logs are saved as usb_log.out

4) How to analyze the raw data?:

String from left tp right:

- URB Tag. This is used to identify URBs is normally a kernel mode address
 of the URB structure in hexadecimal.

- Timestamp in microseconds, a decimal number. The timestamp's resolution
  depends on available clock, and so it can be much worse than a microsecond
  (if the implementation uses jiffies, for example).

- Event Type. This type refers to the format of the event, not URB type.
  Available types are: S - submission, C - callback, E - submission error.

- "Address" word (formerly a "pipe"). It consists of four fields, separated by
  colons: URB type and direction, Bus number, Device address, Endpoint number.
  Type and direction are encoded with two bytes in the following manner:
    Ci Co   Control input and output
    Zi Zo   Isochronous input and output
    Ii Io   Interrupt input and output
    Bi Bo   Bulk input and output
  Bus number, Device address, and Endpoint are decimal numbers, but they may
  have leading zeros, for the sake of human readers.

- URB Status word. This is either a letter, or several numbers separated
  by colons: URB status, interval, start frame, and error count. Unlike the
  "address" word, all fields save the status are optional. Interval is printed
  only for interrupt and isochronous URBs. Start frame is printed only for
  isochronous URBs. Error count is printed only for isochronous callback
  events.

  The status field is a decimal number, sometimes negative, which represents
  a "status" field of the URB. This field makes no sense for submissions, but
  is present anyway to help scripts with parsing. When an error occurs, the
  field contains the error code.

  In case of a submission of a Control packet, this field contains a Setup Tag
  instead of an group of numbers. It is easy to tell whether the Setup Tag is
  present because it is never a number. Thus if scripts find a set of numbers
  in this word, they proceed to read Data Length (except for isochronous URBs).
  If they find something else, like a letter, they read the setup packet before
  reading the Data Length or isochronous descriptors.

- Setup packet, if present, consists of 5 words: one of each for bmRequestType,
  bRequest, wValue, wIndex, wLength, as specified by the USB Specification 2.0.
  These words are safe to decode if Setup Tag was 's'. Otherwise, the setup
  packet was present, but not captured, and the fields contain filler.

- Number of isochronous frame descriptors and descriptors themselves.
  If an Isochronous transfer event has a set of descriptors, a total number
  of them in an URB is printed first, then a word per descriptor, up to a
  total of 5. The word consists of 3 colon-separated decimal numbers for
  status, offset, and length respectively. For submissions, initial length
  is reported. For callbacks, actual length is reported.

- Data Length. For submissions, this is the requested length. For callbacks,
  this is the actual length.

- Data tag. The usbmon may not always capture data, even if length is nonzero.
  The data words are present only if this tag is '='.

- Data words follow, in big endian hexadecimal format. Notice that they are
  not machine words, but really just a byte stream split into words to make
  it easier to read. Thus, the last word may contain from one to four bytes.
  The length of collected data is limited and can be less than the data length
  report in Data Length word.

thanks to corbet for the explaination

5) Successfully tested on:

- Ubuntu 8.10 64Bit
- Yellow Dog Linux PPC

6) Known problems:

none

7) Problem reporting:

skfuinfo@googlemail.com

8) Future:

- log single usb ports
- user modify output path
- user modify output file

9) Library dependencies:

Library dependencies 32Bit:
linux-gate.so.1 => (0xf7f2a000)
libstdc++.so.6 => /usr/lib32/libstdc++.so.6 (0xf7e23000)
libm.so.6 => /lib32/libm.so.6 (0xf7dfd000)
libgcc_s.so.1 => /usr/lib32/libgcc_s.so.1 (0xf7ded000)
libc.so.6 => /lib32/libc.so.6 (0xf7c8f000)
/lib/ld-linux.so.2 (0xf7f2b000)

Library dependencies 64Bit:
linux-vdso.so.1 => (0x00007fffb0ffe000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f9ca8a25000)
libm.so.6 => /lib/libm.so.6 (0x00007f9ca87a0000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007f9ca8588000)
libc.so.6 => /lib/libc.so.6 (0x00007f9ca8216000)
/lib64/ld-linux-x86-64.so.2 (0x00007f9ca8d32000)

10) For the dependencies check in the application itself, you need "getlibs" package.
