Hide Forgot
Description of problem: Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
(sorry, I pressed Enter accidentally) Description of problem: getaddrinfo("localhost6") returns 127.0.0.1 instead of ::1. Version-Release number of selected component (if applicable): glibc-2.12-1.75.el6.x86_64.rpm How reproducible: always Steps to Reproduce: 1. compile attached program (it just prints results of getaddrinfo) 2. ./get localhost6 Actual results: Address: 127.0.0.1 Expected results: Address: ::1 Additional info: glibc-2.12-1.70.el6.x86_64 works perfectly
Created attachment 571150 [details] reproducer
My /etc/hosts: 127.0.0.1 localhost.localdomain localhost ::1 localhost6.localdomain6 localhost6
I'm working on it.
The changes for 797094 to avoid unbounded allocas had a non-obvious dependency on a prior, seemingly unrelated change. QA: We really need to include this in 6.3. The testcase is pretty trivial. Install the host file noted in c#3, then compile & run the code already attached to this bug with the argument "localhost6". If the result is 127.0.0.1, then we failed. ::1 is the expected result.
*** Bug 807224 has been marked as a duplicate of this bug. ***
*** Bug 810780 has been marked as a duplicate of this bug. ***
Created attachment 576309 [details] strace outputs of ping6
Created attachment 576310 [details] tcpdump and strace logs
------- Comment From pthan.com 2012-04-10 01:58 EDT------- Hi Redhat, I believe there is no use to attach the sosreport anymore now, right?
------- Comment From srinivasa.tn.com 2012-04-11 04:56 EDT------- Hi RH, The status of the mirrored bug states that it is verified. Can I have the access to patch in which it is fixed or can you the release in which it will be fixed? Regards, Seenu.
------- Comment From pthan.com 2012-04-23 07:25 EDT------- This bug has been fixed in glibc-2.12-1.78.el6.ppc64: [root@bandlp1 ~]# ping6 zenlp3-sl PING zenlp3-sl(zenlp3-sl.ipv6.upt.austin.ibm.com) 56 data bytes 64 bytes from zenlp3-sl.ipv6.upt.austin.ibm.com: icmp_seq=1 ttl=64 time=19.2 ms 64 bytes from zenlp3-sl.ipv6.upt.austin.ibm.com: icmp_seq=2 ttl=64 time=0.491 ms
*** Bug 807357 has been marked as a duplicate of this bug. ***
Confirmed broken on Fedora 17: host and ssh appear broken (localhost6 -> 127.0.0.1), but telnet appears to work (localhost6 -> ::1) [maze@varda ~]$ cat /etc/nsswitch.conf | egrep hosts hosts: files dns myhostname [maze@varda ~]$ cat /etc/hosts | egrep localhost 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 [maze@varda ~]$ telnet localhost6 1 Trying ::1... telnet: connect to address ::1: Connection refused [maze@varda ~]$ ssh -v -p 1 localhost6 OpenSSH_5.9p1, OpenSSL 1.0.0j-fips 10 May 2012 debug1: Reading configuration data /home/maze/.ssh/config debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 50: Applying options for * debug1: Connecting to localhost6 [127.0.0.1] port 1. debug1: connect to address 127.0.0.1 port 1: Connection refused ssh: connect to host localhost6 port 1: Connection refused [maze@varda ~]$ host localhost6 localhost6.localdomain is an alias for localhost. localhost has address 127.0.0.1 [maze@varda ~]$ ping localhost6 PING localhost (127.0.0.1) 56(84) bytes of data. 64 bytes from localhost (127.0.0.1): icmp_req=1 ttl=64 time=0.092 ms 64 bytes from localhost (127.0.0.1): icmp_req=2 ttl=64 time=0.048 ms ^C --- localhost ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1000ms rtt min/avg/max/mdev = 0.048/0.070/0.092/0.022 ms [maze@varda ~]$ ping6 localhost6 PING localhost6(localhost) 56 data bytes 64 bytes from localhost: icmp_seq=1 ttl=64 time=0.031 ms 64 bytes from localhost: icmp_seq=2 ttl=64 time=0.052 ms ^C --- localhost6 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1000ms rtt min/avg/max/mdev = 0.031/0.041/0.052/0.012 ms
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2012-0763.html