From owner-freebsd-net@FreeBSD.ORG Sun Dec 21 18:47:57 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A3B81065670 for ; Sun, 21 Dec 2008 18:47:57 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 03CA28FC14 for ; Sun, 21 Dec 2008 18:47:56 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id mBLIltpT052013 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 21 Dec 2008 10:47:56 -0800 (PST) (envelope-from sam@freebsd.org) Message-ID: <494E8F5B.3060205@freebsd.org> Date: Sun, 21 Dec 2008 10:47:55 -0800 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.9 (X11/20071125) MIME-Version: 1.0 To: Hartmut Brandt References: <200812150634.mBF6YDVC060565@freefall.freebsd.org> <873agpk11i.fsf@kobe.laptop> <1229691231.1818.53.camel@localhost> <3c1674c90812202300y6dc37e89l7936880179f140b5@mail.gmail.com> <494E7481.1090606@dlr.de> In-Reply-To: <494E7481.1090606@dlr.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-sonic.net-Metrics: ebb.errno.com; whitelist Cc: Gerald Pfeifer , Vladimir Grebenschikov , Kip Macy , Qing Li , freebsd-current@freebsd.org, freebsd-net@freebsd.org Subject: Re: HEADSUP: arp-v2 has been committed X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Dec 2008 18:47:57 -0000 Hartmut Brandt wrote: > 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. If this really becomes an issue you could add a generation # to the arp table and watch for changes to trigger an update. Alternatively it's possible to push the arp table bits through the routing socket but that would likely require more work. We could also define new arp-specific msgs; e.g. to track changes (or just reuse the old msg format). Doing this however perpetuates the routing socket as a kitchen-sink-kinda mechanism--at some point it's worth creating an entirely new path for info like this with a proper TLV-style protocol and support for features like filtering. Sam > > harti > >> >> -Kip >> >> On Sat, Dec 20, 2008 at 9:01 PM, Gerald Pfeifer >> 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 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-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" > >