Bug 249001 - traceroute incorrectly reports MPLS information in ICMP unreachable as icmp checksum wrong
traceroute incorrectly reports MPLS information in ICMP unreachable as icmp c...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: traceroute (Show other bugs)
4.5
All Linux
medium Severity low
: rc
: ---
Assigned To: Jiri Skala
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-07-20 05:17 EDT by Ralph Angenendt
Modified: 2016-09-20 01:54 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-09-10 04:39:55 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
traceroute-1.4a12-icmp_cksum.patch (422 bytes, patch)
2008-06-10 09:32 EDT, Jose Plans
no flags Details | Diff
The patch ensures the MPLS data are not included to the chk_sum function. (1.08 KB, patch)
2008-08-19 08:06 EDT, Jiri Skala
no flags Details | Diff

  None (edit)
Description Ralph Angenendt 2007-07-20 05:17:20 EDT
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)
Comment 1 William B. Peckham 2007-08-24 11:14:05 EDT
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.
Comment 2 Martin Nagy 2007-12-04 03:37:26 EST
I can reproduce this.
Comment 3 Dmitry Butskoy 2008-01-28 11:10:01 EST
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.
Comment 4 Ralph Angenendt 2008-01-28 13:14:14 EST
(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 ...
Comment 5 nars 2008-04-18 17:38:09 EDT
true, and I can reproduce it as well... very annoying :(
Comment 6 nars 2008-04-18 17:46:24 EDT
I have now downgraded to the package on original RHEL4 and working fine again so
it must be a bug on traceroute.
Comment 9 Jose Plans 2008-06-10 09:32:27 EDT
Created attachment 308811 [details]
traceroute-1.4a12-icmp_cksum.patch
Comment 12 RHEL Product and Program Management 2008-06-10 10:01:08 EDT
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.
Comment 14 Kaj J. Niemi 2008-08-19 05:38:01 EDT
backing out patch #18 makes mpls info work
Comment 15 Jiri Skala 2008-08-19 08:06:27 EDT
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.
Comment 16 Kaj J. Niemi 2008-08-19 08:15:00 EDT
The MPLS stuff is supposed to be attached to the packet, please refer to RFC 4950
Comment 17 Jiri Skala 2008-08-22 05:21:04 EDT
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".
Comment 18 Kaj J. Niemi 2008-08-22 05:26:30 EDT
Jiri,


How about fixing the buffer patch which broke this in the first place?


Thanks :)
Comment 19 Kaj J. Niemi 2008-08-22 05:27:20 EDT
That would be bug #164466 which is restricted to us mere mortals ;-)
Comment 20 Jiri Skala 2008-08-22 07:19:34 EDT
Hi,
my fix is an extension of mentioned buffer patch. I increased the minimal buffer size to allow receiving MPLS information.
Comment 31 errata-xmlrpc 2008-09-10 04:39:55 EDT
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

Note You need to log in before you can comment on or make changes to this bug.