[FxChiP]

No, but it's actually worse than that.

Not only is it contingent on your intermediaries actually responding to your packet with the diagnostic information you want, it assumes that the diagnostic response will also be able to get back to you. If, for instance, your links are failing over super frequently or you have something hilarious happen like the response packet ALSO having a too-low TTL, you may not get a response as you expect.

But wait, there's more! Precisely because of that stepping-increase of TTL, by necessity, it must send as many TTLs as necessary to reach the endpoint. That means one packet per TTL. Remember what I said about links flapping? There is no guarantee that any two packets will or even should go the same route, for any number of reasons, some potentially even legitimate. In some situations you may see different hops between hosts that aren't actually even physically connected!

And I love MTR, but it can handle some of these issues really... interestingly. I seem to semi-regularly see it in a state where it's showing a bunch of packet drops, but really I just have to refresh the display because some state or another got desynchronized.

That said, on simple paths that don't change a whole lot, it's great. A very clever way to expose information you might not otherwise ordinarily have that might even be key to resolving any given issue. You just have to remember just how surprisingly much of networking is made up.

[Suppafly]

>Not only is it contingent on your intermediaries actually responding to your packet with the diagnostic information you want, it assumes that the diagnostic response will also be able to get back to you.

Isn't most of the diagnostic information just stuff that's part of TCP/IP anyway?

[FxChiP]

The diagnostic information is really two things: (1) whether you get the packet back to begin with and (2) where it comes from and the ICMP state, which, yeah, is stuff that's part of IP anyway. The point was that the response is also a packet, and subject to all the same potential issues as the packet it's responding to.

[Suppafly]

>The point was that the response is also a packet

Sure, which is why it's useful. If the response doesn't get back it's not a reliable route. It seems like you're saying tracert is bad because of some sort of circular reasoning where you've decided it's bad so it's bad.

[FxChiP]

> If the response doesn't get back it's not a reliable route.

It's not a reliable route specifically for the response packet from the intermediary to the original host -- and that might be because it gets routed out the wrong interface. It could also be because the intermediary doesn't send anything at all (which would therefore mean nothing about the validity of the route either way).

> It seems like you're saying tracert is bad because of some sort of circular reasoning where you've decided it's bad so it's bad.

I didn't even say tracert was bad. I even said on simple, straightforward routes where everything cooperates and everything aligns properly, it's great. There are just lots of external factors to keep in mind that have nothing to do with the end user that might inadvertently affect its usefulness.