Wireshark · Ethereal-users: [Ethereal-users] Bug in IP/TCP checksum ...

["Joshua Nekl" <jnekl@xxxxxxxxxxxxxxxxxxxxx>]

Hello all,

I believe I've found a bug in ethereal, in both the IP and TCP sections
(haven't checked UDP). Origionally, I was trying to determine exactly how
the RFC calculated the checksum:

      "The checksum field is the 16 bit one's complement of the one's
      complement sum of all 16 bit words in the header.  For purposes of
      computing the checksum, the value of the checksum field is zero."
      ~RFC0791

Not being sure if they meant (take the 1's complement first, then add them,
then take the 1's complement again, or add them, then take the 1's
complement...) So, I decided to crunch the numbers and figure out exactly
how they did it.

I've used ethereal for other occasions. I took the data from there and
crunched the numbers. Simply adding, then taking the 1's complement always
came up 1 short. IE: ethereal reported checksum 3789, I kept getting 378A.
Every packet I tried had the same effect, always one short. I checked around
8 packets. Each packet's checksum was 1 short.

Now, if two's complement was involved, I could possibly see a problem.
However, that would be adding one after the complement, not subtracting.
Going the wrong way. Besides, the RFC doesn't mention 2's complement, only
1's complement.

I only tried one TCP segment, however, it came up 2 short ???


I tried this with both the Windoze and the Linux versions of ethereal. Both
did the same thing. One short.


Then, I tried 'tcpdump -x' from the linux command line and crunched the
numbers again by hand. Tried about five packets. All the checksums came out
perfect by adding, then complmenting. Not one was short.

It seems that ethereal may be modifying the checksum as it does it's
calculations...

Josh