Talk:Traceroute

traceroute.org

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)

Matt's Trace Route

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)

correct title

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)

Security concerns

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)

Image necessary?

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)

UDP vs ICMP

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

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)

Add a implementations section

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)

Clarifying "or high port UDP in Unix ping, to a site"

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