Bug 217974 - /bin/tcptraceroute symlink occludes alternate tcptraceroute package
/bin/tcptraceroute symlink occludes alternate tcptraceroute package
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: traceroute (Show other bugs)
6
All Linux
medium Severity medium
: ---
: ---
Assigned To: Martin Bacovsky
:
Depends On:
Blocks: 223795
  Show dependency treegraph
 
Reported: 2006-11-30 18:00 EST by James Ralston
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version: traceroute-2.0.3-1.fc6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-01-29 11:24:36 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description James Ralston 2006-11-30 18:00:05 EST
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.)
Comment 1 Dmitry Butskoy 2006-12-04 08:33:40 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?
Comment 2 James Ralston 2006-12-11 16:45:00 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...)
Comment 3 Martin Bacovsky 2007-01-29 11:24:36 EST
This issue should be fixed in traceroute-2.0.3-1.fc6. Thanks to Dmitry for fix.
Comment 4 Dmitry Butskoy 2007-08-06 13:47:31 EDT
The project now is hosted at SourceForge:
http://traceroute.sourceforge.net

Some discussions about further development steps are planned. Please, subscribe
to traceroute-devel list:
https://lists.sourceforge.net/lists/listinfo/traceroute-devel

Note You need to log in before you can comment on or make changes to this bug.