Description of problem: When a hostname is configured in /etc/hosts and does NOT have a dns entry, when using ping with 'options inet6' set in /etc/resolv.conf and /etc/nsswitch.conf has "hosts: files dns" set, ping returns the localhost name of the pinging computer instead of the name of the host configured in /etc/hosts. Version-Release number of selected component (if applicable): ping utility, iputils-s20121221 How reproducible: See steps below. Steps to Reproduce: 1. Edit /etc/resolv.conf add options inet6 all other parameters default 2. confirm /etc/nsswitch.conf has hosts: files dns 3. edit /etc/hosts enter x.x.x.x some-host-name where x.x.x.x is not an ip on your server but is available via default gateway and host name is NOT in any DNS resolver 4. ping some-host-name Actual results: 64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=1 ttl=64 time=0.094 ms 64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=2 ttl=64 time=0.087 ms 64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=3 ttl=64 time=0.106 ms Expected results: 64 bytes from some-host-name (x.x.x.x): icmp_seq=1 ttl=63 time=0.361 ms 64 bytes from some-host-name (x.x.x.x): icmp_seq=2 ttl=63 time=0.330 ms 64 bytes from some-host-name (x.x.x.x): icmp_seq=3 ttl=63 time=0.323 ms Additional info: This is also reproduceable on Centos 6.5 using ping utility, iputils-sss20071127
Tried to do the same steps on Kali, iputils-sss2010106 Kali-Linux GNU/Linux 1.0.6 and could not reproduce.
I'm thinking it's related to what we're experiencing as well. With options inet6 in /etc/resolv.conf, (apparently, or so I'm guessing) the resolver library will by default return an IPv6 record if one exists, unless you specifically ask for a family. Ping doesn't do that, nor does it detect that the returned IP isn't an IPv4 one. This leads to some very strange effects. Perfectly reproducable as soon as you turn on 'options inet6': [root@f20 ~]# host www.google.com www.google.com has address 173.194.65.147 www.google.com has address 173.194.65.103 www.google.com has address 173.194.65.104 www.google.com has address 173.194.65.105 www.google.com has address 173.194.65.99 www.google.com has address 173.194.65.106 www.google.com has IPv6 address 2a00:1450:4013:c00::67 [root@f290 ~]# ping www.google.com PING www.google.com (42.0.20.80) 56(84) bytes of data. using wireshark you can see an AAAA being asked & returned. I'm guessing the '42.0.20.80' is a botched attempt at interpreting the IPv6 as an IPv4.
BTW, I can also reproduce the same behaviour on a CentOS 6.5 machine
I've been meaning to push the latest bugfix version to F20 anyway, so here it comes: http://pkgs.fedoraproject.org/cgit/iputils.git/commit/?h=f20&id=3ce67e25af522ab0f36514dc5a2a5e9cf1e2af23
Fedora 20 update: https://admin.fedoraproject.org/updates/FEDORA-2014-7656/iputils-20140519-1.fc20
Update fixes the problem :) Will this be a RHEL fix as well, or do I have to shoot in a separate bug report for that?
Further validate fix works for me in F20. Thank you. [jwacaser@localhost ~]$ ping oj4500 PING oj4500 (127.0.0.1) 56(84) bytes of data. 64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=1 ttl=64 time=0.049 ms [jwacaser@localhost ~]$ sudo yum update Downloads/iputils-20140519-1.fc20.x86_64.rpm <snip> iputils.x86_64 0:20140519-1.fc20 Complete! [jwacaser@localhost ~]$ ping oj4500 PING oj4500 (10.100.22.189) 56(84) bytes of data. 64 bytes from oj4500 (10.100.22.189): icmp_seq=1 ttl=128 time=2.45 ms
(In reply to Ronald van Zantvoort from comment #6) > Will this be a RHEL fix as well, or do I have to shoot in a separate bug > report for that? Please, file a separate bug report. Thank you.
The updated package is in stable now.