Received-SPF: pass (google.com: domain of linux-kernel+bounces-91271-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Date: Mon, 4 Mar 2024 21:04:00 +0000
From: Greg KH <gregkh@linuxfoundation.org>
To: Demi Marie Obenour <demi@invisiblethingslab.com>
Cc: linux-usb@vger.kernel.org,
	Marek =?iso-8859-1?Q?Marczykowski-G=F3recki?= <marmarek@invisiblethingslab.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: usbip doesn't work with userspace code that accesses USB devices
Message-ID: <2024030406-kilogram-raving-33c5@gregkh>
References: <ZeYov0k8njwcZzGX@itl-email>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ZeYov0k8njwcZzGX@itl-email>

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 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 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