Re: usbmon: Extended text API

On 2/25/07, Alan Stern <[email protected]> wrote:
> On Sat, 24 Feb 2007, Jon Smirl wrote:
>
> > On 2/24/07, Pete Zaitcev <[email protected]> wrote:
> > > Also, Jon was hitting some problems with tcpdump and Paolo's libpcap,
> > > so let's keep one more revision stable to help them to figure this out
> > > and bring libpcap into shape. They may yet find a kernel bug too.
> >
> > I wish the bus numbers were stable across boots. I have five buses and
> > I don't see any pattern in how the bus numbers get assigned.
>
> If you don't move things around, they should be fairly stable.  The way
> bus numbers are assigned is pretty simple: Each time a new bus is
> registered it gets the first available number.  Registration occurs in the
> order of driver probing, which depends on two things: PCI device
> discovery and driver loading.  Neither of those should vary too much
> between boots.  If you know what to look for, you can follow the progress
> in detail in the dmesg log.

I seem to be in an unstable race between the ehci and uhci buses for
assigning bus #1.

> > The wireshark packet decoder needs a lot of work. It's not broken, but
> > there are huge amounts of code that need to be written just to finish
> > decoding the low level protocol. The decoder needs to be much further
> > along before I would feel good in saying that the lower layers do what
> > we want. Finishing this is going to need some help from USB experts,
> > there are a lot of obscure things in the USB protocol that I don't
> > know what they do.
>
> Post your questions and we'll try to answer them.

What does this do?
#define USB_ENDPOINT_MAX_ADJUSTABLE     0x80

Are 0x02 and 0x04 supposed to be missing?
#define USB_REQ_GET_STATUS            0x00
#define USB_REQ_CLEAR_FEATURE         0x01
#define USB_REQ_SET_FEATURE           0x03
#define USB_REQ_SET_ADDRESS           0x05
#define USB_REQ_GET_DESCRIPTOR        0x06
#define USB_REQ_SET_DESCRIPTOR        0x07
.....

> > For example, as far as I can tell there is no info in the capture
> > packet stream describing the attached devices unless I so something
> > like "lsusb -v" while data is being captured.
>
> That's true for libpcap in general, isn't it?  If you capture an Ethernet
> session using tcpdump, the packet stream doesn't contain information
> about the remote hosts unless you do a DNS lookup or something similar.

Yes, but you don't need the remote host DNS data to fully decode the
stream protocol. I can't fully decode my protocol if I don't know the
USB device ID of the device that generated it. That's the problem with
all of the vendor specific data formats.


>
> >  I want to write a
> > decoder for device ID 2001:3c00, a ralink wireless dongle. I can't do
> > this because I can't tell the device ID of the streams being recorded.
> > Somebody (libpcap or the kernel) needs to automatically query the
> > descriptors when the monitor stream is first opened so that the
> > descriptor data will get recorded and I can tell what devices are
> > present. It would be best if this data was the first data recorded in
> > every session. It also needs to track hot plugs.
>
> This should be done by the user program, just the way tcpdump does it.
> When you run the capture program you tell it what device you're interested
> in.  The program looks up the device ID and finds the device's address;
> then it can filter just the packets for that address.  I guess that's
> built into libpcap.
>
> Tracking hot plugs doesn't seem necessary.  It's like saying that tcpdump
> should track every time a new computer is added to your network.

Hotplugs are already visible they generate a bunch of traffic when
device is un/plugged in. When a new device is plugged in the
descriptors need to be enumerated so that the device can be
identified. I suspect the kernel does this anyway so that it knows
what module to load and usbmon will capture it.

> > At a minimum I think we should have decoders for HID, audio and mass
> > storage working before committing everything to stone. Those three
> > device classes each use USB quite differently.
>
> Add hubs to the list, plus general Chapter-9 requests.

This is a lot of decoding code to write. It is not hard but it
requires you to understand the binary format of the protocols. More
people helping with make this happen faster.

-- 
Jon Smirl
[email protected]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel