ip: explain why we don't worry about ip_checksum_tvb() returning 0xFFFF.

Change-Id: I0040fedc743759eed604a6a0464d59de5c5261a2
Reviewed-on: https://code.wireshark.org/review/37426
Reviewed-by: Guy Harris <gharris@sonic.net>
This commit is contained in:
Guy Harris 2020-06-09 21:54:37 -07:00
parent a6f37c5a35
commit 05b2804cb4
1 changed files with 25 additions and 0 deletions

View File

@ -2056,6 +2056,31 @@ dissect_ip_v4(tvbuff_t *tvb, packet_info *pinfo, proto_tree *parent_tree, void*
ipsum = ip_checksum_tvb(tvb, offset, hlen);
item = proto_tree_add_checksum(ip_tree, tvb, offset + 10, hf_ip_checksum, hf_ip_checksum_status, &ei_ip_checksum_bad, pinfo, ipsum,
ENC_BIG_ENDIAN, PROTO_CHECKSUM_VERIFY|PROTO_CHECKSUM_IN_CKSUM);
/*
* ip_checksum_tvb() should never return 0xFFFF here, because, to
* quote RFC 1624 section 3 "Discussion":
*
* In one's complement, there are two representations of
* zero: the all zero and the all one bit values, often
* referred to as +0 and -0. One's complement addition
* of non-zero inputs can produce -0 as a result, but
* never +0. Since there is guaranteed to be at least
* one non-zero field in the IP header, and the checksum
* field in the protocol header is the complement of the
* sum, the checksum field can never contain ~(+0), which
* is -0 (0xFFFF). It can, however, contain ~(-0), which
* is +0 (0x0000).
*
* ip_checksum_tvb() checksums the IPv4 header, where the "version"
* field is 4, ensuring that, in a valid IPv4 header, there is at
* least one non-zero field. We've already verified that the
* version is 4.
*
* ip_checksum_tvb() returns the negation of the one's-complement
* sum of all the data handed to it, and that data won't be
* all zero, so the sum won't be 0 (+0), and thus the negation
* won't be -0, i.e. won't be 0xFFFF.
*/
if (ipsum == 0) {
/* XXX - Keeping hf_ip_checksum_calculated field for now. Doesn't fit into the
proto_tree_add_checksum design, but IP is a popular enough dissector that somebody