Path: utzoo!attcan!utgpu!watserv1!watmath!att!pacbell!pacbell.com!ucsd!nosc!crash!simpact!jeh
From: jeh@dcs.simpact.com
Newsgroups: comp.mail.uucp
Subject: 
Message-ID: <1604.26ea5380@dcs.simpact.com>
Date: 9 Sep 90 21:36:48 GMT
References: <1990Sep6.120027.15972@sun.soe.clarkson.edu> <1990Sep7.023857.1974@sun.soe.clarkson.edu>
Organization: Simpact Associates, San Diego CA
Lines: 64

In article <1990Sep7.023857.1974@sun.soe.clarkson.edu>, help@kendra.kew.com 
(Drew Derbyshire - UUPC/extended Help Desk) writes:
> I received within a minutes the old posting of the description of the
> initial handshake description and G.L. Chesson's Bell Labs paper on the
> "g" protocol.  (Thanks Mark!)
> 
> However, in reading it and comparing it to UUCP (and UUPC, which I don't
> trust as much), the initial description of the six byte control packet
> looks wrong (it says the third byte should be the same as fifth byte,
> and the fourth byte should be zero, which is clearly not the case for
> the systems I connect to).  This, alas, makes entire paper suspect.

You must be referring to this section:

Chesson>      A six byte framing envelope is  constructed  using  the
Chesson> control  byte C of a packet and five other bytes as depicted
Chesson> below.
Chesson>           
Chesson> The  symbol denotes the ASCII ctrl/P character.  If the
Chesson> envelope  is  to  be followed by a data segment,  has the
Chesson> value log (size)-4; i.e. 1 <= k <= 8.  If k  is  9,  then  the
Chesson>          2
Chesson> envelope  represents  a  control  packet.  The  and 
Chesson> bytes are the low-order and high-order bytes respectively of
Chesson> 0xAAAA  minus  a 16-bit checksum.  For control packets, this
Chesson> 16-bit checksum is the same as the control byte C.  For data
Chesson> packets,  the  checksum  is calculated by the program below.
Chesson> The  byte is the exclusive-or of  .   Error
Chesson> control  is  accomplished  by  checking  a  received framing
Chesson> envelope for compliance with the definition, and comparing a
Chesson> checksum function of the data segment with .

The description is not quite right, but not for the reason you mention.  
What it is saying is that for data packets

	c1c0 = 0xAAAA - checksum(data segment)

while for control packets

	c1c0 = 0xAAAA - control byte

In other words, for control packets, it is not saying that the c1c0 value is
the same as the control byte.  It is saying that the value that is subtracted
from 0xAAAA is the same as the control byte. 

What IS wrong here is that it doesn't mention that the control byte gets 
into the checksum value, even for data packets.  In fact, for data packets,
the c1c0 value is calculated as follows:

	c1c0 = 0xAAAA - (chksum(buf->data, xlen) ^ (0xFF & buf->cbyte));

where buf is a pointer to the packet (header+data), data is the data field
within, xlen is the physical, transmitted length of the data field (eg 64 bytes
for K=2, even for short data packets, which is to say that the checksum is done
on the entire transmitted or received buffer even for short data packets), and
cbyte is the control byte within the packet header. 

At least, that's how my 'g' code works, and no uucps it talks to have complained
about checksum troubles.  

	--- Jamie Hanrahan, Simpact Associates, San Diego CA
Chair, VMSnet [DECUS uucp] and Internals Working Groups, DECUS VAX Systems SIG 
Internet:  jeh@dcs.simpact.com, or if that fails, jeh@crash.cts.com
Uucp:  ...{crash,scubed,decwrl}!simpact!jeh