Bug 1096415
| Summary: | ping returns localhost with options inet6 set in resolv.conf | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | John <handyj> |
| Component: | iputils | Assignee: | Jan Synacek <jsynacek> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 20 | CC: | jsynacek, jwacaser, van.zantvoort |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | iputils-20140519-1.fc20 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2014-06-26 07:48:54 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
John
2014-05-09 23:11:53 UTC
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 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. |