Received-SPF: pass (google.com: domain of linux-kernel+bounces-91426-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Feedback-ID: i1568416f:Fastmail
Date: Tue, 5 Mar 2024 00:52:22 +0100
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: Demi Marie Obenour <demi@invisiblethingslab.com>,
	linux-usb@vger.kernel.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: usbip doesn't work with userspace code that accesses USB devices
Message-ID: <ZeZetkR-i1bCDr9v@mail-itl>
References: <ZeYov0k8njwcZzGX@itl-email>
 <2024030406-kilogram-raving-33c5@gregkh>
 <ZeZPLX6z5pyn2Eh_@mail-itl>
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="vjxjlK2sKkkzCwBy"
Content-Disposition: inline
In-Reply-To: <ZeZPLX6z5pyn2Eh_@mail-itl>


--vjxjlK2sKkkzCwBy
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Tue, 5 Mar 2024 00:52:22 +0100
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: Demi Marie Obenour <demi@invisiblethingslab.com>,
	linux-usb@vger.kernel.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: usbip doesn't work with userspace code that accesses USB devices

On Mon, Mar 04, 2024 at 11:46:04PM +0100, Marek Marczykowski-G=C3=B3recki w=
rote:
> On Mon, Mar 04, 2024 at 09:04:00PM +0000, Greg KH wrote:
> > On Mon, Mar 04, 2024 at 03:01:51PM -0500, Demi Marie Obenour wrote:
> > > Qubes OS users are reporting that MTP doesn't work with USB passthrou=
gh.
> > > 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.
> > >=20
> > > The bug report can be found at [1] and the source code for the USB pr=
oxy
> > > can be found at [2].  The script used on the sending side (the one wi=
th
> > > 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.
> > >=20
> > > Is this a bug in usbip, or is this due to usbip being used incorrectl=
y?
> >=20
> > I'm amazed that usbip works with usbfs at all, I didn't think that was a
> > thing.
> >=20
> > 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.
>=20
> 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.
>=20
> 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)
>=20
> 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 xh=
ci_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).

--=20
Best Regards,
Marek Marczykowski-G=C3=B3recki
Invisible Things Lab

--vjxjlK2sKkkzCwBy
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmXmXrYACgkQ24/THMrX
1ywqTAf+KFm0MRSupyhuHY/Ls1eORUE8fuKGhlY3Xr2n19WrYulw7grHbJ8WwoVf
IqV4r05Uy5fvhnBCw9upayG18vN7tWGwlWorar8dWvDAssOauenoz9U0IC57fBOq
7zsxLJRHUOSraglMINDkP/pcFmYm7uSFOwneLIsvFvX+9vpH/yc8y83+vSpB9/w0
CZHgY2EE0+9S0Cobz7II3O8bBDLGJuvH8X+WOp61hEU3S21MUEX8pGqMDh+br/WE
iUgIaP2xHQAuUACXUJPpY3lmCpzkRC9epVCiup5AQij3I4donvJzhtiuaqE59QuP
Flw5B+LVuYhTOMDWUZyfcgs5qCcxFA==
=xUcW
-----END PGP SIGNATURE-----

--vjxjlK2sKkkzCwBy--