traceroute-devel — Development discussions related to Traceroute for Linux

Re: [traceroute] Strange message when cannot resolve host version 2.1.0

[COMTE G. <her...@gm...>]

Hello,

I understand your point, and agree with it, i use this traceroute because
it is part of the basic core utility, and can be found in most of linux
distribution by default.

Did not know that it is a open/close manner, :-) now i know, and will
expect this.

I figured out, that what was annoying me is not what i reported, and more
over is not related to traceroute itself:

 i output the result for the traceroute using "echo" later, hence the
backquote became an issue as it is processed by bash.

Will just take care of escaping those chars.

Many thanks for your answer, it helped me a lot to track down ... my own
issue!

Guillaume.

Le mer. 16 oct. 2024 à 05:06, Dmitry Butskoy <bu...@bu...> a écrit :

> COMTE Guillaume wrote:
>
> When doing a simple traceroute to google.com, in a host that doesnt have
> the right dns, there is a strange error output, which can be somehow
> surprising:
>
> traceroute google.com
> google.com:  Name or service not known
> Cannot handle "host" cmdline arg `google.com' on position 1 (argc 1)
>
>
> There are two error reports here. The first is from getaddr() from
> set_host(), which handles the first cmdline argument. The second is from
> the clif.c library itself. This is a common paradigm (where different code
> components react to something together).
>
> The clif library is a completely independent thing, so it knows nothing
> about what the method it calls does ("set_host"). Only the return value is
> analyzed. Therefore it cannot supress its own warning just because the
> method it called has already reported an error in its own way.
>
> Certainly more complex projects often implement different levels of
> debugging, but here such a complexity looks extra. Traceroute behaves such
> since the very first days of the project (2006) and has not caused any
> complaints for all the time. :)
>
> when the traceroute for example is embedded within a script, this output
> misleading, at first sight i was thinking it was my embedding script that
> produced the error
>
>
> Well, this practical case sounds reasonable, but I would still prefer not
> to introduce an additional level of complexity. Traceroute is designed more
> for interactive use than for scripts, so such an additional information
> when reporting an error does not seem inherently harmful. For the
> scripting... well, just use (in modern bash(1)):
>
> traceroute $hostname 2> >(grep -v cmdline)
>
>
>
> And, seems also, there is a typo in the message:
>
> Cannot handle "host" cmdline arg `google.com' on position 1 (argc 1) <= `
> google.com' <= backquote followed by a single quote.
>
>
> Nope. This is an ancient way of quoting something in an open/close manner,
> with the restriction of using only ascii characters. (You can see it in
> Linux/UNIX manuals, fe. search for "`" symbol in "man bash" output).
>
> Traceroute is a basic core utility,  so it must be completely independent
> of the presence of any localization in the system, or even unicode support
> at all. Therefore it must use ascii symbols only (so ` and '), and cannot
> use more recent unicodes “ ” or  ‘ ’ .
>
> Strange message when cannot resolve host version 2.1.0
>
>
> Please note, that the current version is 2.1.6 (with some improvements).
>
>
> Best regards,
> Dmitry Butskoy
>
>

Re: [traceroute] Strange message when cannot resolve host version 2.1.0

[Dmitry B. <bu...@bu...>]

COMTE Guillaume wrote:
> When doing a simple traceroute to google.com <http://google.com>, in a 
> host that doesnt have the right dns, there is a strange error output, 
> which can be somehow surprising:
>
> traceroute google.com <http://google.com>
> google.com <http://google.com>: Name or service not known
> Cannot handle "host" cmdline arg `google.com <http://google.com>' on 
> position 1 (argc 1)

There are two error reports here. The first is from getaddr() from 
set_host(), which handles the first cmdline argument. The second is from 
the clif.c library itself. This is a common paradigm (where different 
code components react to something together).

The clif library is a completely independent thing, so it knows nothing 
about what the method it calls does ("set_host"). Only the return value 
is analyzed. Therefore it cannot supress its own warning just because 
the method it called has already reported an error in its own way.

Certainly more complex projects often implement different levels of 
debugging, but here such a complexity looks extra. Traceroute behaves 
such since the very first days of the project (2006) and has not caused 
any complaints for all the time. :)

