IPv4_CHECKSUM_01: Ensure that the DUT generates an IPv4 Packet with a valid Header Checksum
这条case在TC8 2.0已标记为弃用，在3.0已删除，同时在Note那一栏也说明了为什么弃用，因为和IPv4_CHECKSUM_05这条case重复了
目的
“
确保DUT生成的IP数据报的IP首部里的Checksum字段是有效的
”
IP首部里的校验和计算的是首部，不校验数据部分，采用简单的计算方法，也就是反码求和法，具体如何计算，请看我以前的文章
测试步骤
“
Tester：发送一条ICMPv4 Echo Request DUT：发送一条ICMPv4 Echo Reply，包含有效的Checksum字段 ”
期望结果
“
2, DUT：发送的IP数据报IP首部里的Checksum字段有效
”
CANoe TC8
由于此case在2.0版本就已经被弃用，CANoe TC8 demo里也没有实际的执行用例
但是大概的思路我们应该了解，tester发送一条icmp echo request，接收dut发送的icmp echo reply并检查IP首部里的checksum是否正确
参考
Derived from RFC791 section 3.1, RFC1122 section 3.2.1.2
IP首部和ICMP首部里的校验和计算方法，之前的文章已经介绍的足够详细了，这里不再介绍
但是我在RFC791里找到这样一句话
“
This is a simple to compute checksum and experimental evidence indicates it is adequate, but it is provisional and may be replaced by a CRC procedure, depending on further experience.
”
“
大概意思是这种简单计算目前来说是能够达到目的，但它是临时的，以后可能会被CRC校验取代
”
而在RFC1122中
“
A host MUST verify the IP header checksum on every received datagram and silently discard every datagram that has a bad checksum.
”
“
主机必须验证每一个接收到的数据报的IP首部里的Checksum字段，并且要安静地丢弃错误的校验和的数据报
”
IPv4_CHECKSUM_02: IP Checksum method validation on receiving
目的
“
如果IP首部校验和失败，主机会立即丢弃此IP数据报
”
主机网络层接收到IP数据报后，会对IP首部进行校验和计算，如果得到的结果为0，则表示Checksum字段正确，IP首部字段正确，如果不为0，则表明IP首部里的数据有错误，会丢弃这条IP数据报
测试步骤
“
Tester：发送一条ICMPv4 Echo Request报文，其中IP首部里Checksum字段是无效值 DUT；不发送ICMPv4 Echo Reply ”
期望结果
“
2, DUT安静地丢弃IP数据报
”
3.0版本中这里的描述会更简单明了，“DUT；不发送ICMPv4 Echo Reply”
CANoe TC8
CANoe在发送这条报文时也解析出校验和错误的问题了
参考
Derived from RFC791 section 3.1, RFC1122 section 3.2.1.2
在RFC1122中
“
A host MUST verify the IP header checksum on every received datagram and silently discard every datagram that has a bad checksum.
”
“
主机必须验证每一个接收到的数据报的IP首部里的Checksum字段，并且要安静地丢弃错误的校验和的数据报
”
IPv4_CHECKSUM_04: IP Checksum method validation on sending
这条case在TC8 3.0版本中已被删除，为什么被删除，因为和下面的IPv4_CHECKSUM_05那条case重复了
目的
“
验证DUT发送的IP数据报中IP首部的Checksum字段采用了简单计算方法-反码求和法
”
测试步骤
“
Tester：让DUT发送一条IP报文 Tester：监听在网卡上 DUT：发送一条报文 Tester：验证IP首部里的Checksum字段采用了反码求和法 ”
期望结果
“
3, DUT：发送一条报文
4, Tester：验证IP首部里的Checksum字段采用了反码求和法”
CANoe TC8
参考
Derived from RFC 791 s3.1 p14 Internet Header Format (MUST)
DUT主机支持反码求和计算校验和，没什么可讲的，上面已经说过了
IPv4_CHECKSUM_05: IP Checksum method validation
目的
“
验证DUT发送的IP数据报中IP首部的Checksum字段采用了简单计算方法-反码求和法
”
怎么验证，Tester把接收到的IP数据报里的IP首部里的所有数据做16位补码和，结果如果为0，则说明正确
测试步骤
“
Tester：发送一条ICMPv4 Echo Request Tester：监听在网卡上 DUT：发送ICMPv4 Echo Reply Tester：验证接收到的ICMP Echo Reply报文里IP首部里的Checksum字段采用反码求和法 ”
期望结果
“
3, DUT：发送ICMPv4 Echo Reply
4, Tester：验证接收到的ICMP Echo Reply报文里IP首部里的Checksum字段采用反码求和法”
CANoe TC8
参考
Derived from RFC 791 s3.1 p14 Internet Header Format (MUST)
“
The checksum algorithm is:
“
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.
”
”
“
此校验和计算方法为：校验和字段是报头中所有16位bit的补码和的16位反码。为了计算校验和，校验和字段的值需要设置为零
”
原文始发于微信公众号（汽车网络诊断通信）：TC8：IPv4_CHECKSUM_01-05
