This is the talk page for discussing improvements to the Traceroute article. This is not a forum for general discussion of the subject of the article.

Add new text under old text. New to Wikipedia? Welcome! Learn to edit; get help. Start a new topic Assume good faith Be polite and avoid personal attacks Be welcoming to newcomers Seek dispute resolution if needed Article policies Neutral point of view No original research Verifiability

Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL

👁 Image

This article is rated C-class on Wikipedia's content assessment scale. It is of interest to the following WikiProjects:

👁 WikiProject icon Software: Computing Low‑importance 👁 WikiProject icon This article is within the scope of WikiProject Software, a collaborative effort to improve the coverage of software on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.SoftwareWikipedia:WikiProject SoftwareTemplate:WikiProject Softwaresoftware Low This article has been rated as Low-importance on the project's importance scale. 👁 Taskforce icon This article is supported by WikiProject Computing. 👁 WikiProject icon Computing: Networking Low‑importance 👁 WikiProject icon This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing Low This article has been rated as Low-importance on the project's importance scale. 👁 Taskforce icon This article is supported by Networking task force. 👁 WikiProject icon Internet Mid‑importance 👁 WikiProject icon 👁 icon Internet portal This article is within the scope of WikiProject Internet, a collaborative effort to improve the coverage of the Internet on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.InternetWikipedia:WikiProject InternetTemplate:WikiProject InternetInternet Mid This article has been rated as Mid-importance on the project's importance scale.

👁 icon

This article is based on material taken from the Free On-line Dictionary of Computing prior to 1 November 2008 and incorporated under the "relicensing" terms of the GFDL, version 1.3 or later.

traceroute.org isn't updated for a lot of years, half of links are dead and his maintainer takes care of it ! —Preceding unsigned comment added by 91.163.173.59 (talk) 23:23, 14 January 2008 (UTC)[]

The information on this page is a bit mixed up. It might take some work to sort out all the small discrepancies here. Kim Bruning 07:55, 4 Aug 2004 (UTC)

As to images,anyone up for an xtraceroute screenshot? For some reason my xtraceroute database sucks. I wonder if anyone has a nicer one to make a decent image with ;-) Kim Bruning 12:41, 30 Aug 2004 (UTC)

There is an article on mtr, "Matt's Trace Route," which should be merged into the traceroute article as a new section unless there's some compelling reason to keep the information in two unsynchronized places. (Or unless, of course, "Matt's Trace Route" turns out to be unencyclopedic; but apparently a bunch of Linux sysadmins use it, so I reserve judgment on that point.) --Quuxplusone 05:10, 21 April 2006 (UTC)[]

--Dissagree-- No don't do that, tracrt and mtr are completly different tools (they share some similarities in functionality) just reference each of them on both pages

--Disagree-- I concur with the above editor.Shouta 09:54, 4 May 2006 (UTC)[]

--Disagree-- Functionality is different, btw as one of those Linux sysadmins I recomend this tool as a replacement to tregular traceroute. Htaccess 13:50, 4 May 2006 (UTC)[]

--Agree-- The functionality is the same, MTR just adds another element (ping) after the initial traceroute. Note MTR often results in poor data, since it probes based on data going "to" the router (slow path / control-plane data which is usually heavily rate limited and cpu processed), not data going "through" the router. Take any such data with a grain of salt, or be prepared to be confused. Humble226 08:18, 8 July 2006 (UTC)[]

--Disagree-- traceroute is a traditional Unix command, there are dozens of "improved" versions out there, let's not mention them all in the article. Jaho 04:43, 17 March 2007 (UTC)[]

Why should the first letter not be capitalized if the name of the program is not traceroute? Mace 11:10, 12 November 2006 (UTC)[]

Because Unix-like operating systems distinguish between upper and lower case in filenames. Typing "Traceroute" in stead of "traceroute" results in a "command not found" error. Jaho 04:12, 17 March 2007 (UTC)[]

For these reasons, while traceroute was widely used during the early days of Internet, by the 1990s many Internet sites have blocked traceroute requests

This is somewhat deceptive, as there's no way to directly block traceroute requests, since traceroute just uses one of the standard network protocols (usually UDP, ICMP, or TCP). UDP-based traceroutes merely rely on the the hops and destination hosts sending ICMP_TIME_EXCEEDED and ICMP_PORT_UNREACHABLE, respectively. Standard UNIX traceroute also implements ICMP-based traceroute which uses ICMP ECHO instead of UDP. As mentioned in the article, some traceroutes use TCP.

