>> My only complaint about sup versus rdist is that sup doesn't appear
>> to CRC the files that it transfers, so if the IP checksum fails,
>> you've got a corrupt file and no way of knowing that it's corrupt.
>> I notice what I think are IP checksum failures (that is, an error
>> isn't detected) on my slip link about every other week or so.

(Good reason to use something other than SLIP, I'd say.  Something that
includes a relatively strong checksum.)

> I thought TCP was designed to guarantee error-free delivery of a
> packet.  Shouldn't TCP cause the packet to be resent if the IP
> checksum is wrong?

There are multiple checksums involved.  There's the IP header checksum,
which covers just the IP header, and there's the TCP checksum, which
covers the TCP header, the data, and fragments of the IP header (see
RFC793).  But both use the same checksum algorithm.

The problem is, the checksum algorithm used is almost ludicrously weak;
it consists of simply treating the data as 16-bit units and adding them
one's-complement (ie, end-around carry).  To pick a simple example, if
0x0000 gets replaced with 0xffff, the checksum will not notice it.  If
the checksum is incorrect, the packet will be dropped (and, presumably,
retransmitted); the problem comes from packets which get corrupted in
ways that don't produce checksum failures.

Of course, no checksum algorithm provides a perfect guarantee against
corrupted packets.  It's just a question of deciding how likely the
checksum is to pass a bad packet, which you can determine only after
characterizing the errors your medium tends to produce.  SLIP does no
checksumming at all, letting the IP and higher-layer checksums do all
the checking, and it seems that at least for the person who wrote the
first text I quoted above, this isn't good enough.  (In contrast, my
serial line IP code uses 32-bit CRCs, and I have no reason to think it
has ever let even a single bad packet through.)

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu