http://fixunix.com/tcp-ip/380349-ip-checksum-calculation-question.html
 04-13-2008, 05:29 PM
|
|
Junior Member
|
|
Join Date: Sep 2009
Posts: 0
|
|
 IP
Checksum calculation question
In the following URL
http://www.netfor2.com/checksum.html
The author cites the following for using one's complement
"Probably the most important is that it is endian independent. Little
Endian computers store hex numbers with the LSB last (Intel processors
for example). Big Endian computers
put the LSB first (IBM mainframes
for example). When carry is added to the LSB to form the 1's
complement sum (see the example) it doesn't matter if we add 03 + 01
or 01 + 03. The result is the same."
How woud this be different if someone would use two's complement? I
don't see how a person could get different results.
|
04-13-2008, 11:46 PM
|
|
Junior Member
|
|
Join Date: Sep 2009
Posts: 0
|
|
Re:
IP Checksum calculation question
On Apr 13, 1:29*pm, grocery_stocker wrote:
> In the following URL
>
> http://www.netfor2.com/checksum.html
>
> The author cites the following for using one's complement
>
> "Probably the most important is that it is endian independent.
Little
> Endian computers store hex numbers with the LSB last (Intel
processors
> for example). Big Endian computers put the LSB first (IBM
mainframes
> for example). When carry is added to the LSB to form the 1's
> complement sum (see the example) it doesn't matter if we add 03 +
01
> or 01 + 03. The result is the same."
>
> How woud this be different if someone would use two's complement? I
> don't see how a person could get different results.
You have to read that in the context of RFC 1072, which explains IP
checksums.
As all other discussions about endianness, the word length matters. In
this case, the IP checksum is computed assuming that bytes of the
packets are paired up, to form 16-bit words.
Now normally, if you added up numbers represented as 16-bit words, you
would definitely expect the byte order of those words (numbers) to
matter, right? Just in general, you would not expect that adding up
two 16-bit values such as
AB + CD,
where AB and CD each represent a particular 16-bit number, would be
the same as adding up
BA + DC. Swapping bytes changes the numerical value of the 16-bit word
in potentially huge ways.
And yet, if you use the one's complement sum, the result IS the same,
as long as you use the same byte order in the computed 16-bit sum as
you assumed for each 16-bit word.
Bert
|
04-14-2008, 02:07 AM
|
|
Junior Member
|
|
Join Date: Sep 2009
Posts: 0
|
|
Re:
IP Checksum calculation question
On Apr 13, 4:46*pm, Albert Manfredi wrote:
> On Apr 13, 1:29*pm, grocery_stocker wrote:
>
> > In the following URL
>
> >http://www.netfor2.com/checksum.html
>
> > The author cites the following for using one's complement
>
> > "Probably the most important is that it is endian
independent. Little
> > Endian computers store hex numbers with the LSB last (Intel
processors
> > for example). Big Endian computers put the LSB first (IBM
mainframes
> > for example). When carry is added to the LSB to form the 1's
> > complement sum (see the example) it doesn't matter if we add
03 + 01
> > or 01 + 03. The result is the same."
>
> > How woud this be different if someone would use two's
complement? I
> > don't see how a person could get different results.
>
> You have to read that in the context of RFC 1072, which explains IP
> checksums.
>
> As all other discussions about endianness, the word length
matters. In
> this case, the IP checksum is computed assuming that bytes of the
> packets are paired up, to form 16-bit words.
>
> Now normally, if you added up numbers represented as 16-bit words,
you
> would definitely expect the byte order of those words (numbers) to
> matter, right? Just in general, you would not expect that adding up
> two 16-bit values such as
>
> AB + CD,
>
> where AB and CD each represent a particular 16-bit number, would be
> the same as adding up
>
> BA + DC. Swapping bytes changes the numerical value of the 16-bit
word
> in potentially huge ways.
>
> And yet, if you use the one's complement sum, the result IS the
same,
> as long as you use the same byte order in the computed 16-bit sum
as
> you assumed for each 16-bit word.
>
> Bert
I think I see this. When AB + CD got swapped, I was under the
impression that it was CD + AB, not BA + DC.
|
04-14-2008, 02:22 PM
|
|
Junior Member
|
|
Join Date: Sep 2009
Posts: 0
|
|
Re:
IP Checksum calculation question
On Apr 13, 10:07*pm, grocery_stocker wrote:
> I think I see this. When AB + CD got swapped, I was under the
> impression that it was CD + AB, not BA + DC.
That's not changing the byte order in the 16-bit words. You've swapped
words without changing the byte ordering.
The scheme also works for any word length that's a multiple of 16
bits. So for example, if the machine uses 32-bit numbers, then ABCD +
DEFG could be byte-swapped to DCBA + GFED, and the result would be the
same. Or swapping the order of each two-byte component of each 32-bit
word, such as BADC + EDGF.
Bert
|
04-14-2008, 08:49 PM
|
|
Junior Member
|
|
Join Date: Sep 2009
Posts: 0
|
|
Re:
IP Checksum calculation question
On Sun, 13 Apr 2008 10:29:10 -0700 (PDT), grocery_stocker
wrote:
> In the following URL
>
> http://www.netfor2.com/checksum.html
>
> The author cites the following for using one's complement
>
> "Probably the most important is that it is endian independent.
Little
> Endian computers store hex numbers with the LSB last (Intel
processors
^^^^^^^^^^^
I distrust any text which uses the term "hex number" in this context.
Hexadecimal has nothing to do with it -- they might as well have
written "binary number", "octal number" or "decimal number".
/Jorgen
--
// Jorgen Grahn
\X/ snipabacken.se> R'lyeh wgah'nagl fhtagn! |
|