The quoted text above oversimplifies what would be required to "block" traceroute requests (if it's even really feasible) and is thus deceptive. —Preceding unsigned comment added by Ramorum (talk • contribs) 23:41, 5 February 2008 (UTC)[]

I've now flagged "many Internet sites have blocked traceroute requests" as dubious. As stated above, there is no direct way to block traceroute requests. Perhaps the article writer means that many sites/isp's block ICMP/UDP. But even then, if a site does not respond to the ICMP or UDP packets involved, it is still possible to trace the route up to the node that blocks those packets. Also the article talks about round trip time here, but it is hop count that traceroute relies on, not round trip time, wich suggests to me that the article writer confuses traceroute and ping. The security concerns section needs at least clarification. Or perhaps it is better removed, since internet security is a general concern, and not specifically related to traceroute. Jaho (talk) 14:43, 12 November 2010 (UTC)[]

In 2003 a worm did quite a lot of damage and it caused infected computers to send zillions of ICMP packets. Many ISPs configured routers to block all ICMP packets that had the length used by the worm. MS Windows systems use ICMP packets for tracert which happened to be the same length, and for a couple of months it was not possible to tracert. Perhaps whoever wrote the section in question had that experience, or something like it, in mind. I'm not sure how it's done, but it is true that many private networks block incoming traceroute in practice (yes, I know that there is no such thing as a "traceroute" packet, so they are blocking more than traceroute). Johnuniq (talk) 23:04, 12 November 2010 (UTC)[]

While graphical illustrations are great, I think the screenshot of a terminal emulator running traceroute is superflous, as it's output is ASCII text, which is better conveyed as preformatted text. —SvartMan (talk) 17:50, 1 May 2011 (UTC)[]

Since the original implementation by Van Jacobson used UDP and virtually all implementations, except for Windows, use UDP by default, should we not put emphasis on UDP rather than ICMP operation. Possibly starting off with stating that UDP is the more common mode measured by numbers of implementation while ICMP, having backing by the most widely deployed OS (Windows), would probably be more commonly seen? If noone objects, I would like to rewrite the article accordingly. — Preceding unsigned comment added by Kll (talk • contribs) 10:08, 10 June 2011 (UTC)[]

Tracepath redirects here but is not mentioned in the article. ~Kvng (talk) 15:42, 20 June 2015 (UTC)[]

Now it is, :) please check it out. — Dsimic (talk | contribs) 06:18, 21 June 2015 (UTC)[]

Thanks for this and other cleanup. ~Kvng (talk) 16:25, 24 June 2015 (UTC)[]

Thank you for bringing it up in the first place. :) — Dsimic (talk | contribs) 19:41, 24 June 2015 (UTC)[]

There are many traceroute implementations out there, some better than others. Can we add a implementations section? I am thinking of a table, with the implementation name, kind of probes supported, release date, license etc. — Preceding unsigned comment added by 179.126.2.222 (talk) 12:54, 10 June 2017 (UTC)[]

I support saying that there are multiple implementations of varying quality. But, it seems foolhardy to try to track all the implementations and their limitations in WP. Stevebroshar (talk) 19:52, 16 May 2024 (UTC)[]

@Kvng: I think "...or high port UDP in Unix ping, to a site" means that, at least for versions of traceroute with a -p flag, you can check how far a UDP packet to a given port will go on the way to a given host. Is that what you're wondering about? Guy Harris (talk) 01:32, 2 November 2020 (UTC)[]

Guy Harris, If I understand your description correctly, that seems like an obscure use of the tool. I'm inclined to remove it and change "firewalls that may be blocking ICMP traffic" so that we're discussing all types of blockage including by UDP port number. ~Kvng (talk) 01:47, 2 November 2020 (UTC)[]

