Bug 176587 - New traceroute (was: ICMP support vanished)
New traceroute (was: ICMP support vanished)
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: traceroute (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Martin Bacovsky
:
: 190092 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-12-27 02:20 EST by Kaj J. Niemi
Modified: 2007-11-30 17:11 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-10-20 09:30:03 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Inofficial patch by upstream maintainer for ICMPv4 support (18.81 KB, patch)
2006-07-19 17:21 EDT, Robert Scheck
no flags Details | Diff
Fixed patch (add it after patch0 into FC5's rpm spec) (18.81 KB, patch)
2006-09-21 10:18 EDT, Dmitry Butskoy
no flags Details | Diff

  None (edit)
Description Kaj J. Niemi 2005-12-27 02:20:23 EST
Description of problem:
traceroute does not seem to support the '-I' option anymore. This was a nice
feature considering not everyone permitted high udp ports but still permitted
some ICMP.

Version-Release number of selected component (if applicable):
traceroute-1.0.3-5.1.i386

How reproducible:
Always
Comment 1 Radek Vokal 2005-12-29 04:59:20 EST
Well, there was an announce about new traceroute package which doesn't have this
feature. Nobody complained at that time ... I will try to look at it later and
at this option.
Comment 2 Kaj J. Niemi 2006-01-05 01:43:22 EST
A case of "didn't you read the memo", then ;-) Must have missed it completely.
Comment 3 Radek Vokal 2006-04-28 02:06:24 EDT
*** Bug 190092 has been marked as a duplicate of this bug. ***
Comment 4 Peter Bieringer 2006-05-15 02:36:57 EDT
First, I also really miss this feature.

Second, I would like to see this feature also for IPv6, FC4 traceroute6 hasn't
support this at all. So one has reimplement this feature for both protocols.
Comment 5 Robert Scheck 2006-06-14 10:51:06 EDT
Olaf (upstream maintainer of the traceroute replacement) sent me a few minutes 
ago a test version including ICMPv4 support. Guessing, ICMPv6 will follow not so 
far. BUT: ICMP support requires a +s for normal users, again...

I'm not very conform with the whole stuff, but isn't bug #176588 a duplicate of 
this report?
Comment 6 Peter Bieringer 2006-06-14 19:07:26 EDT
Why do not add a "fallback" that in case option "use ICMP" instead of "use UDP"
is used and user has not the capability (because of missing u+s), a
notice/warning is displayed?

I have no problems by preventing users to use ICMP-traceroute but keep the
support for root users.
Comment 7 Jason Haar 2006-07-16 20:20:56 EDT
Another "me too". 

I feel ICMP support is too important to drop. For one thing, Cisco and Microsoft
traceroute default to ICMP instead of UDP, so there is an inconsistancy there
("why doesn't my Fedora box produce the same results as my XP box?"). Secondly,
it is normal for most firewalls and DMZ to block UDP altogether - but most still
allow ICMP echo. 

i.e. ICMP-base traceroute works in many more situations than UDP-based does

As far as the setuid goes, was that actually an issue? If so, can't it be done
some other way, or at the very least, allow root to use it. I for one find
myself mainly using traceroute as root anyway (as you tend to be diagnosing a
problem, so root tends to be who you are)
Comment 8 Robert Scheck 2006-07-19 17:21:37 EDT
Created attachment 132707 [details]
Inofficial patch by upstream maintainer for ICMPv4 support

Feel free to test it, but bugs, problems and patches regarding this also
should be upstreamed as this patch was worked out by Olaf. Maybe somebody
of the Fedora folks is able to contribute ICMPv6 support? ;-)
Comment 9 Dmitry Butskoy 2006-09-21 08:46:20 EDT
The patch above uses '-i' for icmp (whereas upstream uses '-I' for iface selecting).
In Fedora it should be changed to '-I' (as well upstreams '-I' was changed to
'-i' in the Fedora's rpm already :) )

BTW, what was a reason to replace old BSD-licensed traceroute-1.4a12 to new
GPL-ed 1.0.4, with lack of the some wide-used features? Why it was not mentioned
in FC5's ReleaseNotes?

You do not represent as unpleasantly at the emergency decision of network
problems to unexpectedly find out, that traceroute does not work any more. :(((

IMHO the icmp patch (with '-i'/'-I' swapping) should be included at least for
upcoming FC6. Even without IPv6 support (just print something to stderr on it).
The "absence of universality" cannot excuse to do nothing and leave the utility
in the actually castrated kind.
Comment 10 Roy-Magne Mo 2006-09-21 09:34:23 EDT
I've used mtr instead for diagnosing these problems since the ICMP-support
vanished from traceroute. Works for me :) 
Comment 11 Dmitry Butskoy 2006-09-21 09:47:55 EDT
For comment #10:

"mtr" is GUI/TUI-focused application, not a cmdline tool.

> Works for me :) 
How exactly do you use "mtr" to obtain information similar to "traceroute -I"
output?



Comment 12 Roy-Magne Mo 2006-09-21 09:55:30 EDT
(In reply to comment #11)
> For comment #10:
> 
> "mtr" is GUI/TUI-focused application, not a cmdline tool.
> 
> > Works for me :) 
> How exactly do you use "mtr" to obtain information similar to "traceroute -I"
> output?

for example: 
mtr --report www.redhat.com

mtr is a command line application too

Comment 13 Dmitry Butskoy 2006-09-21 10:02:00 EDT
> for example: 
> mtr --report www.redhat.com
It seems to be similar to ping (prints some statistics). But what about
"traceroute -I" exactly?

> mtr is a command line application too
Nope. Not all the features of mtr are usable by command line.
Comment 14 Dmitry Butskoy 2006-09-21 10:18:17 EDT
Created attachment 136854 [details]
Fixed patch (add it after patch0 into FC5's rpm spec)

The same patch as above, but '-i'/'-I' swapped for Fedora way.

Note, that '-I' is not described yet in the man page...
Comment 15 Robert Scheck 2006-09-21 10:26:33 EDT
Did somebody test the patch carefully? And is somebody able to port this patch 
for the IPv6 version? If yes, please sent upstream :)
Comment 16 Dmitry Butskoy 2006-09-21 11:08:10 EDT
for comment #15:
Could you contact Olaf -- maybe he has some work done since the patch was sent
to you?

> And is somebody able to port this patch for the IPv6 version?
I can, but I'm busy :) Maybe if nobody else.
And if our employer will not decide to go from Fedora away, because of a lot of
such an ugly issues last time. :(
Comment 17 Dmitry Butskoy 2006-09-25 12:27:28 EDT
>> And is somebody able to port this patch for the IPv6 version?
>I can, but I'm busy :) Maybe if nobody else.
It seems to be not so easy...

Instead, I get the ready traceroute6 implementation from *bsd systems (it was
ported there by KAME project).

There is a source rpm package, which contain both the sources -- the old
Fedora's one and BSD's traceroute6, ported to Linux:

SRPM: http://dmitry.butskoy.name/traceroute-icmp/traceroute-icmp-1.4a12-26.src.rpm
SPEC file: http://dmitry.butskoy.name/traceroute-icmp/traceroute-icmp.spec

You must remove current "traceroute-1.0.4" before install it, as it surely
"conflicts" with it.

Comment 18 Martin Bacovsky 2006-09-26 03:35:51 EDT
I asked Olaf whether he will support ICMP and/or ICMP6 in upstream and how far
he is with implementation. According to his message I can decide what to do. I
can try to do ICMP6 support if it will be needed.

On the other hand I'm afraid that ICMP support does require suid set. That is
what we wanted to avoid by migrating to Olaf's upstream. Maybe allowing ICMP
just when traceroute run as superuser would be sufficient.

I'll keep you informed :)

Comment 19 Dmitry Butskoy 2006-09-26 10:25:49 EDT
> I asked Olaf whether he will support ICMP and/or ICMP6 in upstream
BTW, the BSD's implementation might be a good hint for him :)

> I can try to do ICMP6 support if it will be needed.
It seems that both icmp/icmp6 should be re-created from the scratch. The patch
present above (an upstream's one) is not very optimal. It uses *too raw* :)
socket with IP header included, etc.etc. As at least under kernel 2.6 the raw
sockets support connect(2) and IP_RECVERR (as well ordinary udp socks),
therefore an adding of the icmp support, even icmp6, can be easier.

> On the other hand I'm afraid that ICMP support does require suid set. That is
> what we wanted to avoid by migrating to Olaf's upstream. Maybe allowing ICMP
> just when traceroute run as superuser would be sufficient.
Well,
Just do nothing with it. Under root icmp will work anyway.
If someone want the icmp support for unprivileged users (IMO too rare case),
then he/she can just do "chmod u+s" (As well as for procmail now).


Comment 20 Dmitry Butskoy 2006-09-26 13:15:31 EDT
Also some remarks:

This traceroute tries to send all packets at the same time (or something
similar) -- to provide more fast results. But IMHO it leads to some strange effects.

Consider these two outputs of traceroute of some powered off host:

Old traceroute:
[root@net ~]# traceroute 194.85.96.35
traceroute to 194.85.96.35 (194.85.96.35), 30 hops max, 38 byte packets
 1  asn (194.85.101.190)  0.563 ms  0.437 ms  0.403 ms
 2  filter.stu.neva.ru (194.85.4.8)  0.600 ms  0.536 ms  0.529 ms
 3  filter.stu.neva.ru (194.85.4.8)  3002.852 ms !H  3002.627 ms !H  3003.724 ms !H

New traceroute:
[root@net ~]# ./traceroute 194.85.96.35
traceroute to 194.85.96.35 (194.85.96.35), 30 hops max, 40 byte packets
 1  asn.odu.neva.ru (194.85.101.190)  0.106 ms   0.080 ms   0.078 ms
 2  filter.stu.neva.ru (194.85.4.8)  0.286 ms   0.288 ms   0.277 ms
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  filter.stu.neva.ru (194.85.4.8)(H!)  2946.723 ms (H!)  2942.764 ms (H!) 
2938.780 ms

First of all, it uses "H!" instead of old "!H", and second, it reports the 3th
powered-off hop as 8 ... 

It means the assumption that an error will be returned to its "own" socket is
incorrect. IP_RECVERR'ed packet should be inspected to get right seq/dst_port etc...
Comment 21 Dmitry Butskoy 2006-09-27 11:36:31 EDT
Heh...

Try "traceroute -q 7  some_address". Very interesting results (certainly if it
not segfaults immediately :) ).

'-q' allows to change number of retries (default is 3). The hard-coded maximum
is 6, but the option's value is not checked at all.


Martin,
Surely it was a good idea to have a traceroute without setuid need. But this
implementation seems to be some pre-beta version, not applicable in production
environments. Sadly :(

According to RHEL5b1 iso images, it will be included in RHEL5. I say:
<sarcasm>Good luck with RHEL customers!</sarcasm> ;)


Maybe return the old traceroute back? At least for a while?


Comment 22 Dmitry Butskoy 2006-10-01 14:48:36 EDT
Well.
I've written my own implementation "from the scratch".

Both ipv4/ipv6 for udp/icmp .

I'll publish the source tomorrow (after some pre-publish cleanups etc.)

It seems that it even will support tcp tracerouting too :)

(The today's snapshot is available at
http://dmitry.butskoy.name/traceroute/traceroute-1.9.0.tar.gz )

Bye.
Comment 23 Robert Scheck 2006-10-01 16:32:39 EDT
Dmitry...could you add IDN support like in Olafs traceroute, too?
Comment 24 Dmitry Butskoy 2006-10-02 08:45:13 EDT
Of course! Just a moment... :)
Comment 25 Dmitry Butskoy 2006-10-02 10:50:23 EDT
The next snapshot: http://dmitry.butskoy.name/traceroute/traceroute-1.9.1.tar.gz 
)

Now TCP tracing seems to work for both ipv4/ipv6. Unfortunately, traceroute
using TCP requires root privileges too (no other way to obtain icmp errors
without icmp raw socket). Only UDP method is allowed for non-root users.

AI_IDN added.

I'm working further. Please, test all the udp/icmp/tcp under ipv4/ipv6 (i.e. 6
variants).
Hint: a good host for ipv6 tests is "mobile-ipv6.org" ...


