ping reports wrong IP responding under certain conditions

Bug #1405232 reported by Elliot Dronebarger
This bug affects 6 people
Affects Status Importance Assigned to Milestone
iputils (Ubuntu)

Bug Description

Description: Ubuntu 14.04.1 LTS
Release: 14.04
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, last hop router was
circle@circle:~$ /bin/ping
PING ( 56(84) bytes of data.
From icmp_seq=1 Destination Host Unreachable
From icmp_seq=2 Destination Host Unreachable
From icmp_seq=3 Destination Host Unreachable
From icmp_seq=4 Destination Host Unreachable
From icmp_seq=5 Destination Host Unreachable
From icmp_seq=6 Destination Host Unreachable
64 bytes from icmp_seq=7 ttl=63 time=0.689 ms
64 bytes from icmp_seq=8 ttl=63 time=0.635 ms
64 bytes from icmp_seq=9 ttl=63 time=0.656 ms
64 bytes from icmp_seq=10 ttl=63 time=0.822 ms
64 bytes from icmp_seq=11 ttl=63 time=0.785 ms
--- 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
PING ( 56(84) bytes of data.
64 bytes from icmp_seq=1 ttl=63 time=0.737 ms
64 bytes from icmp_seq=2 ttl=63 time=0.646 ms
64 bytes from icmp_seq=3 ttl=63 time=0.626 ms
--- 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
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)

Revision history for this message
Elliot Dronebarger (edon22) wrote :
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in iputils (Ubuntu):
status: New → Confirmed
Revision history for this message
Martijn Lievaart (j-launchpad-net-rtij-nl) wrote :

The problem even exists on an ICMP redirect.

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

Revision history for this message
Martijn Lievaart (j-launchpad-net-rtij-nl) wrote :

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)
+ */
  in_pr_addr = !setjmp(pr_addr_jmp);

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

I think this can be kicked upstream.

Revision history for this message
Martijn Lievaart (j-launchpad-net-rtij-nl) wrote :

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

Revision history for this message
Martijn Lievaart (j-launchpad-net-rtij-nl) wrote :

To follow up on myself (I seem to do that a lot) see 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.

Revision history for this message
Ketil (ketil-froyn) wrote :

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.

Revision history for this message
Noah Meyerhans (noahm) wrote :

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:
and the current version of the patch:

Revision history for this message
Elliot Dronebarger (edon22) wrote :

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

Revision history for this message
Avery-yates (avery-yates) wrote :

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

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.