X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-1.9 required=5.0	tests=AWL,BAYES_00,FREEMAIL_FROM,SPF_HELO_PASS,T_RP_MATCHES_RCVD,T_TO_NO_BRKTS_FREEMAIL
X-Spam-Check-By: sourceware.org
To: cygwin AT cygwin DOT com
From: Jason Curl <jcurlnews AT arcor DOT de>
Subject: Re: Difference in behaviour between getifaddrs() and ioctl(SIOCGIFCONF)
Date: Thu, 2 Dec 2010 14:23:02 +0000 (UTC)
Lines: 66
Message-ID: <loom.20101202T145411-365@post.gmane.org>
References: <id6eq6$un5$1 AT dough DOT gmane DOT org> <20101202114036 DOT GG30913 AT calimero DOT vinschen DOT de> <20101202133251 DOT GL30913 AT calimero DOT vinschen DOT de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
User-Agent: Loom/3.14 (http://gmane.org/)
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> I think there's a potential solution to this problem.  It just depends on
> how important it is.
> 

snip

> So here's the idea.  If we remove the braces from the GUID name, we drop
> 2 chars, so we have 6 chars left.  6 chars are enough to convert the
> IPv4 address into a radix-64 like string, using the l64a function.
> 
> For instance, in my case the aforementioned interface has the IPv4
> address 192.168.129.107.  That's 0xc0a8816b as long, which translates
> into "f36e.1" as radix-64 value per the l64a function.
> 
> So, for the above interface we get
> 
>   371D57D9-0FF3-402C-AB69-E88FF9D85BC3:f36e.1
> 
> as the unique alias name for the given IPv4 address.
> 
> Of course, if we do that, then all configured IPv4 address will always
> get an alias name like this.  Just skipping the alias extension for the
> first IPv4 address of an interface would not be an option.  Only the
> IPv6 addresses would use the interface name without alias.  I don't
> think that's actually a problem, though, but I'm not sure.
> 
> Any thoughts on this?  Is it worth it?

No - it's not worth it.

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.

The solution that I do prefer, is one similar to QNX. QNX behaves differently 
to Linux, but could be the simplest implementation for Cygwin. If an interface 
has aliases, it simply has multiple records in getifaddrs(). The ioctl() 
interface returns the main/preferred address. Cygwin could return the first 
AF_INET record in this case.

That is, you might very well see:
* en0, AF_INET, 192.168.0.1
* en0, AF_INET, 169.254.123.45
* en0, AF_INET6, <address>
* lo, AF_INET, 127.0.0.1

Having something similar to QNX would mean a much simpler implementation for 
Cygwin and I need to deal with the case of multiple addresses in my software in 
any case. The ioctl()s would all work as the native interface name is used 
(primarily I need SIOCGIFHWADDR, SIOCGIFFRNDLYNAM and others that are not 
implicitly given by getifaddrs()), which is not the case today, unless all ioctl
()s are also updated.

We also remove all uncertainty due to addresses being added and removed.

After detecting that an interface has an address, I can check if it is in a 
particular subnet or not myself, or just assume that if at least one IP is 
assigned, everything is OK and get a list of all addresses myself.

Linux inherently doesn't have this problem, as an alias once defined, behaves 
as an independent interface.

I'd like to hear your thoughts.
Jason.


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