LinuxQuestions.org
Review your favorite Linux distribution.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Networking
User Name
Password
Linux - Networking This forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.

Notices


Reply
  Search this Thread
Old 02-21-2013, 10:27 AM   #1
hua
Member
 
Registered: Oct 2006
Location: Slovak Republic
Distribution: Slackware 13.37, 14.0
Posts: 414

Rep: Reputation: 52
traceroute doesn't find all hops - tracert does


I am trying to find out what can be the reason for this difference:

1. When I try to traceroute from my linux desktop to the remote host there are several hops which are lost. (I used -I for ICMP)

2. When I do the same from windows with tracert (same PC) all those previously lost hops are present.

I tried already several parameter changes:
-w for wait
-z 5 for wait between pings
-N 1 for number of packets sent out simultaneously

Its always the same. So the trace to the host misses 4 hops with linux compared to windows .

I know that it must work because with mtr I can see all the hops but I cannot find out how it does.

 
Old 02-21-2013, 10:40 AM   #2
lleb
Senior Member
 
Registered: Dec 2005
Location: Florida
Distribution: CentOS/Fedora
Posts: 2,612

Rep: Reputation: 486Reputation: 486Reputation: 486Reputation: 486Reputation: 486
copy/paste them here. there could be duplicates in the tracert that are being skipped in traceroute. you can also run mtr as root to get a better picture on the linux box.
 
Old 02-21-2013, 10:44 AM   #3
lleb
Senior Member
 
Registered: Dec 2005
Location: Florida
Distribution: CentOS/Fedora
Posts: 2,612

Rep: Reputation: 486Reputation: 486Reputation: 486Reputation: 486Reputation: 486
from my win7 box

Code:
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

C:\Users\ray>tracert google.com

Tracing route to google.com [74.125.137.100]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  ssmahomeipcop.ssmahome.local [192.168.2.1]
  2    32 ms    22 ms    14 ms  10.108.240.1
  3    59 ms    40 ms    37 ms  ten0-1-0-7.orld53-ser2.bhn.net [72.31.194.34]
  4    36 ms    35 ms    32 ms  ten0-10-0-9.orld71-car2.bhn.net [71.44.60.146]
  5    55 ms    39 ms    40 ms  hun0-6-0-0.orld71-cbr3.bhn.net [72.31.193.22]
  6    30 ms    33 ms    35 ms  xe-11-0-0.bar1.Orlando1.Level3.net [4.79.118.41]

  7    45 ms    48 ms    41 ms  ae-0-11.bar2.Orlando1.Level3.net [4.69.137.146]

  8    42 ms    42 ms    35 ms  ae-5-5.ebr2.Miami1.Level3.net [4.69.148.209]
  9    48 ms    59 ms    52 ms  ae-2-52.edge1.Miami2.Level3.net [4.69.138.107]
 10    47 ms    64 ms    77 ms  GOOGLE-INC.edge1.Miami2.Level3.net [4.59.240.26]

 11    22 ms    20 ms    22 ms  209.85.253.118
 12    59 ms    62 ms    57 ms  216.239.48.192
 13    43 ms    65 ms    65 ms  209.85.248.31
 14     *        *        *     Request timed out.
 15    24 ms    24 ms    22 ms  yh-in-f100.1e100.net [74.125.137.100]

Trace complete.

C:\Users\ray>
my iMAC sitting right next to the win7 box:

Code:
ssma-imac:~ ssma$ traceroute google.com
traceroute: Warning: google.com has multiple addresses; using 74.125.137.101
traceroute to google.com (74.125.137.101), 64 hops max, 52 byte packets
 1  ssmahomeipcop (192.168.2.1)  0.720 ms  0.310 ms  0.224 ms
 2  10.108.240.1 (10.108.240.1)  24.055 ms  16.687 ms  21.918 ms
 3  ten0-1-0-7.orld53-ser2.bhn.net (72.31.194.34)  15.951 ms  32.139 ms  28.779 ms
 4  ten0-10-0-9.orld71-car2.bhn.net (71.44.60.146)  49.745 ms  26.064 ms
    ten0-15-0-2.orld71-car2.bhn.net (97.69.193.74)  36.809 ms
 5  hun0-6-0-0.orld71-cbr3.bhn.net (72.31.193.22)  31.271 ms
    hun0-7-0-0.orld71-cbr3.bhn.net (72.31.193.24)  29.892 ms
    hun0-6-0-0.orld71-cbr3.bhn.net (72.31.193.22)  40.020 ms
 6  xe-11-3-0.bar1.orlando1.level3.net (4.79.116.137)  38.765 ms
    xe-11-0-0.bar1.orlando1.level3.net (4.79.118.41)  31.703 ms
    xe-11-3-0.bar1.orlando1.level3.net (4.79.116.137)  59.512 ms
 7  ae-0-11.bar2.orlando1.level3.net (4.69.137.146)  16.837 ms  25.208 ms  14.700 ms
 8  ae-5-5.ebr2.miami1.level3.net (4.69.148.209)  39.938 ms  28.567 ms  27.019 ms
 9  ae-2-52.edge1.miami2.level3.net (4.69.138.107)  32.290 ms  30.671 ms  36.659 ms
