usbip doesn't work with userspace code that accesses USB devices
Qubes OS users are reporting that MTP doesn't work with USB passthrough. Fastboot (used for flashing a custom OS to an Android device) also doesn't work. Kernel-mode drivers, such as Bluetooth and USB storage, seem to usually work as expected. Since MTP and fastboot are both implemented in userspace, it appears that there is some problem with the interaction of usbip, our USB proxy (which is based on USBIP), and userspace programs that interact with USB devices directly.
The bug report can be found at [1] and the source code for the USB proxy can be found at [2]. The script used on the sending side (the one with the physical USB controller) is at [3] and the script used by the receiving side (the one the device is attached to) is at [4]. All of these links are for the current version as of this email being sent, so that anyone looking at this email in the future doesn't get confused.
Is this a bug in usbip, or is this due to usbip being used incorrectly? I'm happy to provide additional information needed to debug the problem, but I don't have access to the reporter's system.
[1]: https://github.com/QubesOS/qubes-issues/issues/6330
[2]: https://github.com/QubesOS/qubes-app-linux-usb-proxy/tree/57ab3940d450b18e570da57886d65cb5707aa60f
[3]: https://github.com/QubesOS/qubes-app-linux-usb-proxy/blob/57ab3940d450b18e570da57886d65cb5707aa60f/src/usb-export
[4]: https://github.com/QubesOS/qubes-app-linux-usb-proxy/blob/57ab3940d450b18e570da57886d65cb5707aa60f/src/usb-import
Signature · 3 lines
Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab
Greg KH
maintainerQuoted 8 lines · Demi Marie Obenour
Qubes OS users are reporting that MTP doesn't work with USB passthrough. Fastboot (used for flashing a custom OS to an Android device) also doesn't work. Kernel-mode drivers, such as Bluetooth and USB storage, seem to usually work as expected. Since MTP and fastboot are both implemented in userspace, it appears that there is some problem with the interaction of usbip, our USB proxy (which is based on USBIP), and userspace programs that interact with USB devices directly.
Quoted 8 lines
The bug report can be found at [1] and the source code for the USB proxy can be found at [2]. The script used on the sending side (the one with the physical USB controller) is at [3] and the script used by the receiving side (the one the device is attached to) is at [4]. All of these links are for the current version as of this email being sent, so that anyone looking at this email in the future doesn't get confused.
Is this a bug in usbip, or is this due to usbip being used incorrectly?
I'm amazed that usbip works with usbfs at all, I didn't think that was a thing.
If you have a reproducer, or some error messages somewhere, that might be the easiest way forward. In reading the bug report, it looks like the "bridge" you all made can't handle the device disconnecting itself properly? But that's just a guess, could be anything.
thanks,
greg k-h
Quoted 18 lines · Greg KH
Quoted 8 lines · Demi Marie Obenour
Qubes OS users are reporting that MTP doesn't work with USB passthrough. Fastboot (used for flashing a custom OS to an Android device) also doesn't work. Kernel-mode drivers, such as Bluetooth and USB storage, seem to usually work as expected. Since MTP and fastboot are both implemented in userspace, it appears that there is some problem with the interaction of usbip, our USB proxy (which is based on USBIP), and userspace programs that interact with USB devices directly.
Quoted 8 lines
The bug report can be found at [1] and the source code for the USB proxy can be found at [2]. The script used on the sending side (the one with the physical USB controller) is at [3] and the script used by the receiving side (the one the device is attached to) is at [4]. All of these links are for the current version as of this email being sent, so that anyone looking at this email in the future doesn't get confused.
Is this a bug in usbip, or is this due to usbip being used incorrectly?
Quoted 7 lines
I'm amazed that usbip works with usbfs at all, I didn't think that was a thing.
If you have a reproducer, or some error messages somewhere, that might be the easiest way forward. In reading the bug report, it looks like the "bridge" you all made can't handle the device disconnecting itself properly? But that's just a guess, could be anything.
Device disconnecting itself indeed is an issue (our proxy doesn't automatically reconnect it, at least not yet). But that's definitely not the only issue, things break also when disconnect is not involved.
Terminology:
1. sys-usb - a VM where USB controller (a PCI device) lives; here usbip-host is attached to the device
2. testvm - target VM where usbip is connected; here vhci-hcd is used
3. qvm-usb - tool that connects the above two (equivalent of userspace part of standard usbip)
Specific steps:
1. Connect android phone - at this point it's only in sys-usb
2. Switch its mode to file transfer - observe reconnect in sys-usb
3. Use qvm-usb to attach it to the testvm
4. Call jmtpfs -d /mnt in testvm
It fails this way:
Device 0 (VID=18d1 and PID=4ee1) is a Google Inc Nexus/Pixel (MTP).
PTP_ERROR_IO: failed to open session, trying again after resetting USB interface LIBMTP libusb: Attempt to reset device
LIBMTP PANIC: failed to open session on second attempt
Cannot open requested device
There is a short wait before first failure and then the reset fails as well (interestingly, device doesn't actually reset, it stays connected).
At that time, testvm's dmesg shows:
[2126560.758005] vhci_hcd: unlink->seqnum 98
[2126560.758025] vhci_hcd: urb->status -104
[2126560.872413] usb 1-1: reset high-speed USB device number 3 using vhci_hcd
[2126560.992995] usb 1-1: SetAddress Request (3) to port 0
[2126561.162264] usb 1-1: reset high-speed USB device number 3 using vhci_hcd
[2126561.278584] usb 1-1: SetAddress Request (3) to port 0And sys-usb's dmesg:
[915567.691431] usbip-host 2-1: unlinked by a call to usb_unlink_urb()
I've observed it also with wireshark in testvm, and there is a single packet sent (before the attempt to reset):
Frame 90: 80 bytes on wire (640 bits), 80 bytes captured (640 bits) on interface usbmon1, id 0
USB URB
[Source: host]
[Destination: 1.3.1]
URB id: 0xffff888007cbaa80
URB type: URB_SUBMIT ('S')
URB transfer type: URB_BULK (0x03)
Endpoint: 0x01, Direction: OUT
Device: 3
URB bus id: 1
Device setup request: not relevant ('-')
Data: present ('\0')
URB sec: 1709589466
URB usec: 80050
URB status: Operation now in progress (-EINPROGRESS) (-115)
URB length [bytes]: 16
Data length [bytes]: 16
[Response in: 91]
[bInterfaceClass: Imaging (0x06)]
Unused Setup Header
Interval: 0
Start frame: 0
Copy of Transfer Flags: 0x00000000
Number of ISO descriptors: 0
Leftover Capture Data: 10000000010002100000000001000000And the same seen in sys-usb:
Frame 117: 80 bytes on wire (640 bits), 80 bytes captured (640 bits) on interface usbmon2, id 0
USB URB
[Source: host]
[Destination: 2.18.1]
URB id: 0xffff908b585f5480
URB type: URB_SUBMIT ('S')
URB transfer type: URB_BULK (0x03)
Endpoint: 0x01, Direction: OUT
Device: 18
URB bus id: 2
Device setup request: not relevant ('-')
Data: present ('\0')
URB sec: 1709591829
URB usec: 752585
URB status: Operation now in progress (-EINPROGRESS) (-115)
URB length [bytes]: 16
Data length [bytes]: 16
[Response in: 118]
[bInterfaceClass: Imaging (0x06)]
Unused Setup Header
Interval: 0
Start frame: 0
Copy of Transfer Flags: 0x00000000
Number of ISO descriptors: 0
Leftover Capture Data: 10000000010002100000000001000000And after few seconds it gets this "response":
Frame 91: 64 bytes on wire (512 bits), 64 bytes captured (512 bits) on interface usbmon1, id 0
USB URB
[Source: 1.3.1]
[Destination: host]
URB id: 0xffff888007cbaa80
URB type: URB_COMPLETE ('C')
URB transfer type: URB_BULK (0x03)
Endpoint: 0x01, Direction: OUT
Device: 3
URB bus id: 1
Device setup request: not relevant ('-')
Data: not present ('>')
URB sec: 1709589471
URB usec: 83920
URB status: No such file or directory (-ENOENT) (-2)
URB length [bytes]: 0
Data length [bytes]: 0
[Request in: 90]
[Time from request: 5.003870000 seconds]
[bInterfaceClass: Imaging (0x06)]
Unused Setup Header
Interval: 0
Start frame: 0
Copy of Transfer Flags: 0x00000000
Number of ISO descriptors: 0and the same seen in sys-usb:
Frame 118: 64 bytes on wire (512 bits), 64 bytes captured (512 bits) on interface usbmon2, id 0
USB URB
[Source: 2.18.1]
[Destination: host]
URB id: 0xffff908b585f5480
URB type: URB_COMPLETE ('C')
URB transfer type: URB_BULK (0x03)
Endpoint: 0x01, Direction: OUT
Device: 18
URB bus id: 2
Device setup request: not relevant ('-')
Data: not present ('>')
URB sec: 1709591834
URB usec: 753529
URB status: Connection reset by peer (-ECONNRESET) (-104)
URB length [bytes]: 0
Data length [bytes]: 0
[Request in: 117]
[Time from request: 5.000944000 seconds]
[bInterfaceClass: Imaging (0x06)]
Unused Setup Header
Interval: 0
Start frame: 0
Copy of Transfer Flags: 0x00000000
Number of ISO descriptors: 0Calling jmtpfs directly in sys-usb succeeds without device reset:
Device 0 (VID=18d1 and PID=4ee1) is a Google Inc Nexus/Pixel (MTP).
Android device detected, assigning default bug flags
FUSE library version: 2.9.9
nullpath_ok: 0
nopath: 0
utime_omit_ok: 0
unique: 2, opcode: INIT (26), nodeid: 0, insize: 104, pid: 0
INIT: 7.37
flags=0x73fffffb
max_readahead=0x00020000
INIT: 7.19
flags=0x00000011
max_readahead=0x00020000
max_write=0x00020000
max_background=0
congestion_threshold=0
unique: 2, success, outsize: 40At that time, looking at wireshark in sys-usb, I see similar URB_BULK sent:
Frame 1171: 80 bytes on wire (640 bits), 80 bytes captured (640 bits) on interface usbmon2, id 0
USB URB
[Source: host]
[Destination: 2.18.1]
URB id: 0xffff908b4fe92180
URB type: URB_SUBMIT ('S')
URB transfer type: URB_BULK (0x03)
Endpoint: 0x01, Direction: OUT
Device: 18
URB bus id: 2
Device setup request: not relevant ('-')
Data: present ('\0')
URB sec: 1709591408
URB usec: 157571
URB status: Operation now in progress (-EINPROGRESS) (-115)
URB length [bytes]: 16
Data length [bytes]: 16
[Response in: 1172]
[bInterfaceClass: Imaging (0x06)]
Unused Setup Header
Interval: 0
Start frame: 0
Copy of Transfer Flags: 0x00000000
Number of ISO descriptors: 0
Leftover Capture Data: 10000000010002100000000001000000but this time it gets a response:
Frame 1172: 64 bytes on wire (512 bits), 64 bytes captured (512 bits) on interface usbmon2, id 0
USB URB
[Source: 2.18.1]
[Destination: host]
URB id: 0xffff908b4fe92180
URB type: URB_COMPLETE ('C')
URB transfer type: URB_BULK (0x03)
Endpoint: 0x01, Direction: OUT
Device: 18
URB bus id: 2
Device setup request: not relevant ('-')
Data: not present ('>')
URB sec: 1709591408
URB usec: 157806
URB status: Success (0)
URB length [bytes]: 16
Data length [bytes]: 0
[Request in: 1171]
[Time from request: 0.000235000 seconds]
[bInterfaceClass: Imaging (0x06)]
Unused Setup Header
Interval: 0
Start frame: 0
Copy of Transfer Flags: 0x00000000
Number of ISO descriptors: 0I'm happy to provide more information, debug logs etc, just tell me what :)
Signature · 3 lines
Best Regards, Marek Marczykowski-Górecki Invisible Things Lab
Quoted 38 lines · Marek Marczykowski-Górecki
Quoted 18 lines · Greg KH
Quoted 8 lines · Demi Marie Obenour
Qubes OS users are reporting that MTP doesn't work with USB passthrough. Fastboot (used for flashing a custom OS to an Android device) also doesn't work. Kernel-mode drivers, such as Bluetooth and USB storage, seem to usually work as expected. Since MTP and fastboot are both implemented in userspace, it appears that there is some problem with the interaction of usbip, our USB proxy (which is based on USBIP), and userspace programs that interact with USB devices directly.
Quoted 8 lines
The bug report can be found at [1] and the source code for the USB proxy can be found at [2]. The script used on the sending side (the one with the physical USB controller) is at [3] and the script used by the receiving side (the one the device is attached to) is at [4]. All of these links are for the current version as of this email being sent, so that anyone looking at this email in the future doesn't get confused.
Is this a bug in usbip, or is this due to usbip being used incorrectly?
Quoted 7 lines
I'm amazed that usbip works with usbfs at all, I didn't think that was a thing.
If you have a reproducer, or some error messages somewhere, that might be the easiest way forward. In reading the bug report, it looks like the "bridge" you all made can't handle the device disconnecting itself properly? But that's just a guess, could be anything.
Device disconnecting itself indeed is an issue (our proxy doesn't automatically reconnect it, at least not yet). But that's definitely not the only issue, things break also when disconnect is not involved.
Terminology:
1. sys-usb - a VM where USB controller (a PCI device) lives; here usbip-host is attached to the device
2. testvm - target VM where usbip is connected; here vhci-hcd is used
3. qvm-usb - tool that connects the above two (equivalent of userspace part of standard usbip)
Quoted 5 lines
Specific steps:
1. Connect android phone - at this point it's only in sys-usb
2. Switch its mode to file transfer - observe reconnect in sys-usb
3. Use qvm-usb to attach it to the testvm
4. Call jmtpfs -d /mnt in testvm
Or maybe reset or something is involved here too?
After using qvm-usb to attach _and detach_ the device, it stays bound to usbip-host driver (that's intentional). But then, even after re-binding back to the "usb" driver, jmtpfs called in sys-usb directly fails the same way, including failure to reset.
In fact, even without usbip involved at all, jmtpfs directly in sys-usb works only once. The second attempt (without either physically reconnecting the phone, or changing its more to "no data transfer" and back to "file transfer") fails the same way. After terminating the first instance, I see just this logged:
[921332.525210] usb 2-1: reset high-speed USB device number 22 using xhci_hcd
Since both problematic cases involve Android, maybe the actual issue is somewhere in Android instead of usbip? But then, fastboot could be a completely different issue, likely related to reconnection (this one I haven't tried to reproduce, and can't find much details in our issues tracker).
On the other hand, USB tethering works just fine, so at least some Android functions do work with usbip (but then, it's a kernel driver, not usbfs).
Could be also an issue with just MTP implementation on either side of the connection (I did tried also gvfs instead of jmtpfs with similar result, but they likely use the same implementation). Since that's Android, the device side is Linux too, but I don't know how MTP is implemented there (I don't see MTP gadget function in upstream Linux).
Signature · 3 lines
Best Regards, Marek Marczykowski-Górecki Invisible Things Lab
Quoted 52 lines · Marek Marczykowski-Górecki
Quoted 38 lines · Marek Marczykowski-Górecki
Quoted 18 lines · Greg KH
Quoted 8 lines · Demi Marie Obenour
Qubes OS users are reporting that MTP doesn't work with USB passthrough. Fastboot (used for flashing a custom OS to an Android device) also doesn't work. Kernel-mode drivers, such as Bluetooth and USB storage, seem to usually work as expected. Since MTP and fastboot are both implemented in userspace, it appears that there is some problem with the interaction of usbip, our USB proxy (which is based on USBIP), and userspace programs that interact with USB devices directly.
Quoted 8 lines
The bug report can be found at [1] and the source code for the USB proxy can be found at [2]. The script used on the sending side (the one with the physical USB controller) is at [3] and the script used by the receiving side (the one the device is attached to) is at [4]. All of these links are for the current version as of this email being sent, so that anyone looking at this email in the future doesn't get confused.
Is this a bug in usbip, or is this due to usbip being used incorrectly?
Quoted 7 lines
I'm amazed that usbip works with usbfs at all, I didn't think that was a thing.
If you have a reproducer, or some error messages somewhere, that might be the easiest way forward. In reading the bug report, it looks like the "bridge" you all made can't handle the device disconnecting itself properly? But that's just a guess, could be anything.
Device disconnecting itself indeed is an issue (our proxy doesn't automatically reconnect it, at least not yet). But that's definitely not the only issue, things break also when disconnect is not involved.
Terminology:
1. sys-usb - a VM where USB controller (a PCI device) lives; here usbip-host is attached to the device
2. testvm - target VM where usbip is connected; here vhci-hcd is used
3. qvm-usb - tool that connects the above two (equivalent of userspace part of standard usbip)Quoted 5 lines
Specific steps:
1. Connect android phone - at this point it's only in sys-usb
2. Switch its mode to file transfer - observe reconnect in sys-usb
3. Use qvm-usb to attach it to the testvm
4. Call jmtpfs -d /mnt in testvmOr maybe reset or something is involved here too?
After using qvm-usb to attach
_anddetach_the device, it stays bound to usbip-host driver (that's intentional). But then, even after re-binding back to the "usb" driver, jmtpfs called in sys-usb directly fails the same way, including failure to reset.
Quoted 7 lines
In fact, even without usbip involved at all, jmtpfs directly in sys-usb works only once. The second attempt (without either physically reconnecting the phone, or changing its more to "no data transfer" and back to "file transfer") fails the same way. After terminating the first instance, I see just this logged:
[921332.525210] usb 2-1: reset high-speed USB device number 22 using xhci_hcd
What happens if the device is not bound to _any_ driver in sys-usb? For instance, does the problem go away if the only USB-related drivers in sys-usb are xhci-pci, usbip-host, and their dependencies? If not, what about if sys-usb's kernel has no other USB-related drivers included at all?
Also, if you have not done so already, could you try uninstalling gvfs from sys-usb's template? gvfs might be interacting with the device. Using a -minimal template might help.
Quoted 5 lines
Since both problematic cases involve Android, maybe the actual issue is somewhere in Android instead of usbip? But then, fastboot could be a completely different issue, likely related to reconnection (this one I haven't tried to reproduce, and can't find much details in our issues tracker).
Quoted 8 lines
On the other hand, USB tethering works just fine, so at least some Android functions do work with usbip (but then, it's a kernel driver, not usbfs).
Could be also an issue with just MTP implementation on either side of the connection (I did tried also gvfs instead of jmtpfs with similar result, but they likely use the same implementation). Since that's Android, the device side is Linux too, but I don't know how MTP is implemented there (I don't see MTP gadget function in upstream Linux).
I suspect MTP is implemented in userspace somewhere in AOSP.
Signature · 3 lines
Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab
Quoted 59 lines · Demi Marie Obenour
Quoted 58 lines · Marek Marczykowski-Górecki
Quoted 38 lines · Marek Marczykowski-Górecki
Quoted 18 lines · Greg KH
Quoted 8 lines · Demi Marie Obenour
Qubes OS users are reporting that MTP doesn't work with USB passthrough. Fastboot (used for flashing a custom OS to an Android device) also doesn't work. Kernel-mode drivers, such as Bluetooth and USB storage, seem to usually work as expected. Since MTP and fastboot are both implemented in userspace, it appears that there is some problem with the interaction of usbip, our USB proxy (which is based on USBIP), and userspace programs that interact with USB devices directly.
Quoted 8 lines
The bug report can be found at [1] and the source code for the USB proxy can be found at [2]. The script used on the sending side (the one with the physical USB controller) is at [3] and the script used by the receiving side (the one the device is attached to) is at [4]. All of these links are for the current version as of this email being sent, so that anyone looking at this email in the future doesn't get confused.
Is this a bug in usbip, or is this due to usbip being used incorrectly?
Quoted 7 lines
I'm amazed that usbip works with usbfs at all, I didn't think that was a thing.
If you have a reproducer, or some error messages somewhere, that might be the easiest way forward. In reading the bug report, it looks like the "bridge" you all made can't handle the device disconnecting itself properly? But that's just a guess, could be anything.
Device disconnecting itself indeed is an issue (our proxy doesn't automatically reconnect it, at least not yet). But that's definitely not the only issue, things break also when disconnect is not involved.
Terminology:
1. sys-usb - a VM where USB controller (a PCI device) lives; here usbip-host is attached to the device
2. testvm - target VM where usbip is connected; here vhci-hcd is used
3. qvm-usb - tool that connects the above two (equivalent of userspace part of standard usbip)Quoted 5 lines
Specific steps:
1. Connect android phone - at this point it's only in sys-usb
2. Switch its mode to file transfer - observe reconnect in sys-usb
3. Use qvm-usb to attach it to the testvm
4. Call jmtpfs -d /mnt in testvmOr maybe reset or something is involved here too?
After using qvm-usb to attach
_anddetach_the device, it stays bound to usbip-host driver (that's intentional). But then, even after re-binding back to the "usb" driver, jmtpfs called in sys-usb directly fails the same way, including failure to reset.In fact, even without usbip involved at all, jmtpfs directly in sys-usb works only once. The second attempt (without either physically reconnecting the phone, or changing its more to "no data transfer" and back to "file transfer") fails the same way. After terminating the first instance, I see just this logged:
Quoted 7 lines
Quoted 1 line
[921332.525210] usb 2-1: reset high-speed USB device number 22 using xhci_hcdWhat happens if the device is not bound to _any_ driver in sys-usb? For instance, does the problem go away if the only USB-related drivers in sys-usb are xhci-pci, usbip-host, and their dependencies? If not, what about if sys-usb's kernel has no other USB-related drivers included at all?
I don't think I can get rid of the "usb" driver, and that's what binds to the device. There is no driver bound to the first interface of the device (2-1:1.0) at all.
Quoted 3 lines
Also, if you have not done so already, could you try uninstalling gvfs from sys-usb's template? gvfs might be interacting with the device. Using a -minimal template might help.
I highly doubt it would change anything.
Quoted 15 lines
Quoted 5 lines
Since both problematic cases involve Android, maybe the actual issue is somewhere in Android instead of usbip? But then, fastboot could be a completely different issue, likely related to reconnection (this one I haven't tried to reproduce, and can't find much details in our issues tracker).
Quoted 8 lines
On the other hand, USB tethering works just fine, so at least some Android functions do work with usbip (but then, it's a kernel driver, not usbfs).
Could be also an issue with just MTP implementation on either side of the connection (I did tried also gvfs instead of jmtpfs with similar result, but they likely use the same implementation). Since that's Android, the device side is Linux too, but I don't know how MTP is implemented there (I don't see MTP gadget function in upstream Linux).I suspect MTP is implemented in userspace somewhere in AOSP.
Signature · 3 lines
Best Regards, Marek Marczykowski-Górecki Invisible Things Lab
Quoted 21 lines · Marek Marczykowski-Górecki
Quoted 7 lines · Marek Marczykowski-Górecki
Terminology:
1. sys-usb - a VM where USB controller (a PCI device) lives; here usbip-host is attached to the device
2. testvm - target VM where usbip is connected; here vhci-hcd is used
3. qvm-usb - tool that connects the above two (equivalent of userspace part of standard usbip)Quoted 5 lines
Specific steps:
1. Connect android phone - at this point it's only in sys-usb
2. Switch its mode to file transfer - observe reconnect in sys-usb
3. Use qvm-usb to attach it to the testvm
4. Call jmtpfs -d /mnt in testvmOr maybe reset or something is involved here too?
After using qvm-usb to attach
_anddetach_the device, it stays bound to usbip-host driver (that's intentional). But then, even after re-binding back to the "usb" driver, jmtpfs called in sys-usb directly fails the same way, including failure to reset.
Quoted 7 lines
In fact, even without usbip involved at all, jmtpfs directly in sys-usb works only once. The second attempt (without either physically reconnecting the phone, or changing its more to "no data transfer" and back to "file transfer") fails the same way. After terminating the first instance, I see just this logged:
[921332.525210] usb 2-1: reset high-speed USB device number 22 using xhci_hcd
If something doesn't work when usbip isn't involved, you definitely shouldn't expect it to work when usbip _is_ involved.
It sounds like you're facing more than one type of problem. The best approach is to attack them separately.
I'd start with problems that exist only on sys-usb first -- keeping usbip out of the picture will make everything much simpler. You can try capturing a usbmon trace, starting from before the phone is attached, and continuing on through the mode changes and failures. In fact, break it up into several traces, each starting just before one of the major events (initial plug-in, mode change, whatever).
Once that's under control, I suggest using usbmon on both sides (sys-usb and testvm) of the usbip connection. But start without usbip.
Alan Stern
Quoted 28 lines · Alan Stern
Quoted 27 lines · Marek Marczykowski-Górecki
Quoted 7 lines · Marek Marczykowski-Górecki
Terminology:
1. sys-usb - a VM where USB controller (a PCI device) lives; here usbip-host is attached to the device
2. testvm - target VM where usbip is connected; here vhci-hcd is used
3. qvm-usb - tool that connects the above two (equivalent of userspace part of standard usbip)Quoted 5 lines
Specific steps:
1. Connect android phone - at this point it's only in sys-usb
2. Switch its mode to file transfer - observe reconnect in sys-usb
3. Use qvm-usb to attach it to the testvm
4. Call jmtpfs -d /mnt in testvmOr maybe reset or something is involved here too?
After using qvm-usb to attach
_anddetach_the device, it stays bound to usbip-host driver (that's intentional). But then, even after re-binding back to the "usb" driver, jmtpfs called in sys-usb directly fails the same way, including failure to reset.In fact, even without usbip involved at all, jmtpfs directly in sys-usb works only once. The second attempt (without either physically reconnecting the phone, or changing its more to "no data transfer" and back to "file transfer") fails the same way. After terminating the first instance, I see just this logged:
Quoted 4 lines
Quoted 1 line
[921332.525210] usb 2-1: reset high-speed USB device number 22 using xhci_hcdIf something doesn't work when usbip isn't involved, you definitely shouldn't expect it to work when usbip _is_ involved.
With usbip, jmtpfs fails the _first_ time, instead of only the _second_ time. This might be related: maybe the attachment of usbip acts like the first attach?
Signature · 3 lines
Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab
Quoted 16 lines · Greg Kroah-Hartman
Quoted 15 lines · Demi Marie Obenour
Qubes OS users are reporting that MTP doesn't work with USB passthrough. Fastboot (used for flashing a custom OS to an Android device) also doesn't work. Kernel-mode drivers, such as Bluetooth and USB storage, seem to usually work as expected. Since MTP and fastboot are both implemented in userspace, it appears that there is some problem with the interaction of usbip, our USB proxy (which is based on USBIP), and userspace programs that interact with USB devices directly.
The bug report can be found at [1] and the source code for the USB proxy can be found at [2]. The script used on the sending side (the one with the physical USB controller) is at [3] and the script used by the receiving side (the one the device is attached to) is at [4]. All of these links are for the current version as of this email being sent, so that anyone looking at this email in the future doesn't get confused.
Quoted 4 lines
Quoted 1 line
Is this a bug in usbip, or is this due to usbip being used incorrectly?
I'm amazed that usbip works with usbfs at all, I didn't think that was a thing.
If it isn't a thing, then how would one go about making it be a thing? usbfs not supporting usbip would certainly explain the behavior we are seeing, but this also means that usbip is not a complete solution for our use-case. I had assumed that usbip simply created a new USB device that was just as functional as any device implemented in hardware.
Quoted 2 lines
If you have a reproducer, or some error messages somewhere, that might be the easiest way forward.
Multiple users have 100% reliable reproducers, and I believe (but am not certain) that Marek can reproduce this problem too. Writing a reproducer that doesn't involve Qubes OS or any USB peripherals would be quite a bit harder, mostly because I can't think of any way to run into this bug without either having least two machines (either physical or virtual) or using usbip from a machine to itself (which would be rather strange and might throw things off). It would also be necessary to somehow emulate the USB device in question.
Quoted 3 lines
In reading the bug report, it looks like
the "bridge" you all made can't handle the device disconnecting itself properly? But that's just a guess, could be anything.
What is the proper way to deal with disconnections? It's quite possible that the shell scripts have a bug somewhere, but I'm not sure what it is.
Signature · 3 lines
Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab