jeh@dcs.simpact.com (09/10/90)
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> <DLE><k><c0><c1><C><x> Chesson> The <DLE> symbol denotes the ASCII ctrl/P character. If the Chesson> envelope is to be followed by a data segment, <k> 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 <c0> and <c1> 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 <x> byte is the exclusive-or of <k><c0><c1><C>. 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 <c0><c1>. 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