10  google-inc.edge1.miami2.level3.net (4.59.240.26)  87.059 ms  83.597 ms  98.170 ms
11  209.85.253.118 (209.85.253.118)  49.247 ms  149.058 ms
    209.85.253.74 (209.85.253.74)  62.365 ms
12  216.239.48.192 (216.239.48.192)  57.790 ms  79.809 ms  61.301 ms
13  209.85.248.53 (209.85.248.53)  69.179 ms
    209.85.248.29 (209.85.248.29)  22.881 ms
    209.85.248.31 (209.85.248.31)  54.507 ms
14  * * *
15  yh-in-f101.1e100.net (74.125.137.101)  34.236 ms  43.339 ms  38.861 ms
note, it took the iMAC less then 2sec to complete traceroute, while win7 took better then 3min.

and on my CentOS 6.3 box i had the following results:

Code:
[ray@centos ~]$ traceroute google.com
traceroute to google.com (74.125.137.100), 30 hops max, 60 byte packets
 1  ssmahomeipcop.ssmahome.local (192.168.2.1)  0.399 ms  0.430 ms  0.477 ms
 2  10.108.240.1 (10.108.240.1)  24.554 ms  24.669 ms  24.887 ms
 3  ten0-1-0-7.orld53-ser2.bhn.net (72.31.194.34)  27.283 ms  27.479 ms  27.670 ms
 4  ten0-15-0-2.orld71-car2.bhn.net (97.69.193.74)  42.605 ms ten0-10-0-9.orld71-car2.bhn.net (71.44.60.146)  39.753 ms  40.223 ms
 5  hun0-7-0-0.orld71-cbr3.bhn.net (72.31.193.24)  27.801 ms  36.796 ms  36.495 ms
 6  xe-11-2-0.bar1.Orlando1.Level3.net (4.79.116.145)  28.254 ms xe-11-0-0.bar1.Orlando1.Level3.net (4.79.118.41)  26.542 ms xe-11-2-0.bar1.Orlando1.Level3.net (4.79.116.145)  27.069 ms
 7  ae-0-11.bar2.Orlando1.Level3.net (4.69.137.146)  27.440 ms  21.538 ms  21.921 ms
 8  ae-5-5.ebr2.Miami1.Level3.net (4.69.148.209)  29.378 ms  27.006 ms  27.115 ms
 9  ae-2-52.edge1.Miami2.Level3.net (4.69.138.107)  29.533 ms  29.907 ms  29.212 ms
10  GOOGLE-INC.edge1.Miami2.Level3.net (4.59.240.26)  75.040 ms  74.496 ms  74.739 ms
11  209.85.253.118 (209.85.253.118)  36.764 ms 209.85.253.74 (209.85.253.74)  36.710 ms  40.785 ms
12  209.85.254.252 (209.85.254.252)  40.636 ms  50.235 ms  48.870 ms
13  209.85.248.31 (209.85.248.31)  46.926 ms  47.052 ms 209.85.248.29 (209.85.248.29)  48.517 ms
14  * * *
15  yh-in-f100.1e100.net (74.125.137.100)  49.144 ms  49.302 ms  49.500 ms
mtr on that same box provides the following:

Code:
 My traceroute  [v0.75]
