Re: USB: Request for guidance investigating configuration descriptor enumeration failure

[Michal Pecio <michal.pecio@gmail.com>]

On Sun, 31 May 2026 15:41:14 +0530, Nikhil Solanke wrote:
> > By "VM" you mean that it's connected to Windows and works normally,
> > then you pass it through to a Linux guest and the guest breaks it?
> > I suppose it remains broken until power cycled? And I suppose it
> > breaks after connecting to a Linux host, so a Windows guest can't
> > use it normally either?  
> 
> I actually didn't test for Linux guest on Windows host. I only tested
> Linux guest on a Linux host. I had utilized PCI Passthrough to
> passthrough the entire usb hub itself that is present in my laptop.
> This, to my knowledge, completely negates any interaction of the
> device with the VM host on the USB path. It only interacts with the
> guest directly. The Linux guest also couldn't properly enumerate the
> device (failing with "unable to read config index 0 descriptor/start:
> -71"). Then i tried a Windows guest with same configuration (i.e. PCI
> passthrough of the usb root hub), the device enumerated successfully!

Well, that's not surprising. As you noted, with PCI passthrough the
guest has full control over all USB transfers to the device.

What about xHCI vs EHCI?
 
> Also a side note: during initial enumeration, when it presents itself
> as 045e:028e, that ID only appears in the usbmon trace. Because the
> device didn't finish enumeration, lsusb doesn't show that VID:PID.
> Only after it fails and falls back to Android mode does lsusb show the
> Android mode's VID:PID. Therefore, to even try applying existing
> quirks, the user must use usbmon to find the initial VID:PID. This
> might seem like common sense to you and other developers, but it
> wasn't to me or any other normal user. So my workaround also displays
> the VID:PID that failed to enumerate in dmesg. This helps an average
> non-technical user to apply the quirks, let's say, by following a
> tutorial or guide to resolve any issue (at the start, I was trying to
> apply those quirks to the Android mode's VID:PID. only later i
> discovered that it presents itself as another vid:pid).

Annoying, and not the first such case. Perhaps VID:PID should always
be printed earlier, as soon as the device descriptor is obtained.

> > I ask because I found Windows Wireshark traces not to be fully
> > complete and running Wireshark on a Linux host with Windows VM
> > could be better.  
> 
> I'm sorry; I didn't understand what you meant by "not fully complete."
> As I mentioned in the note, I did truncate the packets sent and
> received before the device's enumeration began, but that was for
> Linux. The Windows traces I obtained were originally just like what I
> had attached. There weren't any other packets captured, unlike what we
> see on Linux with those USBHUB packets. Perhaps I missed some
> USBPcap/Wireshark configuration? I tested it on a fresh Windows
> install and a fresh Wireshark install. Nothing else besides that.

That's what I mean. There is plenty of missing communication with hubs,
which "should be there", particularly when the device is connected to
an external hub. And IIRC some descriptors (like BOS) are missing too
in Windows Wireshark traces.

I don't know if it can be fixed, and how.

I also found this article, which claims that Windows uses wLength=255
for its config descriptor request "for compatibility reasons". But your
pcap doesn't show anything like that and so do mine (Windows 10).

https://thewindowsupdate.com/2018/10/12/how-does-usb-stack-enumerate-a-device/

So I don't know what's true anymore. Running Windows under a Linux host
with individual device passthrough (e.g. qemu) could show what really
happens. Even better would be a USB bus analyzer. I don't have one :(

Maybe 255 would make sense for the quirk, if we can't find the true
root cause and any better solution.

Regards,
Michal