USB Mass Storage Gadget - how to convincingly emulate a flash drive?

Question

I've got a Pi Zero W that I'm using in OTG/gadget mode. I've activated dwc2 USB, partitioned and formatted the file that is to be used as filesystem and loaded g_mass_storage. It is working fine in Windows - I can connect and see the contents, add/delete files, eject and reconnect seeing changes fine. I can mount it in Raspbian to check contents and can also attach it to other devices and interact with it fine.

However, I've got some devices that are very picky about what USB devices they will connect to (basically only flash drives). The problem is the OTG mass storage is being identified as "File-Stor Gadget (Rev: 0404)", which is causing it to be rejected.

I can successfully use a USB flash drive in the target devices and have scraped the vendor/product ID from it to see if I can mimic them via g_mass_storage.

I have therefore adjusted modprobe to the following:

sudo modprobe g_mass_storage file=/home/pi/piusb.bin stall=0 removable=1 idVendor=0x0781 idProduct=0x5572 bcdDevice=0x011a iManufacturer="SanDisk" iProduct="Cruzer Switch" iSerialNumber="1234567890"

Unfortunately this doesn't seem to make any difference to how it is presented to the device.

Any thoughts/suggestions?

Thanks!

PS When connecting to Windows, here's what the USB mass storage displays:

USBSTOR\DISK&VEN_LINUX&PROD_FILE-STOR_GADGET&REV_0404\1234567890&0
USBSTOR\DiskLinux___File-Stor_Gadget0404
USBSTOR\DiskLinux___File-Stor_Gadget
USBSTOR\DiskLinux___
USBSTOR\Linux___File-Stor_Gadget0
Linux___File-Stor_Gadget0
USBSTOR\GenDisk
GenDisk

& here's what SanDisk shows:

USBSTOR\DISK&VEN_SANDISK&PROD_CRUZER_SWITCH&REV_1.26\4C532015741508522393&0
USBSTOR\DiskSanDisk_Cruzer_Switch___1.26
USBSTOR\DiskSanDisk_Cruzer_Switch___
USBSTOR\DiskSanDisk_
USBSTOR\SanDisk_Cruzer_Switch___1
SanDisk_Cruzer_Switch___1
USBSTOR\GenDisk
GenDisk

Answer 1

The answer is that inquiry_string cannot be changed when you're using g_mass_storage unless you recompile the module. But the desired outcome can be achieved with libcomposite instead. There is a working script for Pi Zero here now: Change Raspberry Pi Zero USB Gadget name from Linux File-Stor Gadget

Answer 2

Solution ended up being to update the Pi Raspbian OS to the latest version - this updated the OTG Gadget and no longer caused the behaviour outlined above.

Answer 3

You don't say the OS of your device that you're testing against. If it's Windows based, the following snippet from the this article will help. Hopefully you have the appropriate access to your device. If not, look for some method to reset it to factory defaults.

Debugging Windows USB Stack

Being the guy who always strives for the minimal test case, I’ve tested the script with the bare minimum ConfigFS setup for a composite serial + network device, but the drivers were not correctly installed. I then added the OS Descriptors, but it still doesn’t work. This caused me a lot of hair pulling, and made me doubt whether this OS Descriptor nonsense even works at all.

It was not until I fully read the page on Microsoft OS Descriptors did I realise that Windows caches the presence of OS Descriptors the first time a device is plugged in (emphasis mine):

When a new device is attached to a computer for the first time, an operating system […] will request the string descriptor that is at

index 0xEE. […] After the operating system requests a Microsoft OS String Descriptor from a device, it creates the following registry key..

The operating system creates a registry entry, named osvc, under this registry key that indicates whether the device supports Microsoft

OS Descriptors. If the device does not provide a valid response the first time that the operating system queries it for a Microsoft OS String Descriptor, the operating system will make no further requests for that descriptor.

This has also been highlighted by the libwdi wiki on WCID devices:

When Windows checks for this String Descriptor, one of the first thing that happens is the creation of a registry entry, under

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\usbflags, that is the concatenation of VID+PID+BCD_RELEASE_NUMBER (This key is never deleted).

During testing on Windows, it is therefore necessary to remove the “UsbFlags” key for that particular device that indicates to the OS whether or not it supports Microsoft OS Descriptors. After deleting the key, the script that advertises the OS Descriptors should successfully convince Windows to use the RNDIS drivers automatically.

To ensure that your device will work on other Windows PCs, avoid using common or well-known vendor/product ID and instead, use your own VID/PID that has been uniquely assigned to you.