Comment 26 Dmitry Butskoy 2006-10-02 13:32:08 EDT
`-g' support added.

Could anyone test it? (i.e., whether still exist anywhere routers  which allow
source routing? :) )

http://dmitry.butskoy.name/traceroute/traceroute-1.9.2.tar.gz 
Comment 27 Peter Bieringer 2006-10-03 06:04:40 EDT
First, looking very well!

Could you please add support for options "-h" and "?"

# ./traceroute-1.9.2/traceroute/traceroute -h
Bad option `-h' (argc 1)
# ./traceroute-1.9.2/traceroute/traceroute -?
Bad option `-?' (argc 1)

On -T it would be nice if destination port can be displayed and also the type.

Currently:
traceroute to www.bieringer.de (2001:a60:9002:1::186:3), 30 hops max, 40 byte
packets

Suggestion:
traceroute to www.bieringer.de (2001:a60:9002:1::186:3), 30 hops max, 40 byte
packets, using ICMP-ECHO|UDP to port <port> and upper|TCP to port <port>

Typo in help:

probe, defailt is 33434), for the ICMP seq number
s/defailt/default/

Another suggestion: add a option for specifying payload size like in ping to
check, if packets going lost with or without notification from the router
inbetween. This would help to detect buggy tunnels (or tunnels in tunnels).
If implemented, should be supported for ICMP, UDP and TCP.

And the next one: could you add an option to specify the flowlabel value? Can
help, if policy routing depending on flow labels will be used (sometimes in the
future...).

Can you catch this error and display a suggestion like: "you have to be
superuser to execute traceroute with this option"?
$ LANG=C ./traceroute/traceroute-1.9.2/traceroute/traceroute -T -6 www.bieringer.de
socket: Operation not permitted

Comment 28 Robert Scheck 2006-10-03 06:29:33 EDT
(In reply to comment #25)
> AI_IDN added.

but reverse way is not available (IPv4|IPv6 -> Hostname) yet, which requires 
NI_IDN at getnameinfo() like in Olaf's traceroute.

Hm and when tracerouting google.de (hop 7 and 8 are looking strange, but maybe 
correct?):
 5  72.14.232.208 (72.14.232.208)  7,811 ms  7,779 ms  7,728 ms
 6  72.14.232.141 (72.14.232.141)  20,355 ms  14,665 ms  14,618 ms
 7  72.14.233.77 (72.14.233.77)  14,550 ms 72.14.233.79 (72.14.233.79)  14,477 
ms 72.14.233.79 (72.14.233.79)  14,422 ms
 8  66.249.94.54 (66.249.94.54)  187,377 ms  187,341 ms 66.249.94.46 (66.249.94.
46)  14,259 ms
 9  66.249.93.104 (66.249.93.104)  14,204 ms  13,027 ms  12,986 ms

Even I'm a German, it's strange to me to see commas instead of dots above...
Comment 29 Robert Scheck 2006-10-03 06:34:46 EDT
Ha and are there any plans to do AS path lookups like at ftp://ftp.login.com/
pub/software/traceroute/? If yes, could kick another traceroute clone from my 
system... :)
Comment 30 Dmitry Butskoy 2006-10-03 12:55:19 EDT
> Could you please add support for options "-h" and "?"
Surely, but I'm doubt a little.

First, there is already "--help" option. (It seems to be a gnu standard...)
Second, AFAIK there is no traceroute implementations which use "-h".
But if you insist, I'll implement it :)

> Suggestion:
> traceroute to www.bieringer.de (2001:a60:9002:1::186:3), 30 hops max, 40 byte
> packets, using ICMP-ECHO|UDP to port <port> and upper|TCP to port <port>
It is a good idea.
But "traditional" traceroute (which was 1.4a12 before FC5) does not mention this
in its header. Are any compatibility issues possible here?

> s/defailt/default/
done.

> Another suggestion: add a option for specifying payload size like in ping to
> check, if packets going lost with or without notification from the router
> inbetween.
Could you point me the particular place in the ping's code?

> option to specify the flowlabel value
done. I choose "-l" for it.
(Currently it seems to be not works together with "-g" ...)

> display a suggestion like: "you have to be superuser to execute traceroute
> with this option"
done

> NI_IDN at getnameinfo()
done

> Hm and when tracerouting google.de, hop 7 and 8 are looking strange
For me too.  Even with another traceroutes ;)

> commas instead of dots
IMHO it was inspired by using setlocale() call. I comment out it, because
(atleast now) there is no actual locale support for this program.

> to do AS path lookups like at ftp://ftp.login.com/pub/software/traceroute/?
It was a hint? :)
Add to TODO list. Think about it later.


* add manual (please check it)
* add .spec file

New version: http://dmitry.butskoy.name/traceroute/traceroute-1.9.3.tar.gz



Comment 31 Robert Scheck 2006-10-03 17:07:05 EDT
Ripping out setlocale() broke IDN support - guess, it's better to live with 
commas, but having the IDN support. Unfortunately, I'm not able to figure out, 
how Olaf solved this small thing.

$ ./traceroute dänic.de
dänic.de: Parameter string not correctly encoded
Cannot handle "host" cmdline arg `dänic.de' on position 1 (argc 1)
$ 

