On 06.01.2009 00:24, kilgota at banach.math.auburn.edu wrote: > 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: kilgota at 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?
Just from memory (which, I must admit, is not very good) I'd say that 0xc1 is a vendor specific command. Have you had a look at the SCSI drafts at t10.org, especially http://www.t10.org/cgi-bin/ac.pl?t=f&f=s2-r10l.pdf ? Abel
