Bug 223795

+++ This bug was initially created as a clone of Bug #217974 +++

traceroute-2.0.2-1.fc6 includes the symbolic link /bin/tcptraceroute -> traceroute.

However, there is alternate tcptraceroute program, which installs in /usr/bin by
default:

http://michael.toren.net/code/tcptraceroute/

The /bin/tcptraceroute symlink occludes the /usr/bin/tcptraceroute binary.  This
is unnecessary, as the TCP tracerouting can be selected with traceroute-2.0.2
merely by usign the "-T" option.  Please remove the symlink.

(IMHO, Michael Toren's tcptraceroute implementation is a far superior TCP-based
tracerouting tool, as it uses the same half-open scanning technique that "nmap
-sS" does, plus it supports the selective use of ECN, which is extremely handy
for identifying sites that break on ECN traffic.  But these features rely on
being able to construct raw packets (via the libnet package), which requires
setuid-root for regular users.  So even though Michael Toren's tcptraceroute
implementation is licensed under the GPL, I don't expect traceroute-2.0.2 to
acquire those features anytime soon.)

-- Additional comment from dmitry on 2006-12-04 08:33 EST --
> there is alternate tcptraceroute program, which installs in /usr/bin by
> default
Nope.
Both 1.4 and 1.5beta7 installs under /usr/local by default (just untar,
configure, make and see "make -n install" output).
Normally /usr/local/bin takes precedence over /bin (see "echo $PATH" output).

But certainly there are some rpm packages (at the upstream site and in the Dries
RPM Repository) which place it in /usr/bin

> Please remove the symlink.
Well, it sounds reasonable.

The reason for this symlink was to satisfy some users who wanted to switch from
several different traceroute implementations to the newest one. Since there is
no any "tcptraceroute" in Extras or some another wide-used repos, it seemed
applicable...

Martin,
I think we should drop /bin/tcptraceroute symlink (just in rawhide/cvs, an extra
update is not needed for this). The solution for currently affected users is "rm
-f /bin/tcptraceroute" (just for those who install it as rpm package, pure
tarball users are unaffected).


> to acquire those features anytime soon
Why are not? ;)

We have a plan to support "generic IP' tracerouting with selective probe-package
construction (perhaps using plugins too). It seems that most of the
tcptraceroute's features could be supported such way.

James,
Since you have appeared here :), I would like to ask you:
- What features of the "original tcptraceroute" are practically useful for you?
- Could you comment our TODO list (from the source tarball)? Maybe add something
more for it?


-- Additional comment from ralston on 2006-12-11 16:45 EST --
If you plan on supporting selective probe-package construction, then yes; you'll
certainly be able to implement tcptraceroute's features.

The two main features of tcptraceroute I want are:

1.  The ability to abort the SYN/SYN+ACK/ACK 3-way handshake (by issuing a RST
instead of the final ACK).  That way, the TCP connection is never established,
so there is no chance that a daemon will be launched to handle the connection. 
(This is important, because not all daemons react gracefully to clients that
connect and then immediately disconnect without saying anything, and running
traceroute should not perturb the target in any way.)

2.  The ability to selectively enable ECN.  (I use this all the time to detect
sites that have broken routers that drop ECN-enabled traffic.)

Honestly, while I'm grateful to Michael Toren for writing tcptraceroute, it's
pretty clear he's not actively developing it anymore.  I'd much rather see a
"canonical" traceroute program that has the important features of all the
various scattered traceroute implementations/forks that have sprung up over the
years, and I'll provide whatever assistance I can if that's your goal as well.

(I skimmed the TODO; I can't think of any further comments at the moment...)