Wishing everyone a prosperous, happy, and peaceful year 2009.
For a lark, I bought a rather worthless but very cheap gadget for myself
for Christmas. It is a very small digital picture frame which one can hang
on the key ring. The little book which came with it says that to use it,
one merely plugs it in on a computer running XP or Vista, and the app is
already installed which will communicate with it. I tried this, and it is
so. With the app, one can view JPEG images on the device, also move images
to/from, and delete what is on the device. Then, the device has a
primitive OS which will allow various things to be done, such as to
display the time instead of a picture. It also gets reported as an
external drive, with the information that it is "full" and AFAIK one
cannot access it directly.
I made one snoop log, which probably does not yet have the serious
information needed to continue with this thing. I spent most of my time
fighting Vista to get the log made.
So much for the background. What it is, is a Mass Storage Bulk Transport
device which comes up as a /dev/sg, not as a /dev/sd. So in other words it
is possible to talk to it with Mass Storage Bulk Transport, but one can
not mount it. In other words, similar to some audio CDs, or to some
scanners. In the forwarded message below, there is some report of the
results of various commands, and also a question at the end, about a
certain SCSI command with which I am not acquainted and can not seem to
find relevant documentation. I hope that someone can help me with the
question.
Theodore Kilgore
---------- Forwarded message ----------
Date: Mon, 5 Jan 2009 12:57:13 -0600 (CST)
From: kilg...@banach.math.auburn.edu
To: Pete Zaitcev <zaitcev at redhat.com>
Cc: usb-storage at lists.one-eyed-alien.net
Subject: Re: [usb-storage] A keychain digital picture frame.
On Thu, 1 Jan 2009, Pete Zaitcev wrote:
> On Thu, 1 Jan 2009 21:34:00 -0600 (CST), kilgota at banach.math.auburn.edu
> wrote:
>
>> I successfully made a snoop log of one photo being moved over to the
>> device. Indeed, it appears to be using Mass Storage Bulk Transport
>> commands.
>
> Try to eject the pseudo-CD on Linux, maybe the device will re-enumerate
> itself then.
>
> -- Pete
>
Well, as I mentioned earlier, the eject did not work. Therefore, I have done a
bit of looking through that log file. I have also gotten a copy of sg3-utils
and played with it a little bit.
One thing seems clear, that the device reports itself as a CD. The sectors are
2048 bytes, and it uses READ_10 to read a sector, or sectors. Lots of fairly
routine stuff. Some selections:
00000000: 55 53 42 43 c8 e6 95 84 08 00 00 00 80 00 0a 25
00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
reports
00000000: 00 01 e7 ff 00 00 08 00 (0x1e7ff sectors of size 0x800)
so I wonder if it has the off-by-one error. It would not make any difference
unless one were going to mount it, I suppose...
I do not know enough about this to understand the response to REQUEST_SENSE
00000000: 55 53 42 43 88 d5 9f 84 12 00 00 00 80 00 0c 03
00000010: 00 00 00 12 00 00 00 00 00 00 00 00 00 00 00
which gets various responses. One of them is
00000000: f0 00 02 00 00 00 00 0b 00 00 00 00 3a 00 00 00
00000010: 00 53
Windows keeps insisting on sending
00000000: 55 53 42 43 28 3e 6e 84 20 00 00 00 80 00 0a 51
00000010: 00 00 00 00 00 00 00 20 00 00 00 00 00 00 00
which makes the device to throw a fit, and a reset is required. I think that
this has something to do with initializing RAID setup?
Now, scsi.h says the following one is READ_TOC:
00000000: 55 53 42 43 88 2b 82 84 0c 00 00 00 80 00 0a 43
00000010: 00 01 00 00 00 00 00 0c 00 00 00 00 00 00 00
I do not understand what the response might be telling me, which is
00000000: 00 0a 01 01 01 14 00 a0 00 00 00 00
though I do vaguely remember that the device claimed to have room for 45
images. The numbers strung out here do add up to that, which might or might not
be significant.
Here is a sample of READ_10
00000000: 55 53 42 43 c8 e6 95 84 00 08 00 00 80 00 0a 28
00000010: 00 00 00 00 19 00 00 01 00 00 00 00 00 00 00
(read one sector at 0x19)
to which the reply begins with
00000000: 5b 41 55 54 4f 52 55 4e 5d 0d 0a 49 43 4f 4e 3d
A u t o r u n i c o O P E
00000010: 41 75 74 6f 72 75 6e 2e 69 63 6f 0d 0a 4f 50 45
00000020: 4e 3d 49 6d 61 67 65 56 69 65 77 65 72 34 2e 65
x e - C O P Y F I L E
00000030: 78 65 20 2d 43 4f 50 59 46 49 4c 45 00 00 00 00
00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000050: 00 00 00 (the rest of the sector is empty)
and then
00000000: 55 53 42 43 08 00 5b 84 38 00 00 00 80 00 0c 12
00000010: 00 00 00 38 00 00 00 00 00 00 00 00 00 00 00
followed by a "reply" (my annotations, which could be partly wrong of course)
05 means CDROM 0x80 means removable medium then 0s means scsi(?) and 02(?)
1f is something about extra length and then
I n s i g n i a
00000000: 05 80 02 02 1f 00 00 00 49 6e 73 69 67 6e 69 61
N S - D K U Y X X 0 9
00000010: 4e 53 2d 44 4b 45 59 58 58 30 39 00 20 20 20 20
t e n x d s k E Y X
00000020: 00 20 20 20 74 65 6e 78 64 73 6b 00 00 45 59 58
X 0 9
00000030: 58 30 39 00 20 20 20 20
But then I got a bit of the way through the log file, and it came up with
00000000: 55 53 42 43 08 00 5b 84 00 80 00 00 80 00 0c c1
00000010: 11 31 0f 30 01 80 00 00 00 00 00 00 00 00 00
to which the reply is a block, and then the command is repeated, apparently
with a different answer, then still a third time (at least).
I cannot find much information about the SCSI command 0xc1. What little I did
find would lead me to believe that, again, it has something to do with a CD.
Does anyone know where to learn more about this, or actually know the
information, to save the trouble of chasing it?
Theodore Kilgore