centos.ssmahome (0.0.0.0)                                                                                                                                                             Thu Feb 21 07:37:28 2013
Resolver error: No error returned but no answers given. of fields   quit
                                                                                                                                                                      Packets               Pings
 Host                                                                                                                                                               Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. ssmahomeipcop.ssmahome.local                                                                                               0.0%    11    0.2   0.2   0.2   0.3   0.0
 2. 10.108.240.1                                                                                                                             0.0%    10   21.6  22.3   9.9  37.1  11.2
 3. ten0-1-0-7.orld53-ser2.bhn.net                                                                                               0.0%    10   11.3  18.1   8.3  30.2   7.2
 4. ten0-10-0-9.orld71-car2.bhn.net                                                                                             0.0%    10   27.0  24.2  13.4  35.1   6.7
 5. hun0-6-0-0.orld71-cbr3.bhn.net                                                                                              0.0%    10   24.0  24.1  11.0  41.8   9.1
 6. xe-11-3-0.bar1.Orlando1.Level3.net                                                                                         0.0%    10   19.3  29.3  17.2  70.6  16.5
 7. ae-0-11.bar2.Orlando1.Level3.net                                                                                             0.0%    10   30.4  22.8  10.0  36.3  10.2
 8. ae-5-5.ebr2.Miami1.Level3.net                                                                                                  0.0%    10   20.1  28.2  19.9  41.2   8.0
 9. ae-2-52.edge1.Miami2.Level3.net                                                                                              0.0%    10   20.1  28.9  18.2  64.9  13.7
10. GOOGLE-INC.edge1.Miami2.Level3.net                                                                                      0.0%    10   61.0  71.3  53.0  89.5  13.2
11. 209.85.253.74                                                                                                                           0.0%    10   24.6  52.6  22.2 205.5  54.5
12. 209.85.254.252                                                                                                                         0.0%    10   28.4  35.8  22.3  53.5  11.0
13. 209.85.248.29                                                                                                                           0.0%    10   26.0  36.4  26.0  49.4   7.9
    209.85.248.53
14. ???
15. yh-in-f113.1e100.net                                                                                                                0.0%    10   23.4  38.0  22.9  53.2  11.5
also note CentOS took about as long as the iMAC to run both traceroute and mtr to the final hop.

Last edited by lleb; 02-21-2013 at 10:47 AM.
 
1 members found this post helpful.
Old 02-21-2013, 02:54 PM   #4
hua
Member
 
Registered: Oct 2006
Location: Slovak Republic
Distribution: Slackware 13.37, 14.0
Posts: 414

Original Poster
Rep: Reputation: 52
Thanks for your answer. I can see that you get the same for CentOS as win7 - so this is not usual and you also use just simple traceroute google.com as I do. So what can cause that I get on my CentOS (and also on my Slackware) something like this:
(I use your results as example)
Quote:
[ray@centos ~]$ traceroute google.com
traceroute to google.com (74.125.137.100), 30 hops max, 60 byte packets
1 ssmahomeipcop.ssmahome.local (192.168.2.1) 0.399 ms 0.430 ms 0.477 ms
2 10.108.240.1 (10.108.240.1) 24.554 ms 24.669 ms 24.887 ms
3 ten0-1-0-7.orld53-ser2.bhn.net (72.31.194.34) 27.283 ms 27.479 ms 27.670 ms
4 ten0-15-0-2.orld71-car2.bhn.net (97.69.193.74) 42.605 ms ten0-10-0-9.orld71-car2.bhn.net (71.44.60.146) 39.753 ms 40.223 ms
5 * * *
6 * * *
7 * * *
8 ae-5-5.ebr2.Miami1.Level3.net (4.69.148.209) 29.378 ms 27.006 ms 27.115 ms
9 ae-2-52.edge1.Miami2.Level3.net (4.69.138.107) 29.533 ms 29.907 ms 29.212 ms
10 * * *
11 209.85.253.118 (209.85.253.118) 36.764 ms 209.85.253.74 (209.85.253.74) 36.710 ms 40.785 ms
12 209.85.254.252 (209.85.254.252) 40.636 ms 50.235 ms 48.870 ms
13 209.85.248.31 (209.85.248.31) 46.926 ms 47.052 ms 209.85.248.29 (209.85.248.29) 48.517 ms
14 * * *
15 yh-in-f100.1e100.net (74.125.137.100) 49.144 ms 49.302 ms 49.500 ms
but when I use tracert in windows7, I get this:
Quote:
C:\Users\ray>tracert google.com

