brian@wb6rqn.UUCP (Brian Lloyd) (03/31/88)
Rick, you are right, 95% of the time it is a waste to add error
correction to a SLIP link. On the other hand the checksum routines in
TCP and IP are not very robust. They work just fine in the presence of
single bit errors but will fall down in the presence of burst errors. I
am perfectly willing to allow TCP to handle the request for
retransmission of "lost" packets but I do not want to rely on the
checksum routines to ensure that the packets are good. Too much margin
for error.
At Sirius Systems we are adding an option that will allow you to turn on
one of three error handling modes: current SLIP (no error checking),
CRC-CCITT error checking where it discards bad frames, and lastly the
retransmission of bad frames.
I expect that most sites will run in the first mode and the rest will
run in the second mode. We may just ignore the third mode altogether,
especially in light of modems like the trailblazer (which we love too).
Brian Lloyd, President
Sirius Systems, Inc.
(301) 540-2066
{bellcore, syscad, cp1, irs3, n3dmc}!wb6rqn!brian
Share and enjoy!ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins) (04/05/88)
In fact, there is one very nasty error which the IP checksum does not catch. Because carries are added in, a word of 0's is interchangable with a word of 1's. For example: x + 0 = x x + 0xffff = x !!!! This problem has caused us no end of trouble. Early Ungermann Bass ethernet boards for IBM RTPC's had a problem such that a packet would be corrupted AFTER it had passed the ethernet CRC check. However it also passed the IP/UDP checksum test. This caused us many problems with corrupted files and directories. The point is that this type of error may not be that uncommon on async lines. Noise could easily insert nulls. If those nulls were in the place of valid 0xff's you may be in trouble. Drew