> when the traceroute for example is embedded within a script, this 
> output misleading, at first sight i was thinking it was my embedding 
> script that produced the error

Well, this practical case sounds reasonable, but I would still prefer 
not to introduce an additional level of complexity. Traceroute is 
designed more for interactive use than for scripts, so such an 
additional information when reporting an error does not seem inherently 
harmful. For the scripting... well, just use (in modern bash(1)):
> traceroute $hostname 2> >(grep -v cmdline)

>
> And, seems also, there is a typo in the message:
>
> Cannot handle "host" cmdline arg `google.com <http://google.com>' on 
> position 1 (argc 1) <= `google.com <http://google.com>' <= backquote 
> followed by a single quote.

Nope. This is an ancient way of quoting something in an open/close 
manner, with the restriction of using only ascii characters. (You can 
see it in Linux/UNIX manuals, fe. search for "`" symbol in "man bash" 
output).

Traceroute is a basic core utility,  so it must be completely 
independent of the presence of any localization in the system, or even 
unicode support at all. Therefore it must use ascii symbols only (so ` 
and '), and cannot use more recent unicodes “ ” or  ‘ ’ .

> Strange message when cannot resolve host version 2.1.0

Please note, that the current version is 2.1.6 (with some improvements).


Best regards,
Dmitry Butskoy

[traceroute] Strange message when cannot resolve host version 2.1.0

[COMTE G. <her...@gm...>]

When doing a simple traceroute to google.com, in a host that doesnt have
the right dns, there is a strange error output, which can be somehow
surprising:

traceroute google.com
google.com:  Name or service not known
Cannot handle "host" cmdline arg `google.com' on position 1 (argc 1)

I cannot understand why in libsupp/clif.c the static void err_report is
outputting somehow a puzzling error message, which can make think, there is
something really wrong (when the traceroute for example is embedded within
a script, this output misleading, at first sight i was thinking it was my
embedding script that produced the error)

And, seems also, there is a typo in the message:

Cannot handle "host" cmdline arg `google.com' on position 1 (argc 1) <= `
google.com' <= backquote followed by a single quote.

I will ignore this message Cannot handle "host" cmdline arg `google.com' on
position 1 (argc 1); but what is the aim of this "report", the first
statement could have been sufficient " google.com: Name or service not
known"

Regards
Guillaume.

[traceroute] How does traceroute identify the hop on the path when a specific UDP port is used?

[Marek K. <m-k...@mk...>]

Hello,

I have a question about traceroute: traceroute idendifies the hop on
the path by default at the port to which the packet was sent. However,
I can also specify the port with the option "--udp", where traceroute
then from which hop the packet comes? Furthermore, I can also use ICMP
and TCP, how does it work there?

I would be happy about an answer!

Greetings
Marek Küthe

-- 
Marek Küthe
m....@mk...
er/ihm he/him

Re: [traceroute] two feature requests: source IP without interface and using different interfaces for ingress and egress

[Dmitry B. <bu...@tu...>]

Raf...@th... wrote:
> Dear traceroute developers,
>
> I'm wondering what would be your recommendations or chances to implement features specified in the subject:
> 1. using source IP that is not bound to any existing interface.
> At the moment attempt to issue such traceroute results in bind error: "Cannot assign requested address". The easy workaround is to create interface alias but this is an extra effort
>
> 2. Using different interfaces for outgoing and incoming traffic
>
Unfortunately, both cannot be implemented due to the way how this 
traceroute works.

This traceroute does not work with "raw packets" immediately. Instead, 
it relies on the kernel to receive, prepare and inform about the reply 
packets. This way looks more secure (no own parsing of external data) 
and provides a possibility to avoid a special system privileges for some 
traceroute methods (ie. udp tracing and sometimes even icmp can be done 
without "root" privileges).

Sorry, but it seems that for your needs only tcpdump can help. (Probably 
some other software, aka hping, might help).

Regards,
Dmitry Butskoy

Re: [traceroute] two feature requests: source IP without interface and using different interfaces for ingress and egress

[<Raf...@th...>]

Apologize for duplicate e-mails. I made a list subscription to @tr.com account and after sending the first e-mail I realized the address in my From: field is @thomsonreuters.com. I haven't seen my e-mail here: https://sourceforge.net/p/traceroute/mailman/traceroute-devel/ for a couple of minutes so I assumed it must have been dropped because of mail addresses mismatch. So I cancelled subscription and made a new one for @thomsonreuters.com account and made a second attempt. After a few minutes I received both e-mails.

[traceroute] two feature requests: source IP without interface and using different interfaces for ingress and egress

[<Raf...@th...>]

Dear traceroute developers,

I'm wondering what would be your recommendations or chances to implement features specified in the subject:
1. using source IP that is not bound to any existing interface.
At the moment attempt to issue such traceroute results in bind error: "Cannot assign requested address". The easy workaround is to create interface alias but this is an extra effort

2. Using different interfaces for outgoing and incoming traffic
I can't find such option in traceroute.  I would assume it does not exist. Ideally would be to have an option to specify TX and RX interfaces. I'm not sure what would be workaround for this case, possibly creating some bridge interface but I have not tested it.
I have a use case where I need to forge the source IP but returning traffic is received only on a span port (a different one than the out interface). So at the moment I need to observe responses on a tcpdump session which is not really convenient.

Regards,
Rafał

PS
Apologize for the corporate footer, if that's an issue I can switch to my private account

________________________________

This e-mail is for the sole use of the intended recipient and contains information that may be privileged and/or confidential. If you are not an intended recipient, please notify the sender by return e-mail and delete this e-mail and any attachments. Certain required legal entity disclosures can be accessed on our website.<http://site.thomsonreuters.com/site/disclosures/>

[traceroute] two feature requests: source IP without interface and using different interfaces for ingress and egress

[<Raf...@th...>]

Dear traceroute developers,

I'm wondering what would be your recommendations or chances to implement features specified in the subject:
1. using source IP that is not bound to any existing interface.
At the moment attempt to issue such traceroute results in bind error: "Cannot assign requested address". The easy workaround is to create interface alias but this is an extra effort

2. Using different interfaces for outgoing and incoming traffic
I can't find such option in traceroute.  I would assume it does not exist. Ideally would be to have an option to specify TX and RX interfaces. I'm not sure what would be workaround for this case, possibly creating some bridge interface but I have not tested it.
I have a use case where I need to forge the source IP but returning traffic is received only on a span port (a different one than the out interface and traceroute). So at the moment I need to observe responses on tcpdump session which is not really convenient.

Regards,
Rafał

PS
Apologize for the corporate footer, if that's an issue I can switch to my private account

________________________________

This e-mail is for the sole use of the intended recipient and contains information that may be privileged and/or confidential. If you are not an intended recipient, please notify the sender by return e-mail and delete this e-mail and any attachments. Certain required legal entity disclosures can be accessed on our website.<http://site.thomsonreuters.com/site/disclosures/>

Re: [traceroute] How important is SO_RCVBUFFORCE and SO_SNDBUFFORCE (can it be denied by MAC) ?

[Vincas D. <vi...@gm...>]

2017.07.04 23:48, Dmitry Butskoy wrote:
>> and also it calls:
>>
>> setsockopt(4, SOL_SOCKET, SO_SNDBUFFORCE, [8388608], 4)
>> setsockopt(4, SOL_SOCKET, SO_RCVBUFFORCE, [8388608], 4)
> Strange. I never used it in the code.
> Probably some Ubuntu patch, or maybe it is called internally by glibc.

Thanks for your valuable input, I'll search for the truth elsewhere :-) .

Re: [traceroute] How important is SO_RCVBUFFORCE and SO_SNDBUFFORCE (can it be denied by MAC) ?

[Dmitry B. <bu...@tu...>]

Vincas Dargis wrote:
> Hi,
>
> I've discovered that traceroute on Ubuntu 17.04 requires access to:
>
> /proc/sys/net/ipv4/tcp_{ecn,sack,timestamps,window_scaling}
Yes,
it is needed for tcp tracerouting defaults (`-T').

When we create a tcp probe packet (fe. tcp_syn), we must create it the 
same way as it is created by the system.
(IOW, when users have some troubles with some tcp application, and they 
try to do tcp tracerouting to resolve issues, the trace packets must 
mautch an application behavior, else it is incorrect testing...)

The easiest and the  obvious way to obtain such defaults is to read the 
correspond /proc/sys/net/ipv4/tcp_* files.
>
> and also it calls:
>
> setsockopt(4, SOL_SOCKET, SO_SNDBUFFORCE, [8388608], 4)
> setsockopt(4, SOL_SOCKET, SO_RCVBUFFORCE, [8388608], 4)
Strange. I never used it in the code.
Probably some Ubuntu patch, or maybe it is called internally by glibc.

Regards,
Dmitry Butskoy

[traceroute] How important is SO_RCVBUFFORCE and SO_SNDBUFFORCE (can it be denied by MAC) ?

[Vincas D. <vi...@gm...>]

Hi,

I've discovered that traceroute on Ubuntu 17.04 requires access to:

/proc/sys/net/ipv4/tcp_{ecn,sack,timestamps,window_scaling}

and also it calls:

setsockopt(4, SOL_SOCKET, SO_SNDBUFFORCE, [8388608], 4)
setsockopt(4, SOL_SOCKET, SO_RCVBUFFORCE, [8388608], 4)

for which it it needs net_admin capability.

All I mentioned above is denied by current AppArmor profile, which I am intended to update [0], in result fixing DENIED 
messages in syslog/audit log.

While usually it is favourable to have most restrictive AppArmor profile to reduce attack vectors as much as possible, 
maybe in this case, allowing net_admin capability for SO_SNDBUFFORCE / SO_RCVBUFFORCE is necessary, and we should not 
deny it? Although currently it seems that traceroute still produces expected results even if it is denied by AppArmor.

So, how it is important to have ability to change SO_RCVBUFFORCE and SO_SNDBUFFORCE values? How can it affect traceroute 
correctness/performance in negative way?

Thanks!


[0] https://code.launchpad.net/~talkless/apparmor/fix_traceroute_tcp/+merge/326260

Re: [traceroute] Compilation fails for armv6 tool chain

[Dmitry B. <bu...@tu...>]

Kansara, Kaushal (Kaushal) wrote:
>
> mod-dccp.c: In function 'dccp_init':
>
> mod-dccp.c:66: error: 'IPPROTO_DCCP' undeclared (first use in this 
> function)
>
> mod-dccp.c:66: error: (Each undeclared identifier is reported only once
>
> mod-dccp.c:66: error: for each function it appears in.)
>
It should be defined in /usr/include/netinet/in.h with a value of "33" .
>
> mod-dccp.c: In function 'dccp_send_probe':
>
> mod-dccp.c:180: error: 'SOCK_DCCP' undeclared (first use in this function)
>
> mod-dccp.c:180: error: 'IPPROTO_DCCP' undeclared (first use in this 
> function)
>
>
It should be defined in /usr/include/bits/in.h with a value of "6" .

Probably something is wrong/incomplete with the system headers in your 
(cross) environment.

You can try to add the definitions to cflags at compile time:
CFLAGS="-D_GNU_SOURCE -DIPPROTO_ICCP=33 -DSOCK_DCCP=6".
If not help, try to just remove the mod-dccp.c file from the source (no 
other changes needed) to drop DCCP support.


Regards,
Dmitry Butskoy

[traceroute] Compilation fails for armv6 tool chain

[Kansara, K. (Kaushal) <kka...@av...>]

Hi,

Getting below error while compiling traceroute-2.0.21 and above.

[platform@localhost traceroute-2.1.0]$ make CROSS=arm-wrs-linux-gnueabi-  CFLAGS="-O2 -Wall -I/home/platform/Kaushal/Work/Project/lib_common/bcom/x86-linux2/lib/gcc/arm-wrs-linux-gnueabi/4.3.2/include -I/home/platform/Kaushal/Work/Project/lib_common/bcom/sysroot/usr/include"
arm-wrs-linux-gnueabi-gcc -O2 -Wall -I/home/platform/Kaushal/Work/Project/lib_common/bcom/x86-linux2/lib/gcc/arm-wrs-linux-gnueabi/4.3.2/include -I/home/platform/Kaushal/Work/Project/lib_common/bcom/sysroot/usr/include  -D_GNU_SOURCE -c clif.c
rm -f libsupp.a
arm-wrs-linux-gnueabi-ar -rc libsupp.a clif.o
arm-wrs-linux-gnueabi-ranlib libsupp.a
arm-wrs-linux-gnueabi-gcc -O2 -Wall -I/home/platform/Kaushal/Work/Project/lib_common/bcom/x86-linux2/lib/gcc/arm-wrs-linux-gnueabi/4.3.2/include -I/home/platform/Kaushal/Work/Project/lib_common/bcom/sysroot/usr/include  -D_GNU_SOURCE -c as_lookups.c
arm-wrs-linux-gnueabi-gcc -O2 -Wall -I/home/platform/Kaushal/Work/Project/lib_common/bcom/x86-linux2/lib/gcc/arm-wrs-linux-gnueabi/4.3.2/include -I/home/platform/Kaushal/Work/Project/lib_common/bcom/sysroot/usr/include  -D_GNU_SOURCE -c csum.c
arm-wrs-linux-gnueabi-gcc -O2 -Wall -I/home/platform/Kaushal/Work/Project/lib_common/bcom/x86-linux2/lib/gcc/arm-wrs-linux-gnueabi/4.3.2/include -I/home/platform/Kaushal/Work/Project/lib_common/bcom/sysroot/usr/include  -D_GNU_SOURCE -c extension.c
arm-wrs-linux-gnueabi-gcc -O2 -Wall -I/home/platform/Kaushal/Work/Project/lib_common/bcom/x86-linux2/lib/gcc/arm-wrs-linux-gnueabi/4.3.2/include -I/home/platform/Kaushal/Work/Project/lib_common/bcom/sysroot/usr/include  -D_GNU_SOURCE -c mod-dccp.c
mod-dccp.c: In function 'dccp_init':
mod-dccp.c:66: error: 'IPPROTO_DCCP' undeclared (first use in this function)
mod-dccp.c:66: error: (Each undeclared identifier is reported only once
mod-dccp.c:66: error: for each function it appears in.)
mod-dccp.c: In function 'dccp_send_probe':
mod-dccp.c:180: error: 'SOCK_DCCP' undeclared (first use in this function)
mod-dccp.c:180: error: 'IPPROTO_DCCP' undeclared (first use in this function)
make[1]: *** [mod-dccp.o] Error 1
make: *** [traceroute] Error 2


Thanks,
Kaushal

[traceroute] New traceroute version 2.1.0 available

[Dmitry B. <bu...@tu...>]

New traceroute-2.1.0 available, with new waiting mechanism.

See 
https://sourceforge.net/projects/traceroute/files/traceroute/traceroute-2.1.0/ 
for more info.

Still have plans to support 2.0.x line for a while, for old production 
systems etc.


Regards,
Dmitry Butskoy

Re: [traceroute] build fails when cross-compiling due to missing linkpaths

[Mike F. <va...@ge...>]

On 21 Feb 2016 21:31, Dmitry Butskoy wrote:
> Mike Frysinger wrote:
> > relying on CC=gcc for correct behavior seems incorrect to me.
>
> The playing with CPATH and LIBRARY_PATH was just for cosmetic reasons -- 
> ie. hide a lot of annoying `-I' amd `-L' in the cmdline printed by make.
> IOW nothing crashes if you use, say, "make CC=cc"  -- you'll see just 
> "more verbose output".
>
> > what if i'm using clang ? or i'm setting it to my full native compiler 
> > x86_64-pc-linux-gnu-gcc ?
>
> Both cases LIBRARY_PATH will not be set, a path to the "libsupp" will be 
> send to LD by the `-L' option, and you'll see this `-L' option in the 
> make's output.
> 
> Since "CC=gcc" is used most widely, most cases all should be as before.

still seems unnecessary to me, but the patch does work.  nowadays for
verbose-vs-pretty mode, people have moved towards V= build modes.  then
the only output is something like:
	CC foo.o
	LD traceroute
-mike

Re: [traceroute] build fails when cross-compiling due to missing linkpaths

[Dmitry B. <bu...@tu...>]

Mike Frysinger wrote:
> relying on CC=gcc for correct behavior seems incorrect to me.
The playing with CPATH and LIBRARY_PATH was just for cosmetic reasons -- 
ie. hide a lot of annoying `-I' amd `-L' in the cmdline printed by make.
IOW nothing crashes if you use, say, "make CC=cc"  -- you'll see just 
"more verbose output".
> what if i'm using clang ? or i'm setting it to my full native compiler 
> x86_64-pc-linux-gnu-gcc ?
Both cases LIBRARY_PATH will not be set, a path to the "libsupp" will be 
send to LD by the `-L' option, and you'll see this `-L' option in the 
make's output.

Since "CC=gcc" is used most widely, most cases all should be as before.


~buc

Re: [traceroute] build fails when cross-compiling due to missing linkpaths

[Mike F. <va...@ge...>]

On 20 Feb 2016 23:43, Dmitry Butskoy wrote:
> Mike Frysinger wrote:
> > On 20 Feb 2016 23:18, Dmitry Butskoy wrote:
> >> Mike Frysinger wrote:
> >>> the makefile relies on vpaths to automatically turn -lsupp into a full
> >>> path to libsupp/libsupp.a.  when cross-compiling, this doesn't happen,
> >>> so we get:
> >>> /usr/libexec/gcc/powerpc64-unknown-linux-gnu/ld: cannot find -lsupp
> >>>
> >>> adding an explicit -L../libsupp makes it work.
> 
> Could you please test the patch attached?

relying on CC=gcc for correct behavior seems incorrect to me.
what if i'm using clang ?  or i'm setting it to my full native
compiler x86_64-pc-linux-gnu-gcc ?

or am i misreading the patch ?
-mike

Re: [traceroute] build fails when cross-compiling due to missing linkpaths

[Dmitry B. <bu...@tu...>]

Mike Frysinger wrote:
> On 20 Feb 2016 23:18, Dmitry Butskoy wrote:
>> Mike Frysinger wrote:
>>> the makefile relies on vpaths to automatically turn -lsupp into a full
>>> path to libsupp/libsupp.a.  when cross-compiling, this doesn't happen,
>>> so we get:
>>> /usr/libexec/gcc/powerpc64-unknown-linux-gnu/ld: cannot find -lsupp
>>>
>>> adding an explicit -L../libsupp makes it work.

Could you please test the patch attached?


~buc

Re: [traceroute] build fails when cross-compiling due to missing linkpaths

[Mike F. <va...@ge...>]

On 20 Feb 2016 23:18, Dmitry Butskoy wrote:
> Mike Frysinger wrote:
> > the makefile relies on vpaths to automatically turn -lsupp into a full
> > path to libsupp/libsupp.a.  when cross-compiling, this doesn't happen,
> > so we get:
> > /usr/libexec/gcc/powerpc64-unknown-linux-gnu/ld: cannot find -lsupp
> >
> > adding an explicit -L../libsupp makes it work.
>
> Ack.
> 
> Thanks, I'll think about it.
> (Last time i did something with cross compiling all worked fine, but it 
> was 15 year ago indeed :) )
> 
> Hope add "-L../libsupp" to LDFLAGS would not be too hard for a while...

