On Sat, Jun 15, 2024 at 12:31:12AM +0200, Andrey Konovalov wrote: > Hi Alan, > > I'm working on implementing a USB proxy that uses libusb on one side > and Raw Gadget on the other. The idea is to pass all requests received > from the host via Raw Gadget to the proxied device via libusb and > report back the responses. > > However, I've stumbled upon an issue with non-0-length control > requests that get stalled by the proxied device. > > To pass an OUT control request to the device via libusb I need to > first retrieve the data for the request from the host. And with Raw > Gadget I can do that via USB_RAW_IOCTL_EP0_READ, which internally > calls usb_ep_queue, waits for its completion, and copies the data to > userspace. > > But the problem is that once I retrieve the data, the request is > automatically acked. Thus, if the proxied device stalls the request, > it's already too late to stall it via Raw Gadget. > > AFAIU, GadgetFS works the same way. > > Is there a way to work around this? If this requires a change is Raw > Gadget, that is fine. But I'm wondering if this is possible to do at > all with the USB Gadget API: AFAIU, we have to either stall or > retrieve the data; we cannot do both. Yeah, this is a known weakness of the Gadget API. There's no way to do it at present. > If this is indeed impossible, perhaps you know if there's a way to > directly use usbfs to separately submit the control request header to > the proxied device to figure out if it wants to stall? And only then > retrieve the data from the host via Raw Gadget if the device doesn't > stall. usbfs allows the user to send a complete transfer, not a partial one (i.e., just the SETUP transaction). Besides, it's not possible for a device to stall a SETUP packet -- the USB-2.0 spec requires devices to respond to SETUP with ACK every time (section 8.5.3) -- so this approach won't solve the problem anyway. And even if it did, you'd still have to handle the situation where the proxy device accepts the SETUP packet and the data but then stalls during the Status stage of the transfer. There has been a patch posted to support UDC drivers that don't automatically acknowledge non-zero-length control-OUT transfers. But the patch hasn't been merged, and even if it were, all the existing UDC drivers would still need to be updated. Sorry, but the kernel just doesn't provide any way to do this. Alan Stern
