USB2 Link USB-SCSI converter and LUNs

USB2 Link USB-SCSI converter and LUNs

[mark_k]

Hi,

I have a Core Micro Systems USB2 Link USB-SCSI converter (07B4:0380).

Adding an entry to unusual_devs.h should get it to work, just needing
USB_PR_BULK. That should at least allow the connected device with SCSI ID 0
to be accessed.

However in order to access multiple targets and LUNs, the USB2 Link uses
byte 13 of the command block wrapper in a special way.

Normally CBW byte 13 has bCBWLUN in bits [3:0] with bits [7:4] reserved.
The USB2 Link expects the target ID in bits [3:0] and LUN in bits [7:4].
The advantage of that is, it should be possible to access multiple targets
without needing to modify the USB mass storage driver. (It returns 0x06 to
a Get Max LUN request since its SCSI ID is hard-coded to 7.)

Being able to access non-zero actual LUNs would of course require changes
to the driver.

I'm just wondering, how does the usb-storage driver handle these cases:

 - (What it thinks are) LUNs are not contiguous. Suppose the user has two
   SCSI devices in the chain, one with ID 0 the other with ID 3. Would it
   scan LUNs (which map to separate targets) 1, 2, 4, 5 and 6? Or would it
   give up on getting no response from LUN 1?

 - "LUN" 0 is not present. E.g. where the connected SCSI devices have IDs 1
   and 3.

 - When different "LUNs" are completely different devices (e.g. one a
   CD-ROM, another a hard disk, another a tape drive).

Re: USB2 Link USB-SCSI converter and LUNs

[Greg KH]

On Tue, Oct 19, 2021 at 12:15:09PM +0200, mark_k@iname.com wrote:
> Hi,
> 
> I have a Core Micro Systems USB2 Link USB-SCSI converter (07B4:0380).
> 
> Adding an entry to unusual_devs.h should get it to work, just needing
> USB_PR_BULK. That should at least allow the connected device with SCSI ID 0
> to be accessed.

Why do you need any quirk at all for this?

> However in order to access multiple targets and LUNs, the USB2 Link uses
> byte 13 of the command block wrapper in a special way.
> 
> Normally CBW byte 13 has bCBWLUN in bits [3:0] with bits [7:4] reserved.
> The USB2 Link expects the target ID in bits [3:0] and LUN in bits [7:4].
> The advantage of that is, it should be possible to access multiple targets
> without needing to modify the USB mass storage driver. (It returns 0x06 to
> a Get Max LUN request since its SCSI ID is hard-coded to 7.)
> 
> Being able to access non-zero actual LUNs would of course require changes
> to the driver.
> 
> I'm just wondering, how does the usb-storage driver handle these cases:
> 
>  - (What it thinks are) LUNs are not contiguous. Suppose the user has two
>    SCSI devices in the chain, one with ID 0 the other with ID 3. Would it
>    scan LUNs (which map to separate targets) 1, 2, 4, 5 and 6? Or would it
>    give up on getting no response from LUN 1?
> 
>  - "LUN" 0 is not present. E.g. where the connected SCSI devices have IDs 1
>    and 3.
> 
>  - When different "LUNs" are completely different devices (e.g. one a
>    CD-ROM, another a hard disk, another a tape drive).
> 

That should all be up to the scsi layer in the kernel.  If this device
is not following the standard, how is it supposed to work at all?

Does it require custom drivers for other operating systems?

thanks,

greg k-h

Re: USB2 Link USB-SCSI converter and LUNs

[mark_k]

On Tuesday, October 19, 2021 at 12:18 PM "Greg KH" <gregkh@linuxfoundation.org> wrote:
> On Tue, Oct 19, 2021 at 12:15:09PM +0200, mark_k@iname.com wrote:
> > I have a Core Micro Systems USB2 Link USB-SCSI converter (07B4:0380).
> >
> > Adding an entry to unusual_devs.h should get it to work, just needing
> > USB_PR_BULK. That should at least allow the connected device with SCSI ID 0
> > to be accessed.
>
> Why do you need any quirk at all for this?

My mistake, sorry. Its interface descriptor has
  bInterfaceClass 0xFF
  bInterfaceSubClass 0x06
  bInterfaceProtocol 0x50
so an entry with USB_SC_DEVICE, USB_PR_DEVICE would work.


> > I'm just wondering, how does the usb-storage driver handle these cases:
> >
> >  - (What it thinks are) LUNs are not contiguous. Suppose the user has two
> >    SCSI devices in the chain, one with ID 0 the other with ID 3. Would it
> >    scan LUNs (which map to separate targets) 1, 2, 4, 5 and 6? Or would it
> >    give up on getting no response from LUN 1?
> >
> >  - "LUN" 0 is not present. E.g. where the connected SCSI devices have IDs 1
> >    and 3.
> >
> >  - When different "LUNs" are completely different devices (e.g. one a
> >    CD-ROM, another a hard disk, another a tape drive).
> >
>
> That should all be up to the scsi layer in the kernel.  If this device
> is not following the standard, how is it supposed to work at all?
>
> Does it require custom drivers for other operating systems?

My guess is that (with quirk entry) it will work when there is a SCSI
device with ID 0. If all other devices in the chain have contiguous IDs
they could be accessible too.

I can tell Windows to use its built-in mass storage driver and that works
to access the device with ID 0 only. I haven't yet checked with more than
one SCSI device in the chain.

It could/should be possible to properly support multiple targets and LUNs
by using a similar method to the SCM USB-SCSI converters. (Those, after a
special intitialisation request, take the target ID from the *upper* 4 bits
of CBW byte 13.)

But I figure an initial patch to add a quirk entry will be much easier. And
in practice would be enough for most use cases.

Re: USB2 Link USB-SCSI converter and LUNs

[Greg KH]

On Tue, Oct 19, 2021 at 02:53:29PM +0200, mark_k@iname.com wrote:
> On Tuesday, October 19, 2021 at 12:18 PM "Greg KH" <gregkh@linuxfoundation.org> wrote:
> > On Tue, Oct 19, 2021 at 12:15:09PM +0200, mark_k@iname.com wrote:
> > > I have a Core Micro Systems USB2 Link USB-SCSI converter (07B4:0380).
> > >
> > > Adding an entry to unusual_devs.h should get it to work, just needing
> > > USB_PR_BULK. That should at least allow the connected device with SCSI ID 0
> > > to be accessed.
> >
> > Why do you need any quirk at all for this?
> 
> My mistake, sorry. Its interface descriptor has
>   bInterfaceClass 0xFF
>   bInterfaceSubClass 0x06
>   bInterfaceProtocol 0x50
> so an entry with USB_SC_DEVICE, USB_PR_DEVICE would work.

Again, why is a quirk needed at all?

> > > I'm just wondering, how does the usb-storage driver handle these cases:
> > >
> > >  - (What it thinks are) LUNs are not contiguous. Suppose the user has two
> > >    SCSI devices in the chain, one with ID 0 the other with ID 3. Would it
> > >    scan LUNs (which map to separate targets) 1, 2, 4, 5 and 6? Or would it
> > >    give up on getting no response from LUN 1?
> > >
> > >  - "LUN" 0 is not present. E.g. where the connected SCSI devices have IDs 1
> > >    and 3.
> > >
> > >  - When different "LUNs" are completely different devices (e.g. one a
> > >    CD-ROM, another a hard disk, another a tape drive).
> > >
> >
> > That should all be up to the scsi layer in the kernel.  If this device
> > is not following the standard, how is it supposed to work at all?
> >
> > Does it require custom drivers for other operating systems?
> 
> My guess is that (with quirk entry) it will work when there is a SCSI
> device with ID 0. If all other devices in the chain have contiguous IDs
> they could be accessible too.
> 
> I can tell Windows to use its built-in mass storage driver and that works
> to access the device with ID 0 only. I haven't yet checked with more than
> one SCSI device in the chain.

Does this work properly with Linux in this way with no quirk as well?

And how do you know that the device will work with additional scsi
devices?

> It could/should be possible to properly support multiple targets and LUNs
> by using a similar method to the SCM USB-SCSI converters. (Those, after a
> special intitialisation request, take the target ID from the *upper* 4 bits
> of CBW byte 13.)

Are you sure this device actually supports this?  If so, what operating
system does it work on?

thanks,

greg k-h

Re: USB2 Link USB-SCSI converter and LUNs

[Alan Stern]

On Tue, Oct 19, 2021 at 12:15:09PM +0200, mark_k@iname.com wrote:
> Hi,
> 
> I have a Core Micro Systems USB2 Link USB-SCSI converter (07B4:0380).
> 
> Adding an entry to unusual_devs.h should get it to work, just needing
> USB_PR_BULK. That should at least allow the connected device with SCSI ID 0
> to be accessed.
> 
> However in order to access multiple targets and LUNs, the USB2 Link uses
> byte 13 of the command block wrapper in a special way.
> 
> Normally CBW byte 13 has bCBWLUN in bits [3:0] with bits [7:4] reserved.
> The USB2 Link expects the target ID in bits [3:0] and LUN in bits [7:4].

Why on earth does it use such a non-standard protocol?  After all, the 
USB mass-storage specifications have been available since 1999 or 
earlier!  And they haven't exactly been kept secret during all that 
time.

