Re: getifaddrs(3) returns 2 AF_LINK instances for the same interface

[Roy Marples <roy%marples.name@localhost>]

David Young wrote:
> On Fri, Apr 17, 2009 at 08:55:15PM +0100, Roy Marples wrote:
> > So something like this?
> >
> > Index: sys/net/rtsock.c
> > ===================================================================
> > RCS file: /cvsroot/src/sys/net/rtsock.c,v
> > retrieving revision 1.125
> > diff -u -p -r1.125 rtsock.c
> > --- sys/net/rtsock.c    2 Apr 2009 21:02:06 -0000       1.125
> > +++ sys/net/rtsock.c    17 Apr 2009 19:51:33 -0000
> > @@ -1061,7 +1061,8 @@ sysctl_iflist(int af, struct rt_walkarg
> >                         }
> >                 }
> >                 IFADDR_FOREACH(ifa, ifp) {
> > -                       if (af && af != ifa->ifa_addr->sa_family)
> > +                       if (ifa == ifp->if_dl ||
> > +                           (af && af != ifa->ifa_addr->sa_family))
> >                                 continue;
> >                         info.rti_info[RTAX_IFA] = ifa->ifa_addr;
> >                         info.rti_info[RTAX_NETMASK] = ifa->ifa_netmask;
>
> The kernel copies out the interface information in an RTM_IFINFO
> message, then each of the addresses in an RTM_NEWADDR message.  There
> is overlap between the _IFINFO and _NEWADDR information, but it's not
> a *total* overlap, so you really do have to copy out one _NEWADDR per
> ifaddr.

So what info is present in _NEWADDR that isn't in _IFINFO for ifp->if_dl?
How is userland supposed to pick the right AF_LINK or are they both right?

> Have another look at the doco and source for getifaddrs(3).  I think
> that if there is a bug, you will find it there.

I have checked and the last change of note was over 7 years ago.
So are you suggesting that getifaddrs(3) should ignore the _IFINFO 
message or somehow merge it into the _NEWADDR one - if it's present?

Thanks

Roy