Hi. Author of the original tcptraceroute here.

I first wrote tcptraceroute is 2001, while I was working for a large Mid-Atlantic NSP. I'd routinely see customers (and our NOC staff) reporting that traceroutes to many popular sites (such as ebay.com, microsoft.com, etc) were broken, and wondering if their connectivity was somehow defective. I would have to explain (again) how traceroute worked, and how the probe packets it uses are now (sadly) routinely firewalled, thus breaking our diagnostic tools.

At one point, the idea struck me that there was no reason we couldn't use any type of packet as a probe packet for traceroute -- including packets that firewalls found permissible. After a night or two hacking with libnet and libpcap I had a working implementation. Suddenly being able to traceroute through those firewalls and see the internal network of those large networks felt magical, like having X-Ray vision. :-) Over time, I added other features that provided even greater visibility -- such as the ability to detect when some NAT/load-balancers aren't doing as good a job as they could be, and thus revealing the internal IP address you're being NAT'd to. (Have a peek at http://michael.toren.net/code/tcptraceroute/examples.txt for some example output.)

I haven't done a great job of investing time into tcptraceroute over the past few years. The code is still functional and hasn't suffered from any bitrot, but the last "beta" release was "1.5beta7", back in 2006. There's no reason it shouldn't have been released as "1.6", I just never got around to officially "releasing" it. There are also a bunch of additional features I've contemplated over the years that I'd really like to add. This thread has definitely invigorated me to put more energy into the project soon, which I'm grateful for. :-)

Tangentially, one of the annoying things about "traceroute" programs in general is that the name is very overloaded, with many unrelated projects over the years calling themselves "traceroute". Further complicating things, a brand new project called "traceroute" was started a few years ago with the stated goal of only supporting Linux, and wishing to be the one, true traceroute in all Linux distributions. That project also implemented the ability to use TCP probe packets, which is awesome. I'm glad to see that there are other implementations out there. But sadly, they're also distributing a shell script called "tcptraceroute" that invokes their traceroute program with the flag to set the probe type to TCP. In Debian, if you have the "traceroute" package installed but not the "tcptraceroute" package, typing "tcptraceroute" will invoke their traceroute program. If you instead have both the "traceroute" and "tcptraceroute" packages installed, typing "tcptraceroute" will invoke my traceroute program. As the two programs differ in other ways, this can be really annoying, and lead to the type of confusion that can be seen elsewhere in this thread. I've also received a number of messages from people asking for help with "tcptraceroute", only to have us both later figure out that they're really running the other "tcptraceroute" program, which is very frustrating for both of us.

I'm not sure what the best course of action is. I strongly believe in, and advocate, open source. I want other people to be able to look at my code, learn from it, borrow useful parts, and distribute changes. And yet, I really don't want someone distributing a program that has the same proper noun I chose years earlier for my own project. This is something I've thought about off and on over the years as I consider releasing (and naming) other open source projects, but don't yet have a good answer. I suppose one solution is to utilize trademark law, but that's something I have very mixed feelings about.

This turned into a much longer post than I intended :-), but if anyone has any thoughts, I'd love to hear them! My contact information can be found in my profile.

Thanks!