Re: HEADSUP: arp-v2 has been committed

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_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"
>