Bug 733030 - Drop tcptraceroute due to good tcp support in the ordinary traceroute
Summary: Drop tcptraceroute due to good tcp support in the ordinary traceroute
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: tcptraceroute
Version: rawhide
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Adam Miller
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-08-24 14:29 UTC by Dmitry Butskoy
Modified: 2013-05-16 11:32 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-11-01 17:48:43 UTC


Attachments (Terms of Use)

Description Dmitry Butskoy 2011-08-24 14:29:41 UTC
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...

Comment 1 Dmitry Butskoy 2011-09-19 13:25:20 UTC
ping.

Comment 2 Dmitry Butskoy 2011-10-27 13:34:47 UTC
Ping!

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...

Comment 3 Adam Miller 2011-11-01 17:28:27 UTC
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.

-AdamM

Comment 5 Dmitry Butskoy 2011-11-02 13:07:39 UTC
Thanks.

I sent emails on tcptraceroute-owner@fedoraproject.org, maxamillion@fedoraproject.org and maxamillion@gmail.com .
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?

My thoughts:

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 ).

Comment 6 Karel Volný 2013-05-14 19:07:01 UTC
curse on you!!! => bug #962913

btw,

(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 ...

Comment 7 Dmitry Butskoy 2013-05-16 11:32:39 UTC
Well,

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

or:

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).


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