3

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
  • I'm not familiar enough with the g_mass_storage driver to comment on your (IMO brilliant) mimicry idea, but: 1. This should present as a USB storage class device, which per USB specs should be supported universally (so I'm very surprised this didn't just work), and 2. I think I'll be putting my zero w in my car to replace a USB stick with MP3s (I'll be able to rsync automatically when I'm home! Love it!). – BJ Black May 28 '17 at 6:31
  • Haha glad you like the idea :D Be careful when updating via rsync to stop the gadget service first - you should only change files from either the Linux side (via mounting the file) or the USB host side (by running gadget service and plugging it in to host) - it doesn't like things being updated simultaneously on both sides! No idea why the it's not passing the vendor/manuf IDs etc on properly - the iSerial number is (I can see it in Windows), so frustrating! – EDIflyer May 28 '17 at 16:06
  • I have same problem as you but I think something is missing because I use the latest version, raspbian-2018-04-19, and it still says "USBSTOR\DiskLinux___File-Stor_Gadget" in Windows, even tho if I check /sys/module/g_mass_storage/parameters/* I get the correct values. – alin.calinciuc Jun 26 '18 at 18:40
  • I switched to 4.9.36+ as you described here spinics.net/lists/linux-usb/msg158912.html , but I couldn't make it work either on this version. – alin.calinciuc Jun 26 '18 at 19:29
1

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.

  • I am using the latest version, raspbian-2018-04-19, and the instruction you mentioned but on windows it still says USBSTOR\DiskLinux___File-Stor_Gadget . It must be something you did to fix the issue. – alin.calinciuc Jun 26 '18 at 18:33
  • Hmm, interesting - I can't think of anything I did differently apart from update the Raspbian version. I've double-checked my code and still have the same modprobe code being used. – EDIflyer Jun 28 '18 at 8:34
  • Can you share an image of your raspberry pi zero so I can check if it works with my device ? At this moment I have the following errors when I connect the to the device: pastebin.com/EAx689zP – alin.calinciuc Jun 28 '18 at 17:02
  • Can you paste your /boot/cmdline.txt parameters please ? – alin.calinciuc Jun 28 '18 at 17:36
  • /boot/cmdline.txt is as follows: dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=PARTUUID=f1db339a-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait – EDIflyer Jul 10 '18 at 21:14
0

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.

  • 1
    Thanks - turns out updating Linux OS version seemed to solve the issue in the end! – EDIflyer Nov 6 '17 at 20:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.