Tracing route to google.com [74.125.137.100]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms ssmahomeipcop.ssmahome.local [192.168.2.1]
2 32 ms 22 ms 14 ms 10.108.240.1
3 59 ms 40 ms 37 ms ten0-1-0-7.orld53-ser2.bhn.net [72.31.194.34]
4 36 ms 35 ms 32 ms ten0-10-0-9.orld71-car2.bhn.net [71.44.60.146]
5 55 ms 39 ms 40 ms hun0-6-0-0.orld71-cbr3.bhn.net [72.31.193.22]
6 30 ms 33 ms 35 ms xe-11-0-0.bar1.Orlando1.Level3.net [4.79.118.41]
7 45 ms 48 ms 41 ms ae-0-11.bar2.Orlando1.Level3.net [4.69.137.146]
8 42 ms 42 ms 35 ms ae-5-5.ebr2.Miami1.Level3.net [4.69.148.209]
9 48 ms 59 ms 52 ms ae-2-52.edge1.Miami2.Level3.net [4.69.138.107]
10 47 ms 64 ms 77 ms GOOGLE-INC.edge1.Miami2.Level3.net [4.59.240.26]
11 22 ms 20 ms 22 ms 209.85.253.118
12 59 ms 62 ms 57 ms 216.239.48.192
13 43 ms 65 ms 65 ms 209.85.248.31
14 * * * Request timed out.
15 24 ms 24 ms 22 ms yh-in-f100.1e100.net [74.125.137.100]

Trace complete.
Note that the win7 is a virtual PC in virtualbox on top of the Slackware. The CentOS is also a virtual PC in same virtualbox.
What means that the network must be absolutely the same.
I am really confused.
Right now I am trying to compare the complete traffic by wireshark on both - what is different in the win7 tracert.
 
Old 02-21-2013, 04:11 PM   #5
lleb
Senior Member
 
Registered: Dec 2005
Location: Florida
Distribution: CentOS/Fedora
Posts: 2,612

Rep: Reputation: 486Reputation: 486Reputation: 486Reputation: 486Reputation: 486
please use your own data so we can help troubleshoot. all you did is show that one traceroute had timeouts and the other didnt. nothing out of the ordinary there.
 
Old 02-22-2013, 03:14 AM   #6
hua
Member
 
Registered: Oct 2006
Location: Slovak Republic
Distribution: Slackware 13.37, 14.0
Posts: 414

Original Poster
Rep: Reputation: 52
Quote:
Originally Posted by lleb View Post
please use your own data so we can help troubleshoot. all you did is show that one traceroute had timeouts and the other didnt. nothing out of the ordinary there.
The actual data has nothing to do with the point in my question. I don't want to post such information in a public post about my network path.
The point here is that from same location linux behaves differently like windows its the same notebook connected to the same physical network. It must be something wrong in the traceroute utility itself - its not reliable.

Why is this important for me:

I need to write a script which can be run by simple user privileges under CentOS. The script should create a text file with lots of data in it - network configuration, ping data to several locations, traceroute data to several locations. This text file should serve for administrators to track down user connection problems. Since this is a mixed environment - Linux and Windows too the same script exists for windows.

The problem:
- The windows script (with tracert) can be run without any problems under simple user privileges.
- The linux script can not - actually I can use traceroute without the -I switch as user, but I get no valid data (only stars). Since linux uses UDP as default and this doesn't work (all hops get stars). See: http://www.linuxquestions.org/questi...f-icmp-815625/
Question 1: Did you get the above results (in CentOS) with UDP traceroute???

- And the actual problem is: even if I run traceroute as root with -I ICMP packets I do not get the same data as in windows with tracert - And tracert can be run by simple user account - no need to be an administrator (again its a same physical connection point in my local network)

What is a good point in the linked thread above:
Question 2: Why is that - that ping, which uses ICMP doesn't need root privileges and traceroute needs when used with ICMP?

The result is that I cannot create an linux like user script which does the same as the windows one.

Windows bat file
Code:
ping google.com >> "C:\debug.txt"
tracert google.com >> "C:\debug.txt"
Linux script
Code:
#!/bin/bash
ping google.com >> ./debug.txt
traceroute -I google.com >> ./debug.txt

Last edited by hua; 02-22-2013 at 03:19 AM.
 
Old 02-22-2013, 04:41 PM   #7
lleb
Senior Member
 
