> 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? Yes, that's exactly right. I was thinking if the device can relay the USB data in both directions, then it should be fairly simple to implement monitor/capture/replay functionality in the middle. > Maybe you could make it work if you restricted yourself to control and > bulk transfers. That would be fine for my applications (debugging USB drivers, no isochronous EP's), but granted not universally useful. > Acting as a relay, right? Yes > My advice is not to spend too much time on it. Think through the > possible limitations and pitfalls first. That was my motivation for posting to this list :) Thanks for the feedback! 2009/5/14 Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>: > 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. > >> I'm guessing I will need to start with skeleton USB host and gadget >> drivers, and the host driver will have to talk to the gadget driver >> such that the gadget mimics the vendor/product IDs and EP topology of >> the device under test. Then URBs in each direction will require >> forwarding in an efficient manner such that the USB data is fairly >> transparently "passed through" the driver/drivers. > > Acting as a relay, right? > >> For the actual sniffing, I just expect to use the usbmon module. >> >> Any thoughts appreciated! > > My advice is not to spend too much time on it. Think through the > possible limitations and pitfalls first. > > Alan Stern > > -- 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
