Date: Tue, 10 Jun 2008 12:41:46 +0200
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: XP + cygwin version 1.7: problem with /proc/net/if_inet6 	format  and  if_indextoname
Message-ID: <20080610104146.GB32187@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <484C3B1B DOT 8000907 AT fliegl DOT de> <20080609173303 DOT GA22164 AT calimero DOT vinschen DOT de> <484D760C DOT 3090700 AT fliegl DOT de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <484D760C.3090700@fliegl.de>
User-Agent: Mutt/1.5.16 (2007-06-09)
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

On Jun  9 20:27, Deti Fliegl wrote:
> Corinna Vinschen wrote:
>> The scope values are not always equal to the index, as you can see in your
>> above output as well for the loopback.  It's also 0 for the addresses
>> with global scope.  The values are taken from the sin6_scope_id field
>> returned by the Win32 function GetAdaptersAddresses.  Compare with the
>> scope values printed by `ipconfig /all'.  Apparently the v6 stack in
>> XP uses (not quite) arbitrary numbers for local interfaces.  I don't
>> know the rules behind the choice, but apparently it has been fixed in
>> Vista.
> According to http://msdn.microsoft.com/en-us/library/ms803554.aspx and 
> http://msdn.microsoft.com/en-us/library/aa366357(VS.85).aspx the 
> SCOPE_LEVEL for link local addresses should be 2.
>
> BUT:
>
> The output of ipconfig /all varies between XP and Vista for link local 
> addresses:
> Vista: fe80:...%8
> XP: fe80:...%4

Yeah, for local scope the scope id is equivalent to the IPv6 interface
index.

> The same values can be found in the /proc/net/if_inet6 scope field. IMHO 
> this makes it impossible to rely on these values.
>
> Maybe there should be some scope tests (by IN6_IS_ADDR_* macros) in 
> winsup/cygwin/fhandler_procnet.cc to provide a consistent value.

I see.  Well, I put this on my TODO list.  It shouldn't be too tricky
to generate the same values as on Linux here.  But see below...

>> The flags field is the DAD state right now.  I'm looking through what I
>> did when I implemented that but I can't figure out anymore why I put the
>> DAD state into this field.  It looks like it should actually contain the
>> interface flags (IFF_* values).  Can somebody confirm or deny that?  If
>> that's correct, it's probably not a big deal to change that.
> Well the  DAD field is perfectly OK for me - because it's as close as 
> possible to the original definition. I just could not figure out the 
> meaning at the first glance ;-)

On second glance I found the flag values defined for this field on
Linux.  Looks like it wasn't such a bad idea to use the DAD state
after all...

> Try something like:
>         int i;
>         char name[IFNAMSIZ];
>         for(i=0;i<255;i++) {
>                 if (if_indextoname (i, name)) {
>                         printf("Index: %d, Name: %s\n",i, name);
>                 }
>         }

Try

  struct if_nameindex *ifs, *iff;
  ifs = if_nameindex ();
  for (iff = ifs; iff && iff->if_index; ++iff)
    printf ("index: 0x%x name: %s\n", iff->if_index, iff->if_name);
  if_freenameindex (ifs);

This solves the problem that you don't see all interfaces.
Unfortunately this shows that the interface indices are not always the
same as in /proc/net/if_inet6 on XP.  The underlying problem is that XP
has potentially two *different* interface indices for the same
interface, one for v4 and one for v6 :( I'll look into finding a better
solution.

> Compare the output between XP and Vista. In my place I get many {UUIDS} on 
> Vista:
> Index: 1, Name: {3D4E88D4-6A70-11DB-B1BA-806E6F6E6963}
> Index: 2, Name: {2F1F689C-4E19-439F-970B-9D3953DD3745}
> [...]
> On XP the function returns only few interfaces in UUID style and in a fully 
> resolved interface-name-style:
>
> Index: 0, Name: {571E18F0-10E9-4D0F-A998-FE68B6C687EC}
> Index: 1, Name: MS TCP Loopback interface

This is not a Cygwin problem.  On XP, the interface name of the IPv4
loopback device is NOT a UUID-style name(*).  The adapter name as well
as the so-called "friendly name" is "MS TCP Loopback interface".  On
Vista, there's no IPv4-specific loopback device anymore, just a generic
loopback device for v4 and v6 which has a UUID-style adapter name.

> IMHO it should return the same interface name as shown by ipconfig -
> otherwise there should exist a function to convert the UUID value into
> a human readable interface name.

There is already a way to get the so-called "friendly name" of an
interface.  However, this friendly name can not be used to identify
an interface unambiguously on Windows.  AFAIR from my testing, the
user can give two different interfaces the same friendly name.  Also,
the name can be up to 259 chars long. Therefore the "real" adapter
name is the one which should be used to unambiguously identify the
device. 

To get the friendly name of an interface, you can call ioctl.
Because the size of a friendly name is so big, and because this
is very Cygwin-specifc anyway, you have to specify a buffer for the
friendly name (See /usr/include/cygwin/if.h for the definitions):

  #include <net/if.h>

  struct ifreq ifr;
  struct ifreq_frndlyname iff;

  ifr.ifr_frndlyname = &iff;
  if (!ioctl (socket_desc, SIOCGIFFRNDLYNAM, &ifr))
    printf ("IF Name: %s, Friendly IF Name: %s\n",
            ifr.ifr_name, iff.ifrf_friendlyname);
  

Thanks for the report.  Btw., since I'm rather new to IPv6, I'd be very
glad to have some coding help with it.  I think I did the ground work,
but there's obviously quite a lot of polish missing so far.

http://cygwin.com/acronyms/#PTC


Thanks,
Corinna


(*) I can't help to note that the IPv6 implementation in XP is still
    marked as experimental.  So there are some flaws which are only
    really solved starting with Vista.  Not all these flaws can be
    worked around.  But, as I wrote above:

    http://cygwin.com/acronyms/#PTC
-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

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