Hi all, I'm implementing a simple USB device using gadgetfs and dummy_udc to help reverse engineer a physical USB device which can only be used with a Windows-based closed-source application. I figure if I can get the Windows app talking to my virtual device then I can fiddle with the values it returns and observe what changes this triggers in the app. So far I have implemented the device basics and it correctly gets identified by lsusb as a HID device, almost exactly like the actual hardware device (the exception being the real hardware is USB1.1 only, but gadgetfs only seems to support USB2.0 devices.) I'm running WinXP through VirtualBox and XP correctly detects my gadgetfs device and uses its HID driver for it. When I run the closed-source app to access the device, it works by sending control messages to the device and getting interrupt messages in response. With the gadgetfs "device" I receive the control message and send a response to the interrupt endpoint without any error, but not only does XP never receive the interrupt message, usbmon doesn't show it either - which seems to indicate that gadgetfs isn't sending the interrupt message over the virtual USB bus. If I run my own client under Linux then it works fine, I can send a control message and receive an interrupt in response, although interestingly enough if I run my client *after* the WinXP app, I receive the interrupt message that was supposed to go to the XP app instead - so it seems that gadgetfs is storing the interrupt data but it must be waiting for a read operation to come along instead of sending the interrupt immediately. Is there some limitation in gadgetfs that might cause this? I'm a bit stuck as to what it might be or where to look next. The only thing I can think of is that the hardware device indicates the maximum packet size is only eight bytes (usb_device_descriptor.bMaxPacketSize0), but the comments in the example client suggest gadgetfs fills this out itself - which in my case sets it to 64 bytes instead of the eight bytes the hardware device reports. I have however tried padding my interrupt responses with 56 bytes to get it up to the 64 byte max size, but it didn't do anything (apart from sending a ton of 0x00 interrupt responses after the original one!) so I don't think that's the problem. Does anyone know why these interrupt messages are not being sent? Does the host need to be notified when an interrupt message comes along and this isn't happening? Thanks, Adam. -- 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
