[ih] UDP checksums (Was: UDP Length Field?)

Louis Mamakos louie at transsys.com
Wed Dec 2 22:27:09 PST 2020


On Wed, Dec 2, 2020 at 11:22 AM Joseph Touch <touch at strayalpha.com> wrote:

>
> You’d have to take that into account both in the coding and the checking.
> I.e., for UDP on that machine, after a sum computation, if the sum were
> zero you’d have to force it to be -0 when written to the header.
>
> Further, you’d need to adjust your expectations of a successful checksum
> calculation - rather than checking for -0 (per RFC791), you would check for
> 0.
>

The UDP checksum field stores the 1's complement (negative value, logical
NOT of all the bits) of the computed checksum of the UDP payload and
header, with the checksum field set to zero.  So when the UDP datagram is
received, the UDP stack would do a checksum of the entire header, including
the checksum field and payload, the result should be zero -- since the
value in the checksum field is the negative value of the computed checksum
over the header and payload.

So there's no special case - when the transmitter computes the checksum,
even if it turns out to be (positive) zero, when you complement it (get the
negative value) to store it in the header, the correct value is written -
which could be a negative zero (all one bits) if the computed checksum
value was (positive) zero.  This presumes that the 1's complement ALU on
those old mainframes normalize to a positive zero result when doing
addition.

The only special cases here result from simulating 1's complement
arithmetic on 2's complement CPUs.

Louis Mamakos


>
> Joe
>
>
>



More information about the Internet-history mailing list