> The advantage of that is, it should be possible to access multiple targets
> without needing to modify the USB mass storage driver. (It returns 0x06 to
> a Get Max LUN request since its SCSI ID is hard-coded to 7.)
> 
> Being able to access non-zero actual LUNs would of course require changes
> to the driver.
> 
> I'm just wondering, how does the usb-storage driver handle these cases:
> 
>  - (What it thinks are) LUNs are not contiguous. Suppose the user has two
>    SCSI devices in the chain, one with ID 0 the other with ID 3. Would it
>    scan LUNs (which map to separate targets) 1, 2, 4, 5 and 6? Or would it
>    give up on getting no response from LUN 1?

This is not handled by usb-storage at all; it is handled by the SCSI 
core.  My memory of what the SCSI core does is old (so a little 
unreliable) and possibly out of date, but here it is:

The handling of non-contiguous LUNs may depend on which SCSI level the 
device claims to support.  However, in many cases the LUN scan does stop 
when no response is received.

>  - "LUN" 0 is not present. E.g. where the connected SCSI devices have IDs 1
>    and 3.

If there's no LUN 0 then the SCSI layer will give up on the target 
entirely.

>  - When different "LUNs" are completely different devices (e.g. one a
>    CD-ROM, another a hard disk, another a tape drive).

No matter.  Each LUN can have its own individual device type.

Alan Stern

Re: USB2 Link USB-SCSI converter and LUNs

[mark_k]

On Tuesday, October 19, 2021 at 2:01 PM "Greg KH" <gregkh@linuxfoundation.org> wrote:
> On Tue, Oct 19, 2021 at 02:53:29PM +0200, mark_k@iname.com wrote:
> > On Tuesday, October 19, 2021 at 12:18 PM "Greg KH" <gregkh@linuxfoundation.org> wrote:
> > > On Tue, Oct 19, 2021 at 12:15:09PM +0200, mark_k@iname.com wrote:
> > > > I have a Core Micro Systems USB2 Link USB-SCSI converter (07B4:0380).
> > > >
> > > > Adding an entry to unusual_devs.h should get it to work, just needing
> > > > USB_PR_BULK. That should at least allow the connected device with SCSI ID 0
> > > > to be accessed.
> > >
> > > Why do you need any quirk at all for this?
> >
> > My mistake, sorry. Its interface descriptor has
> >   bInterfaceClass 0xFF
> >   bInterfaceSubClass 0x06
> >   bInterfaceProtocol 0x50
> > so an entry with USB_SC_DEVICE, USB_PR_DEVICE would work.
>
> Again, why is a quirk needed at all?

bInterfaceClass = 0xFF (not 0x08 which is the mass storage class number)
so usb-storage does not bind to it automatically.


> > > That should all be up to the scsi layer in the kernel.  If this device
> > > is not following the standard, how is it supposed to work at all?
> > >
> > > Does it require custom drivers for other operating systems?
> >
> > My guess is that (with quirk entry) it will work when there is a SCSI
> > device with ID 0. If all other devices in the chain have contiguous IDs
> > they could be accessible too.
> >
> > I can tell Windows to use its built-in mass storage driver and that works
> > to access the device with ID 0 only. I haven't yet checked with more than
> > one SCSI device in the chain.
>
> Does this work properly with Linux in this way with no quirk as well?
>
> And how do you know that the device will work with additional scsi
> devices?

I rebuilt the usb-storage module after adding an entry for the USB2 Link to
unusual_devs.h.

With one SCSI device set to ID 0, the kernel detected the drive and I could
access it:

[ 2219.761126] usb-storage 2-1:1.0: USB Mass Storage device detected
[ 2219.762033] scsi host5: usb-storage 2-1:1.0
[ 2219.762163] usbcore: registered new interface driver usb-storage
[ 2220.769695] scsi 5:0:0:0: Optical Device    HP       C1113M           1.19 PQ: 0 ANSI: 2
[ 2221.156254] usb 2-1: reset high-speed USB device number 5 using ehci-pci
[ 2221.712223] usb 2-1: reset high-speed USB device number 5 using ehci-pci
[ 2222.268262] usb 2-1: reset high-speed USB device number 5 using ehci-pci
[ 2222.824239] usb 2-1: reset high-speed USB device number 5 using ehci-pci
[ 2222.981475] sd 5:0:0:0: Attached scsi generic sg2 type 7
[ 2222.987240] sd 5:0:0:0: [sdb] Attached SCSI removable disk


Note the extra "reset high-speed..." lines, probably due to the kernel
trying to access LUNs 1 to 5 (which the USB2 Link maps to accesses to non-
existent SCSI targets 1-5). Is that harmless?
[As mentioned before, the USB2 Link reports its Max LUN as 6.]


> > It could/should be possible to properly support multiple targets and LUNs
> > by using a similar method to the SCM USB-SCSI converters. (Those, after a
> > special intitialisation request, take the target ID from the *upper* 4 bits
> > of CBW byte 13.)
>
> Are you sure this device actually supports this?  If so, what operating
> system does it work on?

