2 Feb
2022
2 Feb
'22
3:26 p.m.
On Feb 2, 2022, at 7:00 AM, R. Voorhorst
<R.Voorhorst(a)swabhawat.com> wrote:
@Johhny:
Funny that is, I only see KG11 involvement in the traces in the Xmit header parts, not in
any Rcv header parts for the data packets, so it seems (for the Dup11 at least) complete
receive packet is checked in Dup11.
.
An interesting math detail is at work here. DDCMP defines the CRCs as covering header and
data respectively. But the CRC used has an initial value of zero and a final value also
of zero -- in other words, if you run both data and associated CRC through the CRC logic,
the result at that point is zero.
A lot of other CRCs don't work that way. In many of them the initial value is all
ones, and the final value is constant but a random-looking pattern. CRC-32 is an example
(the Ethernet CRC). I don't know enough math to say whether this is true if and only
if the initial value is non-zero.
So with the DDCMP CRC-16 behaving the way it does, you can handle the data CRC either by
operating on just the data field, or on the whole packet including both header and header
CRC; the answer is the same either way. This allows the DUP-11 to offload CRC generation
and checking without needing to know anything about DDCMP headers.
paul