Hello linux-usb. currently it seems most network interfaces (ethernet + wifi) can not be forwarded using usbip. my context for the problem is QubesOS, which uses usbip (over ipc sockets instead of tcp) to pass around usb devices between xen vms. there are enough different reports to make it unlikely it is a hardware issue. https://github.com/QubesOS/qubes-issues/issues/3778 a check with two plain fedora installs shows the same problem, so it does not seem to be anything qubes specific either. additional testing was performed using kernel 5.1.6 on qubes for convenience. a quick git/log check against current 5.2 and 5.3 says there have not been any relevant changes since then. comparing USBIP_DEBUG traces for working and non-working devices says things go wrong if/when the receiving side device-specific driver tries to reset the device as part of its firmware+config intialization ritual. this seems to be very common for network drivers. the reset is caught+handled receiver side in vhci_hcd and is never passed on to the giver side. on the giver side, there is code for handling reset urbs in stub_rx. i was unable to determine whether this ever worked or is just a code artifact, so i am unsure how to proceed. if there is an urb for the reset somewhere, its probably in whatever calls vhci_hub_control through the hc_driver.hub_control abstraction. should it just make sure that urb is passed on to the giver? i added code to make up a reset urb from scratch in vhci_hcd, and toss it over to stub_rx which actualy makes the reset code trigger, but then get lost in what feels like usb device state engine hell. currently the code in stub_rx submits the tweak-handled urbs anyways, with a comment indicating that may or may not be a good idea. adding code to not submit the reset urb just leads to a different-flavored mess of timeouts and small explosions. my current guesses are i either need to send some additional message or something gets dropped because it happens while the 50ms reset on the giver side is still ongoing at the time. please advise on how to proceed with this, i would feel more comfortable randomly stumbling around kernel source if i knew i was headed in the right direction. ;) of course i would also settle for an "ugh, fixed" without any additional explanation. regards, x23
