Public bug reported:

Binary package hint: traceroute

Hello Ubuntuers,

I am facing a very strange problem in the traceroute package present in
the latest Ubuntu release (Hardy).

Problem description:
Because of lots of systems blocking udp packets, I prefer to use ICMP 
traceroute (the "traceroute -I" command). However I am unable to use this 
command in Hardy, because instead of printing the hops properly, it prints the 
first hop, then prints four lines with stars, fifth line with one star and then 
continues properly. This happens only with the ICMP tracing and DNS name 
resolution turned on.

Let me give you an example:
ICMP traceroute, DNS resolution turned on:
[EMAIL PROTECTED]:~$ sudo /usr/bin/traceroute -I 10.128.9.101
traceroute to 10.128.9.101 (10.128.9.101), 30 hops max, 40 byte packets
 1  10.128.6.1 (10.128.6.1)  20.654 ms  35.966 ms *
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * 10.128.9.101 (10.128.9.101)  30.744 ms  81.052 ms
ICMP traceroute, DNS resolution turned off ("-n" parameter):
[EMAIL PROTECTED]:~$ sudo /usr/bin/traceroute -n -I 10.128.9.101
traceroute to 10.128.9.101 (10.128.9.101), 30 hops max, 40 byte packets
 1  10.128.6.1  16.265 ms  35.758 ms  35.788 ms
 2  10.160.0.2  35.835 ms  35.845 ms  35.852 ms
 3  10.160.8.5  35.785 ms  35.794 ms  35.802 ms
 4  10.128.12.11  35.845 ms  35.853 ms  36.047 ms
 5  10.128.9.101  36.059 ms  57.850 ms  57.872 ms
UDP traceroute, name resolution turned on:
[EMAIL PROTECTED]:~$ sudo /usr/bin/traceroute 10.128.9.101
traceroute to 10.128.9.101 (10.128.9.101), 30 hops max, 40 byte packets
 1  10.128.6.1 (10.128.6.1)  16.038 ms  32.945 ms  32.958 ms
 2  10.160.0.2 (10.160.0.2)  32.999 ms  33.002 ms  33.018 ms
 3  10.160.8.5 (10.160.8.5)  32.929 ms  32.932 ms  32.935 ms
 4  klient10.ap-pk.zebetin.brno.czf (10.128.12.11)  32.965 ms  32.982 ms  
81.841 ms
 5  10.128.9.101 (10.128.9.101)  81.855 ms  81.860 ms  81.864 ms

To compare, here is also a Windows ICMP traceroute, which works perfectly:
C:\Users\Radek>tracert -d 10.128.9.101

Tracing route to 10.128.9.101 over a maximum of 30 hops

  1    20 ms    17 ms    18 ms  10.128.6.1
  2    20 ms    28 ms    18 ms  10.160.0.2
  3    29 ms    22 ms    42 ms  10.160.8.5
  4    19 ms    26 ms    18 ms  10.128.12.11
  5    40 ms    30 ms    38 ms  10.128.9.101

Trace complete.

And also a Mandriva traceroute (from the other side, the 10.160.8.4
router, which is connected using wired ethernet to 10.160.8.5)

[EMAIL PROTECTED] ~]# traceroute -V
Version 1.4a12

[EMAIL PROTECTED] ~]# traceroute 10.128.6.136
traceroute to 10.128.6.136 (10.128.6.136), 30 hops max, 38 byte packets
 1  cisco-vlan-008 (10.160.8.1)  2.617 ms  1.692 ms  2.498 ms
 2  openvpn (10.160.0.10)  0.981 ms  0.582 ms  0.640 ms
 3  10.128.6.136 (10.128.6.136)  78.158 ms  102.499 ms  17.792 ms

Possible issue:
You might think of a lossy network - that is not the case. I am experiencing 
this problem on every network connection in the system (tunelled, physical 
wired ethernet, physical wireless ethernet), it occurs when tracing the host 
over a VPN connection, over an internet connections (multiple different 
providers and speeds, starting 1 Mbit, ending 100 Mbit internet connection 
line), no matter what I choose, I get this strange behaviour, which already 
drives me crazy.

You may say, that the routers in the middle do not send ICMP responses.
That is not the case also. I have snapped the traffic with tcpdump and
attaching it to this bug. You may notice that the hosts _do_ send ICMP
responses.

I think that this is a bug in the traceroute 2.0.X package when using
some DNS servers - it's waiting for a name resolution for too long and
in the meantime it loses the ICMP replies that come over the network.

The version concerned is:

[EMAIL PROTECTED]:~$ traceroute -V
Modern traceroute for Linux, version 2.0.9, Nov 19 2007
Copyright (c) 2006  Dmitry Butskoy,   License: GPL

[EMAIL PROTECTED]:~$ dpkg --list | grep traceroute
ii  traceroute                                 2.0.9-3                          
                    Traces the route taken by packets over an IP

[EMAIL PROTECTED]:~$ apt-cache show traceroute
Package: traceroute
Priority: optional
Section: net
Installed-Size: 192
Maintainer: Ubuntu Core Developers <[EMAIL PROTECTED]>
Original-Maintainer: Daniel Baumann <[EMAIL PROTECTED]>
Architecture: amd64
Version: 2.0.9-3
Depends: libc6 (>= 2.6.1-1)
Conflicts: traceroute-nanog (<< 6.4.2-1), traceproto (<< 1.1.2beta1-3)
Filename: pool/main/t/traceroute/traceroute_2.0.9-3_amd64.deb
Size: 51776
MD5sum: 32a60cea0662ec745d477310a7e92b64
SHA1: f5d743ed8347bae1e8a2036dd40cad78b2e8e154
SHA256: c996606b09be773c5d333d8eab64e89b9e76a2c3c3ee98602ca66c01280708d0
(...)
Bugs: mailto:[EMAIL PROTECTED]
Origin: Ubuntu

How to reproduce the bug:
Simply run sudo traceroute -I www.google.com
(the letter in the traceroute parameter is a capital i fo ICMP traceroute, not 
small L)

** Affects: traceroute (Ubuntu)
     Importance: Undecided
         Status: New

-- 
ICMP traceroute does not work properly in Hardy
https://bugs.launchpad.net/bugs/269749
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to