USB: Request for guidance investigating configuration descriptor enumeration failure

USB: Request for guidance investigating configuration descriptor enumeration failure

[Nikhil Solanke]

Hello,

I have been investigating a USB enumeration issue affecting at least
one controller exposing an Xbox-compatible interface (VID:PID
045e:028e).

The device consistently fails enumeration under Linux during the
initial configuration descriptor read. The failure is reproducible on
multiple physical machines and also inside a VM.

Observations:
- Reproduces successfully on latest mainline linux kernel and also the
latest lts kernel release
- Windows successfully enumerates the device.
- Linux fails while reading the initial configuration descriptor.
- The issue reproduces across different hosts.
- The device falls back to a secondary mode (with different vendor id
and product id) (meant for android support) when enumeration fails.
This android mode gets enumerated and initialized properly but we lose
a few capabilities that get exposed when its in the Xinput mode.

So I collected and investigated USB captures from both Windows and
Linux via Wireshark.

Interesting finding:

The standard Linux path requests the initial configuration descriptor
using USB_DT_CONFIG_SIZE (9 bytes). By introducing a new usbcore quirk
and modifying usb_get_configuration() so that affected devices request
10 bytes instead of 9, enumeration succeeds reliably and the
controller remains in its expected XInput mode.

Additional testing:

9-byte request: fails
48-byte request: succeeds
16-byte request: succeeds
10-byte request: succeeds

I do not currently understand the underlying protocol-level reason for
this behavior and would prefer to investigate the root cause rather
than submit a workaround.

Could anyone suggest:

which USB core paths would be most useful to instrument,

whether there are existing examples of devices failing specifically at
the initial configuration descriptor size probe,

and whether usbmon alone is sufficient here or if
host-controller-level tracing would be more appropriate?

I would be happy to provide:
Windows and Linux Wireshark captures,
kernel logs,
and the experimental workaround patch.

Thanks.
Nikhil Solanke

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

[Alan Stern]

On Sat, May 30, 2026 at 02:52:28AM +0530, Nikhil Solanke wrote:
> Hello,
> 
> I have been investigating a USB enumeration issue affecting at least
> one controller exposing an Xbox-compatible interface (VID:PID
> 045e:028e).
> 
> The device consistently fails enumeration under Linux during the
> initial configuration descriptor read. The failure is reproducible on
> multiple physical machines and also inside a VM.
> 
> Observations:
> - Reproduces successfully on latest mainline linux kernel and also the
> latest lts kernel release
> - Windows successfully enumerates the device.
> - Linux fails while reading the initial configuration descriptor.
> - The issue reproduces across different hosts.
> - The device falls back to a secondary mode (with different vendor id
> and product id) (meant for android support) when enumeration fails.
> This android mode gets enumerated and initialized properly but we lose
> a few capabilities that get exposed when its in the Xinput mode.
> 
> So I collected and investigated USB captures from both Windows and
> Linux via Wireshark.
> 
> Interesting finding:
> 
> The standard Linux path requests the initial configuration descriptor
> using USB_DT_CONFIG_SIZE (9 bytes). By introducing a new usbcore quirk
> and modifying usb_get_configuration() so that affected devices request
> 10 bytes instead of 9, enumeration succeeds reliably and the
> controller remains in its expected XInput mode.
> 
> Additional testing:
> 
> 9-byte request: fails
> 48-byte request: succeeds
> 16-byte request: succeeds
> 10-byte request: succeeds

Probably any length larger than 9 will work.

It would be nice to know _how_ the 9-byte request fails.  That is, what 
is the status code when the request completes?  This information is in 
the usbmon trace.

Also, what happens under Windows?  Isn't a 9-byte Get-Config-Descriptor 
request standard in Windows as well as Linux?

> I do not currently understand the underlying protocol-level reason for
> this behavior and would prefer to investigate the root cause rather
> than submit a workaround.

Most likely the root cause is a bug in the device's firmware.

> Could anyone suggest:
> 
> which USB core paths would be most useful to instrument,

I doubt that anything needs to be instrumented.  If the device doesn't 
respond properly to a standard request, it's the device's fault.

> whether there are existing examples of devices failing specifically at
> the initial configuration descriptor size probe,

Not that I know of.

> and whether usbmon alone is sufficient here or if 
> host-controller-level tracing would be more appropriate?

Can't answer that without seeing the usbmon/Wireshark output.  Post 
whatever you've got, for both Linux and Windows.

Alan Stern

> I would be happy to provide:
> Windows and Linux Wireshark captures,
> kernel logs,
> and the experimental workaround patch.
> 
> Thanks.
> Nikhil Solanke

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

[Nikhil Solanke]

