[Bug libc/160] New: if_nameindex has inconsistent behavior because of __opensock

[joshk at triplehelix dot org]

I recently used if_nameindex for some code in the Debian installer and found
that it had fairly erratic behavior depending on which kernel one is using.

This is the relevant part of the code with a test stub:
(The goal is to receive a char* list of nul-terminated interface names.)

char** get_ifaces (void)
{
  struct if_nameindex *o = if_nameindex(), *index = o;
  char** list = NULL;
  size_t len = 0;

  while (index->if_name)
  {
    if (strcmp(index->if_name, "lo"))
    {
      list = realloc(list, (len + 1) * sizeof(char**));
      list[len] = strdup(index->if_name);
      len++;
    }
    index++;
  }

  if_freenameindex(o);

  /* terminate the list */
  list = realloc(list, (len + 1) * sizeof(char**));
  list[len] = NULL;

  return list;
}

int main(void)
{
  char** interfaces = get_ifaces();
  while (*interfaces)
    puts(*interfaces++);
  return 0;
}

The specific output of this is not very important, but I found that

* on kernel 2.4.26 at least, it would only return interfaces which were
configured up with an IP address
* on kernel 2.6.6-mm1 it would return all interfaces, up or down.

Using strace provided a reason.

Strace log on 2.4:

access("/proc/net", R_OK)               = 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3
       ^^^^^^^
ioctl(3, 0x8912, 0xbffff9b4)            = 0
ioctl(3, 0x8912, 0xbffff9b4)            = 0
brk(0)                                  = 0x8050334
brk(0x8071334)                          = 0x8071334
brk(0)                                  = 0x8071334
brk(0x8072000)                          = 0x8072000
ioctl(3, 0x8933, 0xbffff910)            = 0
ioctl(3, 0x8933, 0xbffff930)            = 0
ioctl(3, 0x8933, 0xbffff950)            = 0
ioctl(3, 0x8933, 0xbffff970)            = 0
close(3)                                = 0

Strace log on 2.6:
access("/proc/net", R_OK)               = 0
access("/proc/net/unix", R_OK)          = 0
socket(PF_UNIX, SOCK_DGRAM, 0)          = 3
       ^^^^^^^
ioctl(3, 0x8912, 0xbffff904)            = 0
ioctl(3, 0x8912, 0xbffff904)            = 0
brk(0)                                  = 0x8051000
brk(0x8072000)                          = 0x8072000
brk(0)                                  = 0x8072000
ioctl(3, 0x8933, 0xbffff880)            = 0
ioctl(3, 0x8933, 0xbffff8a0)            = 0
ioctl(3, 0x8933, 0xbffff8c0)            = 0
close(3)                                = 0

As you can see some fairly different things happen here, even though
/proc/net/unix does exist on the 2.4.26 machine. I traced this down to
__opensock in glibc, but I can't figure out why the behavior is different.

Specifically, both machines are using glibc 2.3.2.ds1-12 from Debian.

What is going on here?

-- 
           Summary: if_nameindex has inconsistent behavior because of
                    __opensock
           Product: glibc
           Version: 2.3.2
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
        AssignedTo: gotom at debian dot or dot jp
        ReportedBy: joshk at triplehelix dot org
                CC: glibc-bugs at sources dot redhat dot com
 GCC build triplet: unknown
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i486-pc-linux-gnu


http://sources.redhat.com/bugzilla/show_bug.cgi?id=160

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