Difference in behaviour between getifaddrs() and ioctl(SIOCGIFCONF)

Corinna Vinschen corinna-cygwin@cygwin.com
Thu Dec 2 21:21:00 GMT 2010

On Dec  2 21:03, Jason Curl wrote:
> On 02/12/2010 18:59, Corinna Vinschen wrote:
> >On Dec  2 14:23, Jason Curl wrote:
> >>One of my use cases is to test a particular interface if it has an IP address
> >>or not (due to DHCP, AutoIP, etc.). Then on definition of an address, I can
> >>trigger a process. This assumes that the interface names remains constant. So a
> >>dynamically changing interface name is something I'd like to NOT see.
> >
> >Huh?  My proposal does exactly that.  It would always return unique
> >interface names.
> Maybe I don't understand your proposal. You want to assign an index
> name based on the IPv4 address. The "UUID:Index" is the complete
> interface name. It's unique for that IPv4 address, but as soon as
> its IP changes, so does the interface name.

Yeah, that's right.

> Then I think ioctl(SIOCGIFCONF) would also need to follow this
> behaviour. ioctl(SIOCGIFxxx) would also need to accept the interface
> names given.

It does so automatically, at least now.  Note that the current
behaviour, before the patch I applied today, was buggy per my
description.   The core function for ioctl and getifaddrs is the same,
get_xp_ifs.  The bug was that get_xp_ifs counted the index value per
address returned by the underlying Windows function, including for IPv6
addresses even though v6 addresses never actually used the index value.
The problem arose from the fact that get_xp_ifs only requests IPv4
addresses from Windows when called from ioctl, while it requests v4 and
v6 addresses when called from getifaddrs.  So the indices generated by
getifaddrs were not the same as the indices generated by ioctl.  My
today's patch fixed that.

> With Linux, QNX, FBSD, Solaris, I don't even need to use
> getifaddrs() or ioctl(SIOCGIFCONF), I can poll it directly with
> ioctl(SIOCGIFADDR) as normally the interfaces don't have an alias.

But that's just kind of a coincidence, given that you interface has only
a single v4 address configured.  And if so, you have the same in Cygwin
as well.  So, right now, you can do the same in Cygwin.  In 1.7.7 it
works when using ioctl(SIOCGIFCONF) to fetch the interface name, and
with my patch from today it will work with getifaddrs, too.

> With Cygwin 1.7.7 I can obtain a complete list once, use
> SIOCGIFFRNDLYNAM to find the interface name and then poll (only with

I don't understand why you request the friendly name at all.  It's not
required for this functionality and it's not a unique string.  It's only
used for the user interface.  The real unique interface name is what's
returned by SIOCGIFCONF, just like on Linux.  

> Now with the proposal, I need to obtain a complete list of all
> interfaces every time I poll, perform a check against
> SIOCGIFFRNDLYNAM, because the name of the interfaces themselves
> change.

Except they are unique up to the colon.  But I see our point.

>  Thus my suggestion that ioctl()
> from Cygwin support this ":index" format, which it currently
> doesn't, also in 1.7.7.

No, that's not right.  Try it.  As long as you don't use getifaddrs
it already works in 1.7.7.  The problem only arises when using getifaddrs.

> I'm also assuming, that IP address orders will only change if there
> is a change in the system configuration. So such a surprise won't
> occur too often. But importantly, interface names are known in
> advance with ioctl() without having to use SIOCGIFCONF.

Again, that's already the case today.

> And it provides for the minimalistic amount of change to Cygwin,
> remains compatible with other OSes and mappings continue to work
> with names returned by getifaddrs() and ioctl() - always.

Hmm.  I'll think about it.


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

More information about the Cygwin mailing list