I started to use MTR as my traceroute app and have never looked back.

thank you for this, i could have used this earlier debugging wireguard config. i have never heard of this tool before and it's phenomenal

(MTR is “my traceroute,” for the unfamiliar.)

I thought it was "Matt's Traceroute"

edit, I guess not anymore

I hope this makes a difference - traceroute was invaluable when I first started working in networked environments, but over time, it's become effectively useless because it just reports "* * *" after the first couple of hops. I always assumed that was because of network security policies, but maybe it was just timing out the whole time.

You might have better results if you use different traceroute options (e.g. --tcp on Linux, which uses TCP SYN for probes) or other traceroute-like programs (e.g. lft, paris-traceroute, mtr)

I think it’s often due to people using private IP addresses for intermediate nodes, to save on ipv4 addresses.

mtr will keep going after hitting a blackhole in the middle.

In linux you can already speed up traceroute with the -w argument to limit how long it waits for responses. Eg traceroute -w 2 8.8.8.8

What does the (8) mean?

It's one of these mystery numbers:

    $ man printf
    [goddammit you stupid computer]
    $ man 3 printf

Hey, not the computer's fault that you didn't remember to ask for libc instead of the shell command:) (Although I kinda like whatever SUSE did to make it interactive prompt whenever the manual section is ambiguous)

It references the BSD manual section where you can find the documentation.

1 General commands

2 Syscalls

3 Library functions

4 Kernel interfaces

5 File formats

6 Games

7 Misc

8 System commands

9 kernel dev

[ EDIT: I have no idea how to make a single-spaced numbered list here.. ]

> I have no idea how to make a single-spaced numbered list here

Two spaces at the beginning of each line. This will also make the text monospaced, which you may not always want.

Others have answered what the 8 means, you might also want to know why it's used, since it may be "obvious" that traceroute is a system utility. In many cases it's not obvious whether one is referring to the syscall, kernel API, system utility, etc, since overloading a single simple word is quite common.

    man 8 traceroute

8 is section number for this man page.

Quoting the manual section number is common practice in the OpenBSD project and community. It is used quite heavily in the documentation and on the mailing lists.

Manual section 8 - “System Manager” commands.

see man(1) :)

It sounds like a good change but it's worth thinking about how this changes what traceroute actually does. I wonder if any significant amount of network infrastructure will respond differently to getting a bunch of probes with different TTLs all at once?

(I've long since switched to MTR for most uses. It's different than traceroute in lots of ways and is noticeable.)

This is the kind of thing that keeps me running OpenBSD-current - super excited to see this in snaps! Awesome work!

And here is the commit https://github.com/openbsd/src/commit/21b3e8786537fe05ba6f42...

Part of the reason I have a huge crash on OpenBSD is that nothing is ever done and dusted, but in constant evolution -- without breaking the universe.

why dont you just issue all the ttls concurrently?

You don't know how many hops there are, so it would mean guessing beforehand, or using a big default (like 64) which means a ton of unnecessary packets for the average route.

Possible solution: binary search to find the number of hops (buffering intermediate responses so that you don't have to re-send them), and send all missing TTLs in parallel once you've determined the number of hops to use.

You could do a linear scan in parallel with the binary search so that the user-facing behavior looks more or less the same as now.

(It could be that some utilities---including this one!!!---already do that. The linked article doesn't go into that level of detail and I haven't read the code.)

Knowing little about other use-cases, i would guess sending 1,2,4,8, ~12 is well within bandwidth budget for all people running traceroute.

Some bastardized version of binary search sounds reasonable for most internet targets.

You wouldn't know which packet reached its TTL just by flurry of ICMP packets received? i.e. what is the actual order of the path(s)

Shouldn't there be some way to match up an ICMP packet received to a particular probe(s) e.g. by UDP port or something else?

Tradition ("if it ain't broke...") as well as general resistance to things that may well be fads (eg github) are hallmarks of people who have been doing serous systems engineering for multiple decades.

There are also real costs to switching tools, borne a little bit by everyone in the project. What they have is obviously working okay for them at the moment.

One big cost would be changing all the documentation ... OpenBSD does that...

Git now being a 16 year old technology, might be worth looking at for some.

OpenBSD already officially mirrors the CVS repository to GitHub, and contributing patches via mailing list is substantially the same whether they’re created with CVS or with Git. In other words, Git users already use Git to work on OpenBSD.

And before that, SVN was already considered a straight upgrade from CVS, and that's 21 years old.

AFAIK, net, free, and open BSD are all in various stages of looking. They'll get there:)

Isn’t OpenBSD reimplementing git so they could use it instead of CVS?

http://gameoftrees.org/