iputils/iputils

The iputils package is set of small old utilities for Linux networking.

The iputils package is set of small useful utilities for Linux networking.

Installation

$ ./configure && meson build
# cd builddir && meson install

Configuration can be adjusted (prefix, what is being build, etc.), see meson_options.txt, meson.build.

Build dependencies are listed in scripts in ci directory.

Supported libc

• glibc
• uClibc-ng
• musl

Contributing

Issues

• If reporting a bug, please document how to reproduce it.
• Please always test the latest master branch.
• Finding the commit which introduced the problem helps (bisecting).
• Document the kernel and distribution that were used.
• Tests should ideally use network namespaces to not interfere with the rest of the system.

Pull requests

• If fixing a bug, please document how to reproduce it.
• Finding the commit which introduced the problem helps (bisecting). Add Fixme: tag.
• If adding a feature, please describe why it's useful to add it.
• Commits should be signed: Signed-off-by: Your Name <[email protected]>, see https://www.kernel.org/doc/html/latest/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin.
• Although the coding style for most tools is ancient, new code should follow the Linux kernel coding style. See https://www.kernel.org/doc/html/latest/process/coding-style.html.
• To update the code in the pull request, use git push -f. Do not open a new pull request.

Reviewers

• Reviewers are very welcome. Post your comments or add Reviewed-by: Your Name <[email protected]>.

Translators

Localization is hosted on Fedora Weblate.

Tools included in iputils

• arping
• clockdiff
• ping
• tracepath

Tools removed from iputils

