From owner-freebsd-net@FreeBSD.ORG Sun Dec 21 05:33:53 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 9EDEF1065674; Sun, 21 Dec 2008 05:33:53 +0000 (UTC) (envelope-from gerald@pfeifer.com) Received: from vexpert.dbai.tuwien.ac.at (vexpert.dbai.tuwien.ac.at [128.131.111.2]) by mx1.freebsd.org (Postfix) with ESMTP id 5D42F8FC26; Sun, 21 Dec 2008 05:33:53 +0000 (UTC) (envelope-from gerald@pfeifer.com) Received: from acrux.dbai.tuwien.ac.at (acrux [128.131.111.60]) by vexpert.dbai.tuwien.ac.at (Postfix) with ESMTP id 641BC3910F; Sun, 21 Dec 2008 06:01:28 +0100 (CET) Received: by acrux.dbai.tuwien.ac.at (Postfix, from userid 1203) id C70BD10059; Sun, 21 Dec 2008 06:01:35 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by acrux.dbai.tuwien.ac.at (Postfix) with ESMTP id AA07310055; Sun, 21 Dec 2008 06:01:35 +0100 (CET) Date: Sun, 21 Dec 2008 06:01:35 +0100 (CET) From: Gerald Pfeifer To: Vladimir Grebenschikov In-Reply-To: <1229691231.1818.53.camel@localhost> Message-ID: References: <200812150634.mBF6YDVC060565@freefall.freebsd.org> <873agpk11i.fsf@kobe.laptop> <1229691231.1818.53.camel@localhost> User-Agent: Alpine 1.99 (LSU 1142 2008-08-13) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: 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 05:33:53 -0000 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/ From owner-freebsd-net@FreeBSD.ORG Sun Dec 21 07:00:19 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 2EED71065670; Sun, 21 Dec 2008 07:00:19 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.224]) by mx1.freebsd.org (Postfix) with ESMTP id DE3968FC14; Sun, 21 Dec 2008 07:00:18 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so2953127rvf.43 for ; Sat, 20 Dec 2008 23:00:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=zY+NGdnaU8uOX8fRAG+c/4Wd105KkorKakNivCW42Ak=; b=gEej7u+flfJbFihl83A+DzxjACzjdR7NUnxq2YEEaPNoMTbfLVgpvwU+d0DYucNEX5 ETj+WOfmLy6g6nwgHBjNyIKa3T7sv4Td1AGkKu3hIVSgiHP/+g1LWZ7soGdVIlxhgMdI sUQXKD6CIPNSYRNWYzLvHIhdAY8k55kdLine8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=EAoppj+THIDZAew5JMx5+d0gVZoFkvNCxwegdW8ENMLb70XjK1AL7lmDwMhEiGuuvx u/RY7tlidL+B4USXXsXT9Zow5nRc/EsFUerOFxng6vvqvAvQY+pOzem6pPcIVu9q4yfA SI34yT4I/Y9RClfTIWbRsY8LWjf1a9LTHgkDA= Received: by 10.141.76.1 with SMTP id d1mr2523840rvl.110.1229842818076; Sat, 20 Dec 2008 23:00:18 -0800 (PST) Received: by 10.141.37.17 with HTTP; Sat, 20 Dec 2008 23:00:18 -0800 (PST) Message-ID: <3c1674c90812202300y6dc37e89l7936880179f140b5@mail.gmail.com> Date: Sat, 20 Dec 2008 23:00:18 -0800 From: "Kip Macy" Sender: mat.macy@gmail.com To: "Gerald Pfeifer" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200812150634.mBF6YDVC060565@freefall.freebsd.org> <873agpk11i.fsf@kobe.laptop> <1229691231.1818.53.camel@localhost> X-Google-Sender-Auth: 09d4d9ae3c4ed317 Cc: Vladimir Grebenschikov , 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 07:00:19 -0000 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. -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" > -- Als die Nazis die Kommunisten holten, habe ich geschwiegen; ich war ja kein Kommunist. Als sie die Sozialdemokraten einsperrten, habe ich geschwiegen; ich war ja kein Sozialdemokrat. Als sie die Gewerkschafter holten, habe ich nicht protestiert; ich war ja kein Gewerkschafter. Als sie die Juden holten, habe ich geschwiegen; ich war ja kein Jude. Als sie mich holten, gab es keinen mehr, der protestieren konnte. From owner-freebsd-net@FreeBSD.ORG Sun Dec 21 12:51:23 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 D1DAA106564A; Sun, 21 Dec 2008 12:51:23 +0000 (UTC) (envelope-from erwin@mail.droso.net) Received: from mail.droso.net (koala.ipv6.droso.net [IPv6:2001:6c8:6:c:20d:56ff:fe6f:f935]) by mx1.freebsd.org (Postfix) with ESMTP id 55D9F8FC08; Sun, 21 Dec 2008 12:51:23 +0000 (UTC) (envelope-from erwin@mail.droso.net) Received: by mail.droso.net (Postfix, from userid 1001) id 7DBE41CD33; Sun, 21 Dec 2008 13:51:21 +0100 (CET) Date: Sun, 21 Dec 2008 13:51:21 +0100 From: Erwin Lansing To: Gerald Pfeifer Message-ID: <20081221125120.GO23166@droso.net> References: <200812150634.mBF6YDVC060565@freefall.freebsd.org> <873agpk11i.fsf@kobe.laptop> <1229691231.1818.53.camel@localhost> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IJAclU0AInkryoed" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD/i386 7.1-PRERELEASE User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Vladimir Grebenschikov , 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 12:51:23 -0000 --IJAclU0AInkryoed Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Dec 21, 2008 at 06:01:35AM +0100, Gerald Pfeifer wrote: > The code in question on the Wine side is >=20 > #if defined(HAVE_SYS_SYSCTL_H) && defined(NET_RT_DUMP) > int mib[] =3D {CTL_NET, PF_ROUTE, 0, AF_INET, NET_RT_FLAGS, RTF_LLINFO}; >=20 > and there is nothing FreeBSD-specific in dlls/iphlpapi/ipstats.c as far > as I can see. =20 >=20 > If the arp-v2 update now made us incompatible both with earlier versions= =20 > of FreeBSD and Linux, that sounds like something that should be fixed=20 > (instead of hacking applications like Wine). >=20 > 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,=20 > RTF_WASCLONE and RTF_LLINFO routing flags. The userland applications=20 > such as "arp" and "ndp" have been modified to reflect those changes. > so I guess it's not so easy. =20 >=20 > How many other ports are affected? >=20 The latest full run with HEAD from a few days back hasn't quite finished yet, so there might turn up a few more, but so far it's just a handful: net/libdnet devel/libpdel net-mgmt/net-snmp net/netwib net/p5-Net-RawIP net-mgmt/net-snmp4 emulators/wine Cheers, -erwin --=20 Erwin Lansing http://droso.org erwin@FreeBSD.org You are now free to move around the cabin erwin@aauug.dk --IJAclU0AInkryoed Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iD8DBQFJTjvIqy9aWxUlaZARAg9QAKCFLhRPeFXNIRGvMt3kRkVJBhRQIwCePcFe hDq9V3NKI/dV0YX3eajNMxA= =2JE6 -----END PGP SIGNATURE----- --IJAclU0AInkryoed-- From owner-freebsd-net@FreeBSD.ORG Sun Dec 21 16:53:27 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 340221065673 for ; Sun, 21 Dec 2008 16:53:27 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp-1.dlr.de (smtp-1.dlr.de [195.37.61.185]) by mx1.freebsd.org (Postfix) with ESMTP id B8C108FC12 for ; Sun, 21 Dec 2008 16:53:26 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from [192.168.2.101] ([172.21.151.1]) by smtp-1.dlr.de with Microsoft SMTPSVC(6.0.3790.1830); Sun, 21 Dec 2008 17:53:24 +0100 Message-ID: <494E7481.1090606@dlr.de> Date: Sun, 21 Dec 2008 17:53:21 +0100 From: Hartmut Brandt Organization: German Aerospace Center User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Kip Macy References: <200812150634.mBF6YDVC060565@freefall.freebsd.org> <873agpk11i.fsf@kobe.laptop> <1229691231.1818.53.camel@localhost> <3c1674c90812202300y6dc37e89l7936880179f140b5@mail.gmail.com> In-Reply-To: <3c1674c90812202300y6dc37e89l7936880179f140b5@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Dec 2008 16:53:24.0248 (UTC) FILETIME=[A343F180:01C9638C] Cc: Vladimir Grebenschikov , Qing Li , freebsd-net@freebsd.org, Gerald Pfeifer , freebsd-current@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 16:53:27 -0000 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 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" >> > > > From owner-freebsd-net@FreeBSD.ORG Sun Dec 21 18:16:28 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from freefall.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with SMTP id C0648106564A; Sun, 21 Dec 2008 18:16:26 +0000 (UTC) (envelope-from nork@FreeBSD.org) Date: Mon, 22 Dec 2008 03:16:25 +0900 From: Norikatsu Shigemura To: "Kip Macy" , Erwin Lansing Message-Id: <20081222031625.63645f78.nork@FreeBSD.org> In-Reply-To: <20081221125120.GO23166@droso.net> References: <200812150634.mBF6YDVC060565@freefall.freebsd.org> <873agpk11i.fsf@kobe.laptop> <1229691231.1818.53.camel@localhost> <20081221125120.GO23166@droso.net> X-Mailer: Sylpheed 2.5.0 (GTK+ 2.12.11; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart=_Mon__22_Dec_2008_03_16_25_+0900_71N8EW_ClhzzwbMW" Cc: Gerald Pfeifer , Vladimir Grebenschikov , freebsd-net@freebsd.org, Norikatsu Shigemura , Qing Li , freebsd-current@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:16:28 -0000 This is a multi-part message in MIME format. --Multipart=_Mon__22_Dec_2008_03_16_25_+0900_71N8EW_ClhzzwbMW Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi Kip&Erwin! On Sun, 21 Dec 2008 13:51:21 +0100 Erwin Lansing wrote: > > 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? > The latest full run with HEAD from a few days back hasn't quite finished > yet, so there might turn up a few more, but so far it's just a handful: > net/libdnet > devel/libpdel > net-mgmt/net-snmp > net/netwib > net/p5-Net-RawIP > net-mgmt/net-snmp4 > emulators/wine Oh, just time! I'm having a trouble about this issue of devel/libpdel. So I fixed this issue of devel/libpdel. But I don't know that the attached patches are good. So please review these. --Multipart=_Mon__22_Dec_2008_03_16_25_+0900_71N8EW_ClhzzwbMW Content-Type: text/plain; name="patch-net-if_arp.c" Content-Disposition: attachment; filename="patch-net-if_arp.c" Content-Transfer-Encoding: 7bit --- net/if_arp.c.orig 2005-01-22 06:02:02.000000000 +0900 +++ net/if_arp.c 2008-12-22 02:49:58.000000000 +0900 @@ -124,7 +124,11 @@ mib[2] = 0; mib[3] = AF_INET; mib[4] = NET_RT_FLAGS; +#ifdef RTF_LLINFO mib[5] = RTF_LLINFO; +#else + mib[5] = 0; +#endif if (sysctl(mib, 6, NULL, &needed, NULL, 0) < 0) return (-1); needed += 128; @@ -227,9 +231,14 @@ sdl = (struct sockaddr_dl *)(void *) (ROUNDUP(sin->sin_len) + (char *)sin); if (sin->sin_addr.s_addr == sin_m.sin_addr.s_addr) { +#ifdef RTF_LLINFO if (sdl->sdl_family == AF_LINK && (rtm->rtm_flags & (RTF_LLINFO|RTF_GATEWAY)) == RTF_LLINFO) { +#else + if (sdl->sdl_family == AF_LINK && + !(rtm->rtm_flags & RTF_GATEWAY)) { +#endif switch (sdl->sdl_type) { case IFT_ETHER: case IFT_FDDI: --Multipart=_Mon__22_Dec_2008_03_16_25_+0900_71N8EW_ClhzzwbMW Content-Type: text/plain; name="patch-net-uroute.c" Content-Disposition: attachment; filename="patch-net-uroute.c" Content-Transfer-Encoding: 7bit --- net/uroute.c.orig 2005-01-22 06:02:03.000000000 +0900 +++ net/uroute.c 2008-12-22 02:53:23.000000000 +0900 @@ -74,9 +74,15 @@ ((a) > 0 ? (1 + (((a) - 1) | (sizeof(long) - 1))) : sizeof(long)) #define ADVANCE(x, n) ((x) += ROUNDUP((n)->sa_len)) +#ifdef RTF_LLINFO #define WRITABLE_FLAGS (RTF_STATIC | RTF_LLINFO | RTF_REJECT | RTF_BLACKHOLE \ | RTF_PROTO1 | RTF_PROTO2 | RTF_CLONING \ | RTF_XRESOLVE | RTF_UP | RTF_GATEWAY) +#else +#define WRITABLE_FLAGS (RTF_STATIC | RTF_REJECT | RTF_BLACKHOLE \ + | RTF_PROTO1 | RTF_PROTO2 | RTF_CLONING \ + | RTF_XRESOLVE | RTF_UP | RTF_GATEWAY) +#endif struct route_flag { const char *name; --Multipart=_Mon__22_Dec_2008_03_16_25_+0900_71N8EW_ClhzzwbMW-- 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" > > From owner-freebsd-net@FreeBSD.ORG Sun Dec 21 18:54:34 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 0BB951065673; Sun, 21 Dec 2008 18:54:34 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id E48F18FC08; Sun, 21 Dec 2008 18:54:33 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id mBLIsOqA003998; Sun, 21 Dec 2008 10:54:24 -0800 (PST) Received: from 10.2.2.114 ([10.2.2.114]) by bcs-mail03.internal.cacheflow.com ([10.2.2.95]) with Microsoft Exchange Server HTTP-DAV ; Sun, 21 Dec 2008 18:54:18 +0000 MIME-Version: 1.0 Message-ID: <55f001c9639d$875f14ec$7202020a@internal.cacheflow.com> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-class: From: "Li, Qing" X-MimeOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: HEADSUP: arp-v2 has been committed Thread-Index: AcljnYdfWUXWFzTlQF2w8blLs6aF/Q== Date: Sun, 21 Dec 2008 10:54:06 -0800 Importance: normal X-Priority: 3 To: "Hartmut Brandt" , "Kip Macy" Cc: Vladimir Grebenschikov , Qing Li , Gerald Pfeifer , 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:54:34 -0000 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 Sent: Sunday, December 21, 2008 8:54 AM To: Kip Macy Cc: Vladimir Grebenschikov ; Qing Li ; = freebsd-net@freebsd.org ; Gerald Pfeifer = ; 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=20 through the routing socket anymore? This would be a performance issue,=20 since it would have to fetch the ARP table from the kernel each time it=20 is asked for. Now it refreshes the table only if it is older than 30=20 seconds and in the mean time monitors routing messages. harti >=20 > -Kip >=20 > 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[] =3D {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" >> >=20 >=20 >=20 _______________________________________________ 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" From owner-freebsd-net@FreeBSD.ORG Sun Dec 21 19:09:56 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 34F46106564A; Sun, 21 Dec 2008 19:09:56 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id 1BE7F8FC14; Sun, 21 Dec 2008 19:09:56 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id mBLJ9qMQ004810; Sun, 21 Dec 2008 11:09:52 -0800 (PST) Received: from 10.2.2.114 ([10.2.2.114]) by bcs-mail03.internal.cacheflow.com ([10.2.2.95]) with Microsoft Exchange Server HTTP-DAV ; Sun, 21 Dec 2008 19:09:46 +0000 MIME-Version: 1.0 Message-ID: <561201c9639f$b096ac5c$7202020a@internal.cacheflow.com> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-class: From: "Li, Qing" X-MimeOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: HEADSUP: arp-v2 has been committed Thread-Index: Acljn7CWSP+qPheCR8S6rNzS/cH5rg== Date: Sun, 21 Dec 2008 11:09:40 -0800 Importance: normal X-Priority: 3 To: "Gerald Pfeifer" , "Vladimir Grebenschikov" Cc: 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 19:09:56 -0000 I am not entirely sure if that piece of code fragment you referred to is = OS agnostic. This code is very similar to another piece of code in mibII = at.c code where it checks for whether RTF_LLINFO is defined, however, = there is inconsistency in enforcement throughout that file. So far in the reported cases the code in question requires a simple = removal of that flag bit. One could go a little further and remove some = dead code. I am curious if there is a better approach to compatibility without = having to re-introduce RTF_LLINFO flag. -- Qing -----Original Message----- From: Gerald Pfeifer Sent: Sunday, December 21, 2008 4:06 AM To: Vladimir Grebenschikov Cc: Qing Li ; freebsd-current@freebsd.org = ; freebsd-net@freebsd.org = Subject: Re: HEADSUP: arp-v2 has been committed The code in question on the Wine side is #if defined(HAVE_SYS_SYSCTL_H) && defined(NET_RT_DUMP) int mib[] =3D {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. =20 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=20 (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,=20 RTF_WASCLONE and RTF_LLINFO routing flags. The userland applications=20 such as "arp" and "ndp" have been modified to reflect those changes. so I guess it's not so easy. =20 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: >=20 >>> The arp-v2 changes have been committed into HEAD. >>> Please report problems to me and Kip Macy. >=20 > Wine is not build any more:=20 >=20 > ... > 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 >=20 >=20 --=20 Gerald (Jerry) Pfeifer gerald@pfeifer.com = http://www.pfeifer.com/gerald/ _______________________________________________ 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" From owner-freebsd-net@FreeBSD.ORG Sun Dec 21 20:17:11 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 5E78F106564A for ; Sun, 21 Dec 2008 20:17:11 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outK.internet-mail-service.net (outk.internet-mail-service.net [216.240.47.234]) by mx1.freebsd.org (Postfix) with ESMTP id 344908FC1B for ; Sun, 21 Dec 2008 20:17:11 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id BE65E2408; Sun, 21 Dec 2008 12:17:11 -0800 (PST) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id EFACD2D6017; Sun, 21 Dec 2008 12:17:08 -0800 (PST) Message-ID: <494EA44E.4030303@elischer.org> Date: Sun, 21 Dec 2008 12:17:18 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) 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 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 20:17:11 -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. this is one of the things that worried me abuot the arp change, which is is that the change itself is fine but that I had no idea if LLINFO was BSD specific or if other ports and 3rd party code would rely on the connection between routing and ARP. maybe ARP activity should produce routing socket events. and maybe teh output should synthesize the missing entries. > > 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-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Sun Dec 21 23:47:47 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 E8CC11065673; Sun, 21 Dec 2008 23:47:47 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id CABE58FC16; Sun, 21 Dec 2008 23:47:47 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id mBLNlcox016338; Sun, 21 Dec 2008 15:47:38 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 21 Dec 2008 15:47:32 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: HEADSUP: arp-v2 has been committed Thread-Index: AcljqSw/KzsPCvP3RjidO+AYF7Rn0AAHD8YY References: <200812150634.mBF6YDVC060565@freefall.freebsd.org> <873agpk11i.fsf@kobe.laptop> <1229691231.1818.53.camel@localhost> <3c1674c90812202300y6dc37e89l7936880179f140b5@mail.gmail.com> <494E7481.1090606@dlr.de> <494EA44E.4030303@elischer.org> From: "Li, Qing" To: "Julian Elischer" , "Hartmut Brandt" 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 23:47:48 -0000 In earlier versions I had the kernel returning RTF_LLINFO back to the calling applications to provide a bit of compatibility. It's fairly straightforward for me to put that code back in.=20 The change is tiny in the application in majority of the cases=20 that I have seen. If these flags are obsolete and to be sure they won't linger forever, perhaps the right thing to do is removing=20 them and fix the applications as appropriate in 8.0 release.=20 -- Qing -----Original Message----- From: owner-freebsd-net@freebsd.org on behalf of Julian Elischer Sent: Sun 12/21/2008 12:17 PM To: Hartmut Brandt 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 =20 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. >=20 > Does this mean that the snmp daemon cannot monitor the arp entries=20 > 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=20 > is asked for. Now it refreshes the table only if it is older than 30=20 > seconds and in the mean time monitors routing messages. this is one of the things that worried me abuot the arp change, which=20 is is that the change itself is fine but that I had no idea if LLINFO was BSD specific or if other ports and 3rd party code would rely on=20 the connection between routing and ARP. maybe ARP activity should produce routing socket events. and maybe teh output should synthesize the missing entries. >=20 > harti >=20 >> >> -Kip >> >> On Sat, Dec 20, 2008 at 9:01 PM, Gerald Pfeifer =20 >> wrote: >>> The code in question on the Wine side is >>> >>> #if defined(HAVE_SYS_SYSCTL_H) && defined(NET_RT_DUMP) >>> int mib[] =3D {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__ =20 >>>> -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing=20 >>>> -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith=20 >>>> -I/usr/local/include -O2 -pipe -fno-strict-aliasing -o ipstats.o=20 >>>> ipstats.c >>>> ipstats.c: In function 'getNumArpEntries': >>>> ipstats.c:1253: error: 'RTF_LLINFO' undeclared (first use in this=20 >>>> 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=20 >>>> function) >>>> ipstats.c:1311: warning: initialization makes integer from pointer=20 >>>> without a cast >>>> gmake[2]: *** [ipstats.o] ?????? 1 >>>> gmake[2]: Leaving directory=20 >>>> `/usr/ports/emulators/wine/work/wine-1.1.10/dlls/iphlpapi' >>>> gmake[1]: *** [iphlpapi] ?????? 2 >>>> gmake[1]: Leaving directory=20 >>>> `/usr/ports/emulators/wine/work/wine-1.1.10/dlls' >>>> gmake: *** [dlls] ?????? 2 >>>> >>>> >>> --=20 >>> Gerald (Jerry) Pfeifer gerald@pfeifer.com =20 >>> 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" >>> >> >> >> >=20 > _______________________________________________ > 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" From owner-freebsd-net@FreeBSD.ORG Mon Dec 22 01:05:33 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 59B55106564A for ; Mon, 22 Dec 2008 01:05:33 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 2F7FA8FC08 for ; Mon, 22 Dec 2008 01:05:33 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 220561EAEFD; Sun, 21 Dec 2008 20:05:32 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute2.internal (MEProxy); Sun, 21 Dec 2008 20:05:32 -0500 X-Sasl-enc: pacEfdmy6eKXY87WQ/9cxtMjPGHn9LKKAYGwBdrcFvBw 1229907931 Received: from anglepoise.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 975864664F; Sun, 21 Dec 2008 20:05:31 -0500 (EST) Message-ID: <494EE7D9.5060000@incunabulum.net> Date: Mon, 22 Dec 2008 01:05:29 +0000 From: Bruce Simpson User-Agent: Thunderbird 2.0.0.18 (X11/20081204) MIME-Version: 1.0 To: Ferner Cilloniz References: <1229738406.5614.17.camel@mobiliare.Belkin> In-Reply-To: <1229738406.5614.17.camel@mobiliare.Belkin> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: sending arbitrary UDP packets from kernel module 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: Mon, 22 Dec 2008 01:05:33 -0000 Ferner Cilloniz wrote: > So i have done some research and reading and found that i need to call > either udp_send or udp_output. Can anyone help me out with providing the > proper arguments to these functions so i may call them and send > arbitrary UDP packets from a kernel module? > The NFS and BOOTP code would be the first place to look, it has a rather shonky way of creating a socket in-kernel so that an INPCB will be created, allowing you to send and receive UDP datagrams. Fire up KScope or similar and look at how it does it. cheers BMS From owner-freebsd-net@FreeBSD.ORG Mon Dec 22 01:19:38 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 3D48C106564A for ; Mon, 22 Dec 2008 01:19:38 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.230]) by mx1.freebsd.org (Postfix) with ESMTP id 059A58FC12 for ; Mon, 22 Dec 2008 01:19:37 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so3162694rvf.43 for ; Sun, 21 Dec 2008 17:19:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from :to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=0hPwVrmaxUcVV9rVydIPmUovq1h2cd5JPrSO6JKVWrk=; b=P0R3teq6Q6ofzyglo6USD6DYB/rVc59pUMUPLN6NICX40G8N+yqLWY7qrg23JsXg47 qubwZkydWXytCKYFugQclzEL4Z7/xn1EAMbrt6bCqUac8Qn03miVaLYMm99WefGp5pU+ +NKkgNUAZxlGzB281Z70J2PiU5GUN+HJrHsrE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=BbMNHPZ9NrTgEagsF2O3AoxyY86eTQzo0hSHSBrQ9GJvfP4FM1QCOzipRw6EmRIosw KTPuT8nFLcD+mMcKF7+hm1NN2G7TuAScCd6i6pmN2fD6ijw44eiiWvOwPENfGc6rEQ7i dAVNP8rSbLqV1VeMZgMH07WEAjVBshzL+7DuI= Received: by 10.141.29.18 with SMTP id g18mr2900273rvj.149.1229908777495; Sun, 21 Dec 2008 17:19:37 -0800 (PST) Received: from michelle.cdnetworks.co.kr ([211.53.35.84]) by mx.google.com with ESMTPS id k37sm8099845rvb.1.2008.12.21.17.19.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 21 Dec 2008 17:19:36 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id mBM1JUZW087149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Dec 2008 10:19:30 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id mBM1JT0Y087148; Mon, 22 Dec 2008 10:19:29 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Mon, 22 Dec 2008 10:19:29 +0900 From: Pyun YongHyeon To: Michael T?xen Message-ID: <20081222011929.GB86809@cdnetworks.co.kr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: FreeBSD Net Subject: Re: Checksum offloading X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Dec 2008 01:19:38 -0000 On Sat, Dec 20, 2008 at 10:31:39PM +0100, Michael T?xen wrote: > Dear all, > > I'm currently analyzing how TCP/UDP checksum offloading works > to find the best way to add SCTP checksum offloading. > > sys/mbuf.h has constants: > #define CSUM_IP 0x0001 /* will csum IP */ > #define CSUM_TCP 0x0002 /* will csum TCP */ > #define CSUM_UDP 0x0004 /* will csum UDP */ > which are used to signal which offloading is supported by the drive. > But, if I understand the code correctly, this only > applies to UDP/IPv4 and TCP/IPv4. > What about IPv6? Would this require flags like CSUM_TCP6 and CSUM_UDP6 > to signal that also offloading of UDP/IPv6 and TCP/IPv6 is supported? > > I'm asking this because we want to add CRC offloading for SCTP/IPv4 > and SCTP/IPv6. We could only add one flag CSUM_SCTP and use it > for IPv4 and IPv6 ar two flags CSUM_SCTP4 and CSUM_SCTP6... > I guess you're right. FreeBSD still lacks IPv6 checksum offloading related stuff. All recent hardwares support checksum offloading for TCP/UDP/IPv6 as well as TSO for IPv6. Don't know SCTP checksum offloading as I don't know any hardwares that can do SCTP checksum offloading. Sun Netptune might have the capability but I didn't check it though. > Best regards > Michael -- Regards, Pyun YongHyeon From owner-freebsd-net@FreeBSD.ORG Mon Dec 22 02:08:59 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 085DD1065677 for ; Mon, 22 Dec 2008 02:08:59 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.183]) by mx1.freebsd.org (Postfix) with ESMTP id CC0FA8FC16 for ; Mon, 22 Dec 2008 02:08:58 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by wa-out-1112.google.com with SMTP id m34so984318wag.27 for ; Sun, 21 Dec 2008 18:08:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=qTWOoAAR0WTjrHd+aCh5yn9MbUkLcYno4VOy0o+oBhg=; b=g8LJDA9li4pPQJxd6vKFqQ9RU7kYriez49mBA3fCPn7IN0L2F2ne/LxlUeA/NVw0al mNhzwmR1U97U7S64/C1XA6L3UWgyKIHY/tsoEaAEeY1WnLrXKyqbG0pxGN1BzXbvQg3I G1CTqjUbhtGTwf22rqxLIbE1q1fySULIpCtf8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=IyGAhen7Rl6rUEVJk4Q6R7C7VmHGp/arGKw0RbxK182EIF/WxtRnXyTWRVh/ZPWs2x SU2/lv0xkPRi+m+2UJEYUhPjOiAj413Gm9CRQ6r+iioZOXwn/wO/cVRF9UYfT0ADCSDy a/L/1VTk5WCn805ZtHlknDBowUmPBwiHrAVQI= Received: by 10.114.175.16 with SMTP id x16mr3667592wae.134.1229911738400; Sun, 21 Dec 2008 18:08:58 -0800 (PST) Received: by 10.114.12.2 with HTTP; Sun, 21 Dec 2008 18:08:58 -0800 (PST) Message-ID: <2a41acea0812211808y7178d2fp75467f19248d1be3@mail.gmail.com> Date: Sun, 21 Dec 2008 18:08:58 -0800 From: "Jack Vogel" To: pyunyh@gmail.com In-Reply-To: <20081222011929.GB86809@cdnetworks.co.kr> MIME-Version: 1.0 References: <20081222011929.GB86809@cdnetworks.co.kr> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Michael T?xen , FreeBSD Net Subject: Re: Checksum offloading 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: Mon, 22 Dec 2008 02:08:59 -0000 Our (Intel) hardware can do it, at least the newer adapters, and someone is working on it now btw. Jack On Sun, Dec 21, 2008 at 5:19 PM, Pyun YongHyeon wrote: > On Sat, Dec 20, 2008 at 10:31:39PM +0100, Michael T?xen wrote: > > Dear all, > > > > I'm currently analyzing how TCP/UDP checksum offloading works > > to find the best way to add SCTP checksum offloading. > > > > sys/mbuf.h has constants: > > #define CSUM_IP 0x0001 /* will csum IP */ > > #define CSUM_TCP 0x0002 /* will csum TCP */ > > #define CSUM_UDP 0x0004 /* will csum UDP */ > > which are used to signal which offloading is supported by the drive. > > But, if I understand the code correctly, this only > > applies to UDP/IPv4 and TCP/IPv4. > > What about IPv6? Would this require flags like CSUM_TCP6 and CSUM_UDP6 > > to signal that also offloading of UDP/IPv6 and TCP/IPv6 is supported? > > > > I'm asking this because we want to add CRC offloading for SCTP/IPv4 > > and SCTP/IPv6. We could only add one flag CSUM_SCTP and use it > > for IPv4 and IPv6 ar two flags CSUM_SCTP4 and CSUM_SCTP6... > > > > I guess you're right. FreeBSD still lacks IPv6 checksum offloading > related stuff. All recent hardwares support checksum offloading for > TCP/UDP/IPv6 as well as TSO for IPv6. Don't know SCTP checksum > offloading as I don't know any hardwares that can do SCTP checksum > offloading. Sun Netptune might have the capability but I didn't > check it though. > > > Best regards > > Michael > > -- > Regards, > Pyun YongHyeon > _______________________________________________ > 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" > From owner-freebsd-net@FreeBSD.ORG Mon Dec 22 03:15:28 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 87063106564A for ; Mon, 22 Dec 2008 03:15:28 +0000 (UTC) (envelope-from mailnull@mips.inka.de) Received: from mail-in-05.arcor-online.net (mail-in-05.arcor-online.net [151.189.21.45]) by mx1.freebsd.org (Postfix) with ESMTP id 3D5A08FC08 for ; Mon, 22 Dec 2008 03:15:28 +0000 (UTC) (envelope-from mailnull@mips.inka.de) Received: from mail-in-04-z2.arcor-online.net (mail-in-04-z2.arcor-online.net [151.189.8.16]) by mail-in-05.arcor-online.net (Postfix) with ESMTP id 9D3EE1834DE for ; Mon, 22 Dec 2008 04:15:25 +0100 (CET) Received: from mail-in-04.arcor-online.net (mail-in-04.arcor-online.net [151.189.21.44]) by mail-in-04-z2.arcor-online.net (Postfix) with ESMTP id 04DBDABE6E for ; Mon, 22 Dec 2008 04:15:25 +0100 (CET) Received: from lorvorc.mips.inka.de (dslb-088-067-116-226.pools.arcor-ip.net [88.67.116.226]) by mail-in-04.arcor-online.net (Postfix) with ESMTP id C02A91BF397 for ; Mon, 22 Dec 2008 04:15:23 +0100 (CET) Received: from lorvorc.mips.inka.de (localhost [127.0.0.1]) by lorvorc.mips.inka.de (8.14.3/8.14.3) with ESMTP id mBM3FNDV002211 for ; Mon, 22 Dec 2008 04:15:23 +0100 (CET) (envelope-from mailnull@lorvorc.mips.inka.de) Received: (from mailnull@localhost) by lorvorc.mips.inka.de (8.14.3/8.14.3/Submit) id mBM3FNR9002210 for freebsd-net@freebsd.org; Mon, 22 Dec 2008 04:15:23 +0100 (CET) (envelope-from mailnull) From: naddy@mips.inka.de (Christian Weisgerber) Date: Mon, 22 Dec 2008 03:15:23 +0000 (UTC) Message-ID: Originator: naddy@mips.inka.de (Christian Weisgerber) To: freebsd-net@freebsd.org X-Virus-Scanned: ClamAV 0.94.1/8789/Mon Dec 22 01:19:15 2008 on mail-in-04.arcor-online.net X-Virus-Status: Clean Subject: NDP breakage in -CURRENT 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: Mon, 22 Dec 2008 03:15:28 -0000 Something seems to be wrong with IPv6 neighbor discovery. FreeBSD lorvorc.mips.inka.de 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Sat Dec 20 17:46:35 CET 2008 naddy@lorvorc.mips.inka.de:/usr/obj/usr/src/sys/GENERIC amd64 This box is on a network that has IPv6. No exciting configuration, just ipv6_enable=YES and ipv6_defaultrouter and ipv6_ifconfig_nfe0 for a manually configured address. IPv6 with other hosts on the network and beyond works. However, clearing the NDP cache (ndp -c) kills IPv6 connectivity. The cache remains empty. tcpdump shows that neighbor solicitations are sent and advertisement received, but these replies seem to be ignored. ndp -a shows that no entries are added to the cache. This is a new problem. Fallout from arp-v2? -- Christian "naddy" Weisgerber naddy@mips.inka.de From owner-freebsd-net@FreeBSD.ORG Mon Dec 22 05:24:14 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 304F01065670; Mon, 22 Dec 2008 05:24:14 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 079CD8FC16; Mon, 22 Dec 2008 05:24:14 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id mBM5ODls071787; Mon, 22 Dec 2008 05:24:13 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mBM5ODq7071783; Mon, 22 Dec 2008 05:24:13 GMT (envelope-from linimon) Date: Mon, 22 Dec 2008 05:24:13 GMT Message-Id: <200812220524.mBM5ODq7071783@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/129793: [ip6] [patch] Locking related leaks in the kernel (routing handling) 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: Mon, 22 Dec 2008 05:24:14 -0000 Synopsis: [ip6] [patch] Locking related leaks in the kernel (routing handling) Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Dec 22 05:24:08 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=129793 From owner-freebsd-net@FreeBSD.ORG Mon Dec 22 05:50:05 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 76B771065670; Mon, 22 Dec 2008 05:50:05 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id 6155E8FC0C; Mon, 22 Dec 2008 05:50:05 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id mBM5o4WN006312; Sun, 21 Dec 2008 21:50:04 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 21 Dec 2008 21:49:19 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NDP breakage in -CURRENT Thread-Index: Aclj46BxVYNt7CC8QfeH3Ln7cjzqSAAFWfhC References: From: "Li, Qing" To: "Christian Weisgerber" , Cc: current@freebsd.org Subject: RE: NDP breakage in -CURRENT 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: Mon, 22 Dec 2008 05:50:05 -0000 Yes, probably a bug introduced by arp-v2, I will investigate and get back to you. -- Qing -----Original Message----- From: owner-freebsd-net@freebsd.org on behalf of Christian Weisgerber Sent: Sun 12/21/2008 7:15 PM To: freebsd-net@freebsd.org Subject: NDP breakage in -CURRENT =20 Something seems to be wrong with IPv6 neighbor discovery. FreeBSD lorvorc.mips.inka.de 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Sat Dec = 20 17:46:35 CET 2008 = naddy@lorvorc.mips.inka.de:/usr/obj/usr/src/sys/GENERIC amd64 This box is on a network that has IPv6. No exciting configuration, just ipv6_enable=3DYES and ipv6_defaultrouter and ipv6_ifconfig_nfe0 for a manually configured address. IPv6 with other hosts on the network and beyond works. However, clearing the NDP cache (ndp -c) kills IPv6 connectivity. The cache remains empty. tcpdump shows that neighbor solicitations are sent and advertisement received, but these replies seem to be ignored. ndp -a shows that no entries are added to the cache. This is a new problem. Fallout from arp-v2? --=20 Christian "naddy" Weisgerber naddy@mips.inka.de _______________________________________________ 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" From owner-freebsd-net@FreeBSD.ORG Mon Dec 22 06:26:37 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 78821106564A; Mon, 22 Dec 2008 06:26:37 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 1584A8FC16; Mon, 22 Dec 2008 06:26:31 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Subject:Message-ID:Reply-To:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender; b=CL3TjAQ6dyyk8wcpE5KmdwP+NhqnKA+3lVEFxbBhoxZvun9X/Ja4ZlxVUUrgWMaY31p4nD0LJ4rbaYW5wMnRVQ4nh5y1R1k4r5AjrWuS97geHjO3Z8rGfKqzmeLe3V7SpRwM/OHOhJEDcOImkY+RU4uU3X29j0SG3+fo8rvur+c=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1LEeFJ-0002tK-OG; Mon, 22 Dec 2008 09:26:29 +0300 Date: Mon, 22 Dec 2008 09:26:28 +0300 From: Eygene Ryabinkin To: Uwe Grohnwaldt Message-ID: <2Bap5VDKzT7zMmPiWYyBFNrSahA@R1iWMyMbby3vqLLqlL15VaO5FRQ> References: <494954FD.8050708@grohnwaldt.eu> <5c0ff6a70812171217w1f19b185v7f8d3defde6c4deb@mail.gmail.com> <49496783.1090805@grohnwaldt.eu> <5c0ff6a70812171259rd32459bu7b77ffc9eb8ef7b@mail.gmail.com> <20081217210718.GA73545@onelab2.iet.unipi.it> <494974F7.7080408@grohnwaldt.eu> <49499D47.5040509@grohnwaldt.eu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YS7t75H5cNTCpbja" Content-Disposition: inline In-Reply-To: <49499D47.5040509@grohnwaldt.eu> Sender: rea-fbsd@codelabs.ru Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: [Fwd: em0 disappeared] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rea-fbsd@codelabs.ru List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Dec 2008 06:26:37 -0000 --YS7t75H5cNTCpbja Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Uwe, good day. Thu, Dec 18, 2008 at 01:45:59AM +0100, Uwe Grohnwaldt wrote: > Maksim Yevmenkin wrote: > > older tyan motherboards. when i upgraded from 7.x to current (amd64 > > arch) both onboard bge nics disappeared. i had to go to the bios > > screen and set "installed os" (or something like that) to "linux". > > other choices were "windows" and "other" (default). > > > The problem is: it is a rented Strato-Server. So I have no access to the > bios. Then the first thing to provide is the output from the verbose boot of the system in question. In your case the system isn't event seeing the PCI device (NIC), so it will be very good to get two outputs: from the system where you had your card recognized and from one that doesn't recognise it. Another thing to try is to disable ACPI. This seems to be very uneasy step -- for me, 8-CURRENT without ACPI wasn't been able to find even the disks, so you likely will want to use nextboot(8). But may be some ACPI-related things are plaing their role, so this is worth to try it. At least it helped me in the past on some systems. --=20 Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual =20 )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook=20 {_.-``-' {_/ # --YS7t75H5cNTCpbja Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAklPMxQACgkQthUKNsbL7YhOPACdGvHm7ESICz6YD0iEr6Ri4v4s IAIAnR01cCIc+Zup7Svv02UsLuxgqKEr =hbld -----END PGP SIGNATURE----- --YS7t75H5cNTCpbja-- From owner-freebsd-net@FreeBSD.ORG Mon Dec 22 07:14:20 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 186C4106564A; Mon, 22 Dec 2008 07:14:20 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id DB7E98FC08; Mon, 22 Dec 2008 07:14:18 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id mBM7EHj6011818; Sun, 21 Dec 2008 23:14:17 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 21 Dec 2008 23:12:46 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NDP breakage in -CURRENT Thread-Index: Aclj46BxVYNt7CC8QfeH3Ln7cjzqSAAFWfhCAALqHqU= References: From: "Li, Qing" To: "Li, Qing" , "Christian Weisgerber" , Cc: current@freebsd.org Subject: RE: NDP breakage in -CURRENT 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: Mon, 22 Dec 2008 07:14:20 -0000 Please sync ./src/sys/netinet6/in6.c to=20 SVN rev 186392 on 2008-12-22 07:11:15Z by qingli Let me know how it works out for you. -- Qing -----Original Message----- From: owner-freebsd-net@freebsd.org on behalf of Li, Qing Sent: Sun 12/21/2008 9:49 PM To: Christian Weisgerber; freebsd-net@freebsd.org Cc: current@freebsd.org Subject: RE: NDP breakage in -CURRENT =20 Yes, probably a bug introduced by arp-v2, I will investigate and get back to you. -- Qing -----Original Message----- From: owner-freebsd-net@freebsd.org on behalf of Christian Weisgerber Sent: Sun 12/21/2008 7:15 PM To: freebsd-net@freebsd.org Subject: NDP breakage in -CURRENT =20 Something seems to be wrong with IPv6 neighbor discovery. FreeBSD lorvorc.mips.inka.de 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Sat Dec = 20 17:46:35 CET 2008 = naddy@lorvorc.mips.inka.de:/usr/obj/usr/src/sys/GENERIC amd64 This box is on a network that has IPv6. No exciting configuration, just ipv6_enable=3DYES and ipv6_defaultrouter and ipv6_ifconfig_nfe0 for a manually configured address. IPv6 with other hosts on the network and beyond works. However, clearing the NDP cache (ndp -c) kills IPv6 connectivity. The cache remains empty. tcpdump shows that neighbor solicitations are sent and advertisement received, but these replies seem to be ignored. ndp -a shows that no entries are added to the cache. This is a new problem. Fallout from arp-v2? --=20 Christian "naddy" Weisgerber naddy@mips.inka.de _______________________________________________ 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" From owner-freebsd-net@FreeBSD.ORG Mon Dec 22 08:29:30 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 238A31065688; Mon, 22 Dec 2008 08:29:30 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from inbound01.jnb1.gp-online.net (inbound01.jnb1.gp-online.net [41.161.16.135]) by mx1.freebsd.org (Postfix) with ESMTP id 54FA68FC13; Mon, 22 Dec 2008 08:29:28 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from [41.241.101.159] (helo=clue.co.za) by inbound01.jnb1.gp-online.net with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1LEfm9-0002Um-Ow; Mon, 22 Dec 2008 10:04:29 +0200 Received: from localhost ([127.0.0.1] helo=clue.co.za) by clue.co.za with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LEfm2-000BPk-Rs; Mon, 22 Dec 2008 10:04:22 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Erwin Lansing From: Ian FREISLICH In-Reply-To: <20081221125120.GO23166@droso.net> X-Attribution: BOFH Mime-Version: 1.0 Content-Type: multipart/mixed ; boundary="==_Exmh_1229933021_14280" Date: Mon, 22 Dec 2008 10:04:22 +0200 Message-Id: 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: Mon, 22 Dec 2008 08:29:30 -0000 This is a multipart MIME message. --==_Exmh_1229933021_14280 Content-Type: text/plain; charset=us-ascii Erwin Lansing wrote: > > 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? > The latest full run with HEAD from a few days back hasn't quite finished > yet, so there might turn up a few more, but so far it's just a handful: > net/libdnet > devel/libpdel > net-mgmt/net-snmp > net/netwib > net/p5-Net-RawIP > net-mgmt/net-snmp4 > emulators/wine You can add net/quagga to that list as well. The following patch solves it, and you'll need patch-lib-sockopt.c for multicast to work correctly on -CURRENT. -- Ian Freislich --==_Exmh_1229933021_14280 Content-Type: text/plain ; name="patch-zebra-kernel_socket.c"; charset=us-ascii Content-Description: patch-zebra-kernel_socket.c Content-Disposition: attachment; filename="patch-zebra-kernel_socket.c" --- zebra/kernel_socket.c.orig 2008-12-22 09:59:00.000000000 +0200 +++ zebra/kernel_socket.c 2008-12-22 09:59:10.000000000 +0200 @@ -173,9 +173,13 @@ #ifdef RTF_MASK {RTF_MASK, "MASK"}, #endif /* RTF_MASK */ +#ifdef RTF_CLONING {RTF_CLONING, "CLONING"}, +#endif /* RTF_CLONING */ {RTF_XRESOLVE, "XRESOLVE"}, +#ifdef RTF_LLINFO {RTF_LLINFO, "LLINFO"}, +#endif /* RTF_LLINFO */ {RTF_STATIC, "STATIC"}, {RTF_BLACKHOLE, "BLACKHOLE"}, #ifdef RTF_PRIVATE @@ -999,9 +1003,11 @@ if (gate && message == RTM_ADD) msg.rtm.rtm_flags |= RTF_GATEWAY; +#ifdef RTF_CLONING if (! gate && message == RTM_ADD && ifp && (ifp->flags & IFF_POINTOPOINT) == 0) msg.rtm.rtm_flags |= RTF_CLONING; +#endif */ RTF_CLONING */ /* If no protocol specific gateway is specified, use link address for gateway. */ --==_Exmh_1229933021_14280 Content-Type: text/plain ; name="patch-lib-sockopt.c"; charset=us-ascii Content-Description: patch-lib-sockopt.c Content-Disposition: attachment; filename="patch-lib-sockopt.c" --- lib/sockopt.c.orig 2007-08-21 18:32:56.000000000 +0200 +++ lib/sockopt.c 2008-08-13 09:07:20.000000000 +0200 @@ -231,6 +231,7 @@ else mreqn.imr_address = if_addr; + mreqn.imr_address = if_addr; ret = setsockopt(sock, IPPROTO_IP, optname, (void *)&mreqn, sizeof(mreqn)); if ((ret < 0) && (optname == IP_ADD_MEMBERSHIP) && (errno == EADDRINUSE)) --==_Exmh_1229933021_14280-- From owner-freebsd-net@FreeBSD.ORG Mon Dec 22 09:40:27 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 ADD85106564A; Mon, 22 Dec 2008 09:40:27 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 521398FC18; Mon, 22 Dec 2008 09:40:27 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Subject:Message-ID:Reply-To:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender; b=OITeQaCtT1SeEV8F+fItK7h9Vz1HqeHUOze9pGFwjulO1rUqZz3KghSGwqBXQbuEKcfwR4agbeH6A2V1CbQ1PkEdvLbQ/iiAI4f3Yng8Shr4arRJ2AzctP8d47O+tvlqhrzoa1iNEg53pdIiPxDB58Duy2XC1SudjV+bBLamfOs=; Received: from shadow.pikenet.ru (school.pikenet.ru [85.30.229.242]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1LEhGv-000HAE-6R; Mon, 22 Dec 2008 12:40:22 +0300 Date: Mon, 22 Dec 2008 12:40:17 +0300 From: Eygene Ryabinkin To: freebsd-current@freebsd.org, freebsd-net@freebsd.org Message-ID: References: <20081221125120.GO23166@droso.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ctP54qlpMx3WjD+/" Content-Disposition: inline In-Reply-To: Sender: rea-fbsd@codelabs.ru Cc: Gerald Pfeifer , Vladimir Grebenschikov , Kip Macy , Qing Li , Ian FREISLICH , Erwin Lansing Subject: Re: HEADSUP: arp-v2 has been committed X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rea-fbsd@codelabs.ru List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Dec 2008 09:40:27 -0000 --ctP54qlpMx3WjD+/ Content-Type: multipart/mixed; boundary="kORqDWCi7qDJ0mEj" Content-Disposition: inline --kORqDWCi7qDJ0mEj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Greetings! Mon, Dec 22, 2008 at 10:04:22AM +0200, Ian FREISLICH wrote: > Erwin Lansing wrote: > > > RTF_WASCLONE and RTF_LLINFO routing flags. The userland application= s=20 > > > such as "arp" and "ndp" have been modified to reflect those changes. > > > so I guess it's not so easy. =20 > > > How many other ports are affected? > > The latest full run with HEAD from a few days back hasn't quite finished > > yet, so there might turn up a few more, but so far it's just a handful: > > net/libdnet > > devel/libpdel > > net-mgmt/net-snmp > > net/netwib > > net/p5-Net-RawIP > > net-mgmt/net-snmp4 > > emulators/wine > > You can add net/quagga to that list as well. net/openospfd is also affected. Attached is the simple patch to take into account the withdrawal of RTF_LLINFO. Perhaps something else should be done -- I'll up some -CURRENT systems and will try to test the Real Stuff (TM). --=20 Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual =20 )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook=20 {_.-``-' {_/ # --kORqDWCi7qDJ0mEj Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="Fix-usage-of-RTF_LLINFO-due-to-the-ARP-v2-changes.diff" Content-Transfer-Encoding: quoted-printable =46rom 1138f09b72a42ddb7b35780da0e51a0b378bea1b Mon Sep 17 00:00:00 2001 =46rom: Eygene Ryabinkin Date: Mon, 22 Dec 2008 12:13:13 +0300 Subject: [PATCH] Fix usage of RTF_LLINFO due to the ARP-v2 changes ARP-v2, commited in SVN rev 186119, eliminated RTF_WASCLONE, RTF_CLONING and RTF_LLINFO, http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/net/route.h?rev=3D1.77 The latter flag was used in OpenOSPFD to skip ARP entries from the routing table. We're just conditionalizing the code on the existence of RTF_LLINFO variable. Perhaps checking __FreeBSD__ value will be better: errors due to the non-included net/route.h won't be spotted in the former case. But since many RTF_* constants are used in kroute.c, this shouldn't be a problem, at least now. Signed-off-by: Eygene Ryabinkin --- ospfd/kroute.c | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/ospfd/kroute.c b/ospfd/kroute.c index b46fa30..acc2a32 100644 --- a/ospfd/kroute.c +++ b/ospfd/kroute.c @@ -1174,8 +1174,10 @@ fetchtable(void) if ((sa =3D rti_info[RTAX_DST]) =3D=3D NULL) continue; =20 +#if defined(RTF_LLINFO) /* FreeBSD dropped RTF_LLINFO after ARP-v2 rework = */ if (rtm->rtm_flags & RTF_LLINFO) /* arp cache */ continue; +#endif /* defined(RTF_LLINFO) */ =20 if ((kr =3D calloc(1, sizeof(struct kroute_node))) =3D=3D NULL) { log_warn("fetchtable"); @@ -1371,8 +1373,10 @@ dispatch_rtmsg(void) if (rtm->rtm_errno) /* failed attempts... */ continue; =20 +#if defined(RTF_LLINFO) /* FreeBSD dropped RTF_LLINFO after ARP-v2 rework = */ if (rtm->rtm_flags & RTF_LLINFO) /* arp cache */ continue; +#endif /* defined(RTF_LLINFO) */ =20 #ifdef RTF_MPATH if (rtm->rtm_flags & RTF_MPATH) --=20 1.6.0.4 --kORqDWCi7qDJ0mEj-- --ctP54qlpMx3WjD+/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAklPYIAACgkQthUKNsbL7YhAiACfULidRafQfojEhiDMPMW16RNU XEoAn3x552kwJuoC2fkqaaAk8ASLK3u2 =pjPd -----END PGP SIGNATURE----- --ctP54qlpMx3WjD+/-- From owner-freebsd-net@FreeBSD.ORG Mon Dec 22 09:56:01 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 C03DF1065674; Mon, 22 Dec 2008 09:56:01 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id 89C6A8FC22; Mon, 22 Dec 2008 09:56:01 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id mBM9tep0025276; Mon, 22 Dec 2008 01:55:40 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 22 Dec 2008 01:55:34 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: HEADSUP: arp-v2 has been committed Thread-Index: AclkGZbkPMJpOFPYTQuW1eHqlBXE2QAARJEL References: <20081221125120.GO23166@droso.net> From: "Li, Qing" To: , , Cc: Gerald Pfeifer , Vladimir Grebenschikov , Kip Macy , Qing Li , Ian FREISLICH , Erwin Lansing 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: Mon, 22 Dec 2008 09:56:01 -0000 Thank you all for patching these programs. I scanned through your patches and they all look fine.=20 Each one that I read through seems to be simple fix, which=20 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=20 that retrieve the routing table through the routing socket interface, the code that bypasses RTF_LLINFO entries can=20 also be eliminated because the routing table does not contain any L2 information.=20 -- Qing -----Original Message----- From: owner-freebsd-net@freebsd.org on behalf of Eygene Ryabinkin Sent: Mon 12/22/2008 1:40 AM To: freebsd-current@freebsd.org; freebsd-net@freebsd.org Cc: Gerald Pfeifer; Vladimir Grebenschikov; Kip Macy; Qing Li; Ian = FREISLICH; Erwin Lansing Subject: Re: HEADSUP: arp-v2 has been committed =20 Greetings! Mon, Dec 22, 2008 at 10:04:22AM +0200, Ian FREISLICH wrote: > Erwin Lansing wrote: > > > RTF_WASCLONE and RTF_LLINFO routing flags. The userland = applications=20 > > > such as "arp" and "ndp" have been modified to reflect those = changes. > > > so I guess it's not so easy. =20 > > > How many other ports are affected? > > The latest full run with HEAD from a few days back hasn't quite = finished > > yet, so there might turn up a few more, but so far it's just a = handful: > > net/libdnet > > devel/libpdel > > net-mgmt/net-snmp > > net/netwib > > net/p5-Net-RawIP > > net-mgmt/net-snmp4 > > emulators/wine > > You can add net/quagga to that list as well. net/openospfd is also affected. Attached is the simple patch to take into account the withdrawal of RTF_LLINFO. Perhaps something else should be done -- I'll up some -CURRENT systems and will try to test the Real Stuff (TM). --=20 Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual =20 )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook=20 {_.-``-' {_/ # From owner-freebsd-net@FreeBSD.ORG Mon Dec 22 10:41:13 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 B45241065670; Mon, 22 Dec 2008 10:41:13 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 5BAE78FC12; Mon, 22 Dec 2008 10:41:13 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Subject:Message-ID:Reply-To:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender; b=Di3Wh+psstIlmUIv7RYO8HscKmSfQSIpJQ9xE+80qh6kl+EczSlR3PSlYM2tS/qf7aTivnvkSJ3+zcG86A2adkU/FIZVwf0ZEkkZKAHyEtuY5+HjRsfmpFeCxsNpGm4RaB1CqEolfMMwxrpK+tJYRAJV+3Q4RALP1q4I3/1Zb0g=; Received: from shadow.pikenet.ru (school.pikenet.ru [85.30.229.242]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1LEiDl-000LdZ-7A; Mon, 22 Dec 2008 13:41:10 +0300 Date: Mon, 22 Dec 2008 13:40:58 +0300 From: Eygene Ryabinkin To: "Li, Qing" Message-ID: References: <20081221125120.GO23166@droso.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="r7U+bLA8boMOj+mD" Content-Disposition: inline In-Reply-To: Sender: rea-fbsd@codelabs.ru Cc: Ian FREISLICH , Gerald Pfeifer , Vladimir Grebenschikov , freebsd-net@freebsd.org, Qing Li , freebsd-current@freebsd.org, Kip Macy , Erwin Lansing Subject: Re: HEADSUP: arp-v2 has been committed X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rea-fbsd@codelabs.ru List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Dec 2008 10:41:13 -0000 --r7U+bLA8boMOj+mD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Li, good day. Mon, Dec 22, 2008 at 01:55:34AM -0800, Li, Qing wrote: > Thank you all for patching these programs. Thank you for your work! > 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. Are you going to submit the patches for affected ports by yourself or individual persons should do it? For me, it does not matter what route you will take, I just want to know how to proceed ;)) --=20 Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual =20 )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook=20 {_.-``-' {_/ # --r7U+bLA8boMOj+mD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAklPbrkACgkQthUKNsbL7YjSjQCfQeuZzjER3L7q5a9ZzQAxOygs 1ZQAnAqEoGcha9ORtUAUIUd7PSpu5ux1 =Vsdo -----END PGP SIGNATURE----- --r7U+bLA8boMOj+mD-- From owner-freebsd-net@FreeBSD.ORG Mon Dec 22 11:06:55 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 BFCB91065675 for ; Mon, 22 Dec 2008 11:06:55 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id AD1B88FC29 for ; Mon, 22 Dec 2008 11:06:55 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id mBMB6tvL060649 for ; Mon, 22 Dec 2008 11:06:55 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mBMB6tn1060645 for freebsd-net@FreeBSD.org; Mon, 22 Dec 2008 11:06:55 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 22 Dec 2008 11:06:55 GMT Message-Id: <200812221106.mBMB6tn1060645@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-net@FreeBSD.org 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: Mon, 22 Dec 2008 11:06:55 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/129793 net [ip6] [patch] Locking related leaks in the kernel (rou o kern/129750 net [ath] Atheros AR5006 exits on "cannot map register spa o kern/129719 net [tcp] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129580 net [ndis] Netgear WG311v3 (ndis) causes kenel trap at boo o kern/129517 net [ipsec] [panic] double fault / stack overflow o kern/129508 net [panic] Kernel panic with EtherIP (may be related to S o kern/129352 net [xl] [patch] xl0 watchdog timeout o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129135 net [vge] vge driver on a VIA mini-ITX not working f kern/129074 net [ppp] [panic] kernel panic with pppoe_server o kern/128917 net [wpi] [panic] if_wpi and wpa+tkip causing kernel panic o kern/128884 net [msk] if_msk page fault while in kernel mode o kern/128840 net [igb] page fault under load with igb/LRO o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128598 net [bluetooth] WARNING: attempt to net_add_domain(bluetoo o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o conf/128334 net [request] use wpa_cli in the "WPA DHCP" situation o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o kern/128247 net [ip6] [panic] Fatal Trap 12 in ip6_forward = o conf/128030 net [request] Isn't it time to enable IPsec in GENERIC? o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127928 net [tcp] [patch] TCP bandwidth gets squeezed every time t o kern/127834 net [ixgbe] [patch] wrong error counting o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net arp: Segmentation fault (core dumped) s kern/127587 net [bge] [request] if_bge(4) doesn't support BCM576X fami f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/127102 net [wpi] Intel 3945ABG low throughput o kern/127057 net [udp] Unable to send UDP packet via IPv6 socket to IPv o kern/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126945 net [carp] CARP interface destruction with ifconfig destro o kern/126924 net [an] [patch] printf -> device_printf and simplify prob o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o bin/126822 net wpa_supplicant(8): WPA PSK does not work in adhoc mode o kern/126714 net [carp] CARP interface renaming makes system no longer o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126688 net [ixgbe] [patch] 1.4.7 ixgbe driver panic with 4GB and f kern/126564 net [ath] doesn't work with my PCI-E X1 wireless network a o kern/126561 net [nlm] [patch] NLM (rpclockd) RPC UNLOCK failure (stall o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126469 net [fxp] [panic] fxp(4) related kernel panic o kern/126339 net [ipw] ipw driver drops the connection o kern/126214 net [ath] txpower problem with Atheros wifi card o kern/126075 net [in] Network: internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [if_bridge] carp stuck in init when using bridg f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre f kern/125195 net [fxp] fxp(4) driver failed to initialize device Intel o kern/125079 net [ppp] host routes added by ppp with gateway flag (regr o kern/124904 net [fxp] EEPROM corruption with Compaq NC3163 NIC o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/124753 net [ieee80211] net80211 discards power-save queue packets o kern/124609 net [ipsec] [panic] ipsec 'remainder too big' panic with p o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124127 net [msk] watchdog timeout (missed Tx interrupts) -- recov o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o kern/123892 net [tap] [patch] No buffer space available o kern/123881 net [tcp] Turning on TCP blackholing causes slow localhost o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123617 net [tcp] breaking connection when client downloading file o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) f kern/123200 net [netgraph] Server failure due to netgraph mpd and dhcp f kern/123172 net [bce] Watchdog timeout problems with if_bce o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/123066 net [ipsec] [panic] kernel trap with ipsec o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122928 net [em] interface watchdog timeouts and stops receiving p f kern/122839 net [multicast] FreeBSD 7 multicast routing problem p kern/122794 net [lagg] Kernel panic after brings lagg(8) up if NICs ar o kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix o kern/122743 net [panic] vm_page_unwire: invalid wire count: 0 o kern/122697 net [ath] Atheros card is not well supported o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi o kern/122427 net [apm] [panic] apm and mDNSResponder cause panic during o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal f kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122195 net [ed] Alignment problems in if_ed o kern/122068 net [ppp] ppp can not set the correct interface with pptpd o kern/122058 net [em] [panic] Panic on em1: taskq o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup [reg o kern/121983 net [fxp] fxp0 MBUF and PAE o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] LOR icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/120966 net [rum] kernel panic with if_rum and WPA encryption p docs/120945 net [PATCH] ip6(4) man page lacks documentation for TCLASS o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [panic] gnugk causes kernel panic when closing UDP soc o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119361 net [bge] bge(4) transmit performance problem o kern/119345 net [ath] Unsuported Atheros 5424/2424 and CPU speedstep n o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor o kern/118880 net [ip6] IP_RECVDSTADDR & IP_SENDSRCADDR not implemented a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o kern/118727 net [netgraph] [patch] [request] add new ng_pf module o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116328 net [bge]: Solid hang with bge interface o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/116077 net [ip] [patch] 6.2-STABLE panic during use of multi-cast o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/114839 net [fxp] fxp looses ability to speak with traffic o kern/114714 net [gre][patch] gre(4) is not MPSAFE and does not support o kern/113842 net [ip6] PF_INET6 proto domain state can't be cleared wit o kern/112722 net [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/109733 net [bge] bge link state issues [regression] o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/108542 net [bce]: Huge network latencies with 6.2-RELEASE / STABL o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o conf/107035 net [patch] bridge interface given in rc.conf not taking a o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o conf/102502 net [patch] ifconfig name does't rename netgraph node in n o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear o kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo f kern/92552 net A serious bug in most network drivers from 5.X to 6.X o kern/92090 net [bge] bge0: watchdog timeout -- resetting s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if p kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/64556 net [sis] if_sis short cable fix problems with NetGear FA3 s kern/60293 net FreeBSD arp poison patch o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o conf/23063 net [PATCH] for static ARP tables in rc.network 201 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Dec 22 11:48:38 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 2A9E91065670 for ; Mon, 22 Dec 2008 11:48:38 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:203:6dff:fe1a:4ddc]) by mx1.freebsd.org (Postfix) with ESMTP id C77698FC1B for ; Mon, 22 Dec 2008 11:48:37 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from [10.1.1.54] ([10.1.1.54]) (authenticated bits=0) by lakerest.net (8.14.1/8.14.1) with ESMTP id mBMBmZO6064840 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 22 Dec 2008 06:48:35 -0500 (EST) (envelope-from rrs@lakerest.net) Message-Id: <7723D33A-A87F-4CEC-93E6-7D11BCDC849C@lakerest.net> From: Randall Stewart To: freebsd-net Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 22 Dec 2008 06:48:35 -0500 X-Mailer: Apple Mail (2.929.2) Subject: ACE and FreeBSD 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: Mon, 22 Dec 2008 11:48:38 -0000 Hi all: I am trying to get the latest ACE/TAO toolkit compiling with Head... (the port is marked broken in 7).. In the process of fixing things I found something I am not sure how to approach.. for now I have just ifdef'd it out but maybe someone can point me to the right method... They are using a ioctl -- SIOCGIFDATA -- to get access to the interface packet counts and such. Now near as I can tell we don't have that SIO. A google of someone a few years ago where the question was asked turned up a, we don't need that instead we should have access to this information via the sysctl. So my immediate thought, hey netstat does this.. and it probably uses the sysctl... so I go and look at the code.. and tada.. it does a kread() to get the actual if_data .... yuck. So, is there a sysctl that gets access to this information? I have poked around in a sysctl -a -N and don't see anything that looks promising.. Pointers to the right approach would be appreciated.. I am not sure what the monitor stuff is used for.. but I would like to get this toolkit fully functional if possible :-) R ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct) From owner-freebsd-net@FreeBSD.ORG Mon Dec 22 12:21:27 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 EE8761065676 for ; Mon, 22 Dec 2008 12:21:27 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id DF3E68FC1E for ; Mon, 22 Dec 2008 12:21:27 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 9F3A71A3C4B; Mon, 22 Dec 2008 04:21:27 -0800 (PST) Date: Mon, 22 Dec 2008 04:21:27 -0800 From: Alfred Perlstein To: Randall Stewart Message-ID: <20081222122127.GO18389@elvis.mu.org> References: <7723D33A-A87F-4CEC-93E6-7D11BCDC849C@lakerest.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7723D33A-A87F-4CEC-93E6-7D11BCDC849C@lakerest.net> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net Subject: Re: ACE and FreeBSD 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: Mon, 22 Dec 2008 12:21:28 -0000 * Randall Stewart [081222 03:48] wrote: > Hi all: > > I am trying to get the latest ACE/TAO toolkit compiling with Head... > (the > port is marked broken in 7).. > > In the process of fixing things I found something I am not sure how > to approach.. for now I have just ifdef'd it out but maybe someone > can point me to the right method... > > They are using a ioctl -- SIOCGIFDATA -- to get access to the interface > packet counts and such. Now near as I can tell we don't have that > SIO. A google of someone a few years ago where the question was > asked turned up a, we don't need that instead we should have > access to this information via the sysctl. > > So my immediate thought, hey netstat does this.. and it probably uses > the sysctl... so I go and look at the code.. and tada.. it does a > kread() to get the actual if_data .... yuck. > > So, is there a sysctl that gets access to this information? I have > poked around in a sysctl -a -N and don't see anything that looks > promising.. > > Pointers to the right approach would be appreciated.. I am not sure > what the monitor stuff is used for.. but I would like to get this > toolkit fully functional if possible :-) You could expand SIOCGIFDATA, but you'd need to make a compat SIOCGIFODATA (OLD DATA) ioctl. Or you could export it maybe through the dev sysctl tree. I like the former. -Alfred From owner-freebsd-net@FreeBSD.ORG Mon Dec 22 13:37:25 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 2CC131065673 for ; Mon, 22 Dec 2008 13:37:25 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 08C638FC17 for ; Mon, 22 Dec 2008 13:37:25 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTP id 85D6346B46; Mon, 22 Dec 2008 08:37:24 -0500 (EST) Date: Mon, 22 Dec 2008 13:37:24 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Bruce Simpson In-Reply-To: <494EE7D9.5060000@incunabulum.net> Message-ID: References: <1229738406.5614.17.camel@mobiliare.Belkin> <494EE7D9.5060000@incunabulum.net> User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, Ferner Cilloniz Subject: Re: sending arbitrary UDP packets from kernel module 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: Mon, 22 Dec 2008 13:37:25 -0000 On Mon, 22 Dec 2008, Bruce Simpson wrote: > Ferner Cilloniz wrote: > >> So i have done some research and reading and found that i need to call >> either udp_send or udp_output. Can anyone help me out with providing the >> proper arguments to these functions so i may call them and send arbitrary >> UDP packets from a kernel module? > > The NFS and BOOTP code would be the first place to look, it has a rather > shonky way of creating a socket in-kernel so that an INPCB will be created, > allowing you to send and receive UDP datagrams. Fire up KScope or similar > and look at how it does it. I would encourage this approach, if the application model works with it, as it allows using the existing socket infrastruture to reserve the port/ip tuple and avoid conflicts with userspace, use existing buffering on the receive side, etc. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-net@FreeBSD.ORG Mon Dec 22 14:16:35 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 B7B95106564A; Mon, 22 Dec 2008 14:16:35 +0000 (UTC) (envelope-from naddy@mips.inka.de) Received: from mail-in-10.arcor-online.net (mail-in-10.arcor-online.net [151.189.21.50]) by mx1.freebsd.org (Postfix) with ESMTP id 69A068FC29; Mon, 22 Dec 2008 14:16:35 +0000 (UTC) (envelope-from naddy@mips.inka.de) Received: from mail-in-09-z2.arcor-online.net (mail-in-09-z2.arcor-online.net [151.189.8.21]) by mail-in-10.arcor-online.net (Postfix) with ESMTP id 5FD511F5980; Mon, 22 Dec 2008 14:44:08 +0100 (CET) Received: from mail-in-09.arcor-online.net (mail-in-09.arcor-online.net [151.189.21.49]) by mail-in-09-z2.arcor-online.net (Postfix) with ESMTP id 36A2928EDD2; Mon, 22 Dec 2008 14:44:08 +0100 (CET) Received: from lorvorc.mips.inka.de (dslb-092-075-199-214.pools.arcor-ip.net [92.75.199.214]) by mail-in-09.arcor-online.net (Postfix) with ESMTP id 103E43425F6; Mon, 22 Dec 2008 14:44:08 +0100 (CET) Received: from lorvorc.mips.inka.de (localhost [127.0.0.1]) by lorvorc.mips.inka.de (8.14.3/8.14.3) with ESMTP id mBMDi7Tg001930; Mon, 22 Dec 2008 14:44:07 +0100 (CET) (envelope-from naddy@lorvorc.mips.inka.de) Received: (from naddy@localhost) by lorvorc.mips.inka.de (8.14.3/8.14.3/Submit) id mBMDi7ct001929; Mon, 22 Dec 2008 14:44:07 +0100 (CET) (envelope-from naddy) Date: Mon, 22 Dec 2008 14:44:07 +0100 From: Christian Weisgerber To: "Li, Qing" Message-ID: <20081222134407.GA1898@lorvorc.mips.inka.de> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) X-Virus-Scanned: ClamAV 0.94.1/8791/Mon Dec 22 11:54:23 2008 on mail-in-09.arcor-online.net X-Virus-Status: Clean Cc: freebsd-net@freebsd.org, current@freebsd.org Subject: Re: NDP breakage in -CURRENT 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: Mon, 22 Dec 2008 14:16:35 -0000 Li, Qing: > Please sync ./src/sys/netinet6/in6.c to > > SVN rev 186392 on 2008-12-22 07:11:15Z by qingli = rev 1.92 in the CVS export > Let me know how it works out for you. Yes, that fixes the problem. Thanks! -- Christian "naddy" Weisgerber naddy@mips.inka.de From owner-freebsd-net@FreeBSD.ORG Mon Dec 22 15:18:07 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 6B055106564A for ; Mon, 22 Dec 2008 15:18:07 +0000 (UTC) (envelope-from sem@FreeBSD.org) Received: from mail.ciam.ru (mail.ciam.ru [212.34.63.72]) by mx1.freebsd.org (Postfix) with ESMTP id 27B928FC2F for ; Mon, 22 Dec 2008 15:18:07 +0000 (UTC) (envelope-from sem@FreeBSD.org) Received: from dhcp250-188.yandex.ru ([87.250.250.188]) by mail.ciam.ru with esmtpa (Exim 4.x) id 1LEmXk-0006ET-KH; Mon, 22 Dec 2008 18:18:04 +0300 Message-ID: <494FAFAC.90802@FreeBSD.org> Date: Mon, 22 Dec 2008 18:18:04 +0300 From: Sergey Matveychuk User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Ian FREISLICH References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Gerald Pfeifer , Vladimir Grebenschikov , Kip Macy , Qing Li , freebsd-current@freebsd.org, freebsd-net@freebsd.org, Erwin Lansing 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: Mon, 22 Dec 2008 15:18:07 -0000 Ian FREISLICH wrote: > --- lib/sockopt.c.orig 2007-08-21 18:32:56.000000000 +0200 > +++ lib/sockopt.c 2008-08-13 09:07:20.000000000 +0200 > @@ -231,6 +231,7 @@ > else > mreqn.imr_address = if_addr; > > + mreqn.imr_address = if_addr; > ret = setsockopt(sock, IPPROTO_IP, optname, > (void *)&mreqn, sizeof(mreqn)); > if ((ret < 0) && (optname == IP_ADD_MEMBERSHIP) && (errno == EADDRINUSE)) > I don't catch your idea here. Can you explain it please? A result code looks ugly: if (ifindex) mreqn.imr_ifindex = ifindex; else mreqn.imr_address = if_addr; mreqn.imr_address = if_addr; ret = setsockopt(sock, IPPROTO_IP, optname, ... -- Dixi. Sem. From owner-freebsd-net@FreeBSD.ORG Mon Dec 22 15:20:32 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 912DB1065670 for ; Mon, 22 Dec 2008 15:20:32 +0000 (UTC) (envelope-from sem@FreeBSD.org) Received: from mail.ciam.ru (mail.ciam.ru [212.34.63.72]) by mx1.freebsd.org (Postfix) with ESMTP id 50C8A8FC1B for ; Mon, 22 Dec 2008 15:20:32 +0000 (UTC) (envelope-from sem@FreeBSD.org) Received: from dhcp250-188.yandex.ru ([87.250.250.188]) by mail.ciam.ru with esmtpa (Exim 4.x) id 1LEma7-0006LY-42; Mon, 22 Dec 2008 18:20:31 +0300 Message-ID: <494FB03F.1010005@FreeBSD.org> Date: Mon, 22 Dec 2008 18:20:31 +0300 From: Sergey Matveychuk User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Randall Stewart References: <7723D33A-A87F-4CEC-93E6-7D11BCDC849C@lakerest.net> In-Reply-To: <7723D33A-A87F-4CEC-93E6-7D11BCDC849C@lakerest.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net Subject: Re: ACE and FreeBSD 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: Mon, 22 Dec 2008 15:20:32 -0000 Randall Stewart wrote: > Hi all: > > I am trying to get the latest ACE/TAO toolkit compiling with Head... (the > port is marked broken in 7).. > Could you take the port and upgrade/fix it? I did not use ace+tao for ages and can't support it anymore. -- Dixi. Sem. From owner-freebsd-net@FreeBSD.ORG Mon Dec 22 15:40:30 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 F40771065673 for ; Mon, 22 Dec 2008 15:40:29 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from proxy.meer.net (proxy.meer.net [64.13.141.13]) by mx1.freebsd.org (Postfix) with ESMTP id D50648FC13 for ; Mon, 22 Dec 2008 15:40:29 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mail.meer.net (mail.meer.net [64.13.141.3]) by proxy.meer.net (8.14.2/8.14.2) with ESMTP id mBMFSBo5014436; Mon, 22 Dec 2008 07:28:11 -0800 (PST) (envelope-from gnn@neville-neil.com) Received: from mail2.meer.net (mail2.meer.net [64.13.141.16]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id mBMFS3wv016569; Mon, 22 Dec 2008 07:28:03 -0800 (PST) (envelope-from gnn@neville-neil.com) Received: from gnnbsd.hudson-trading.com.neville-neil.com (209.249.190.8.available.above.net [209.249.190.8] (may be forged)) (authenticated bits=0) by mail2.meer.net (8.14.1/8.14.1) with ESMTP id mBMFS3ga041496; Mon, 22 Dec 2008 07:28:03 -0800 (PST) (envelope-from gnn@neville-neil.com) Date: Mon, 22 Dec 2008 10:28:02 -0500 Message-ID: <7ik59sgrgd.wl%gnn@neville-neil.com> From: gnn@freebsd.org To: "Vladimir V. Kobal" In-Reply-To: <004a01c961ec$ec136540$c43a2fc0$@net> References: <004a01c961ec$ec136540$c43a2fc0$@net> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.7 Emacs/22.3 (amd64-portbld-freebsd7.1) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Canit-CHI2: 0.50 X-Bayes-Prob: 0.5 (Score 0, tokens from: ) X-Spam-Score: 0.10 () [Tag at 5.00] COMBINED_FROM X-CanItPRO-Stream: default X-Canit-Stats-ID: 2783804 - b4d5bc16ed03 X-Scanned-By: CanIt (www . roaringpenguin . com) on 64.13.141.13 Cc: freebsd-net@freebsd.org Subject: Re: Panic on boot with em1 attached 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: Mon, 22 Dec 2008 15:40:30 -0000 Hi, Can you try this with fastforwarding off? It looks like a double free somewhere in the ip_fastforward() routine. Someone frees m but does not NULL it out and at the drop: label the mbuf m is valid but the data within it has already been freed. Knowing if this is related only to the fast forwarding case will help. Best, George From owner-freebsd-net@FreeBSD.ORG Mon Dec 22 15:50:33 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 E45651065686; Mon, 22 Dec 2008 15:50:33 +0000 (UTC) (envelope-from tijl@ulyssis.org) Received: from mailrelay007.isp.belgacom.be (mailrelay007.isp.belgacom.be [195.238.6.173]) by mx1.freebsd.org (Postfix) with ESMTP id 58B4E8FC1D; Mon, 22 Dec 2008 15:50:33 +0000 (UTC) (envelope-from tijl@ulyssis.org) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArcEAOA/T0lR92C8/2dsb2JhbACBbLxJWI9shkM Received: from 188.96-247-81.adsl-dyn.isp.belgacom.be (HELO kalimero.kotnet.org) ([81.247.96.188]) by relay.skynet.be with ESMTP; 22 Dec 2008 16:21:44 +0100 Received: from kalimero.kotnet.org (kalimero.kotnet.org [127.0.0.1]) by kalimero.kotnet.org (8.14.3/8.14.3) with ESMTP id mBMFLfvX003349; Mon, 22 Dec 2008 16:21:41 +0100 (CET) (envelope-from tijl@ulyssis.org) From: Tijl Coosemans To: freebsd-current@freebsd.org, "Li, Qing" , freebsd-net@freebsd.org Date: Mon, 22 Dec 2008 16:21:39 +0100 User-Agent: KMail/1.9.10 References: <20081221125120.GO23166@droso.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200812221621.40722.tijl@ulyssis.org> Cc: Gerald Pfeifer 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: Mon, 22 Dec 2008 15:50:34 -0000 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? From owner-freebsd-net@FreeBSD.ORG Mon Dec 22 21:11:26 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 1A6AF106564A for ; Mon, 22 Dec 2008 21:11:26 +0000 (UTC) (envelope-from auryn@zirakzigil.org) Received: from aurynhome1sv1.zirakzigil.org (mail.zirakzigil.org [82.63.178.63]) by mx1.freebsd.org (Postfix) with SMTP id 486DC8FC1A for ; Mon, 22 Dec 2008 21:11:24 +0000 (UTC) (envelope-from auryn@zirakzigil.org) Received: (qmail 2510 invoked by uid 98); 22 Dec 2008 20:44:42 -0000 Received: from 192.168.229.11 by aurynhome1sv1.zirakzigil.org (envelope-from , uid 89) with qmail-scanner-1.25 ( Clear:RC:1(192.168.229.11):. Processed in 0.034844 secs); 22 Dec 2008 20:44:42 -0000 X-Qmail-Scanner-Mail-From: auryn@zirakzigil.org via aurynhome1sv1.zirakzigil.org X-Qmail-Scanner: 1.25 (Clear:RC:1(192.168.229.11):. Processed in 0.034844 secs) Received: from unknown (HELO aurynhome1ws2.zirakzigil.org) (postmaster@zirakzigil.org@192.168.229.11) by 0 with SMTP; 22 Dec 2008 20:44:41 -0000 Message-ID: <494FFC34.9020600@zirakzigil.org> Date: Mon, 22 Dec 2008 21:44:36 +0100 From: Giulio Ferro User-Agent: Thunderbird 2.0.0.0 (X11/20070513) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: ng_fec and vlan 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: Mon, 22 Dec 2008 21:11:26 -0000 I've tried (without too much effort, I admit...) to create vlan interfaces using a fec device as parent. It was something like this: ... fec_interfaces="fec0" fecconfig_fec0="re1 re2" ifconfig_fec0="inet 192.168.0.1 netmask 255.255.255.0" ... cloned_interfaces="vlan1 vlan2 vlan3 ..." ifconfig_vlan1="inet 192.168.1.1 netmask 255.255.255.0 vlan 1 vlandev fec0" ifconfig_vlan2="inet 192.168.2.1 netmask 255.255.255.0 vlan 2 vlandev fec0" ifconfig_vlan3="inet 192.168.3.1 netmask 255.255.255.0 vlan 3 vlandev fec0" ... freebsd 7 stable (recent) amd64 Result: I see the vlan interfaces up and active, but they neither transmit nor receive. By using tcpdump on the vlan ifaces I can see the arp packets leaving when I try to ping a host on the same vlan, but they are unanswered. The switch has been configured correctly, since the same vlans work using either re1 or re2 as parent. Any idea? From owner-freebsd-net@FreeBSD.ORG Mon Dec 22 21:47:49 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 098B4106564A; Mon, 22 Dec 2008 21:47:49 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D33528FC17; Mon, 22 Dec 2008 21:47:48 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id mBMLlm8O048700; Mon, 22 Dec 2008 21:47:48 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mBMLlm33048696; Mon, 22 Dec 2008 21:47:48 GMT (envelope-from linimon) Date: Mon, 22 Dec 2008 21:47:48 GMT Message-Id: <200812222147.mBMLlm33048696@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/129846: [panic] /usr/sbin/ppp causes panic "Sleeping thread owns a non-sleepable lock 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: Mon, 22 Dec 2008 21:47:49 -0000 Old Synopsis: /usr/sbin/ppp causes panic "Sleeping thread owns a non-sleepable lock New Synopsis: [panic] /usr/sbin/ppp causes panic "Sleeping thread owns a non-sleepable lock Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Dec 22 21:47:10 UTC 2008 Responsible-Changed-Why: May be networking-related. http://www.freebsd.org/cgi/query-pr.cgi?pr=129846 From owner-freebsd-net@FreeBSD.ORG Tue Dec 23 00:30:36 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A59751065675 for ; Tue, 23 Dec 2008 00:30:36 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 97A788FC2A for ; Tue, 23 Dec 2008 00:30:36 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 974041A3C4D; Mon, 22 Dec 2008 16:12:16 -0800 (PST) Date: Mon, 22 Dec 2008 16:12:16 -0800 From: Alfred Perlstein To: net@freebsd.org Message-ID: <20081223001216.GH18389@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: ipv6 bugfix, need review. 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: Tue, 23 Dec 2008 00:30:36 -0000 Hey guys, we found a bug at Juniper and it resolves an issue for us. I've been asked to forward this to FreeBSD, I honestly am not that clear on the issue so I'm hoping someone can step up to review this. Synopsis is: The traffic class byte is set to 0x00000000 in the header of some BGP packets sent between interfaces that have IPv6 addresses, instead of the correct setting 0xc0 (INTERNETCONTROL). Fix is small and attached. One thing I am wondering, do we need to check "if (inp)" ? I don't think so. Index: bsd/sys/netinet/tcp_syncache.c =================================================================== RCS file: /cvs/junos-2008/bsd/sys/netinet/tcp_syncache.c,v retrieving revision 1.24 diff -p -u -r1.24 tcp_syncache.c --- bsd/sys/netinet/tcp_syncache.c 29 Jul 2008 17:07:43 -0000 1.24 +++ bsd/sys/netinet/tcp_syncache.c 16 Dec 2008 19:23:31 -0000 @@ -1271,6 +1271,7 @@ syncache_respond(sc, m) struct inpcb *inp; #ifdef INET6 struct ip6_hdr *ip6 = NULL; + int inp_tclass; #endif struct rt_nexthop *minmtu_nh; struct route_table *rtb = NULL; @@ -1387,6 +1388,12 @@ syncache_respond(sc, m) /* ip6_hlim is set after checksum */ ip6->ip6_flow &= ~IPV6_FLOWLABEL_MASK; ip6->ip6_flow |= sc->sc_flowlabel; + /* Set the TC for IPv6 just like TOS for IPv4 */ + ip6->ip6_flow &= ~IPV6_CLASS_MASK; + if (inp) { + inp_tclass = IPV6_GET_CLASS(inp->in6p_flowinfo); + ip6->ip6_flow |= IPV6_SET_CLASS(inp_tclass); + } th = (struct tcphdr *)(ip6 + 1); } else -- - Alfred Perlstein From owner-freebsd-net@FreeBSD.ORG Tue Dec 23 02:27:08 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 DD19B1065673; Tue, 23 Dec 2008 02:27:08 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id A55008FC19; Tue, 23 Dec 2008 02:27:08 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id mBN2R8qR001542; Mon, 22 Dec 2008 18:27:08 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 22 Dec 2008 18:27:21 -0800 Message-ID: In-Reply-To: <200812221621.40722.tijl@ulyssis.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: HEADSUP: arp-v2 has been committed Thread-Index: AclkSQFXYpnx5DzIQR2tYY9xXa8VxQAWkVXw References: <20081221125120.GO23166@droso.net> <200812221621.40722.tijl@ulyssis.org> From: "Li, Qing" To: "Tijl Coosemans" , "Qing Li" Cc: freebsd-net@freebsd.org, freebsd-current@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: Tue, 23 Dec 2008 02:27:09 -0000 Hi Tijl, Good questions and see my comments below. >=20 > 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. >=20 > Wine currently uses: >=20 > int mib[] =3D {CTL_NET, PF_ROUTE, 0, AF_INET, NET_RT_FLAGS, RTF_LLINFO}; >=20 > 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: >=20 > #ifdef RTF_LLINFO > int mib[] =3D {CTL_NET, PF_ROUTE, 0, AF_INET, NET_RT_FLAGS, RTF_LLINFO}; > #else > int mib[] =3D {CTL_NET, PF_ROUTE, 0, AF_INET, NET_RT_FLAGS, 0}; > #endif >=20 > 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? >=20 AF_INET is the correct address family, which indicates the L2=20 information (a.k.a RTF_LLINFO previously) should be retrieved from the IPv4 ARP table. If the AF family were instead AF_INET6, then the L2 information would be coming from the ND6 cache.=20 NET_RT_DUMP walks the entire routing tree. Specifying specific flags and using the NET_RT_FLAGS opcode retrieves routing entries that have those bits set. NET_RT_FLAGS with mask 0 is an indication to the kernel the L2 table=20 should be retrieved.=20 I am glad you asked these questions because after re-examining my code,=20 I realized I could make slight optimization and also need to perform=20 additional check against erroneous input.=20 >=20 > Also, at some other place, Wine wants to retrieve gateway entries and > it uses: >=20 > int mib[6] =3D {CTL_NET, PF_ROUTE, 0, PF_INET, NET_RT_DUMP, 0}; > ^ this should be AF_INET I think >=20 > 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? > No, the output of this command is still the same. NET_RT_DUMP obtains the entire L3 table and filtering for RTF_GATEWAY non-multicast routes have the same semantics. Those flags never apply to L2 entries. -- Qing From owner-freebsd-net@FreeBSD.ORG Tue Dec 23 02:37:42 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 ED68A1065676; Tue, 23 Dec 2008 02:37:42 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id B5D2A8FC25; Tue, 23 Dec 2008 02:37:42 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id mBN2bbQc002502; Mon, 22 Dec 2008 18:37:38 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 22 Dec 2008 18:37:44 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: HEADSUP: arp-v2 has been committed Thread-Index: AclkIdLf4ZXFGP/NQQ6eaJLsxsXvCQAhHe6w References: <20081221125120.GO23166@droso.net> From: "Li, Qing" To: , "Qing Li" Cc: freebsd-net@freebsd.org, freebsd-current@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: Tue, 23 Dec 2008 02:37:43 -0000 Hi Eygene, I think it would be more efficient if individuals who have=20 discovered these issues could submit the patches directly to=20 the corresponding port maintainers.=20 You could also file a PR for tracking purposes. In any case, please cc: me so that I am aware of these breakage and in case I need to resolve any non-trivial mapping. Thank you. -- Qing > -----Original Message----- > From: rea-fbsd@codelabs.ru [mailto:rea-fbsd@codelabs.ru] > Sent: Monday, December 22, 2008 2:41 AM > To: Li, Qing > Cc: freebsd-current@freebsd.org; freebsd-net@freebsd.org; Gerald > Pfeifer; Vladimir Grebenschikov; Kip Macy; Qing Li; Ian FREISLICH; > Erwin Lansing > Subject: Re: HEADSUP: arp-v2 has been committed >=20 > Li, good day. >=20 > Mon, Dec 22, 2008 at 01:55:34AM -0800, Li, Qing wrote: > > Thank you all for patching these programs. >=20 > Thank you for your work! >=20 > > 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. >=20 > Are you going to submit the patches for affected ports by yourself > or individual persons should do it? For me, it does not matter > what route you will take, I just want to know how to proceed ;)) > -- > Eygene > _ ___ _.--. # > \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard > / ' ` , __.--' # to read the on-line manual > )/' _/ \ `-_, / # while single-stepping the kernel. > `-'" `"\_ ,_.-;_.-\_ ', fsc/as # > _.-'_./ {_.' ; / # -- FreeBSD Developers handbook > {_.-``-' {_/ # From owner-freebsd-net@FreeBSD.ORG Tue Dec 23 05:50:18 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 3EF981065673; Tue, 23 Dec 2008 05:50:18 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from inbound01.jnb1.gp-online.net (inbound01.jnb1.gp-online.net [41.161.16.135]) by mx1.freebsd.org (Postfix) with ESMTP id CB8B88FC30; Tue, 23 Dec 2008 05:50:17 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from [41.241.101.159] (helo=clue.co.za) by inbound01.jnb1.gp-online.net with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1LF09n-0001Jz-1D; Tue, 23 Dec 2008 07:50:15 +0200 Received: from localhost ([127.0.0.1] helo=clue.co.za) by clue.co.za with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LF09h-0004XQ-O2; Tue, 23 Dec 2008 07:50:09 +0200 To: Sergey Matveychuk From: Ian FREISLICH In-Reply-To: <494FAFAC.90802@FreeBSD.org> References: <494FAFAC.90802@FreeBSD.org> X-Attribution: BOFH Date: Tue, 23 Dec 2008 07:50:09 +0200 Message-Id: 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: Tue, 23 Dec 2008 05:50:18 -0000 Sergey Matveychuk wrote: > Ian FREISLICH wrote: > > --- lib/sockopt.c.orig 2007-08-21 18:32:56.000000000 +0200 > > +++ lib/sockopt.c 2008-08-13 09:07:20.000000000 +0200 > > @@ -231,6 +231,7 @@ > > else > > mreqn.imr_address = if_addr; > > > > + mreqn.imr_address = if_addr; > > ret = setsockopt(sock, IPPROTO_IP, optname, > > (void *)&mreqn, sizeof(mreqn)); > > if ((ret < 0) && (optname == IP_ADD_MEMBERSHIP) && (errno == EADDRIN USE)) > > > > I don't catch your idea here. Can you explain it please? I can't quite remember exactly why imr_ifindex doesn't work, but on my hosts which have several hundred interfaces and my OSPF sessions are never on the interface that has the default route, until I explicitly set the imr_address, the kernel always chooses the interface which has the default route. I know the resultant code looks ugly. I've just never had the time to relook the problem. Does this look better? --- sockopt.c.orig 2008-12-23 07:00:24.000000000 +0200 +++ sockopt.c 2008-12-23 07:41:28.000000000 +0200 @@ -227,9 +227,11 @@ if (mcast_addr) mreqn.imr_multiaddr.s_addr = mcast_addr; +#if OSVERSION > 700001 if (ifindex) mreqn.imr_ifindex = ifindex; else +#endif mreqn.imr_address = if_addr; ret = setsockopt(sock, IPPROTO_IP, optname, Ian -- Ian Freislich From owner-freebsd-net@FreeBSD.ORG Tue Dec 23 11:58:00 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 1D06B106564A for ; Tue, 23 Dec 2008 11:58:00 +0000 (UTC) (envelope-from vlad@prokk.net) Received: from smtp.prokk.net (smtp.prokk.net [195.16.77.5]) by mx1.freebsd.org (Postfix) with ESMTP id 693538FC18 for ; Tue, 23 Dec 2008 11:57:55 +0000 (UTC) (envelope-from vlad@prokk.net) Received: from base (base.prokk.net [195.16.77.7]) by smtp.prokk.net (8.13.8/8.13.8) with ESMTP id mBNBvipI060768; Tue, 23 Dec 2008 13:57:49 +0200 (EET) (envelope-from vlad@prokk.net) From: "Vladimir V. Kobal" To: References: <004a01c961ec$ec136540$c43a2fc0$@net> <7ik59sgrgd.wl%gnn@neville-neil.com> In-Reply-To: <7ik59sgrgd.wl%gnn@neville-neil.com> Date: Tue, 23 Dec 2008 13:57:39 +0200 Organization: ProKK SE Message-ID: <000201c964f5$aa94e6a0$ffbeb3e0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclkSe0Z5XzXd3ooQeemvJdYz0CefgAqruqA Content-Language: uk X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (smtp.prokk.net [195.16.77.5]); Tue, 23 Dec 2008 13:57:49 +0200 (EET) Cc: freebsd-net@freebsd.org Subject: RE: Panic on boot with em1 attached 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: Tue, 23 Dec 2008 11:58:00 -0000 With fastforwarding off the system works well and boots without panicing. As for the rtfree messages, they were caused by net.link.ether.inet.proxyall=1 and were not connected to panicing. Best regards, Vladimir -----Original Message----- From: gnn@freebsd.org [mailto:gnn@freebsd.org] Sent: Monday, December 22, 2008 5:28 PM To: Vladimir V. Kobal Cc: freebsd-net@freebsd.org Subject: Re: Panic on boot with em1 attached Hi, Can you try this with fastforwarding off? It looks like a double free somewhere in the ip_fastforward() routine. Someone frees m but does not NULL it out and at the drop: label the mbuf m is valid but the data within it has already been freed. Knowing if this is related only to the fast forwarding case will help. Best, George From owner-freebsd-net@FreeBSD.ORG Tue Dec 23 13:36:55 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 7C6371065675; Tue, 23 Dec 2008 13:36:55 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp-1.dlr.de (smtp-1.dlr.de [195.37.61.185]) by mx1.freebsd.org (Postfix) with ESMTP id 110558FC23; Tue, 23 Dec 2008 13:36:54 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from [192.168.2.100] ([172.21.151.1]) by smtp-1.dlr.de with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Dec 2008 14:36:52 +0100 Message-ID: <4950E95C.9060307@dlr.de> Date: Tue, 23 Dec 2008 14:36:28 +0100 From: Hartmut Brandt User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: "Li, Qing" References: <55f001c9639d$875f14ec$7202020a@internal.cacheflow.com> In-Reply-To: <55f001c9639d$875f14ec$7202020a@internal.cacheflow.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Dec 2008 13:36:52.0863 (UTC) FILETIME=[83E0E0F0:01C96503] 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: Tue, 23 Dec 2008 13:36:55 -0000 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. > Its not that easy, but fixable :-) Up to now I could use common code to handle routing message from the routing socket and the sysctl. This is not possible anymore, because most of the fields in the sysctl's routing message are just zero. The following should fix this (at least to the extend bsnmp needs it): Index: in.c =================================================================== --- in.c (revision 186335) +++ in.c (working copy) @@ -1200,6 +1200,10 @@ */ bzero(&arpc, sizeof(arpc)); arpc.rtm.rtm_msglen = sizeof(arpc); + arpc.rtm.rtm_version = RTM_VERSION; + arpc.rtm.rtm_type = RTM_GET; + arpc.rtm.rtm_flags = RTF_UP; + arpc.rtm.rtm_addrs = RTA_DST | RTA_GATEWAY; arpc.sin.sin_family = AF_INET; arpc.sin.sin_len = sizeof(arpc.sin); arpc.sin.sin_addr.s_addr = SIN(lle)->sin_addr.s_addr; Also one thing that would be extremly helpful is a short description of that interface arp(4). Currently one has to reverse engineer arp.c to understand how to do things. A last thing: I wonder if this would have been a good chance to get rid of that ugly sockaddr_inaddr construct. It looks like it is used only to hold the proxy flag, right? Couldn't we just use sockaddr_in and put that flag elsewhere. Having a single sa_family value, but two different struct sockaddr depending on the context defeats any kind of generic sockaddr handling. harti From owner-freebsd-net@FreeBSD.ORG Tue Dec 23 14:36:55 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 2774E106564A; Tue, 23 Dec 2008 14:36:55 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp-1.dlr.de (smtp-1.dlr.de [195.37.61.185]) by mx1.freebsd.org (Postfix) with ESMTP id B01848FC1A; Tue, 23 Dec 2008 14:36:54 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from [192.168.2.100] ([172.21.151.1]) by smtp-1.dlr.de with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Dec 2008 15:36:52 +0100 Message-ID: <4950F770.3090700@dlr.de> Date: Tue, 23 Dec 2008 15:36:32 +0100 From: Hartmut Brandt User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: "Li, Qing" References: <55f001c9639d$875f14ec$7202020a@internal.cacheflow.com> In-Reply-To: <55f001c9639d$875f14ec$7202020a@internal.cacheflow.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Dec 2008 14:36:52.0755 (UTC) FILETIME=[E594CE30:01C9650B] 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: Tue, 23 Dec 2008 14:36:55 -0000 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 > Sent: Sunday, December 21, 2008 8:54 AM > To: Kip Macy > Cc: Vladimir Grebenschikov ; Qing Li ; freebsd-net@freebsd.org ; Gerald Pfeifer ; 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 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-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Tue Dec 23 15:29:41 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 8AE64106564A for ; Tue, 23 Dec 2008 15:29:41 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:203:6dff:fe1a:4ddc]) by mx1.freebsd.org (Postfix) with ESMTP id 12A408FC27 for ; Tue, 23 Dec 2008 15:29:40 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from [10.1.1.54] ([10.1.1.54]) (authenticated bits=0) by lakerest.net (8.14.1/8.14.1) with ESMTP id mBNFTdjc082092 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 23 Dec 2008 10:29:40 -0500 (EST) (envelope-from rrs@lakerest.net) Message-Id: <4A152664-B170-4C6C-85C1-58E2E1577CA3@lakerest.net> From: Randall Stewart To: freebsd-net In-Reply-To: <200812132030.15665.max@love2party.net> Content-Type: multipart/mixed; boundary=Apple-Mail-9-483392564 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 23 Dec 2008 10:29:39 -0500 References: <494157DF.6030802@FreeBSD.org> <13C9478E-CBF6-4EDA-8E78-AD76549EB844@lakerest.net> <200812132030.15665.max@love2party.net> X-Mailer: Apple Mail (2.930.3) Cc: Max Laier Subject: Re: Heads up --- Thinking about UDP and tunneling 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: Tue, 23 Dec 2008 15:29:41 -0000 --Apple-Mail-9-483392564 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit All: Ok here is the latest... this: 1) Incorporates Matt's changes 2) Goes with Matt's idea of adding an INP. 3) We now are holding the INP lock across the call to the tunnel as well as the append. Since the caller will have the INP they can unlock if they need to :-) 4) revamped my s9indent use.. I ran it and then patched back in just its complaints about me... that way the other s9 issues can stay in the file untouched by me :-D Note to Sam, I did not make the base code use the function.. since I thought it got a bit tricky when one started having to worry about sockaddr's being passed to the function AND the typing there of... So I deferred that until later .. :-) I will wait tell all the criticisms settle down and commit eventually here :) R --Apple-Mail-9-483392564 Content-Disposition: attachment; filename=latest_udp_diff.txt Content-Type: text/plain; x-unix-mode=0644; name="latest_udp_diff.txt" Content-Transfer-Encoding: 7bit Index: netinet/udp_usrreq.c =================================================================== --- netinet/udp_usrreq.c (revision 185928) +++ netinet/udp_usrreq.c (working copy) @@ -488,41 +488,76 @@ struct mbuf *n; n = m_copy(m, 0, M_COPYALL); - if (n != NULL) - udp_append(last, ip, n, iphlen + - sizeof(struct udphdr), &udp_in); - INP_RUNLOCK(last); + + if (last->inp_ppcb == NULL) { + if (n != NULL) + udp_append(last, ip, n, iphlen + + sizeof(struct udphdr), &udp_in); + INP_RUNLOCK(last); + } else { + /* + * Engage the tunneling protocol we + * will have to leave the info_lock + * up, since we are hunting through + * multiple UDP inp's hope we don't + * break :-( + * + * XXXML: Maybe add a flag to the + * prototype so that the tunneling + * can defer work that can't be done + * under the info lock? + */ + udp_tunnel_func_t tunnel_func; + + tunnel_func = (udp_tunnel_func_t) last->inp_ppcb; + tunnel_func(m, iphlen, last); + INP_RUNLOCK(last); + } } last = inp; /* - * Don't look for additional matches if this one does - * not have either the SO_REUSEPORT or SO_REUSEADDR - * socket options set. This heuristic avoids - * searching through all pcbs in the common case of a - * non-shared port. It assumes that an application - * will never clear these options after setting them. + * Don't look for additional matches if this one + * does not have either the SO_REUSEPORT or + * SO_REUSEADDR socket options set. This heuristic + * avoids searching through all pcbs in the common + * case of a non-shared port. It assumes that an + * application will never clear these options after + * setting them. */ if ((last->inp_socket->so_options & - (SO_REUSEPORT|SO_REUSEADDR)) == 0) + (SO_REUSEPORT | SO_REUSEADDR)) == 0) break; } if (last == NULL) { /* - * No matching pcb found; discard datagram. (No need - * to send an ICMP Port Unreachable for a broadcast - * or multicast datgram.) + * No matching pcb found; discard datagram. (No + * need to send an ICMP Port Unreachable for a + * broadcast or multicast datgram.) */ V_udpstat.udps_noportbcast++; goto badheadlocked; } - udp_append(last, ip, m, iphlen + sizeof(struct udphdr), - &udp_in); - INP_RUNLOCK(last); - INP_INFO_RUNLOCK(&V_udbinfo); + if (last->inp_ppcb == NULL) { + udp_append(last, ip, m, iphlen + sizeof(struct udphdr), + &udp_in); + INP_RUNLOCK(last); + INP_INFO_RUNLOCK(&V_udbinfo); + } else { + /* + * Engage the tunneling protocol we must make sure + * all locks are released when we call the tunneling + * protocol. + */ + udp_tunnel_func_t tunnel_func; + + tunnel_func = (udp_tunnel_func_t) last->inp_ppcb; + tunnel_func(m, iphlen, last); + INP_RUNLOCK(last); + INP_INFO_RUNLOCK(&V_udbinfo); + } return; } - /* * Locate pcb for datagram. */ @@ -553,7 +588,6 @@ INP_INFO_RUNLOCK(&V_udbinfo); return; } - /* * Check the minimum TTL for socket. */ @@ -563,6 +597,18 @@ INP_RUNLOCK(inp); goto badunlocked; } + if (inp->inp_ppcb) { + /* + * Engage the tunneling protocol we must make sure all locks + * are released when we call the tunneling protocol. + */ + udp_tunnel_func_t tunnel_func; + + tunnel_func = (udp_tunnel_func_t) inp->inp_ppcb; + tunnel_func(m, iphlen, inp); + INP_RUNLOCK(inp); + return; + } udp_append(inp, ip, m, iphlen + sizeof(struct udphdr), &udp_in); INP_RUNLOCK(inp); return; @@ -1138,10 +1184,41 @@ INP_INFO_WUNLOCK(&V_udbinfo); inp->inp_vflag |= INP_IPV4; inp->inp_ip_ttl = V_ip_defttl; + /* + * UDP does not have a per-protocol + * pcb (inp->inp_ppcb). We use this + * pointer for kernel tunneling pointer. + * If we ever need to have a protocol + * block we will need to move this + * function pointer there. Null + * in this pointer means "do the normal + * thing". + */ + inp->inp_ppcb = NULL; INP_WUNLOCK(inp); return (0); } +int +udp_set_kernel_tunneling(struct socket *so, udp_tunnel_func_t f) +{ + struct inpcb *inp; + inp = (struct inpcb *)so->so_pcb; + + if (so->so_type != SOCK_DGRAM) { + /* Not UDP socket... sorry */ + return (ENOTSUP); + } + if (inp == NULL) { + /* NULL INP? */ + return (EINVAL); + } + INP_WLOCK(inp); + inp->inp_ppcb = f; + INP_WUNLOCK(inp); + return (0); +} + static int udp_bind(struct socket *so, struct sockaddr *nam, struct thread *td) { Index: netinet/udp_var.h =================================================================== --- netinet/udp_var.h (revision 185928) +++ netinet/udp_var.h (working copy) @@ -107,6 +107,10 @@ void udp_input(struct mbuf *, int); struct inpcb *udp_notify(struct inpcb *inp, int errno); int udp_shutdown(struct socket *so); + + +typedef void(*udp_tunnel_func_t)(struct mbuf *, int off, struct inpcb *); +int udp_set_kernel_tunneling(struct socket *so, udp_tunnel_func_t f); #endif #endif Index: netinet6/udp6_usrreq.c =================================================================== --- netinet6/udp6_usrreq.c (revision 185928) +++ netinet6/udp6_usrreq.c (working copy) @@ -262,54 +262,72 @@ if (inp->in6p_lport != uh->uh_dport) continue; /* - * XXX: Do not check source port of incoming datagram - * unless inp_connect() has been called to bind the - * fport part of the 4-tuple; the source could be - * trying to talk to us with an ephemeral port. + * XXX: Do not check source port of incoming + * datagram unless inp_connect() has been called to + * bind the fport part of the 4-tuple; the source + * could be trying to talk to us with an ephemeral + * port. */ if (inp->inp_fport != 0 && inp->inp_fport != uh->uh_sport) continue; if (!IN6_IS_ADDR_UNSPECIFIED(&inp->in6p_laddr)) { if (!IN6_ARE_ADDR_EQUAL(&inp->in6p_laddr, - &ip6->ip6_dst)) + &ip6->ip6_dst)) continue; } if (!IN6_IS_ADDR_UNSPECIFIED(&inp->in6p_faddr)) { if (!IN6_ARE_ADDR_EQUAL(&inp->in6p_faddr, - &ip6->ip6_src) || + &ip6->ip6_src) || inp->in6p_fport != uh->uh_sport) continue; } - if (last != NULL) { struct mbuf *n; if ((n = m_copy(m, 0, M_COPYALL)) != NULL) { INP_RLOCK(last); - udp6_append(last, n, off, &fromsa); - INP_RUNLOCK(last); + if (last->inp_ppcb) { + /* + * Engage the tunneling + * protocol we will have to + * leave the info_lock up, + * since we are hunting + * through multiple UDP + * inp's hope we don't break + * :-( + */ + udp_tunnel_func_t tunnel_func; + + tunnel_func = (udp_tunnel_func_t) last->inp_ppcb; + tunnel_func(m, off, last); + INP_RUNLOCK(last); + } else { + udp6_append(last, n, off, &fromsa); + INP_RUNLOCK(last); + } } } last = inp; /* - * Don't look for additional matches if this one does - * not have either the SO_REUSEPORT or SO_REUSEADDR - * socket options set. This heuristic avoids - * searching through all pcbs in the common case of a - * non-shared port. It assumes that an application - * will never clear these options after setting them. + * Don't look for additional matches if this one + * does not have either the SO_REUSEPORT or + * SO_REUSEADDR socket options set. This heuristic + * avoids searching through all pcbs in the common + * case of a non-shared port. It assumes that an + * application will never clear these options after + * setting them. */ if ((last->inp_socket->so_options & - (SO_REUSEPORT|SO_REUSEADDR)) == 0) + (SO_REUSEPORT | SO_REUSEADDR)) == 0) break; } if (last == NULL) { /* - * No matching pcb found; discard datagram. (No need - * to send an ICMP Port Unreachable for a broadcast - * or multicast datgram.) + * No matching pcb found; discard datagram. (No + * need to send an ICMP Port Unreachable for a + * broadcast or multicast datgram.) */ V_udpstat.udps_noport++; V_udpstat.udps_noportmcast++; @@ -317,6 +335,19 @@ } INP_RLOCK(last); INP_INFO_RUNLOCK(&V_udbinfo); + if (last->inp_ppcb) { + /* + * Engage the tunneling protocol we must make sure + * all locks are released when we call the tunneling + * protocol. + */ + udp_tunnel_func_t tunnel_func; + + tunnel_func = (udp_tunnel_func_t) inp->inp_ppcb; + tunnel_func(m, off, last); + INP_RUNLOCK(last); + return (IPPROTO_DONE); + } udp6_append(last, m, off, &fromsa); INP_RUNLOCK(last); return (IPPROTO_DONE); @@ -354,6 +385,18 @@ } INP_RLOCK(inp); INP_INFO_RUNLOCK(&V_udbinfo); + if (inp->inp_ppcb) { + /* + * Engage the tunneling protocol we must make sure all locks + * are released when we call the tunneling protocol. + */ + udp_tunnel_func_t tunnel_func; + + tunnel_func = (udp_tunnel_func_t) inp->inp_ppcb; + tunnel_func(m, off, inp); + INP_RUNLOCK(inp); + return (IPPROTO_DONE); + } udp6_append(inp, m, off, &fromsa); INP_RUNLOCK(inp); return (IPPROTO_DONE); --Apple-Mail-9-483392564 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct) --Apple-Mail-9-483392564-- From owner-freebsd-net@FreeBSD.ORG Tue Dec 23 16:10:03 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A382C1065674 for ; Tue, 23 Dec 2008 16:10:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 919DF8FC20 for ; Tue, 23 Dec 2008 16:10:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id mBNGA30X041254 for ; Tue, 23 Dec 2008 16:10:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mBNGA358041253; Tue, 23 Dec 2008 16:10:03 GMT (envelope-from gnats) Date: Tue, 23 Dec 2008 16:10:03 GMT Message-Id: <200812231610.mBNGA358041253@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Axel Scheepers Cc: Subject: Re: kern/119432: [arp] route add -host <host> -iface <nic> causes arp entry with nic's arp address [regression] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Axel Scheepers List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2008 16:10:03 -0000 The following reply was made to PR kern/119432; it has been noted by GNATS. From: Axel Scheepers To: bug-followup@FreeBSD.org, axel@axel.truedestiny.net Cc: Subject: Re: kern/119432: [arp] route add -host <host> -iface <nic> causes arp entry with nic's arp address [regression] Date: Tue, 23 Dec 2008 17:01:52 +0100 --=-DJi/6GyJxBE0ge5Iv6Kh Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi, I had to replace the box in question with a real router due to hardware failure. I think using route add -net host -netmask 255.255.255.255 -interface ip-address-on-egress-interface will actually work but I'm still pretty sure -iface used to work on 4.x. I also found a PR which might be related, 121437. 'Routing to layer-2 address does not work on VLAN interface' I'll try to install freebsd on a spare machine to see if using -net -netmask -interface actually does work. Kind regards, Axel Scheepers --=20 () ascii ribbon campaign - against html e-mail=20 /\ www.asciiribbon.org - against proprietary attachments --=-DJi/6GyJxBE0ge5Iv6Kh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAklRC2sACgkQvOFCXiGjP+AHwQCfXlQhJHzK5jTU8FoOzswPc3W/ FwsAniQwvhcivlEn532JqqfPXiI0L90N =G7cf -----END PGP SIGNATURE----- --=-DJi/6GyJxBE0ge5Iv6Kh-- From owner-freebsd-net@FreeBSD.ORG Tue Dec 23 16:53:02 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 5E0EF1065675; Tue, 23 Dec 2008 16:53:02 +0000 (UTC) (envelope-from tijl@ulyssis.org) Received: from mailrelay007.isp.belgacom.be (mailrelay007.isp.belgacom.be [195.238.6.173]) by mx1.freebsd.org (Postfix) with ESMTP id 1B9FD8FC12; Tue, 23 Dec 2008 16:53:00 +0000 (UTC) (envelope-from tijl@ulyssis.org) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApIFAHmmUElR92C8/2dsb2JhbACBbJMMqkBYkWqGQw Received: from 188.96-247-81.adsl-dyn.isp.belgacom.be (HELO kalimero.kotnet.org) ([81.247.96.188]) by relay.skynet.be with ESMTP; 23 Dec 2008 17:52:58 +0100 Received: from kalimero.kotnet.org (kalimero.kotnet.org [127.0.0.1]) by kalimero.kotnet.org (8.14.3/8.14.3) with ESMTP id mBNGoRx3004433; Tue, 23 Dec 2008 17:50:27 +0100 (CET) (envelope-from tijl@ulyssis.org) From: Tijl Coosemans To: "Li, Qing" , Gerald Pfeifer Date: Tue, 23 Dec 2008 17:50:24 +0100 User-Agent: KMail/1.9.10 References: <20081221125120.GO23166@droso.net> <200812221621.40722.tijl@ulyssis.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_SbRUJWpnEldcbHg" Message-Id: <200812231750.26602.tijl@ulyssis.org> Cc: 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: Tue, 23 Dec 2008 16:53:02 -0000 --Boundary-00=_SbRUJWpnEldcbHg Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Tuesday 23 December 2008 03:27:21 Li, Qing wrote: >> 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? > > AF_INET is the correct address family, which indicates the L2 > information (a.k.a RTF_LLINFO previously) should be retrieved from > the IPv4 ARP table. If the AF family were instead AF_INET6, then the > L2 information would be coming from the ND6 cache. > > NET_RT_DUMP walks the entire routing tree. Specifying specific flags > and using the NET_RT_FLAGS opcode retrieves routing entries that have > those bits set. > > NET_RT_FLAGS with mask 0 is an indication to the kernel the L2 table > should be retrieved. > > I am glad you asked these questions because after re-examining my > code, I realized I could make slight optimization and also need to > perform additional check against erroneous input. > >> 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? > > No, the output of this command is still the same. NET_RT_DUMP obtains > the entire L3 table and filtering for RTF_GATEWAY non-multicast > routes have the same semantics. Those flags never apply to L2 entries. Thanks for answering my questions. I've attached the patch for Wine. --Boundary-00=_SbRUJWpnEldcbHg Content-Type: text/plain; charset="iso-8859-1"; name="patch-wine-iphlpapi-current" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="patch-wine-iphlpapi-current" diff --git a/dlls/iphlpapi/ipstats.c b/dlls/iphlpapi/ipstats.c index 3fc91eb..99e78a0 100644 --- a/dlls/iphlpapi/ipstats.c +++ b/dlls/iphlpapi/ipstats.c @@ -1250,7 +1250,11 @@ DWORD getRouteTable(PMIB_IPFORWARDTABLE *ppIpForwardTable, HANDLE heap, DWORD getNumArpEntries(void) { #if defined(HAVE_SYS_SYSCTL_H) && defined(NET_RT_DUMP) +#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 #define MIB_LEN (sizeof(mib) / sizeof(mib[0])) DWORD arpEntries = 0; size_t needed; @@ -1308,7 +1312,11 @@ DWORD getArpTable(PMIB_IPNETTABLE *ppIpNetTable, HANDLE heap, DWORD flags) #if defined(HAVE_SYS_SYSCTL_H) && defined(NET_RT_DUMP) if (table) { +#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 #define MIB_LEN (sizeof(mib) / sizeof(mib[0])) size_t needed; char *buf, *lim, *next; --Boundary-00=_SbRUJWpnEldcbHg-- From owner-freebsd-net@FreeBSD.ORG Tue Dec 23 19:35:47 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 35723106567A for ; Tue, 23 Dec 2008 19:35:47 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from proxy.meer.net (proxy.meer.net [64.13.141.13]) by mx1.freebsd.org (Postfix) with ESMTP id 144368FC2E for ; Tue, 23 Dec 2008 19:35:47 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mail.meer.net (mail.meer.net [64.13.141.3]) by proxy.meer.net (8.14.2/8.14.2) with ESMTP id mBNJZkQ9020089; Tue, 23 Dec 2008 11:35:46 -0800 (PST) (envelope-from gnn@neville-neil.com) Received: from mail2.meer.net (mail2.meer.net [64.13.141.16]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id mBNJZX1R079450; Tue, 23 Dec 2008 11:35:33 -0800 (PST) (envelope-from gnn@neville-neil.com) Received: from gnnbsd.hudson-trading.com.neville-neil.com (209.249.190.8.available.above.net [209.249.190.8] (may be forged)) (authenticated bits=0) by mail2.meer.net (8.14.1/8.14.1) with ESMTP id mBNJZXxd072964; Tue, 23 Dec 2008 11:35:33 -0800 (PST) (envelope-from gnn@neville-neil.com) Date: Tue, 23 Dec 2008 14:35:32 -0500 Message-ID: <7ik59q3csb.wl%gnn@neville-neil.com> From: gnn@freebsd.org To: "Vladimir V. Kobal" In-Reply-To: <000201c964f5$aa94e6a0$ffbeb3e0$@net> References: <004a01c961ec$ec136540$c43a2fc0$@net> <7ik59sgrgd.wl%gnn@neville-neil.com> <000201c964f5$aa94e6a0$ffbeb3e0$@net> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.7 Emacs/22.3 (amd64-portbld-freebsd7.1) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Canit-CHI2: 0.50 X-Bayes-Prob: 0.5 (Score 0, tokens from: ) X-Spam-Score: 0.10 () [Tag at 5.00] COMBINED_FROM X-CanItPRO-Stream: default X-Canit-Stats-ID: 2803445 - 9f4f3fe872b6 X-Scanned-By: CanIt (www . roaringpenguin . com) on 64.13.141.13 Cc: freebsd-net@freebsd.org Subject: Re: Panic on boot with em1 attached 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: Tue, 23 Dec 2008 19:35:47 -0000 At Tue, 23 Dec 2008 13:57:39 +0200, Vladimir V. Kobal wrote: > > With fastforwarding off the system works well and boots without panicing. > OK, that narrows it down. Are you using any filtering such as PF, ipfw, etc.? Best, George From owner-freebsd-net@FreeBSD.ORG Tue Dec 23 20:13:28 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F004C106564A for ; Tue, 23 Dec 2008 20:13:28 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with ESMTP id 709698FC12 for ; Tue, 23 Dec 2008 20:13:28 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 5862 invoked by uid 399); 23 Dec 2008 19:46:46 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 23 Dec 2008 19:46:46 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Date: Tue, 23 Dec 2008 11:46:44 -0800 (PST) From: Doug Barton To: Alfred Perlstein In-Reply-To: <20081223001216.GH18389@elvis.mu.org> Message-ID: References: <20081223001216.GH18389@elvis.mu.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-message-flag: Outlook -- Not just for spreading viruses anymore! X-OpenPGP-Key-ID: 0xD5B2F0FB Organization: http://www.FreeBSD.org/ MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: net@freebsd.org Subject: Re: ipv6 bugfix, need review. 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: Tue, 23 Dec 2008 20:13:29 -0000 On Mon, 22 Dec 2008, Alfred Perlstein wrote: > Hey guys, we found a bug at Juniper and it resolves an issue > for us. I've been asked to forward this to FreeBSD, I honestly > am not that clear on the issue so I'm hoping someone can step > up to review this. > > Synopsis is: > > The traffic class byte is set to 0x00000000 in the header of some > BGP packets sent between interfaces that have IPv6 addresses, > instead of the correct setting 0xc0 (INTERNETCONTROL). > > Fix is small and attached. One thing I am wondering, do we > need to check "if (inp)" ? I don't think so. How about adding an assert to the patch to prove this theory? :) I'll test it on my home box (which has IPv6) as soon as I'm done with the stuff I'm working on atm. hth, Doug -- This .signature sanitized for your protection From owner-freebsd-net@FreeBSD.ORG Tue Dec 23 20:39:05 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7D53B1065670 for ; Tue, 23 Dec 2008 20:39:05 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from proxy.meer.net (proxy.meer.net [64.13.141.13]) by mx1.freebsd.org (Postfix) with ESMTP id 5D5098FC38 for ; Tue, 23 Dec 2008 20:39:05 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mail.meer.net (mail.meer.net [64.13.141.3]) by proxy.meer.net (8.14.2/8.14.2) with ESMTP id mBNKRc26026323 for ; Tue, 23 Dec 2008 12:27:38 -0800 (PST) (envelope-from gnn@neville-neil.com) Received: from mail2.meer.net (mail2.meer.net [64.13.141.16]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id mBNKRTLV001714 for ; Tue, 23 Dec 2008 12:27:29 -0800 (PST) (envelope-from gnn@neville-neil.com) Received: from gnnbsd.hudson-trading.com.neville-neil.com (209.249.190.8.available.above.net [209.249.190.8] (may be forged)) (authenticated bits=0) by mail2.meer.net (8.14.1/8.14.1) with ESMTP id mBNKRTe2086522 for ; Tue, 23 Dec 2008 12:27:29 -0800 (PST) (envelope-from gnn@neville-neil.com) Date: Tue, 23 Dec 2008 15:27:28 -0500 Message-ID: <7ihc4u3adr.wl%gnn@neville-neil.com> From: gnn@freebsd.org To: net@freebsd.org User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.7 Emacs/22.3 (amd64-portbld-freebsd7.1) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Canit-CHI2: 0.50 X-Bayes-Prob: 0.5 (Score 0, tokens from: ) X-Spam-Score: 0.10 () [Tag at 5.00] COMBINED_FROM X-CanItPRO-Stream: default X-Canit-Stats-ID: 2804731 - 004197740fec X-Scanned-By: CanIt (www . roaringpenguin . com) on 64.13.141.13 Cc: Subject: A new tool for low level testing... 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: Tue, 23 Dec 2008 20:39:05 -0000 Hi, I just checked in a small tool to HEAD in /usr/src/tools/tools/ether_reflect which uses pcap and bpf to reflect ethernet packets just about the driver layer without involving the protocol stacks. This is useful for people doing low level testing of drivers and switches. If you happen to be lucky enough to have an ethernet packet generator (ixia et al) this will do what you want in terms of reflecting the packets back. Later, George From owner-freebsd-net@FreeBSD.ORG Tue Dec 23 20:49:36 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 F4057106564A; Tue, 23 Dec 2008 20:49:35 +0000 (UTC) (envelope-from vlad@prokk.net) Received: from smtp.prokk.net (smtp.prokk.net [195.16.77.5]) by mx1.freebsd.org (Postfix) with ESMTP id 713528FC1A; Tue, 23 Dec 2008 20:49:35 +0000 (UTC) (envelope-from vlad@prokk.net) Received: from base (base.prokk.net [195.16.77.7]) by smtp.prokk.net (8.13.8/8.13.8) with ESMTP id mBNKnSsh016831; Tue, 23 Dec 2008 22:49:33 +0200 (EET) (envelope-from vlad@prokk.net) From: "Vladimir V. Kobal" To: References: <004a01c961ec$ec136540$c43a2fc0$@net> <7ik59sgrgd.wl%gnn@neville-neil.com> <000201c964f5$aa94e6a0$ffbeb3e0$@net> <7ik59q3csb.wl%gnn@neville-neil.com> In-Reply-To: <7ik59q3csb.wl%gnn@neville-neil.com> Date: Tue, 23 Dec 2008 22:49:24 +0200 Organization: ProKK SE Message-ID: <000301c9653f$f32c6dd0$d9854970$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcllNk/n5ot4MIvdTmiNN2sXYlQD1QAAzujg Content-Language: uk X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (smtp.prokk.net [195.16.77.5]); Tue, 23 Dec 2008 22:49:33 +0200 (EET) Cc: freebsd-net@freebsd.org Subject: RE: Panic on boot with em1 attached 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: Tue, 23 Dec 2008 20:49:36 -0000 We are using pf+ALTQ for shaping and ipfw for filtering, diverting into netgraph nodes, attaching altq queues. Best regards, Vladimir -----Original Message----- From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd-net@freebsd.org] On Behalf Of gnn@freebsd.org Sent: Tuesday, December 23, 2008 9:36 PM To: Vladimir V. Kobal Cc: freebsd-net@freebsd.org Subject: Re: Panic on boot with em1 attached OK, that narrows it down. Are you using any filtering such as PF, ipfw, etc.? Best, George From owner-freebsd-net@FreeBSD.ORG Tue Dec 23 21:18:34 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 D04B6106564A; Tue, 23 Dec 2008 21:18:34 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id AE42D8FC14; Tue, 23 Dec 2008 21:18:34 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id mBNLIV2I029728; Tue, 23 Dec 2008 13:18:31 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 23 Dec 2008 13:18:47 -0800 Message-ID: In-Reply-To: <4950F770.3090700@dlr.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: HEADSUP: arp-v2 has been committed Thread-Index: AcllC+gUQ/WnruL3Sa+i1XH+Vht2RgAKxQyw References: <55f001c9639d$875f14ec$7202020a@internal.cacheflow.com> <4950F770.3090700@dlr.de> From: "Li, Qing" To: "Hartmut Brandt" , "Qing Li" Cc: freebsd-net@freebsd.org, freebsd-current@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: Tue, 23 Dec 2008 21:18:34 -0000 Hi Hartmut, I appreciate your candid feedback. You raised many valid points.=20 I combined both of your emails in this reply, please see my=20 comments below ... >=20 > Also one thing that would be extremly helpful is a short description of > that interface arp(4). Currently one has to reverse engineer arp.c to > understand how to do things. > This project has been in the making for quite a long time. I had a lot of content prepared to write in the commit message in my head, but when the moment final arrived in the end, my mind went blank perhaps due to that much anticipation. Funny how that works.=20 I will provide more text on this subject after things have settled down. >=20 > - 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. >=20 This was due to my lack of understanding about the structure of that section of the repository. Thank you for providing this=20 information. > > - you just removed a lot of code and left the ipNetToMedia table > entirely disfunctional. >=20 > - you obviously did not test the change. Otherwise you would have seen > that it did not work. > No, I did not test that piece of code. There were so much to do in=20 the end, and having modified arp and ndp myself, I estimated the fix would not be difficult even if I broke it. So I took a calculated gamble. Thank you for fixing my bugs. > > 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, > You are absolutely right. This was a complete oversight on my part. I was telling myself "I think I am forgetting something".=20 ... then I remembered when the first port breakage report arrived ;-) To be fair though, I did send a message titled=20 "last call for L2/L3 rewrite code review" a week before the commit to net@, current@ and all of the developers. And I have sent many emails on this subject in the past few years. A couple of points I hope you could recognize: 1. The arp-v2 project replaces a major networking kernel design and=20 all of its dependencies that have been in operation for many years=20 (16+ ??). The networking kernel went through quite a surgery so=20 do expect things will continue to evolve. 2. This is the first time I am making such a major change in the kernel. Since I am still learning the process, I am bound to make mistakes but I will not repeat these mistakes in the future. My goal is to be diligent in monitoring the problem reports and provide timely responses and fixes. And finally I want to thank you and others for your hard work in helping me cleaning up the ports. Thanks again. Cheers, --Qing From owner-freebsd-net@FreeBSD.ORG Tue Dec 23 21:29:10 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E4866106567A; Tue, 23 Dec 2008 21:29:10 +0000 (UTC) (envelope-from prvs=julian=236fe5f01@elischer.org) Received: from smtp-outbound.ironport.com (smtp-outbound.ironport.com [63.251.108.112]) by mx1.freebsd.org (Postfix) with ESMTP id CE3B18FC1A; Tue, 23 Dec 2008 21:29:10 +0000 (UTC) (envelope-from prvs=julian=236fe5f01@elischer.org) Received: from jelischer-laptop.sfo.ironport.com (HELO julian-mac.elischer.org) ([10.251.22.38]) by smtp-outbound.ironport.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 23 Dec 2008 13:00:36 -0800 Message-ID: <4951515C.4030706@elischer.org> Date: Tue, 23 Dec 2008 13:00:12 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: gnn@freebsd.org References: <7ihc4u3adr.wl%gnn@neville-neil.com> In-Reply-To: <7ihc4u3adr.wl%gnn@neville-neil.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: A new tool for low level testing... 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: Tue, 23 Dec 2008 21:29:11 -0000 gnn@freebsd.org wrote: > Hi, > > I just checked in a small tool to HEAD in > /usr/src/tools/tools/ether_reflect which uses pcap and bpf to reflect > ethernet packets just about the driver layer without involving the > protocol stacks. This is useful for people doing low level testing of > drivers and switches. If you happen to be lucky enough to have an > ethernet packet generator (ixia et al) this will do what you want in > terms of reflecting the packets back. > > Later, > George > _______________________________________________ > 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" OR ngctl mkpeer em0: echo lower echo hmmmmm no this would leave the source and destination headers in hte same order.. they need to be swapped.. ok so I need to make a patch, but it would be much quicker than a user utility.. From owner-freebsd-net@FreeBSD.ORG Tue Dec 23 22:08:49 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 A40AB1065674; Tue, 23 Dec 2008 22:08:49 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.232]) by mx1.freebsd.org (Postfix) with ESMTP id 63DC88FC08; Tue, 23 Dec 2008 22:08:49 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so4073096rvf.43 for ; Tue, 23 Dec 2008 14:08:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=/BT/mrSodMgMoyV0eKLE5iZBMAGCP6xFsctZzlT2b08=; b=BTYxOSe8lK8Q2ubp8oqGvsnu4g8EPCSyFby8TlS2TQCkcMB2NrKK0BnYk3rfUmaJgf uUob1l1hNQOzFfUsW02k0FNUeRclzp+TC0Isi+MK6zm4rVe23dltHc++4kBi11R1J9Pf 9WRr1Km/VZBa11oYrVTCgP1O+MNZ/zPswKvT4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=on1kZEvV9X8kZE9Mrfe0SPO5ojcTQlmC7stpa67ZclJ6uu1D3DCGV2r4E9BDvDG9Fk M4hQBGaPnxp30eZeMgKoHp9zWgQKWWDdIZUiX8//3CFGXF04tWbGEO7beUAq8AzZp0ly EJ97UWVoy+APE5ND53PNj++lSLI6CfFyQ2fKA= Received: by 10.141.203.7 with SMTP id f7mr3937242rvq.125.1230070129184; Tue, 23 Dec 2008 14:08:49 -0800 (PST) Received: by 10.141.37.17 with HTTP; Tue, 23 Dec 2008 14:08:49 -0800 (PST) Message-ID: <3c1674c90812231408h53b16b4as5d3fa242e6d02a10@mail.gmail.com> Date: Tue, 23 Dec 2008 14:08:49 -0800 From: "Kip Macy" Sender: mat.macy@gmail.com To: "Li, Qing" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <55f001c9639d$875f14ec$7202020a@internal.cacheflow.com> <4950F770.3090700@dlr.de> X-Google-Sender-Auth: 5f5fea3d9a27b04b Cc: Qing Li , Hartmut Brandt , 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: Tue, 23 Dec 2008 22:08:49 -0000 Hi Harti, Let me first preface this e-mail by saying that you and I have had very little contact prior to this. The comments below are meant to explain the point of view of myself and that of a number of other developers with whom I have spoken, not to criticize you or trivialize your point of view. >> - 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. Even those of us well versed in networking are not familiar with all subsystems. I know that whenever someone breaks a subsystem that is important to me that I am indignant. That is natural. Although Sam Leffler reviewed much of the code before commit, and I (re-)implemented all of the locking, we have to accept that there was really only one person working on this. He publicly asked for a review many times and made a good faith effort to test all of the dependent network subsystems that he could. However, at the end of the day the code goes in and bugs get fixed as they crop up. Most of us feel that he has done a commendable job in dealing with issues promptly. >> 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, The only reasonable way to do a full ports build is to ask portmgr to use the build systems. Although it may now be possible with svn, in the past there was no way for him to do that for out of tree code. Hence portmgr does not share your point of view. What we should have done is grepped for RTM_RESOLVE and the flags that I removed. However, that did not occur to me. He asked on numerous occasions for review and someone should have brought it up then. We do not feel that it is reasonable to hold him solely responsible when he did not act in a unilateral fashion. Thank you for taking care of that bit of breakage. Cheers, Kip -- Als die Nazis die Kommunisten holten, habe ich geschwiegen; ich war ja kein Kommunist. Als sie die Sozialdemokraten einsperrten, habe ich geschwiegen; ich war ja kein Sozialdemokrat. Als sie die Gewerkschafter holten, habe ich nicht protestiert; ich war ja kein Gewerkschafter. Als sie die Juden holten, habe ich geschwiegen; ich war ja kein Jude. Als sie mich holten, gab es keinen mehr, der protestieren konnte. From owner-freebsd-net@FreeBSD.ORG Tue Dec 23 22:27:58 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 DFE06106567D; Tue, 23 Dec 2008 22:27:58 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp-3.dlr.de (smtp-3.dlr.de [195.37.61.187]) by mx1.freebsd.org (Postfix) with ESMTP id 7465E8FC2A; Tue, 23 Dec 2008 22:27:58 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from [129.247.12.20] ([129.247.12.20]) by smtp-3.dlr.de with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Dec 2008 23:27:56 +0100 Message-ID: <495165D8.2070409@dlr.de> Date: Tue, 23 Dec 2008 23:27:36 +0100 From: Hartmut Brandt User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: "Li, Qing" References: <55f001c9639d$875f14ec$7202020a@internal.cacheflow.com> <4950F770.3090700@dlr.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Dec 2008 22:27:56.0994 (UTC) FILETIME=[B4616A20:01C9654D] Cc: 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: Tue, 23 Dec 2008 22:27:59 -0000 Li, Qing wrote: > Hi Hartmut, > > I appreciate your candid feedback. You raised many valid points. > I combined both of your emails in this reply, please see my > comments below ... > > > You are absolutely right. This was a complete oversight on my part. > I was telling myself "I think I am forgetting something". > ... then I remembered when the first port breakage report arrived ;-) > > To be fair though, I did send a message titled > "last call for L2/L3 rewrite code review" a week before the commit > to net@, current@ and all of the developers. > And I have sent many emails on this subject in the past few years. > > A couple of points I hope you could recognize: > > 1. The arp-v2 project replaces a major networking kernel design and > all of its dependencies that have been in operation for many years > (16+ ??). The networking kernel went through quite a surgery so > do expect things will continue to evolve. > > 2. This is the first time I am making such a major change in the > kernel. Since I am still learning the process, I am bound to > make mistakes but I will not repeat these mistakes in the future. > > My goal is to be diligent in monitoring the problem reports and > provide timely responses and fixes. > > And finally I want to thank you and others for your hard work in > helping me cleaning up the ports. > > Well, my mail was probably somewhat harsh, I'm usually more polite. You know, that's the kind of mood you are in after a couple of hours of useless work. Of course I appreciate your work and, I must say, you're an hero for taking this. In any case there is still an Todo on my side: the routing information for NETNATM is currently lost somewhere between L2 and L3 :-) I guess I come back to you in the new year to fix this issue... Have to fetch my ATM equipment from the corner where it is collecting dust to setup a testbed. In the mean time I will do an bsnmp import to fix the arp table problem. keep on your good work, harti From owner-freebsd-net@FreeBSD.ORG Tue Dec 23 22:28:47 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 DC18E10656AE for ; Tue, 23 Dec 2008 22:28:46 +0000 (UTC) (envelope-from antoine.brodin.freebsd@gmail.com) Received: from mail-bw0-f19.google.com (mail-bw0-f19.google.com [209.85.218.19]) by mx1.freebsd.org (Postfix) with ESMTP id 52D9D8FC31 for ; Tue, 23 Dec 2008 22:28:46 +0000 (UTC) (envelope-from antoine.brodin.freebsd@gmail.com) Received: by bwz12 with SMTP id 12so7883122bwz.19 for ; Tue, 23 Dec 2008 14:28:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=CUKmdcQ9GPYjJ525NRW1cN7Y7bceUbuIEUavGsq3llo=; b=k3cNH+AA+7+xBAdY3F9iyTsYbuQr6h7CHwNfRov7WYt/SZX3uSvywDb/qOyjzJ18a/ 46fBIz47syEWNdBh6Fp0AyUB46SRElqJUeJ5qdJpPN3Zo2bNvVyAm5uijY3CwTz9/sMS ur9Sj9lBrY5SNB2Gd9vn2prItAyHbO4Dj0uS4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=Ad7xnv4KviV/COw7lXKCMLs+E2PQpFhJWtRx/erbGV/L8ZTpxmHU5KCtCwKVN1BWv9 GXK7VUR5cl/Mk24imTqnV0zgrZWUii/aFsL1v/cjZmuhBAkEwj6xqXKA6BD3CEShW9bg qJ3gGTFErq08BXlqTROuh1AA181orR8+HYaPY= Received: by 10.181.149.19 with SMTP id b19mr1910555bko.67.1230069688731; Tue, 23 Dec 2008 14:01:28 -0800 (PST) Received: by 10.181.136.11 with HTTP; Tue, 23 Dec 2008 14:01:28 -0800 (PST) Message-ID: Date: Tue, 23 Dec 2008 23:01:28 +0100 From: "Antoine Brodin" Sender: antoine.brodin.freebsd@gmail.com To: "Qing Li" In-Reply-To: <200812150634.mBF6YDVC060565@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200812150634.mBF6YDVC060565@freefall.freebsd.org> X-Google-Sender-Auth: a5fa93ac68d294de Cc: freebsd-net@freebsd.org, freebsd-current@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: Tue, 23 Dec 2008 22:28:47 -0000 On Mon, Dec 15, 2008 at 7:34 AM, Qing Li wrote: > Hi All, > > The arp-v2 changes have been committed into HEAD. > Please report problems to me and Kip Macy. Hi, I still have a panic with ipv6 enabled with current from yesterday afternoon (in6.c rev 1.92): %%% # cat info.1 Dump header from device /dev/ad6s1b Architecture: i386 Architecture Version: 2 Dump Length: 180998144B (172 MB) Blocksize: 512 Dumptime: Tue Dec 23 13:52:41 2008 Hostname: barton.dreadbsd.org. Magic: FreeBSD Kernel Dump Version String: FreeBSD 8.0-CURRENT #2: Mon Dec 22 17:44:06 CET 2008 root@barton.dreadbsd.org.:/usr/obj/usr/src/sys/GENERIC Panic String: _rw_rlock (lle): wlock already held @ /usr/src/sys/netinet6/in6.c:2221 Dump Parity: 1345446215 Bounds: 1 Dump Status: good # kgdb /boot/kernel/kernel vmcore.1 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"... Unread portion of the kernel message buffer: lock order reversal: 1st 0xc549aa08 lle (lle) @ /usr/src/sys/netinet6/in6.c:2219 2nd 0xc51b9608 if_afdata (if_afdata) @ /usr/src/sys/netinet6/nd6_rtr.c:1336 KDB: stack backtrace: db_trace_self_wrapper(c0be5fcb,c4b88648,c08757f6,4,c0be152e,...) at db_trace_self_wrapper+0x26 kdb_backtrace(4,c0be152e,c4d26f50,c4d24ac0,c4b886a4,...) at kdb_backtrace+0x29 _witness_debugger(c0be8cb5,c51b9608,c0bf1709,c4d24ac0,c0bfff5d,...) at _witness_debugger+0x26 witness_checkorder(c51b9608,9,c0bfff5d,538,0,...) at witness_checkorder+0x839 _rw_wlock(c51b9608,c0bfff5d,538,c544c000,c51f6a80,...) at _rw_wlock+0x82 find_pfxlist_reachable_router(f4,c549aa48,c4b88724,c08467fd,c0d35140,...) at find_pfxlist_reachable_router+0x37 pfxlist_onlink_check(c549aa00,3a98,6,1,c188ca38,...) at pfxlist_onlink_check+0x2e nd6_na_input(c544c000,28,20,1,7dc,...) at nd6_na_input+0x518 icmp6_input(c4b88aa0,c4b88ab4,3a,c54230a4,c5923028,...) at icmp6_input+0x1cb6 ip6_input(c58ed700,c070a8b2,86dd,c51b9400,86dd,...) at ip6_input+0x101d netisr_dispatch(1b,c58ed700,c4ed6480,1,c51b9400,...) at netisr_dispatch+0x72 ether_demux(c51b9400,c58ed700,3,0,3,...) at ether_demux+0x1f1 ether_input(c51b9400,c58ed700,c549f000,c524b000,c58c8008,...) at ether_input+0x37f ieee80211_deliver_data(c524b000,c549f000,c58ed700,c4f1947c,4,...) at ieee80211_deliver_data+0x94 sta_input(c549f000,c58ed700,25,ffffffa0,669,...) at sta_input+0x9fc ath_rx_proc(c4ede000,1,c0be7657,54,c4f0a35c,...) at ath_rx_proc+0x4b6 taskqueue_run(c4f0a340,c4f0a35c,0,c0bd996f,0,...) at taskqueue_run+0x10b taskqueue_thread_loop(c4ede26c,c4b88d38,c0bded0e,32d,c0d32c40,...) at taskqueue_thread_loop+0x68 fork_exit(c086ea30,c4ede26c,c4b88d38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xc4b88d70, ebp = 0 --- panic: _rw_rlock (lle): wlock already held @ /usr/src/sys/netinet6/in6.c:2221 cpuid = 0 Uptime: 1h40m57s Physical memory: 1519 MB Dumping 172 MB: 157 141 125 109 93 77 61 45 29 13 Reading symbols from /boot/kernel/sound.ko...Reading symbols from /boot/kernel/sound.ko.symbols...done. done. Loaded symbols for /boot/kernel/sound.ko Reading symbols from /boot/kernel/snd_ich.ko...Reading symbols from /boot/kernel/snd_ich.ko.symbols...done. done. Loaded symbols for /boot/kernel/snd_ich.ko Reading symbols from /boot/kernel/radeon.ko...Reading symbols from /boot/kernel/radeon.ko.symbols...done. done. Loaded symbols for /boot/kernel/radeon.ko Reading symbols from /boot/kernel/drm.ko...Reading symbols from /boot/kernel/drm.ko.symbols...done. done. Loaded symbols for /boot/kernel/drm.ko #0 doadump () at pcpu.h:246 246 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:246 #1 0xc0833dcc in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:420 #2 0xc08340a5 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:576 #3 0xc0832526 in _rw_rlock (rw=0xc549aa08, file=0xc0bfe9e5 "/usr/src/sys/netinet6/in6.c", line=2221) at /usr/src/sys/kern/kern_rwlock.c:291 #4 0xc09a722a in in6_lltable_lookup (llt=0xc5209e00, flags=0, l3addr=0xc4b886a0) at /usr/src/sys/netinet6/in6.c:2221 #5 0xc09b937c in nd6_lookup (addr6=0xc51ebc88, flags=0, ifp=0xc51b9400) at if_llatbl.h:188 #6 0xc09beef4 in find_pfxlist_reachable_router (pr=Variable "pr" is not available. ) at /usr/src/sys/netinet6/nd6_rtr.c:1337 #7 0xc09bef8e in pfxlist_onlink_check () at /usr/src/sys/netinet6/nd6_rtr.c:1376 #8 0xc09bbde8 in nd6_na_input (m=0xc544c000, off=40, icmp6len=32) at /usr/src/sys/netinet6/nd6_nbr.c:742 #9 0xc09a5266 in icmp6_input (mp=0xc4b88aa0, offp=0xc4b88ab4, proto=58) at /usr/src/sys/netinet6/icmp6.c:808 #10 0xc09b2bdd in ip6_input (m=0xc58ed700) at /usr/src/sys/netinet6/ip6_input.c:886 #11 0xc08e2832 in netisr_dispatch (num=27, m=0xc58ed700) at /usr/src/sys/net/netisr.c:178 #12 0xc08dc221 in ether_demux (ifp=0xc51b9400, m=0xc58ed700) at /usr/src/sys/net/if_ethersubr.c:864 #13 0xc08dc68f in ether_input (ifp=0xc51b9400, m=0xc58ed700) at /usr/src/sys/net/if_ethersubr.c:721 #14 0xc08fe974 in ieee80211_deliver_data (vap=0xc524b000, ni=dwarf2_read_address: Corrupted DWARF expression. ) at /usr/src/sys/net80211/ieee80211_input.c:223 #15 0xc091899c in sta_input (ni=0xc549f000, m=0xc58ed700, rssi=37, noise=-96, rstamp=1641) at /usr/src/sys/net80211/ieee80211_sta.c:824 #16 0xc0584b26 in ath_rx_proc (arg=0xc4ede000, npending=1) at /usr/src/sys/dev/ath/if_ath.c:4218 #17 0xc086e93b in taskqueue_run (queue=0xc4f0a340) at /usr/src/sys/kern/subr_taskqueue.c:282 #18 0xc086ea98 in taskqueue_thread_loop (arg=0xc4ede26c) at /usr/src/sys/kern/subr_taskqueue.c:403 #19 0xc08108f8 in fork_exit (callout=0xc086ea30 , arg=0xc4ede26c, frame=0xc4b88d38) at /usr/src/sys/kern/kern_fork.c:821 #20 0xc0b1a1d0 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:270 (kgdb) # ident /boot/kernel/kernel | grep netinet6 $FreeBSD: src/sys/netinet6/dest6.c,v 1.15 2008/12/02 21:37:28 bz Exp $ $FreeBSD: src/sys/netinet6/frag6.c,v 1.41 2008/12/02 21:37:28 bz Exp $ $FreeBSD: src/sys/netinet6/icmp6.c,v 1.101 2008/12/17 13:00:18 bz Exp $ $FreeBSD: src/sys/netinet6/in6.c,v 1.92 2008/12/22 07:11:15 qingli Exp $ $FreeBSD: src/sys/netinet6/in6_cksum.c,v 1.17 2007/12/10 16:03:37 obrien Exp $ $FreeBSD: src/sys/netinet6/in6_gif.c,v 1.34 2008/12/02 21:37:28 bz Exp $ $FreeBSD: src/sys/netinet6/in6_ifattach.c,v 1.53 2008/12/12 02:07:45 kmacy Exp $ $FreeBSD: src/sys/netinet6/in6_pcb.c,v 1.107 2008/12/15 21:50:54 bz Exp $ $FreeBSD: src/sys/netinet6/in6_proto.c,v 1.57 2008/12/11 16:26:38 bz Exp $ $FreeBSD: src/sys/netinet6/sctp6_var.h,v 1.10 2008/07/09 16:45:30 rrs Exp $ $FreeBSD: src/sys/netinet6/in6_rmx.c,v 1.34 2008/12/17 10:03:49 qingli Exp $ $FreeBSD: src/sys/netinet6/in6_src.c,v 1.65 2008/12/16 02:30:42 kmacy Exp $ $FreeBSD: src/sys/netinet6/ip6_forward.c,v 1.46 2008/12/02 21:37:28 bz Exp $ $FreeBSD: src/sys/netinet6/ip6_id.c,v 1.9 2007/12/10 16:03:38 obrien Exp $ $FreeBSD: src/sys/netinet6/ip6_input.c,v 1.112 2008/12/22 12:54:52 bz Exp $ $FreeBSD: src/sys/netinet6/ip6_output.c,v 1.127 2008/12/17 13:00:18 bz Exp $ $FreeBSD: src/sys/netinet6/mld6.c,v 1.39 2008/12/02 21:37:28 bz Exp $ $FreeBSD: src/sys/netinet6/nd6.c,v 1.103 2008/12/17 10:03:49 qingli Exp $ $FreeBSD: src/sys/netinet6/nd6_nbr.c,v 1.59 2008/12/16 02:47:22 kmacy Exp $ $FreeBSD: src/sys/netinet6/nd6_rtr.c,v 1.57 2008/12/17 10:27:34 qingli Exp $ $FreeBSD: src/sys/netinet6/raw_ip6.c,v 1.98 2008/12/17 13:00:18 bz Exp $ $FreeBSD: src/sys/netinet6/route6.c,v 1.18 2008/12/02 21:37:28 bz Exp $ $FreeBSD: src/sys/netinet6/scope6.c,v 1.22 2008/12/02 21:37:28 bz Exp $ $FreeBSD: src/sys/netinet6/sctp6_usrreq.c,v 1.47 2008/12/06 13:19:54 rrs Exp $ $FreeBSD: src/sys/netinet6/sctp6_var.h,v 1.10 2008/07/09 16:45:30 rrs Exp $ $FreeBSD: src/sys/netinet6/udp6_usrreq.c,v 1.103 2008/12/17 13:00:18 bz Exp $ %%% Cheers, Antoine From owner-freebsd-net@FreeBSD.ORG Tue Dec 23 22:39:32 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 58AF41065674; Tue, 23 Dec 2008 22:39:32 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp-3.dlr.de (smtp-3.dlr.de [195.37.61.187]) by mx1.freebsd.org (Postfix) with ESMTP id E05F58FC08; Tue, 23 Dec 2008 22:39:31 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from [129.247.12.20] ([129.247.12.20]) by smtp-3.dlr.de with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Dec 2008 23:39:30 +0100 Message-ID: <4951688D.5080202@dlr.de> Date: Tue, 23 Dec 2008 23:39:09 +0100 From: Hartmut Brandt User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Kip Macy References: <55f001c9639d$875f14ec$7202020a@internal.cacheflow.com> <4950F770.3090700@dlr.de> <3c1674c90812231408h53b16b4as5d3fa242e6d02a10@mail.gmail.com> In-Reply-To: <3c1674c90812231408h53b16b4as5d3fa242e6d02a10@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Dec 2008 22:39:30.0398 (UTC) FILETIME=[51AE77E0:01C9654F] Cc: Qing Li , "Li, Qing" , 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: Tue, 23 Dec 2008 22:39:32 -0000 Hi Kip, Kip Macy wrote: >>> 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, >>> > > The only reasonable way to do a full ports build is to ask portmgr to > use the build systems. Although it may now be possible with svn, in > the past there was no way for him to do that for out of tree code. > Hence portmgr does not share your point of view. > Well, they did this in the past, for example when I did some heavy work on make(1). At that time Kris did this, I don't know through which magic, though. > What we should have done is grepped for RTM_RESOLVE and the flags that > I removed. However, that did not occur to me. He asked on numerous > occasions for review and someone should have brought it up then. We do > not feel that it is reasonable to hold him solely responsible when he > did not act in a unilateral fashion. > > I usually take care of stuff that touches anything that has to do with the SNMP stuff, but this time the triggering did not work. I probably was sure that people will directly mail before touching someting in src/contrib. > Thank you for taking care of that bit of breakage. > No problem. That was a good kick to finally look how this vendor import stuff works and get the next import prepared. Don't take it too serious, 't was just a bad day (it started with a broken cup :-) harti From owner-freebsd-net@FreeBSD.ORG Wed Dec 24 01:09:30 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 93E511065670; Wed, 24 Dec 2008 01:09:30 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from rv-out-0708.google.com (rv-out-0708.google.com [209.85.198.248]) by mx1.freebsd.org (Postfix) with ESMTP id 0658A8FC12; Wed, 24 Dec 2008 01:09:29 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by rv-out-0708.google.com with SMTP id k29so3521670rvb.0 for ; Tue, 23 Dec 2008 17:09:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=bySXiBW+nKwBOSSXLNIuLWk/dZJl/8Uh6VMnJ/nMhec=; b=LRB4vFh4y8bH9CirQsFRywH5bznRLEvaEmroP81fnrRWTLuKw4ZBknPj/uvO4wriQ/ BpQLreinKjsDRbBJjDGy4sfB+g6kAWaLn5aEefkK5otPe1gQ8AU4dM+p7CPm3tChwge8 pyECLaNPDgkfRFluYA9BEyrVW1SNNrR70k60A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=GF5Fuqu1fdskVjnhagtaqHOPU95fmq1u1zaXnaMK/D1nir8S1Lrbvk/5kbjR/Z72F4 wpY33PoZ+sbJV0NR7u8eXl2K9ai2WG1pQgj5PWzoe5Pmpp65Ly3ASQXLOHIbvzfxTykQ bKFSiqT+m3Y5NUIe4WElgdBCZETHB+AMuIz+I= Received: by 10.141.128.19 with SMTP id f19mr4029744rvn.9.1230080969682; Tue, 23 Dec 2008 17:09:29 -0800 (PST) Received: by 10.141.37.17 with HTTP; Tue, 23 Dec 2008 17:09:29 -0800 (PST) Message-ID: <3c1674c90812231709u1e4b107du8995b6ffc6b8e80e@mail.gmail.com> Date: Tue, 23 Dec 2008 17:09:29 -0800 From: "Kip Macy" Sender: mat.macy@gmail.com To: "Antoine Brodin" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200812150634.mBF6YDVC060565@freefall.freebsd.org> X-Google-Sender-Auth: 7f3483265f5e0199 Cc: 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: Wed, 24 Dec 2008 01:09:30 -0000 The should be fixed with 186468. Please confirm. Thanks, Kip On Tue, Dec 23, 2008 at 2:01 PM, Antoine Brodin wrote: > On Mon, Dec 15, 2008 at 7:34 AM, Qing Li wrote: >> Hi All, >> >> The arp-v2 changes have been committed into HEAD. >> Please report problems to me and Kip Macy. > > Hi, > > I still have a panic with ipv6 enabled with current from yesterday > afternoon (in6.c rev 1.92): > > %%% > # cat info.1 > Dump header from device /dev/ad6s1b > Architecture: i386 > Architecture Version: 2 > Dump Length: 180998144B (172 MB) > Blocksize: 512 > Dumptime: Tue Dec 23 13:52:41 2008 > Hostname: barton.dreadbsd.org. > Magic: FreeBSD Kernel Dump > Version String: FreeBSD 8.0-CURRENT #2: Mon Dec 22 17:44:06 CET 2008 > root@barton.dreadbsd.org.:/usr/obj/usr/src/sys/GENERIC > Panic String: _rw_rlock (lle): wlock already held @ > /usr/src/sys/netinet6/in6.c:2221 > Dump Parity: 1345446215 > Bounds: 1 > Dump Status: good > > # kgdb /boot/kernel/kernel vmcore.1 > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i386-marcel-freebsd"... > > Unread portion of the kernel message buffer: > lock order reversal: > 1st 0xc549aa08 lle (lle) @ /usr/src/sys/netinet6/in6.c:2219 > 2nd 0xc51b9608 if_afdata (if_afdata) @ /usr/src/sys/netinet6/nd6_rtr.c:1336 > KDB: stack backtrace: > db_trace_self_wrapper(c0be5fcb,c4b88648,c08757f6,4,c0be152e,...) at > db_trace_self_wrapper+0x26 > kdb_backtrace(4,c0be152e,c4d26f50,c4d24ac0,c4b886a4,...) at kdb_backtrace+0x29 > _witness_debugger(c0be8cb5,c51b9608,c0bf1709,c4d24ac0,c0bfff5d,...) at > _witness_debugger+0x26 > witness_checkorder(c51b9608,9,c0bfff5d,538,0,...) at witness_checkorder+0x839 > _rw_wlock(c51b9608,c0bfff5d,538,c544c000,c51f6a80,...) at _rw_wlock+0x82 > find_pfxlist_reachable_router(f4,c549aa48,c4b88724,c08467fd,c0d35140,...) > at find_pfxlist_reachable_router+0x37 > pfxlist_onlink_check(c549aa00,3a98,6,1,c188ca38,...) at > pfxlist_onlink_check+0x2e > nd6_na_input(c544c000,28,20,1,7dc,...) at nd6_na_input+0x518 > icmp6_input(c4b88aa0,c4b88ab4,3a,c54230a4,c5923028,...) at icmp6_input+0x1cb6 > ip6_input(c58ed700,c070a8b2,86dd,c51b9400,86dd,...) at ip6_input+0x101d > netisr_dispatch(1b,c58ed700,c4ed6480,1,c51b9400,...) at netisr_dispatch+0x72 > ether_demux(c51b9400,c58ed700,3,0,3,...) at ether_demux+0x1f1 > ether_input(c51b9400,c58ed700,c549f000,c524b000,c58c8008,...) at > ether_input+0x37f > ieee80211_deliver_data(c524b000,c549f000,c58ed700,c4f1947c,4,...) at > ieee80211_deliver_data+0x94 > sta_input(c549f000,c58ed700,25,ffffffa0,669,...) at sta_input+0x9fc > ath_rx_proc(c4ede000,1,c0be7657,54,c4f0a35c,...) at ath_rx_proc+0x4b6 > taskqueue_run(c4f0a340,c4f0a35c,0,c0bd996f,0,...) at taskqueue_run+0x10b > taskqueue_thread_loop(c4ede26c,c4b88d38,c0bded0e,32d,c0d32c40,...) at > taskqueue_thread_loop+0x68 > fork_exit(c086ea30,c4ede26c,c4b88d38) at fork_exit+0xb8 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0, eip = 0, esp = 0xc4b88d70, ebp = 0 --- > panic: _rw_rlock (lle): wlock already held @ /usr/src/sys/netinet6/in6.c:2221 > cpuid = 0 > Uptime: 1h40m57s > Physical memory: 1519 MB > Dumping 172 MB: 157 141 125 109 93 77 61 45 29 13 > Reading symbols from /boot/kernel/sound.ko...Reading symbols from > /boot/kernel/sound.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/sound.ko > Reading symbols from /boot/kernel/snd_ich.ko...Reading symbols from > /boot/kernel/snd_ich.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/snd_ich.ko > Reading symbols from /boot/kernel/radeon.ko...Reading symbols from > /boot/kernel/radeon.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/radeon.ko > Reading symbols from /boot/kernel/drm.ko...Reading symbols from > /boot/kernel/drm.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/drm.ko > #0 doadump () at pcpu.h:246 > 246 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) bt > #0 doadump () at pcpu.h:246 > #1 0xc0833dcc in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:420 > #2 0xc08340a5 in panic (fmt=Variable "fmt" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:576 > #3 0xc0832526 in _rw_rlock (rw=0xc549aa08, file=0xc0bfe9e5 > "/usr/src/sys/netinet6/in6.c", line=2221) > at /usr/src/sys/kern/kern_rwlock.c:291 > #4 0xc09a722a in in6_lltable_lookup (llt=0xc5209e00, flags=0, > l3addr=0xc4b886a0) at /usr/src/sys/netinet6/in6.c:2221 > #5 0xc09b937c in nd6_lookup (addr6=0xc51ebc88, flags=0, > ifp=0xc51b9400) at if_llatbl.h:188 > #6 0xc09beef4 in find_pfxlist_reachable_router (pr=Variable "pr" is > not available. > ) at /usr/src/sys/netinet6/nd6_rtr.c:1337 > #7 0xc09bef8e in pfxlist_onlink_check () at > /usr/src/sys/netinet6/nd6_rtr.c:1376 > #8 0xc09bbde8 in nd6_na_input (m=0xc544c000, off=40, icmp6len=32) at > /usr/src/sys/netinet6/nd6_nbr.c:742 > #9 0xc09a5266 in icmp6_input (mp=0xc4b88aa0, offp=0xc4b88ab4, > proto=58) at /usr/src/sys/netinet6/icmp6.c:808 > #10 0xc09b2bdd in ip6_input (m=0xc58ed700) at > /usr/src/sys/netinet6/ip6_input.c:886 > #11 0xc08e2832 in netisr_dispatch (num=27, m=0xc58ed700) at > /usr/src/sys/net/netisr.c:178 > #12 0xc08dc221 in ether_demux (ifp=0xc51b9400, m=0xc58ed700) at > /usr/src/sys/net/if_ethersubr.c:864 > #13 0xc08dc68f in ether_input (ifp=0xc51b9400, m=0xc58ed700) at > /usr/src/sys/net/if_ethersubr.c:721 > #14 0xc08fe974 in ieee80211_deliver_data (vap=0xc524b000, > ni=dwarf2_read_address: Corrupted DWARF expression. > ) at /usr/src/sys/net80211/ieee80211_input.c:223 > #15 0xc091899c in sta_input (ni=0xc549f000, m=0xc58ed700, rssi=37, > noise=-96, rstamp=1641) > at /usr/src/sys/net80211/ieee80211_sta.c:824 > #16 0xc0584b26 in ath_rx_proc (arg=0xc4ede000, npending=1) at > /usr/src/sys/dev/ath/if_ath.c:4218 > #17 0xc086e93b in taskqueue_run (queue=0xc4f0a340) at > /usr/src/sys/kern/subr_taskqueue.c:282 > #18 0xc086ea98 in taskqueue_thread_loop (arg=0xc4ede26c) at > /usr/src/sys/kern/subr_taskqueue.c:403 > #19 0xc08108f8 in fork_exit (callout=0xc086ea30 > , arg=0xc4ede26c, frame=0xc4b88d38) > at /usr/src/sys/kern/kern_fork.c:821 > #20 0xc0b1a1d0 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:270 > (kgdb) > > # ident /boot/kernel/kernel | grep netinet6 > $FreeBSD: src/sys/netinet6/dest6.c,v 1.15 2008/12/02 21:37:28 bz Exp $ > $FreeBSD: src/sys/netinet6/frag6.c,v 1.41 2008/12/02 21:37:28 bz Exp $ > $FreeBSD: src/sys/netinet6/icmp6.c,v 1.101 2008/12/17 13:00:18 bz Exp $ > $FreeBSD: src/sys/netinet6/in6.c,v 1.92 2008/12/22 07:11:15 qingli Exp $ > $FreeBSD: src/sys/netinet6/in6_cksum.c,v 1.17 2007/12/10 16:03:37 > obrien Exp $ > $FreeBSD: src/sys/netinet6/in6_gif.c,v 1.34 2008/12/02 21:37:28 bz Exp $ > $FreeBSD: src/sys/netinet6/in6_ifattach.c,v 1.53 2008/12/12 > 02:07:45 kmacy Exp $ > $FreeBSD: src/sys/netinet6/in6_pcb.c,v 1.107 2008/12/15 21:50:54 bz Exp $ > $FreeBSD: src/sys/netinet6/in6_proto.c,v 1.57 2008/12/11 16:26:38 bz Exp $ > $FreeBSD: src/sys/netinet6/sctp6_var.h,v 1.10 2008/07/09 16:45:30 rrs Exp $ > $FreeBSD: src/sys/netinet6/in6_rmx.c,v 1.34 2008/12/17 10:03:49 > qingli Exp $ > $FreeBSD: src/sys/netinet6/in6_src.c,v 1.65 2008/12/16 02:30:42 kmacy Exp $ > $FreeBSD: src/sys/netinet6/ip6_forward.c,v 1.46 2008/12/02 > 21:37:28 bz Exp $ > $FreeBSD: src/sys/netinet6/ip6_id.c,v 1.9 2007/12/10 16:03:38 obrien Exp $ > $FreeBSD: src/sys/netinet6/ip6_input.c,v 1.112 2008/12/22 12:54:52 bz Exp $ > $FreeBSD: src/sys/netinet6/ip6_output.c,v 1.127 2008/12/17 > 13:00:18 bz Exp $ > $FreeBSD: src/sys/netinet6/mld6.c,v 1.39 2008/12/02 21:37:28 bz Exp $ > $FreeBSD: src/sys/netinet6/nd6.c,v 1.103 2008/12/17 10:03:49 qingli Exp $ > $FreeBSD: src/sys/netinet6/nd6_nbr.c,v 1.59 2008/12/16 02:47:22 kmacy Exp $ > $FreeBSD: src/sys/netinet6/nd6_rtr.c,v 1.57 2008/12/17 10:27:34 > qingli Exp $ > $FreeBSD: src/sys/netinet6/raw_ip6.c,v 1.98 2008/12/17 13:00:18 bz Exp $ > $FreeBSD: src/sys/netinet6/route6.c,v 1.18 2008/12/02 21:37:28 bz Exp $ > $FreeBSD: src/sys/netinet6/scope6.c,v 1.22 2008/12/02 21:37:28 bz Exp $ > $FreeBSD: src/sys/netinet6/sctp6_usrreq.c,v 1.47 2008/12/06 > 13:19:54 rrs Exp $ > $FreeBSD: src/sys/netinet6/sctp6_var.h,v 1.10 2008/07/09 16:45:30 rrs Exp $ > $FreeBSD: src/sys/netinet6/udp6_usrreq.c,v 1.103 2008/12/17 > 13:00:18 bz Exp $ > %%% > > Cheers, > > Antoine > _______________________________________________ > 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" > -- Als die Nazis die Kommunisten holten, habe ich geschwiegen; ich war ja kein Kommunist. Als sie die Sozialdemokraten einsperrten, habe ich geschwiegen; ich war ja kein Sozialdemokrat. Als sie die Gewerkschafter holten, habe ich nicht protestiert; ich war ja kein Gewerkschafter. Als sie die Juden holten, habe ich geschwiegen; ich war ja kein Jude. Als sie mich holten, gab es keinen mehr, der protestieren konnte. From owner-freebsd-net@FreeBSD.ORG Wed Dec 24 02:31:06 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 503571065670; Wed, 24 Dec 2008 02:31:06 +0000 (UTC) (envelope-from stutiredboy@gmail.com) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.187]) by mx1.freebsd.org (Postfix) with ESMTP id B6B598FC13; Wed, 24 Dec 2008 02:31:05 +0000 (UTC) (envelope-from stutiredboy@gmail.com) Received: by ti-out-0910.google.com with SMTP id a1so1797977tib.3 for ; Tue, 23 Dec 2008 18:31:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=NkzI3fZ6MjYGxH4Jg02KH/h5di7F0N5jMBxcDWlN0U8=; b=w9webGIcfmfhJUp0YdW2oX5oQ6/C1D9xZGCBAj2+WLuRPIesRYWviDP44KMBS7rabS Q8oLJb95zhE2xMLEOaoIM3OjK22ZXHEtR3bQPfkzHWWpF6fX16LTKOzmxpOmUTNe2yNM w46Iz5WGaeqeVO69+P7gsvE7b+tHHRZR9jFjQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=hLzeRsX8WlrGlY0TUzRZu+gVXzipPwQ+XBtdR8bwOjV3t+B1njDMfW3t8CAk/ZgkLP m7SOww7GcR8MR5//seo1zR24wceRPHQpLqFwhlK9mypOwhKJDrASScLefj3628U1MLiz BKf6sMK0k8dhQ9Xhtq14VnUI0/JSdTHVvYK0c= Received: by 10.110.43.18 with SMTP id q18mr12463374tiq.14.1230085864722; Tue, 23 Dec 2008 18:31:04 -0800 (PST) Received: from ?192.168.25.72? ([218.107.55.254]) by mx.google.com with ESMTPS id i6sm2913749tid.36.2008.12.23.18.31.02 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 23 Dec 2008 18:31:03 -0800 (PST) Message-ID: <49519EE4.7040109@gmail.com> Date: Wed, 24 Dec 2008 10:31:00 +0800 From: stutiredboy User-Agent: Mozilla-Thunderbird 2.0.0.17 (X11/20081018) MIME-Version: 1.0 To: Hajimu UMEMOTO References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org Subject: Re: [help]strange problem about gethostbyname/getaddrinfo 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: Wed, 24 Dec 2008 02:31:06 -0000 Hajimu UMEMOTO 写道: > Hi, > > >>>>>> On Wed, 10 Dec 2008 13:48:51 +0800 >>>>>> "=?GB2312?B?s8LQocn6?=" said: >>>>>> > > stutiredboy> hi,all,we have a project which must resolv some domains in the server > stutiredboy> process > stutiredboy> our system in FreeBSD 6.2 or 6.3, the server process may open 7000+ > stutiredboy> sockets,not fork > > Umm, it seems your system is slightly old. I believe 6.3-RELEASE is > okay. But, there was a bug on 6.2 and earlier that rejected file > descriptors higher than FD_SETSIZE even when using kevent(2). > > http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/resolv/res_send.c#rev1.2.2.5 > > Perhaps, it is your case. > > Sincerely, > > -- > Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan > ume@mahoroba.org ume@{,jp.}FreeBSD.org > http://www.imasy.org/~ume/ > hi, thanks for your response, but the testing server we use is FreeBSD 6.3, %uname -a FreeBSD localhost 6.3-RELEASE FreeBSD 6.3-RELEASE #0: Wed Jan 16 04:45:45 UTC 2008 root@dessler.cse.buffalo.edu:/usr/obj/usr/src/sys/SMP i386 Best Wishes ! From owner-freebsd-net@FreeBSD.ORG Wed Dec 24 03:05:54 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D446F1065674 for ; Wed, 24 Dec 2008 03:05:54 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id C15628FC14 for ; Wed, 24 Dec 2008 03:05:54 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id AAB861A3C3A; Tue, 23 Dec 2008 19:05:54 -0800 (PST) Date: Tue, 23 Dec 2008 19:05:54 -0800 From: Alfred Perlstein To: Doug Barton Message-ID: <20081224030554.GX18389@elvis.mu.org> References: <20081223001216.GH18389@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: net@freebsd.org Subject: Re: ipv6 bugfix, need review. 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: Wed, 24 Dec 2008 03:05:54 -0000 * Doug Barton [081223 11:46] wrote: > On Mon, 22 Dec 2008, Alfred Perlstein wrote: > > >Hey guys, we found a bug at Juniper and it resolves an issue > >for us. I've been asked to forward this to FreeBSD, I honestly > >am not that clear on the issue so I'm hoping someone can step > >up to review this. > > > >Synopsis is: > > > > The traffic class byte is set to 0x00000000 in the header of some > > BGP packets sent between interfaces that have IPv6 addresses, > > instead of the correct setting 0xc0 (INTERNETCONTROL). > > > >Fix is small and attached. One thing I am wondering, do we > >need to check "if (inp)" ? I don't think so. > > How about adding an assert to the patch to prove this theory? :) > > I'll test it on my home box (which has IPv6) as soon as I'm done with the > stuff I'm working on atm. > > > hth, > > Doug Thanks Doug, will do. Please let me know results. do you know how to test if this is actually being excersized? I guess you could add a sysctl that gets incremented each time this codepath is hit to test? -- - Alfred Perlstein From owner-freebsd-net@FreeBSD.ORG Wed Dec 24 08:58:24 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 CA7E71065689; Wed, 24 Dec 2008 08:58:24 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (lefty.soaustin.net [66.135.55.46]) by mx1.freebsd.org (Postfix) with ESMTP id AA7918FC17; Wed, 24 Dec 2008 08:58:24 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: by mail.soaustin.net (Postfix, from userid 502) id 528458C049; Wed, 24 Dec 2008 02:35:00 -0600 (CST) Date: Wed, 24 Dec 2008 02:35:00 -0600 To: Hartmut Brandt Message-ID: <20081224083500.GB8120@soaustin.net> References: <55f001c9639d$875f14ec$7202020a@internal.cacheflow.com> <4950F770.3090700@dlr.de> <3c1674c90812231408h53b16b4as5d3fa242e6d02a10@mail.gmail.com> <4951688D.5080202@dlr.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4951688D.5080202@dlr.de> User-Agent: Mutt/1.5.13 (2006-08-11) From: linimon@lonesome.com (Mark Linimon) Cc: Kip Macy , "Li, Qing" , freebsd-current@freebsd.org, freebsd-net@freebsd.org, Qing Li 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: Wed, 24 Dec 2008 08:58:24 -0000 On Tue, Dec 23, 2008 at 11:39:09PM +0100, Hartmut Brandt wrote: > Well, they did this in the past, for example when I did some heavy work > on make(1). At that time Kris did this, I don't know through which > magic, though. Just email portmgr@ and ask for a regression-test on the build cluster. We generally use amd64-7 and tell it "rebuild all ports with the following modified src tree." We can't guarantee that it will happen immediately (we do use the cluster for building packages, after all :-) ) but we do our best to make it a 2-way street. mcl From owner-freebsd-net@FreeBSD.ORG Wed Dec 24 11:09:29 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E4EE1065675; Wed, 24 Dec 2008 11:09:29 +0000 (UTC) (envelope-from p.pisati@oltrelinux.com) Received: from averell.mail.tiscali.it (averell.mail.tiscali.it [213.205.33.55]) by mx1.freebsd.org (Postfix) with ESMTP id F27368FC14; Wed, 24 Dec 2008 11:09:28 +0000 (UTC) (envelope-from p.pisati@oltrelinux.com) Received: from newluxor.wired.org (94.36.96.206) by averell.mail.tiscali.it (8.0.022) id 4948FCD50049CECD; Wed, 24 Dec 2008 11:57:44 +0100 Message-ID: <495215A6.2040002@oltrelinux.com> Date: Wed, 24 Dec 2008 11:57:42 +0100 From: Paolo Pisati User-Agent: Thunderbird 2.0.0.18 (X11/20081214) MIME-Version: 1.0 To: Julian Elischer References: <7ihc4u3adr.wl%gnn@neville-neil.com> <4951515C.4030706@elischer.org> In-Reply-To: <4951515C.4030706@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: gnn@freebsd.org, net@freebsd.org Subject: Re: A new tool for low level testing... 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: Wed, 24 Dec 2008 11:09:29 -0000 Julian Elischer wrote: > > OR > > ngctl mkpeer em0: echo lower echo > > > hmmmmm no this would leave the source and destination headers in hte > same order.. they need to be swapped.. > > ok so I need to make a patch, but it would be much quicker than a user > utility.. what about a netgraph cookbook? From owner-freebsd-net@FreeBSD.ORG Wed Dec 24 11:30:16 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D21831065678; Wed, 24 Dec 2008 11:30:16 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id 961B78FC1B; Wed, 24 Dec 2008 11:30:16 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 212A57309E; Wed, 24 Dec 2008 12:15:46 +0100 (CET) Date: Wed, 24 Dec 2008 12:15:46 +0100 From: Luigi Rizzo To: Paolo Pisati Message-ID: <20081224111546.GA59523@onelab2.iet.unipi.it> References: <7ihc4u3adr.wl%gnn@neville-neil.com> <4951515C.4030706@elischer.org> <495215A6.2040002@oltrelinux.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <495215A6.2040002@oltrelinux.com> User-Agent: Mutt/1.4.2.3i Cc: gnn@freebsd.org, Julian Elischer , net@freebsd.org Subject: Re: A new tool for low level testing... 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: Wed, 24 Dec 2008 11:30:16 -0000 On Wed, Dec 24, 2008 at 11:57:42AM +0100, Paolo Pisati wrote: > Julian Elischer wrote: > > > >OR > > > >ngctl mkpeer em0: echo lower echo > > > > > >hmmmmm no this would leave the source and destination headers in hte > >same order.. they need to be swapped.. > > > >ok so I need to make a patch, but it would be much quicker than a user > >utility.. > what about a netgraph cookbook? indeed, that would be a nice Xmas present! cheers luigi From owner-freebsd-net@FreeBSD.ORG Wed Dec 24 12:46:23 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 F32501065674 for ; Wed, 24 Dec 2008 12:46:23 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail10.syd.optusnet.com.au (mail10.syd.optusnet.com.au [211.29.132.191]) by mx1.freebsd.org (Postfix) with ESMTP id 9017B8FC0C for ; Wed, 24 Dec 2008 12:46:23 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c122-107-121-84.carlnfd1.nsw.optusnet.com.au (c122-107-121-84.carlnfd1.nsw.optusnet.com.au [122.107.121.84]) by mail10.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id mBOCkDZm014361 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Dec 2008 23:46:19 +1100 Date: Wed, 24 Dec 2008 23:46:12 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Randall Stewart In-Reply-To: <4A152664-B170-4C6C-85C1-58E2E1577CA3@lakerest.net> Message-ID: <20081224232356.O754@delplex.bde.org> References: <494157DF.6030802@FreeBSD.org> <13C9478E-CBF6-4EDA-8E78-AD76549EB844@lakerest.net> <200812132030.15665.max@love2party.net> <4A152664-B170-4C6C-85C1-58E2E1577CA3@lakerest.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net Subject: Re: Heads up --- Thinking about UDP and tunneling 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: Wed, 24 Dec 2008 12:46:24 -0000 On Tue, 23 Dec 2008, Randall Stewart wrote: > 4) revamped my s9indent use.. I ran it and then patched back > in just its complaints about me... that way the other s9 issues > can stay in the file untouched by me :-D Thanks, but it still has many of the style bugs already pointed out and a few new ones. Please fix them and s9indent so that they don't get pointed out again :-). % Index: netinet/udp_usrreq.c % =================================================================== % --- netinet/udp_usrreq.c (revision 185928) % +++ netinet/udp_usrreq.c (working copy) % @@ -488,41 +488,76 @@ % struct mbuf *n; % % n = m_copy(m, 0, M_COPYALL); % - if (n != NULL) % - udp_append(last, ip, n, iphlen + % - sizeof(struct udphdr), &udp_in); % - INP_RUNLOCK(last); % + Extra blank line. % + if (last->inp_ppcb == NULL) { % + if (n != NULL) % + udp_append(last, ip, n, iphlen + % + sizeof(struct udphdr), &udp_in); Line too long. % + INP_RUNLOCK(last); % + } else { % + /* % + * Engage the tunneling protocol we % + * will have to leave the info_lock % + * up, since we are hunting through % + * multiple UDP inp's hope we don't % + * break :-( Missing punctuation. % + * % + * XXXML: Maybe add a flag to the % + * prototype so that the tunneling % + * can defer work that can't be done % + * under the info lock? % + */ % + udp_tunnel_func_t tunnel_func; This typedef is very verbose... % + % + tunnel_func = (udp_tunnel_func_t) last->inp_ppcb; ... line too long, caused by the verbose typedef. Casts are not followed by a space in KNF. This style bug is made fairly consistently in this patch. Bogus cast (depends on undefined behaviour to save space). % + tunnel_func(m, iphlen, last); % + INP_RUNLOCK(last); % + } % } % last = inp; % /* % - * Don't look for additional matches if this one does % - * not have either the SO_REUSEPORT or SO_REUSEADDR % - * socket options set. This heuristic avoids % - * searching through all pcbs in the common case of a % - * non-shared port. It assumes that an application % - * will never clear these options after setting them. % + * Don't look for additional matches if this one % + * does not have either the SO_REUSEPORT or % + * SO_REUSEADDR socket options set. This heuristic % + * avoids searching through all pcbs in the common % + * case of a non-shared port. It assumes that an % + * application will never clear these options after % + * setting them. % */ % if ((last->inp_socket->so_options & % - (SO_REUSEPORT|SO_REUSEADDR)) == 0) % + (SO_REUSEPORT | SO_REUSEADDR)) == 0) You didn't have to touch this statement. Touching it improves it. % break; % } % % if (last == NULL) { % /* % - * No matching pcb found; discard datagram. (No need % - * to send an ICMP Port Unreachable for a broadcast % - * or multicast datgram.) % + * No matching pcb found; discard datagram. (No % + * need to send an ICMP Port Unreachable for a % + * broadcast or multicast datgram.) You didn't have to touch this. Touching it unimproves it. % ... % } % - % /* % * Locate pcb for datagram. % */ % @@ -553,7 +588,6 @@ % INP_INFO_RUNLOCK(&V_udbinfo); % return; % } % - % /* % * Check the minimum TTL for socket. % */ You didn't have to touch these. Touching them arguably unimproves them, though strict KNF probably doesn't permit these blank lines. % @@ -563,6 +597,18 @@ % INP_RUNLOCK(inp); % goto badunlocked; % } % + if (inp->inp_ppcb) { It is preferable to compare pointers explicitly with NULL. The previous comparision of inp_ppcb in this patch is explicit (but it is for equality). This and all of the following comparisions are implicit (for inequality). % @@ -1138,10 +1184,41 @@ % INP_INFO_WUNLOCK(&V_udbinfo); % inp->inp_vflag |= INP_IPV4; % inp->inp_ip_ttl = V_ip_defttl; % + /* % + * UDP does not have a per-protocol % + * pcb (inp->inp_ppcb). We use this % + * pointer for kernel tunneling pointer. % + * If we ever need to have a protocol % + * block we will need to move this % + * function pointer there. Null % + * in this pointer means "do the normal % + * thing". % + */ Lines too short (formatted for 50-column terminals). Normal entence breaks are 2 spaces, not 1 as in this comment. Most of the other comments in this patch have normal sentence breakes. % ... % +int % +udp_set_kernel_tunneling(struct socket *so, udp_tunnel_func_t f) % +{ % + struct inpcb *inp; Missing blank line after declarations. % + inp = (struct inpcb *)so->so_pcb; % + Extra blank line. % + if (so->so_type != SOCK_DGRAM) { % + /* Not UDP socket... sorry */ Missing punctuation. % Index: netinet/udp_var.h % =================================================================== % --- netinet/udp_var.h (revision 185928) % +++ netinet/udp_var.h (working copy) % @@ -107,6 +107,10 @@ % void udp_input(struct mbuf *, int); % struct inpcb *udp_notify(struct inpcb *inp, int errno); % int udp_shutdown(struct socket *so); % + % + % +typedef void(*udp_tunnel_func_t)(struct mbuf *, int off, struct inpcb *); % +int udp_set_kernel_tunneling(struct socket *so, udp_tunnel_func_t f); % #endif % % #endif Still has a style bug density of about 5 per line :-(. % Index: netinet6/udp6_usrreq.c Similarly. Bruce From owner-freebsd-net@FreeBSD.ORG Wed Dec 24 14:00:40 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 DD384106564A for ; Wed, 24 Dec 2008 14:00:40 +0000 (UTC) (envelope-from yonyossef.lists@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.31]) by mx1.freebsd.org (Postfix) with ESMTP id 7BE798FC1B for ; Wed, 24 Dec 2008 14:00:40 +0000 (UTC) (envelope-from yonyossef.lists@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so1782788ywe.13 for ; Wed, 24 Dec 2008 06:00:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:mime-version:content-type:content-transfer-encoding :content-disposition; bh=I5n16JX6L3O/3G9v/1qTdVcO64JYR1E2c7rSGfIR6Vg=; b=ulC6rmgg111/zibpeYmQHCIXckTEcmAuGjTp0leLa79zUNnIaq8CaSXagPzsQS5sEY Xww1TcZJGsnX/ztuQnx1HRNHleGmlFuCTfR8XW/mvOmaZ4r0Sb4vcZGHsicawYUN913I h5f6ERNWjHciDKyCOpUKLNpqfZZdfl2GOfz/4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:mime-version:content-type :content-transfer-encoding:content-disposition; b=h2ksgmrJBkC5VaI5o4DT7AteGHwTEWrln9ArlRJgz3lvhNtbiyruBcquyJvtWrQAHC VuZfq6gDyvEQj1UU8b8PKIXzZnOuvw7SudocMGQh8avGmkwPhI+2838PPVHG8Nzhyilp wpU6xuS8dQ8cBTH6RjsrDHEVoMetq5FHSszU0= Received: by 10.150.50.1 with SMTP id x1mr16083355ybx.213.1230127239289; Wed, 24 Dec 2008 06:00:39 -0800 (PST) Received: by 10.150.157.20 with HTTP; Wed, 24 Dec 2008 06:00:39 -0800 (PST) Message-ID: <20def4870812240600n6edbcad7k2100a0ccbe49f0dd@mail.gmail.com> Date: Wed, 24 Dec 2008 16:00:39 +0200 From: "Yony Yossef" To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: eitans@mellanox.co.il, Yehonatan Yossef , liranl@mellanox.co.il, yevgenyp@mellanox.co.il Subject: net.inet.udp.blackhole issue 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: Wed, 24 Dec 2008 14:00:40 -0000 Hi All, I'm facing lots of UDP "Connection refused" errors while running multistream iperf test. Analyzing it with wireshark showed several "ICMP Port Unreachable" problems. I've overriden it with "sysctl net.inet.udp.blackhole=1", but I'm not sure this is the correct thing to do, I feel like I've sweeped the problem under the carpet. PS - I see similar failures with TCP bidirectional iperf test, it can also be overriden by "sysctl net.inet.tcp.blackhole=1". My question is - can it be a NIC problem? If so, how can a driver problem cause an iperf UDP socket to be in a "non listening state"? Thanks, Yony From owner-freebsd-net@FreeBSD.ORG Wed Dec 24 14:03:35 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 544AC1065679; Wed, 24 Dec 2008 14:03:35 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 223858FC14; Wed, 24 Dec 2008 14:03:34 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id DD9591F1666; Wed, 24 Dec 2008 09:03:33 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Wed, 24 Dec 2008 09:03:33 -0500 X-Sasl-enc: mkUHPkOqXG0YI+eq0vXJuMNs1Jr4yFCM/aIv8EoTXUrZ 1230127413 Received: from anglepoise.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id C6BB715EED; Wed, 24 Dec 2008 09:03:32 -0500 (EST) Message-ID: <49524131.7010700@incunabulum.net> Date: Wed, 24 Dec 2008 14:03:29 +0000 From: Bruce Simpson User-Agent: Thunderbird 2.0.0.18 (X11/20081204) MIME-Version: 1.0 To: Ian FREISLICH References: <494FAFAC.90802@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Gerald Pfeifer , Vladimir Grebenschikov , Kip Macy , Qing Li , freebsd-net@freebsd.org, freebsd-current@freebsd.org, Sergey Matveychuk 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: Wed, 24 Dec 2008 14:03:35 -0000 Ian FREISLICH wrote: > ... > I can't quite remember exactly why imr_ifindex doesn't work, but > on my hosts which have several hundred interfaces and my OSPF > sessions are never on the interface that has the default route, > until I explicitly set the imr_address, the kernel always chooses > the interface which has the default route. > Do you have applications which do not explicitly specify the interface address to use for multicast group joins? If they do not, that's a bug in the application -- IPv4 and IPv6 multicast *requires* that a link be specified somehow, either using the new APIs which take an ifindex, or an IPv4 "primary address". Unfortunately there has been historical breakage in the multicast APIs. There are some apps which run before all interfaces have been ifconfig'd up in the system, and they need to create multicast sockets. The kernel behaviour you describe is historical and I had to reintroduce it to avoid breaking such applications. It is a kludge which we probably can't retire until their developers fix their multicast apps to be aware of multiple interfaces on the system. This ground is well covered in the literature and the RFCs. thanks, BMS From owner-freebsd-net@FreeBSD.ORG Wed Dec 24 14:16:53 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 E6511106568A; Wed, 24 Dec 2008 14:16:53 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id B4F428FC14; Wed, 24 Dec 2008 14:16:53 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 4782B1F4FDD; Wed, 24 Dec 2008 09:16:53 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute2.internal (MEProxy); Wed, 24 Dec 2008 09:16:53 -0500 X-Sasl-enc: o6f51Gzd5M1PPItepSC1ie5jW4a+9eJvdHwxKMRI3XGb 1230128212 Received: from anglepoise.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 36CF724E1A; Wed, 24 Dec 2008 09:16:52 -0500 (EST) Message-ID: <49524453.7080709@incunabulum.net> Date: Wed, 24 Dec 2008 14:16:51 +0000 From: Bruce Simpson User-Agent: Thunderbird 2.0.0.18 (X11/20081204) MIME-Version: 1.0 To: Kip Macy References: <55f001c9639d$875f14ec$7202020a@internal.cacheflow.com> <4950F770.3090700@dlr.de> <3c1674c90812231408h53b16b4as5d3fa242e6d02a10@mail.gmail.com> In-Reply-To: <3c1674c90812231408h53b16b4as5d3fa242e6d02a10@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Qing Li , "Li, Qing" , freebsd-current@freebsd.org, Hartmut Brandt , freebsd-net@freebsd.org Subject: Comment re ARP work and ad-hoc networking 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: Wed, 24 Dec 2008 14:16:54 -0000 The ARPv2 snap makes things that much more interesting. I can foresee that folk may wish to do things e.g. with MANET protocols. In an ad-hoc wireless world, things happen very differently. Both ARP and IGMP straddle layer boundaries in the ISO 7 -layer model, and are geared towards fixed network topologies which don't change dynamically over small t time. Nothing out there in open source land really deals with the split all that elegantly. Because ad-hoc protocols enable the endpoints to discover each other dynamically, and there may be multiple ingress/egress points, you can effectively populate the ARP table i.e. based on MANET "hello" messages. Of course now that ARP is out of the routing table, this probably makes things easier in this regard. But as Sam points out, we may be better off with a new kernel comm mechanism. Linux's netlink socket has an Informational RFC, and as such is not subject to the GPL -- one cannot copyright an idea. Whilst implementing it would be a lot of work, it is one good way to proceed as it then ties everything together under one API, which would greatly help folk writing network apps. Of course, without a compelling case for going off and doing the work (i.e. funded), this is largely hand-waving and just a suggestion I'm putting out 'out there'. just my 2p BMS From owner-freebsd-net@FreeBSD.ORG Wed Dec 24 14:27:23 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 A85371065675; Wed, 24 Dec 2008 14:27:23 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 7A82C8FC1A; Wed, 24 Dec 2008 14:27:23 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 12F021F501B; Wed, 24 Dec 2008 09:27:23 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Wed, 24 Dec 2008 09:27:23 -0500 X-Sasl-enc: jAEfYLQyGjg4qGkbk8h/52B8ABzqbl/QswfKrmRAraue 1230128842 Received: from anglepoise.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 445A147243; Wed, 24 Dec 2008 09:27:22 -0500 (EST) Message-ID: <495246C9.9090305@incunabulum.net> Date: Wed, 24 Dec 2008 14:27:21 +0000 From: Bruce Simpson User-Agent: Thunderbird 2.0.0.18 (X11/20081204) MIME-Version: 1.0 To: Hartmut Brandt References: <55f001c9639d$875f14ec$7202020a@internal.cacheflow.com> <4950F770.3090700@dlr.de> <495165D8.2070409@dlr.de> In-Reply-To: <495165D8.2070409@dlr.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Qing Li , "Li, Qing" , freebsd-current@freebsd.org, freebsd-net@freebsd.org Subject: NATM hardware available 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: Wed, 24 Dec 2008 14:27:23 -0000 Hartmut Brandt wrote: > > In any case there is still an Todo on my side: the routing information > for NETNATM is currently lost somewhere between L2 and L3 :-) I guess > I come back to you in the new year to fix this issue... Have to fetch > my ATM equipment from the corner where it is collecting dust to setup > a testbed. Guys: Native NATM support would be nice, because it lets FreeBSD be used as a direct ADSL endpoint without an external ADSL router. I have a pair of ATM25 cards, an ATM25 crossover, and an ATM25-to-ADSL G.DMT modem bagged up ready to ship to someone who has the time and motivation to work on NATM. Also: I did have an ATM25 capable switch which I left at ICSI in Berkeley, I don't know where it is at the moment due to people movements. thanks BMS From owner-freebsd-net@FreeBSD.ORG Wed Dec 24 14:35:27 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 0D2DE106564A; Wed, 24 Dec 2008 14:35:27 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id D0EF58FC14; Wed, 24 Dec 2008 14:35:26 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 53DD01EFB9A; Wed, 24 Dec 2008 09:35:26 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Wed, 24 Dec 2008 09:35:26 -0500 X-Sasl-enc: 2ilzggWBxrl4mHl1cTweJZ+Y2utxuMPA1LJ5P5atjW0Y 1230129326 Received: from anglepoise.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 0CBDC24E20; Wed, 24 Dec 2008 09:35:24 -0500 (EST) Message-ID: <495248AB.1050106@incunabulum.net> Date: Wed, 24 Dec 2008 14:35:23 +0000 From: Bruce Simpson User-Agent: Thunderbird 2.0.0.18 (X11/20081204) MIME-Version: 1.0 To: Qing Li References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Gerald Pfeifer , freebsd-current@freebsd.org, Vladimir Grebenschikov , Kip Macy , Ian FREISLICH , freebsd-net@freebsd.org, Erwin Lansing 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: Wed, 24 Dec 2008 14:35:27 -0000 Ian FREISLICH wrote: > You can add net/quagga to that list as well. > net/xorp got bit too. XORP doesn't do anything with the RTF_LLINFO information, so I have checked in a 2 line fix to the XORP repo. The ability to turn off ARP, or redirect ARP processing to a userland daemon, would be interesting -- both for reasons I've given in my message about MANET impact -- and for the reason that XORP has link layer capability to support IS-IS and VRRP, it could do ARP too. thanks, BMS From owner-freebsd-net@FreeBSD.ORG Wed Dec 24 15:41:55 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 2B5EC1065673 for ; Wed, 24 Dec 2008 15:41:55 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from proxy.meer.net (proxy.meer.net [64.13.141.13]) by mx1.freebsd.org (Postfix) with ESMTP id 094E48FC0C for ; Wed, 24 Dec 2008 15:41:55 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mail.meer.net (mail.meer.net [64.13.141.3]) by proxy.meer.net (8.14.2/8.14.2) with ESMTP id mBOFfrpU087581; Wed, 24 Dec 2008 07:41:54 -0800 (PST) (envelope-from gnn@neville-neil.com) Received: from mail2.meer.net (mail2.meer.net [64.13.141.16]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id mBOFfFDF070041; Wed, 24 Dec 2008 07:41:15 -0800 (PST) (envelope-from gnn@neville-neil.com) Received: from gnnbsd.hudson-trading.com.neville-neil.com (209.249.190.8.available.above.net [209.249.190.8] (may be forged)) (authenticated bits=0) by mail2.meer.net (8.14.1/8.14.1) with ESMTP id mBOFfFS0075309; Wed, 24 Dec 2008 07:41:15 -0800 (PST) (envelope-from gnn@neville-neil.com) Date: Wed, 24 Dec 2008 10:41:14 -0500 Message-ID: <7i7i5pr36t.wl%gnn@neville-neil.com> From: gnn@freebsd.org To: "Vladimir V. Kobal" In-Reply-To: <000301c9653f$f32c6dd0$d9854970$@net> References: <004a01c961ec$ec136540$c43a2fc0$@net> <7ik59sgrgd.wl%gnn@neville-neil.com> <000201c964f5$aa94e6a0$ffbeb3e0$@net> <7ik59q3csb.wl%gnn@neville-neil.com> <000301c9653f$f32c6dd0$d9854970$@net> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.7 Emacs/22.3 (amd64-portbld-freebsd7.1) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Canit-CHI2: 0.50 X-Bayes-Prob: 0.5 (Score 0, tokens from: ) X-Spam-Score: 0.10 () [Tag at 5.00] COMBINED_FROM X-CanItPRO-Stream: default X-Canit-Stats-ID: 2815443 - 778ae9fe2d94 X-Scanned-By: CanIt (www . roaringpenguin . com) on 64.13.141.13 Cc: freebsd-net@freebsd.org Subject: Re: Panic on boot with em1 attached 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: Wed, 24 Dec 2008 15:41:55 -0000 At Tue, 23 Dec 2008 22:49:24 +0200, Vladimir V. Kobal wrote: > > We are using pf+ALTQ for shaping and ipfw for filtering, diverting into > netgraph nodes, attaching altq queues. > OK, that also makes sense given what I saw in the code. Can you explain your entire setup? That is, which filters, which interfaces, what bits of netgraph etc. Best, George From owner-freebsd-net@FreeBSD.ORG Wed Dec 24 15:43:53 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84C2A106564A for ; Wed, 24 Dec 2008 15:43:53 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from proxy.meer.net (proxy.meer.net [64.13.141.13]) by mx1.freebsd.org (Postfix) with ESMTP id 6451D8FC1A for ; Wed, 24 Dec 2008 15:43:53 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mail.meer.net (mail.meer.net [64.13.141.3]) by proxy.meer.net (8.14.2/8.14.2) with ESMTP id mBOFhf4g087914; Wed, 24 Dec 2008 07:43:53 -0800 (PST) (envelope-from gnn@neville-neil.com) Received: from mail2.meer.net (mail2.meer.net [64.13.141.16]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id mBOFh89d070826; Wed, 24 Dec 2008 07:43:08 -0800 (PST) (envelope-from gnn@neville-neil.com) Received: from gnnbsd.hudson-trading.com.neville-neil.com (209.249.190.8.available.above.net [209.249.190.8] (may be forged)) (authenticated bits=0) by mail2.meer.net (8.14.1/8.14.1) with ESMTP id mBOFh8R1075689; Wed, 24 Dec 2008 07:43:08 -0800 (PST) (envelope-from gnn@neville-neil.com) Date: Wed, 24 Dec 2008 10:43:07 -0500 Message-ID: <7i63l9r33o.wl%gnn@neville-neil.com> From: gnn@freebsd.org To: Julian Elischer In-Reply-To: <4951515C.4030706@elischer.org> References: <7ihc4u3adr.wl%gnn@neville-neil.com> <4951515C.4030706@elischer.org> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.7 Emacs/22.3 (amd64-portbld-freebsd7.1) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Canit-CHI2: 0.50 X-Bayes-Prob: 0.5 (Score 0, tokens from: ) X-Spam-Score: 0.10 () [Tag at 5.00] COMBINED_FROM X-CanItPRO-Stream: default X-Canit-Stats-ID: 2815540 - 3d2f5ffd460c X-Scanned-By: CanIt (www . roaringpenguin . com) on 64.13.141.13 Cc: net@freebsd.org Subject: Re: A new tool for low level testing... 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: Wed, 24 Dec 2008 15:43:53 -0000 At Tue, 23 Dec 2008 13:00:12 -0800, julian wrote: > > gnn@freebsd.org wrote: > > Hi, > > > > I just checked in a small tool to HEAD in > > /usr/src/tools/tools/ether_reflect which uses pcap and bpf to reflect > > ethernet packets just about the driver layer without involving the > > protocol stacks. This is useful for people doing low level testing of > > drivers and switches. If you happen to be lucky enough to have an > > ethernet packet generator (ixia et al) this will do what you want in > > terms of reflecting the packets back. > > > > Later, > > George > > _______________________________________________ > > 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" > > > OR > > ngctl mkpeer em0: echo lower echo > > > hmmmmm no this would leave the source and destination headers in hte > same order.. they need to be swapped.. > > ok so I need to make a patch, but it would be much quicker than a user > utility.. I agree that netgraph is the right long term answer. I look forward to what you come up with. Also, +1 to an improved set of docs on netgraph. Later, George From owner-freebsd-net@FreeBSD.ORG Wed Dec 24 15:44:36 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 9C09E1065687; Wed, 24 Dec 2008 15:44:36 +0000 (UTC) (envelope-from antoine.brodin.freebsd@gmail.com) Received: from mail-bw0-f19.google.com (mail-bw0-f19.google.com [209.85.218.19]) by mx1.freebsd.org (Postfix) with ESMTP id 643DA8FC1C; Wed, 24 Dec 2008 15:44:29 +0000 (UTC) (envelope-from antoine.brodin.freebsd@gmail.com) Received: by bwz12 with SMTP id 12so8751006bwz.19 for ; Wed, 24 Dec 2008 07:44:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=J+NsKe8aGG7kp4z4TiL8g1cCFXPiZP64amDWCw2GwnA=; b=P0Ucbw/8/gGRScMEi0GWOMruW+tupd7/BxIh0nhFACWLAnUyhWDvBjR4L9yjOjQNZt xtdITu55jI7Hc3QUTEKN6hVnJIwBfyBsOQpCiM09i1p6qzcxNIdcjY3ZjuMLCJkyC1uy CaBVVYCaEY15VKXM0lRvw5Rmns5AS9GfC38sk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=ZwzlgY/jeCItn+GnbPty9vnlH1zX5PYqnLz+FYNCZxVkQMJMBLYyR0V/au+YOPRxgJ udubyVizhTKUcH8Q/S3m0F32SPPV7cM9XPbgaM3Vw3/YFRR3WzzBQQvBF1NGEtssie36 PvyJjCHf01VNsndX/cUUttPm5qz+4GDPXK2ik= Received: by 10.181.58.9 with SMTP id l9mr3174601bkk.214.1230133468725; Wed, 24 Dec 2008 07:44:28 -0800 (PST) Received: by 10.181.136.11 with HTTP; Wed, 24 Dec 2008 07:44:28 -0800 (PST) Message-ID: Date: Wed, 24 Dec 2008 16:44:28 +0100 From: "Antoine Brodin" Sender: antoine.brodin.freebsd@gmail.com To: "Kip Macy" In-Reply-To: <3c1674c90812231709u1e4b107du8995b6ffc6b8e80e@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200812150634.mBF6YDVC060565@freefall.freebsd.org> <3c1674c90812231709u1e4b107du8995b6ffc6b8e80e@mail.gmail.com> X-Google-Sender-Auth: 47a3e12f4d4d2352 Cc: 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: Wed, 24 Dec 2008 15:44:36 -0000 On Wed, Dec 24, 2008 at 2:09 AM, Kip Macy wrote: > The should be fixed with 186468. Please confirm. Yes it seems to be fixed, thanks! Cheers, Antoine From owner-freebsd-net@FreeBSD.ORG Wed Dec 24 15:56:50 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 80AF41065670; Wed, 24 Dec 2008 15:56:50 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from inbound01.jnb1.gp-online.net (inbound01.jnb1.gp-online.net [41.161.16.135]) by mx1.freebsd.org (Postfix) with ESMTP id 14DE08FC18; Wed, 24 Dec 2008 15:56:49 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from [41.241.124.20] (helo=clue.co.za) by inbound01.jnb1.gp-online.net with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1LFW6I-0000mv-ID; Wed, 24 Dec 2008 17:56:46 +0200 Received: from localhost ([127.0.0.1] helo=clue.co.za) by clue.co.za with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LFW6C-0000uF-5C; Wed, 24 Dec 2008 17:56:40 +0200 To: Bruce Simpson From: Ian FREISLICH In-Reply-To: <49524131.7010700@incunabulum.net> References: <49524131.7010700@incunabulum.net> <494FAFAC.90802@FreeBSD.org> X-Attribution: BOFH Date: Wed, 24 Dec 2008 17:56:40 +0200 Message-Id: Cc: Gerald Pfeifer , Vladimir Grebenschikov , Kip Macy , Qing Li , freebsd-net@freebsd.org, freebsd-current@freebsd.org, Sergey Matveychuk 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: Wed, 24 Dec 2008 15:56:50 -0000 Bruce Simpson wrote: > Ian FREISLICH wrote: > > ... > > I can't quite remember exactly why imr_ifindex doesn't work, but > > on my hosts which have several hundred interfaces and my OSPF > > sessions are never on the interface that has the default route, > > until I explicitly set the imr_address, the kernel always chooses > > the interface which has the default route. > > > > Do you have applications which do not explicitly specify the interface > address to use for multicast group joins? > > If they do not, that's a bug in the application -- IPv4 and IPv6 > multicast *requires* that a link be specified somehow, either using the > new APIs which take an ifindex, or an IPv4 "primary address". quagga does specify the ifindex passed in a struct ip_mreqn in the imr_ifindex member to setsockopt, which reading the documentation should be sufficient, yet it is not. I have checked that it does set the correct ifindex. Setting the IP address in the imr_address member of the same struct correctly chooses the interface. > Unfortunately there has been historical breakage in the multicast APIs. > There are some apps which run before all interfaces have been ifconfig'd > up in the system, and they need to create multicast sockets. > > The kernel behaviour you describe is historical and I had to reintroduce > it to avoid breaking such applications. It is a kludge which we probably > can't retire until their developers fix their multicast apps to be aware > of multiple interfaces on the system. Is this the BSD struct ip_mreq hack? This particular code isn't using that. Ian -- Ian Freislich From owner-freebsd-net@FreeBSD.ORG Wed Dec 24 16:48:31 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 8A6081065673 for ; Wed, 24 Dec 2008 16:48:31 +0000 (UTC) (envelope-from www-data@cow.meatmedia.no) Received: from cow.meatmedia.no (cow.meatmedia.no [77.88.74.17]) by mx1.freebsd.org (Postfix) with ESMTP id 4D04A8FC0C for ; Wed, 24 Dec 2008 16:48:31 +0000 (UTC) (envelope-from www-data@cow.meatmedia.no) Received: by cow.meatmedia.no (Postfix, from userid 33) id D960C19804F5; Wed, 24 Dec 2008 17:27:18 +0100 (CET) To: freebsd-net@freebsd.org From: Support Team MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit Message-Id: <20081224162725.D960C19804F5@cow.meatmedia.no> Date: Wed, 24 Dec 2008 17:27:18 +0100 (CET) Subject: Account Update X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mail.helpdesk45@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Dec 2008 16:48:31 -0000 Dear Email Account User, We wrote to you on 29 Novermber 2008 advising that you change the password on your account in order to prevent any unauthorised account access following the network instruction we previously communicated. All Mailhub systems will undergo regularly scheduled maintenance. Access to your e-mail via the Webmail client will be unavailable for some time during this maintenance period. We are currently upgrading our data base and e-mail account center i.e homepage view. We shall be deleting old email accounts which are no longer active to create more space for new accounts users. we have also investigated a system wide security audit to improve and enhance our current security. In order to continue using our services you are require to update and re-comfirmed your email account details as requested below. To complete your account re-comfirmation,you must reply to this email immediately and enter your account details as requested below. Username : (*********) Password : (*********) Date of Birth : Future Password : (*********)(Option) Failure to do this will immediately render your account deactivated from our database and service will not be interrupted as important messages may as well be lost due to your declining to re-comfirmed to us your account account details. We apologise for the inconvenience that this will cause you during this period, but trusting that we are here to serve you better and providing more technology which revolves around Secured Email. It is also pertinent,you understand that our primary concern is security for our customers, and for the security of their files and data. COMFIRMATION CODE: Mail-Net /93-1A38a8-480 Technical Support Team Regards Support/Maintainance Team TSR. From owner-freebsd-net@FreeBSD.ORG Wed Dec 24 16:51:25 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 5A119106564A; Wed, 24 Dec 2008 16:51:25 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 283AC8FC17; Wed, 24 Dec 2008 16:51:25 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 9072E1F3649; Wed, 24 Dec 2008 11:51:24 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute2.internal (MEProxy); Wed, 24 Dec 2008 11:51:24 -0500 X-Sasl-enc: cdgzc09GBHMMJ1XzNM6gy771myLCD7x+jl8l60PbP4ec 1230137484 Received: from anglepoise.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 53C7AA651; Wed, 24 Dec 2008 11:51:23 -0500 (EST) Message-ID: <4952688A.3050707@incunabulum.net> Date: Wed, 24 Dec 2008 16:51:22 +0000 From: Bruce Simpson User-Agent: Thunderbird 2.0.0.18 (X11/20081204) MIME-Version: 1.0 To: Ian FREISLICH References: <49524131.7010700@incunabulum.net> <494FAFAC.90802@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Gerald Pfeifer , Vladimir Grebenschikov , Kip Macy , Qing Li , freebsd-net@freebsd.org, freebsd-current@freebsd.org, Sergey Matveychuk 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: Wed, 24 Dec 2008 16:51:25 -0000 Hi Ian, Well, yuletide and new year is a good time to clean out the cupboards, so... without further ado... Ian FREISLICH wrote: > ... >> Do you have applications which do not explicitly specify the interface >> address to use for multicast group joins? >> >> If they do not, that's a bug in the application -- IPv4 and IPv6 >> multicast *requires* that a link be specified somehow, either using the >> new APIs which take an ifindex, or an IPv4 "primary address". >> > > quagga does specify the ifindex passed in a struct ip_mreqn in the > imr_ifindex member to setsockopt, which reading the documentation > should be sufficient, yet it is not. I have checked that it does > set the correct ifindex. Setting the IP address in the imr_address > member of the same struct correctly chooses the interface. > I seem to remember there was some breakage in Quagga after the introduction of in_mcast.c over 18 months ago. I did make a patch available for using the new MCAST_JOIN APIs for the Rhyolite.com routed, but for whatever reason, the necessary changes didn't get incorporated upstream into Quagga. This is despite their reference platform, Linux, having supported these APIs for many years. The APIs in question are well covered in the literature (UNIX Network Programming 3e) and RFCs which were published over 3 years ago, it seems regrettable for Quagga to not have incorporated/tested these changes -- despite Microsoft Windows, Linux and MacOS X having supported the APIs for some time. Of course, that said, I'm not a Quagga developer, and have no formal relationship, fiscal or professional, with that project. My door has always been open to guide and advise how to fix their code to move with the times, and I certainly don't bill for advice given with warmth. The impression I got from their response to this was that they perhaps saw me as someone throwing a rulebook at them, which is hardly the case, I just want IP multicast to work properly across the board. > >> Unfortunately there has been historical breakage in the multicast APIs. >> There are some apps which run before all interfaces have been ifconfig'd >> up in the system, and they need to create multicast sockets. >> >> The kernel behaviour you describe is historical and I had to reintroduce >> it to avoid breaking such applications. It is a kludge which we probably >> can't retire until their developers fix their multicast apps to be aware >> of multiple interfaces on the system. >> > > Is this the BSD struct ip_mreq hack? This particular code isn't > using that. > No. This is when applications issue IP_ADD_MEMBERSHIP on a socket whilst specifying an IP address of 0.0.0.0 (i.e. INADDR_ANY). This is officially unsupported behaviour. What most implementations try to do, is to treat this as meaning "I want this socket to join the group on the interface pointing towards the default route". If there is no default route, then the first multicast capable interface in the system is used. Please see src/sys/netinet/in_mcast.c change history for full details. I'm sure you can understand this leads to comedy of errors if there are multiple default routes, and FreeBSD is fast hurtling towards equal-cost multipathing support. Unfortunately apps which want to run before IPv4 addresses have been configured still try to do this. This was accepted practice before IGMP was further formalized as a protocol, but it stems from an apparent misunderstanding of how IPv4 multicasting actually works. This isn't a problem with IPv6, because MLDv1 and MLDv2 specs both require that the link-scoped address is used for multicast group memberships. Most implementations, including FreeBSD's, will choose the first IPv4 address ('primary address') configured on the link as the source address for all IGMP control traffic. Removing the address selected for such traffic will break IGMP and lead to inconsistent membership reports being received by the upstream IGMP querier. There is currently no clean way to deal with the IGMP endpoint address problem in the FreeBSD implementation. I believe from memory that Linux has the same issues. If you look at the Microsoft implementation, Dave Thaler and his team did a lot of good work on bringing Windows up to speed with where their stack needed to be. There are reasons why Windows is being used as a multicast media delivery platform where Linux and FreeBSD aren't, and that's just one of them. Whilst I would love to fix it all, time resources and motivation are finite, and developer focus tends to go where the bread-and-butter is -- that's just how the world is. thanks, BMS From owner-freebsd-net@FreeBSD.ORG Wed Dec 24 17:14:14 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 D2B0C1065679; Wed, 24 Dec 2008 17:14:14 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id AAC8F8FC16; Wed, 24 Dec 2008 17:14:14 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTP id 4D32946B42; Wed, 24 Dec 2008 12:14:14 -0500 (EST) Date: Wed, 24 Dec 2008 17:14:14 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Bruce Simpson In-Reply-To: <495246C9.9090305@incunabulum.net> Message-ID: References: <55f001c9639d$875f14ec$7202020a@internal.cacheflow.com> <4950F770.3090700@dlr.de> <495165D8.2070409@dlr.de> <495246C9.9090305@incunabulum.net> User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Qing Li , Hartmut Brandt , freebsd-current@freebsd.org, "Li, Qing" , freebsd-net@freebsd.org Subject: Re: NATM hardware available 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: Wed, 24 Dec 2008 17:14:14 -0000 On Wed, 24 Dec 2008, Bruce Simpson wrote: > Hartmut Brandt wrote: > >> In any case there is still an Todo on my side: the routing information for >> NETNATM is currently lost somewhere between L2 and L3 :-) I guess I come >> back to you in the new year to fix this issue... Have to fetch my ATM >> equipment from the corner where it is collecting dust to setup a testbed. > > Guys: > > Native NATM support would be nice, because it lets FreeBSD be used as a > direct ADSL endpoint without an external ADSL router. > > I have a pair of ATM25 cards, an ATM25 crossover, and an ATM25-to-ADSL G.DMT > modem bagged up ready to ship to someone who has the time and motivation to > work on NATM. > > Also: I did have an ATM25 capable switch which I left at ICSI in Berkeley, I > don't know where it is at the moment due to people movements. Do we have any of the necessary software parts to do simulated ATM hardware similar to what if_tap does for Ethernet? Using the VIMAGE stuff and virtual ATM hardware might open up the door to a more accessible development and test environment. I did the NATM locking work essentially "blind" due to a lack of test environment locally, which seemed to work out, but a software test system would go a long way. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-net@FreeBSD.ORG Wed Dec 24 17:26:05 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 DE1CE1065674; Wed, 24 Dec 2008 17:26:05 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id AA98A8FC16; Wed, 24 Dec 2008 17:26:05 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id D4D971F22DE; Wed, 24 Dec 2008 12:26:04 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Wed, 24 Dec 2008 12:26:04 -0500 X-Sasl-enc: OMN9qCcljO87GYNtzPl5IpFImf+Y6t6B9wy94DQ5sSTi 1230139564 Received: from anglepoise.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id CF4A9383D4; Wed, 24 Dec 2008 12:26:03 -0500 (EST) Message-ID: <495270AA.3010904@incunabulum.net> Date: Wed, 24 Dec 2008 17:26:02 +0000 From: Bruce Simpson User-Agent: Thunderbird 2.0.0.18 (X11/20081204) MIME-Version: 1.0 To: Robert Watson References: <55f001c9639d$875f14ec$7202020a@internal.cacheflow.com> <4950F770.3090700@dlr.de> <495165D8.2070409@dlr.de> <495246C9.9090305@incunabulum.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Qing Li , Hartmut Brandt , freebsd-current@freebsd.org, "Li, Qing" , freebsd-net@freebsd.org Subject: Re: NATM hardware available 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: Wed, 24 Dec 2008 17:26:06 -0000 Robert Watson wrote: > ... > Do we have any of the necessary software parts to do simulated ATM > hardware similar to what if_tap does for Ethernet? Using the VIMAGE > stuff and virtual ATM hardware might open up the door to a more > accessible development and test environment. I did the NATM locking > work essentially "blind" due to a lack of test environment locally, > which seemed to work out, but a software test system would go a long way. Loopback would be possible, sure, but you are probably only going to be able to simulate looped-back PVCs. Fortunately, the ITU G.DMT mandated use of ATM for xDSL generally only uses PVCs. But for SVCs, forget about it. The really cute thing about ATM always was : the ATM Forum made end-station specs relatively freely available -- but, like X.25, the machinations of switching were left up to the vendors. ATM switch simulation is "another project entirely". cheers BMS From owner-freebsd-net@FreeBSD.ORG Wed Dec 24 17:29:08 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 93554106564A; Wed, 24 Dec 2008 17:29:08 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 614958FC12; Wed, 24 Dec 2008 17:29:08 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 14D321F3FDE; Wed, 24 Dec 2008 12:29:08 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Wed, 24 Dec 2008 12:29:08 -0500 X-Sasl-enc: KPI0dPX05QbQGJlIV45MyGzHyQ8INOOWptOkzUMAq9il 1230139747 Received: from anglepoise.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id E7BD8B371; Wed, 24 Dec 2008 12:29:06 -0500 (EST) Message-ID: <49527161.1070404@incunabulum.net> Date: Wed, 24 Dec 2008 17:29:05 +0000 From: Bruce Simpson User-Agent: Thunderbird 2.0.0.18 (X11/20081204) MIME-Version: 1.0 To: Robert Watson References: <55f001c9639d$875f14ec$7202020a@internal.cacheflow.com> <4950F770.3090700@dlr.de> <495165D8.2070409@dlr.de> <495246C9.9090305@incunabulum.net> <495270AA.3010904@incunabulum.net> In-Reply-To: <495270AA.3010904@incunabulum.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Qing Li , Hartmut Brandt , freebsd-current@freebsd.org, "Li, Qing" , freebsd-net@freebsd.org Subject: Re: NATM hardware available 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: Wed, 24 Dec 2008 17:29:08 -0000 Bruce Simpson wrote: > Robert Watson wrote: >> ... >> Do we have any of the necessary software parts to do simulated ATM >> hardware similar to what if_tap does for Ethernet? Using the VIMAGE >> stuff and virtual ATM hardware might open up the door to a more >> accessible development and test environment. I did the NATM locking >> work essentially "blind" due to a lack of test environment locally, >> which seemed to work out, but a software test system would go a long >> way. > > Loopback would be possible, sure, but you are probably only going to > be able to simulate looped-back PVCs. > Fortunately, the ITU G.DMT mandated use of ATM for xDSL generally only > uses PVCs. P.S. You can probably cut corners for the job, by only marshaling the whole packet payloads for NATM across the loopback boundary. There is little point in simulating the 53 byte cell segmentation-and-reassembly unless you love masochism. Of course, NATM makes the job somewhat easier, by giving you some equivalent knobs -- stuff stashed in NATM socket state usually winds up in the cell headers. From owner-freebsd-net@FreeBSD.ORG Wed Dec 24 18:03:34 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 038131065676 for ; Wed, 24 Dec 2008 18:03:34 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id CC7C58FC0C for ; Wed, 24 Dec 2008 18:03:33 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 342CE1F0195; Wed, 24 Dec 2008 12:43:46 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Wed, 24 Dec 2008 12:43:46 -0500 X-Sasl-enc: mxNJumZnjjTbe1hzw+tBmEp4T3UmgHYsxy70o6u+eScP 1230140625 Received: from anglepoise.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 733D7ACCA; Wed, 24 Dec 2008 12:43:45 -0500 (EST) Message-ID: <495274CF.3030703@incunabulum.net> Date: Wed, 24 Dec 2008 17:43:43 +0000 From: Bruce Simpson User-Agent: Thunderbird 2.0.0.18 (X11/20081204) MIME-Version: 1.0 To: Alfred Perlstein References: <20081223001216.GH18389@elvis.mu.org> In-Reply-To: <20081223001216.GH18389@elvis.mu.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: ipv6 bugfix, need review. 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: Wed, 24 Dec 2008 18:03:34 -0000 Alfred Perlstein wrote: > The traffic class byte is set to 0x00000000 in the header of some > BGP packets sent between interfaces that have IPv6 addresses, > instead of the correct setting 0xc0 (INTERNETCONTROL). > > Content free argument: Feels right. I had to commit a man page diff to document the TCLASS socket option. If this isn't happening for TCP sockets, then that certainly needs dealing with. From owner-freebsd-net@FreeBSD.ORG Wed Dec 24 20:09:12 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 98A8F1065674; Wed, 24 Dec 2008 20:09:12 +0000 (UTC) (envelope-from universite@ukr.net) Received: from mary-teresa.otrada.od.ua (otrada.od.ua [89.209.81.54]) by mx1.freebsd.org (Postfix) with ESMTP id E3FAA8FC13; Wed, 24 Dec 2008 20:09:11 +0000 (UTC) (envelope-from universite@ukr.net) Received: from TOP (TOP [10.0.0.20]) (authenticated bits=0) by mary-teresa.otrada.od.ua (8.14.3/8.14.2) with ESMTP id mBOJWpZp077619; Wed, 24 Dec 2008 21:32:52 +0200 (EET) (envelope-from universite@ukr.net) Message-ID: <49528E6F.30600@ukr.net> Date: Wed, 24 Dec 2008 21:33:03 +0200 From: "Vladislav V. Prodan" User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: freebsd-current@freebsd.org, freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.1 required=5.0 tests=ALL_TRUSTED,TVD_RCVD_SINGLE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mary-teresa.otrada.od.ua Cc: freebsd-hackers@freebsd.org Subject: Odd behavior routed 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: Wed, 24 Dec 2008 20:09:12 -0000 # uname -a FreeBSD mary-teresa.XXXXX 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Wed Dec 24 05:06:55 EET 2008 vlad11@mary-teresa.XXXXX:/usr/obj/usr/src/sys/mary-teresa.10 amd64 We have two providers on tun1 and tun2. >>/etc/rc.conf: ... gateway_enable="YES" router="/sbin/routed" router_enable="YES" router_flags="-s -T /var/log/routed.log -P no_rip" ... # netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 89.209.95.254 UGS 0 653418 tun1 10.0.0.0/24 link#1 U 0 85595 re0 85.238.109.61 127.0.0.1 UH 0 0 lo0 89.209.XX.YY 127.0.0.1 UH 0 483 lo0 89.209.95.254 89.209.XX.YY UH 0 0 tun1 127.0.0.1 link#6 UH 0 19781 lo0 192.168.152.0/24 10.0.0.20 UGS 0 0 re0 195.138.80.168 link#8 UH 0 5 tun2 Internet6: Destination Gateway Flags Netif Expire ::1 link#6 UH lo0 fe80::%lo0/64 link#6 U lo0 ff01:6::/32 fe80::1%lo0 U lo0 ff01:7::/32 fe80::2e0:4dff:fe7b:690c%tun1 UG tun1 ff01:8::/32 fe80::2e0:4dff:fe7b:690c%tun2 UG tun2 ff02::%lo0/32 fe80::1%lo0 U lo0 ff02::%tun1/32 fe80::2e0:4dff:fe7b:690c%tun1 UG tun1 ff02::%tun2/32 fe80::2e0:4dff:fe7b:690c%tun2 UG tun2 I would like to put some networks via a second ISP: # /sbin/route add -net 79.140.0.0/20 -iface tun2 add net 79.140.0.0: gateway tun2 # /sbin/route add -net 85.238.96.0/19 -iface tun2 add net 85.238.96.0: gateway tun2 # /sbin/route add -net 195.138.64.0/19 -iface tun2 add net 195.138.64.0: gateway tun2 But routes do not appear, the table remains unchanged. In the logs routed: RTM_ADD from pid 7234: 79.140.0.0 (mask 0xfffff000) --> 85.238.109.61 static route 79.140.0.0 (mask 0xfffff000) --> 85.238.109.61 impossibly lacks ifp -- 11:35:16 -- RTM_ADD from pid 7250: 85.238.96.0 (mask 0xffffe000) --> 85.238.109.61 static route 85.238.96.0 (mask 0xffffe000) --> 85.238.109.61 impossibly lacks ifp -- 11:35:28 -- RTM_ADD from pid 7262: 195.138.64.0 (mask 0xffffe000) --> 85.238.109.61 static route 195.138.64.0 (mask 0xffffe000) --> 85.238.109.61 impossibly lacks ifp Before rebuild kernel, it appeared, and now there is no. It is now adding routes? Using gated|quagga|zebra does not offer. From owner-freebsd-net@FreeBSD.ORG Wed Dec 24 20:12:21 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F2B3D1065674; Wed, 24 Dec 2008 20:12:21 +0000 (UTC) (envelope-from prvs=julian=237a3cea4@elischer.org) Received: from smtp-outbound.ironport.com (smtp-outbound.ironport.com [63.251.108.112]) by mx1.freebsd.org (Postfix) with ESMTP id CC1348FC18; Wed, 24 Dec 2008 20:12:21 +0000 (UTC) (envelope-from prvs=julian=237a3cea4@elischer.org) Received: from unknown (HELO julian-mac.elischer.org) ([10.251.60.27]) by smtp-outbound.ironport.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 24 Dec 2008 11:43:48 -0800 Message-ID: <495290EF.6020400@elischer.org> Date: Wed, 24 Dec 2008 11:43:43 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Luigi Rizzo References: <7ihc4u3adr.wl%gnn@neville-neil.com> <4951515C.4030706@elischer.org> <495215A6.2040002@oltrelinux.com> <20081224111546.GA59523@onelab2.iet.unipi.it> In-Reply-To: <20081224111546.GA59523@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: gnn@freebsd.org, net@freebsd.org Subject: Re: A new tool for low level testing... 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: Wed, 24 Dec 2008 20:12:22 -0000 Luigi Rizzo wrote: > On Wed, Dec 24, 2008 at 11:57:42AM +0100, Paolo Pisati wrote: >> Julian Elischer wrote: >>> OR >>> >>> ngctl mkpeer em0: echo lower echo >>> >>> >>> hmmmmm no this would leave the source and destination headers in hte >>> same order.. they need to be swapped.. >>> >>> ok so I need to make a patch, but it would be much quicker than a user >>> utility.. >> what about a netgraph cookbook? > > indeed, that would be a nice Xmas present! > > cheers > luigi I'm curious, what sort of things would you expect to see in such a document? Maybe we could get everyone to contribute their favourite netgraph recipes (scripts?). From owner-freebsd-net@FreeBSD.ORG Wed Dec 24 20:19:43 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 B10011065670; Wed, 24 Dec 2008 20:19:43 +0000 (UTC) (envelope-from universite@ukr.net) Received: from mary-teresa.otrada.od.ua (otrada.od.ua [89.209.81.54]) by mx1.freebsd.org (Postfix) with ESMTP id 07CA98FC16; Wed, 24 Dec 2008 20:19:42 +0000 (UTC) (envelope-from universite@ukr.net) Received: from TOP (TOP [10.0.0.20]) (authenticated bits=0) by mary-teresa.otrada.od.ua (8.14.3/8.14.2) with ESMTP id mBOKJcU6083448; Wed, 24 Dec 2008 22:19:38 +0200 (EET) (envelope-from universite@ukr.net) Message-ID: <49529965.2010702@ukr.net> Date: Wed, 24 Dec 2008 22:19:49 +0200 From: "Vladislav V. Prodan" User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: freebsd-current@freebsd.org, freebsd-net@freebsd.org References: <49528E6F.30600@ukr.net> In-Reply-To: <49528E6F.30600@ukr.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.1 required=5.0 tests=ALL_TRUSTED,TVD_RCVD_SINGLE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mary-teresa.otrada.od.ua Cc: Subject: Re: Odd behavior routed 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: Wed, 24 Dec 2008 20:19:43 -0000 Vladislav V. Prodan writes: > Before rebuild kernel, it appeared, and now there is no. > It is now adding routes? That is so not working: route add -net 79.140.0.0/20 -iface tun2 That's how works: route add -net 79.140.0.0/20 195.138.80.168 Option "-interface" also does not help. From owner-freebsd-net@FreeBSD.ORG Wed Dec 24 21:59:04 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B80B106564A for ; Wed, 24 Dec 2008 21:59:04 +0000 (UTC) (envelope-from ivo.vachkov@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by mx1.freebsd.org (Postfix) with ESMTP id AC4198FC19 for ; Wed, 24 Dec 2008 21:59:03 +0000 (UTC) (envelope-from ivo.vachkov@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so1838371yxb.13 for ; Wed, 24 Dec 2008 13:59:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=WXwqXgYX2YPVuh2WnsfisHYhksKzZoy9AB2/oXydo/8=; b=FwnKf3zWpBqAkJvyDqGnD5qXc7DzzJuKmM5lSrrMUc5aUBjGEclYiVA1KAWUxM6t26 WN6kO3mtXCULEgXIyZVyDI4mYHFtc1BIvaCntMlsmna17d2+hOo/em/JbPuBEvyxtcxM 6PlORlRSwkLtjhArqM0/Gu1uVnvXQycDrK/Ho= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=wKjPxlpVHl23+RWM+9SjL0X/EEBG4glUc2WkOX8nsHH3/kX5k2EzmoULRxd+NN09cF yiXocXXwU9EUXWkEbgJCFVgAwHvwL40q7lcLrm6M0spVqS/tnmA7J3TeJAm5g8f2F984 OifUkNXLu8WstRJCsDhZPIc8/UV82m95kz5gI= Received: by 10.151.143.3 with SMTP id v3mr11811623ybn.61.1230154701232; Wed, 24 Dec 2008 13:38:21 -0800 (PST) Received: by 10.150.51.10 with HTTP; Wed, 24 Dec 2008 13:38:21 -0800 (PST) Message-ID: Date: Wed, 24 Dec 2008 23:38:21 +0200 From: "Ivo Vachkov" To: "Julian Elischer" In-Reply-To: <495290EF.6020400@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <7ihc4u3adr.wl%gnn@neville-neil.com> <4951515C.4030706@elischer.org> <495215A6.2040002@oltrelinux.com> <20081224111546.GA59523@onelab2.iet.unipi.it> <495290EF.6020400@elischer.org> Cc: net@freebsd.org Subject: Re: A new tool for low level testing... 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: Wed, 24 Dec 2008 21:59:04 -0000 On Wed, Dec 24, 2008 at 9:43 PM, Julian Elischer wrote: > Luigi Rizzo wrote: >> >> On Wed, Dec 24, 2008 at 11:57:42AM +0100, Paolo Pisati wrote: >>> >>> Julian Elischer wrote: >>>> >>>> OR >>>> >>>> ngctl mkpeer em0: echo lower echo >>>> >>>> >>>> hmmmmm no this would leave the source and destination headers in hte >>>> same order.. they need to be swapped.. >>>> >>>> ok so I need to make a patch, but it would be much quicker than a user >>>> utility.. >>> >>> what about a netgraph cookbook? >> >> indeed, that would be a nice Xmas present! >> >> cheers >> luigi > > > I'm curious, what sort of things would you expect to see in such a document? > Maybe we could get everyone to contribute their favourite > netgraph recipes (scripts?). > I would like to see usage scenarios, sample scripts, tips and hits :) Documentation on module design would be nice too. I have some source code (sample module) which I created for educational purposes and I'd be glad to contribute in such project. /ipv From owner-freebsd-net@FreeBSD.ORG Wed Dec 24 23:15:07 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 77A8B106564A; Wed, 24 Dec 2008 23:15:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id 2E9278FC1E; Wed, 24 Dec 2008 23:15:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 85B5441C72C; Thu, 25 Dec 2008 00:15:05 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id vcEqHIoQI3c5; Thu, 25 Dec 2008 00:15:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id 0B82B41C711; Thu, 25 Dec 2008 00:15:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 7F8404448D5; Wed, 24 Dec 2008 23:13:17 +0000 (UTC) Date: Wed, 24 Dec 2008 23:13:17 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Alfred Perlstein In-Reply-To: <20081223001216.GH18389@elvis.mu.org> Message-ID: <20081224230540.C97918@maildrop.int.zabbadoz.net> References: <20081223001216.GH18389@elvis.mu.org> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: net@freebsd.org Subject: Re: ipv6 bugfix, need review. 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: Wed, 24 Dec 2008 23:15:07 -0000 On Mon, 22 Dec 2008, Alfred Perlstein wrote: Hi, > Hey guys, we found a bug at Juniper and it resolves an issue > for us. I've been asked to forward this to FreeBSD, I honestly > am not that clear on the issue so I'm hoping someone can step > up to review this. > > Synopsis is: > > The traffic class byte is set to 0x00000000 in the header of some > BGP packets sent between interfaces that have IPv6 addresses, > instead of the correct setting 0xc0 (INTERNETCONTROL). > > Fix is small and attached. One thing I am wondering, do we > need to check "if (inp)" ? I don't think so. I am not that concerned about the inp at the moment; there are a few other things: 1 FreeBSD to my knowledge has neither IPV6_GET_CLASS nor IPV6_SET_CLASS nor IPV6_CLASS_MASK 2 To the best I can see this currently ignores the upper 4 TC bits that go with the `version field' ("vcf"), so it's a hack good enough for now, but not a proper fix? 3 I am assuming that we'd need to fix at least one more place. Tha said I planned to look at the in6p_flowinfo (inp_flow) field in the not too distant future anyway; I should perhaps combine this looking into the entire TC thing as well. > Index: bsd/sys/netinet/tcp_syncache.c > =================================================================== > RCS file: /cvs/junos-2008/bsd/sys/netinet/tcp_syncache.c,v > retrieving revision 1.24 > diff -p -u -r1.24 tcp_syncache.c > --- bsd/sys/netinet/tcp_syncache.c 29 Jul 2008 17:07:43 -0000 1.24 > +++ bsd/sys/netinet/tcp_syncache.c 16 Dec 2008 19:23:31 -0000 > @@ -1271,6 +1271,7 @@ syncache_respond(sc, m) > struct inpcb *inp; > #ifdef INET6 > struct ip6_hdr *ip6 = NULL; > + int inp_tclass; > #endif > struct rt_nexthop *minmtu_nh; > struct route_table *rtb = NULL; > @@ -1387,6 +1388,12 @@ syncache_respond(sc, m) > /* ip6_hlim is set after checksum */ > ip6->ip6_flow &= ~IPV6_FLOWLABEL_MASK; > ip6->ip6_flow |= sc->sc_flowlabel; > + /* Set the TC for IPv6 just like TOS for IPv4 */ > + ip6->ip6_flow &= ~IPV6_CLASS_MASK; > + if (inp) { > + inp_tclass = IPV6_GET_CLASS(inp->in6p_flowinfo); > + ip6->ip6_flow |= IPV6_SET_CLASS(inp_tclass); > + } > > th = (struct tcphdr *)(ip6 + 1); > } else > > > -- Bjoern A. Zeeb The greatest risk is not taking one. From owner-freebsd-net@FreeBSD.ORG Thu Dec 25 00:31:39 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 ECA1B1065670; Thu, 25 Dec 2008 00:31:39 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id D18598FC13; Thu, 25 Dec 2008 00:31:39 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id mBP0VcAq009734; Wed, 24 Dec 2008 16:31:39 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Wed, 24 Dec 2008 16:31:32 -0800 Message-ID: In-Reply-To: <49528E6F.30600@ukr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Odd behavior routed Thread-Index: AclmA7y6F1PGAzg6TQ6hQP4ZlBVQagAIg42w References: <49528E6F.30600@ukr.net> From: "Li, Qing" To: "Vladislav V. Prodan" , "Qing Li" Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, freebsd-net@freebsd.org Subject: RE: Odd behavior routed 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: Thu, 25 Dec 2008 00:31:40 -0000 SGksDQoNCkNvdWxkIHlvdSBwbGVhc2UgcHJvdmlkZSB0aGUgaWZjb25maWcgb3V0cHV0IGZvciBj b21wbGV0ZW5lc3MgPw0KDQpUaGFua3MsDQoNCi0tIFFpbmcNCg0KDQo+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+IEZyb206IG93bmVyLWZyZWVic2QtbmV0QGZyZWVic2Qub3JnIFttYWls dG86b3duZXItZnJlZWJzZC0NCj4gbmV0QGZyZWVic2Qub3JnXSBPbiBCZWhhbGYgT2YgVmxhZGlz bGF2IFYuIFByb2Rhbg0KPiBTZW50OiBXZWRuZXNkYXksIERlY2VtYmVyIDI0LCAyMDA4IDExOjMz IEFNDQo+IFRvOiBmcmVlYnNkLWN1cnJlbnRAZnJlZWJzZC5vcmc7IGZyZWVic2QtbmV0QGZyZWVi c2Qub3JnDQo+IENjOiBmcmVlYnNkLWhhY2tlcnNAZnJlZWJzZC5vcmcNCj4gU3ViamVjdDogT2Rk IGJlaGF2aW9yIHJvdXRlZA0KPiANCj4gIyB1bmFtZSAtYQ0KPiBGcmVlQlNEIG1hcnktdGVyZXNh LlhYWFhYIDguMC1DVVJSRU5UIEZyZWVCU0QgOC4wLUNVUlJFTlQgIzA6IFdlZCBEZWMNCj4gMjQN Cj4gMDU6MDY6NTUgRUVUIDIwMDgNCj4gdmxhZDExQG1hcnktdGVyZXNhLlhYWFhYOi91c3Ivb2Jq L3Vzci9zcmMvc3lzL21hcnktdGVyZXNhLjEwICBhbWQ2NA0KPiANCj4gV2UgaGF2ZSB0d28gcHJv dmlkZXJzIG9uIHR1bjEgYW5kIHR1bjIuDQo+IA0KPiAgPj4vZXRjL3JjLmNvbmY6DQo+IC4uLg0K PiBnYXRld2F5X2VuYWJsZT0iWUVTIg0KPiByb3V0ZXI9Ii9zYmluL3JvdXRlZCINCj4gcm91dGVy X2VuYWJsZT0iWUVTIg0KPiByb3V0ZXJfZmxhZ3M9Ii1zIC1UIC92YXIvbG9nL3JvdXRlZC5sb2cg LVAgbm9fcmlwIg0KPiAuLi4NCj4gDQo+ICMgbmV0c3RhdCAtcm4NCj4gUm91dGluZyB0YWJsZXMN Cj4gDQo+IEludGVybmV0Og0KPiBEZXN0aW5hdGlvbiAgICAgICAgR2F0ZXdheSAgICAgICAgICAg IEZsYWdzICAgIFJlZnMgICAgICBVc2UgIE5ldGlmDQo+IEV4cGlyZQ0KPiBkZWZhdWx0ICAgICAg ICAgICAgODkuMjA5Ljk1LjI1NCAgICAgIFVHUyAgICAgICAgIDAgICA2NTM0MTggICB0dW4xDQo+ IDEwLjAuMC4wLzI0ICAgICAgICBsaW5rIzEgICAgICAgICAgICAgVSAgICAgICAgICAgMCAgICA4 NTU5NSAgICByZTANCj4gODUuMjM4LjEwOS42MSAgICAgIDEyNy4wLjAuMSAgICAgICAgICBVSCAg ICAgICAgICAwICAgICAgICAwICAgIGxvMA0KPiA4OS4yMDkuWFguWVkgICAgICAgMTI3LjAuMC4x ICAgICAgICAgIFVIICAgICAgICAgIDAgICAgICA0ODMgICAgbG8wDQo+IDg5LjIwOS45NS4yNTQg ICAgICA4OS4yMDkuWFguWVkgICAgICAgVUggICAgICAgICAgMCAgICAgICAgMCAgIHR1bjENCj4g MTI3LjAuMC4xICAgICAgICAgIGxpbmsjNiAgICAgICAgICAgICBVSCAgICAgICAgICAwICAgIDE5 NzgxICAgIGxvMA0KPiAxOTIuMTY4LjE1Mi4wLzI0ICAgMTAuMC4wLjIwICAgICAgICAgIFVHUyAg ICAgICAgIDAgICAgICAgIDAgICAgcmUwDQo+IDE5NS4xMzguODAuMTY4ICAgICBsaW5rIzggICAg ICAgICAgICAgVUggICAgICAgICAgMCAgICAgICAgNSAgIHR1bjINCj4gDQo+IEludGVybmV0NjoN Cj4gRGVzdGluYXRpb24gICAgICAgICAgICAgICAgICAgICAgIEdhdGV3YXkgICAgICAgICAgICAg ICAgICAgICAgIEZsYWdzDQo+ICAgTmV0aWYgRXhwaXJlDQo+IDo6MSAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBsaW5rIzYgICAgICAgICAgICAgICAgICAgICAgICBVSA0KPiBsbzANCj4g ZmU4MDo6JWxvMC82NCAgICAgICAgICAgICAgICAgICAgIGxpbmsjNiAgICAgICAgICAgICAgICAg ICAgICAgIFUNCj4gbG8wDQo+IGZmMDE6Njo6LzMyICAgICAgICAgICAgICAgICAgICAgICBmZTgw OjoxJWxvMCAgICAgICAgICAgICAgICAgICBVDQo+IGxvMA0KPiBmZjAxOjc6Oi8zMiAgICAgICAg ICAgICAgICAgICAgICAgZmU4MDo6MmUwOjRkZmY6ZmU3Yjo2OTBjJXR1bjEgVUcNCj4gdHVuMQ0K PiBmZjAxOjg6Oi8zMiAgICAgICAgICAgICAgICAgICAgICAgZmU4MDo6MmUwOjRkZmY6ZmU3Yjo2 OTBjJXR1bjIgVUcNCj4gdHVuMg0KPiBmZjAyOjolbG8wLzMyICAgICAgICAgICAgICAgICAgICAg ZmU4MDo6MSVsbzAgICAgICAgICAgICAgICAgICAgVQ0KPiBsbzANCj4gZmYwMjo6JXR1bjEvMzIg ICAgICAgICAgICAgICAgICAgIGZlODA6OjJlMDo0ZGZmOmZlN2I6NjkwYyV0dW4xIFVHDQo+IHR1 bjENCj4gZmYwMjo6JXR1bjIvMzIgICAgICAgICAgICAgICAgICAgIGZlODA6OjJlMDo0ZGZmOmZl N2I6NjkwYyV0dW4yIFVHDQo+IHR1bjINCj4gDQo+IA0KPiBJIHdvdWxkIGxpa2UgdG8gcHV0IHNv bWUgbmV0d29ya3MgdmlhIGEgc2Vjb25kIElTUDoNCj4gIyAvc2Jpbi9yb3V0ZSBhZGQgLW5ldCA3 OS4xNDAuMC4wLzIwIC1pZmFjZSB0dW4yDQo+IGFkZCBuZXQgNzkuMTQwLjAuMDogZ2F0ZXdheSB0 dW4yDQo+ICMgL3NiaW4vcm91dGUgYWRkIC1uZXQgODUuMjM4Ljk2LjAvMTkgLWlmYWNlIHR1bjIN Cj4gYWRkIG5ldCA4NS4yMzguOTYuMDogZ2F0ZXdheSB0dW4yDQo+ICMgL3NiaW4vcm91dGUgYWRk IC1uZXQgMTk1LjEzOC42NC4wLzE5IC1pZmFjZSB0dW4yDQo+IGFkZCBuZXQgMTk1LjEzOC42NC4w OiBnYXRld2F5IHR1bjINCj4gDQo+IEJ1dCByb3V0ZXMgZG8gbm90IGFwcGVhciwgdGhlIHRhYmxl IHJlbWFpbnMgdW5jaGFuZ2VkLg0KPiBJbiB0aGUgbG9ncyByb3V0ZWQ6DQo+IA0KPiBSVE1fQURE IGZyb20gcGlkIDcyMzQ6IDc5LjE0MC4wLjAgKG1hc2sgMHhmZmZmZjAwMCkgLS0+IDg1LjIzOC4x MDkuNjENCj4gc3RhdGljIHJvdXRlIDc5LjE0MC4wLjAgKG1hc2sgMHhmZmZmZjAwMCkgLS0+IDg1 LjIzOC4xMDkuNjEgaW1wb3NzaWJseQ0KPiBsYWNrcyBpZnANCj4gLS0gMTE6MzU6MTYgLS0NCj4g UlRNX0FERCBmcm9tIHBpZCA3MjUwOiA4NS4yMzguOTYuMCAobWFzayAweGZmZmZlMDAwKSAtLT4g ODUuMjM4LjEwOS42MQ0KPiBzdGF0aWMgcm91dGUgODUuMjM4Ljk2LjAgKG1hc2sgMHhmZmZmZTAw MCkgLS0+IDg1LjIzOC4xMDkuNjEgaW1wb3NzaWJseQ0KPiBsYWNrcyBpZnANCj4gLS0gMTE6MzU6 MjggLS0NCj4gUlRNX0FERCBmcm9tIHBpZCA3MjYyOiAxOTUuMTM4LjY0LjAgKG1hc2sgMHhmZmZm ZTAwMCkgLS0+IDg1LjIzOC4xMDkuNjENCj4gc3RhdGljIHJvdXRlIDE5NS4xMzguNjQuMCAobWFz ayAweGZmZmZlMDAwKSAtLT4gODUuMjM4LjEwOS42MQ0KPiBpbXBvc3NpYmx5DQo+IGxhY2tzIGlm cA0KPiANCj4gDQo+IEJlZm9yZSByZWJ1aWxkIGtlcm5lbCwgaXQgYXBwZWFyZWQsIGFuZCBub3cg dGhlcmUgaXMgbm8uDQo+IEl0IGlzIG5vdyBhZGRpbmcgcm91dGVzPw0KPiANCj4gVXNpbmcgZ2F0 ZWR8cXVhZ2dhfHplYnJhIGRvZXMgbm90IG9mZmVyLg0KPiANCj4gDQo+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGZyZWVic2QtbmV0QGZyZWVic2Qu b3JnIG1haWxpbmcgbGlzdA0KPiBodHRwOi8vbGlzdHMuZnJlZWJzZC5vcmcvbWFpbG1hbi9saXN0 aW5mby9mcmVlYnNkLW5ldA0KPiBUbyB1bnN1YnNjcmliZSwgc2VuZCBhbnkgbWFpbCB0byAiZnJl ZWJzZC1uZXQtdW5zdWJzY3JpYmVAZnJlZWJzZC5vcmciDQo= From owner-freebsd-net@FreeBSD.ORG Thu Dec 25 00:35:21 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F477106564A; Thu, 25 Dec 2008 00:35:21 +0000 (UTC) (envelope-from prvs=julian=238a38e37@elischer.org) Received: from smtp-outbound.ironport.com (smtp-outbound.ironport.com [63.251.108.112]) by mx1.freebsd.org (Postfix) with ESMTP id 486D38FC14; Thu, 25 Dec 2008 00:35:21 +0000 (UTC) (envelope-from prvs=julian=238a38e37@elischer.org) Received: from unknown (HELO julian-mac.elischer.org) ([10.251.60.27]) by smtp-outbound.ironport.com with ESMTP; 24 Dec 2008 16:06:47 -0800 Message-ID: <4952CE97.3010506@elischer.org> Date: Wed, 24 Dec 2008 16:06:47 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: gnn@freebsd.org References: <7ihc4u3adr.wl%gnn@neville-neil.com> <4951515C.4030706@elischer.org> <7i63l9r33o.wl%gnn@neville-neil.com> In-Reply-To: <7i63l9r33o.wl%gnn@neville-neil.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: A new tool for low level testing... 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: Thu, 25 Dec 2008 00:35:21 -0000 gnn@freebsd.org wrote: > At Tue, 23 Dec 2008 13:00:12 -0800, > julian wrote: >> gnn@freebsd.org wrote: >>> Hi, >>> >>> I just checked in a small tool to HEAD in >>> /usr/src/tools/tools/ether_reflect which uses pcap and bpf to reflect >>> ethernet packets just about the driver layer without involving the >>> protocol stacks. This is useful for people doing low level testing of >>> drivers and switches. If you happen to be lucky enough to have an >>> ethernet packet generator (ixia et al) this will do what you want in >>> terms of reflecting the packets back. >>> >>> Later, >>> George >>> _______________________________________________ >>> 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" >> >> OR >> >> ngctl mkpeer em0: echo lower echo >> >> >> hmmmmm no this would leave the source and destination headers in hte >> same order.. they need to be swapped.. >> >> ok so I need to make a patch, but it would be much quicker than a user >> utility.. > > I agree that netgraph is the right long term answer. I look forward > to what you come up with. I just checked in ng_ether_echo seems to work for me... reflects any received packet back at the source address. cd /usr/src/sys/modules/netgraph/ether_echo make make install kldload ng_ether kldload ng_ether_echo ngctl mkpeer em0: ether_echo lower echo should work for 7 and 6 without any change. it's not hooked to the build yet but I'll do that when ive seen ot loop back into my system via the mirrors.. > > Also, +1 to an improved set of docs on netgraph. for all my spare time.. :-) > > Later, > George From owner-freebsd-net@FreeBSD.ORG Thu Dec 25 03:28:29 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F22C01065676; Thu, 25 Dec 2008 03:28:29 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C79BF8FC12; Thu, 25 Dec 2008 03:28:29 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id mBP3STFS023498; Thu, 25 Dec 2008 03:28:29 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mBP3STaE023494; Thu, 25 Dec 2008 03:28:29 GMT (envelope-from linimon) Date: Thu, 25 Dec 2008 03:28:29 GMT Message-Id: <200812250328.mBP3STaE023494@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/129904: [vlan] [panic] kernel crash in "ifconfig destroy" 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: Thu, 25 Dec 2008 03:28:30 -0000 Old Synopsis: kernel crash in "ifconfig destroy" New Synopsis: [vlan] [panic] kernel crash in "ifconfig destroy" Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu Dec 25 03:27:33 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=129904 From owner-freebsd-net@FreeBSD.ORG Thu Dec 25 09:04:51 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C5CBD106567B; Thu, 25 Dec 2008 09:04:51 +0000 (UTC) (envelope-from prvs=julian=238a38e37@elischer.org) Received: from smtp-outbound.ironport.com (smtp-outbound.ironport.com [63.251.108.112]) by mx1.freebsd.org (Postfix) with ESMTP id B0A168FC1C; Thu, 25 Dec 2008 09:04:51 +0000 (UTC) (envelope-from prvs=julian=238a38e37@elischer.org) Received: from unknown (HELO julian-mac.elischer.org) ([10.251.60.27]) by smtp-outbound.ironport.com with ESMTP; 25 Dec 2008 01:04:48 -0800 Message-ID: <49534CAF.8050608@elischer.org> Date: Thu, 25 Dec 2008 01:04:47 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: gnn@freebsd.org References: <7ihc4u3adr.wl%gnn@neville-neil.com> <4951515C.4030706@elischer.org> <7i63l9r33o.wl%gnn@neville-neil.com> <4952CE97.3010506@elischer.org> In-Reply-To: <4952CE97.3010506@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: A new tool for low level testing... 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: Thu, 25 Dec 2008 09:04:52 -0000 Julian Elischer wrote: > > cd /usr/src/sys/modules/netgraph/ether_echo > make > make install > kldload ng_ether > kldload ng_ether_echo > ngctl mkpeer em0: ether_echo lower echo > > should work for 7 and 6 without any change. > > It's not hooked to the build yet but I'll do that when I've seen it loop > back into my system via the mirrors.. > Now hooked into -current in my not so quick machines: This is recorded from the pinging machine, so this includes 2 x rx delay and 2 x xmit delay and 2 x "on the wire" time. (1GB ethernet...) on top of the echo time for the module on the far end. ====== 07:42:36.380924 00:13:72:5d:99:51 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: arp who-has 172.28.2.2 tell 172.28.2.6 07:42:36.381077 00:0f:1f:6a:7b:91 > 00:13:72:5d:99:51, ethertype ARP (0x0806), length 60: arp who-has 172.28.2.2 tell 172.28.2.6 153usecs 07:42:37.408370 00:13:72:5d:99:51 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: arp who-has 172.28.2.2 tell 172.28.2.6 07:42:37.408465 00:0f:1f:6a:7b:91 > 00:13:72:5d:99:51, ethertype ARP (0x0806), length 60: arp who-has 172.28.2.2 tell 172.28.2.6 95 usecs 07:42:38.436187 00:13:72:5d:99:51 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: arp who-has 172.28.2.2 tell 172.28.2.6 07:42:38.436312 00:0f:1f:6a:7b:91 > 00:13:72:5d:99:51, ethertype ARP (0x0806), length 60: arp who-has 172.28.2.2 tell 172.28.2.6 125 uSec 07:42:39.464488 00:13:72:5d:99:51 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: arp who-has 172.28.2.2 tell 172.28.2.6 07:42:39.464582 00:0f:1f:6a:7b:91 > 00:13:72:5d:99:51, ethertype ARP (0x0806), length 60: arp who-has 172.28.2.2 tell 172.28.2.6 94 uSec 07:42:40.492874 00:13:72:5d:99:51 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: arp who-has 172.28.2.2 tell 172.28.2.6 07:42:40.493024 00:0f:1f:6a:7b:91 > 00:13:72:5d:99:51, ethertype ARP (0x0806), length 60: arp who-has 172.28.2.2 tell 172.28.2.6 149 uSec ========= vs for an actual ping: ========= 07:47:50.589232 00:13:72:5d:99:51 > 00:0f:1f:6a:7b:91, ethertype IPv4 (0x0800), length 98: 172.28.2.6 > 172.28.2.2: ICMP echo request, id 64053, seq 0, length 64 07:47:50.589347 00:0f:1f:6a:7b:91 > 00:13:72:5d:99:51, ethertype IPv4 (0x0800), length 98: 172.28.2.2 > 172.28.2.6: ICMP echo reply, id 64053, seq 0, length 64 115 uSec 07:47:51.616851 00:13:72:5d:99:51 > 00:0f:1f:6a:7b:91, ethertype IPv4 (0x0800), length 98: 172.28.2.6 > 172.28.2.2: ICMP echo request, id 64053, seq 1, length 64 07:47:51.617192 00:0f:1f:6a:7b:91 > 00:13:72:5d:99:51, ethertype IPv4 (0x0800), length 98: 172.28.2.2 > 172.28.2.6: ICMP echo reply, id 64053, seq 1, length 64 343 uSec 07:47:52.644629 00:13:72:5d:99:51 > 00:0f:1f:6a:7b:91, ethertype IPv4 (0x0800), length 98: 172.28.2.6 > 172.28.2.2: ICMP echo request, id 64053, seq 2, length 64 07:47:52.644741 00:0f:1f:6a:7b:91 > 00:13:72:5d:99:51, ethertype IPv4 (0x0800), length 98: 172.28.2.2 > 172.28.2.6: ICMP echo reply, id 64053, seq 2, length 64 112 uSec 07:47:53.672976 00:13:72:5d:99:51 > 00:0f:1f:6a:7b:91, ethertype IPv4 (0x0800), length 98: 172.28.2.6 > 172.28.2.2: ICMP echo request, id 64053, seq 3, length 64 07:47:53.673179 00:0f:1f:6a:7b:91 > 00:13:72:5d:99:51, ethertype IPv4 (0x0800), length 98: 172.28.2.2 > 172.28.2.6: ICMP echo reply, id 64053, seq 3, length 64 223 uSec 07:47:54.700774 00:13:72:5d:99:51 > 00:0f:1f:6a:7b:91, ethertype IPv4 (0x0800), length 98: 172.28.2.6 > 172.28.2.2: ICMP echo request, id 64053, seq 4, length 64 07:47:54.700868 00:0f:1f:6a:7b:91 > 00:13:72:5d:99:51, ethertype IPv4 (0x0800), length 98: 172.28.2.2 > 172.28.2.6: ICMP echo reply, id 64053, seq 4, length 64 94 uSec ======== so a bit faster but not hugely. to get rid of the transmit times etc: on the echoing machine tcpdump shows: about 14uSec for ether_echo (with an occasional 16 or 19uSec) vs varying between 26usec and 46uSec for icmp echo. now even that isn't 'optimal' we can probably do better than that, as netgraph does have some overhead.. anyhow it's gotta be better than libpcap and a user program... From owner-freebsd-net@FreeBSD.ORG Thu Dec 25 09:32:27 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 602FE106574B; Thu, 25 Dec 2008 09:32:26 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id A9F228FC1F; Thu, 25 Dec 2008 09:32:26 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id mBP9WPaJ008045; Thu, 25 Dec 2008 01:32:25 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Thu, 25 Dec 2008 01:32:43 -0800 Message-ID: In-Reply-To: <49528E6F.30600@ukr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Odd behavior routed Thread-Index: AclmA7y6F1PGAzg6TQ6hQP4ZlBVQagAaEv6w References: <49528E6F.30600@ukr.net> From: "Li, Qing" To: "Vladislav V. Prodan" , "Qing Li" Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: RE: Odd behavior routed 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: Thu, 25 Dec 2008 09:32:27 -0000 SSBmb3VuZCB0aGUgYnVnIGFuZCBpdCB3YXMgaW5kZWVkIGludHJvZHVjZWQgYnkgdGhlIGFycC12 MiANCmNoYW5nZXMuDQoNClNpbmNlIGFkZGluZyBzdGF0aWMgQVJQL05EUCBlbnRyaWVzIGFuZCBh ZGRpbmcgc3RhdGljDQpyb3V0aW5nIGVudHJpZXMgYm90aCBleGVjdXRlIHRocm91Z2ggdGhlIHJv dXRpbmcgc29ja2V0DQppbnRlcmZhY2UsIEkgY291bGQgbm90IGRpc3Rpbmd1aXNoIG9uZSBvcGVy YXRpb24gZnJvbQ0KdGhlIG90aGVyIHdoZW4gdGhlICItaWZhY2UiIGlzIHNwZWNpZmllZCBpbiB0 aGUgInJvdXRlIg0KY29tbWFuZC4gDQoNCkkgaGF2ZSBpbnRyb2R1Y2VkIGEgbmV3IFJURl9MTERB VEEgZmxhZyB0byBkaWZmZXJlbnRpYXRlDQpiZXR3ZWVuIHRoZXNlIHR3byB0eXBlcyBvZiBvcGVy YXRpb24uDQoNClBsZWFzZSBmaW5kIHRoZSBwYXRjaCBmaWxlIGluIG15IGhvbWUgZGlyZWN0b3J5 DQphdCBodHRwOi8vcGVvcGxlLmZyZWVic2Qub3JnL35xaW5nbGkvYXJwLXYyLXBhdGNoLTEyMjUw OA0KDQpJIHdpbGwgZG8gbW9yZSB0ZXN0aW5nIGFuZCBnZXR0aW5nIHRoZSBwYXRjaCByZXZpZXdl ZA0KYmVmb3JlIEkgbWFrZSB0aGUgb2ZmaWNpYWwgY29tbWl0LiBJbiB0aGUgbWVhbnRpbWUsIA0K cGxlYXNlIHRyeSBpdCBvdXQgYW5kIGxldCBtZSBrbm93IGhvdyB0aGUgcGF0Y2ggd29ya3MgDQpv dXQgZm9yIHlvdS4NCg0KVGhhbmtzLA0KDQotLSBRaW5nDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPiBGcm9tOiBvd25lci1mcmVlYnNkLW5ldEBmcmVlYnNkLm9yZyBbbWFpbHRv Om93bmVyLWZyZWVic2QtDQo+IG5ldEBmcmVlYnNkLm9yZ10gT24gQmVoYWxmIE9mIFZsYWRpc2xh diBWLiBQcm9kYW4NCj4gU2VudDogV2VkbmVzZGF5LCBEZWNlbWJlciAyNCwgMjAwOCAxMTozMyBB TQ0KPiBUbzogZnJlZWJzZC1jdXJyZW50QGZyZWVic2Qub3JnOyBmcmVlYnNkLW5ldEBmcmVlYnNk Lm9yZw0KPiBDYzogZnJlZWJzZC1oYWNrZXJzQGZyZWVic2Qub3JnDQo+IFN1YmplY3Q6IE9kZCBi ZWhhdmlvciByb3V0ZWQNCj4gDQo+ICMgdW5hbWUgLWENCj4gRnJlZUJTRCBtYXJ5LXRlcmVzYS5Y WFhYWCA4LjAtQ1VSUkVOVCBGcmVlQlNEIDguMC1DVVJSRU5UICMwOiBXZWQgRGVjDQo+IDI0DQo+ IDA1OjA2OjU1IEVFVCAyMDA4DQo+IHZsYWQxMUBtYXJ5LXRlcmVzYS5YWFhYWDovdXNyL29iai91 c3Ivc3JjL3N5cy9tYXJ5LXRlcmVzYS4xMCAgYW1kNjQNCj4gDQo+IFdlIGhhdmUgdHdvIHByb3Zp ZGVycyBvbiB0dW4xIGFuZCB0dW4yLg0KPiANCj4gID4+L2V0Yy9yYy5jb25mOg0KPiAuLi4NCj4g Z2F0ZXdheV9lbmFibGU9IllFUyINCj4gcm91dGVyPSIvc2Jpbi9yb3V0ZWQiDQo+IHJvdXRlcl9l bmFibGU9IllFUyINCj4gcm91dGVyX2ZsYWdzPSItcyAtVCAvdmFyL2xvZy9yb3V0ZWQubG9nIC1Q IG5vX3JpcCINCj4gLi4uDQo+IA0KPiAjIG5ldHN0YXQgLXJuDQo+IFJvdXRpbmcgdGFibGVzDQo+ IA0KPiBJbnRlcm5ldDoNCj4gRGVzdGluYXRpb24gICAgICAgIEdhdGV3YXkgICAgICAgICAgICBG bGFncyAgICBSZWZzICAgICAgVXNlICBOZXRpZg0KPiBFeHBpcmUNCj4gZGVmYXVsdCAgICAgICAg ICAgIDg5LjIwOS45NS4yNTQgICAgICBVR1MgICAgICAgICAwICAgNjUzNDE4ICAgdHVuMQ0KPiAx MC4wLjAuMC8yNCAgICAgICAgbGluayMxICAgICAgICAgICAgIFUgICAgICAgICAgIDAgICAgODU1 OTUgICAgcmUwDQo+IDg1LjIzOC4xMDkuNjEgICAgICAxMjcuMC4wLjEgICAgICAgICAgVUggICAg ICAgICAgMCAgICAgICAgMCAgICBsbzANCj4gODkuMjA5LlhYLllZICAgICAgIDEyNy4wLjAuMSAg ICAgICAgICBVSCAgICAgICAgICAwICAgICAgNDgzICAgIGxvMA0KPiA4OS4yMDkuOTUuMjU0ICAg ICAgODkuMjA5LlhYLllZICAgICAgIFVIICAgICAgICAgIDAgICAgICAgIDAgICB0dW4xDQo+IDEy Ny4wLjAuMSAgICAgICAgICBsaW5rIzYgICAgICAgICAgICAgVUggICAgICAgICAgMCAgICAxOTc4 MSAgICBsbzANCj4gMTkyLjE2OC4xNTIuMC8yNCAgIDEwLjAuMC4yMCAgICAgICAgICBVR1MgICAg ICAgICAwICAgICAgICAwICAgIHJlMA0KPiAxOTUuMTM4LjgwLjE2OCAgICAgbGluayM4ICAgICAg ICAgICAgIFVIICAgICAgICAgIDAgICAgICAgIDUgICB0dW4yDQo+IA0KPiBJbnRlcm5ldDY6DQo+ IERlc3RpbmF0aW9uICAgICAgICAgICAgICAgICAgICAgICBHYXRld2F5ICAgICAgICAgICAgICAg ICAgICAgICBGbGFncw0KPiAgIE5ldGlmIEV4cGlyZQ0KPiA6OjEgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgbGluayM2ICAgICAgICAgICAgICAgICAgICAgICAgVUgNCj4gbG8wDQo+IGZl ODA6OiVsbzAvNjQgICAgICAgICAgICAgICAgICAgICBsaW5rIzYgICAgICAgICAgICAgICAgICAg ICAgICBVDQo+IGxvMA0KPiBmZjAxOjY6Oi8zMiAgICAgICAgICAgICAgICAgICAgICAgZmU4MDo6 MSVsbzAgICAgICAgICAgICAgICAgICAgVQ0KPiBsbzANCj4gZmYwMTo3OjovMzIgICAgICAgICAg ICAgICAgICAgICAgIGZlODA6OjJlMDo0ZGZmOmZlN2I6NjkwYyV0dW4xIFVHDQo+IHR1bjENCj4g ZmYwMTo4OjovMzIgICAgICAgICAgICAgICAgICAgICAgIGZlODA6OjJlMDo0ZGZmOmZlN2I6Njkw YyV0dW4yIFVHDQo+IHR1bjINCj4gZmYwMjo6JWxvMC8zMiAgICAgICAgICAgICAgICAgICAgIGZl ODA6OjElbG8wICAgICAgICAgICAgICAgICAgIFUNCj4gbG8wDQo+IGZmMDI6OiV0dW4xLzMyICAg ICAgICAgICAgICAgICAgICBmZTgwOjoyZTA6NGRmZjpmZTdiOjY5MGMldHVuMSBVRw0KPiB0dW4x DQo+IGZmMDI6OiV0dW4yLzMyICAgICAgICAgICAgICAgICAgICBmZTgwOjoyZTA6NGRmZjpmZTdi OjY5MGMldHVuMiBVRw0KPiB0dW4yDQo+IA0KPiANCj4gSSB3b3VsZCBsaWtlIHRvIHB1dCBzb21l IG5ldHdvcmtzIHZpYSBhIHNlY29uZCBJU1A6DQo+ICMgL3NiaW4vcm91dGUgYWRkIC1uZXQgNzku MTQwLjAuMC8yMCAtaWZhY2UgdHVuMg0KPiBhZGQgbmV0IDc5LjE0MC4wLjA6IGdhdGV3YXkgdHVu Mg0KPiAjIC9zYmluL3JvdXRlIGFkZCAtbmV0IDg1LjIzOC45Ni4wLzE5IC1pZmFjZSB0dW4yDQo+ IGFkZCBuZXQgODUuMjM4Ljk2LjA6IGdhdGV3YXkgdHVuMg0KPiAjIC9zYmluL3JvdXRlIGFkZCAt bmV0IDE5NS4xMzguNjQuMC8xOSAtaWZhY2UgdHVuMg0KPiBhZGQgbmV0IDE5NS4xMzguNjQuMDog Z2F0ZXdheSB0dW4yDQo+IA0KPiBCdXQgcm91dGVzIGRvIG5vdCBhcHBlYXIsIHRoZSB0YWJsZSBy ZW1haW5zIHVuY2hhbmdlZC4NCj4gSW4gdGhlIGxvZ3Mgcm91dGVkOg0KPiANCj4gUlRNX0FERCBm cm9tIHBpZCA3MjM0OiA3OS4xNDAuMC4wIChtYXNrIDB4ZmZmZmYwMDApIC0tPiA4NS4yMzguMTA5 LjYxDQo+IHN0YXRpYyByb3V0ZSA3OS4xNDAuMC4wIChtYXNrIDB4ZmZmZmYwMDApIC0tPiA4NS4y MzguMTA5LjYxIGltcG9zc2libHkNCj4gbGFja3MgaWZwDQo+IC0tIDExOjM1OjE2IC0tDQo+IFJU TV9BREQgZnJvbSBwaWQgNzI1MDogODUuMjM4Ljk2LjAgKG1hc2sgMHhmZmZmZTAwMCkgLS0+IDg1 LjIzOC4xMDkuNjENCj4gc3RhdGljIHJvdXRlIDg1LjIzOC45Ni4wIChtYXNrIDB4ZmZmZmUwMDAp IC0tPiA4NS4yMzguMTA5LjYxIGltcG9zc2libHkNCj4gbGFja3MgaWZwDQo+IC0tIDExOjM1OjI4 IC0tDQo+IFJUTV9BREQgZnJvbSBwaWQgNzI2MjogMTk1LjEzOC42NC4wIChtYXNrIDB4ZmZmZmUw MDApIC0tPiA4NS4yMzguMTA5LjYxDQo+IHN0YXRpYyByb3V0ZSAxOTUuMTM4LjY0LjAgKG1hc2sg MHhmZmZmZTAwMCkgLS0+IDg1LjIzOC4xMDkuNjENCj4gaW1wb3NzaWJseQ0KPiBsYWNrcyBpZnAN Cj4gDQo+IA0KPiBCZWZvcmUgcmVidWlsZCBrZXJuZWwsIGl0IGFwcGVhcmVkLCBhbmQgbm93IHRo ZXJlIGlzIG5vLg0KPiBJdCBpcyBub3cgYWRkaW5nIHJvdXRlcz8NCj4gDQo+IFVzaW5nIGdhdGVk fHF1YWdnYXx6ZWJyYSBkb2VzIG5vdCBvZmZlci4NCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBmcmVlYnNkLW5ldEBmcmVlYnNkLm9y ZyBtYWlsaW5nIGxpc3QNCj4gaHR0cDovL2xpc3RzLmZyZWVic2Qub3JnL21haWxtYW4vbGlzdGlu Zm8vZnJlZWJzZC1uZXQNCj4gVG8gdW5zdWJzY3JpYmUsIHNlbmQgYW55IG1haWwgdG8gImZyZWVi c2QtbmV0LXVuc3Vic2NyaWJlQGZyZWVic2Qub3JnIg0K From owner-freebsd-net@FreeBSD.ORG Thu Dec 25 10:11:18 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 5754B1065673; Thu, 25 Dec 2008 10:11:18 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id F0A128FC1A; Thu, 25 Dec 2008 10:11:17 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Subject:Message-ID:Reply-To:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender; b=Ke5ex527ArKSEK6rmP4DzPh7Pqgm02CnQgU3Qnwov86XpJCID3TOdHcO2rFuC0WpicjOc8Yx7fBZgBUuOqUr8MSQDqeDijNO124A20gibdxIkcsOyHAQ35r//EJjrwVLVUWW756hKxjxYmd0Er92B+EYa6nYGjMHB1EMrrg73Xs=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1LFnBU-0009X2-AB; Thu, 25 Dec 2008 13:11:16 +0300 Date: Thu, 25 Dec 2008 13:11:14 +0300 From: Eygene Ryabinkin To: "Li, Qing" Message-ID: References: <49528E6F.30600@ukr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: rea-fbsd@codelabs.ru Cc: Qing Li , "Vladislav V. Prodan" , freebsd-current@freebsd.org, freebsd-net@freebsd.org Subject: Re: Odd behavior routed X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rea-fbsd@codelabs.ru List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Dec 2008 10:11:18 -0000 Thu, Dec 25, 2008 at 01:32:43AM -0800, Li, Qing wrote: > Please find the patch file in my home directory > at http://people.freebsd.org/~qingli/arp-v2-patch-122508 The real URL is http://people.freebsd.org/~qingli/arp-v2-patch-122408 -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From owner-freebsd-net@FreeBSD.ORG Thu Dec 25 12:58:18 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 4E837106564A; Thu, 25 Dec 2008 12:58:18 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp-1.dlr.de (smtp-1.dlr.de [195.37.61.185]) by mx1.freebsd.org (Postfix) with ESMTP id D5E8C8FC12; Thu, 25 Dec 2008 12:58:17 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from [192.168.2.100] ([172.21.151.2]) by smtp-1.dlr.de with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Dec 2008 13:58:15 +0100 Message-ID: <4953834E.3020100@dlr.de> Date: Thu, 25 Dec 2008 13:57:50 +0100 From: Hartmut Brandt User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Robert Watson References: <55f001c9639d$875f14ec$7202020a@internal.cacheflow.com> <4950F770.3090700@dlr.de> <495165D8.2070409@dlr.de> <495246C9.9090305@incunabulum.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Dec 2008 12:58:15.0668 (UTC) FILETIME=[738C7B40:01C96690] Cc: Qing Li , "Li, Qing" , Bruce Simpson , freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: NATM hardware available 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: Thu, 25 Dec 2008 12:58:18 -0000 Robert Watson wrote: > On Wed, 24 Dec 2008, Bruce Simpson wrote: > >> Hartmut Brandt wrote: >> >>> In any case there is still an Todo on my side: the routing >>> information for NETNATM is currently lost somewhere between L2 and >>> L3 :-) I guess I come back to you in the new year to fix this >>> issue... Have to fetch my ATM equipment from the corner where it is >>> collecting dust to setup a testbed. >> >> Guys: >> >> Native NATM support would be nice, because it lets FreeBSD be used as >> a direct ADSL endpoint without an external ADSL router. >> >> I have a pair of ATM25 cards, an ATM25 crossover, and an >> ATM25-to-ADSL G.DMT modem bagged up ready to ship to someone who has >> the time and motivation to work on NATM. >> >> Also: I did have an ATM25 capable switch which I left at ICSI in >> Berkeley, I don't know where it is at the moment due to people >> movements. > > Do we have any of the necessary software parts to do simulated ATM > hardware similar to what if_tap does for Ethernet? Using the VIMAGE > stuff and virtual ATM hardware might open up the door to a more > accessible development and test environment. I did the NATM locking > work essentially "blind" due to a lack of test environment locally, > which seemed to work out, but a software test system would go a long way. Having at least a virtual interface would be nice. Should be fairly easy if only UBR (unspecified bit rate) is supported. harti From owner-freebsd-net@FreeBSD.ORG Thu Dec 25 19:38:23 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A50B106564A for ; Thu, 25 Dec 2008 19:38:23 +0000 (UTC) (envelope-from eugen@kuzbass.ru) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.freebsd.org (Postfix) with ESMTP id 988D58FC14 for ; Thu, 25 Dec 2008 19:38:21 +0000 (UTC) (envelope-from eugen@kuzbass.ru) Received: from www.svzserv.kemerovo.su (eugen@localhost [127.0.0.1]) by www.svzserv.kemerovo.su (8.13.8/8.13.8) with ESMTP id mBPJcICI009443 for ; Fri, 26 Dec 2008 02:38:18 +0700 (KRAT) (envelope-from eugen@www.svzserv.kemerovo.su) Received: (from eugen@localhost) by www.svzserv.kemerovo.su (8.13.8/8.13.8/Submit) id mBPJcIJP009442 for net@freebsd.org; Fri, 26 Dec 2008 02:38:18 +0700 (KRAT) (envelope-from eugen) Date: Fri, 26 Dec 2008 02:38:18 +0700 From: Eugene Grosbein To: net@freebsd.org Message-ID: <20081225193818.GA9210@svzserv.kemerovo.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: bsnmpd & BGP full view 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: Thu, 25 Dec 2008 19:38:23 -0000 Hi! Is there a way to reduce bsnmpd's CPU & memory usage for BGP router using full view? I do not need to deal with routing table via SNMP. SNMP is needed to monitor interface byte counters only via mrtg. bsnmpd grows upto 18Mb for FreeBSD 6.4 and worse, it hogs CPU while bgpd obtains full view. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Thu Dec 25 20:11:06 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 84C1E1065675; Thu, 25 Dec 2008 20:11:06 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 445008FC0C; Thu, 25 Dec 2008 20:11:06 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 962FD170E2; Thu, 25 Dec 2008 19:46:29 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.3/8.14.3) with ESMTP id mBPJkSVF017787; Thu, 25 Dec 2008 19:46:28 GMT (envelope-from phk@critter.freebsd.dk) To: Hartmut Brandt From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 25 Dec 2008 13:57:50 +0100." <4953834E.3020100@dlr.de> Date: Thu, 25 Dec 2008 19:46:28 +0000 Message-ID: <17786.1230234388@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: "Li, Qing" , freebsd-net@FreeBSD.org, Qing Li , freebsd-current@FreeBSD.org, Robert Watson , Bruce Simpson Subject: Re: NATM hardware available 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: Thu, 25 Dec 2008 20:11:06 -0000 In message <4953834E.3020100@dlr.de>, Hartmut Brandt writes: >> Do we have any of the necessary software parts to do simulated ATM >> hardware similar to what if_tap does for Ethernet? I believe I have a couple of ATM cards in my lab somewhere, who wants them ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-net@FreeBSD.ORG Thu Dec 25 20:23:42 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40B3E1065673 for ; Thu, 25 Dec 2008 20:23:42 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp-1.dlr.de (smtp-1.dlr.de [195.37.61.185]) by mx1.freebsd.org (Postfix) with ESMTP id CF9E98FC1A for ; Thu, 25 Dec 2008 20:23:41 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from [192.168.2.100] ([172.21.151.1]) by smtp-1.dlr.de with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Dec 2008 21:10:24 +0100 Message-ID: <4953E89B.1060102@dlr.de> Date: Thu, 25 Dec 2008 21:10:03 +0100 From: Hartmut Brandt User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Eugene Grosbein References: <20081225193818.GA9210@svzserv.kemerovo.su> In-Reply-To: <20081225193818.GA9210@svzserv.kemerovo.su> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Dec 2008 20:10:24.0532 (UTC) FILETIME=[D25B2540:01C966CC] Cc: net@freebsd.org Subject: Re: bsnmpd & BGP full view 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: Thu, 25 Dec 2008 20:23:42 -0000 Eugene Grosbein wrote: > Hi! > > Is there a way to reduce bsnmpd's CPU & memory usage > for BGP router using full view? > > I do not need to deal with routing table via SNMP. > SNMP is needed to monitor interface byte counters only via mrtg. > > bsnmpd grows upto 18Mb for FreeBSD 6.4 and worse, > it hogs CPU while bgpd obtains full view. > Hmm. I just had a look and the version in 6.4 already has the optimized route table (you may confirm that: contrib/bsnmp/snmp_mibII/mibII_route.c should include sys/tree.h). It takes 36 byte per route on a 32-bit machine and should take 52 byte on a 64-bit one. The only way to reduce memory consumption considerably that I can see is to use the kernel routing table directly, but this requires to implement the GETNEXT operation in kernel. In any case it should re-read the kernel table only every 10 minutes and in the mean time monitor the routing socket to update its copy of the table. If of course someone is doing a lot of updates on the kernel table it will receive all these changes and apply them to its copy of the routing table. If the latter is a problem you could disable the routing socket interface and could just rely on the 10 minute re-reads. Between these re-reads you would not see changes to the routing table through SNMP. BTW: how many routes do you have? When I introduced the optimized routing table I tested with 150k routes which was reported to be reasonable at that time. harti From owner-freebsd-net@FreeBSD.ORG Fri Dec 26 04:43:22 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B9411065678 for ; Fri, 26 Dec 2008 04:43:22 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 8FED38FC0C for ; Fri, 26 Dec 2008 04:43:21 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id mBQ48nGS036342; Thu, 25 Dec 2008 23:08:49 -0500 (EST) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.8/8.13.3) with ESMTP id mBQ48me9045751 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Dec 2008 23:08:48 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <200812260408.mBQ48me9045751@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 25 Dec 2008 23:08:50 -0500 To: Hartmut Brandt , Eugene Grosbein From: Mike Tancsa In-Reply-To: <4953E89B.1060102@dlr.de> References: <20081225193818.GA9210@svzserv.kemerovo.su> <4953E89B.1060102@dlr.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: net@freebsd.org Subject: Re: bsnmpd & BGP full view 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: Fri, 26 Dec 2008 04:43:22 -0000 At 03:10 PM 12/25/2008, Hartmut Brandt wrote: >BTW: how many routes do you have? When I introduced the optimized >routing table I tested with 150k routes which was reported to be >reasonable at that time. A full view is about 270k right now ---Mike From owner-freebsd-net@FreeBSD.ORG Fri Dec 26 06:41:12 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7B9B1065670 for ; Fri, 26 Dec 2008 06:41:12 +0000 (UTC) (envelope-from eugen@kuzbass.ru) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.freebsd.org (Postfix) with ESMTP id 069748FC08 for ; Fri, 26 Dec 2008 06:41:11 +0000 (UTC) (envelope-from eugen@kuzbass.ru) Received: from kuzbass.ru (kost [213.184.65.82]) by www.svzserv.kemerovo.su (8.13.8/8.13.8) with ESMTP id mBQ6f6p2051764; Fri, 26 Dec 2008 13:41:06 +0700 (KRAT) (envelope-from eugen@kuzbass.ru) Message-ID: <49547BFF.1E17DB47@kuzbass.ru> Date: Fri, 26 Dec 2008 13:38:55 +0700 From: Eugene Grosbein Organization: SVZServ X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: ru,en MIME-Version: 1.0 To: Hartmut Brandt References: <20081225193818.GA9210@svzserv.kemerovo.su> <4953E89B.1060102@dlr.de> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: bsnmpd & BGP full view 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: Fri, 26 Dec 2008 06:41:12 -0000 Hartmut Brandt wrote: > > Is there a way to reduce bsnmpd's CPU & memory usage > > for BGP router using full view? > > > > I do not need to deal with routing table via SNMP. > > SNMP is needed to monitor interface byte counters only via mrtg. > > > > bsnmpd grows upto 18Mb for FreeBSD 6.4 and worse, > > it hogs CPU while bgpd obtains full view. > > > > Hmm. I just had a look and the version in 6.4 already has the optimized > route table (you may confirm that: > contrib/bsnmp/snmp_mibII/mibII_route.c should include sys/tree.h). > It takes 36 byte per route on a 32-bit machine and should take 52 byte > on a 64-bit one. The only way to reduce memory consumption considerably > that I can see is to use the kernel routing table directly, but this > requires to implement the GETNEXT operation in kernel. > > In any case it should re-read the kernel table only every 10 minutes and > in the mean time monitor the routing socket to update its copy of the > table. If of course someone is doing a lot of updates on > the kernel table it will receive all these changes and apply them to its > copy of the routing table. If the latter is a problem you could disable > the routing socket interface and could just rely on the 10 > minute re-reads. Thank you very much. How do I disable this interface for bsnmpd? > Between these re-reads you would not see changes to the > routing table through SNMP. That's OK for me - I don't look at routing table through SNMP at all :-) > BTW: how many routes do you have? When I introduced the optimized > routing table I tested with 150k routes which was reported to be > reasonable at that time. More than 271k prefixes. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Fri Dec 26 08:31:37 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6353B1065673 for ; Fri, 26 Dec 2008 08:31:37 +0000 (UTC) (envelope-from petri@helenius.fi) Received: from silver.he.iki.fi (mx.helenius.fi [IPv6:2001:1bc8:1018::42]) by mx1.freebsd.org (Postfix) with ESMTP id E3F528FC17 for ; Fri, 26 Dec 2008 08:31:36 +0000 (UTC) (envelope-from petri@helenius.fi) Received: from localhost (localhost [127.0.0.1]) by silver.he.iki.fi (Postfix) with ESMTP id 4BEBCBBFB; Fri, 26 Dec 2008 10:31:34 +0200 (EET) Received: from silver.he.iki.fi ([127.0.0.1]) by localhost (silver.he.iki.fi [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jK69hWf6xglp; Fri, 26 Dec 2008 10:31:26 +0200 (EET) Received: from d205.helenius.fi (d205.helenius.fi [83.150.107.205]) by silver.he.iki.fi (Postfix) with ESMTP; Fri, 26 Dec 2008 10:31:26 +0200 (EET) Message-Id: From: Petri Helenius To: Hartmut Brandt In-Reply-To: <4953E89B.1060102@dlr.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 26 Dec 2008 10:31:25 +0200 References: <20081225193818.GA9210@svzserv.kemerovo.su> <4953E89B.1060102@dlr.de> X-Mailer: Apple Mail (2.930.3) Cc: Eugene Grosbein , net@freebsd.org Subject: Re: bsnmpd & BGP full view 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: Fri, 26 Dec 2008 08:31:37 -0000 On Dec 25, 2008, at 10:10 PM, Hartmut Brandt wrote: > > > In any case it should re-read the kernel table only every 10 minutes > and in the mean time monitor the routing socket to update its copy > of the table. If of course someone is doing a lot of updates on Why does it have to re-read the table periodically if it gets the updates anyway? Pete From owner-freebsd-net@FreeBSD.ORG Fri Dec 26 09:31:13 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1CF51106564A for ; Fri, 26 Dec 2008 09:31:13 +0000 (UTC) (envelope-from eugen@kuzbass.ru) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.freebsd.org (Postfix) with ESMTP id 24FC18FC20 for ; Fri, 26 Dec 2008 09:31:04 +0000 (UTC) (envelope-from eugen@kuzbass.ru) Received: from kuzbass.ru (kost [213.184.65.82]) by www.svzserv.kemerovo.su (8.13.8/8.13.8) with ESMTP id mBQ9UvGd060409; Fri, 26 Dec 2008 16:30:58 +0700 (KRAT) (envelope-from eugen@kuzbass.ru) Message-ID: <4954A459.37E85537@kuzbass.ru> Date: Fri, 26 Dec 2008 16:31:05 +0700 From: Eugene Grosbein Organization: SVZServ X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: ru,en MIME-Version: 1.0 To: Petri Helenius References: <20081225193818.GA9210@svzserv.kemerovo.su> <4953E89B.1060102@dlr.de> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Cc: Hartmut Brandt , net@freebsd.org Subject: Re: bsnmpd & BGP full view 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: Fri, 26 Dec 2008 09:31:13 -0000 Petri Helenius wrote: > > In any case it should re-read the kernel table only every 10 minutes > > and in the mean time monitor the routing socket to update its copy > > of the table. If of course someone is doing a lot of updates on > > Why does it have to re-read the table periodically if it gets the > updates anyway? To protect from bugs that may lead to missed updates on rtsocket, I guess. From owner-freebsd-net@FreeBSD.ORG Fri Dec 26 10:54:45 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C5F41106564A for ; Fri, 26 Dec 2008 10:54:45 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp-1.dlr.de (smtp-1.dlr.de [195.37.61.185]) by mx1.freebsd.org (Postfix) with ESMTP id 5D6D78FC2B for ; Fri, 26 Dec 2008 10:54:45 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from [192.168.2.100] ([172.21.151.2]) by smtp-1.dlr.de with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Dec 2008 11:54:43 +0100 Message-ID: <4954B7DF.3030006@dlr.de> Date: Fri, 26 Dec 2008 11:54:23 +0100 From: Hartmut Brandt User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Eugene Grosbein References: <20081225193818.GA9210@svzserv.kemerovo.su> <4953E89B.1060102@dlr.de> <4954A459.37E85537@kuzbass.ru> In-Reply-To: <4954A459.37E85537@kuzbass.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Dec 2008 10:54:43.0180 (UTC) FILETIME=[5BC652C0:01C96748] Cc: Petri Helenius , net@freebsd.org Subject: Re: bsnmpd & BGP full view 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: Fri, 26 Dec 2008 10:54:45 -0000 Eugene Grosbein wrote: > Petri Helenius wrote: > > >>> In any case it should re-read the kernel table only every 10 minutes >>> and in the mean time monitor the routing socket to update its copy >>> of the table. If of course someone is doing a lot of updates on >>> >> Why does it have to re-read the table periodically if it gets the >> updates anyway? >> > > To protect from bugs that may lead to missed updates on rtsocket, I guess. > Yes. I was not sure how well this works. In any case if there is too many traffic from the kernel to the daemon the socket buffer may drop messages. Give me a day and I send you a patch so that you can tune the re-read interval and the routing socket monitoring. harti From owner-freebsd-net@FreeBSD.ORG Fri Dec 26 10:59:22 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 D43A61065673 for ; Fri, 26 Dec 2008 10:59:22 +0000 (UTC) (envelope-from buddy@telenet.ru) Received: from k66.ru (mail.telenet.ru [87.224.128.3]) by mx1.freebsd.org (Postfix) with ESMTP id 3AF4A8FC1C for ; Fri, 26 Dec 2008 10:59:21 +0000 (UTC) (envelope-from buddy@telenet.ru) Received: from [87.224.188.131] (account buddy@telenet.ru HELO machine.hq.telenet.ru) by k66.ru (CommuniGate Pro SMTP 5.1.13) with ESMTPA id 263800657; Fri, 26 Dec 2008 15:29:18 +0500 Date: Fri, 26 Dec 2008 15:28:22 +0500 From: Andrew Alcheyev X-Mailer: The Bat! (v3.80.06) Professional Organization: Telenet-Service Ltd. X-Priority: 3 (Normal) Message-ID: <46629699.20081226152822@telenet.ru> To: freebsd-net@freebsd.org In-Reply-To: <20081225193818.GA9210@svzserv.kemerovo.su> References: <20081225193818.GA9210@svzserv.kemerovo.su> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----------CF888BBEB4C9E" Cc: Eugene Grosbein Subject: Re: bsnmpd & BGP full view X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Andrew Alcheyev List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Dec 2008 10:59:22 -0000 ------------CF888BBEB4C9E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello. On Friday, December 26, 2008, 12:38:18 AM you wrote: EG> Is there a way to reduce bsnmpd's CPU & memory usage EG> for BGP router using full view? EG> I do not need to deal with routing table via SNMP. EG> SNMP is needed to monitor interface byte counters only via mrtg. EG> bsnmpd grows upto 18Mb for FreeBSD 6.4 and worse, EG> it hogs CPU while bgpd obtains full view. You can try the attached patch - it cuts off any routing table processing within bsnmpd. It will be really useful if someone implements some variable in /etc/snmpd.config to control such behaviour. With best regards, Andrew. ------------CF888BBEB4C9E Content-Type: application/octet-stream; name="snmp_mibII__mibII.c.patch" Content-transfer-encoding: base64 Content-Disposition: attachment; filename="snmp_mibII__mibII.c.patch" LS0tIC91c3Ivc3JjL2NvbnRyaWIvYnNubXAvc25tcF9taWJJSS9taWJJSS5jLm9yaWcJMjAw Ni0wMy0zMSAxODo0MzozOC4wMDAwMDAwMDAgKzA2MDAKKysrIC91c3Ivc3JjL2NvbnRyaWIv YnNubXAvc25tcF9taWJJSS9taWJJSS5jCTIwMDgtMTItMjYgMTQ6NDY6MjQuMDAwMDAwMDAw ICswNTAwCkBAIC00MSw4ICs0MSwxMyBAQAogc3RhdGljIHN0cnVjdCBsbW9kdWxlICptb2R1 bGU7CiAKIC8qIHJvdXRpbmcgc29ja2V0ICovCisjaWYgMAogc3RhdGljIGludCByb3V0ZTsK IHN0YXRpYyB2b2lkICpyb3V0ZV9mZDsKKyNlbHNlCitzdGF0aWMgaW50IHJvdXRlID0gLTE7 CitzdGF0aWMgdm9pZCAqcm91dGVfZmQgPSBOVUxMOworI2VuZGlmCiAKIC8qIGlmLWluZGV4 IGFsbG9jYXRvciAqLwogc3RhdGljIHVpbnQzMl90IG5leHRfaWZfaW5kZXggPSAxOwpAQCAt MTMzMCw2ICsxMzM1LDcgQEAKIH0KIAogCisjaWYgMAogLyoKICAqIEludHB1dCBvbiB0aGUg cm91dGluZyBzb2NrZXQuCiAgKi8KQEAgLTEzNTIsNiArMTM1OCw3IEBACiAKIAloYW5kbGVf cnRtc2cocnRtKTsKIH0KKyNlbmRpZgogCiAvKgogICogZXhlY3V0ZSBhbmQgU0lPQ0FJRkFE RFIKQEAgLTE2NDQsMTAgKzE2NTEsMTIgQEAKIHN0YXRpYyB2b2lkCiBtaWJJSV9zdGFydCh2 b2lkKQogeworI2lmIDAKIAlpZiAoKHJvdXRlX2ZkID0gZmRfc2VsZWN0KHJvdXRlLCByb3V0 ZV9pbnB1dCwgTlVMTCwgbW9kdWxlKSkgPT0gTlVMTCkgewogCQlzeXNsb2coTE9HX0VSUiwg ImZkX3NlbGVjdChyb3V0ZSk6ICVtIik7CiAJCXJldHVybjsKIAl9CisjZW5kaWYKIAltaWJf cmVmcmVzaF9pZmxpc3QoKTsKIAl1cGRhdGVfaWZhX2luZm8oKTsKIAltaWJfYXJwX3VwZGF0 ZSgpOwpAQCAtMTY5NCwxMCArMTcwMywxMiBAQAogCQlyZXR1cm4gKC0xKTsKIAl9CiAKKyNp ZiAwCiAJaWYgKChyb3V0ZSA9IHNvY2tldChQRl9ST1VURSwgU09DS19SQVcsIEFGX1VOU1BF QykpID09IC0xKSB7CiAJCXN5c2xvZyhMT0dfRVJSLCAiUEZfUk9VVEU6ICVtIik7CiAJCXJl dHVybiAoLTEpOwogCX0KKyNlbmRpZgogCiAJaWYgKChtaWJfbmV0c29jayA9IHNvY2tldChQ Rl9JTkVULCBTT0NLX0RHUkFNLCAwKSkgPT0gLTEpIHsKIAkJc3lzbG9nKExPR19FUlIsICJQ Rl9JTkVUOiAlbSIpOwo= ------------CF888BBEB4C9E-- From owner-freebsd-net@FreeBSD.ORG Fri Dec 26 11:08:44 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 1D5DB106564A for ; Fri, 26 Dec 2008 11:08:44 +0000 (UTC) (envelope-from nrml@att.net) Received: from web83807.mail.sp1.yahoo.com (web83807.mail.sp1.yahoo.com [69.147.85.77]) by mx1.freebsd.org (Postfix) with SMTP id 07B338FC19 for ; Fri, 26 Dec 2008 11:08:43 +0000 (UTC) (envelope-from nrml@att.net) Received: (qmail 2784 invoked by uid 60001); 26 Dec 2008 10:42:01 -0000 X-YMail-OSG: LRpWNK0VM1lFRDkrDB1g6kSas7ssHuZCQZmCqxe.oWJbL1H5.61tHRAC2J8e6Lqt._6.UZFTiYN9WpIMEDig9DEVOw0lxLvMYFiFEJcV5ahESskl_7Q4.7UmI_1hlywFKYp6magmp2Ww0KMEVdbiBVlJ Received: from [69.43.143.172] by web83807.mail.sp1.yahoo.com via HTTP; Fri, 26 Dec 2008 02:42:01 PST X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.218.2 Date: Fri, 26 Dec 2008 02:42:01 -0800 (PST) From: nrml nrml To: freebsd-net@freebsd.org MIME-Version: 1.0 Message-ID: <960173.98196.qm@web83807.mail.sp1.yahoo.com> Content-Type: text/plain; charset=us-ascii X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: IPSec + Packet loss and ipsec_common_input error 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: Fri, 26 Dec 2008 11:08:44 -0000 All, So I've got IPSec installed and configured and I can communicate across the tunnel just fine but I got some pretty bad packet loss: I've got server1 connected to server2 in another building via a T1 circuit. This is from server1 to a sever behind server2: --- 192.168.20.x ping statistics --- 10 packets transmitted, 6 packets received, 40.0% packet loss round-trip min/avg/max/stddev = 253.545/263.815/270.700/5.500 ms This is from server2 to a machine behind server1 --- 192.168.10.x ping statistics --- 10 packets transmitted, 6 packets received, 40.0% packet loss round-trip min/avg/max/stddev = 258.654/272.065/286.893/8.608 ms And on top of that I've got these messags on both server1 and server2 but most of them are on server1 for some reason: ipsec_common_input: no key association found for SA ipsec_common_input: no key association found for SA ipsec_common_input: no key association found for SA ipsec_common_input: no key association found for SA ipsec_common_input: no key association found for SA ipsec_common_input: no key association found for SA Anyone have any clues? At this point I'm thinking its either just the connection is just bogged down or.. I'm not sure. Thanks /gabe From owner-freebsd-net@FreeBSD.ORG Fri Dec 26 11:27:21 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 185F01065675 for ; Fri, 26 Dec 2008 11:27:21 +0000 (UTC) (envelope-from nrml@att.net) Received: from smtp105.sbc.mail.mud.yahoo.com (smtp105.sbc.mail.mud.yahoo.com [68.142.198.204]) by mx1.freebsd.org (Postfix) with SMTP id D5D668FC3A for ; Fri, 26 Dec 2008 11:27:20 +0000 (UTC) (envelope-from nrml@att.net) Received: (qmail 45098 invoked from network); 26 Dec 2008 11:27:20 -0000 Received: from unknown (HELO Inbox) (nrml@72.62.72.102 with login) by smtp105.sbc.mail.mud.yahoo.com with SMTP; 26 Dec 2008 11:27:19 -0000 X-YMail-OSG: Tlj94kYVM1nJiF.UL7ESdCd60auRLrK.yVC.n1jH6Qxesi15OcraCPnlZ1DS6BnN2Ap1AyrEP.oEBXHIDYl9G7Zs0BNkDtJpu3i3GWpJyE5TRPjq2HOnl3.6x5c.sBEpNWe3Fw5_e_cfm7dcBPZYMTe7FC9a_2S5W7nB1gXPjGWdziRA5R6wjik- X-Yahoo-Newman-Property: ymail-3 MIME-Version: 1.0 content-class: From: Gabe Date: Fri, 26 Dec 2008 03:27:33 -0800 Importance: normal X-Priority: 3 To: Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Message-Id: <20081226112720.D5D668FC3A@mx1.freebsd.org> Subject: RE: IPSec + Packet loss and ipsec_common_input error 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: Fri, 26 Dec 2008 11:27:21 -0000 >-----Original Message----- >From: nrml nrml >Sent: Friday, December 26, 2008 >2:42 AM >To: freebsd-net@freebsd.org >Subject: IPSec + Packet loss and=20 >ipsec_common_input error > >All, > >So I've got IPSec installed and=20 >configured and I can communicate >across the tunnel just fine but I got >s= ome pretty bad packet loss: > >I've got server1 connected to=20 >server2 in another building via a T1 circuit. > >This is from server1 to a sever=20 >behind server2: >--- 192.168.20.x ping statistics --- >10 packets transmitted, 6 packets >received, 40.0% packet loss >round-trip min/avg/max/stddev =3D >253.545/263.815/270.700/5.500=20 >ms >This is from server2 to a machine >behind server1 >--- 192.168.10.x ping statistics --- >10 packets transmitted, 6 packets >received, 40.0% packet loss >round-trip min/avg/max/stddev =3D >258.654/272.065/286.893/8.608=20 >ms >And on top of that I've got these=20 >messags on both server1 and=20 >server2 but most of them are on=20 >server1 for some reason: >ipsec_common_input: no key=20 >association found for SA >ipsec_common_input: no key association found for SA=20 >ipsec_common_input: no key association found for SA=20 >ipsec_common_input: no key association found for SA=20 >ipsec_common_input: no key association found for SA=20 >ipsec_common_input: no key association found for SA=20 >Anyone have any clues? At this=20 >point I'm thinking its either just the >connection is just bogged down or.= >I'm not sure. >Thanks >/gabe _______________________________________________ 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" ---------------------------------------------------------- Okay I figured out the packet loss issue but I still don't know the cause o= f those messages. thanks= From owner-freebsd-net@FreeBSD.ORG Fri Dec 26 11:49:54 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 7C567106564A for ; Fri, 26 Dec 2008 11:49:54 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:203:6dff:fe1a:4ddc]) by mx1.freebsd.org (Postfix) with ESMTP id E06898FC1A for ; Fri, 26 Dec 2008 11:49:53 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from [10.1.1.54] ([10.1.1.54]) (authenticated bits=0) by lakerest.net (8.14.1/8.14.1) with ESMTP id mBQBnpVx023294 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 26 Dec 2008 06:49:52 -0500 (EST) (envelope-from rrs@lakerest.net) Message-Id: <83B28BE4-6F66-4845-9DD6-5A9668521414@lakerest.net> From: Randall Stewart To: Bruce Evans In-Reply-To: <20081224232356.O754@delplex.bde.org> Content-Type: multipart/mixed; boundary=Apple-Mail-146-729405199 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 26 Dec 2008 06:49:51 -0500 References: <494157DF.6030802@FreeBSD.org> <13C9478E-CBF6-4EDA-8E78-AD76549EB844@lakerest.net> <200812132030.15665.max@love2party.net> <4A152664-B170-4C6C-85C1-58E2E1577CA3@lakerest.net> <20081224232356.O754@delplex.bde.org> X-Mailer: Apple Mail (2.930.3) Cc: freebsd-net Subject: Re: Heads up --- Thinking about UDP and tunneling 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: Fri, 26 Dec 2008 11:49:54 -0000 --Apple-Mail-146-729405199 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Bruce: Ok some comments in line and an updated patch... I went through and reverted and manually cut out the "extra's" that s9indent (note not my script something I got for gnn) did :-) And I also have some comments for you :-D On Dec 24, 2008, at 7:46 AM, Bruce Evans wrote: > On Tue, 23 Dec 2008, Randall Stewart wrote: > >> 4) revamped my s9indent use.. I ran it and then patched back >> in just its complaints about me... that way the other s9 issues >> can stay in the file untouched by me :-D > > Thanks, but it still has many of the style bugs already pointed out > and a few new ones. Please fix them and s9indent so that they don't > get pointed out again :-). > > % Index: netinet/udp_usrreq.c > % =================================================================== > % --- netinet/udp_usrreq.c (revision 185928) > % +++ netinet/udp_usrreq.c (working copy) > % @@ -488,41 +488,76 @@ > % struct mbuf *n; > % % n = m_copy(m, 0, M_COPYALL); > % - if (n != NULL) > % - udp_append(last, ip, n, iphlen + > % - sizeof(struct udphdr), &udp_in); > % - INP_RUNLOCK(last); > % + > > Extra blank line. I fixed this.. but I don't see anything in style(9) that talks about taking out extra spaces.. also I find in udp6_usrreq.c (in a quick look) LOTS of places where an extra is present. Is this something missing in style(9) or something recently added? > > > % + if (last->inp_ppcb == NULL) { > % + if (n != NULL) > % + udp_append(last, ip, n, iphlen + > % + sizeof(struct udphdr), &udp_in); > > Line too long. Ok found that and did a bit of rearranging :-) > > > % + INP_RUNLOCK(last); > % + } else { > % + /* > % + * Engage the tunneling protocol we > % + * will have to leave the info_lock > % + * up, since we are hunting through > % + * multiple UDP inp's hope we don't > % + * break :-( > > Missing punctuation. Hmm.. this one must have crept back in when I took Matt's patch since I had fixed it before. Note that just like the extra blank, I don't see anything in style(9) that talks about punctuation in comments (besides the comments on the list that :-)/( and friends were thought to be punctuation :-D)... is this too a new or just missing item from style(9)? > > > % + * % + * XXXML: Maybe add a flag to the > % + * prototype so that the tunneling > % + * can defer work that can't be done > % + * under the info lock? > % + */ > % + udp_tunnel_func_t tunnel_func; > > This typedef is very verbose... Ok, I dropped it down to udp_tun_func_t .. the minimum IMO needed to make it clear what is being done. I have some of those c++ tendency's to want things to be clear :-) > > > % + > % + tunnel_func = (udp_tunnel_func_t) last->inp_ppcb; > > ... line too long, caused by the verbose typedef. I think the 3 char's fix this .. :-) > > > Casts are not followed by a space in KNF. This style bug is made > fairly > consistently in this patch. Hmm I wonder if that was s9indent.. need to go look at that script... since I normally don't put white space in front of a cast ;-D > > > Bogus cast (depends on undefined behaviour to save space). We discussed this.. and I don't think its worth adding the space... > > > % + tunnel_func(m, iphlen, last); > % + INP_RUNLOCK(last); > % + } > % } > % last = inp; > % /* > % - * Don't look for additional matches if this one does > % - * not have either the SO_REUSEPORT or SO_REUSEADDR > % - * socket options set. This heuristic avoids > % - * searching through all pcbs in the common case of a > % - * non-shared port. It assumes that an application > % - * will never clear these options after setting them. > % + * Don't look for additional matches if this one > % + * does not have either the SO_REUSEPORT or > % + * SO_REUSEADDR socket options set. This heuristic > % + * avoids searching through all pcbs in the common > % + * case of a non-shared port. It assumes that an > % + * application will never clear these options after > % + * setting them. > % */ > % if ((last->inp_socket->so_options & > % - (SO_REUSEPORT|SO_REUSEADDR)) == 0) > % + (SO_REUSEPORT | SO_REUSEADDR)) == 0) > > You didn't have to touch this statement. Touching it improves it. > > % break; > % } > % % if (last == NULL) { > % /* > % - * No matching pcb found; discard datagram. (No need > % - * to send an ICMP Port Unreachable for a broadcast > % - * or multicast datgram.) > % + * No matching pcb found; discard datagram. (No > % + * need to send an ICMP Port Unreachable for a > % + * broadcast or multicast datgram.) > > You didn't have to touch this. Touching it unimproves it. > > % ... > % } > % - > % /* > % * Locate pcb for datagram. > % */ > % @@ -553,7 +588,6 @@ > % INP_INFO_RUNLOCK(&V_udbinfo); > % return; > % } > % - > % /* > % * Check the minimum TTL for socket. > % */ > > You didn't have to touch these. Touching them arguably unimproves > them, > though strict KNF probably doesn't permit these blank lines. Ok, All of those touches (improvements or un-improvements) are gone now :-D > > > % @@ -563,6 +597,18 @@ > % INP_RUNLOCK(inp); > % goto badunlocked; > % } > % + if (inp->inp_ppcb) { > > It is preferable to compare pointers explicitly with NULL. The > previous > comparision of inp_ppcb in this patch is explicit (but it is for > equality). > This and all of the following comparisions are implicit (for > inequality). I agree .. and have made those changes :-D > > > % @@ -1138,10 +1184,41 @@ > % INP_INFO_WUNLOCK(&V_udbinfo); > % inp->inp_vflag |= INP_IPV4; > % inp->inp_ip_ttl = V_ip_defttl; > % + /* > % + * UDP does not have a per-protocol > % + * pcb (inp->inp_ppcb). We use this > % + * pointer for kernel tunneling pointer. > % + * If we ever need to have a protocol > % + * block we will need to move this > % + * function pointer there. Null > % + * in this pointer means "do the normal > % + * thing". > % + */ > > Lines too short (formatted for 50-column terminals). Fixed... > > > Normal entence breaks are 2 spaces, not 1 as in this comment. Most > of the > other comments in this patch have normal sentence breakes. > > % ... > % +int > % +udp_set_kernel_tunneling(struct socket *so, udp_tunnel_func_t f) > % +{ > % + struct inpcb *inp; > > Missing blank line after declarations. > > % + inp = (struct inpcb *)so->so_pcb; > % + > > Extra blank line. > > % + if (so->so_type != SOCK_DGRAM) { > % + /* Not UDP socket... sorry */ > > Missing punctuation. fixed both of these... but my comments above apply :-D > > > % Index: netinet/udp_var.h > % =================================================================== > % --- netinet/udp_var.h (revision 185928) > % +++ netinet/udp_var.h (working copy) > % @@ -107,6 +107,10 @@ > % void udp_input(struct mbuf *, int); > % struct inpcb *udp_notify(struct inpcb *inp, int errno); > % int udp_shutdown(struct socket *so); > % + > % + > % +typedef void(*udp_tunnel_func_t)(struct mbuf *, int off, struct > inpcb *); > % +int udp_set_kernel_tunneling(struct socket *so, udp_tunnel_func_t > f); > % #endif > % % #endif > > Still has a style bug density of about 5 per line :-(. > > % Index: netinet6/udp6_usrreq.c > > Similarly. > > Bruce > --Apple-Mail-146-729405199 Content-Disposition: attachment; filename=udp_patch_again.txt Content-Type: text/plain; x-unix-mode=0644; name="udp_patch_again.txt" Content-Transfer-Encoding: 7bit Index: netinet/udp_usrreq.c =================================================================== --- netinet/udp_usrreq.c (revision 186478) +++ netinet/udp_usrreq.c (working copy) @@ -488,10 +488,33 @@ struct mbuf *n; n = m_copy(m, 0, M_COPYALL); - if (n != NULL) - udp_append(last, ip, n, iphlen + - sizeof(struct udphdr), &udp_in); - INP_RUNLOCK(last); + if (last->inp_ppcb == NULL) { + if (n != NULL) + udp_append(last, + ip, n, + iphlen + + sizeof(struct udphdr), + &udp_in); + INP_RUNLOCK(last); + } else { + /* + * Engage the tunneling protocol we + * will have to leave the info_lock + * up, since we are hunting through + * multiple UDP inp's hope we don't + * break. + * + * XXXML: Maybe add a flag to the + * prototype so that the tunneling + * can defer work that can't be done + * under the info lock? + */ + udp_tun_func_t tunnel_func; + + tunnel_func = (udp_tun_func_t)last->inp_ppcb; + tunnel_func(n, iphlen, last); + INP_RUNLOCK(last); + } } last = inp; /* @@ -516,10 +539,24 @@ V_udpstat.udps_noportbcast++; goto badheadlocked; } - udp_append(last, ip, m, iphlen + sizeof(struct udphdr), - &udp_in); - INP_RUNLOCK(last); - INP_INFO_RUNLOCK(&V_udbinfo); + if (last->inp_ppcb == NULL) { + udp_append(last, ip, m, iphlen + sizeof(struct udphdr), + &udp_in); + INP_RUNLOCK(last); + INP_INFO_RUNLOCK(&V_udbinfo); + } else { + /* + * Engage the tunneling protocol we must make sure + * all locks are released when we call the tunneling + * protocol. + */ + udp_tun_func_t tunnel_func; + + tunnel_func = (udp_tun_func_t)last->inp_ppcb; + tunnel_func(m, iphlen, last); + INP_RUNLOCK(last); + INP_INFO_RUNLOCK(&V_udbinfo); + } return; } @@ -563,6 +600,18 @@ INP_RUNLOCK(inp); goto badunlocked; } + if (inp->inp_ppcb != NULL) { + /* + * Engage the tunneling protocol we must make sure all locks + * are released when we call the tunneling protocol. + */ + udp_tun_func_t tunnel_func; + + tunnel_func = (udp_tun_func_t)inp->inp_ppcb; + tunnel_func(m, iphlen, inp); + INP_RUNLOCK(inp); + return; + } udp_append(inp, ip, m, iphlen + sizeof(struct udphdr), &udp_in); INP_RUNLOCK(inp); return; @@ -1138,10 +1187,38 @@ INP_INFO_WUNLOCK(&V_udbinfo); inp->inp_vflag |= INP_IPV4; inp->inp_ip_ttl = V_ip_defttl; + /* + * UDP does not have a per-protocol pcb (inp->inp_ppcb). + * We use this pointer for kernel tunneling pointer. + * If we ever need to have a protocol block we will + * need to move this function pointer there. Null + * in this pointer means "do the normal thing". + */ + inp->inp_ppcb = NULL; INP_WUNLOCK(inp); return (0); } +int +udp_set_kernel_tunneling(struct socket *so, udp_tun_func_t f) +{ + struct inpcb *inp; + + inp = (struct inpcb *)so->so_pcb; + if (so->so_type != SOCK_DGRAM) { + /* Not UDP socket... sorry! */ + return (ENOTSUP); + } + if (inp == NULL) { + /* NULL INP? */ + return (EINVAL); + } + INP_WLOCK(inp); + inp->inp_ppcb = f; + INP_WUNLOCK(inp); + return (0); +} + static int udp_bind(struct socket *so, struct sockaddr *nam, struct thread *td) { Index: netinet/udp_var.h =================================================================== --- netinet/udp_var.h (revision 186478) +++ netinet/udp_var.h (working copy) @@ -110,6 +110,10 @@ void udp_input(struct mbuf *, int); struct inpcb *udp_notify(struct inpcb *inp, int errno); int udp_shutdown(struct socket *so); + + +typedef void(*udp_tun_func_t)(struct mbuf *, int off, struct inpcb *); +int udp_set_kernel_tunneling(struct socket *so, udp_tun_func_t f); #endif #endif Index: netinet6/udp6_usrreq.c =================================================================== --- netinet6/udp6_usrreq.c (revision 186478) +++ netinet6/udp6_usrreq.c (working copy) @@ -287,8 +287,25 @@ if ((n = m_copy(m, 0, M_COPYALL)) != NULL) { INP_RLOCK(last); - udp6_append(last, n, off, &fromsa); - INP_RUNLOCK(last); + if (last->inp_ppcb != NULL) { + /* + * Engage the tunneling + * protocol we will have to + * leave the info_lock up, + * since we are hunting + * through multiple UDP + * inp's hope we don't break. + * + */ + udp_tun_func_t tunnel_func; + + tunnel_func = (udp_tun_func_t)last->inp_ppcb; + tunnel_func(n, off, last); + INP_RUNLOCK(last); + } else { + udp6_append(last, n, off, &fromsa); + INP_RUNLOCK(last); + } } } last = inp; @@ -317,6 +334,19 @@ } INP_RLOCK(last); INP_INFO_RUNLOCK(&V_udbinfo); + if (last->inp_ppcb != NULL) { + /* + * Engage the tunneling protocol we must make sure + * all locks are released when we call the tunneling + * protocol. + */ + udp_tun_func_t tunnel_func; + + tunnel_func = (udp_tun_func_t)inp->inp_ppcb; + tunnel_func(m, off, last); + INP_RUNLOCK(last); + return (IPPROTO_DONE); + } udp6_append(last, m, off, &fromsa); INP_RUNLOCK(last); return (IPPROTO_DONE); @@ -354,6 +384,18 @@ } INP_RLOCK(inp); INP_INFO_RUNLOCK(&V_udbinfo); + if (inp->inp_ppcb != NULL) { + /* + * Engage the tunneling protocol we must make sure all locks + * are released when we call the tunneling protocol. + */ + udp_tun_func_t tunnel_func; + + tunnel_func = (udp_tun_func_t)inp->inp_ppcb; + tunnel_func(m, off, inp); + INP_RUNLOCK(inp); + return (IPPROTO_DONE); + } udp6_append(inp, m, off, &fromsa); INP_RUNLOCK(inp); return (IPPROTO_DONE); --Apple-Mail-146-729405199 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct) --Apple-Mail-146-729405199-- From owner-freebsd-net@FreeBSD.ORG Fri Dec 26 20:15:33 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 A67E4106564A; Fri, 26 Dec 2008 20:15:33 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id 87EE18FC17; Fri, 26 Dec 2008 20:15:33 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id mBQKFWW3005390; Fri, 26 Dec 2008 12:15:33 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Fri, 26 Dec 2008 12:15:53 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Odd behavior routed Thread-Index: AclmA7y6F1PGAzg6TQ6hQP4ZlBVQagAaEv6wAEqQL/A= References: <49528E6F.30600@ukr.net> From: "Li, Qing" To: "Vladislav V. Prodan" , "Qing Li" Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: RE: Odd behavior routed 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: Fri, 26 Dec 2008 20:15:33 -0000 SGksDQoNCkkgaGF2ZSBjb21taXR0ZWQgYSBwYXRjaCBmb3IgdGhpcyBwcm9ibGVtLiBQbGVhc2Ug c3luYy11cCB0bw0KDQogIFNWTiByZXYgMTg2NTAwIG9uIDIwMDgtMTItMjYgMTk6NDU6MjRaIGJ5 IHFpbmdsaQ0KDQpUaGFuaywNCg0KLS0gUWluZw0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gRnJvbTogb3duZXItZnJlZWJzZC1jdXJyZW50QGZyZWVic2Qub3JnIFttYWlsdG86 b3duZXItZnJlZWJzZC0NCj4gY3VycmVudEBmcmVlYnNkLm9yZ10gT24gQmVoYWxmIE9mIExpLCBR aW5nDQo+IFNlbnQ6IFRodXJzZGF5LCBEZWNlbWJlciAyNSwgMjAwOCAxOjMzIEFNDQo+IFRvOiBW bGFkaXNsYXYgVi4gUHJvZGFuOyBRaW5nIExpDQo+IENjOiBmcmVlYnNkLW5ldEBmcmVlYnNkLm9y ZzsgZnJlZWJzZC1jdXJyZW50QGZyZWVic2Qub3JnDQo+IFN1YmplY3Q6IFJFOiBPZGQgYmVoYXZp b3Igcm91dGVkDQo+IA0KPiBJIGZvdW5kIHRoZSBidWcgYW5kIGl0IHdhcyBpbmRlZWQgaW50cm9k dWNlZCBieSB0aGUgYXJwLXYyDQo+IGNoYW5nZXMuDQo+IA0KPiBTaW5jZSBhZGRpbmcgc3RhdGlj IEFSUC9ORFAgZW50cmllcyBhbmQgYWRkaW5nIHN0YXRpYw0KPiByb3V0aW5nIGVudHJpZXMgYm90 aCBleGVjdXRlIHRocm91Z2ggdGhlIHJvdXRpbmcgc29ja2V0DQo+IGludGVyZmFjZSwgSSBjb3Vs ZCBub3QgZGlzdGluZ3Vpc2ggb25lIG9wZXJhdGlvbiBmcm9tDQo+IHRoZSBvdGhlciB3aGVuIHRo ZSAiLWlmYWNlIiBpcyBzcGVjaWZpZWQgaW4gdGhlICJyb3V0ZSINCj4gY29tbWFuZC4NCj4gDQo+ IEkgaGF2ZSBpbnRyb2R1Y2VkIGEgbmV3IFJURl9MTERBVEEgZmxhZyB0byBkaWZmZXJlbnRpYXRl DQo+IGJldHdlZW4gdGhlc2UgdHdvIHR5cGVzIG9mIG9wZXJhdGlvbi4NCj4gDQo+IFBsZWFzZSBm aW5kIHRoZSBwYXRjaCBmaWxlIGluIG15IGhvbWUgZGlyZWN0b3J5DQo+IGF0IGh0dHA6Ly9wZW9w bGUuZnJlZWJzZC5vcmcvfnFpbmdsaS9hcnAtdjItcGF0Y2gtMTIyNTA4DQo+IA0KPiBJIHdpbGwg ZG8gbW9yZSB0ZXN0aW5nIGFuZCBnZXR0aW5nIHRoZSBwYXRjaCByZXZpZXdlZA0KPiBiZWZvcmUg SSBtYWtlIHRoZSBvZmZpY2lhbCBjb21taXQuIEluIHRoZSBtZWFudGltZSwNCj4gcGxlYXNlIHRy eSBpdCBvdXQgYW5kIGxldCBtZSBrbm93IGhvdyB0aGUgcGF0Y2ggd29ya3MNCj4gb3V0IGZvciB5 b3UuDQo+IA0KPiBUaGFua3MsDQo+IA0KPiAtLSBRaW5nDQo+IA0KPiANCj4gPiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IG93bmVyLWZyZWVic2QtbmV0QGZyZWVic2Qub3Jn IFttYWlsdG86b3duZXItZnJlZWJzZC0NCj4gPiBuZXRAZnJlZWJzZC5vcmddIE9uIEJlaGFsZiBP ZiBWbGFkaXNsYXYgVi4gUHJvZGFuDQo+ID4gU2VudDogV2VkbmVzZGF5LCBEZWNlbWJlciAyNCwg MjAwOCAxMTozMyBBTQ0KPiA+IFRvOiBmcmVlYnNkLWN1cnJlbnRAZnJlZWJzZC5vcmc7IGZyZWVi c2QtbmV0QGZyZWVic2Qub3JnDQo+ID4gQ2M6IGZyZWVic2QtaGFja2Vyc0BmcmVlYnNkLm9yZw0K PiA+IFN1YmplY3Q6IE9kZCBiZWhhdmlvciByb3V0ZWQNCj4gPg0KPiA+ICMgdW5hbWUgLWENCj4g PiBGcmVlQlNEIG1hcnktdGVyZXNhLlhYWFhYIDguMC1DVVJSRU5UIEZyZWVCU0QgOC4wLUNVUlJF TlQgIzA6IFdlZCBEZWMNCj4gPiAyNA0KPiA+IDA1OjA2OjU1IEVFVCAyMDA4DQo+ID4gdmxhZDEx QG1hcnktdGVyZXNhLlhYWFhYOi91c3Ivb2JqL3Vzci9zcmMvc3lzL21hcnktdGVyZXNhLjEwICBh bWQ2NA0KPiA+DQo+ID4gV2UgaGF2ZSB0d28gcHJvdmlkZXJzIG9uIHR1bjEgYW5kIHR1bjIuDQo+ ID4NCj4gPiAgPj4vZXRjL3JjLmNvbmY6DQo+ID4gLi4uDQo+ID4gZ2F0ZXdheV9lbmFibGU9IllF UyINCj4gPiByb3V0ZXI9Ii9zYmluL3JvdXRlZCINCj4gPiByb3V0ZXJfZW5hYmxlPSJZRVMiDQo+ ID4gcm91dGVyX2ZsYWdzPSItcyAtVCAvdmFyL2xvZy9yb3V0ZWQubG9nIC1QIG5vX3JpcCINCj4g PiAuLi4NCj4gPg0KPiA+ICMgbmV0c3RhdCAtcm4NCj4gPiBSb3V0aW5nIHRhYmxlcw0KPiA+DQo+ ID4gSW50ZXJuZXQ6DQo+ID4gRGVzdGluYXRpb24gICAgICAgIEdhdGV3YXkgICAgICAgICAgICBG bGFncyAgICBSZWZzICAgICAgVXNlICBOZXRpZg0KPiA+IEV4cGlyZQ0KPiA+IGRlZmF1bHQgICAg ICAgICAgICA4OS4yMDkuOTUuMjU0ICAgICAgVUdTICAgICAgICAgMCAgIDY1MzQxOCAgIHR1bjEN Cj4gPiAxMC4wLjAuMC8yNCAgICAgICAgbGluayMxICAgICAgICAgICAgIFUgICAgICAgICAgIDAg ICAgODU1OTUgICAgcmUwDQo+ID4gODUuMjM4LjEwOS42MSAgICAgIDEyNy4wLjAuMSAgICAgICAg ICBVSCAgICAgICAgICAwICAgICAgICAwICAgIGxvMA0KPiA+IDg5LjIwOS5YWC5ZWSAgICAgICAx MjcuMC4wLjEgICAgICAgICAgVUggICAgICAgICAgMCAgICAgIDQ4MyAgICBsbzANCj4gPiA4OS4y MDkuOTUuMjU0ICAgICAgODkuMjA5LlhYLllZICAgICAgIFVIICAgICAgICAgIDAgICAgICAgIDAg ICB0dW4xDQo+ID4gMTI3LjAuMC4xICAgICAgICAgIGxpbmsjNiAgICAgICAgICAgICBVSCAgICAg ICAgICAwICAgIDE5NzgxICAgIGxvMA0KPiA+IDE5Mi4xNjguMTUyLjAvMjQgICAxMC4wLjAuMjAg ICAgICAgICAgVUdTICAgICAgICAgMCAgICAgICAgMCAgICByZTANCj4gPiAxOTUuMTM4LjgwLjE2 OCAgICAgbGluayM4ICAgICAgICAgICAgIFVIICAgICAgICAgIDAgICAgICAgIDUgICB0dW4yDQo+ ID4NCj4gPiBJbnRlcm5ldDY6DQo+ID4gRGVzdGluYXRpb24gICAgICAgICAgICAgICAgICAgICAg IEdhdGV3YXkgICAgICAgICAgICAgICAgICAgICAgIEZsYWdzDQo+ID4gICBOZXRpZiBFeHBpcmUN Cj4gPiA6OjEgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbGluayM2ICAgICAgICAgICAg ICAgICAgICAgICAgVUgNCj4gPiBsbzANCj4gPiBmZTgwOjolbG8wLzY0ICAgICAgICAgICAgICAg ICAgICAgbGluayM2ICAgICAgICAgICAgICAgICAgICAgICAgVQ0KPiA+IGxvMA0KPiA+IGZmMDE6 Njo6LzMyICAgICAgICAgICAgICAgICAgICAgICBmZTgwOjoxJWxvMCAgICAgICAgICAgICAgICAg ICBVDQo+ID4gbG8wDQo+ID4gZmYwMTo3OjovMzIgICAgICAgICAgICAgICAgICAgICAgIGZlODA6 OjJlMDo0ZGZmOmZlN2I6NjkwYyV0dW4xIFVHDQo+ID4gdHVuMQ0KPiA+IGZmMDE6ODo6LzMyICAg ICAgICAgICAgICAgICAgICAgICBmZTgwOjoyZTA6NGRmZjpmZTdiOjY5MGMldHVuMiBVRw0KPiA+ IHR1bjINCj4gPiBmZjAyOjolbG8wLzMyICAgICAgICAgICAgICAgICAgICAgZmU4MDo6MSVsbzAg ICAgICAgICAgICAgICAgICAgVQ0KPiA+IGxvMA0KPiA+IGZmMDI6OiV0dW4xLzMyICAgICAgICAg ICAgICAgICAgICBmZTgwOjoyZTA6NGRmZjpmZTdiOjY5MGMldHVuMSBVRw0KPiA+IHR1bjENCj4g PiBmZjAyOjoldHVuMi8zMiAgICAgICAgICAgICAgICAgICAgZmU4MDo6MmUwOjRkZmY6ZmU3Yjo2 OTBjJXR1bjIgVUcNCj4gPiB0dW4yDQo+ID4NCj4gPg0KPiA+IEkgd291bGQgbGlrZSB0byBwdXQg c29tZSBuZXR3b3JrcyB2aWEgYSBzZWNvbmQgSVNQOg0KPiA+ICMgL3NiaW4vcm91dGUgYWRkIC1u ZXQgNzkuMTQwLjAuMC8yMCAtaWZhY2UgdHVuMg0KPiA+IGFkZCBuZXQgNzkuMTQwLjAuMDogZ2F0 ZXdheSB0dW4yDQo+ID4gIyAvc2Jpbi9yb3V0ZSBhZGQgLW5ldCA4NS4yMzguOTYuMC8xOSAtaWZh Y2UgdHVuMg0KPiA+IGFkZCBuZXQgODUuMjM4Ljk2LjA6IGdhdGV3YXkgdHVuMg0KPiA+ICMgL3Ni aW4vcm91dGUgYWRkIC1uZXQgMTk1LjEzOC42NC4wLzE5IC1pZmFjZSB0dW4yDQo+ID4gYWRkIG5l dCAxOTUuMTM4LjY0LjA6IGdhdGV3YXkgdHVuMg0KPiA+DQo+ID4gQnV0IHJvdXRlcyBkbyBub3Qg YXBwZWFyLCB0aGUgdGFibGUgcmVtYWlucyB1bmNoYW5nZWQuDQo+ID4gSW4gdGhlIGxvZ3Mgcm91 dGVkOg0KPiA+DQo+ID4gUlRNX0FERCBmcm9tIHBpZCA3MjM0OiA3OS4xNDAuMC4wIChtYXNrIDB4 ZmZmZmYwMDApIC0tPiA4NS4yMzguMTA5LjYxDQo+ID4gc3RhdGljIHJvdXRlIDc5LjE0MC4wLjAg KG1hc2sgMHhmZmZmZjAwMCkgLS0+IDg1LjIzOC4xMDkuNjENCj4gaW1wb3NzaWJseQ0KPiA+IGxh Y2tzIGlmcA0KPiA+IC0tIDExOjM1OjE2IC0tDQo+ID4gUlRNX0FERCBmcm9tIHBpZCA3MjUwOiA4 NS4yMzguOTYuMCAobWFzayAweGZmZmZlMDAwKSAtLT4NCj4gODUuMjM4LjEwOS42MQ0KPiA+IHN0 YXRpYyByb3V0ZSA4NS4yMzguOTYuMCAobWFzayAweGZmZmZlMDAwKSAtLT4gODUuMjM4LjEwOS42 MQ0KPiBpbXBvc3NpYmx5DQo+ID4gbGFja3MgaWZwDQo+ID4gLS0gMTE6MzU6MjggLS0NCj4gPiBS VE1fQUREIGZyb20gcGlkIDcyNjI6IDE5NS4xMzguNjQuMCAobWFzayAweGZmZmZlMDAwKSAtLT4N Cj4gODUuMjM4LjEwOS42MQ0KPiA+IHN0YXRpYyByb3V0ZSAxOTUuMTM4LjY0LjAgKG1hc2sgMHhm ZmZmZTAwMCkgLS0+IDg1LjIzOC4xMDkuNjENCj4gPiBpbXBvc3NpYmx5DQo+ID4gbGFja3MgaWZw DQo+ID4NCj4gPg0KPiA+IEJlZm9yZSByZWJ1aWxkIGtlcm5lbCwgaXQgYXBwZWFyZWQsIGFuZCBu b3cgdGhlcmUgaXMgbm8uDQo+ID4gSXQgaXMgbm93IGFkZGluZyByb3V0ZXM/DQo+ID4NCj4gPiBV c2luZyBnYXRlZHxxdWFnZ2F8emVicmEgZG9lcyBub3Qgb2ZmZXIuDQo+ID4NCj4gPg0KPiA+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gZnJlZWJz ZC1uZXRAZnJlZWJzZC5vcmcgbWFpbGluZyBsaXN0DQo+ID4gaHR0cDovL2xpc3RzLmZyZWVic2Qu b3JnL21haWxtYW4vbGlzdGluZm8vZnJlZWJzZC1uZXQNCj4gPiBUbyB1bnN1YnNjcmliZSwgc2Vu ZCBhbnkgbWFpbCB0byAiZnJlZWJzZC1uZXQtDQo+IHVuc3Vic2NyaWJlQGZyZWVic2Qub3JnIg0K From owner-freebsd-net@FreeBSD.ORG Fri Dec 26 21:43:04 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E95701065673; Fri, 26 Dec 2008 21:43:04 +0000 (UTC) (envelope-from vanhu@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C113E8FC0C; Fri, 26 Dec 2008 21:43:04 +0000 (UTC) (envelope-from vanhu@FreeBSD.org) Received: from freefall.freebsd.org (vanhu@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id mBQLh4gp008895; Fri, 26 Dec 2008 21:43:04 GMT (envelope-from vanhu@freefall.freebsd.org) Received: (from vanhu@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mBQLh4IQ008891; Fri, 26 Dec 2008 21:43:04 GMT (envelope-from vanhu) Date: Fri, 26 Dec 2008 21:43:04 GMT Message-Id: <200812262143.mBQLh4IQ008891@freefall.freebsd.org> To: vanhu@FreeBSD.org, freebsd-net@FreeBSD.org, vanhu@FreeBSD.org From: vanhu@FreeBSD.org Cc: Subject: Re: kern/124609: [ipsec] [panic] ipsec 'remainder too big' panic with ping -s 3989 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: Fri, 26 Dec 2008 21:43:05 -0000 Synopsis: [ipsec] [panic] ipsec 'remainder too big' panic with ping -s 3989 Responsible-Changed-From-To: freebsd-net->vanhu Responsible-Changed-By: vanhu Responsible-Changed-When: Fri Dec 26 21:42:15 UTC 2008 Responsible-Changed-Why: We are currently tracking down the same problem. http://www.freebsd.org/cgi/query-pr.cgi?pr=124609 From owner-freebsd-net@FreeBSD.ORG Sat Dec 27 12:28:43 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 01DE31065686; Sat, 27 Dec 2008 12:28:43 +0000 (UTC) (envelope-from gerald@pfeifer.com) Received: from vexpert.dbai.tuwien.ac.at (vexpert.dbai.tuwien.ac.at [128.131.111.2]) by mx1.freebsd.org (Postfix) with ESMTP id B03498FC27; Sat, 27 Dec 2008 12:28:42 +0000 (UTC) (envelope-from gerald@pfeifer.com) Received: from acrux.dbai.tuwien.ac.at (acrux [128.131.111.60]) by vexpert.dbai.tuwien.ac.at (Postfix) with ESMTP id C57AF3910F; Sat, 27 Dec 2008 13:28:40 +0100 (CET) Received: by acrux.dbai.tuwien.ac.at (Postfix, from userid 1203) id B64E710059; Sat, 27 Dec 2008 13:28:42 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by acrux.dbai.tuwien.ac.at (Postfix) with ESMTP id 9473610055; Sat, 27 Dec 2008 13:28:42 +0100 (CET) Date: Sat, 27 Dec 2008 13:28:42 +0100 (CET) From: Gerald Pfeifer To: Tijl Coosemans In-Reply-To: <200812231750.26602.tijl@ulyssis.org> Message-ID: References: <20081221125120.GO23166@droso.net> <200812221621.40722.tijl@ulyssis.org> <200812231750.26602.tijl@ulyssis.org> User-Agent: Alpine 1.99 (LSU 1142 2008-08-13) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Qing Li , "Li, Qing" , 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: Sat, 27 Dec 2008 12:28:43 -0000 On Tue, 23 Dec 2008, Tijl Coosemans wrote: >> No, the output of this command is still the same. NET_RT_DUMP obtains >> the entire L3 table and filtering for RTF_GATEWAY non-multicast >> routes have the same semantics. Those flags never apply to L2 entries. > Thanks for answering my questions. I've attached the patch for Wine. Thanks, Tijl! Are you also going to submit this patch upstream or would you prefer me to submit my (syntactically different, but equivalent) version? I'd love to see this addressed in Wine 1.1.12. Gerald From owner-freebsd-net@FreeBSD.ORG Sat Dec 27 13:58:56 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 3EF2B106564A; Sat, 27 Dec 2008 13:58:56 +0000 (UTC) (envelope-from tijl@ulyssis.org) Received: from mailrelay002.isp.belgacom.be (mailrelay002.isp.belgacom.be [195.238.6.175]) by mx1.freebsd.org (Postfix) with ESMTP id 7E4638FC0C; Sat, 27 Dec 2008 13:58:55 +0000 (UTC) (envelope-from tijl@ulyssis.org) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAHPDVUlR9NlS/2dsb2JhbACBbLsZWI8ghkQ Received: from 82.217-244-81.adsl-dyn.isp.belgacom.be (HELO kalimero.kotnet.org) ([81.244.217.82]) by relay.skynet.be with ESMTP; 27 Dec 2008 14:58:53 +0100 Received: from kalimero.kotnet.org (kalimero.kotnet.org [127.0.0.1]) by kalimero.kotnet.org (8.14.3/8.14.3) with ESMTP id mBRDwr7B004465; Sat, 27 Dec 2008 14:58:53 +0100 (CET) (envelope-from tijl@ulyssis.org) From: Tijl Coosemans To: Gerald Pfeifer Date: Sat, 27 Dec 2008 14:58:50 +0100 User-Agent: KMail/1.9.10 References: <20081221125120.GO23166@droso.net> <200812231750.26602.tijl@ulyssis.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200812271458.52492.tijl@ulyssis.org> Cc: Qing Li , "Li, Qing" , 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: Sat, 27 Dec 2008 13:58:56 -0000 On Saturday 27 December 2008 13:28:42 Gerald Pfeifer wrote: > On Tue, 23 Dec 2008, Tijl Coosemans wrote: >>> No, the output of this command is still the same. NET_RT_DUMP >>> obtains the entire L3 table and filtering for RTF_GATEWAY >>> non-multicast routes have the same semantics. Those flags never >>> apply to L2 entries. >> >> Thanks for answering my questions. I've attached the patch for Wine. > > Thanks, Tijl! Are you also going to submit this patch upstream or > would you prefer me to submit my (syntactically different, but > equivalent) version? I'd love to see this addressed in Wine 1.1.12. I was kind of waiting for the dust to settle. I didn't want to speak up because I'm no authority in this area and in the end I'm OK with any outcome, but personnaly I find special-casing {NET_RT_FLAGS,0} to retrieve the L2 entries a bit odd. Surely, letting {NET_RT_FLAGS,RTF_LLINFO} return L2 entries is exactly the same to implement, is far more descriptive, is fully backwards compatible and compatible with other sysctl operating systems like the other BSDs and Mac OS X, which helps portability. AFAIK, the other use of RTF_LLINFO was to filter out L2 entries from the entire L2+L3 routing table to obtain just the L3 entries. Because the L2 and L3 table have been separated this filtering isn't needed anymore, but what harm would it do to reintroduce RTF_LLINFO? The filtering code would become a useless no-op, but you'd stay fully compatible, again both backwards and with other operating systems. I just think that removing RTF_LLINFO was a bit too aggressive an optimisation with little advantage and too many disadvantages and I'd like to see it return. From owner-freebsd-net@FreeBSD.ORG Sat Dec 27 20:47:56 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 D3CF71065676 for ; Sat, 27 Dec 2008 20:47:56 +0000 (UTC) (envelope-from qingli@speakeasy.net) Received: from mail4.sea5.speakeasy.net (mail4.sea5.speakeasy.net [69.17.117.6]) by mx1.freebsd.org (Postfix) with ESMTP id B1CB98FC1E for ; Sat, 27 Dec 2008 20:47:56 +0000 (UTC) (envelope-from qingli@speakeasy.net) Received: (qmail 12277 invoked from network); 27 Dec 2008 20:21:15 -0000 Received: from dsl081-051-194.sfo1.dsl.speakeasy.net (HELO qm8nwm5acsx) ([64.81.51.194]) (envelope-sender ) by mail4.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 27 Dec 2008 20:21:15 -0000 From: "Qing Li" To: "'Tijl Coosemans'" , "'Gerald Pfeifer'" Date: Sat, 27 Dec 2008 12:21:25 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <200812271458.52492.tijl@ulyssis.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AcloK0Nf0n7CsmqYRgyE2M14UKtkGQAL8eAg Message-Id: <20081227204756.B1CB98FC1E@mx1.freebsd.org> Cc: '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: Sat, 27 Dec 2008 20:47:56 -0000 Right now I am also a bit leaning towards reintroducing the RTF_LLINFO flag bit. This is mainly due to the recent discovery of the "route" command issued with the "-iface/-interface" option, which conflicts with the way how "arp" and "ndp" is handled in the kernel. I renamed this flag bit to RTF_LLDATA because only the "arp" and "ndp" commands need it. > > I didn't want to speak up because I'm no authority in this > area and in the end I'm OK with any outcome, but personnaly I > find special-casing {NET_RT_FLAGS,0} to retrieve the L2 > entries a bit odd. > As I've indicated previously, a few ports already have the #ifdef RTF_LLINFO block around the sysctl() setup code. Perhaps it's because these ports (such as Wine) run on OS that does not support RTF_LLINFO (e.g. Linux?) ? > > Surely, letting {NET_RT_FLAGS,RTF_LLINFO} > return L2 entries is exactly the same to implement, is far > more descriptive, is fully backwards compatible and > compatible with other sysctl operating systems like the other > BSDs and Mac OS X, which helps portability. > I believe all of the affected ports have been updated to include the conditional blocks around RTF_LLINFO. So there is still a level of compatibility, right ? > > AFAIK, the other use of RTF_LLINFO was to filter out L2 > entries from the entire L2+L3 routing table to obtain just > the L3 entries. Because the L2 and L3 table have been > separated this filtering isn't needed anymore, but what harm > would it do to reintroduce RTF_LLINFO? The filtering code > would become a useless no-op, but you'd stay fully > compatible, again both backwards and with other operating systems. > > I just think that removing RTF_LLINFO was a bit too > aggressive an optimisation with little advantage and too many > disadvantages and I'd like to see it return. > I believe examining the impacts of RTF_LLINFO on the ports was a good exercise even if we have to rejuvenate it. I hope we could reach a consensus soon now that we have more input from the ports developers. Please provide your input ... -- Qing From owner-freebsd-net@FreeBSD.ORG Sat Dec 27 22:54:36 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 46D4B1065673 for ; Sat, 27 Dec 2008 22:54:36 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outE.internet-mail-service.net (oute.internet-mail-service.net [216.240.47.228]) by mx1.freebsd.org (Postfix) with ESMTP id 29AC48FC17 for ; Sat, 27 Dec 2008 22:54:36 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id A70302344; Sat, 27 Dec 2008 14:54:35 -0800 (PST) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 25C412D6004; Sat, 27 Dec 2008 14:54:35 -0800 (PST) Message-ID: <4956B22A.6080109@elischer.org> Date: Sat, 27 Dec 2008 14:54:34 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Qing Li References: <20081227204756.B58938FC1F@mx1.freebsd.org> In-Reply-To: <20081227204756.B58938FC1F@mx1.freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'Tijl Coosemans' , freebsd-net@freebsd.org, 'Gerald Pfeifer' , freebsd-current@freebsd.org, 'Qing Li' 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: Sat, 27 Dec 2008 22:54:36 -0000 Qing Li wrote: > > > I believe examining the impacts of RTF_LLINFO on the ports > was a good exercise even if we have to rejuvenate it. > > I hope we could reach a consensus soon now that we have more > input from the ports developers. > > Please provide your input ... reintroduce it with value 0 then teh optimiser should remove dead code... > > -- Qing > > > > > > > > > > > > From owner-freebsd-net@FreeBSD.ORG Sat Dec 27 23:06:26 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 B2BE11065673; Sat, 27 Dec 2008 23:06:26 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail17.syd.optusnet.com.au (mail17.syd.optusnet.com.au [211.29.132.198]) by mx1.freebsd.org (Postfix) with ESMTP id 476F68FC14; Sat, 27 Dec 2008 23:06:26 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c122-106-215-175.belrs3.nsw.optusnet.com.au [122.106.215.175]) by mail17.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id mBRN6DAR031395 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 28 Dec 2008 10:06:21 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.3/8.14.3) with ESMTP id mBRN6Dlo064388; Sun, 28 Dec 2008 10:06:13 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.3/8.14.3/Submit) id mBRN6D4C064387; Sun, 28 Dec 2008 10:06:13 +1100 (EST) (envelope-from peter) Date: Sun, 28 Dec 2008 10:06:13 +1100 From: Peter Jeremy To: Julian Elischer Message-ID: <20081227230613.GB64280@server.vk2pj.dyndns.org> References: <20081227204756.B58938FC1F@mx1.freebsd.org> <4956B22A.6080109@elischer.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gj572EiMnwbLXET9" Content-Disposition: inline In-Reply-To: <4956B22A.6080109@elischer.org> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.18 (2008-05-17) Cc: 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: Sat, 27 Dec 2008 23:06:26 -0000 --gj572EiMnwbLXET9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2008-Dec-27 14:54:34 -0800, Julian Elischer wrote: >Qing Li wrote: >> I believe examining the impacts of RTF_LLINFO on the ports=20 >> was a good exercise even if we have to rejuvenate it. > >reintroduce it with value 0 And a comment indicating that the definition of RTF_LLINFO is solely for backward compatibility. (To make it clear why it's never referenced in the base system and not needed for new code). --=20 Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. --gj572EiMnwbLXET9 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAklWtOUACgkQ/opHv/APuIcUPgCggEZmSjLwsLBG0x1ne4Xkarkq 9GgAn2Od0X9ZR5ncG47XRILQRZ7TMp++ =MIxA -----END PGP SIGNATURE----- --gj572EiMnwbLXET9-- From owner-freebsd-net@FreeBSD.ORG Sat Dec 27 23:07:28 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 CC7721065673; Sat, 27 Dec 2008 23:07:28 +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 A4DAA8FC19; Sat, 27 Dec 2008 23:07:28 +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 mBRN7RwG091538 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 27 Dec 2008 15:07:27 -0800 (PST) (envelope-from sam@freebsd.org) Message-ID: <4956B52F.2070300@freebsd.org> Date: Sat, 27 Dec 2008 15:07:27 -0800 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.18 (X11/20081209) MIME-Version: 1.0 To: Julian Elischer References: <20081227204756.B58938FC1F@mx1.freebsd.org> <4956B22A.6080109@elischer.org> In-Reply-To: <4956B22A.6080109@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-sonic.net-Metrics: ebb.errno.com; whitelist Cc: Qing Li , freebsd-net@freebsd.org, 'Gerald Pfeifer' , freebsd-current@freebsd.org, 'Tijl Coosemans' 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: Sat, 27 Dec 2008 23:07:28 -0000 Julian Elischer wrote: > Qing Li wrote: >> >> >> I believe examining the impacts of RTF_LLINFO on the ports was a good >> exercise even if we have to rejuvenate it. >> >> I hope we could reach a consensus soon now that we have more input >> from the ports developers. >> >> Please provide your input ... > > reintroduce it with value 0 > then teh optimiser should remove dead code... > The worry is that this will cause subtle bugs when code assumes functionality is present. We tried yanking this entirely and it's obviously caused some issues. The question now is whether to follow through and accept an incompatibility or put back sufficient compatibility to enable legacy code to work unchanged. Sam