USB drive serial numbers

[Sean Bruno]

Scott Long wrote:
> Sean Bruno wrote:
>> Scott Long wrote:
>>> Sean Bruno wrote:
>>>> Can someone send me the output of "camcontrol inquiry daX" where 
>>>> daX is a usb attached hard drive?  I'm interested to know if the 
>>>> USB external hard drives report a serial number as the USB flash 
>>>> drives I currently have in my possession do not report one.
>>>>
>>>> eg:  SCSI hard drive:
>>>> sudo camcontrol inquiry da0
>>>> pass0: <SEAGATE ST373207LC D701> Fixed Direct Access SCSI-3 device
>>>> pass0: Serial Number 3KT17YJL
>>>> pass0: 320.000MB/s transfers (160.000MHz, offset 63, 16bit), Tagged 
>>>> Queueing Enabled
>>>>
>>>>
>>>> eg: USB flash drive:
>>>> sudo camcontrol inquiry da3
>>>> pass4: <TOSHIBA TransMemory 5.00> Removable Direct Access SCSI-0 
>>>> device
>>>> pass4: Serial Number
>>>> pass4: 40.000MB/s transfers
>>>>
>>>
>>> CAM used to assume that all DA devices supported the serial number EVPD
>>> page.  I recently changed it to query the device for the list of pages
>>> it does support, and only ask for the serial number page if it does
>>> (which in turns cuts down on a whole lot of kernel printf noise).  My
>>> experience is that some devices do, but most devices don't.  If you 
>>> want
>>> to check your devices manually, do:
>>>
>>> camcontrol cmd pass0 -v -c "12 01 00 00 255 00" -i 255 "-" | hd
>>>
>>> If 0x80 appears after the 4th byte, the device claims support for
>>> querying the serial number.  The serial number can then be fetched with
>>>
>>> camcontrol cmd pass0 -v -c "12 01 80 00 255 00" -i 255 "-" | hd
>>>
>>> Or via
>>>
>>> camcontrol inq pass0 -S
>>>
>>>
>>> Scott
>>
>> Hrm....it looks like asking for page 0x80 directly is returning the same
>> as requesting page 0x80 or asking for all pages:
>>
>> sudo camcontrol devlist
>> <SEAGATE ST373207LC D701>          at scbus0 target 0 lun 0 (da0,pass0)
>> <SEAGATE ST373207LC 0003>          at scbus0 target 1 lun 0 (da1,pass1)
>> <PE/PV 1x2 SCSI BP 1.0>            at scbus0 target 6 lun 0 (ses0,pass2)
>> <Rorke GalaxyHD 342D>              at scbus1 target 1 lun 0 (da2,pass3)
>> <TOSHIBA TransMemory 5.00>         at scbus2 target 0 lun 0 (pass4,da3)
>>
>> sudo camcontrol cmd pass4 -v -c "12 01 00 00 255 00" -i 255 "-" | hd
>> 00000000  00 80 00 01 1f 00 00 00  54 4f 53 48 49 42 41 20  
>> |........TOSHIBA |
>> 00000010  54 72 61 6e 73 4d 65 6d  6f 72 79 20 20 20 20 20  
>> |TransMemory     |
>> 00000020  35 2e 30 30 50 4d 41 50  31 32 33 34 00 00 00 00  
>> |5.00PMAP1234....|
>> 00000030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  
>> |................|
>> *
>> 000000f0
>>
>> sudo camcontrol cmd pass4 -v -c "12 01 80 00 255 00" -i 255 "-" | hd
>> 00000000  00 80 00 01 1f 00 00 00  54 4f 53 48 49 42 41 20  
>> |........TOSHIBA |
>> 00000010  54 72 61 6e 73 4d 65 6d  6f 72 79 20 20 20 20 20  
>> |TransMemory     |
>> 00000020  35 2e 30 30 50 4d 41 50  31 32 33 34 00 00 00 00  
>> |5.00PMAP1234....|
>> 00000030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  
>> |................|
>> *
>
> Wow, that's just fantastically broken.  It's completely ignoring the
> EVPD bit in the request and simply reporting standard inq data.  I
> guess the only thing that keeps CAM from exploding on this is that it
> sees the length field in byte 4 as 0x01, so it doesn't search too far
> into what it thinks is the response.  I'll have to read the spec some
> more to see if there's a standard way to report that the device supports
> the EVPD bit that FreeBSD should be checking.
>
> Scott
Any chance you have a USB hard drive lying around that you could run a 
"camcontrol inq"?

Sean