On Thu, May 14, 2009 at 10:25 AM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > On Thu, 14 May 2009, Steve Hardy wrote: > > > Hi all, > > > > I am considering writing a gadget device driver which would act as > > both a USB host and device, for use as a USB sniffer. > > If I understand you correctly, you want to hook the device's peripheral > interface to some host and your device's host controller to another > device, and then make your device act as a sort of relay, transferring > packets from the other host to the other device and vice versa. Is > that right? > > > My intention is to use a simple, low cost ARM development board like > > the Olimex SAM9-L9260, which has both usb host and device > > capabilities. > > > > I have seen this idea proposed as a Beagleboard SoC project > > (http://elinux.org/BeagleBoard/Ideas-2009#USB_sniffer), but otherwise > > have not found any evidence that someone else is actively working on > > such a capability. > > That's because it can't be done. The timing requirements are too > tight, for one thing. Your device would have to send a response back > to the host before it got the real response back from the other device. > > Maybe you could make it work if you restricted yourself to control and > bulk transfers. > > > I have driver and some USB experience, so am happy to just get hacking > > and see how it goes, but I am keen to avoid duplicating effort if > > something similar has been attempted already. > > > > Can anyone provide any thoughts, links or ideas related to this before I start? > > Some years ago, Steve Calfee made something similar. It doesn't act as > a relay; instead it just monitors the signals on the USB cable and > stores the data. I can't find his announcement in the email archives, > though. > Hi Alan, Yes, but what I did was make a real usb bus analyzer ala catc or beagle. Alan is right, you cannot meet the usb bus timings where an ACK has to be received within so many usb bus clocks (around 24?) around (2 usec at FS clock) maximum. A bus analyzer is a wire tap. It sees everything on the wire and reports it in some kind of GUI. This allows showing non signaling bus data too, such as reset, otg signalling, in HS chirp signaling. The bit level timing information is very useful to hardware debugging guys etc. What you are proposing is a man-in-the-middle attack. That might be very useful for doing software driver debugging. It is very much what usbmon does. However what you propose might be somewhat better because it shows a slightly lower level view of what was actually on the wire, not what some software intended to go on the wire. If you really do want to extend the usbmon like this you might look into usb/ip. There the data is actually traveling over ethernet where other tools (wireshark) can be used to look at it. To me, the additional benefit of this kind of tap over usbmon is not worth the effort. And for serious development, the Beagle is probably cheaper than a usb gadget interface for the pc. By the way, Iso transfers are the easiest to do an analyzer on because there is no handshaking. Regards, Steve -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
