protocol details

Hi,

I pondered the protocol data I got hold of from this list and xmd's
proto.txt file.  I will have to produce my own log data to verify some
ideas, however, what Pete Ryland said earlier here was pretty suggestive.
I am ot sure how much of this is already well known, at least as an idea,
however, here are some bits that look interesting to me:

In the request, there is usually some "ff" that is changed in the reply. 
One common pattern is that the ff is followed by some zeroes, and later
becomes 10 00 00 XX with some number XX.  A good example is the get disc
title operation, which has ff 00 00 00 00 00 which becomes
10 00 00 L1 00 00 00 L2 00 0a 00 L3 Title with L3 = len(Title), L2 = L3 + 4,
and L1 = L2 + 2.

Pete Ryland suggested some pattern like "type format length" and a packed
format which nestes such constructs.  This is not too bad for a start.

To unpack it in reverse, you would have the header "000a", followed by the
length "00L3" and the data.  This itself is the data of a packet with the
header "0000" and the length "00L2".  This breaks down at the top level,
with the header "1000" and the length "00L1" because L1 is two bytes short.

However, the request was two bytes longer than "1000 00L1".  So maybe the L1
count is the number of bytes that were appended to the request.  This is
supported by, for example, the disc flags operation, which has:

"ff 00 00 01 00 08" -> "10 00 00 01 00 08 XX" with XX being the flags.
Here only 1 byte is appended, thus the "01".

Of course, there must be more experimentation to verify this, but the data I
have seen seems to support this.

If this is true, then it is suggestive to think of "ff" -> "10" as an
indication that data was appended to the request, and that the amount of
data appended can be found in the two bytes after the next "10 00 XX XX"
(ie, L1 is the word following "10 00").  Indeed, commands that do not append
data to the request convert the "ff" to "00" on reply.

I think it is a bit strange that such commands seem to encode the parameters
after the "ff" instead before it.  This is still unclear to me.

Here is an interpretation of the disc capacity call:

Request:
001806 02101000 30800300 ff000000 0000
Reply:
091806 02101000 30800300 1000001d 0000 001b 8003 0017 8000 0005 00t4t3t2t1
							   0005 00t4t3t2t1
							   0005 00t4t3t2t1

"ff"   ->   "10": Data was appended.
"001d" -> The number of bytes appended (0x1b)
"0000" -> unknown, probably further specifies the type of the reply
"001b" -> The number of bytes of the packet with the reply data.
"8003" -> "80" array (Rylands suggestion) of "03" elements.
"0017" -> The number of the bytes in the array.
"8000" -> Indicates that the array members are following.
          (As every packet must have a header, this serves as one).
"0005" -> Number of bytes of the first entry.
"00t4t3t2t1" -> First array entry.  I suspect that the leading 00 is the
                number of days.

(Similar for second and third entry).

There is still a lot of speculation in the above analysis.  The array format
is mostly made up so that everything "fits in".  However, I can already
imagine how you would implement a parser for such a packed structure, and I
can imagine that the format was carefully designed to allow such a type of
parser to be implemented.  I can not explain the peculiar position of the ff
in the play/stop/etc commands.

I have developed Pete Rylands idea and will test it when I have setup a
sniffer evironment.  Maybe those of you who already dig into this stuff can
watch out for the above or similar patterns, or code it into their log
parser or drivers if it holds any water.

Thanks,
Marcus


-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    [email protected]
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
[email protected]
http://www.marcus-brinkmann.de/