11

I'm a Linux Mint user. I've run traceroute on Linux and tracert on Windows. On Linux, I just get asterisks. Everything seems to work fine on Windows. Here are the outputs

Windows:

Windows

Linux Mint:

Linux Mint

Why is this happening and is there something I can do to solve this problem?

Anthon
  • 78,313
  • 42
  • 165
  • 222
Luigi
  • 261
  • 2
  • 3
  • 9
  • And you can access the Internet from the Linux Mint system? Are these OSes both running on the same PC? As a dual-boot or using virtualization? – depquid Apr 16 '13 at 18:59
  • 1
    Down voting because of same reason as @depquid comment. This question lacks many critical information to solve this. – bagavadhar Apr 16 '13 at 19:30
  • 2
    I don't think he deserved any downvotes for this. There was enough information here to provide an answer. – jordanm Apr 17 '13 at 00:28
  • 1
    I'm not looking for upvotes, just for answers, so I won't defend myself :) Of couse I can access the Internet, this seems to me a trivial question. Sorry for not writing about the machine: yes, it's the same (with dual-boot) – Luigi May 31 '13 at 08:42

2 Answers2

16

A likely reason for the difference is that by default Window's tracert uses ICMP, whereas Linux traceroute defaults to UDP. Using the -I option for traceroute should produce the same results as tracert:

traceroute -w 10 -I google.it

From the traceroute documentation:

In the modern network environment the traditional traceroute methods can not be always applicable, because of widespread use of firewalls. Such firewalls filter the "unlikely" UDP ports, or even ICMP echoes. To solve this, some additional tracerouting methods are implemented (including tcp), see LIST OF AVAILABLE METHODS below. Such methods try to use particular protocol and source/destination port, in order to bypass firewalls (to be seen by firewalls just as a start of allowed type of a network session).

LIST OF AVAILABLE METHODS

In general, a particular traceroute method may have to be chosen by -M name, but most of the methods have their simple cmdline switches (you can see them after the method name, if present).

default

The traditional, ancient method of tracerouting. Used by default.

Probe packets are udp datagrams with so-called "unlikely" destination ports. The "unlikely" port of the first probe is 33434, then for each next probe it is incremented by one. Since the ports are expected to be unused, the destination host normally returns "icmp unreach port" as a final response. (Nobody knows what happens when some application listens for such ports, though).

nate
  • 103
  • 2
jordanm
  • 41,988
  • 9
  • 116
  • 113
0

Try this:

traceroute -M icmp google.it
roaima
  • 107,089
  • 14
  • 139
  • 261
user372552
  • 1
  • 3
    It would be much better if you could [edit] your question and explain what this does, and why it would solve the issue described. – roaima Sep 13 '19 at 19:40
  • ICMP is never the good tool to troubleshoot networking problems (and you could as well just use `ping` then, no need for `traceroute -M`). If you try to assess HTTP connectivity (which I guess based on the name used in the question) then you need to do an HTTP query which a TCP/80 or TCP/443 typically. Hence you use `tpctraceroute` for that. – Patrick Mevzek Sep 13 '19 at 20:58