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 _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