an alternative would be to not use -lxxx but add the full path to
libxxx.a to the link
-mike

Re: [traceroute] build fails when cross-compiling due to missing linkpaths

[Dmitry B. <bu...@tu...>]

Mike Frysinger wrote:
> the makefile relies on vpaths to automatically turn -lsupp into a full
> path to libsupp/libsupp.a.  when cross-compiling, this doesn't happen,
> so we get:
> /usr/libexec/gcc/powerpc64-unknown-linux-gnu/ld: cannot find -lsupp
>
> adding an explicit -L../libsupp makes it work.
>
Ack.

Thanks, I'll think about it.
(Last time i did something with cross compiling all worked fine, but it 
was 15 year ago indeed :) )

Hope add "-L../libsupp" to LDFLAGS would not be too hard for a while...


Regards,
Dmitry Butskoy

[traceroute] build fails when cross-compiling due to missing linkpaths

[Mike F. <va...@ge...>]

the makefile relies on vpaths to automatically turn -lsupp into a full
path to libsupp/libsupp.a.  when cross-compiling, this doesn't happen,
so we get:
/usr/libexec/gcc/powerpc64-unknown-linux-gnu/ld: cannot find -lsupp

adding an explicit -L../libsupp makes it work.

full log here:
	https://bugs.gentoo.org/432116
