ping reports wrong IP responding under certain conditions

[Elliot Dronebarger]

Description: Ubuntu 14.04.1 LTS
Release: 14.04
iputils-ping:
Installed: 3:20121221-4ubuntu1.1
Candidate: 3:20121221-4ubuntu1.1

ping will report the incorrect reply IP address under certain, specific conditions, and is repeatable. This is how to re-create the issue:

1. Start pinging an IP where you get an ICMP error message from some other device (RFC792 lists errors). For instance: Destination IP is offline and the last-hop router reports message type "Destination Unreachable". I assume this would work for any ICMP error, though.

2. When the device comes back online, ping reports replies from the "other" device, when it should report replies from the device that is sending the "Echo Reply" messages.

3. If the ping is stopped and restarted after the device is up, it reports the correct IP address again. Other ping utilities do not exhibit this behavior.

Example output (Destination that was pinged was 172.21.56.50, last hop router was 172.21.25.103):
circle@circle:~$ /bin/ping 172.21.56.50
PING 172.21.56.50 (172.21.56.50) 56(84) bytes of data.
From 172.21.25.103 icmp_seq=1 Destination Host Unreachable
From 172.21.25.103 icmp_seq=2 Destination Host Unreachable
From 172.21.25.103 icmp_seq=3 Destination Host Unreachable
From 172.21.25.103 icmp_seq=4 Destination Host Unreachable
From 172.21.25.103 icmp_seq=5 Destination Host Unreachable
From 172.21.25.103 icmp_seq=6 Destination Host Unreachable
64 bytes from 172.21.25.103: icmp_seq=7 ttl=63 time=0.689 ms
64 bytes from 172.21.25.103: icmp_seq=8 ttl=63 time=0.635 ms
64 bytes from 172.21.25.103: icmp_seq=9 ttl=63 time=0.656 ms
64 bytes from 172.21.25.103: icmp_seq=10 ttl=63 time=0.822 ms
64 bytes from 172.21.25.103: icmp_seq=11 ttl=63 time=0.785 ms
^C
--- 172.21.56.50 ping statistics ---
11 packets transmitted, 5 received, +6 errors, 54% packet loss, time 10023ms
rtt min/avg/max/mdev = 0.635/0.717/0.822/0.077 ms, pipe 3
circle@circle:~$ /bin/ping 172.21.56.50
PING 172.21.56.50 (172.21.56.50) 56(84) bytes of data.
64 bytes from 172.21.56.50: icmp_seq=1 ttl=63 time=0.737 ms
64 bytes from 172.21.56.50: icmp_seq=2 ttl=63 time=0.646 ms
64 bytes from 172.21.56.50: icmp_seq=3 ttl=63 time=0.626 ms
^C
--- 172.21.56.50 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1998ms
rtt min/avg/max/mdev = 0.626/0.669/0.737/0.056 ms

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: iputils-ping 3:20121221-4ubuntu1.1
ProcVersionSignature: Ubuntu 3.13.0-43.72-generic 3.13.11.11
Uname: Linux 3.13.0-43-generic x86_64
ApportVersion: 2.14.1-0ubuntu3.6
Architecture: amd64
CurrentDesktop: XFCE
Date: Tue Dec 23 10:50:35 2014
InstallationDate: Installed on 2014-10-08 (76 days ago)
InstallationMedia: Xubuntu 14.04.1 LTS "Trusty Tahr" - Release amd64 (20140723)
SourcePackage: iputils
UpgradeStatus: No upgrade log present (probably fresh install)

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Martijn Lievaart (j-launchpad-net-rtij-nl)]

The problem even exists on an ICMP redirect.

martijn@garfield:~$ ping 172.22.226.3
PING 172.22.226.3 (172.22.226.3) 56(84) bytes of data.
From 10.0.0.138: icmp_seq=1 Redirect Host(New nexthop: 10.0.0.138)
64 bytes from 10.0.0.138: icmp_seq=1 ttl=245 time=66.4 ms
64 bytes from 10.0.0.138: icmp_seq=2 ttl=245 time=127 ms
64 bytes from 10.0.0.138: icmp_seq=3 ttl=245 time=280 ms

[Martijn Lievaart (j-launchpad-net-rtij-nl)]

I Noted the nexthop field is wrong as well in my last output.

What happens is a wrong optimisation. the pr_addr function assumes it is always called with the same address, so it just returns the previous buffer on subsequent invocations.

The following quickfix fixes both the issue in this ticket as the nexthop issue.

$ diff -U3 ping.c{~,}
--- ping.c~ 2015-02-12 13:00:18.000000000 +0100
+++ ping.c 2015-02-12 13:45:47.515167752 +0100
@@ -1244,10 +1244,10 @@
 {
  struct hostent *hp;
  static char buf[4096] = "";
-
+ /*
  if (*buf)
   return(buf);
-
+ */
  in_pr_addr = !setjmp(pr_addr_jmp);

  if (exiting || (options & F_NUMERIC) ||

I think this can be kicked upstream.

[Martijn Lievaart (j-launchpad-net-rtij-nl)]

No, don't kick upstream. It's bug109709-less-dns.patch. Revert it, it's bogus

[Martijn Lievaart (j-launchpad-net-rtij-nl)]

To follow up on myself (I seem to do that a lot) see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=109709. The problem that this patch tries to fix is sort of real (but see below), but the patch is plain wrong. Yes it fixes that issue, but introduces this new bug.

Which one is more serious? I think this bug is more serious and the patch should be (maybe partially) reverted. The original bug can be avoided (I think) by simply using the -n switch, so it's even a solution to a non-problem. This bug has no workaround.

[Ketil (ketil-froyn)]

Couldn't the upstream fix be to time out the DNS resolution? If you don't have an answer in X seconds/milliseconds, never mind and carry on. It's just ping, after all, and it's a good idea to make low level diagnosis independent of higher level functionality, as noted in the Debian bug report.

Caching hostnames in ping is a possible strategy, but that's what the local resolver is for. IMHO, that's not something ping should bother doing.

[Noah Meyerhans (noahm)]

14.04 contains an old version of the bug109709-less-dns.patch patch. Current versions implement DNS caching without this buggy behavior, so the best solution would be to refresh the patch.

See the commit history for that file:
http://anonscm.debian.org/cgit/collab-maint/iputils.git/log/debian/patches/bug109709-less-dns.patch
and the current version of the patch:
http://anonscm.debian.org/cgit/collab-maint/iputils.git/tree/debian/patches/bug109709-less-dns.patch

[Elliot Dronebarger (edon22)]

Can confirm - I tested in 15.10 and this bug no longer exists in the current iputils package, but this should be backported to 14.04 IMHO

[Avery-yates (avery-yates)]

Was about to file a report for this.
Can confirm, tested in 16.04

http://pastebin.com/JzexVR0D