Some obsolete tools has been removed (see #363).

Tool	Removing commit	Last release	Replacement
ninfod	8f0d897	20211215	experimental unused protocol
rarpd	fba7b62	20211215	superseded by DHCP protocol
rdisc	7447806	20211215	superseded by DHCP protocol
tftpd	341975a	20210722	tftp-hpa, dnsmasq
traceroute6	a139421	20210722	mtr, traceroute, tracepath

History

Alexey Kuznetsov (1999–2002)

• first release (1999-01-07): iputils-ss990107.tar.gz (source code not available)
• first downloadable release (1999-04-16): iputils-ss990417.tar.gz
• latest release (2002-09-26): iputils-ss020927.tar.gz

Hideaki Yoshifuji (2006–2015)

• first release (2006-04-25): iputils-s20060425.tar.bz2
• latest release (2015-12-18): iputils-s20151218.tar.bz2

iputils's Issues

sync with iputils-YH

http://www.linux-ipv6.org/gitweb/gitweb.cgi?p=gitroot/iputils.git brings three new patches since latest sync:

• ping,ping6 doc: More description on CAP_NET_RAW usage.
• iputils ping/ping6: add (non-raw) ICMP socket support
• 4 iputils ping/ping6: Add a function to check if a packet is ours

-thanks-

ping6 crash while getifaddrs return entries with if name NULL

ping6 segfault 0 while getifaddrs return entries with ifa->ifa_name == NULL.
https://sourceware.org/bugzilla/show_bug.cgi?id=21812 --> this bug hit, causing ping6 to crash

crashed here ==> if (!strncmp(ifa->ifa_name, device, sizeof(device) - 1)

There are new patches at netdev ml

from Mike Frysinger, https://marc.info/?l=linux-netdev&w=2&r=1&s=iputils&q=b
[PATCH iputils] tftpd: fix syslog setup
[PATCH iputils] ping6: allow disabling of openssl support
[PATCH iputils] ping: fix -i number parsing in locales

and maybe others older.

-thanks-

remove -g from default CFLAGS

it's useful only for debuging, is it needed by default?

Some results for gcc 4.8.2
Default (CFLAGS="-g -O3"):
149K ping
160K ping6

Without -g (CFLAGS="-O3"):
47K ping
51K ping6

Without -g and with -lto (CFLAGS="-O3 -lto"):
44K ping
49K ping6

Move from libidn to libidn2 (or add possibility to select between them)

Hi there!

It would be nice if you consider to move from libidn to libidn2:
https://www.gnu.org/software/libidn/#libidn2

tracepath and ping fail to compile with musl-libc and linux-headers 4.2.0

Ran into this while cross compiling for musl. Will check to see if it works fine natively once I can.

make -j4 CC="x86_64-pc-linux-musl-cc" CFLAGS="-march=native -pipe -Os -g" LIBC_INCLUDE="/usr/x86_64-pc-linux-musl/include" USE_CAP=no USE_GCRYPT=no USE_IDN=no USE_NETTLE=no
fatal: Not a git repository (or any of the parent directories): .git
x86_64-pc-linux-musl-cc -march=native -pipe -Os -g -march=native -pipe -Os -g -D_GNU_SOURCE  -c ping.c    -o ping.o
x86_64-pc-linux-musl-cc -march=native -pipe -Os -g -march=native -pipe -Os -g -D_GNU_SOURCE  -c ping_common.c   -o ping_common.o
x86_64-pc-linux-musl-cc -march=native -pipe -Os -g -march=native -pipe -Os -g -D_GNU_SOURCE  -c ping6_common.c   -o ping6_common.o
x86_64-pc-linux-musl-cc -march=native -pipe -Os -g -march=native -pipe -Os -g -D_GNU_SOURCE  -c tracepath.c  -o tracepath.o
In file included from tracepath.c:17:0:
/usr/x86_64-pc-linux-musl/include/linux/errqueue.h:33:18: error: array type has incomplete element type 'struct timespec'
  struct timespec ts[3];
                  ^
Makefile:137: recipe for target 'tracepath.o' failed
make: *** [tracepath.o] Error 1
make: *** Waiting for unfinished jobs....
ping.c: In function 'main':
ping.c:289:22: error: 'SCOPE_DELIMITER' undeclared (first use in this function)
     p = strchr(addr, SCOPE_DELIMITER);
                      ^
ping.c:289:22: note: each undeclared identifier is reported only once for each function it appears in
Makefile:137: recipe for target 'ping.o' failed
make: *** [ping.o] Error 1

[PATCH] broken "-I <ifname>" option

In Debian/testing, "ping -I..." from package 3:20150815-2 is not working.
Following patch fixes it:

--- iputils-master/ping.c.orig 2016-04-05 19:44:37.000000000 +0300
+++ iputils-master/ping.c 2016-04-15 18:00:08.000000000 +0300
@@ -570,7 +570,7 @@
strncpy(ifr.ifr_name, device, IFNAMSIZ-1);

                    enable_capability_raw();

•                   rc = setsockopt(probe_fd, SOL_SOCKET, SO_BINDTODEVICE, device, strlen(device)+1);
  

•                   rc = setsockopt(sock->fd, SOL_SOCKET, SO_BINDTODEVICE, device, strlen(device)+1);
                  disable_capability_raw();
  
                  if (rc == -1) {
  

Should we split niquery functions?

In my opinion the niquery set of functions is pretty much self-contained and it would be best to put it in niquery.h and niquery.c and use them from ping/ping6 code.

Make iputils localizable

From what I understood, iputils isn't localizable today. Suggestion is to do like coreutils, use gettext and then hand over the translation work to https://translationproject.org/html/welcome.html

License

Where is the license?

Thank you 👍

Colorize `ping` output, and maybe other commands

I think we are missing a lot. Check this out http://denilson.sa.nom.br/prettyping/

Would be great if ping has nice coloring. Maybe add --color=(always|auto|off).

what is the purpose of traceroute6 and what shall we do with it?

We're removing all IPv6 specific software that can be merged into originally IPv4 but now generic variants. But traceroute6 doesn't fit this scenario because there is no traceroute in the package. I would be happy if someone could explain that so that I can proceed with the necessary changes.

ping -I device_name device_ip_address (self) does not work

It's a rather cosmetic issue, but still...

# ip addr show dev eth0 | grep inet
    inet 192.168.122.100/24 brd 192.168.122.255 scope global eth0
    inet6 fe80::8817:157e:68cc:d912/64 scope link 

# ping -I eth0 192.168.122.100
PING 192.168.122.100 (192.168.122.100) from 192.168.122.100 eth0: 56(84) bytes of data.
<nothing... loops forever>

# ping -I 192.168.122.100 192.168.122.100
PING 192.168.122.100 (192.168.122.100) from 192.168.122.100 : 56(84) bytes of data.
64 bytes from 192.168.122.100: icmp_seq=1 ttl=64 time=0.029 ms
64 bytes from 192.168.122.100: icmp_seq=2 ttl=64 time=0.048 ms
64 bytes from 192.168.122.100: icmp_seq=3 ttl=64 time=0.024 ms
<works just fine>

Note that using the device name when pinging the IP address of the same device results in ping not working, whereas using the device IP address instead of its name does work.

This is a result of #56. I didn't really find a problem with the code itself. The described problem seems to happen because of the setsockopt(fd, SOL_SOCKET, SO_BINDTODEVICE, device, strlen(device)+1); is called on the sock->fd in addition to the probe fd. I'm not sure if this is a problem in the kernel, or in iputils code, or it's simply not meant to be used like that.

trailing dot required

discovered this issue with rhel 6.6 stock, no update, or with update (no other in our env has this issue / rhel 7/ubuntu 14.4) then got the latest version of iputils from here, compiled and see the exact same behavior. If i place the somehost in /etc/hosts, all works fine

[root@ping-rh iputils]# ./ping -I eth0 somehost (local name, only avail in dnsmasq)
ping: somehost: Name or service not known
[root@ping-rh iputils]# ./ping -I eth0 somehost.
PING somehost (10.155.203.21) from 10.155.203.64 eth0: 56(84) bytes of data.
64 bytes from somehost (10.155.203.21): icmp_seq=1 ttl=64 time=0.571 ms
64 bytes from somehost (10.155.203.21): icmp_seq=2 ttl=64 time=0.585 ms
^C

running against dnsmasq, with nsswitch on the host set to files/dns all the usual suspects.
this might not be the right spot to ask, but i don't see any other place that knows as much about ping :)

Broken ping to local interfaces with IPv6

This bug was introduced in #57.

$ ip addr |grep 'inet6'
    inet6 fe80::fc54:ff:fe2d:cc21/64 scope link

$ ./ping -6 fe80::fc54:ff:fe2d:cc21
connect: Invalid argument

make iputils Rusty!

Since iputils codebase is pretty old, using many formating styles and there is really small amount people, which are able to understand code, I'd like open discussion about slowly replacing codebase with Rust based code.

Goals:

• simplify code
• make it more understanble to newcomers
• Rust itself make it much more robust, more secure
• maybe even some performance gains, but that's only small bonus for us

So, there is ongoing process to rewrite iputils ping [1], feel free to watch this repository and in point, when it will have functionality parity with our ping and testing done, I vote for replacing old-one C89/GNU89 code with Rusty one :)

At this moment is repository [1] in ongoing WIP development, so in case you'll want contribute, pull request are welcome.

[1] https://github.com/mikeecb/ring

Bug in ipv6 ping -I

In ping6_run() there is an if statement which is supposed to set the IPV6_PKTINFO and SO_BINDTODEVICE options, but only the first setsockopt will be executed because there is && instead of || (ping6_common.c line 798)

Wrong host reported.

Sometimes I start a ping and come back days later to find it oddly reporting return packets from the source host itself.

64 bytes from abra2.bitwizard.nl (192.168.234.34): icmp_seq=32960 ttl=64 time=0.132 ms
64 bytes from abra2.bitwizard.nl (192.168.234.34): icmp_seq=32961 ttl=64 time=0.157 ms
^C
--- falbala.bitwizard.nl ping statistics ---
1474753 packets transmitted, 1474028 received, +575 errors, 0% packet loss, time 1474755201ms
rtt min/avg/max/mdev = 0.055/0.160/253.260/0.538 ms, pipe 3
abra2:~> ping falbala
PING falbala.bitwizard.nl (192.168.234.32) 56(84) bytes of data.
64 bytes from falbala.bitwizard.nl (192.168.234.32): icmp_seq=1 ttl=64 time=0.143 ms
...
64 bytes from falbala.bitwizard.nl (192.168.234.32): icmp_seq=5 ttl=64 time=0.140 ms
^C
--- falbala.bitwizard.nl ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 3999ms
rtt min/avg/max/mdev = 0.137/0.147/0.162/0.014 ms

I'm suspecting that the

From 192.168.234.34 icmp_seq=1 Destination Host Unreachable

carries over to when the host comes back.

Oh. The ping times reported at first seem to indicate that the packets actually DO travel over the link to the remote host and back.

failure on musl when idn is enabled

Musl built with this patch, git master.

https://paste.pound-python.org/show/fL41zvIQn8jvybYXkfpm/

If built with idn (or idn2, both tested) enabled all lookups won't happen. Here's a strace.

strace -s 4096 -o /tmp/ping.strace.log /bin/ping -c 1 www.köln.de

https://paste.pound-python.org/show/qdiPCezgEoizMp1y0d3G/

even when not trying an idn I get failures

# ping google.com
ping: google.com: Invalid flags

tracepath doesnt show ip of host in output anymore post 20071127 version

Is this expected ? or a problem

Document or correct "mdev" in summary output

Forwarded from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=477569

Quoting the Debian bug report:

After a successful sequence of ICMP echo responses, ping outputs values
labelled;

min, mean, max, mdev

for the round trip times, "min", "mean" and "max" being self
explanatory but documented.

I believe it would be desirable to clarify what "mdev" is because;

Wikipedia ping article suggests it is mean deviation, and that mdev is
a common or accepted abbreviation for mean deviation.

The release notes hint it may be "mean deviation" as they mention mean
deviation when referring to IPv6 (I believe this to be an error in the
release notes).

The code calculates: sqrt( mean of squares - square of mean).

Which is a quick method of calculating standard deviation from a running
sequence of values.

I'm not aware of the abbreviation "mdev" being used for standard
deviation outside of this implementation of ping.

ping sometime exists before receiving last packet with -A option

ping sometime exists before receiving last packet with -A option.
Even if -W option is supplied with bigger number, it terminates.

In the __schedule_exit it looks like timer is set when N packets are transmitted, but only (N-1) packets are received.

Timer is set to "2 x max-round-trip-time".
Here round-trip time will be less than a milliseconds. i.e 0sec and 0 usec and eventually setting timer with 0sec which triggers SIGALRM immediately to set the exited flag.

In case of ADAPTIVE option, recvmsg is called with non-blocking option and may not receive last packet in one iteration.

In function __schedule_exit, should not it set the timer to the value of lingertime i.e -W option instead of setting it to "2 x round-trip-time"?

ping: support IPV6 directly

integrate ping6 functionality into ping.

parameters -4 and -6 could force IP version for domain names, IP address is unique enough to distinguish

Bug: https://bugzilla.redhat.com/show_bug.cgi?id=617934

Proposed steps:

1. make ping6 functions unique, so they won't collide with ping
2. add "-6" option to ping command, which use ping6 codepaths
3. allow ping detect IP version and then decide, add "-4" param. which allow force ipv4
4. cleanup and integrate code closely, which should improve size and code readability.

Error of ping compilation for musl

I tried compile iputils-s20140519 and compiler displayed error:
ing.c: In function ‘send_probe’:
ping.c:697:10: warning: initialization makes integer from pointer without a cast [enabled by default]
ping.c:697:10: warning: (near initialization for ‘m.__pad1’) [enabled by default]
ping.c:697:10: error: initializer element is not computable at load time
ping.c:697:10: error: (near initialization for ‘m.__pad1’)

Problem is at the msghdr structure. I used musl-1.0.3.
I created my patch and compiled iputils but my patch propably work for only musl.

switch iputils to Meson build system

@okias,

Would you be interested in either a cmake or autotools build system if i sent a pull request?

The reason i ask is the the two pull requests i made (#42 and #50) are both about linking against the correct libraries. A better solution might be to have a configure stage to check which libraries are needed to link against.

What do you think?

BTW, thanks for maintaining iputils.

-M pmtudisc_opt is broken in 1c59920

I'm probing some network with the -M do (do not fragment) flag for pmtu set with ping.

I ran the ping from one host with an older iputils from before the ping/ping6 merge.

And one on a host that i have 1c59920 on. (Latest iputils in ArchLinux testing repository)

It does seem that the newer iputils doesn't respect the -M flag at all.

When i check with tcpdump i see that it does put fragments out. Rather than the expected behaviour that it doesn't do it. and use the DF bit to indicate that fragmentation is not desired.

Could this be some regression?

ping 100% cpu

It's the third time that i did left ping -O 8.8.8.8 running for few days and i get 100% cpu usage from it.

i did run strace on ping, and 5s of strace is 20MB of log
https://www.dropbox.com/s/93bl3lkhowopco0/ping_strace.log?dl=1

Arch Linux
ping utility, iputils-s20161105

Is there something i can do to help debug this?

Add support for IPPROTO_ICMP

I'm running a system with restricted user capabilities, so I am unable to use ping:

$ ping google.com
ping: socket: Operation not permitted

Would it be possible to add support for the new socket type that does not require special user capabilities as described in the link below?
https://lwn.net/Articles/420799/

traceroute6: tracing to an IPv6 address is broken

In #68 traceroute6 was completely broken for tracing to a hostname. The fix fixed hostname tracing, but broke tracing to an IP address. Here's output from the current master:

nate@ubuntu-testing:~/src/iputils⟫ sudo ./traceroute6 2607:f8b0:4006:80d::2004
traceroute to 2607:f8b0:4006:80d::2004 (2607:f8b0:4006:80d::2004) from 2604:a880:0:1010::1855:a001, 30 hops max, 24 byte packets
sendto: Invalid argument
1 traceroute: wrote 2607:f8b0:4006:80d::2004 24 chars, ret=-1
*sendto: Invalid argument
traceroute: wrote 2607:f8b0:4006:80d::2004 24 chars, ret=-1
^C

And checking out the previous commit:

nate@ubuntu-testing:~/src/iputils⟫ sudo ./traceroute6 2607:f8b0:4006:80d::2004
traceroute to 2607:f8b0:4006:80d::2004 (2607:f8b0:4006:80d::2004) from 2604:a880:0:1010::1855:a001, 30 hops max, 24 byte packets
1 2604:a880:0:1010:ffff:ffff:ffff:fff1 (2604:a880:0:1010:ffff:ffff:ffff:fff1) 0.561 ms 1.541 ms 3.577 ms
2 2604:a880:ffff:1:1::35 (2604:a880:ffff:1:1::35) 0.274 ms 0.314 ms 0.224 ms
3 2604:a880:ffff:1:1::1 (2604:a880:ffff:1:1::1) 29.256 ms 0.346 ms 0.246 ms
4 2604:a880::101 (2604:a880::101) 0.317 ms 0.397 ms 0.291 ms
5 2001:4860::1:4000:ce4b (2001:4860::1:4000:ce4b) 0.774 ms 0.801 ms 0.676 ms
6 2001:4860:0:1::121d (2001:4860:0:1::121d) 1.446 ms 1.382 ms 1.246 ms
7 lga15s49-in-x04.1e100.net (2607:f8b0:4006:80d::2004) 0.878 ms 0.987 ms 0.911 ms

I believe we just need to move the setting of to->sin6_port to after the conditional. Pull request incoming.

Ping packetloss% upgrade

Hello, Really new to github sorry for putting this here if it doesn't belong there.

Using a ping command I realised the % for packetloss upgrade was not really accurate. Actually if you make like 30 000 pings and received 29 950 of them, since u did not hit the 1%, the output missleads you and tell you that you have 0% packet loss.

I'd love to see a slight improvement for this with a symbol (>/=) for results between 0 and 1% for example :

30000 packets transmitted, 29950 received, >0% packet loss, time 0ms
and
30000 packets transmitted, 30000 received, =0% packet loss, time 0ms

English is not my native language either so please do not bash me :D

Thank you for your time.

ping -Q184 fails with "Invalid tclass"

Worked fine with ping from iputils-s20121221, does not work with ping from iputils-s20160308.

Cannot ping IPv4 addresses when SOCK_DGRAM is not supported

Pinging IPv4 addresses fails when the kernel is too old to support SOCK_DGRAM ICMP socket (actually OpenVZ 2.6.32-042stab113.11).

# strace ./ping -v -4 127.0.0.1

socket(PF_INET, SOCK_DGRAM, IPPROTO_ICMP) = -1 EAFNOSUPPORT (Address family not supported by protocol)
[snip]
write(2, "ping: socket: Address family not supported by protocol\n", 55) = 55

However, it is okay to ping IPv6 addresses:

# strace -s 99 ./ping -v -6 ::1

socket(PF_INET6, SOCK_DGRAM, IPPROTO_ICMPV6) = -1 EPROTONOSUPPORT (Protocol not supported)
[snip]
write(2, "ping: socket: Protocol not supported, attempting raw socket...\n", 63) = 63
socket(PF_INET6, SOCK_RAW, IPPROTO_ICMPV6) = 3
[snip]
sendto(3, ...) = 64
recvmsg(3, ...) = 64

Apparently it is deliberately instructed in the code not to retry for a raw socket when the errno is EAFNOSUPPORT, which is the return value for IPv4 sockets with SOCK_DGRAM.

I don't understand why or when that condition is necessary, but removing it makes ping work fine.

diff --git a/ping.c b/ping.c
index 4455091..fd3c20b 100644
--- a/ping.c
+++ b/ping.c
@@ -115,7 +115,7 @@ static void create_socket(socket_st *sock, int family, int socktype, int protoco
        sock->fd = socket(family, socktype, protocol);

        /* Attempt creating a raw socket when ping socket failed */
-       if (sock->fd == -1 && errno != EAFNOSUPPORT && socktype == SOCK_DGRAM) {
+       if (sock->fd == -1 && socktype == SOCK_DGRAM) {
                if (options & F_VERBOSE)
                        fprintf(stderr, "ping: socket: %s, attempting raw socket...\n", strerror(errno));
                create_socket(sock, family, SOCK_RAW, protocol, requisite);

# ./ping -v -4 8.8.8.8
ping: socket: Address family not supported by protocol, attempting raw socket...
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=58 time=0.587 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=58 time=0.682 ms

main_loop() requests POLLERR but ignores it when returned

I believe I've encountered a kernel bug in linux 4.10-rc8 which caused this pathological case to occur:

1487242826.199486 poll([{fd=3, events=POLLIN|POLLERR}], 1, 970) = 1 ([{fd=3, revents=POLLERR}]) <0.000026>
1487242826.199578 recvmsg(3, 0x7ffc8e05e260, MSG_DONTWAIT) = -1 EAGAIN (Resource temporarily unavailable) <0.000024>
1487242826.199657 gettimeofday({1487242826, 199681}, NULL) = 0 <0.000021>
1487242826.199733 poll([{fd=3, events=POLLIN|POLLERR}], 1, 970) = 1 ([{fd=3, revents=POLLERR}]) <0.000027>
1487242826.199824 recvmsg(3, 0x7ffc8e05e260, MSG_DONTWAIT) = -1 EAGAIN (Resource temporarily unavailable) <0.000022>
1487242826.199899 gettimeofday({1487242826, 199923}, NULL) = 0 <0.000022>
1487242826.199991 poll([{fd=3, events=POLLIN|POLLERR}], 1, 970) = 1 ([{fd=3, revents=POLLERR}]) <0.000026>
1487242826.200085 recvmsg(3, 0x7ffc8e05e260, MSG_DONTWAIT) = -1 EAGAIN (Resource temporarily unavailable) <0.000022>
1487242826.200159 gettimeofday({1487242826, 200183}, NULL) = 0 <0.000022>
1487242826.200236 poll([{fd=3, events=POLLIN|POLLERR}], 1, 970) = 1 ([{fd=3, revents=POLLERR}]) <0.000028>
1487242826.200350 recvmsg(3, 0x7ffc8e05e260, MSG_DONTWAIT) = -1 EAGAIN (Resource temporarily unavailable) <0.000023>
1487242826.200427 gettimeofday({1487242826, 200451}, NULL) = 0 <0.000022>
1487242826.200503 poll([{fd=3, events=POLLIN|POLLERR}], 1, 969) = 1 ([{fd=3, revents=POLLERR}]) <0.000026>

I've already reported it to lkml, but this caused ping to spin and burn CPU when arguably it should have exited with an error. Perhaps the assumption is that a subsequent sendmsg would return error when POLLERR caused poll to return, but that's not happening and sendmsg and recvmsg are both succeeding:

1487242826.169425 gettimeofday({1487242826, 169450}, NULL) = 0 <0.000023>
1487242826.169502 sendmsg(3, {msg_name(16)={sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("xx.xxx.xxx.xxx")}, msg_iov(1)=[{"\10\0\245G\23\373\243uJ\206\245X\0
\0\0\0\352\225\2\0\0\0\0\0\20\21\22\23\24\25\26\27"..., 64}], msg_controllen=0, msg_flags=0}, MSG_CONFIRM) = 64 <0.000133>
1487242826.169757 recvmsg(3, {msg_name(16)={sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("xx.xxx.xxx.xxx")}, msg_iov(1)=[{"E \0T\345\364\0\0002\1w\23B\360\33
6~\n\0\0\23\0\0\255G\23\373\243uJ\206\245X"..., 192}], msg_controllen=32, {cmsg_len=32, cmsg_level=SOL_SOCKET, cmsg_type=0x1d /* SCM_??? */, ...}, msg_flags=0}, 0) = 84 <0.028825>
1487242826.198697 write(1, "64 bytes from xxx.com (xx.xx"..., 79) = 79 <0.000639>
1487242826.199405 gettimeofday({1487242826, 199430}, NULL) = 0 <0.000023>
1487242826.199486 poll([{fd=3, events=POLLIN|POLLERR}], 1, 970) = 1 ([{fd=3, revents=POLLERR}]) <0.000026>
1487242826.199578 recvmsg(3, 0x7ffc8e05e260, MSG_DONTWAIT) = -1 EAGAIN (Resource temporarily unavailable) <0.000024>

It's unclear to me if this should be fixed to reliably break the loop on POLLERR. What's happening here suggests that there's a potential disconnect between POLLERR and sendmsg errors, so perhaps it should be defended against.

SGML to XML man page conversion

current format doesn't seems much friendly these days, so I'd consider conversion.

xmltoman seems to be better build-able and supported these days than openjade & docbook-sgml-utils.

ccc-analyzer hints

ccc-analyzer -O3 -g -fno-strict-aliasing -Wstrict-prototypes -Wall -D_GNU_SOURCE  -c ping.c -DCAPABILITIES   -o ping.o
ping.c:1095:4: warning: Value stored to 'i' is never read
                        i -= 4;
                        ^    ~
ping.c:1126:5: warning: Value stored to 'cp' is never read
                                cp += i;
                                ^     ~
2 warnings generated.
ccc-analyzer -O3 -g -fno-strict-aliasing -Wstrict-prototypes -Wall -D_GNU_SOURCE  -c ping_common.c -DCAPABILITIES  -o ping_common.o
ccc-analyzer   -O3 -g -fno-strict-aliasing -Wstrict-prototypes -Wall ping.o ping_common.o -lcap    -o ping
ccc-analyzer -O3 -g -fno-strict-aliasing -Wstrict-prototypes -Wall -D_GNU_SOURCE  -c clockdiff.c -DCAPABILITIES -o clockdiff.o
clockdiff.c:62:12: warning: Assigned value is garbage or undefined
                                u.c[0] = *(char *)addr;
                                       ^ ~~~~~~~~~~~~~
clockdiff.c:63:12: warning: Assigned value is garbage or undefined
                                u.c[1] = *((char *)addr+1);
                                       ^ ~~~~~~~~~~~~~~~~~
clockdiff.c:67:9: warning: Assigned value is garbage or undefined
                                sum += *addr++;
                                    ^  ~~~~~~~
clockdiff.c:136:18: warning: Value stored to 'icp' during its initialization is never read
        struct icmphdr *icp = (struct icmphdr *) packet;
                        ^~~   ~~~~~~~~~~~~~~~~~~~~~~~~~
clockdiff.c:178:2: warning: Value stored to 'msgcount' is never read
        msgcount = 0;
        ^          ~
clockdiff.c:313:18: warning: Value stored to 'icp' during its initialization is never read
        struct icmphdr *icp = (struct icmphdr *) packet;
                        ^~~   ~~~~~~~~~~~~~~~~~~~~~~~~~
clockdiff.c:355:2: warning: Value stored to 'msgcount' is never read
        msgcount = 0;
        ^          ~
clockdiff.c:637:29: warning: Assigned value is garbage or undefined
                ((__u32*)(rspace+4))[0*2] = myaddr.sin_addr.s_addr;
                                          ^ ~~~~~~~~~~~~~~~~~~~~~~
8 warnings generated.
ccc-analyzer   -O3 -g -fno-strict-aliasing -Wstrict-prototypes -Wall clockdiff.o -lcap   -o clockdiff
ccc-analyzer -O3 -g -fno-strict-aliasing -Wstrict-prototypes -Wall -D_GNU_SOURCE  -c rdisc.c  -o rdisc.o
ccc-analyzer   -O3 -g -fno-strict-aliasing -Wstrict-prototypes -Wall rdisc.o    -o rdisc
ccc-analyzer -O3 -g -fno-strict-aliasing -Wstrict-prototypes -Wall -D_GNU_SOURCE  -c arping.c  -DCAPABILITIES   -o arping.o
ccc-analyzer   -O3 -g -fno-strict-aliasing -Wstrict-prototypes -Wall arping.o  -lcap    -o arping
ccc-analyzer -O3 -g -fno-strict-aliasing -Wstrict-prototypes -Wall -D_GNU_SOURCE  -c tftpd.c  -o tftpd.o
ccc-analyzer -O3 -g -fno-strict-aliasing -Wstrict-prototypes -Wall -D_GNU_SOURCE  -c tftpsubs.c  -o tftpsubs.o
ccc-analyzer   -O3 -g -fno-strict-aliasing -Wstrict-prototypes -Wall tftpd.o tftpsubs.o    -o tftpd
ccc-analyzer -O3 -g -fno-strict-aliasing -Wstrict-prototypes -Wall -D_GNU_SOURCE  -c rarpd.c  -o rarpd.o
rarpd.c:435:22: warning: The left operand of '!=' is a garbage value
        if (sll.sll_pkttype != PACKET_BROADCAST &&
            ~~~~~~~~~~~~~~~ ^
1 warning generated.
ccc-analyzer   -O3 -g -fno-strict-aliasing -Wstrict-prototypes -Wall rarpd.o    -o rarpd
ccc-analyzer -O3 -g -fno-strict-aliasing -Wstrict-prototypes -Wall -D_GNU_SOURCE  -c tracepath6.c  -o tracepath6.o
ccc-analyzer   -O3 -g -fno-strict-aliasing -Wstrict-prototypes -Wall tracepath6.o    -o tracepath6
ccc-analyzer -O3 -g -fno-strict-aliasing -Wstrict-prototypes -Wall -D_GNU_SOURCE  -c traceroute6.c -DCAPABILITIES  -o traceroute6.o
traceroute6.c:612:6: warning: Value stored to 'reset_timer' is never read
                                        reset_timer = 1;
                                        ^             ~
1 warning generated.
ccc-analyzer   -O3 -g -fno-strict-aliasing -Wstrict-prototypes -Wall traceroute6.o -lcap    -o traceroute6
ccc-analyzer -O3 -g -fno-strict-aliasing -Wstrict-prototypes -Wall -D_GNU_SOURCE  -c ping6.c -DCAPABILITIES    -DUSE_GNUTLS -o ping6.o
ping6.c:1496:8: warning: Value stored to 'p' during its initialization is never read
        __u8 *p = h + 4;
              ^   ~~~~~
1 warning generated.

tracepath documentation still references a tracepath6 binary

Forwarded from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=869202

The tracepath documentation still contains multiple references to a tracepath6 binary, which we no longer build or install.

From the original report:

The tracepath(8) man page mentions tracepath6:

NAME
   tracepath, tracepath6 - traces path to a network host discovering MTU
              ^^^^^^^^^^
   along this path
[...]
   tracepath6 is good replacement for traceroute6 and classic example of
   ^^^^^^^^^^
[...]
   -l     Sets  the initial packet length to pktlen instead of 65535 for
          tracepath or 128000 for tracepath6.
                                  ^^^^^^^^^^
[...]
OUTPUT
       root@mops:~ # tracepath6 3ffe:2400:0:109::2
                     ^^^^^^^^^^

However, tracepath6 no longer exists. The Debian changelog file says:

  * Merge IPv6 support into tracepath, drop tracepath6 binary.

when libgcrypt is used no explicit initialization of the library is done

libgcrypt requires explicit initialization prior to using the library:
https://www.gnupg.org/documentation/manuals/gcrypt/Initializing-the-library.html#Initializing-the-library

iputils doesn't do that, and while the hashing code works now, it may not in the future. For that I've submitted a patch (PR #17) to use nettle (the library used by gnutls) instead.

IPv6 SOCK_DGRAM/IPPROTO_ICMP question

I'm sorry for a question slighly unrelated (but still related) to iputils...

I have a program which is creating user-space ICMP sockets using the pattern (on IPv4) socket(AF_INET, SOCK_DGRAM, IPPROTO_ICMP). In order for this to work (on CentOS), I must first enable the capability by sysctl -w net.ipv4.ping_group_range = "0 9999". Even root (on CentOS at least) cannot create such a user-space socket until that setting is changed. That's all fine, so far so good, it works if that setting is changed.

However, when I try to construct an IPv6 socket, socket(AF_INET6, SOCK_DGRAM, IPPROTO_ICMPV6), the socket creation fails. I assumed there must be a comparable sysctl setting for IPv6, e.g. ````sysctl -w net.ipv6.ping_group_range = "0 9999"``. However, there is no such kernel parameter.

Googling revealed that such a patch was proposed in 2013, but after some small discussion the submitter concluded with:

I think we can just ignore the patch for now, we can add it if someone requests for it in future.

So, my question is, without such a kernel parameter, how is it that iputils can create an IPv6 SOCK_DGRAM/IPPROTO_ICMPV6 socket at all? How does it succeed? Am I missing something fundamental?

ping6 changed exit code

# ./ping6 2000::1 -c 1
PING 2000::1(2000::1) 56 data bytes
ping: sendmsg: No route to host

--- 2000::1 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

# echo $?
1

This used to be 2. Also, this is also inconsistent with ping4 now, which still correctly returns 2.

remove "ping6" from the man pages

Since ping6 doesn't exist anymore, I suggest removing every mention about it from the man pages. Maybe also add a small "historical" note saying that ping6 has been merged into ping.

What do you think? I can submit a pull request if there are no objections.

ping 100% cpu

I'm using ping6 to ping from a specific ip address -I to my router and after some time ping uses 100% CPU (measured in top).

Linux kernel: 4.10.16-200.fc25.x86_64
iputils-20161105-1.fc25.x86_64.

strace gives a continous loop of:

poll([{fd=3, events=POLLIN|POLLERR}], 1, 445) = 1 ([{fd=3, revents=POLLERR}])
recvmsg(3, {msg_namelen=128}, MSG_DONTWAIT) = -1 EAGAIN (Resource temporarily unavailable)

The output from ping doesn't report any problems (only a changing TTL):

64 bytes from router: icmp_seq=39153 ttl=64 time=1.02 ms
64 bytes from router: icmp_seq=39154 ttl=64 time=1.00 ms
64 bytes from router: icmp_seq=39155 ttl=64 time=1.02 ms
64 bytes from router: icmp_seq=39156 ttl=255 time=0.972 ms
64 bytes from router: icmp_seq=39157 ttl=255 time=1.02 ms
64 bytes from router: icmp_seq=39158 ttl=255 time=0.978 ms
64 bytes from router: icmp_seq=39159 ttl=255 time=1.01 ms
64 bytes from router: icmp_seq=39160 ttl=255 time=0.986 ms
64 bytes from router: icmp_seq=39161 ttl=255 time=5.11 ms
64 bytes from router: icmp_seq=39162 ttl=64 time=1.22 ms
64 bytes from router: icmp_seq=39163 ttl=64 time=4.25 ms
64 bytes from router: icmp_seq=39164 ttl=64 time=0.985 ms
64 bytes from router: icmp_seq=39165 ttl=64 time=1.08 ms
64 bytes from router: icmp_seq=39166 ttl=64 time=0.972 ms
64 bytes from router: icmp_seq=39167 ttl=255 time=0.953 ms
64 bytes from router: icmp_seq=39168 ttl=255 time=0.999 ms
64 bytes from router: icmp_seq=39169 ttl=255 time=0.876 ms
64 bytes from router: icmp_seq=39170 ttl=64 time=1.07 ms
64 bytes from router: icmp_seq=39171 ttl=64 time=1.01 ms
64 bytes from router: icmp_seq=39172 ttl=64 time=1.03 ms
64 bytes from router: icmp_seq=39173 ttl=64 time=1.04 ms

Related to closed issue #85

Bashism inside Doc Makefile

doc/Makefile uses pushd, a bash builtin, and doesn't compile directly under Ubuntu hosts (that use dash as their sh). Setting the shell to bash (SHELL := /bin/bash) or eliminating pushd/popd from the makefile would fix this.

CentOS 7 - ping address family not supported by protocol

I get the following error on CentOS 7 when trying to ping:

ping: socket: Address family not supported by protocol

Performing the following commands to downgrade to a previous version fixes it:

yum downgrade http://vault.centos.org/7.2.1511/os/x86_64/Packages/iputils-20121221-7.el7.x86_64.rpm
add "exclude=iputils" to "[base]" section of /etc/yum.repos.d/CentOS-Base.repo to prevent the broken version from being automatically reinstalled.

But not ideal as won't get any further updates. CentOS 7 is being run on VPSDime using OpenVZ.

The faulty version installed is: 20160308-10.el7

please document fork status

please update the top level README.md to document the status of this repo wrt upstream. unless you happen to come across the announce buried in the netdev archives [1], it's confusing to people that this might be official. especially since you've got the "iputils" username and not just a project named "iputils" under your own username.

this repo is also out of sync with the upstream git repo [2]. please merge with the latest master branch, and pull in all of its historical tags.

[1] http://www.spinics.net/lists/netdev/msg279881.html
[2] http://www.linux-ipv6.org/gitweb/gitweb.cgi?p=gitroot/iputils.git

traceroute6: sendto: Invalid argument

Forwarded from Debian bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843264

traceroute6 does not work at all:

tglase@tglase:~ $ sudo traceroute6 -n www.teckids.org
traceroute to (2a02:a00:1022:9846::74) from 2a01:4f8:150:946c::42:3, 30 hops max, 24 byte packets
sendto: Invalid argument
1 traceroute: wrote 24 chars, ret=-1
*sendto: Invalid argument
traceroute: wrote 24 chars, ret=-1
^C
130|tglase@tglase:~ $ ping6 www.teckids.org
PING www.teckids.org(terra.teckids.org (2a02:a00:1022:9846::74)) 56 data bytes
64 bytes from terra.teckids.org (2a02:a00:1022:9846::74): icmp_seq=1 ttl=54 time=24.6 ms
^C
--- www.teckids.org ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 24.670/24.670/24.670/0.000 ms

The other implementation on the system, however, does:

tglase@tglase:~ $ traceroute6.db -6 -n www.teckids.org
traceroute to www.teckids.org (2a02:a00:1022:9846::74), 30 hops max, 80 byte packets
1 2a01:4f8:150:946c::42:1 12.458 ms 12.460 ms 12.460 ms
2 * * *
3 2a01:4f8::a:15:b 12.445 ms 12.614 ms 12.621 ms
4 2a01:4f8:0:3::1c5 12.624 ms 2a01:4f8:0:3::1c1 12.628 ms 2a01:4f8:0:3::1c5 12.815 ms
5 2a01:4f8:0:3::a 16.829 ms 2a01:4f8:0:3::da 17.050 ms 17.059 ms
6 2001:7f8::62cb:0:1 17.286 ms 16.609 ms 16.616 ms
7 2a00:13c8:1:d::2 22.053 ms 22.064 ms 21.994 ms
8 2a01:170:0:2:3:1:0:c18 23.436 ms 23.446 ms 23.652 ms
9 2a01:170:0:2:3::2 21.965 ms 21.933 ms 21.749 ms
10 2a02:a00:1022:9846::74 24.218 ms 24.003 ms 24.150 ms

Add instructions how to install into a prefix to INSTALL

or add a configure script which should provide an intuitive way to achieve this

Translation to brazilian portuguese

I would like to contribute translanting the man pages to brazilian portuguese.
Please, could you gently tell me how could I do it?

Thank you.

a question about tracepath

How to identify the packet received?
Is there possibility that the recvd packet is the reply of last hop? (because of time delay or sth.)
I did some research of "tracepath.c", but still no idea now.
Anyone can help? thank you very much!

adding long options

I would like to add long options for better memorability and readability.

Can I just use getopt_long for this?

ping fails when IPv6 is disabled

When ping is ran without the -4 and -6 flags, the create_socket function is ran for both protocols. This gives the following error on machines which have disabled IPv6 in the kernel:

ping: socket: Address family not supported by protocol (raw socket required by specified options).

The program should not fail when an IPv6 socket cannot be opened, if an IPv4 socket is already available.

Arch Linux bug report