3

如RFC1071中所述，在奇数字节的情况下计算校验和时，应在最后一个字节中添加一个额外的 0 字节：

在此处输入图像描述

但在“C”代码算法中，只添加了最后一个字节：

在此处输入图像描述

上面的代码确实适用于 [Z,0] 等于 Z 的小端机器，但我认为在 [Z,0] 等于 Z*256 的大端机器上存在一些问题。

所以我想知道 RFC1071 中的示例“C”代码是否仅适用于小端机器？

-------------新添加-------------

RFC1071 中描述了另一个“将总和分成两组”的示例：

在此处输入图像描述

我们可以在这里取数据 (addr[]={0x00, 0x01, 0xf2}) 例如：

在此处输入图像描述

这里，“标准”表示公式[ 2 ]中描述的情况，而“C-code”表示C代码算法的情况。

正如我们所看到的，在“标准”情况下，最终总和为 f201，而不管字节序差异如何，因为“交换”之后的 [Z,0] 的抽象形式没有字节序问题。但它在“C 代码”情况下很重要，因为无论是大端还是小端，f2 始终是低字节。

因此，校验和是可变的，具有不同字节序的相同数据（地址和计数）。

4

2 回答 2

2

I think you're right. The code in the RFC adds the last byte in as low-order, regardless of whether it is on a litte-endian or big-endian machine.

In these examples of code on the web we see they have taken special care with the last byte:

https://github.com/sjaeckel/wireshark/blob/master/epan/in_cksum.c

and in

http://www.opensource.apple.com/source/tcpdump/tcpdump-23/tcpdump/print-ip.c

it does this:

if (nleft == 1)
    sum += htons(*(u_char *)w<<8);

Which means that this text in the RFC is incorrect:

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; however, storing the result back into memory will swap the sum back into network byte order.

于 2012-12-29T11:03:30.937 回答
1

以下代替原始奇字节处理的代码是可移植的（即可以在大端和小端机器上工作），并且不依赖于外部函数：

if (count > 0)
{
    char buf2[2] = {*addr, 0};
    sum += *(unsigned short *)buf2;
}

（假设 addr 是 char * 或 const char *）。

于 2014-08-13T00:42:46.097 回答