Inconsistent behaviour of getaddrinfo() with AI_ADDRCONFIG

Bug #583278 reported by Joachim Haga
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
glibc (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

If the AI_ADDRCONFIG flag is passed to getaddrinfo() with AF_INET or AF_INET6 address families, addresses in /etc/hosts are not resolved properly.

The following test case illustrates the problem. Its output depends on the configured networks, but if only "lo" is configured, the output is:
  Requested family: 2 [AF_INET]
  Error -2: Name or service not known
  Requested family: 10 [AF_INET6]
  Error -2: Name or service not known
  Requested family: 0 [AF_UNSPEC]
  Returned family: 10 [AF_INET6]
  ...
  Returned family: 2 [AF_INET]
  ...

This is inconsistent and wrong (explicit requests for INET or INET6 should both succeed, given the contents of /etc/hosts). /etc/hosts includes the lines:
  127.0.0.1 localhost
  ::1 localhost ip6-localhost ip6-loopback

I see a failure from this behaviour when mounting an NFS share from localhost when the network is down. It might be argued that AI_ADDRCONFIG is meaningless with explicit address families, in which case this is an NFS bug? But the current behaviour is surprising.

--------------------------------------
cat <<EOF >gai.c
#include <netdb.h>
#include <string.h>
#include <stdio.h>

void query(int family)
{
  struct addrinfo *ai;
  struct addrinfo hint = {
        .ai_family = family,
        .ai_flags = AI_ADDRCONFIG,
        };

  int ret = getaddrinfo("localhost", NULL, &hint, &ai);
  printf("Requested family: %d\n", hint.ai_family);
  if (ret == 0)
    while (ai) {
      printf("Returned family: %d\n", ai->ai_family);
      ai = ai->ai_next;
    }
  else
    printf("Error %d: %s\n", ret, gai_strerror(ret));
}

int
main()
{
  query(AF_INET);
  query(AF_INET6);
  query(AF_UNSPEC);
}
EOF
gcc -o gai gai.c
./gai

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

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

Changed in glibc (Ubuntu):
status: New → Confirmed
Revision history for this message
Pavel Šimerda (pavlix-a) wrote :
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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