Bug 217974

Summary: /bin/tcptraceroute symlink occludes alternate tcptraceroute package
Product: [Fedora] Fedora Reporter: James Ralston <ralston>
Component: tracerouteAssignee: Martin Bacovsky <mbacovsk>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 6CC: dmitry, redhat-bugzilla
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
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 16:24:36 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 223795    

Description James Ralston 2006-11-30 23:00:05 UTC
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 13:33:40 UTC
> 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 21:45:00 UTC
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 16:24:36 UTC
This issue should be fixed in traceroute-2.0.3-1.fc6. Thanks to Dmitry for fix.

Comment 4 Dmitry Butskoy 2007-08-06 17:47:31 UTC
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