Beside of AS path lookups, are all (or even most) features from tcptraceroute 
added? Would be very interesting to have a traceroute for *everything* instead 
having 3 or more traceroutes :)

Regarding the name you asked on fedora-devel-list list, personally I would 
suggest simply "traceroute". And SourceForge or Berlios could be a nice home
for your project, of course.
Comment 32 Dmitry Butskoy 2006-10-04 12:59:37 EDT
> it's better to live with commas, but having the IDN support.
The reason of commas is Olaf used for the time "%d.%d" format with two integers,
I use "%.3f" format and the double value. And your locale uses "," as a float
point...

Fixed, using setlocale (LC_NUMERIC, "C"). Check it out now.

> are all (or even most) features from tcptraceroute added?
Surely not all, as not all features are practically claimed. What particularly
features you would like to add?

* add AS path lookups support (`-A' option).
* some cleanups.

New version SRPM: http://dmitry.butskoy.name/traceroute/traceroute-1.9.4-1.src.rpm



Comment 33 Dmitry Butskoy 2006-10-05 13:37:15 EDT
Some more cleanups.

New version SRPM: http://dmitry.butskoy.name/traceroute/traceroute-1.9.5-1.src.rpm
Comment 34 Peter Bieringer 2006-10-05 14:04:20 EDT
Thank you for implementing the packetlen, looks like there is a CRLF missing
somewhere:

# traceroute -F -I www.bieringer.de 1492
sendto: Message too long
[root@server ~]# bieringer.de (212.18.21.186), 30 hops max, 1492 byte
packets[root@server ~]#


BTW: I doubt whether it was a good idea to implement the packetlen
parameter...it currently works only for ICMP and UDP (seems to me that for TCP
it is not possible).

BTW2: can you check whether traceroute proper catch packet-too-big?

It looks like if packet is too big, it never leaves the system, but nothing
happens (and client is hanging).

straces shows me (repeating):
sendto(3, "\200\0\313\246Ch\0\2HIJKLMNOPQRSTUVWXYZ[\\]^_"..., 1288, 0,
{sa_family=AF_INET6, sin6_port=htons(0), inet_pton(AF_INET6,
"2001:a60:9002:1::186:3", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = 
1

Used command:
# traceroute -6 -N 1 -q 1 -f 6 -F  -I www.bieringer.de 1240

MTU of link is 1280
Comment 35 Peter Bieringer 2006-10-06 04:46:31 EDT
I got an additional request from a collegue:

would it be able to add an option which do not increment ports on UDP
traceroute? Would help to traceroute e.g. to port 53 and 500.
Comment 36 Dmitry Butskoy 2006-10-06 10:43:07 EDT
> looks like there is a CRLF missing somewhere
Fixed

> Thank you for implementing the packetlen
Hmmm... Actually it was already implemented in the first version. (BTW another
traceroute variants implement it too ;) ).

> whether it was a good idea to implement the packetlen parameter
Anyway, it must be implemented for compatibility with the original traceroute.
And IMO this is a good feature.
> for TCP it is not possible
Yep. Seems to me that i should mention it in the manual.

> It looks like if packet is too big, it never leaves the system, but nothing
> happens (and client is hanging).
>
># traceroute -6 -N 1 -q 1 -f 6 -F  -I www.bieringer.de 1240
>
>MTU of link is 1280

I've browsed the current kernel's code (2.6.17) and have found that '-F' for
IPv6 just takes no effect. It seems that now the kernel always fragments IPv6
packets... Perhaps it will be changed in the future.
Our provider's routers answer for fragmented udp but ignore fragmented
icmp-echo. IMO in your case too (and you should see '*' if wait some more time).

> would it be able to add an option which do not increment ports on UDP
> traceroute? Would help to traceroute e.g. to port 53 and 500.
Good idea, I already thought of it. Will add to TODO list. (BTW, what a good
option name for this?)


Comment 37 Dmitry Butskoy 2006-10-07 12:51:12 EDT
New version SRPM: http://dmitry.butskoy.name/traceroute/traceroute-1.9.6-1.src.rpm

* add "-z sendpause" option
* some cleanups
Comment 38 Dmitry Butskoy 2006-10-11 11:25:04 EDT
New version SRPM: http://dmitry.butskoy.name/traceroute/traceroute-1.9.7-1.src.rpm

* handle situations when the final hop drops some packets (when too bug `-N' value)
* some more cleanups.

I consider this version as 2.0rc . No more new features for a while.
 


Comment 39 Dmitry Butskoy 2006-10-16 11:25:09 EDT
Assume the final one:
http://dmitry.butskoy.name/traceroute/traceroute-2.0.0-1.src.rpm
Comment 40 Martin Bacovsky 2006-10-20 09:30:03 EDT
I would like to thank Dmitry for his work. Traceroute 2.0.0 is now commited in
devel as well as in RHEL5. It was a bit too late for FC6 but it will appear in
update 0. FC5 will be updated too.
Comment 41 Dmitry Butskoy 2007-08-06 13:45:28 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.