It does definitely support that. I installed the manufacturer driver on
(32-bit) Windows and looked at USBpcap captures. I also disassembled the
driver.

Do you think it would be worthwhile submitting a patch adding the USB2
Link to unusual-devs.h? If those reset... lines aren't acceptable I could
add US_FL_SINGLE_LUN, but that would only allow it to work with a single
SCSI device (set to ID 0).

Or should I try and get proper/full support (multiple targets and LUNs)
working first?

Re: USB2 Link USB-SCSI converter and LUNs

[mark_k]

On Tuesday, October 19, 2021 at 3:32 PM "Alan Stern" <stern@rowland.harvard.edu> wrote:
> On Tue, Oct 19, 2021 at 12:15:09PM +0200, mark_k@iname.com wrote:
> > I have a Core Micro Systems USB2 Link USB-SCSI converter (07B4:0380).
> > ...
> > However in order to access multiple targets and LUNs, the USB2 Link uses
> > byte 13 of the command block wrapper in a special way.
> >
> > Normally CBW byte 13 has bCBWLUN in bits [3:0] with bits [7:4] reserved.
> > The USB2 Link expects the target ID in bits [3:0] and LUN in bits [7:4].
>
> Why on earth does it use such a non-standard protocol?  After all, the
> USB mass-storage specifications have been available since 1999 or
> earlier!  And they haven't exactly been kept secret during all that
> time.

The bulk only transport doesn't have any way to access multiple targets.
In theory mapping the LUN number in the CBW to a target ID could allow an
unmodified driver to access multiple targets, as long as their IDs are
contiguous from 0. (At the cost of not being able to access non-zero LUNs
but most devices only have one LUN.)

Maybe that didn't work out as compatible as the manufacturer hoped so
they set bInterfaceClass to 0xFF not 0x08. Or maybe that was just done to
prevent Windows automatically loading its built-in mass storage driver,
so the vendor driver could be installed instead.

Re: USB2 Link USB-SCSI converter and LUNs

[Alan Stern]

On Tue, Oct 19, 2021 at 06:37:57PM +0200, mark_k@iname.com wrote:
> I rebuilt the usb-storage module after adding an entry for the USB2 Link to
> unusual_devs.h.
> 
> With one SCSI device set to ID 0, the kernel detected the drive and I could
> access it:
> 
> [ 2219.761126] usb-storage 2-1:1.0: USB Mass Storage device detected
> [ 2219.762033] scsi host5: usb-storage 2-1:1.0
> [ 2219.762163] usbcore: registered new interface driver usb-storage
> [ 2220.769695] scsi 5:0:0:0: Optical Device    HP       C1113M           1.19 PQ: 0 ANSI: 2
> [ 2221.156254] usb 2-1: reset high-speed USB device number 5 using ehci-pci
> [ 2221.712223] usb 2-1: reset high-speed USB device number 5 using ehci-pci
> [ 2222.268262] usb 2-1: reset high-speed USB device number 5 using ehci-pci
> [ 2222.824239] usb 2-1: reset high-speed USB device number 5 using ehci-pci
> [ 2222.981475] sd 5:0:0:0: Attached scsi generic sg2 type 7
> [ 2222.987240] sd 5:0:0:0: [sdb] Attached SCSI removable disk
> 
> 
> Note the extra "reset high-speed..." lines, probably due to the kernel
> trying to access LUNs 1 to 5 (which the USB2 Link maps to accesses to non-
> existent SCSI targets 1-5). Is that harmless?

To really find out what's going on, you should collect a usbmon trace 
showing what happens when the device is plugged in.

> [As mentioned before, the USB2 Link reports its Max LUN as 6.]
> 
> 
> > > It could/should be possible to properly support multiple targets and LUNs
> > > by using a similar method to the SCM USB-SCSI converters. (Those, after a
> > > special intitialisation request, take the target ID from the *upper* 4 bits
> > > of CBW byte 13.)
> >
> > Are you sure this device actually supports this?  If so, what operating
> > system does it work on?
> 
> It does definitely support that. I installed the manufacturer driver on
> (32-bit) Windows and looked at USBpcap captures. I also disassembled the
> driver.
> 
> Do you think it would be worthwhile submitting a patch adding the USB2
> Link to unusual-devs.h? If those reset... lines aren't acceptable I could
> add US_FL_SINGLE_LUN, but that would only allow it to work with a single
> SCSI device (set to ID 0).
> 
> Or should I try and get proper/full support (multiple targets and LUNs)
> working first?

Either approach would be acceptable.  If you do implement the 
full-support approach, you should imitate the scheme used for the 
US_FL_SCM_MULT_TARG flag.  But you may find it's not worth the trouble.  
After all, how often will people want to chain together more than seven 
devices to one of these things?

Alan Stern