Linux USB
 help / color / mirror / Atom feed
From: Michal Pecio <michal.pecio@gmail.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Nikhil Solanke <nikhilsolanke5@gmail.com>,
	linux-usb@vger.kernel.org, gregkh@linuxfoundation.org,
	mathias.nyman@linux.intel.com, sakari.ailus@linux.intel.com,
	katieeliu@tencent.com, johannes.bruederl@gmail.com,
	kees@kernel.org, dengjie03@kylinos.cn, limiao@kylinos.cn,
	wse@tuxedocomputers.com, dev@a1rm4x.com, vahnenko2003@gmail.com,
	cs@tuxedo.de, lijiayi@kylinos.cn, oneukum@suse.com,
	bence98@sch.bme.hu, eeodqql09@gmail.com
Subject: Re: USB: Request for guidance investigating configuration descriptor enumeration failure
Date: Thu, 4 Jun 2026 12:53:23 +0200	[thread overview]
Message-ID: <20260604125323.1bcb40d7.michal.pecio@gmail.com> (raw)
In-Reply-To: <49acc9dd-9d2e-4a37-9b41-de5e16445461@rowland.harvard.edu>

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

On Wed, 3 Jun 2026 22:02:44 -0400, Alan Stern wrote:
> I used a bus analyzer to capture what happens when Windows 11 
> initializes and enumerates a USB-2 flash drive.  The short answer is 
> that yes, the initial Get-Configuration-Descriptor request is for 255 
> bytes.

Could you also try a few BIOSes, UEFIs and such?
Or anything from Apple?

It has occurred to me that if Linux enumeration switches Nikhil's
device more or less permanently to Android mode then his BIOS must
be using some other scheme too if the device to survives intact.

I also tried Windows 95 OSR 2.1 in QEMU, which AFAIK is the fist
Windows release to support USB in any form. It works like W10:

Get Descriptor DEVICE 64 bytes
Set Address
Get Descriptor DEVICE 18 bytes
Get Descriptor CONFIGURATION 255 bytes
Get Descriptor CONFIGURATION actual size, only if greater than 255

And an emulated SuperSpeed UAS device with W10, which is different:

<xHCI Address Device command *probably* goes here>
Get Descriptor DEVICE 18 bytes
Get Descriptor CONFIGURATION 255 bytes
Get Descriptor CONFIGURATION actual size, only if greater than 255
Get Descriptor BOS 255 bytes

I'd guess that MS tries to get whole descriptors in one go, but is
worried (or aware) of buggy devices crashing when wLength > 255.

Notable SuperSpeed differences vs Linux:
- doesn't bother with the DEVICE request before Set Address
- CONFIGURATION is queried before BOS
- first BOS request is for 255 bytes

Some of these may be responsible for the recent BOS problems with
some particular buggy video capture devices.

I'm attaching W95 enumerating a full-speed device with configuration
exceeding 255 bytes and W10 enumerating a SuperSpeed UAS device (the
first few packets are QEMU BIOS, which is similar to Linux).

Regards,
Michal

[-- Attachment #2: ms2109-w95.pcap --]
[-- Type: application/vnd.tcpdump.pcap, Size: 1470 bytes --]

[-- Attachment #3: uas-w10.pcap --]
[-- Type: application/vnd.tcpdump.pcap, Size: 3119 bytes --]

  reply	other threads:[~2026-06-04 10:53 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-29 21:22 USB: Request for guidance investigating configuration descriptor enumeration failure Nikhil Solanke
2026-05-30  1:58 ` Alan Stern
2026-05-30  6:57   ` Nikhil Solanke
2026-05-30 14:48     ` Alan Stern
2026-05-30 16:48       ` Nikhil Solanke
2026-05-30 20:26         ` Alan Stern
2026-05-30 20:47           ` Nikhil Solanke
2026-05-31  1:44             ` Alan Stern
2026-05-31  7:49               ` Nikhil Solanke
2026-05-31 14:03                 ` Alan Stern
2026-05-31  8:16 ` Michal Pecio
2026-05-31 10:11   ` Nikhil Solanke
2026-05-31 10:38     ` Michal Pecio
2026-05-31 11:20       ` Nikhil Solanke
2026-05-31 14:12       ` Alan Stern
2026-06-01  6:49         ` Michal Pecio
2026-06-01  9:01           ` Nikhil Solanke
2026-06-02 17:30             ` Michal Pecio
2026-06-04  2:02               ` Alan Stern
2026-06-04 10:53                 ` Michal Pecio [this message]
2026-06-07  2:17                   ` Alan Stern
2026-06-07 20:02                     ` Nikhil Solanke
2026-06-07 21:25                     ` Michal Pecio
2026-06-01 13:02           ` Alan Stern

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260604125323.1bcb40d7.michal.pecio@gmail.com \
    --to=michal.pecio@gmail.com \
    --cc=bence98@sch.bme.hu \
    --cc=cs@tuxedo.de \
    --cc=dengjie03@kylinos.cn \
    --cc=dev@a1rm4x.com \
    --cc=eeodqql09@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=johannes.bruederl@gmail.com \
    --cc=katieeliu@tencent.com \
    --cc=kees@kernel.org \
    --cc=lijiayi@kylinos.cn \
    --cc=limiao@kylinos.cn \
    --cc=linux-usb@vger.kernel.org \
    --cc=mathias.nyman@linux.intel.com \
    --cc=nikhilsolanke5@gmail.com \
    --cc=oneukum@suse.com \
    --cc=sakari.ailus@linux.intel.com \
    --cc=stern@rowland.harvard.edu \
    --cc=vahnenko2003@gmail.com \
    --cc=wse@tuxedocomputers.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox