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

[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.

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

[roland at gnu dot org]

------- Additional Comments From roland at gnu dot org  2004-05-14 00:42 -------
You haven't given any reason why you think that opening a PF_INET vs a PF_UNIX
socket has anything to do with the error.  Did you actually do any investigation
to draw that conclusion?  Unless you have proof (i.e. a test program using both
socket types run on both kernels), there is no reason for us to believe that
this has anything to do with your issue.  The contents returned by the ioctls
are different on the two kernels, and that is almost surely the source of your
troubles.  Most likely, if any changes are needed at all they are kernel changes.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING


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.

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

[joshk at triplehelix dot org]

------- Additional Comments From joshk at triplehelix dot org  2004-05-14 01:19 -------
I think I leaped to that conclusion. My hasty logic was that a PF_INET socket fd
would only pick up interfaces set up with PF_INET, that is, IPv4, and PF_UNIX
would grab all interfaces.

I'll try to come up with a test program soon and see if I can force PF_UNIX to
be used on my 2.4 box, and see if it works. I'll basically need to copy the
nameindex/__opensock code out of glibc and customize it..

FWIW, the reason I reported this as a glibc bug was that

1) I was under the impression that the function was guaranteed to return _all_
network interfaces (cf.
http://www.opengroup.org/onlinepubs/009695399/functions/if_nameindex.html)
2) as such, glibc should take steps to ensure it works the same way on a variety
of system configurations.

-- 


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.

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

[v13 at priest dot com]

------- Additional Comments From v13 at priest dot com  2004-08-07 19:31 -------
I've the same problem using 2.6.7 
 
As far as i can see, if_nameindex uses SIOCGIFCONF to get a list of the 
interfaces and after that it uses SIOCGIFINDEX for each one of them. 
 
After taking a look in kernel sources I found that the ioctl returns one entry 
per interface configuration. Thus, it will return all configured interfaces 
(like eth0, eth0:1 etc) but not all interfaces. 
 
To test it just create a program that calls if_nameindex to get a list of all 
interfaces (lets say /tmp/i) and do this: 
 
(supposed that loopback has 127.0.0.1 configured): 
Run /tmp/i and you'll see loopback interface. 
# ifconfig lo 0.0.0.0 
Run /tmp/i and you won't see the loopback interface 
 
I believe you can see how that is expected behaviour (if I understand it 
correctly) at: /usr/src/linux/net/core/dev.h lines 2003-2005 of 2.6.7 (+imq 
patch) kernel where there is: 
 
for (dev = dev_base; dev; dev = dev->next) { 
  for (i = 0; i < NPROTO; i++) { 
    if (gifconf_list[i]) { 
      int done; 
      if (!pos) 
        done = gifconf_list[i](dev, NULL, 0); 
      else 
        done = gifconf_list[i](dev, pos + total,len - total); 
      if (done < 0) 
        return -EFAULT; 
      total += done; 
    } 
  } 
} 
 
I believe that interfaces without a configured address will not have a 
gifconf_list entry unless their net driver has its own function of reporting 
device addresses. 
 
This way it is impossible to discover interfaces like imq0. 
 
On my system, if_nameindex returns lo, eth0, eth0:1 and the netlink interface 
returns lo, imq0, imq1, irlan0, eth0, sit0 
 
It seems that the ifconfig (from net-tools) does what if_nameindex wanted to 
do by reading /proc/net/dev and then calling the SIOCGIFCONF ioctl and when it 
encounters two interfaces which match (it matches eth0 to eth0 *and* to 
eth0:1) then it creates a new list entry after the existing one, so it returns 
(with ifconfig -a) eth0, eth0:1, imq0, imq1, irlan0, lo, sit0 
 
Hope that helped... 
 

-- 


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.

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

[v13 at priest dot com]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |v13 at priest dot com


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.

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

[drepper at redhat dot com]

------- Additional Comments From drepper at redhat dot com  2004-08-09 07:36 -------
Current CVS glibc uses netlink for if_nameindex when possible.  The kernel
maintainers agreed the kernel handling of SIOCGIFCONF is inconsistent, but did
not want to change it.  Does not matter, since netlink provides the information.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|                            |FIXED


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.