[Bug libc/3847] New: Request for getaddrinfo to search IPv4 before IPv6 when family is PF_UNSPEC

[Bug libc/3847] New: Request for getaddrinfo to search IPv4 before IPv6 when family is PF_UNSPEC

[nr at eecs dot harvard dot edu]

The source file sysdeps/posix/getaddrinfo.c defines an array of searching
functions in the static array gaih[] defined on lines 1116-1125.  I request
that you swap lines 1118 and 1119 so that in the event getaddrinfo() is called
with hints that specify hints->ai_family == PF_UNSPEC, the loop at line 1542
will try IPv4 first, rather than trying IPv6 first.

Reason: for local networks at home, many of us are stuck behind routers that do
DNS in firmware, and an IPv6 query results in a timeout.  A trace of netkit
telnet shows two of these timeouts:
     0.000201 socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3
     0.000054 connect(3, {sa_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr("192.168.2.1")}
, 28) = 0
     0.000055 fcntl64(3, F_GETFL)       = 0x2 (flags O_RDWR)
     0.000025 fcntl64(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0
     0.000025 gettimeofday({1168294755, 189161}, NULL) = 0
     0.000031 poll([{fd=3, events=POLLOUT, revents=POLLOUT}], 1, 0) = 1
     0.000035 send(3, "\17h\1\0\0\1\0\0\0\0\0\0\5paulm\3com\0\0\34\0\1", 27, 0) = 27
     0.000091 poll([{fd=3, events=POLLIN}], 1, 5000) = 0
     5.000430 gettimeofday({1168294760, 189751}, NULL) = 0
     0.000030 poll([{fd=3, events=POLLOUT, revents=POLLOUT}], 1, 0) = 1
     0.000030 send(3, "\17h\1\0\0\1\0\0\0\0\0\0\5paulm\3com\0\0\34\0\1", 27, 0) = 27
     0.000067 poll([{fd=3, events=POLLIN}], 1, 5000) = 0
     5.013835 close(3)                  = 0

Simply trying the IPv4 query first, when the family is unspecified, would cut 10
seconds off every DNS lookup for programs that use getaddrinfo with explict
hints.  Code that explicitly requests either IPv4 or IPv6 should not be affected. 

I enclose a test program you can use to expose the problem, but you will only
see the delay if you stick it behind a DNS server that does not respond to
IPv6 queries.  Any old wirelesss router will probably do :-)

#include <netdb.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

main (int argc, char **argv) {
  if (argc == 3) {
    int rc;
    struct addrinfo *res;
    struct addrinfo hints;
    memset(&hints, 0, sizeof(hints));
    hints.ai_socktype = SOCK_STREAM;
    hints.ai_flags = AI_CANONNAME;
    rc = getaddrinfo(argv[1], argv[2], &hints, &res);
    printf("getaddrinfo returns %d\n", rc);
  } else {
    fprintf(stderr, "Usage: %s hostname port\n", argv[0]);
    return 1;
  }
}

-- 
           Summary: Request for getaddrinfo to search IPv4 before IPv6 when
                    family is PF_UNSPEC
           Product: glibc
           Version: 2.3.6
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: libc
        AssignedTo: drepper at redhat dot com
        ReportedBy: nr at eecs dot harvard dot edu
                CC: glibc-bugs at sources dot redhat dot com


http://sourceware.org/bugzilla/show_bug.cgi?id=3847

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/3847] Request for getaddrinfo to search IPv4 before IPv6 when family is PF_UNSPEC

[drepper at redhat dot com]

------- Additional Comments From drepper at redhat dot com  2007-01-09 01:25 -------
Not only do you not understand the code, you have not even looked at the latest
version of the file.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID


http://sourceware.org/bugzilla/show_bug.cgi?id=3847

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/3847] Request for getaddrinfo to search IPv4 before IPv6 when family is PF_UNSPEC

[nr at eecs dot harvard dot edu]

------- Additional Comments From nr at eecs dot harvard dot edu  2007-01-09 06:02 -------
Subject: Re:  Request for getaddrinfo to search IPv4 before IPv6 when family is PF_UNSPEC 

 > ------- Additional Comments From drepper at redhat dot com  2007-01-09
 > 01:25 ------- Not only do you not understand the code, you have not even
 > looked at the latest version of the file.

Thank you for your kind remarks.  I apologize for filing a request
against the wrong file.  I examined the latest version of the file
which is approved by the Debian people, because using the Debian libc6
is the only way for me to guarantee compatibility with hundreds of the
Debian packages that I use.

I'm puzzled by your thought that I don't understand the code.
It sure looks to me as if the while loop is trying each element
of the gaih array that is compatible with hints->ai_family.
And I did verify with gdb that this is the call that causes my machine
to sit and time out for 5 seconds, twice.  

Having downloaded version 2.5 and looked there, I guarantee I don't
understand that code.  But I've made a pass through it, and it's
become clear to me that I don't understand the specification of
getaddrinfo(3).  Neither the man page nor RFC 2553 have enlightened me
on this point, but perhaps you will be kind enough to do so: is
getaddrinfo() required to return a list containing *every* possible
protocol, family, and socket type available for the requested
host/service pair?  And if so, is there any way for me to configure
glibc version 2.5 to tell it that I wish PF_INET6 to be considered
completely and permanently unavailable?  If not, that's obviously the
request I should file.


Norman Ramsey

 >            What    |Removed                     |Added
 > ----------------------------------------------------------------------------
 >              Status|NEW                         |RESOLVED
 >          Resolution|                            |INVALID
 > 
 > http://sourceware.org/bugzilla/show_bug.cgi?id=3847


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=3847

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.