Description of problem: traceroute ncorrectly reports MPLS information in ICMP unreachable as icmp checksum wrong - this is a degression against the traceroute which was in 4.4. This bug has been reported at the CentOS bugtracker: http://bugs.centos.org/view.php?id=2182 Version-Release number of selected component (if applicable): traceroute-1.4a12-24.EL4.1.i386 How reproducible: Run traceroute against google.com. Steps to Reproduce: traceroute.google.com Actual results: [root@rootsserver ~]# traceroute google.com traceroute: Warning: google.com has multiple addresses; using 64.233.187.99 traceroute to google.com (64.233.187.99), 30 hops max, 38 byte packets [...] 4 xr-gar1-ge9-2.x-win.dfn.de (188.1.37.45) 3.491 ms 3.435 ms 3.987 ms 5 * * zr-fra1-te0-7-0-1.x-win.dfn.de (188.1.145.53) 11.641 ms 6 64.213.78.237 (64.213.78.237) 25.066 ms 25.133 ms 25.132 ms 7 72.14.198.49 (72.14.198.49) 21.357 ms 21.355 ms 21.694 ms Icmp checksum is wrong 8 216.239.43.90 (216.239.43.90) 30.126 msIcmp checksum is wrong 29.449 msIcmp checksum is wrong 43.949 ms Icmp checksum is wrong 9 64.233.174.26 (64.233.174.26) 32.564 msIcmp checksum is wrong 216.239.46.112 (216.239.46.112) 111.575 msIcmp checksum is wrong 64.233.174.26 (64.233.174.26) 31.783 ms Icmp checksum is wrong [...] Expected results: [root@shutdown ~]# traceroute google.com traceroute to google.com (64.233.187.99), 30 hops max, 40 byte packets [...] 4 xr-gar1-ge9-2.x-win.dfn.de (188.1.37.45) 4.569 ms 3.777 ms 3.086 ms 5 * * * 6 64.213.78.237 (64.213.78.237) 26.119 ms 26.216 ms 26.202 ms 7 72.14.198.49 (72.14.198.49) 22.100 ms 22.115 ms 22.094 ms 8 216.239.43.90 (216.239.43.90) 30.037 ms 45.982 ms 45.978 ms 9 72.14.238.248 (72.14.238.248) 32.051 ms 64.233.174.26 (64.233.174.26) 33.915 ms 33.908 ms 10 72.14.236.212 (72.14.236.212) 112.327 ms 111.932 ms 111.944 ms 11 66.249.94.235 (66.249.94.235) 116.357 ms 116.672 ms 116.658 ms 12 72.14.238.138 (72.14.238.138) 129.488 ms 129.557 ms 128.343 ms 13 72.14.239.23 (72.14.239.23) 129.955 ms 130.039 ms 130.951 ms 14 216.239.49.226 (216.239.49.226) 142.687 ms 130.815 ms 130.053 ms 15 jc-in-f99.google.com (64.233.187.99) 130.016 ms 130.691 ms 129.482 ms (traceroute from RHEL 5)
At my site I found that specifying a packet size of 72 or larger (99 is convenient) seems to avoid the bug. This may serve as a temporary work-around pending install of another version.
I can reproduce this.
Martin, It related to the previous epoch of the traceroute (1.4a). All mine are >= 2.0.x :) Try is it reproducable under RHEL5 or Fedora.
(In reply to comment #3) > Martin, > > It related to the previous epoch of the traceroute (1.4a). > > All mine are >= 2.0.x :) > > Try is it reproducable under RHEL5 or Fedora. That doesn't help for RHEL4 at all. And it worked before ...
true, and I can reproduce it as well... very annoying :(
I have now downgraded to the package on original RHEL4 and working fine again so it must be a bug on traceroute.
Created attachment 308811 [details] traceroute-1.4a12-icmp_cksum.patch
This bugzilla has Keywords: Regression. Since no regressions are allowed between releases, it is also being proposed as a blocker for this release. Please resolve ASAP.
backing out patch #18 makes mpls info work
Created attachment 314534 [details] The patch ensures the MPLS data are not included to the chk_sum function. The MPLS data are added to the packets for routing purpose on the entry point of label switched network. This label should be taken away when the packet leaves this kind of network. Unfortunately the ICMP packets contain this label. The patch detects real length of ICMP packet and didn't include MPLS to check sum calculation. This fixes the bug.
The MPLS stuff is supposed to be attached to the packet, please refer to RFC 4950
You are right. Thank you for your notice. There is an implementation of this RFC in the sources but it works after packet size definition on the command line: traceroute google.com 140 (140 is necessary minimum for rel. 24) This means that current traceroute-1.4a12-24.EL4.1.i386 works fine with this extra parameter: - no "Icmp checksum is wrong" message - MPLS packets are indicated in accordance to RFC 4950 This bug (#249001) will be fixed in next release increasing minimum packet size. This bug fix will fix also RFC 4950 compliance as a "side effect".
Jiri, How about fixing the buffer patch which broke this in the first place? Thanks :)
That would be bug #164466 which is restricted to us mere mortals ;-)
Hi, my fix is an extension of mentioned buffer patch. I increased the minimal buffer size to allow receiving MPLS information.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2008-0883.html