https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3112
--- Comment #6 from Jaap Keuter <jaap.keuter@xxxxxxxxx> 2008-12-23 06:36:15 PDT ---
(In reply to comment #5)
> That's a case with an odd number of octets, so it'd be padded on the right
> with zeroes, giving 0xfe00. The one's complement of that is 0x01ff, or 511.
...when calculated on a big endian machine.
On a little endian box: ...That's a case with an odd number of octets, so it'd
be padded on the right with zeroes, giving 0xfe 0x00, or 0x00fe. The one's
complement of that is 0xff01, or 65281.
To quote RFC 1071 section 2. (B):
(B) Byte Order Independence
The sum of 16-bit integers can be computed in either byte order.
Thus, if we calculate the swapped sum:
[B,A] +' [D,C] +' ... +' [Z,Y] [4]
the result is the same as [1], except the bytes are swapped in
the sum! To see why this is so, observe that in both orders the
carries are the same: from bit 15 to bit 0 and from bit 7 to bit
8. In other words, consistently swapping bytes simply rotates
the bits within the sum, but does not affect their internal
ordering.
Therefore, the sum may be calculated in exactly the same way
regardless of the byte order ("big-endian" or "little-endian")
of the underlaying hardware. For example, assume a "little-
endian" machine summing data that is stored in memory in network
("big-endian") order. Fetching each 16-bit word will swap
bytes, resulting in the sum [4]; however, storing the result
back into memory will swap the sum back into network byte order.
So it comes down to endianness. What strikes me as odd in the CDP checksum code
is that, first, it accesses the network data in host order for summation:
const unsigned short *d = (const unsigned short *)data;
...
sum += *d++;
then goes on to add in the final byte converting it to network order:
sum += htons(*((unsigned char *)d));
Also, when inserting the CDP packet in the dataset and running the module test
I would expect the CDP checksum code result to be 0 (the CDP packet includes
the checksum 0xdb37). Instead the CDP checksum code results in 0xfffe. Only
when I patch the packets' checksum to 0xda37 the CDP checksum code comes up
with 0. Is the packets' checksum really valid or is there something more to CDP
checksumming?
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