[-- Attachment #1: Type: text/plain, Size: 5424 bytes --]

Thanks for the follow up.

> It would be nice to know _how_ the 9-byte request fails.  That is, what is the status code when the request completes?  This information is in the usbmon trace.

The device reports failure by responding with a GET DESCRIPTOR
Response (not a GET DESCRIPTOR Response CONFIGURATION) that has no
descriptor response data and sets URB Status with EPROTO (-71) which
the kernel reports as is in dmesg (unable to read config index 0
descriptor/start: -71).

> Also, what happens under Windows?  Isn't a 9-byte Get-Config-Descriptor request standard in Windows as well as Linux?

Yes it is the standard on both platforms and that is what bugged me
too. I'll be attaching the packet traces here, but here's a quick
observation regarding that:
On windows, the usbpcap captures shows that windows sets Packet Data
Length in the URB data as 8 but requests wLength of 9 in Setup Data.
Linux on the other hand has URB Length equal to the wLength and Data
Length as 0. Furthermore, the device enumerates perfectly fine in the
fallback mode (Android mode) with the 9-byte descriptor request.
Further testing also revealed that the xinput mode would fail with
broken pipe error if I use an external USB hub. However, all these
issues are magically resolved with just a slightly bigger request.

I also had tested the device with various other existing quirks as
well but none worked. I also tested using the
usbcore.old_scheme_first=1 kernel cmdline, which failed as well.

> I doubt that anything needs to be instrumented.  If the device doesn't respond properly to a standard request, it's the device's fault.

That seems most likely to be the case. However, this behavior is found
with other third-party Xbox-compatible controllers as well (i
personally tried 2 other controllers that failed the same way). They
all fail the enumeration stage in the same way. Wouldn't it be
appropriate to introduce a proper fix as a "quirk" in the main line
kernel?

Note: i have attached the packet traces, but they are truncated to
only show the device communications with the host and any intermediate
packets. There were other packets sent and received that communicated
with the USB root hub before the device started its enumeration.
Should I include those as well?

Thanks,
Nikhil Solanke

On Sat, 30 May 2026 at 07:28, Alan Stern <stern@rowland.harvard.edu> wrote:
>
> On Sat, May 30, 2026 at 02:52:28AM +0530, Nikhil Solanke wrote:
> > Hello,
> >
> > I have been investigating a USB enumeration issue affecting at least
> > one controller exposing an Xbox-compatible interface (VID:PID
> > 045e:028e).
> >
> > The device consistently fails enumeration under Linux during the
> > initial configuration descriptor read. The failure is reproducible on
> > multiple physical machines and also inside a VM.
> >
> > Observations:
> > - Reproduces successfully on latest mainline linux kernel and also the
> > latest lts kernel release
> > - Windows successfully enumerates the device.
> > - Linux fails while reading the initial configuration descriptor.
> > - The issue reproduces across different hosts.
> > - The device falls back to a secondary mode (with different vendor id
> > and product id) (meant for android support) when enumeration fails.
> > This android mode gets enumerated and initialized properly but we lose
> > a few capabilities that get exposed when its in the Xinput mode.
> >
> > So I collected and investigated USB captures from both Windows and
> > Linux via Wireshark.
> >
> > Interesting finding:
> >
> > The standard Linux path requests the initial configuration descriptor
> > using USB_DT_CONFIG_SIZE (9 bytes). By introducing a new usbcore quirk
> > and modifying usb_get_configuration() so that affected devices request
> > 10 bytes instead of 9, enumeration succeeds reliably and the
> > controller remains in its expected XInput mode.
> >
> > Additional testing:
> >
> > 9-byte request: fails
> > 48-byte request: succeeds
> > 16-byte request: succeeds
> > 10-byte request: succeeds
>
> Probably any length larger than 9 will work.
>
> It would be nice to know _how_ the 9-byte request fails.  That is, what
> is the status code when the request completes?  This information is in
> the usbmon trace.
>
> Also, what happens under Windows?  Isn't a 9-byte Get-Config-Descriptor
> request standard in Windows as well as Linux?
>
> > I do not currently understand the underlying protocol-level reason for
> > this behavior and would prefer to investigate the root cause rather
> > than submit a workaround.
>
> Most likely the root cause is a bug in the device's firmware.
>
> > Could anyone suggest:
> >
> > which USB core paths would be most useful to instrument,
>
> I doubt that anything needs to be instrumented.  If the device doesn't
> respond properly to a standard request, it's the device's fault.
>
> > whether there are existing examples of devices failing specifically at
> > the initial configuration descriptor size probe,
>
> Not that I know of.
>
> > and whether usbmon alone is sufficient here or if
> > host-controller-level tracing would be more appropriate?
>
> Can't answer that without seeing the usbmon/Wireshark output.  Post
> whatever you've got, for both Linux and Windows.
>
> Alan Stern
>
> > I would be happy to provide:
> > Windows and Linux Wireshark captures,
> > kernel logs,
> > and the experimental workaround patch.
> >
> > Thanks.
> > Nikhil Solanke

[-- Attachment #2: controller_linux.pcapng --]
[-- Type: application/x-pcapng, Size: 7260 bytes --]

[-- Attachment #3: controller_linux_patched.pcapng --]
[-- Type: application/x-pcapng, Size: 3248 bytes --]

[-- Attachment #4: controller_windows.pcapng --]
[-- Type: application/x-pcapng, Size: 1480 bytes --]

[-- Attachment #5: controller_with_external_hub_linux.pcapng --]
[-- Type: application/x-pcapng, Size: 5112 bytes --]

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

[Alan Stern]

On Sat, May 30, 2026 at 12:27:13PM +0530, Nikhil Solanke wrote:
> Thanks for the follow up.
> 
> > It would be nice to know _how_ the 9-byte request fails.  That is, what is the status code when the request completes?  This information is in the usbmon trace.
> 
> The device reports failure by responding with a GET DESCRIPTOR
> Response (not a GET DESCRIPTOR Response CONFIGURATION) that has no
> descriptor response data and sets URB Status with EPROTO (-71) which
> the kernel reports as is in dmesg (unable to read config index 0
> descriptor/start: -71).

Actually what happens is the device disconnects from the USB bus without 
responding at all.  (Probably it does this as part of reinitializing 
with the fallback-mode firmware.)  That's what leads to the -71 errors.

> > Also, what happens under Windows?  Isn't a 9-byte Get-Config-Descriptor request standard in Windows as well as Linux?
> 
> Yes it is the standard on both platforms and that is what bugged me
> too. I'll be attaching the packet traces here, but here's a quick
> observation regarding that:
> On windows, the usbpcap captures shows that windows sets Packet Data
> Length in the URB data as 8 but requests wLength of 9 in Setup Data.

The Packet Data Length probably refers to the length of the request, not 
the length of the response.

The difference between the two operating systems is that Linux issues a 
Get-Device-Qualifier-Descriptor request three times (each time the 
device responds with a Halt) before issuing the length-9 
Get-Configuration-Descriptor request.  But Windows does not ask for the 
Device Qualifier descriptor; it just sends the length-9 request for the 
Configuration descriptor directly and the device responds properly.

> Linux on the other hand has URB Length equal to the wLength and Data
> Length as 0.

Again, you may be misinpreting the meaning of those values.  But it 
doesn't matter.

> Furthermore, the device enumerates perfectly fine in the
> fallback mode (Android mode) with the 9-byte descriptor request.
> Further testing also revealed that the xinput mode would fail with
> broken pipe error if I use an external USB hub. However, all these
> issues are magically resolved with just a slightly bigger request.
> 
> I also had tested the device with various other existing quirks as
> well but none worked. I also tested using the
> usbcore.old_scheme_first=1 kernel cmdline, which failed as well.
> 
> > I doubt that anything needs to be instrumented.  If the device doesn't respond properly to a standard request, it's the device's fault.
> 
> That seems most likely to be the case. However, this behavior is found
> with other third-party Xbox-compatible controllers as well (i
> personally tried 2 other controllers that failed the same way). They
> all fail the enumeration stage in the same way. Wouldn't it be
> appropriate to introduce a proper fix as a "quirk" in the main line
> kernel?

You should try setting the USB_QUIRK_DEVICE_QUALIFIER flag for the 
device.  If that doesn't fix the problem, collect and post another 
usbmon trace showing what happens.  If it does fix the problem, you can 
submit a patch with this quirk flag instead of adding a new one.

> Note: i have attached the packet traces, but they are truncated to
> only show the device communications with the host and any intermediate
> packets. There were other packets sent and received that communicated
> with the USB root hub before the device started its enumeration.
> Should I include those as well?

No, what you did is fine.

Alan Stern

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

[Nikhil Solanke]

> Actually what happens is the device disconnects from the USB bus without
> responding at all.

Just being curious here, but wouldn't i see a packet from the usb root
hub / usb host controller notifying of that?. or even a dmesg log
saying the device disconnected? Because that doesn't happen at all as
the kernel tries the request 3 times before completely giving up. If
the device disconnected, only one configuration request would've been
sent and the enumeration would have started again from start, wouldn't
it?

> Again, you may be misinpreting the meaning of those values. But it doesn't matter.

Yeah, I kind of figured that, but mentioned it nonetheless just in
case. Windows mentions the packet data length for the setup data size
it sends, and it checks out (i counted the bytes). However, the Linux
behavior confused me. Like I said earlier, the URB length is basically
the same as what we request as wLength in setup data. Nothing else in
the whole packet matches that size. So i was a bit confused and felt
to mention it.

> You should try setting the USB_QUIRK_DEVICE_QUALIFIER flag for the
> device.  If that doesn't fix the problem, collect and post another
> usbmon trace showing what happens.  If it does fix the problem, you can
> submit a patch with this quirk flag instead of adding a new one.

As I mentioned earlier, I tested it with that specific quirk too. I
also tested the delay init quirk and various others (even paired a few
of those together). They make no difference at all. The resulting
packet trace from the USB_QUIRK_DEVICE_QUALIFIER is the same as the
unpatched behaviour just with no device qualifier requests. Besides,
if you look at the patched behavior, the DEVICE QUALIFIER requests
were ignored by the device in that trace too, but it still
successfully enumerated in the Xbox/Xinput mode. And as per the USB
spec, if I got it right, full-speed devices should error when
requested a device qualifier. We can see that happening in the packet
trace too. The response packet has URB Status set to -ESTALL (-32),
which can be considered an error. So, it isn't a problem either way
whether the host requests it or not. The patched/workaround behavior
isn't affected by it too after all. Quoting the USB spec directly here
(Section 9.6.2):

> "If a full-speed only device (with a device descriptor version number equal to 0200H) receives a
> GetDescriptor() request for a device_qualifier, it must respond with a request error. The host must not make
> a request for an other_speed_configuration descriptor unless it first successfully retrieves the
> device_qualifier descriptor."

So, to conclude, the device qualifier request isn't the root cause of
the problem at all.

Thanks,
Nikhil Solanke

On Sat, 30 May 2026 at 20:18, Alan Stern <stern@rowland.harvard.edu> wrote:
>
> On Sat, May 30, 2026 at 12:27:13PM +0530, Nikhil Solanke wrote:
> > Thanks for the follow up.
> >
> > > It would be nice to know _how_ the 9-byte request fails.  That is, what is the status code when the request completes?  This information is in the usbmon trace.
> >
> > The device reports failure by responding with a GET DESCRIPTOR
> > Response (not a GET DESCRIPTOR Response CONFIGURATION) that has no
> > descriptor response data and sets URB Status with EPROTO (-71) which
> > the kernel reports as is in dmesg (unable to read config index 0
> > descriptor/start: -71).
>
> Actually what happens is the device disconnects from the USB bus without
> responding at all.  (Probably it does this as part of reinitializing
> with the fallback-mode firmware.)  That's what leads to the -71 errors.
>
> > > Also, what happens under Windows?  Isn't a 9-byte Get-Config-Descriptor request standard in Windows as well as Linux?
> >
> > Yes it is the standard on both platforms and that is what bugged me
> > too. I'll be attaching the packet traces here, but here's a quick
> > observation regarding that:
> > On windows, the usbpcap captures shows that windows sets Packet Data
> > Length in the URB data as 8 but requests wLength of 9 in Setup Data.
>
> The Packet Data Length probably refers to the length of the request, not
> the length of the response.
>
> The difference between the two operating systems is that Linux issues a
> Get-Device-Qualifier-Descriptor request three times (each time the
> device responds with a Halt) before issuing the length-9
> Get-Configuration-Descriptor request.  But Windows does not ask for the
> Device Qualifier descriptor; it just sends the length-9 request for the
> Configuration descriptor directly and the device responds properly.
>
> > Linux on the other hand has URB Length equal to the wLength and Data
> > Length as 0.
>
> Again, you may be misinpreting the meaning of those values.  But it
> doesn't matter.
>
> > Furthermore, the device enumerates perfectly fine in the
> > fallback mode (Android mode) with the 9-byte descriptor request.
> > Further testing also revealed that the xinput mode would fail with
> > broken pipe error if I use an external USB hub. However, all these
> > issues are magically resolved with just a slightly bigger request.
> >
> > I also had tested the device with various other existing quirks as
> > well but none worked. I also tested using the
> > usbcore.old_scheme_first=1 kernel cmdline, which failed as well.
> >
> > > I doubt that anything needs to be instrumented.  If the device doesn't respond properly to a standard request, it's the device's fault.
> >
> > That seems most likely to be the case. However, this behavior is found
> > with other third-party Xbox-compatible controllers as well (i
> > personally tried 2 other controllers that failed the same way). They
> > all fail the enumeration stage in the same way. Wouldn't it be
> > appropriate to introduce a proper fix as a "quirk" in the main line
> > kernel?
>
> You should try setting the USB_QUIRK_DEVICE_QUALIFIER flag for the
> device.  If that doesn't fix the problem, collect and post another
> usbmon trace showing what happens.  If it does fix the problem, you can
> submit a patch with this quirk flag instead of adding a new one.
>
> > Note: i have attached the packet traces, but they are truncated to
> > only show the device communications with the host and any intermediate
> > packets. There were other packets sent and received that communicated
> > with the USB root hub before the device started its enumeration.
> > Should I include those as well?
>
> No, what you did is fine.
>
> Alan Stern

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

[Alan Stern]

On Sat, May 30, 2026 at 10:18:58PM +0530, Nikhil Solanke wrote:
> > Actually what happens is the device disconnects from the USB bus without
> > responding at all.
> 
> Just being curious here, but wouldn't i see a packet from the usb root
> hub / usb host controller notifying of that?.

Yes, you would.  And in fact the usbmon trace (unpatched Linux) contains 
just such packets:

ffff8891748cb380 0.559834 C Ii:3:001:1 0:2048 1 = 02

That is from the root hub saying that there was a status change on port 1.

ffff88929fcaec00 0.628744 S Ci:3:001:0 s a3 00 0000 0001 0004 4 <
ffff88929fcaec00 0.628769 C Ci:3:001:0 0 4 = 00011100

Those are a request to the root hub asking for the port status on port 1 
and a response saying that there was a connect-status change as well as 
no current connection.

>  or even a dmesg log
> saying the device disconnected?

Disconnect messages aren't logged until a device has been fully 
enumerated.  However, there should have been messages in the log saying 
something like "unable to read config index 1 descriptor start: -71" and 
"can't read configurations, error -71".

> Because that doesn't happen at all as
> the kernel tries the request 3 times before completely giving up. If
> the device disconnected, only one configuration request would've been
> sent and the enumeration would have started again from start, wouldn't
> it?

The code that gets the disconnect information from the root hub doesn't 
run until after the code that attempts three times to read the 
configuration descriptor.

And besides, the enumeration did start again from the beginning; you 
said so yourself earlier.  But when it did, the device presented itself 
using its Android mode information.

> > Again, you may be misinpreting the meaning of those values. But it doesn't matter.
> 
> Yeah, I kind of figured that, but mentioned it nonetheless just in
> case. Windows mentions the packet data length for the setup data size
> it sends, and it checks out (i counted the bytes). However, the Linux
> behavior confused me. Like I said earlier, the URB length is basically
> the same as what we request as wLength in setup data. Nothing else in
> the whole packet matches that size. So i was a bit confused and felt
> to mention it.

In the Linux usbmon trace, the URB length is the amount of data meant to 
be (when an URB is submitted) or actually (when an URB completes) sent 
to/from the device.  This does not include the information in a Setup 
packet but only the data bytes; it matches the wLength value, as you 
observed.  Windows may behave differently.

> > You should try setting the USB_QUIRK_DEVICE_QUALIFIER flag for the
> > device.  If that doesn't fix the problem, collect and post another
> > usbmon trace showing what happens.  If it does fix the problem, you can
> > submit a patch with this quirk flag instead of adding a new one.
> 
> As I mentioned earlier, I tested it with that specific quirk too. I

Can you post a usbmon trace showing what happens with that quirk?  I 
would like to compare it with the Windows trace you sent earlier.

> also tested the delay init quirk and various others (even paired a few
> of those together). They make no difference at all. The resulting
> packet trace from the USB_QUIRK_DEVICE_QUALIFIER is the same as the
> unpatched behaviour just with no device qualifier requests. Besides,
> if you look at the patched behavior, the DEVICE QUALIFIER requests
> were ignored by the device in that trace too, but it still
> successfully enumerated in the Xbox/Xinput mode. And as per the USB
> spec, if I got it right, full-speed devices should error when
> requested a device qualifier. We can see that happening in the packet
> trace too. The response packet has URB Status set to -ESTALL (-32),
> which can be considered an error. So, it isn't a problem either way
> whether the host requests it or not. The patched/workaround behavior
> isn't affected by it too after all. Quoting the USB spec directly here
> (Section 9.6.2):
> 
> > "If a full-speed only device (with a device descriptor version number equal to 0200H) receives a
> > GetDescriptor() request for a device_qualifier, it must respond with a request error. The host must not make
> > a request for an other_speed_configuration descriptor unless it 
> > first successfully retrieves the
> > device_qualifier descriptor."
> 
> So, to conclude, the device qualifier request isn't the root cause of
> the problem at all.

That's right; the root cause seems to be a bug in the device's firmware.  
But perhaps that bug is triggered when the device receives a 
Get-Device-Qualifier request.  That's the only theory I was able to 
think of which could explain the behavior in the Windows trace.

Alan Stern

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

[Nikhil Solanke]

[-- Attachment #1: Type: text/plain, Size: 5369 bytes --]

> However, there should have been messages in the log saying
> something like "unable to read config index 1 descriptor start: -71" and
> "can't read configurations, error -71".

yep there is. I did mentioned in one of my replies. It does say:
unable to read config index 0 descriptor/start: -71

Attaching the packet trace with the USB_QUIRK_DEVICE_QUALIFIER quirk set.

Nikhil Solanke

On Sun, 31 May 2026 at 01:57, Alan Stern <stern@rowland.harvard.edu> wrote:
>
> On Sat, May 30, 2026 at 10:18:58PM +0530, Nikhil Solanke wrote:
> > > Actually what happens is the device disconnects from the USB bus without
> > > responding at all.
> >
> > Just being curious here, but wouldn't i see a packet from the usb root
> > hub / usb host controller notifying of that?.
>
> Yes, you would.  And in fact the usbmon trace (unpatched Linux) contains
> just such packets:
>
> ffff8891748cb380 0.559834 C Ii:3:001:1 0:2048 1 = 02
>
> That is from the root hub saying that there was a status change on port 1.
>
> ffff88929fcaec00 0.628744 S Ci:3:001:0 s a3 00 0000 0001 0004 4 <
> ffff88929fcaec00 0.628769 C Ci:3:001:0 0 4 = 00011100
>
> Those are a request to the root hub asking for the port status on port 1
> and a response saying that there was a connect-status change as well as
> no current connection.
>
> >  or even a dmesg log
> > saying the device disconnected?
>
> Disconnect messages aren't logged until a device has been fully
> enumerated.  However, there should have been messages in the log saying
> something like "unable to read config index 1 descriptor start: -71" and
> "can't read configurations, error -71".
>
> > Because that doesn't happen at all as
> > the kernel tries the request 3 times before completely giving up. If
> > the device disconnected, only one configuration request would've been
> > sent and the enumeration would have started again from start, wouldn't
> > it?
>
> The code that gets the disconnect information from the root hub doesn't
> run until after the code that attempts three times to read the
> configuration descriptor.
>
> And besides, the enumeration did start again from the beginning; you
> said so yourself earlier.  But when it did, the device presented itself
> using its Android mode information.
>
> > > Again, you may be misinpreting the meaning of those values. But it doesn't matter.
> >
> > Yeah, I kind of figured that, but mentioned it nonetheless just in
> > case. Windows mentions the packet data length for the setup data size
> > it sends, and it checks out (i counted the bytes). However, the Linux
> > behavior confused me. Like I said earlier, the URB length is basically
> > the same as what we request as wLength in setup data. Nothing else in
> > the whole packet matches that size. So i was a bit confused and felt
> > to mention it.
>
> In the Linux usbmon trace, the URB length is the amount of data meant to
> be (when an URB is submitted) or actually (when an URB completes) sent
> to/from the device.  This does not include the information in a Setup
> packet but only the data bytes; it matches the wLength value, as you
> observed.  Windows may behave differently.
>
> > > You should try setting the USB_QUIRK_DEVICE_QUALIFIER flag for the
> > > device.  If that doesn't fix the problem, collect and post another
> > > usbmon trace showing what happens.  If it does fix the problem, you can
> > > submit a patch with this quirk flag instead of adding a new one.
> >
> > As I mentioned earlier, I tested it with that specific quirk too. I
>
> Can you post a usbmon trace showing what happens with that quirk?  I
> would like to compare it with the Windows trace you sent earlier.
>
> > also tested the delay init quirk and various others (even paired a few
> > of those together). They make no difference at all. The resulting
> > packet trace from the USB_QUIRK_DEVICE_QUALIFIER is the same as the
> > unpatched behaviour just with no device qualifier requests. Besides,
> > if you look at the patched behavior, the DEVICE QUALIFIER requests
> > were ignored by the device in that trace too, but it still
> > successfully enumerated in the Xbox/Xinput mode. And as per the USB
> > spec, if I got it right, full-speed devices should error when
> > requested a device qualifier. We can see that happening in the packet
> > trace too. The response packet has URB Status set to -ESTALL (-32),
> > which can be considered an error. So, it isn't a problem either way
> > whether the host requests it or not. The patched/workaround behavior
> > isn't affected by it too after all. Quoting the USB spec directly here
> > (Section 9.6.2):
> >
> > > "If a full-speed only device (with a device descriptor version number equal to 0200H) receives a
> > > GetDescriptor() request for a device_qualifier, it must respond with a request error. The host must not make
> > > a request for an other_speed_configuration descriptor unless it
> > > first successfully retrieves the
> > > device_qualifier descriptor."
> >
> > So, to conclude, the device qualifier request isn't the root cause of
> > the problem at all.
>
> That's right; the root cause seems to be a bug in the device's firmware.
> But perhaps that bug is triggered when the device receives a
> Get-Device-Qualifier request.  That's the only theory I was able to
> think of which could explain the behavior in the Windows trace.
>
> Alan Stern

[-- Attachment #2: controller_linux_no_qualifier.pcapng --]
[-- Type: application/x-pcapng, Size: 6120 bytes --]

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

[Alan Stern]

On Sun, May 31, 2026 at 02:17:32AM +0530, Nikhil Solanke wrote:
> > However, there should have been messages in the log saying
> > something like "unable to read config index 1 descriptor start: -71" and
> > "can't read configurations, error -71".
> 
> yep there is. I did mentioned in one of my replies. It does say:
> unable to read config index 0 descriptor/start: -71
> 
> Attaching the packet trace with the USB_QUIRK_DEVICE_QUALIFIER quirk set.

Thanks.  There's no visible difference between the enumeration under 
Linux and under Windows until the disconnection occurs.  Here's the 
relevant part of the Windows trace:

ffffc588ce0c3a20 0.327827 S Ci:2:001:0 s 80 06 0100 0000 0012 18 <
ffffc588ce0c3a20 0.329841 C Ci:2:001:0 0 18 = 12010002 00000040 5e048e02 36000002 0301
ffffc588ce0c3a20 0.329887 S Ci:2:001:0 s 80 06 0200 0000 0009 9 <
ffffc588ce0c3a20 0.332841 C Ci:2:001:0 0 9 = 09023000 01010080 fa

And here's the equivalent portion of the Linux trace:

ffff88e64c1fd440 0.965292 S Ci:3:003:0 s 80 06 0100 0000 0012 18 <
ffff88e64c1fd440 0.967582 C Ci:3:003:0 0 18 = 12010002 00000040 5e048e02 36000002 0301
ffff88e64c1fd440 0.967613 S Ci:3:003:0 s 80 06 0200 0000 0009 9 <
ffff88e605143ec0 0.973464 C Ii:3:001:1 0:2048 1 = 02
ffff88e605143ec0 0.973467 S Ii:3:001:1 -115:2048 4 <
ffff88e64c1fd440 0.975670 C Ci:3:003:0 -71 0

As you can see, the first three lines are the same (from the fifth 
column on).  The fourth line under Windows shows a 9-byte response to 
the Get-Configuration-Descriptor request, and the last three lines under 
Linux show a disconnection and consequent error.

Since the traces agree up until the error occurs, I can only conclude 
that the cause of the difference in behavior must be something not 
captured in the traces.  And since there's no way to tell what it is, 
the only alternative is to add the new quirk flag that you proposed.

Go ahead and submit your patch.

Alan Stern

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

[Nikhil Solanke]

> Go ahead and submit your patch.

Thanks.

Before sending the patch, I wanted to clarify a couple of details:
1. The workaround succeeds when the initial configuration descriptor
request length is increased from 9 to 10 bytes. Larger values such as
16 and 48 also work. Would you prefer the patch to use the minimum
known-good value (10), or a larger value such as 16?
2. Since this patch would be submitted as a follow-up to this
discussion, should I submit it as a reply to this thread, preserving
the existing In-Reply-To/References headers?
3. What should be the quirk named? I have currently named it as
"USB_QUIRK_XBOX_CONFIG_DESC_FIX". But looking at the other existing
quirks, that name doesn't seem to fit in. Rather than naming it on
what it fixes, should it be named on what it does in the code base?
Something like "USB_QUIRK_INC_CONFIG_REQ_SIZE"?
4. Should I send the patch inline here or in a fresh email with a
proper subject line?

Also, if there is anything in particular you think I should do (or
avoid doing) when submitting the patch, I would appreciate the advice.
I have read the kernel patch submission guidelines, but any advice
specific to this submission process would be helpful, as this will be
my first submission to the kernel.

Nikhil Solanke

On Sun, 31 May 2026 at 07:14, Alan Stern <stern@rowland.harvard.edu> wrote:
>
> On Sun, May 31, 2026 at 02:17:32AM +0530, Nikhil Solanke wrote:
> > > However, there should have been messages in the log saying
> > > something like "unable to read config index 1 descriptor start: -71" and
> > > "can't read configurations, error -71".
> >
> > yep there is. I did mentioned in one of my replies. It does say:
> > unable to read config index 0 descriptor/start: -71
> >
> > Attaching the packet trace with the USB_QUIRK_DEVICE_QUALIFIER quirk set.
>
> Thanks.  There's no visible difference between the enumeration under
> Linux and under Windows until the disconnection occurs.  Here's the
> relevant part of the Windows trace:
>
> ffffc588ce0c3a20 0.327827 S Ci:2:001:0 s 80 06 0100 0000 0012 18 <
> ffffc588ce0c3a20 0.329841 C Ci:2:001:0 0 18 = 12010002 00000040 5e048e02 36000002 0301
> ffffc588ce0c3a20 0.329887 S Ci:2:001:0 s 80 06 0200 0000 0009 9 <
> ffffc588ce0c3a20 0.332841 C Ci:2:001:0 0 9 = 09023000 01010080 fa
>
> And here's the equivalent portion of the Linux trace:
>
> ffff88e64c1fd440 0.965292 S Ci:3:003:0 s 80 06 0100 0000 0012 18 <
> ffff88e64c1fd440 0.967582 C Ci:3:003:0 0 18 = 12010002 00000040 5e048e02 36000002 0301
> ffff88e64c1fd440 0.967613 S Ci:3:003:0 s 80 06 0200 0000 0009 9 <
> ffff88e605143ec0 0.973464 C Ii:3:001:1 0:2048 1 = 02
> ffff88e605143ec0 0.973467 S Ii:3:001:1 -115:2048 4 <
> ffff88e64c1fd440 0.975670 C Ci:3:003:0 -71 0
>
> As you can see, the first three lines are the same (from the fifth
> column on).  The fourth line under Windows shows a 9-byte response to
> the Get-Configuration-Descriptor request, and the last three lines under
> Linux show a disconnection and consequent error.
>
> Since the traces agree up until the error occurs, I can only conclude
> that the cause of the difference in behavior must be something not
> captured in the traces.  And since there's no way to tell what it is,
> the only alternative is to add the new quirk flag that you proposed.
>
> Go ahead and submit your patch.
>
> Alan Stern

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

[Alan Stern]

On Sun, May 31, 2026 at 01:19:16PM +0530, Nikhil Solanke wrote:
> > Go ahead and submit your patch.
> 
> Thanks.
> 
> Before sending the patch, I wanted to clarify a couple of details:
> 1. The workaround succeeds when the initial configuration descriptor
> request length is increased from 9 to 10 bytes. Larger values such as
> 16 and 48 also work. Would you prefer the patch to use the minimum
> known-good value (10), or a larger value such as 16?

Unlike Michal, I think the best change is the smallest one.  So 10 
instead of anything bigger.

> 2. Since this patch would be submitted as a follow-up to this
> discussion, should I submit it as a reply to this thread, preserving
> the existing In-Reply-To/References headers?

No, new patches should start their own thread.  Patches get threaded 
together only when they constitute a single series that has to be 
applied in order.

> 3. What should be the quirk named? I have currently named it as
> "USB_QUIRK_XBOX_CONFIG_DESC_FIX". But looking at the other existing
> quirks, that name doesn't seem to fit in. Rather than naming it on
> what it fixes, should it be named on what it does in the code base?
> Something like "USB_QUIRK_INC_CONFIG_REQ_SIZE"?

How about USB_QUIRK_CONFIG_REQ_SIZE?

> 4. Should I send the patch inline here or in a fresh email with a
> proper subject line?

In a fresh email.  Look at the mailing list archives on lore.kernel.org 
for examples to see how patches are formatted and presented.

> Also, if there is anything in particular you think I should do (or
> avoid doing) when submitting the patch, I would appreciate the advice.
> I have read the kernel patch submission guidelines, but any advice
> specific to this submission process would be helpful, as this will be
> my first submission to the kernel.

Make sure that the patch description thoroughly explains the problem and 
your solution.

Alan Stern

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

[Michal Pecio]

On Sat, 30 May 2026 02:52:28 +0530, Nikhil Solanke wrote:
> I have been investigating a USB enumeration issue affecting at least
> one controller exposing an Xbox-compatible interface (VID:PID
> 045e:028e).

Does it mean there are multiple clone devices pretending to be
something which originally had this VID:PID? I ask because
linux-hardware.org has many cases of this ID enumerating normally.

Only one instance of the other ID, also enumerating normally:
https://linux-hardware.org/?id=usb:3537-1094

> The device consistently fails enumeration under Linux during the
> initial configuration descriptor read. The failure is reproducible on
> multiple physical machines and also inside a VM.

It seems quite unlikely, but any chance that all the USB controllers
you tried were xHCI and the problem wouldn't occur on EHCI/OHCI/UHCI?

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

> The standard Linux path requests the initial configuration descriptor
> using USB_DT_CONFIG_SIZE (9 bytes). By introducing a new usbcore quirk
> and modifying usb_get_configuration() so that affected devices request
> 10 bytes instead of 9, enumeration succeeds reliably and the
> controller remains in its expected XInput mode.
> 
> Additional testing:
> 
> 9-byte request: fails
> 48-byte request: succeeds
> 16-byte request: succeeds
> 10-byte request: succeeds
> 
> I do not currently understand the underlying protocol-level reason for
> this behavior and would prefer to investigate the root cause rather
> than submit a workaround.

The difference is in the setup packet which is sent to the device and
how large a response will be accepted by the host conroller without
an error which would be reported as -EOVERFLOW in Linux.

In this case it looks like setup packet wLength field somehow affects
device behavior, which is odd because Windows works just fine.

Timing issue? I noticed that Windows gets the preceding device
descriptor response after 2ms, while all Linux traces show 2.3ms.
May indicate that the device is in a different state somehow.

Regards,
Michal

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

[Nikhil Solanke]

> Does it mean there are multiple clone devices pretending to be
> something which originally had this VID:PID? I ask because
> linux-hardware.org has many cases of this ID enumerating normally.

Yes. So these third party controllers on the market, advertise
themselves as compatible with PS3/4/5, android, Xbox, nintendo, etc.
From what i have observed, at least for the Xbox compatibility
(basically Xinput mode), these devices do one of the following:
1. Pretend to be an official xbox-360 or maybe xbox one s, by showing
themselves as having 045e:028e ids which is used by microsoft.
2. Use a different id altogether, but still expose all the
functionality mirroring the official Xbox controllers.

Since these have different compatibilities, each "mode" has its own
unique vid:pid pair. My game controller, in this case, has 045e:028e
for its Xinput/Xbox mode. And for the android mode, it has 3537:1094.
These modes can often be switched manually, usually by holding down
the menu button on the controller. This is so that users can switch
from xinput mode to dinput mode due to compatibility reasons.

Now, I haven't dabbled into the PS mode at all, so I can't say
anything about it. However, in android mode, most of these controllers
don't expose the rumble functionality at all that would otherwise be
present in the xinput mode.

> 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!.
Of course, I also tried it on bare metal Linux distro and Windows
operating systems without virtualization. The results were the same as
their VM counterparts.

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). Asking them to
install a tracing utility is a bit much, in my opinion.

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

> In this case it looks like setup packet wLength field somehow affects
> device behavior, which is odd because Windows works just fine.

Yes, and it's even odder because the device accepts and enumerates
perfectly fine with a wLength of 9 in Android mode.

> Timing issue? I noticed that Windows gets the preceding device
> descriptor response after 2ms, while all Linux traces show 2.3ms.
> May indicate that the device is in a different state somehow.

Could be, but that still doesn't explain why a larger wLength doesn't
trigger the error. And also these errors are very consistent.

Thanks,
NIkhil Solanke

On Sun, 31 May 2026 at 13:46, Michal Pecio <michal.pecio@gmail.com> wrote:
>
> On Sat, 30 May 2026 02:52:28 +0530, Nikhil Solanke wrote:
> > I have been investigating a USB enumeration issue affecting at least
> > one controller exposing an Xbox-compatible interface (VID:PID
> > 045e:028e).
>
> Does it mean there are multiple clone devices pretending to be
> something which originally had this VID:PID? I ask because
> linux-hardware.org has many cases of this ID enumerating normally.
>
> Only one instance of the other ID, also enumerating normally:
> https://linux-hardware.org/?id=usb:3537-1094
>
> > The device consistently fails enumeration under Linux during the
> > initial configuration descriptor read. The failure is reproducible on
> > multiple physical machines and also inside a VM.
>
> It seems quite unlikely, but any chance that all the USB controllers
> you tried were xHCI and the problem wouldn't occur on EHCI/OHCI/UHCI?
>
> 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 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.
>
> > The standard Linux path requests the initial configuration descriptor
> > using USB_DT_CONFIG_SIZE (9 bytes). By introducing a new usbcore quirk
> > and modifying usb_get_configuration() so that affected devices request
> > 10 bytes instead of 9, enumeration succeeds reliably and the
> > controller remains in its expected XInput mode.
> >
> > Additional testing:
> >
> > 9-byte request: fails
> > 48-byte request: succeeds
> > 16-byte request: succeeds
> > 10-byte request: succeeds
> >
> > I do not currently understand the underlying protocol-level reason for
> > this behavior and would prefer to investigate the root cause rather
> > than submit a workaround.
>
> The difference is in the setup packet which is sent to the device and
> how large a response will be accepted by the host conroller without
> an error which would be reported as -EOVERFLOW in Linux.
>
> In this case it looks like setup packet wLength field somehow affects
> device behavior, which is odd because Windows works just fine.
>
> Timing issue? I noticed that Windows gets the preceding device
> descriptor response after 2ms, while all Linux traces show 2.3ms.
> May indicate that the device is in a different state somehow.
>
> Regards,
> Michal

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

[Michal Pecio]

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

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

[Nikhil Solanke]

> What about xHCI vs EHCI?

I don't know how to test that. I couldn't find any BIOS settings
related to USB controllers on my laptop. There used to be an advanced
BIOS menu which revealed a lot more configuration options, but my
laptop vendor has unfortunately disabled or hidden it.
Previously it used to be activated by a combination of key presses,
but now they no longer work. I tried disabling xhci_hcd module but
`rmmod` didn't let me because it was a builtin module. My kernel has
been compiled with the following:
CONFIG_USB_XHCI_HCD=y
CONFIG_USB_XHCI_DBGCAP=y
CONFIG_USB_XHCI_PCI=y
CONFIG_USB_XHCI_PCI_RENESAS=m
CONFIG_USB_XHCI_PLATFORM=m
CONFIG_USB_XHCI_SIDEBAND=y
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_EHCI_ROOT_HUB_TT=y
CONFIG_USB_EHCI_TT_NEWSCHED=y
CONFIG_USB_EHCI_PCI=y
CONFIG_USB_EHCI_FSL=m
CONFIG_USB_EHCI_HCD_PLATFORM=m
CONFIG_USB_ROLES_INTEL_XHCI=m

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

The trace is exactly the same. wLength is not 255. no additional
packets. one-to-one replication (which was expected since it was a PCI
passthrough, so...). And I can't utilize the normal usb device
passthrough (or i think it's more of a redirection instead of complete
passthrough) either since the vid:pid pair is different after a failed
enumeration. The device doesn't initialize in xinput mode, so QEMU
doesn't even grab it. If I redirect the Android mode vid:pid, the
device stays in that mode on Windows as well.

Thanks,
Nikhil Solanke

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

[Alan Stern]

On Sun, May 31, 2026 at 12:38:43PM +0200, Michal Pecio wrote:
> 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 :(

I do.  But I don't have one of those Xbox clone devices to test.  And 
I don't think I have access to any computers with EHCI controllers 
running Windows 10/11.

Alan Stern

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

[Michal Pecio]

[-- Attachment #1: Type: text/plain, Size: 2119 bytes --]

On Sun, 31 May 2026 10:12:50 -0400, Alan Stern wrote:
> On Sun, May 31, 2026 at 12:38:43PM +0200, Michal Pecio wrote:
> > 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 :(  
> 
> I do.  But I don't have one of those Xbox clone devices to test.  And 
> I don't think I have access to any computers with EHCI controllers 
> running Windows 10/11.

The thing to check would be how Windows enumerates any random device,
since I expect that Microsoft designs their own peripherals to work in
Windows out of the box without special quirks.

I have done a quick test with QEMU today. Launched it with

    -device qemu-xhci

booted Windows 10 22H2 and typed in QEMU monitor

    device_add usb-tablet,pcap=qemu-tablet-w10.pcap

The result is attached. The first device descriptor request uses
wLength=64, followed by proper length, and the first configuration
descriptor requests uses wLength=255.

Then there is some other stuff, and another request for the device
descriptor followed by a 9 byte request for configuration. These may
be the requests being logged by Wireshark, but I haven't installed
Wireshark in this VM yet to confirm and correlate.

So this is why I don't trust Wireshark on Windows very much.

And yes, if more people can confirm that Windows behaves like that,
I think that a quirk which mimics this exact behavior could prove more
useful than a wLength=10 one.

We don't know why the device behaves like that. Maybe it's a buffer
overflow in its FW, maybe it fingerprints the host to automagically
select "proper" mode of operation. Maybe the next such device will
check for 255 bytes exactly.

Regards,
Michal

[-- Attachment #2: qemu-tablet-w10.pcap --]
[-- Type: application/vnd.tcpdump.pcap, Size: 2843 bytes --]

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

[Nikhil Solanke]

[-- Attachment #1: Type: text/plain, Size: 2108 bytes --]

It didn't occur to me before, but since i had a patched kernel which
enumerated and initialized the device properly, i was able to do a usb
device passthrough/redirect of the controller when it is in xinput
mode. I have utilized libvirt for this purpose. I tried doing what
Michal did by using qemu cmdline directly and specifying the location
for pcap file, but for some reason the pcap file only contained
request packets. there were no response packets. maybe i had messed
something up. the command line i used was as follows:
qemu-system-x86_64 \
  -enable-kvm \
  -machine q35 \
  -cpu host \
  -smp 4 \
  -m 4096 \
  -drive if=pflash,format=raw,readonly=on,file=/usr/share/edk2/x64/OVMF_CODE.4m.fd
\
  -drive if=pflash,format=raw,file=/var/lib/libvirt/qemu/nvram/archlinux_VARS.fd
\
  -drive file=archlinux.qcow2,if=virtio,format=qcow2 \
  -device qemu-xhci,id=usb \
  -device usb-host,id=pad,vendorid=0x045e,productid=0x028e,hostbus=3,hostaddr=2,pcap=/tmp/usb.pcap
\
  -display gtk \
  -boot menu=on

I have attached the wireshark captures from the linux guest as well as
the libvirt xml. i also had tried using ehci/usb 2 on the guest.

In both these cases, the devices initializes properly in xinput mode.
But as soon as I perform a PCI Passthrough of the host usb controller,
the device no longer enumerates and fails with the "unable to read
config index 0 descriptor/start: -71" error even in the vm. I also
tried plugging the device on my friend's laptop using a live iso. the
enumeration failed there too. (Maybe I will have to find someone with
an old machine that has proper EHCI USB controller).

If the host has unpatched kernel, and the device is initialized in the
android mode, the guest, whether it be Windows or Linux, gets the
device in Android mode only.

So should I proceed with the patch? And what should be the wLength? I
personally think going with 10 would be safer. using something like
255 feels riskier in theory, as in it may cause a buffer overflow on
buggy firmware, even though, realistically, the chances of that
happening are (I believe) none.

Thanks,
Nikhil Solanke

[-- Attachment #2: linux_vm_ehci.xml --]
[-- Type: text/xml, Size: 8841 bytes --]

<domain type='kvm'>
  <name>archlinux</name>
  <uuid>97bd4323-3933-4d81-b087-5f6eb4bfd40d</uuid>
  <metadata>
    <libosinfo:libosinfo xmlns:libosinfo="http://libosinfo.org/xmlns/libvirt/domain/1.0">
      <libosinfo:os id="http://archlinux.org/archlinux/rolling"/>
    </libosinfo:libosinfo>
  </metadata>
  <memory unit='KiB'>4194304</memory>
  <currentMemory unit='KiB'>4194304</currentMemory>
  <vcpu placement='static'>4</vcpu>
  <os firmware='efi'>
    <type arch='x86_64' machine='pc-q35-10.2'>hvm</type>
    <firmware>
      <feature enabled='no' name='enrolled-keys'/>
      <feature enabled='yes' name='secure-boot'/>
    </firmware>
    <loader readonly='yes' secure='yes' type='pflash' format='raw'>/usr/share/edk2/x64/OVMF_CODE.secboot.4m.fd</loader>
    <nvram template='/usr/share/edk2/x64/OVMF_VARS.4m.fd' templateFormat='raw' format='raw'>/var/lib/libvirt/qemu/nvram/archlinux_VARS.fd</nvram>
  </os>
  <features>
    <acpi/>
    <apic/>
    <vmport state='off'/>
    <smm state='on'/>
  </features>
  <cpu mode='host-passthrough' check='none' migratable='on'>
    <topology sockets='1' dies='1' clusters='1' cores='2' threads='2'/>
    <feature policy='require' name='topoext'/>
  </cpu>
  <clock offset='utc'>
    <timer name='rtc' tickpolicy='catchup'/>
    <timer name='pit' tickpolicy='delay'/>
    <timer name='hpet' present='no'/>
  </clock>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>destroy</on_crash>
  <pm>
    <suspend-to-mem enabled='no'/>
    <suspend-to-disk enabled='no'/>
  </pm>
  <devices>
    <emulator>/usr/bin/qemu-system-x86_64</emulator>
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2' discard='unmap'/>
      <source file='/var/lib/libvirt/images/archlinux.qcow2'/>
      <target dev='vda' bus='virtio'/>
      <boot order='2'/>
      <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/>
    </disk>
    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <target dev='sda' bus='sata'/>
      <readonly/>
      <boot order='1'/>
      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
    </disk>
    <controller type='pci' index='0' model='pcie-root'/>
    <controller type='pci' index='1' model='pcie-root-port'>
      <model name='pcie-root-port'/>
      <target chassis='1' port='0x10'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0' multifunction='on'/>
    </controller>
    <controller type='pci' index='2' model='pcie-root-port'>
      <model name='pcie-root-port'/>
      <target chassis='2' port='0x11'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x1'/>
    </controller>
    <controller type='pci' index='3' model='pcie-root-port'>
      <model name='pcie-root-port'/>
      <target chassis='3' port='0x12'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x2'/>
    </controller>
    <controller type='pci' index='4' model='pcie-root-port'>
      <model name='pcie-root-port'/>
      <target chassis='4' port='0x13'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x3'/>
    </controller>
    <controller type='pci' index='5' model='pcie-root-port'>
      <model name='pcie-root-port'/>
      <target chassis='5' port='0x14'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x4'/>
    </controller>
    <controller type='pci' index='6' model='pcie-root-port'>
      <model name='pcie-root-port'/>
      <target chassis='6' port='0x15'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x5'/>
    </controller>
    <controller type='pci' index='7' model='pcie-root-port'>
      <model name='pcie-root-port'/>
      <target chassis='7' port='0x16'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x6'/>
    </controller>
    <controller type='pci' index='8' model='pcie-root-port'>
      <model name='pcie-root-port'/>
      <target chassis='8' port='0x17'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x7'/>
    </controller>
    <controller type='pci' index='9' model='pcie-root-port'>
      <model name='pcie-root-port'/>
      <target chassis='9' port='0x18'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0' multifunction='on'/>
    </controller>
    <controller type='pci' index='10' model='pcie-root-port'>
      <model name='pcie-root-port'/>
      <target chassis='10' port='0x19'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x1'/>
    </controller>
    <controller type='pci' index='11' model='pcie-root-port'>
      <model name='pcie-root-port'/>
      <target chassis='11' port='0x1a'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x2'/>
    </controller>
    <controller type='pci' index='12' model='pcie-root-port'>
      <model name='pcie-root-port'/>
      <target chassis='12' port='0x1b'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x3'/>
    </controller>
    <controller type='pci' index='13' model='pcie-root-port'>
      <model name='pcie-root-port'/>
      <target chassis='13' port='0x1c'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x4'/>
    </controller>
    <controller type='pci' index='14' model='pcie-root-port'>
      <model name='pcie-root-port'/>
      <target chassis='14' port='0x1d'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x5'/>
    </controller>
    <controller type='sata' index='0'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/>
    </controller>
    <controller type='virtio-serial' index='0'>
      <address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x0'/>
    </controller>
    <controller type='usb' index='0' model='ich9-ehci1'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x1d' function='0x7'/>
    </controller>
    <controller type='usb' index='0' model='ich9-uhci1'>
      <master startport='0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x1d' function='0x0' multifunction='on'/>
    </controller>
    <controller type='usb' index='0' model='ich9-uhci2'>
      <master startport='2'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x1d' function='0x1'/>
    </controller>
    <controller type='usb' index='0' model='ich9-uhci3'>
      <master startport='4'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x1d' function='0x2'/>
    </controller>
    <interface type='network'>
      <mac address='52:54:00:28:6c:94'/>
      <source network='default'/>
      <model type='virtio'/>
      <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/>
    </interface>
    <serial type='pty'>
      <target type='isa-serial' port='0'>
        <model name='isa-serial'/>
      </target>
    </serial>
    <console type='pty'>
      <target type='serial' port='0'/>
    </console>
    <channel type='unix'>
      <target type='virtio' name='org.qemu.guest_agent.0'/>
      <address type='virtio-serial' controller='0' bus='0' port='1'/>
    </channel>
    <channel type='spicevmc'>
      <target type='virtio' name='com.redhat.spice.0'/>
      <address type='virtio-serial' controller='0' bus='0' port='2'/>
    </channel>
    <input type='tablet' bus='usb'>
      <address type='usb' bus='0' port='1'/>
    </input>
    <input type='mouse' bus='ps2'/>
    <input type='keyboard' bus='ps2'/>
    <graphics type='spice' port='-1' autoport='no'>
      <listen type='address'/>
      <image compression='off'/>
      <gl enable='no'/>
    </graphics>
    <sound model='ich9'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x1b' function='0x0'/>
    </sound>
    <audio id='1' type='spice'/>
    <video>
      <model type='virtio' heads='1' primary='yes'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/>
    </video>
    <hostdev mode='subsystem' type='usb' managed='yes'>
      <source>
        <vendor id='0x045e'/>
        <product id='0x028e'/>
      </source>
      <address type='usb' bus='0' port='4'/>
    </hostdev>
    <redirdev bus='usb' type='spicevmc'>
      <address type='usb' bus='0' port='2'/>
    </redirdev>
    <redirdev bus='usb' type='spicevmc'>
      <address type='usb' bus='0' port='3'/>
    </redirdev>
    <watchdog model='itco' action='reset'/>
    <memballoon model='virtio'>
      <address type='pci' domain='0x0000' bus='0x05' slot='0x00' function='0x0'/>
    </memballoon>
    <rng model='virtio'>
      <backend model='random'>/dev/urandom</backend>
      <address type='pci' domain='0x0000' bus='0x06' slot='0x00' function='0x0'/>
    </rng>
  </devices>
</domain>


[-- Attachment #3: linux_vm_xhci.xml --]
[-- Type: text/xml, Size: 8271 bytes --]

<domain type='kvm'>
  <name>archlinux</name>
  <uuid>97bd4323-3933-4d81-b087-5f6eb4bfd40d</uuid>
  <metadata>
    <libosinfo:libosinfo xmlns:libosinfo="http://libosinfo.org/xmlns/libvirt/domain/1.0">
      <libosinfo:os id="http://archlinux.org/archlinux/rolling"/>
    </libosinfo:libosinfo>
  </metadata>
  <memory unit='KiB'>4194304</memory>
  <currentMemory unit='KiB'>4194304</currentMemory>
  <vcpu placement='static'>4</vcpu>
  <os firmware='efi'>
    <type arch='x86_64' machine='pc-q35-10.2'>hvm</type>
    <firmware>
      <feature enabled='no' name='enrolled-keys'/>
      <feature enabled='yes' name='secure-boot'/>
    </firmware>
    <loader readonly='yes' secure='yes' type='pflash' format='raw'>/usr/share/edk2/x64/OVMF_CODE.secboot.4m.fd</loader>
    <nvram template='/usr/share/edk2/x64/OVMF_VARS.4m.fd' templateFormat='raw' format='raw'>/var/lib/libvirt/qemu/nvram/archlinux_VARS.fd</nvram>
  </os>
  <features>
    <acpi/>
    <apic/>
    <vmport state='off'/>
    <smm state='on'/>
  </features>
  <cpu mode='host-passthrough' check='none' migratable='on'>
    <topology sockets='1' dies='1' clusters='1' cores='2' threads='2'/>
    <feature policy='require' name='topoext'/>
  </cpu>
  <clock offset='utc'>
    <timer name='rtc' tickpolicy='catchup'/>
    <timer name='pit' tickpolicy='delay'/>
    <timer name='hpet' present='no'/>
  </clock>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>destroy</on_crash>
  <pm>
    <suspend-to-mem enabled='no'/>
    <suspend-to-disk enabled='no'/>
  </pm>
  <devices>
    <emulator>/usr/bin/qemu-system-x86_64</emulator>
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2' discard='unmap'/>
      <source file='/var/lib/libvirt/images/archlinux.qcow2'/>
      <target dev='vda' bus='virtio'/>
      <boot order='2'/>
      <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/>
    </disk>
    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <target dev='sda' bus='sata'/>
      <readonly/>
      <boot order='1'/>
      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
    </disk>
    <controller type='pci' index='0' model='pcie-root'/>
    <controller type='pci' index='1' model='pcie-root-port'>
      <model name='pcie-root-port'/>
      <target chassis='1' port='0x10'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0' multifunction='on'/>
    </controller>
    <controller type='pci' index='2' model='pcie-root-port'>
      <model name='pcie-root-port'/>
      <target chassis='2' port='0x11'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x1'/>
    </controller>
    <controller type='pci' index='3' model='pcie-root-port'>
      <model name='pcie-root-port'/>
      <target chassis='3' port='0x12'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x2'/>
    </controller>
    <controller type='pci' index='4' model='pcie-root-port'>
      <model name='pcie-root-port'/>
      <target chassis='4' port='0x13'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x3'/>
    </controller>
    <controller type='pci' index='5' model='pcie-root-port'>
      <model name='pcie-root-port'/>
      <target chassis='5' port='0x14'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x4'/>
    </controller>
    <controller type='pci' index='6' model='pcie-root-port'>
      <model name='pcie-root-port'/>
      <target chassis='6' port='0x15'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x5'/>
    </controller>
    <controller type='pci' index='7' model='pcie-root-port'>
      <model name='pcie-root-port'/>
      <target chassis='7' port='0x16'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x6'/>
    </controller>
    <controller type='pci' index='8' model='pcie-root-port'>
      <model name='pcie-root-port'/>
      <target chassis='8' port='0x17'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x7'/>
    </controller>
    <controller type='pci' index='9' model='pcie-root-port'>
      <model name='pcie-root-port'/>
      <target chassis='9' port='0x18'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0' multifunction='on'/>
    </controller>
    <controller type='pci' index='10' model='pcie-root-port'>
      <model name='pcie-root-port'/>
      <target chassis='10' port='0x19'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x1'/>
    </controller>
    <controller type='pci' index='11' model='pcie-root-port'>
      <model name='pcie-root-port'/>
      <target chassis='11' port='0x1a'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x2'/>
    </controller>
    <controller type='pci' index='12' model='pcie-root-port'>
      <model name='pcie-root-port'/>
      <target chassis='12' port='0x1b'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x3'/>
    </controller>
    <controller type='pci' index='13' model='pcie-root-port'>
      <model name='pcie-root-port'/>
      <target chassis='13' port='0x1c'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x4'/>
    </controller>
    <controller type='pci' index='14' model='pcie-root-port'>
      <model name='pcie-root-port'/>
      <target chassis='14' port='0x1d'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x5'/>
    </controller>
    <controller type='sata' index='0'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/>
    </controller>
    <controller type='virtio-serial' index='0'>
      <address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x0'/>
    </controller>
    <controller type='usb' index='0' model='qemu-xhci' ports='15'>
      <address type='pci' domain='0x0000' bus='0x02' slot='0x00' function='0x0'/>
    </controller>
    <interface type='network'>
      <mac address='52:54:00:28:6c:94'/>
      <source network='default'/>
      <model type='virtio'/>
      <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/>
    </interface>
    <serial type='pty'>
      <target type='isa-serial' port='0'>
        <model name='isa-serial'/>
      </target>
    </serial>
    <console type='pty'>
      <target type='serial' port='0'/>
    </console>
    <channel type='unix'>
      <target type='virtio' name='org.qemu.guest_agent.0'/>
      <address type='virtio-serial' controller='0' bus='0' port='1'/>
    </channel>
    <channel type='spicevmc'>
      <target type='virtio' name='com.redhat.spice.0'/>
      <address type='virtio-serial' controller='0' bus='0' port='2'/>
    </channel>
    <input type='tablet' bus='usb'>
      <address type='usb' bus='0' port='1'/>
    </input>
    <input type='mouse' bus='ps2'/>
    <input type='keyboard' bus='ps2'/>
    <graphics type='spice' port='-1' autoport='no'>
      <listen type='address'/>
      <image compression='off'/>
      <gl enable='no'/>
    </graphics>
    <sound model='ich9'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x1b' function='0x0'/>
    </sound>
    <audio id='1' type='spice'/>
    <video>
      <model type='virtio' heads='1' primary='yes'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/>
    </video>
    <hostdev mode='subsystem' type='usb' managed='yes'>
      <source>
        <vendor id='0x045e'/>
        <product id='0x028e'/>
      </source>
      <address type='usb' bus='0' port='4'/>
    </hostdev>
    <redirdev bus='usb' type='spicevmc'>
      <address type='usb' bus='0' port='2'/>
    </redirdev>
    <redirdev bus='usb' type='spicevmc'>
      <address type='usb' bus='0' port='3'/>
    </redirdev>
    <watchdog model='itco' action='reset'/>
    <memballoon model='virtio'>
      <address type='pci' domain='0x0000' bus='0x05' slot='0x00' function='0x0'/>
    </memballoon>
    <rng model='virtio'>
      <backend model='random'>/dev/urandom</backend>
      <address type='pci' domain='0x0000' bus='0x06' slot='0x00' function='0x0'/>
    </rng>
  </devices>
</domain>


[-- Attachment #4: controller_linux_vm_xhci_libvirt_usb_hostdev.pcapng --]
[-- Type: application/octet-stream, Size: 7436 bytes --]

[-- Attachment #5: controller_linux_vm_ehci_libvirt_usb_hostdev.pcapng --]
[-- Type: application/octet-stream, Size: 7136 bytes --]

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

[Alan Stern]

On Mon, Jun 01, 2026 at 08:49:09AM +0200, Michal Pecio wrote:
> The thing to check would be how Windows enumerates any random device,
> since I expect that Microsoft designs their own peripherals to work in
> Windows out of the box without special quirks.
> 
> I have done a quick test with QEMU today. Launched it with
> 
>     -device qemu-xhci
> 
> booted Windows 10 22H2 and typed in QEMU monitor
> 
>     device_add usb-tablet,pcap=qemu-tablet-w10.pcap
> 
> The result is attached. The first device descriptor request uses
> wLength=64, followed by proper length, and the first configuration
> descriptor requests uses wLength=255.

Okay, that would be a good reason for changing the Linux code to match.

> Then there is some other stuff, and another request for the device
> descriptor followed by a 9 byte request for configuration. These may
> be the requests being logged by Wireshark, but I haven't installed
> Wireshark in this VM yet to confirm and correlate.

I suspect that the Windows kernel doesn't route packet information to 
sniffers like Wireshark until after device initialization has completed.  
This would mean that Wireshark never sees things like the initial 
request for the device descriptor and perhaps the config descriptor(s), 
as well as the Set-Address request (on non-xHCI hosts).

> So this is why I don't trust Wireshark on Windows very much.

I believe Wireshark on Windows is okay for transfers after the 
initialization, even if the results are a little idiosyncratic.  And 
I've never seen any explanation for why Windows asks for the various 
descriptors repeatedly, so many times.

> And yes, if more people can confirm that Windows behaves like that,
> I think that a quirk which mimics this exact behavior could prove more
> useful than a wLength=10 one.

I'll run a test when I have a chance.

> We don't know why the device behaves like that. Maybe it's a buffer
> overflow in its FW, maybe it fingerprints the host to automagically
> select "proper" mode of operation. Maybe the next such device will
> check for 255 bytes exactly.

If the bus analyzer confirms the first Get-Config-Descriptor request is 
for 255 bytes then I agree, we should do the same thing.  (But why does 
it use 255?  Wouldn't something like 64 -- a multiple of the maxpacket 
value -- make more sense?)  Also, it would be interesting to see what 
Mac OS X does and how the Xbox clones react.

Alan Stern