Godbach

之前讨论的时候觉得，数据包的校验和可以为0x0000, 但是不会为0xFFFF.
而今天再看《Linux网络体系结构》第25章，在介绍UDP的checksum的时候，有这样一段内容：

QUOTE:

If the computation results in the checksum zero, the all-1-bit value is transmitted instead, which is equivalent in ones-complement arithmetic. A zero in the checksum field means that the sender has not computed a checksum.

上面的意思感觉应该是如果计算出的校验和为0x0000的话，则发送的时候采用1的补码，发送0xFFFF作为替代。校验和域为0的情况，代表发送方没有计算校验和。

这个意思应该是就算你计算出实际的校验和为0x0000,但数据包中校验和域应该填写的是0xFFFF. 有点糊涂了？

Godbach

UP一下

dreamice

应该是这样的：如果校验和计算结构为0的话，那么会转而传输比特位均为1的一个值：这等价于与1的补码运算。校验和字段如果为0，则表示发送方没有计算检验和。

Godbach

QUOTE:

原帖由 dreamice 于 2008-11-17 18:11 发表
应该是这样的：如果校验和计算结构为0的话，那么会转而传输比特位均为1的一个值：这等价于与1的补码运算。校验和字段如果为0，则表示发送方没有计算检验和。

这个结果0本身应该就是取1的补码的结果了啊，为什么还要转换。难道是RFC的规定？

dreamice

QUOTE:

原帖由 Godbach 于 2008-11-17 18:50 发表


这个结果0本身应该就是取1的补码的结果了啊，为什么还要转换。难道是RFC的规定？

没有看RFC，不知道是不是规定，猜测应该是。

Au_Hank

QUOTE:

原帖由 Godbach 于 2008-11-17 18:50 发表


这个结果0本身应该就是取1的补码的结果了啊，为什么还要转换。难道是RFC的规定？

因为如果传输校验的值如果为0的话，就代表发送方没有做校验----这是一种约定，所以如果计算出来的CRC为0的话，就用其补码来
代替。

Godbach

QUOTE:

原帖由 Au_Hank 于 2008-11-17 20:17 发表


因为如果传输校验的值如果为0的话，就代表发送方没有做校验----这是一种约定，所以如果计算出来的CRC为0的话，就用其补码来
代替。

哦，那就意味着本来在计算校验和的时候就是用了1的补码运算，但是如果这样计算出来的结果为0x0000的话，又要做一下特殊处理，将其作为0xFFFF发送。

因此，当我们接收到一个数据包的校验和为0xFFFF的时候，他实际上应该是0x0000. 对吧？

Godbach

但是看内核代码中并没有明确的看到当计算校验和为0x0000的时候，作为0xFFFF使用。各位能找到具体的代码吗？

Au_Hank

QUOTE:

原帖由 Godbach 于 2008-11-17 20:30 发表
但是看内核代码中并没有明确的看到当计算校验和为0x0000的时候，作为0xFFFF使用。各位能找到具体的代码吗？

应该是在include/asm-x86/checksum_32.h的汇编代码里面，偶现在看不懂汇编了。

qtdszws

参考 v2.4.0
static int udp_getfrag(const void *p, char * to, unsigned int offset, unsigned int fraglen)
{
...
                if (ufh->uh.check == 0)
                        ufh->uh.check = -1;
...
}