-mike

[traceroute] Version 2.0.22 released

[Dmitry B. <bu...@tu...>]

New version of traceroute released.

Changes in 2.0.22:

         *  Some portability fixing and improvements (Felix Janda)

         *  Require clear numbers for options and arguments (Sergey 
Salnikov)

         *  Drop compilation date from the version string (Debian #774365)

         *  New tcp module option `reuse', which utilize SO_REUSEADDR
            to reuse local port numbers for the huge workloads (Richard 
Sheehan)

         *  Avoid poll(2) call with spurious zero timeout in some rare cases
            by rounding the value properly using ceil(3)

[traceroute] Traceroute-2.0.21 released

[Dmitry B. <bu...@tu...>]

Hi all,

New traceroute version 2.0.21 is released, which fix the issue of 
`--mtu' option working on kernels >= 3.13

Since the kernel-3.13, when we do patch mtu discovery, the first answer 
is from the local host. Previously (kernel < 3.13) an icmp packet was 
sent (ie. the same way as from remote hosts etc.), but now no more icmp, 
a local error instead.

The `-F' (dontfrag) option was affected too.

Please, check how new verson works in your environments (old, new 
kernels, ipv4/ipv6, various trace methods etc.).


Best regards,
Dmitry Butskoy

[traceroute] New version 2.0.20 released

[Dmitry B. <bu...@tu...>]

New version of traceroute-2.0.20 is released,
download it at 
http://sourceforge.net/projects/traceroute/files/traceroute/traceroute-2.0.20/traceroute-2.0.20.tar.gz/download

Just some little improvements and fixes, including:

         *  Describe all complementary long options in the man page (Jan 
Synacek)

         *  Use correct service name for AS lookups (Frederic Mangano)

         *  Avoid some rare case null dereference (geo...@js...)

         *  Improve expiration check for simultaneous probes


Regards,
Dmitry Butskoy

[traceroute] traceroute 2.0.19 released

[Dmitry B. <bu...@od...>]

Traceroute 2.0.19 is released.

Most change is DCCP protocol support (rfc4340), written by Samuel Jero .
Use "-D" option for it (the protocol-specific options are available too).

Besides that, various little cleanups etc.


Regards,
Dmitry Butskoy