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



Linux Mint:

Linux Mint

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

  • 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 0: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 8:42

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).


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).


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).

| improve this answer | |
  • This does not work for me. Gives the same result. – Goose Sep 23 '16 at 13:44

Try this:

traceroute -M icmp google.it
| improve this answer | |
  • 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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.