Why can't certain USB Mass Storage Devices be detected by some hardware?

Question

I am trying to modify a mass storage driver using the composite usb framework to allow an embedded mass storage device to be visible on my Xbox 360. I have confirmed that this is not a simple VendorID/ProductID block.

I would like to understand what specifically prevents some devices, say the Xbox 360, from seeing certain mass storage devices. Although my question is specific to the Xbox, a generic answer that explains why a device cannot see certain types of mass storage, would also be acceptable.

I made the observation that out of the flash devices I own, the ones that do not work are those with only 2 Endpoints defined (Bulk IN, Bulk OUT). Whereas all mass storage devices containing 3 Endpoints (Bulk IN, Bulk OUT, Interrupt IN) have worked. Is this a relevant observation or coincidence?

Answer 1

There are 2 reasons why a mass storage device might not work on a given host.

The simplest reason is the Vendor and Product ID block. Some software, like iTunes will prevent devices from syncing based on the Vendor and Product ID that is presented. This is a very rudimentary prevention and is easily bypassed by spoofing Vendor/Product ID.

For the Xbox 360 specifically, the reason is a combination of Xbox 360 SCSI implementation and USB device driver implementation. The specification for USB Mass Storage contains a structure called the Command Block Wrapper, this structure contains a member bCBWCBLength that declares the length of the command block to be executed. According to the spec, this can legally contain values from 1 to 16.

While the length of command blocks can legally be from 1 to 16, the traditional length of CDBs are 6, 10, 12, or 16 bytes - the length varies depending on the command. For instance the TEST UNIT READY command is 6 bytes while MODE SENSE has a 6 byte and a 10 byte version.

The Xbox 360 happens to send certain commands such as TEST UNIT READY as 10 bytes rather than 6. For USB Devices with older drivers (like the Palm Pre and Android), this can cause a problem because the driver does not know what to do with these oddly sized CDBs.

Ultimately the problem is a mixture of poor driver handling on the device side and odd SCSI implementation on the host side. Unless you are Microsoft, the fix is to modify your mass storage driver to handle the oddly sized CBW length field.

The observation regarding bulk-only vs bulk interrupt endpoints was only a coincidence and had nothing to do with the problem, solution or anything in-between.