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) h1# 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 h1# 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 h1# 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 h1# 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 h1# 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.
Responsible Changed From-To: freebsd-bugs->freebsd-usb Reassign.
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.
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
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.
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.
I've been unable to reproduce this on HEAD running r342879. Can anyone confirm it's still an issue on this version?
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.
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.