USB FS device, MSC with more than one LUN, Windows: weird problem

[Eugene Solo]

Posted on November 27, 2017 at 14:01

I've successfully implemented MSC device on USB FS port, it works perfectly under Windows (7 and XP) and Linux (Ubuntu 16)...

...but only if MaxLun is 0.

I've implemented 3 independent storage devices (actually, all of them are RAM-drives, for debugging purposes; just with slightly different capacity), modified some functions, modified USB BOT handler so it could track status for each LUN independently. Under Linux, I've achieved write speed about 1MB/s with some code optimizations. I've tested all LUNs under linux by formatting/writing/copying files, by playback of MP3 and video; i've copied data from system disk to ramdrive and between ramdrives, in each possible combination.

In my debugging console I see INQUIRY requests for each LUN when device is connected to Linux host (it asks for maxlun and then sends INQUIRY to each of them). I see how Linux host poking each LUN for ready flag. But Windows hosts asks only LUN0 and never asks others, never tests them for anything.

I've found (by googling) that it may be problem with Device Serial number, but I have correct device descriptor with correct serial number : twelve utf16 chars, '000000000001'.

I guess, it may be problem with the Windows host itself, but I don't know how to diagnose it. More than that, i have cardreader device with 4 LUNs and it works perfectly under same windows host!

Any ideas?

[Pavel A.]

Posted on November 27, 2017 at 18:25

This question may be more appropriate in the Windows drivers forum,  here:

https://social.msdn.microsoft.com/Forums/en-US/wdk/threads

 

-- pa

[Tesla DeLorean]

Posted on November 27, 2017 at 19:52

Dump out the command request to your diagnostic channel of choice.

LUN would need to be managed in INQUIRY, READ, WRITE, GET CAPACITY, etc. As I recall embedded in the SCSI command parameters. Been a few years since I built a multi-lun hard drive, but it wasn't difficult, you just need to be thorough.

[Eugene Solo]

Posted on November 27, 2017 at 19:47

I will ask there too, thanks.

But it should be standard option of standard driver, it supports multiple LUNs since Windows 2000 SP3 as I heard.

Im just hoping that someone experienced same problems and PROBABLY solved them somehow

[Eugene Solo]

Posted on November 27, 2017 at 20:12

LUN is one of the key parameters of SCSI commands (its essential part of CDB). And, I guess, I made this mechanics right since it works in Linux and all those LUNs are NOT same, they are different independent 'disks'.

How does it look on Windows (dump in my own format; 1st parameter is LUN, 2nd is EVPD flag, third is page code and last is AllocationLength). What happens when i plug/restart my device:

---

SCSI: Inquiry(0, 0, 0x00, 0x0024)

SCSI: Inquiry(0, 0, 0x00, 0x0024)SCSI: Inquiry(0, 1, 0x80, 0x00FF)

---

Windows asks LUN 0 *twice* for same Vital Product Page 00 and then is asks for page 80 (Unit Serial Number). I've checked this with Wireshark/USBpcap, it shows exactly same requests and responses.

Here is what happens on Linux after i plug/restart my device:

---

SCSI: Inquiry(0, 0, 0x00, 0x0024)

SCSI: Inquiry(1, 0, 0x00, 0x0024)SCSI: Inquiry(2, 0, 0x00, 0x0024)

---

Linux Hosts asking for MaxLun (not shown) and then requests for page 00 for each of reported LUNs, as it should be.

[Eugene Solo]

Posted on December 07, 2017 at 19:35

Ok, since nobody gave me correct answer, not here, not on Microsoft forums, I'm here to report results of my own research.

Problem was (and still is) in Microsoft USB: probably, its only mine misunderstanding, but here what I've found.

On enumeration, Windows host asks for standard descriptors: device, configuration and strings. And when it asks for strings, one of the requests is obviously incorrect (or, as I said, it maybe just my own misunderstanding of correctness): it asks for string descriptor, but requests 2 byte response. Means, device should return only header of requested descriptor (length + type, but not contents). When I saw those requests in my sniffer, I decided that his is some kind of weird bug and wrote a workaround - if host asks for 'no-data' descriptor, send him what he wants.

BUT I WAS TERRIBLY WRONG

Windows wants malformed descriptor? Send her malformed descriptor - but it must 'fail successfully': she wants 2 bytes in response, you send her full-fledged descriptor! And only when i tried this mad idea, after two weeks of hopeless bugchasing, it suddenly went good.

And now im pleased to report that i see all my LUNs in 'My computer', they are working well and i got my ~1MB/s transfer rate with USB Mass storage device on FS port.

[Tesla DeLorean]

Posted on December 07, 2017 at 19:46

Microsoft does things Microsoft's way, and that's the standard...

There's a whole lot of quirky stuff related to MODE SENSE and MODE SELECT and the delivery of MODE PAGE's too

[Eugene Solo]

Posted on December 07, 2017 at 19:58

and there is a bad bug in ST USB Device Library, MSC class, Verify10 function.

It does nothing, thats ok, its just dummy function anyway.

But it does WRONG nothing.

[Grand Joldes]

Posted on February 08, 2018 at 13:47

Can you please include some details regarding all the changes needed in the MSC class code to make multiple LUNs work?

I am fighting the same problem at the moment, and I would really appreciate a solution.

[Eugene Solo]

Posted on February 08, 2018 at 19:47

well, in my case (reminder: i did not used any standard libs from ST or any other vendor, i wanted to explore all this by myself) i've tested device under windows and linux while developing and i've discovered that windows is asking for string descriptor with zero payload length. Linux never asked me for this thingy, so i decided that this is some kind of weird mistake and wrote code that sends back literally zero-length string (means - only header). Windows did not reported any errors in enumeration process, in USB tree viewer i saw every descriptor i have (strings included, but not that 'zero length', ofc) and only one LUN.

But when i tried to ignore payload length field and responded with full string instead of zero-length, problem disappeared. Windows VIOLATES rules of enumeration and you must follow.