Bug#312554: libc6: if_nameindex(3) returns broken list of network interfaces
GOMBAS Gabor <gombasg@sztaki.hu> writes:
> On Wed, Jun 08, 2005 at 08:30:42PM +0200, Hans Ulrich Niedermann wrote:
>
>> The returned list
>>
>> - does not contain "all network interface names" like the man page says.
>> It only includes those which have an IPv4 address configured on them.
>>
>> - does not contain "one [structure] for every interface present" like
>> the libc6 info page says.
>> It contains one if_nameindex structure for every IPv4 address
>> configured on the interface.
>
> Well, glibc 2.3.2 uses ioctl(SIOCGIFCONF) to get the list of network
> addresses. However the Linux kernel implements this ioctl for IPV4 only,
> and the IPV4 implementation returns one ifconf structure for every
> configured address. So what are you seeing is just glibc reporting
> whatever it gets from the kernel.
>
> You can try glibc 2.3.5 from experimental which AFAIK uses netlink
> instead of SIOCGIFCONF. However that may bring other problems since
> netlink is not a reliable protocol and it may drop messages if the
> machine is loaded.
According to the strace output,
- iproute2's "ip" utility does not use SIOCGIFCONF at all, relying
on netlink and SIOCGIFTXQLEN exclusively.
In my book, this makes using netlink kind of OK, as iproute2 is
in my book the "authority" on network configuration on Linux.
- "ifconfig" uses SIOCGIFCONF for the IPv4 interfaces, but also
scans /proc/net/if_inet6 for the IPv6 interfaces
OK, if you resort to /proc file scanning, /proc/net/dev would
probably be the better choice for implementing a if_nameindex()
function.
However, none of these technical details change the fact that the
Linux/glibc implementation currently contradicts both the glibc
documentation (info "(libc.info)Interface Naming") and the POSIX
standard defining the if_nameindex(3) interface (man 3posix
if_nameindex).
As a result, user software moves from this POSIX interface to
non-standard 3rd party libraries which actually do list all interfaces
when claiming to do so. Which is, at the very least, unfortunate.
Uli
Reply to: