RE: HEADSUP: arp-v2 has been committed

From: Li, Qing <qing.li_at_bluecoat.com>
Date: Sun, 21 Dec 2008 10:54:06 -0800
Yes, at least in the IPv4 case, I still generate the routing messages whenever entries are modified, so you can still wait for notifications on the routing socket. One should check for the address family AF_LINK type instead of checking for RTF_LLINFO flag. It's an over sight this note was not attached to the commit message.

There are two locations in ND6 where I temporarily disabled rtmsg generation pending further investigation. I have a note-to-self for that in the code comment.

Since only ARP entries are returned, you are in fact getting some performance gain. The userland application should also be simplified a little because the list walking code does not have to check for non-ARP entries.

-- Qing

-----Original Message-----
From: Hartmut Brandt <hartmut.brandt_at_dlr.de>
Sent: Sunday, December 21, 2008 8:54 AM
To: Kip Macy <kip.macy_at_gmail.com>
Cc: Vladimir Grebenschikov <vova_at_fbsd.ru>; Qing Li <qingli_at_freebsd.org>; freebsd-net_at_freebsd.org <freebsd-net_at_freebsd.org>; Gerald Pfeifer <gerald_at_pfeifer.com>; freebsd-current_at_freebsd.org <freebsd-current_at_freebsd.org>
Subject: Re: HEADSUP: arp-v2 has been committed

Kip Macy wrote:
> The flag is not needed. It is only possible to retrieve arp entries by
> way of sysctl. The converse of this is you no longer need to grab all
> the entries in the routing table and look at each one to determine
> which are cloned routes (dynamic host routes) which contain ARP
> entries.

Does this mean that the snmp daemon cannot monitor the arp entries 
through the routing socket anymore? This would be a performance issue, 
since it would have to fetch the ARP table from the kernel each time it 
is asked for. Now it refreshes the table only if it is older than 30 
seconds and in the mean time monitors routing messages.

harti

> 
> -Kip
> 
> On Sat, Dec 20, 2008 at 9:01 PM, Gerald Pfeifer <gerald_at_pfeifer.com> wrote:
>> The code in question on the Wine side is
>>
>> #if defined(HAVE_SYS_SYSCTL_H) && defined(NET_RT_DUMP)
>>  int mib[] = {CTL_NET, PF_ROUTE, 0, AF_INET, NET_RT_FLAGS, RTF_LLINFO};
>>
>> and there is nothing FreeBSD-specific in dlls/iphlpapi/ipstats.c as far
>> as I can see.
>>
>> If the arp-v2 update now made us incompatible both with earlier versions
>> of FreeBSD and Linux, that sounds like something that should be fixed
>> (instead of hacking applications like Wine).
>>
>> On the other hand, the commit message at
>>  http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/net/route.h
>> explicitly says
>>  The change in design obsoletes the semantics of RTF_CLONING,
>>  RTF_WASCLONE and RTF_LLINFO routing flags. The userland applications
>>  such as "arp" and "ndp" have been modified to reflect those changes.
>> so I guess it's not so easy.
>>
>> How many other ports are affected?
>>
>> What shall we do on the Wine front?  Simply #ifdef-ing out the code in
>> question may not be the best of ideas, either. :-(
>>
>> Gerald
>>
>> On Fri, 19 Dec 2008, Vladimir Grebenschikov wrote:
>>> On Mon, 15 Dec 2008 06:34:13 GMT, Qing Li <qingli_at_freebsd.org> wrote:
>>>
>>>>> The arp-v2 changes have been committed into HEAD.
>>>>> Please report problems to me and Kip Macy.
>>> Wine is not build any more:
>>>
>>> ...
>>> cc -c -I. -I. -I../../include -I../../include  -D__WINESRC__  -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -I/usr/local/include -O2 -pipe -fno-strict-aliasing  -o ipstats.o ipstats.c
>>> ipstats.c: In function 'getNumArpEntries':
>>> ipstats.c:1253: error: 'RTF_LLINFO' undeclared (first use in this function)
>>> ipstats.c:1253: error: (Each undeclared identifier is reported only once
>>> ipstats.c:1253: error: for each function it appears in.)
>>> ipstats.c: In function 'getArpTable':
>>> ipstats.c:1311: error: 'RTF_LLINFO' undeclared (first use in this function)
>>> ipstats.c:1311: warning: initialization makes integer from pointer without a cast
>>> gmake[2]: *** [ipstats.o] ?????? 1
>>> gmake[2]: Leaving directory `/usr/ports/emulators/wine/work/wine-1.1.10/dlls/iphlpapi'
>>> gmake[1]: *** [iphlpapi] ?????? 2
>>> gmake[1]: Leaving directory `/usr/ports/emulators/wine/work/wine-1.1.10/dlls'
>>> gmake: *** [dlls] ?????? 2
>>>
>>>
>> --
>> Gerald (Jerry) Pfeifer   gerald_at_pfeifer.com   http://www.pfeifer.com/gerald/
>> _______________________________________________
>> freebsd-net_at_freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-net
>> To unsubscribe, send any mail to "freebsd-net-unsubscribe_at_freebsd.org"
>>
> 
> 
> 

_______________________________________________
freebsd-net_at_freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe_at_freebsd.org"
Received on Sun Dec 21 2008 - 17:54:34 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:39 UTC