Re: HEADSUP: arp-v2 has been committed

On Monday 22 December 2008 10:55:34 Li, Qing wrote:
> Thank you all for patching these programs.
> 
> I scanned through your patches and they all look fine.
> Each one that I read through seems to be simple fix, which
> is what I hoped for.
> 
> Again, just to emphasize the points I made in my previous
> emails, the code that retrieves the ARP table by means
> of sysctl() does not have to check for the RTF_LLINFO
> entries in the returned list because the retrieved
> entries all belong to the ARP table.  For those programs
> that retrieve the routing table through the routing socket
> interface, the code that bypasses RTF_LLINFO entries can
> also be eliminated because the routing table does not
> contain any L2 information.

I'm looking into the Wine case, but don't have any experience with the
implementation of routing tables, so I need to have a few things
spelled out.

Wine currently uses:

 int mib[] = {CTL_NET, PF_ROUTE, 0, AF_INET, NET_RT_FLAGS, RTF_LLINFO};

I take it this returns all the entries which have the RTF_LLINFO flag
set? And to make this compile on CURRENT I have to change this into:

#ifdef RTF_LLINFO
 int mib[] = {CTL_NET, PF_ROUTE, 0, AF_INET, NET_RT_FLAGS, RTF_LLINFO};
#else
 int mib[] = {CTL_NET, PF_ROUTE, 0, AF_INET, NET_RT_FLAGS, 0};
#endif

Is AF_INET really the correct address family? What about AF_LINK and
AF_ARP? Is using NET_RT_FLAGS with flags mask 0 exactly the same as
using NET_RT_DUMP?


Also, at some other place, Wine wants to retrieve gateway entries and
it uses:

 int mib[6] = {CTL_NET, PF_ROUTE, 0, PF_INET, NET_RT_DUMP, 0};
                                     ^ this should be AF_INET I think

After that it runs over all entries counting only those which have
RTF_GATEWAY set and RTF_MULTICAST unset. Is the output of this
different now in CURRENT?