Date: Tue, 23 Dec 2008 15:36:32 +0100 From: Hartmut Brandt <hartmut.brandt@dlr.de> To: "Li, Qing" <qing.li@bluecoat.com> Cc: Gerald Pfeifer <gerald@pfeifer.com>, Vladimir Grebenschikov <vova@fbsd.ru>, Kip Macy <kip.macy@gmail.com>, Qing Li <qingli@freebsd.org>, freebsd-current@freebsd.org, freebsd-net@freebsd.org Subject: Re: HEADSUP: arp-v2 has been committed Message-ID: <4950F770.3090700@dlr.de> In-Reply-To: <55f001c9639d$875f14ec$7202020a@internal.cacheflow.com> References: <55f001c9639d$875f14ec$7202020a@internal.cacheflow.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Li, Qing wrote:
> 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.
>
Actually I'm somewhat surprised at the moment. I looked at the actual
commit and saw that you've heavily changed src/contrib/bsnmp/snmp_mibII.
I don't think that was a good idea for several reasons:
- this is code maintained in another repository and imported to
FreeBSD. Luckily the cvs-times are over where this commit would have
taken the files of the vendor branch. But nevertheless it is never a
good idea to change code in contrib without pushing the changes upstream.
- you just removed a lot of code and left the ipNetToMedia table
entirely disfunctional.
- you obviously did not test the change. Otherwise you would have seen
that it did not work.
It took me several hours today to re-engineer usr.sbin/arp/arp.c and the
different files under sys/net and sys/netinet to understand how ARP
should work now, fixing an issue with half-baken routing messages while
beeing here. During this time I was puzzled in what strange state I
committed the SNMP stuff: functions that were never called, routing
messages that are not handled. Now looking at your commit I understand
how this happend.
And another point: when changing external interfaces it might be
possible to ask for a full port build with the changes to look for the
fall-out on ports. I would say that this commit was a good candidate to
get the port maintainers into the boat earlier.
not so happy,
harti
> -- Qing
>
> -----Original Message-----
> From: Hartmut Brandt <hartmut.brandt@dlr.de>
> Sent: Sunday, December 21, 2008 8:54 AM
> To: Kip Macy <kip.macy@gmail.com>
> Cc: Vladimir Grebenschikov <vova@fbsd.ru>; Qing Li <qingli@freebsd.org>; freebsd-net@freebsd.org <freebsd-net@freebsd.org>; Gerald Pfeifer <gerald@pfeifer.com>; freebsd-current@freebsd.org <freebsd-current@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@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@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@pfeifer.com http://www.pfeifer.com/gerald/
>>> _______________________________________________
>>> freebsd-net@freebsd.org mailing list
>>> http://lists.freebsd.org/mailman/listinfo/freebsd-net
>>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
>>>
>>>
>>
>>
>
> _______________________________________________
> freebsd-net@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4950F770.3090700>