The ordinary traceroute ("new epoch" traceroute for Linux, in Fedora and other distros since 2006) has good support for tcp tracerouting as well from its born days.
Main benefits for "traceroute -T" against tcptraceroute are:
- it is faster
- full support of IPv6
- a lot of other modern features, etc.
- tcptraceroute upstream is stopped years ago.
I am upstream maintainer (and initial author) of traceroute for Linux.
I provide a wrapper (in the source tarball) for tcptraceroute-->"traceroute -T".
This wrapper handles all the option of the latest stable tcptraceroute-1.4 (2002)
(Some more options appeared in 1.5beta look a bit exotic, those things can be done by tcpdump) The output is the same, except the slightly different header (my implementation always uses standard one).
In the new traceroute version of 2.0.18 I've implemented the "last" thing which should be done to completely win -- the ability to print the "status" of the remote tcp end (whether the port is listen or not). This output is slightly different too -- instead of dumb "open/closed" words I just print the tcp flags exactly ("syn,ack", "rst,ack" etc.)
For now, it seems to me that it would be good time to drop the upstream-stopped tcptraceroute package from Fedora, and provide for compatibility a wrapper for it in the ordinary traceroute package (which I maintain in Fedora as well).
If you agree, maybe just orphan this package, then I get it and perform all the other work...
I see you in at least in fedora-devel maillist, but cannot reach you by e-mail during 2 month. Perhaps some country-wide spamfilters...
Apologies, I've been a little sparse in my activities in Fedora lately due to outside factors.
I'll begin the process to retire the package by the end of the day.
It has been retired in fedora git and fedora pkgdb
I sent emails on firstname.lastname@example.org, email@example.com and firstname.lastname@example.org .
Probably some country-wide filters are in effect (sometimes some mailadmins drop all ".ru", ".jp" etc. domains at all :( ). But it seems that bugzilla report and "*-owner" should not be affected by this. :/
While you are here -- what could you say about the similar change for EPEL6?
RHEL6 has traceroute-2.0.14, which is capable to emulate tcptraceroute as well, except the "final status" (whether the target host has the port open or closed).
The printing of the "final status" looks like an extra thing for me (in a strong term of "trace routing"), but some people could get used to it. Unfortunately, I cannot update the base RHEL package, and it seems that the RH policy is to preserve the version of 2.0.14 for the whole period og RHEL6 (as 2.0.3 for RHEL5). Hence the cost of "fast and IPv6 support and etc." is the lack of info about the port status.
Besides that, we cannot simple drop tcptraceroute from EPEL6 -- I don't believe that RH add the wrapper to the "base" traceroute package. Hence, the wrapper should go to the epel6's tcptraceroute as a new source for it (until RHEL7 ).
curse on you!!! => bug #962913
(In reply to comment #0)
> - a lot of other modern features, etc.
it used to be a good habit to elaborate on such bold statements ... but what could I expect from someone who is so eager to kill any competition :-( ... does tcptraceroute block the users from using "tcptraceroute -T"? - no, so what the hell is the reason to remove it if it ain't broken? there are tons of packages in Fedora with "dead" upstreams (I have two of them on my list) yet nobody yells they should be removed ...
new tcptraceroute does not block ordinary users itself.
Please, consider the tcptraceroute in the other distro (or in the previous Fedora releases). What about setuid bit?
AFAIK the RH policy is to decrease (agressively) the amount of utilities requiring setuid. This way new traceroute is not "setuid root".
If you want to allow some users (who has no rights to sudo etc.) to utilize "traceroute -T", as well as "traceroute -I" (icmp), just do either:
chmod o+s /usr/bin/traceroute
setcap cap_net_raw=pe /usr/bin/traceroute
By default, the ordinary user can perform only "traditional udp traceroute method". (It is not my choice, it was chosen by RH in the previous implementation some yaers ago). Hence, icmp and tcp is allowed for root only.
Since the kernel-3.0, a possibility have appeared to utilize icmp (-I) as well, but currently for IPv4 only and it requires some special support from distro (still not in Fedora).
Note, that old tcptraceroute, besides the stopped upstream, support IPv4 only (the current RH/fedora policy is to support both IPv4/IPv6 in the same utility). If you want to do some sort of come back, please, use the binary (or copy of the binary) of the new traceroute (it even should choose "-T" when called staring "tcp...", but with own options set).