Bug 91896 - camcontrol(8): Serial Number of USB Memory Sticks is not passed through to "camcontrol inquiry" command
Summary: camcontrol(8): Serial Number of USB Memory Sticks is not passed through to "c...
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: usb (show other bugs)
Version: CURRENT
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-usb (Nobody)
Depends on:
Reported: 2006-01-17 03:10 UTC by Simson L. Garfinkel
Modified: 2019-01-15 20:39 UTC (History)
2 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Simson L. Garfinkel 2006-01-17 03:10:07 UTC
The "camcontrol inquiry" command reports the serial number of some USB
and FIrewire-attached devices, but not others.  I need these serial
numbers for work that I do in computer forensics.

For example, my computer has 3 firewire drives on it now and 1 USB memory
sticks. The firewire drives are Maxtor OneTouch II drives. Here is a devlist:

h1# camcontrol devlist
<Maxtor OneTouch II 0310>          at scbus0 target 0 lun 0 (da0,pass0)
<Maxtor OneTouch II 0310>          at scbus0 target 1 lun 0 (da1,pass1)
<Maxtor OneTouch II 0310>          at scbus0 target 2 lun 0 (da2,pass2)
<SONY SDX-300C 0404>               at scbus1 target 0 lun 0 (sa0,pass3)
<SanDisk Cruzer Mini 0.1>          at scbus2 target 0 lun 0 (pass4,da3)

I can get the SN of the OneTouch drives:

h1# camcontrol inquiry 0:0:0
pass0: <Maxtor OneTouch II 0310> Fixed Direct Access SCSI-4 device 
pass0: Serial Number B6202SQH
pass0: 50.000MB/s transfers , Tagged Queueing Enabled

But I can't get the SN of the Cruzer:

h1# camcontrol inquiry 2:0:0
pass4: <SanDisk Cruzer Mini 0.1> Removable Direct Access SCSI-2 device 
pass4: Serial Number 
pass4: 1.000MB/s transfers 

It's worse than it looks; the serial number is actually being reported as control-underbar:

h1# camcontrol inquiry 2:0:0 | cat -v
pass4: <SanDisk Cruzer Mini 0.1> Removable Direct Access SCSI-2 device 
pass4: Serial Number ^_
pass4: 1.000MB/s transfers 

So that's probably a bug in the kernel somewhere. 

Notice that I can get the serial number using the sysctl command:

h1# sysctl -a | grep dev.umass.0
dev.umass.0.%desc: SanDisk Corporation Cruzer Mini, rev 2.00/0.10, addr 2
dev.umass.0.%driver: umass
dev.umass.0.%location: port=1 interface=0
dev.umass.0.%pnpinfo: vendor=0x0781 product=0x5150 devclass=0x00 devsubclass=0x00 sernum="SNDK8CB7743691708407" intclass=0x08 intsubclass=0x06
dev.umass.0.%parent: uhub0

Unfortunately, I can't figure out how to map from /dev/da3 to dev.umass.0.
There's no obvious way that I have found. 

If you could tell me how to do that, that would be neat.  In the meantime,
this bug should probably be fixed.

How-To-Repeat: Attach a memory stick and type "camcontrol devlist", then do an "camcontrol
inquiry" on the device. You won't see its SN.
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2006-01-18 17:14:17 UTC
Responsible Changed
From-To: freebsd-bugs->freebsd-usb

Comment 2 Bruce Cran freebsd_committer 2010-10-11 16:17:04 UTC
State Changed
From-To: open->feedback

Is this still a problem on newer versions of FreeBSD? 
I think this may be a problem with the umass driver in the 'old' USB stack, in 
which case the bug will still be present in 7.x.
Comment 3 Eitan Adler freebsd_committer freebsd_triage 2017-12-31 07:59:09 UTC
For bugs matching the following criteria:

Status: In Progress Changed: (is less than) 2014-06-01

Reset to default assignee and clear in-progress tags.

Mail being skipped
Comment 4 Warner Losh freebsd_committer 2019-01-08 20:16:45 UTC
This is still a problem with -current as of
FreeBSD rebo 13.0-CURRENT FreeBSD 13.0-CURRENT=e46cfe69812(master) IOSCHED  amd64
(which is svn r342237, unmodified -- the hash is from my git svn tree)

We report it in dmesg, but not in camcontrol. The output is nothing for some reason.
Comment 5 Steven Hartland freebsd_committer 2019-01-08 20:43:58 UTC
The code which handles this seems relatively simple, I'll see if I can find a drive which is effected by this to have a look.
Comment 6 Steven Hartland freebsd_committer 2019-01-14 17:41:53 UTC
I've been unable to reproduce this on HEAD running r342879.

Can anyone confirm it's still an issue on this version?
Comment 7 Warner Losh freebsd_committer 2019-01-15 00:22:22 UTC
I reproduced it with a kernel based on December 19th kernel. It only happens on some USB sticks. I didn't dig into which kinds or why some would see it and others wouldn't.
 I can try again with a r342973 kernel later today if that will help.
Comment 8 Steven Hartland freebsd_committer 2019-01-15 20:39:42 UTC
If you could that would be great, my current guess is there's something in the serials them selves which makes is look like its not there, possibly a null or something.

If you can still reproduce, details of models which do and hexdump of the output might help identify the issue.

I've tried about 10 different types of USB sticks and no joy my end.