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!