Registered: Dec 2005
Location: Florida
Distribution: CentOS/Fedora
Posts: 2,612

Rep: Reputation: 486Reputation: 486Reputation: 486Reputation: 486Reputation: 486
if you only want the user to have access to traceroute -I then put it in sudo. then it can be called by the user you gave permissions for that specific call.

as you are using centOS you would add it as root via visudo then you would add the following command to the users line:

/bin/traceroute -I

place a comma after or before as will be required depending on its location in the line.

operator ALL= /bin/traceroute -l, /sbin/shutdown -r now, /sbin/shutdown -h now

in the above example the username=operator
ALL means from anyplace the user 'operator' and execute the following ROOT level commands
/bin/traceroute -l
/sbin/shutdown -r now
/sbin/shutdown -h now

so in your script you would call traceroute with sudo and its full path:

Code:
sudo /bin/traceroute -l
not sure that is helping much, but i hope it does.
 
1 members found this post helpful.
Old 02-22-2013, 04:44 PM   #8
lleb
Senior Member
 
Registered: Dec 2005
Location: Florida
Distribution: CentOS/Fedora
Posts: 2,612

Rep: Reputation: 486Reputation: 486Reputation: 486Reputation: 486Reputation: 486
nm, that might not work with traceroute... as the -l requires an argument to function and that is not in the visudo file...

sorry mate im over my head with this one. sadly im not much more help.
 
Old 02-27-2013, 07:44 AM   #9
hua
Member
 
Registered: Oct 2006
Location: Slovak Republic
Distribution: Slackware 13.37, 14.0
Posts: 414

Original Poster
Rep: Reputation: 52
Quote:
Originally Posted by lleb View Post
nm, that might not work with traceroute... as the -l requires an argument to function and that is not in the visudo file...

sorry mate im over my head with this one. sadly im not much more help.
Thank you for your suggestions. I'm thankful for your posts.

The root execution I partly solved - although the users must input their passwords as an extra step and also edit the /etc/sudoers file to be able to do sudo. This can be pretty annoying for non-admin-like users. But I think its a usable solution.

I replaced the traceroute with MTR (my traceroute) utility which gives good results for the network paths. Unfortunately this also requires root privileges.
Anyway, I need to investigate why the traceroute itself gives wrong results. Maybe I am doing something wrong.

If there are some of you outside who can try to do several tests for me and post the result it would be good point to start. NOTE I don't need the complete result list (your paths) - its enough if you compare this three methods:

traceroute google.com (did you get any hop values?)
traceroute -I google.com ( is this the same as the previous?)
mtr -r -c 4 google.com (are some of the hops in traceroute result missing which are present in the mtr result?)

This can answer the question whether this problem has everybody with linux traceroute or something is wrong with my network or the way I use traceroute.

Thanks

Last edited by hua; 02-27-2013 at 08:08 AM.
 
Old 01-14-2015, 09:01 AM   #10
gprathap1121@gmail.com
LQ Newbie
 
Registered: Jun 2014
Posts: 20

Rep: Reputation: Disabled
traceroute still doesn't work using -I option in su mode

Hello,
I am posting on this chain after long time.
Facing similar issue on my Ubuntu Linux PC.
tracert on windows display all the hops.
But traceroute on Ubuntu fails to display all the last hop.

When tried using -I (ICMP Echo's) option in sudo.
Output displays the last hop but intermediate hops are missing in the output.

Does the cause for this issue found.


Thanks
Prathap G
 
Old 01-15-2015, 06:10 AM   #11
hua
Member
 
Registered: Oct 2006
Location: Slovak Republic
Distribution: Slackware 13.37, 14.0
Posts: 414

Original Poster
Rep: Reputation: 52
Hi Parthap G,

Not really. As a workaround I have used the mtr utility instead.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
split routing - traceroute not displaying unrouted hops fragtion Linux - Networking 8 01-21-2011 12:37 AM
BASH command tracert/traceroute not recognized phantom_cyph Linux - General 6 02-19-2007 10:34 AM
tracert/traceroute dav_y2k Linux - Networking 1 12-06-2006 11:25 AM
traceroute - I option doesn't work nick623 Fedora 1 07-30-2006 03:14 AM
Traceroute, tracert??? MattLaw Linux - General 9 05-02-2004 07:57 PM


All times are GMT -5. The time now is 04:29 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration