IPv4 UDP/TCP Checksum incorrect if routing header present.
This issue was migrated from bug 6561 in our old bug tracker.
Original bug information:
Reporter: Maynard
Status: RESOLVED FIXED
Product: Wireshark
Component: GTK+ UI
OS: All
Platform: All
Version: 1.6.3
Attachments:
bug6561_1.patch: Patch that sets the destination IP address correctly.
bug6561_2.patch: An updated patch.
Activity
Build Information: Version 1.6.3 (SVN Rev 39702 from /trunk-1.6)
Copyright 1998-2011 Gerald Combs <gerald@wireshark.org> and contributors. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Compiled (64-bit) with GTK+ 2.24.5, with GLib 2.29.8, with libpcap 1.0.0, with libz 1.2.3, without POSIX capabilities, without libpcre, with SMI 0.4.8, without c-ares, without ADNS, with Lua 5.1, without Python, with GnuTLS 2.12.7, with Gcrypt 1.4.6, with MIT Kerberos, with GeoIP, with PortAudio V19-devel (built Sep 30 2011 11:17:29), without AirPcap.
Running on Mac OS 10.6.8 (Darwin 10.8.0), with libpcap version 1.0.0, with libz 1.2.3, GnuTLS 2.12.7, Gcrypt 1.4.6.
Built using gcc 4.2.1 (Apple Inc. build 5666) (dot 3).
The final L3 IP destination address will be the last entry in the routing header EXCEPT when the table is exhausted (pointer is greater than the length). In this case, the final L3 IP destination address is the one in the L3 header. See RFC 791.added uigtk version1.6 labels
-
A capture file, WanRgmii.pcap, was attached to bug #6560 (closed). Frame 3 of that file is what is being referred to here.
-
(In reply to comment #0)
> The final L3 IP destination address will be the last entry in the routing
> header EXCEPT when the table is exhausted (pointer is greater than the length).
> In this case, the final L3 IP destination address is the one in the L3 header.
> See RFC 791.OK well I'm confused. The calculation of the UDP checksum is specified in RFC 768 (http://tools.ietf.org/html/rfc768). How does the presence of an IP header routing option affect it? What am I missing?
-
RFC 791 says: Loose Source and Record Route +--------+--------+--------+---------//--------+ |10000011| length | pointer| route data | +--------+--------+--------+---------//--------+ Type=131 The loose source and record route (LSRR) option provides a means for the source of an internet datagram to supply routing information to be used by the gateways in forwarding the datagram to the destination, and to record the route information. The option begins with the option type code. The second octet is the option length which includes the option type code and the length octet, the pointer octet, and length-3 octets of route data. The third octet is the pointer into the route data indicating the octet which begins the next source address to be processed. The pointer is relative to this option, and the smallest legal value for the pointer is 4. A route data is composed of a series of internet addresses. Each internet address is 32 bits or 4 octets. If the pointer is greater than the length, the source route is empty (and the recorded route full) and the routing is to be based on the destination address field. If the address in destination address field has been reached and the pointer is not greater than the length, the next address in the source route replaces the address in the destination address field, and the recorded route address replaces the source address just used, and pointer is increased by four. The recorded route address is the internet module's own internet address as known in the environment into which this datagram is being forwarded. This procedure of replacing the source route with the recorded route (though it is in the reverse of the order it must be in to be used as a source route) means the option (and the IP header as a whole) remains a constant length as the datagram progresses through the internet. This option is a loose source route because the gateway or host IP is allowed to use any route of any number of other intermediate gateways to reach the next address in the route. Must be copied on fragmentation. Appears at most once in a datagram. Strict Source and Record Route +--------+--------+--------+---------//--------+ |10001001| length | pointer| route data | +--------+--------+--------+---------//--------+ Type=137 The strict source and record route (SSRR) option provides a means for the source of an internet datagram to supply routing information to be used by the gateways in forwarding the datagram to the destination, and to record the route information. The option begins with the option type code. The second octet is the option length which includes the option type code and the length octet, the pointer octet, and length-3 octets of route data. The third octet is the pointer into the route data indicating the octet which begins the next source address to be processed. The pointer is relative to this option, and the smallest legal value for the pointer is 4. A route data is composed of a series of internet addresses. Each internet address is 32 bits or 4 octets. If the pointer is greater than the length, the source route is empty (and the recorded route full) and the routing is to be based on the destination address field. If the address in destination address field has been reached and the pointer is not greater than the length, the next address in the source route replaces the address in the destination address field, and the recorded route address replaces the source address just used, and pointer is increased by four. The recorded route address is the internet module's own internet address as known in the environment into which this datagram is being forwarded. This procedure of replacing the source route with the recorded route (though it is in the reverse of the order it must be in to be used as a source route) means the option (and the IP header as a whole) remains a constant length as the datagram progresses through the internet. This option is a strict source route because the gateway or host IP must send the datagram directly to the next address in the source route through only the directly connected network indicated in the next address to reach the next gateway or host specified in the route. Must be copied on fragmentation. Appears at most once in a datagram. RFC 768 says Checksum is the 16-bit one's complement of the one's complement sum of a pseudo header of information from the IP header, the UDP header, and the data, padded with zero octets at the end (if necessary) to make a multiple of two octets. TThe pseudo header conceptually prefixed to the UDP header contains the source address, the destination address, the protocol, and the UDP length. This information gives protection against misrouted datagrams. This checksum procedure is the same as is used in TCP. 0 7 8 15 16 23 24 31 +--------+--------+--------+--------+ | source address | +--------+--------+--------+--------+ | destination address | +--------+--------+--------+--------+ | zero |protocol| UDP length | +--------+--------+--------+--------+ *If* this means that the destination host should check the checksum using the source and destination address *it* sees, that means that the source host should calculate the checksum using what will be the ultimate source and destination addresses, even if they'll be rewritten along the way due to LSRR or SSRR options, and packet sniffers that check UDP checksums should, if they're not capturing the packet as it's delivered to the destination host, check the checksum based on what would be the ultimate source and destination addresses. And, in fact, that's what tcpdump's checksum-checker does. NOTE: this arguably means that the UDP and TCP dissector, and all dissectors they call, should treat the *final* destination address, even when it's not the same as the destination address in the fixed-length portion of the IP header as the address in the destination endpoint, e.g. for finding conversations; two packets sent to the same address/port endpoint could belong to the same conversation *even if they're not being captured at the destination and they have different source routes, so that the destination addresses in the fixed-length portion of the IP header are not the same*. And, in fact, that's what tcpdump's relative-sequence-number printing code does *NOT* do, so it arguably needs to be fixed as well. -
Well I read the RFC's, but it still wasn't all that obvious to me what was going on here. Anyway, I broke out Stevens, read pp104-105, and well, a picture is worth a thousand words: In this figure, # denotes the pointer field. dest = D {#R1,R2,R3} | v +---+ dest = R1 +----+ dest = R2 +----+ dest = R3 +----+ dest = D +---+ | S |----------->| R1 |----------->| R2 |----------->| R3 |----------->| D | +---+ {#R2,R3,D} +----+ {R1,#R3,D} +----+ {R1,R2,#D} +----+ {R1,R2,R3#}+---+ So now it's clear to me. -
Created attachment 7440 An updated patch. Misc. changes such as: -> Adding some "via" filters: o Are the "ip.via" and "ip.via_host" names OK? o Should these match the "ip.addr" and "ip.host" filters too? -> Appending each option to the options tree -> IP name lookups of each source route -> A couple of minor whitespace changes -
(In reply to comment #9)
> First patch committed in r39961 w/a minor change to display the protocol number
> in the INFO column in decimal instead of hexadecimal. Scheduled for 1.6.5 and
> 1.4.11.Correction: The protocol number change to be displayed in decimal will not be backported.
mentioned in issue #6599 (closed)