@Kvng: I guess the idea is that traceroute can be used to test whether packets of the type it's sending make it through firewalls, by sending them (with the usual increasing TTL) to the destination until you either get a response indicating that the TTL expired, get a response indicating that it made it, get a response that indicates that it's been blocked, or get a timeout (in which case you don't know what the problem is). That can be done with ICMP packets or UDP packets to a given port. Are you saying that both of those are obscure uses of traceroute? Guy Harris (talk) 02:18, 2 November 2020 (UTC)[]

Guy Harris, there are several methods available for testing a connection (see List Of Available Methods at [1]). There are a lot of options for exploring the allowable parameters for a connection and we can mention this but I don't think we should try to get at it all. The primary purpose of traceroute is to tell you the path you're using for communication. It can also tell you where in the path a failed connection is going bad. Determining which UDP ports are open through a firewall is possible but obscure. Better to use a port scanner for that. ~Kvng (talk) 13:47, 2 November 2020 (UTC)[]

> == Implementations == A command is available in many modern operating systems, generally named traceroute in Unix-like systems such as FreeBSD, macOS, and Linux ... etc

The command is now "generally named" tracepath as Linux distributors include this along with ping as part of the iputils group package. Traceroute is now normally an optional installation only.

See deepwiki and iputils – A Comprehensive Guide to Essential Linux Networking Utilities

Referencing ping in the introductory section gives a false impression of traceroute's status as an everyday utility WP:FALSEBALANCE

Pushing mentions of tracepath into insignificance gives WP:UNDUE weighting to the title software and not enough to the general subject.

I have tried to update this page but my efforts are being reverted on the grounds that the TITLE is "Traceroute", which I feel is bit like the tail wagging the dog ....

If Wikipedia is to remain up-to-date and relevant then topics generally need to have a bit of expansion room and need to be able to adjust to change.

Maybe the answer is creating a new umbrella topic for route-tracing in general and dropping the other topics seem to be already referenced by this one ?

Whatever the general consensus, this topic definitely NEEDS updating and needs some attention. AlexBwineglass (talk) 12:48, 8 June 2026 (UTC)[]

You quoted selectively. Here's the actual verbiage:

"A command is available in many modern operating systems, generally named traceroute in Unix-like systems such as FreeBSD, macOS, and Linux and named tracert in Windows and ReactOS."

It is clearly distinguishing the utility name as either 'traceroute' or 'tracert' - not distinguishing it as a general 'concept'. This article is clearly and explicitly about the command traceroute, that's why the article is named traceroute. It's not about a general concept of tracing routes, as that would include mapping software, routing and delivery software, logistics, and more.

It's worth noting that the verbiage "generally named" was added in 2024; before then it lacked that verbiage for twenty-two years.

"The command is now "generally named" tracepath as Linux distributors include this along with ping as part of the iputils group package. Traceroute is now normally an optional installation only.

According to what source is the command traceroute now "generally named" tracepath? And that traceroute is "normally" optional but traceroute is installed by default? Sources please. You're aware that there are multiple iputils packages across the more than 1,000 linux distributions? You're aware that the iputils package(s) are generally not installed by default on most linux distributions? Iputils is largely an optional package install; it depends on your choices when configuring a new installation. Often, one or another iputils package is pulled in automatically during installation based on other configuration choices; a strictly end-user desktop distro may completely exclude any iputils package; a purpose-built server installation will likely automatically pull in iputils.

In Debian, tracepath is a "Priority: optional" package, installed via the iputils-tracepath package, while iputils-ping, which includes traceroute, is considered a "Priority: important package - one step below required. One of my testing servers has both tracepath and traceroute, via iputils-tracepath and iputils-ping - both installed manually. Neither are installed by default. Other optional iputils packages in debian are iputils-arping and iputils-clockdiff.

"See [...]" (two urls)"

Neither a wiki nor a blog are reliable sources.

"Referencing ping in the introductory section gives a false impression of traceroute's status as an everyday utility WP:FALSEBALANCE"

Ping is mentioned as a comparative example against what traceroute performs; I think it's overstated as well, as it's an explanatory paragraph in the lede which instead belongs in the body.

"Pushing mentions of tracepath into insignificance gives WP:UNDUE weighting to the title software and not enough to the general subject.

Sorry, but that's a highly fanciful interpretation of UNDUE. In fact, pushing tracepath into the lede is explicitly UNDUE, as the article is about the so-named software, not a general concept.

"being reverted on the grounds that the TITLE is "Traceroute", which I feel is bit like the tail wagging the dog"

If the title of the article were "Trace routing", that would make sense. Please provide an example of the word 'traceroute' used in vernacular language, outside of the OS domain.

"If Wikipedia is to remain up-to-date and relevant then topics generally need to have a bit of expansion room and need to be able to adjust to change.

"Maybe the answer is creating a new umbrella topic for route-tracing in general and dropping the other topics seem to be already referenced by this one ?"

Again, you seem to believe the article is about a 'topic', rather than a UNIX/linux command. If you want more coverage of tracepath, you should consider creating a standalone article for tracepath, and see if it flies. I won't interfere. However, it will probably be rejected, as it's too niche to stand alone. That's why it's mentioned in this article, with an 'anchor', which is what allows people searching for tracepath to go directly to the description within this article. Route tracing as a general topic is covered in the article Traveling Salesman Problem.

You've yet to providing any reliable sourcing that supports the claims made in your changes that have been reverted. No evidence that 'tracepath' has replaced traceroute in any way - it's an alternative to traceroute, for end-users who wish to dabble in network diagnostics without employing privilege escalation required to run traceroute. For neophytes, that's a handy addition to the toolbelt.

Provide sources - third-party coverage (and not wikis or blogs) - that make a reasonably supported claim that traceroute is now in the dustbin of history. We need sources other than an individual editor's opinion that tracepath is installed by default by 'the majority' of distributions (ignoring that most distributions do not install any iputils package by default).

We go by reliable sources, not editor interpretations, observations, or opinions. cheers, anastrophe, an editor he is. 18:47, 8 June 2026 (UTC)[]

> In Debian, tracepath is a "Priority: optional" package, installed via the iputils-tracepath package, while iputils-ping, which includes traceroute, is considered a "Priority: important package - one step below required. One of my testing servers has both tracepath and traceroute, via iputils-tracepath and iputils-ping

There's more to the world of Linux than upstream Debian ....

Downstream, both Ubuntu and Mint come with tracepath preinstalled and not traceroute. See https://releases.ubuntu.com/26.04/ubuntu-26.04-desktop-amd64.manifest

Unlike Debian, both Arch and Fedora list iputils as a whole package. Arch puts iputils in its core list and places traceroute in extras.

Install vanilla Arch and you will only find tracepath. Even Manjaro Plasma FULL only has tracepath. Others like CachyOS and Garuda will have both 'route and 'path, as does Fedora.

The new PopOS Cosmic (written using Rust) and openSuse's TumbleWeed again, both have tracepath and NOT traceroute. AlexBwineglass (talk) 11:22, 9 June 2026 (UTC)[]

The article traceroute is about the tool traceroute, not about anything else. Feel free to start an article about tracepath if it's notable. --Zac67 (talk) 17:00, 9 June 2026 (UTC)[]

@Zac67 I don't think I would want to create a [WP:POVFORK] I don't think that that is the way forward. Some kind of evolution/synthesis process would be more preferable. At least that's how I see it. AlexBwineglass (talk) 19:00, 9 June 2026 (UTC)[]

First, a helpful tip to file away: You can 'quote' other comments by wrapping them in {{tq|"some words"}} ("tq" is short for "talk quote") - that helps to keep the distinction between your words and your interlocutor's clear.

"There's more to the world of Linux than upstream Debian ...."

I made no claim otherwise; however, it can be informative, since Debian is consistently one of the most widely-used distributions, and is the underlying OS of hundreds of others (including Ubuntu).

I also need to tender a correction; in straight Debian, traceroute is its own package; it's not bundled in iputils-ping.

"Downstream, both Ubuntu and Mint come with tracepath preinstalled and not traceroute. See https://releases.ubuntu.com/26.04/ubuntu-26.04-desktop-amd64.manifest"

That's relatively unsurprising, as that's specifically a Desktop distribution; Desktop distros are geared toward 'regular users', rather than systems administrators, so tracepath, which doesn't require escalated privileges, is the more appropriate option. Systems administrators tend to 'live' in escalated privileges ("root"), and need more powerful tools for network analysis than tracepath, so when you build a server, traceroute is the tool of choice. Linux servers outnumber linux desktop installations by orders of magnitude. Traceroute is a 'power' utility, employed by systems administrators; that is the topic of this article.

"Unlike Debian, both Arch and Fedora list iputils as a whole package. Arch puts iputils in its core list and places traceroute in extras."

And that's fine. You've yet to provide a single reliable source that verifies that tracepath is 'normally' included rather than traceroute; claims of 'many' or 'most' distributions including tracepath rather than traceroute require independent sources to verify the claim; manifests aren't probative at all.

"Install vanilla Arch and you will only find tracepath. Even Manjaro Plasma FULL only has tracepath. Others like CachyOS and Garuda will have both 'route and 'path, as does Fedora."

Again - your personal observations of a handful of distributions aren't reliable sources. I suspect you are looking primarily at Desktop distributions, but, no matter. Find a reliable source that supports your claims, and provide it here. That's the only convincing evidence that will fly. The article already mentions tracepath, and if a reader searches WP for tracepath, they are brought directly to that mention in this article.

"The new PopOS Cosmic (written using Rust) and openSuse's TumbleWeed again, both have tracepath and NOT traceroute."

Same thing. None of this 'proves' anything in terms of reliable sourcing for an encyclopedia. This article is about the traceroute utility, which was written by Van Jacobson.

I have yet to see anything you've offered that supports tracepath being pushed to the lede. It's not the topic of this article. It's a related utility, so the mention in the body is what's appropriate. You are welcome to expand the tracepath section with additional details of what it does; however, since tracepath does not replace the traceroute utility, more than that would be problematic. cheers, anastrophe, an editor he is. 21:18, 9 June 2026 (UTC)[]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:Traceroute&oldid=1358615954"