X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
Date: Thu, 2 Dec 2010 18:59:54 +0100
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: Difference in behaviour between getifaddrs() and ioctl(SIOCGIFCONF)
Message-ID: <20101202175954.GO30913@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
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> <loom DOT 20101202T145411-365 AT post DOT gmane DOT org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <loom.20101202T145411-365@post.gmane.org>
User-Agent: Mutt/1.5.20 (2009-06-14)
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT 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

On Dec  2 14:23, Jason Curl wrote:
> 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.

Huh?  My proposal does exactly that.  It would always return unique
interface names.

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

Here's the problem.  Windows does not mark an IPv4 address as preferred
address, nor does it always return the addresses in the order you'd expect.
Actually, it appears as if the addresses of an interface are always returned
in ascending order (on W7, at least).

So, following your proposal, if you add an address which is numerically
lower than the other addresses, the next call to ioctl(SIOCGIFADDR) would
return the new address.  If you remove the address again it would return
the old address again.  From my POV this is as much surprising as the
current behaviour.  Hence my proposal.


Corinna

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