From owner-freebsd-net@FreeBSD.ORG Sun Sep 19 04:11:53 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E493316A4D1 for ; Sun, 19 Sep 2004 04:11:51 +0000 (GMT) Received: from mailout2.barnet.com.au (mailout2.barnet.com.au [218.185.88.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id D3D2A43D46 for ; Sun, 19 Sep 2004 04:11:50 +0000 (GMT) (envelope-from edwin@mavetju.org) Received: by mailout2.barnet.com.au (Postfix, from userid 27) id 8C521707484; Sun, 19 Sep 2004 14:11:49 +1000 (EST) X-Viruscan-Id: <414D07050000D4AF6AE7AD@BarNet> Received: from mail2-auth.barnet.com.au (localhost.barnet.com.au [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) Authority" (verified OK)) by mail2.barnet.com.au (Postfix) with ESMTP id 2EDC1707485 for ; Sun, 19 Sep 2004 14:11:49 +1000 (EST) Received: from k7.mavetju (edwin-3.int.barnet.com.au [10.10.12.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) Certificate Authority" (verified OK)) by mail2-auth.barnet.com.au (Postfix) with ESMTP id 3B087707483 for ; Sun, 19 Sep 2004 14:11:48 +1000 (EST) Received: by k7.mavetju (Postfix, from userid 1001) id 068A261B1; Sun, 19 Sep 2004 14:11:46 +1000 (EST) Date: Sun, 19 Sep 2004 14:11:46 +1000 From: Edwin Groothuis To: freebsd-net@freebsd.org Message-ID: <20040919041146.GA32274@k7.mavetju> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i Subject: ospf / gif / packets not pushed into gif tunnel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 19 Sep 2004 04:11:53 -0000 Hello, I'm trying to get dynamic routing working between two private networks. A gif tunnel is created between the two networks. The central server (FreeBSD 4.8) has 10.10.12.1/32 on its side of the tunnel, the remote (FreeBSD 5.2.1.) has 10.10.12.2/32 on its side of the tunnel. Static routes are added on both sides to point to the other networks. This works fine. If I remove the static routes and start running an OSPF daemon on both sides (using quagga), things start working out strange. This part is working: - OSPF information is exchanged. - The routing table is updated. But the moment this is done, the other side of the tunnel isn't reachable anymore (as in: no answers to my icmp echos). Running tcpdump on different places show me: gif-interface on server: 13:28:30.220792 10.10.12.1 > 10.10.12.2: icmp: echo request fxp-interface on server: 13:28:30.291934 IP 218.185.88.254 > 192.168.1.1: IP 10.10.12.1 > 10.10.12.2: icmp 64: echo request seq 512 (ipip-proto-4) fxp-interface on remote: 13:28:30.220823 218.185.88.254 > 203.111.122.2: 10.10.12.1 > 10.10.12.2: icmp: echo request (ipip-proto-4) gif-interface on remote: nothing The absence of output on the gif tunnel got me a little bit worried. Then I saw something else: my routing table is sometimes full (114 entries, directly connected and OSPF) and sometimes it's empty (only directly connected interfaces). This is all in 40 seconds intervals which make me believe its related to OSPF hello timeouts. I compared the routing tables and only saw this as the difference: Destination Gateway Flags Refs Use Netif empty: 10.10.12.1 10.10.12.2 UH 0 2957 gif1 full : 10.10.12.1 10.10.12.2 UH 99 2957 gif1 10.10.12.1 is the other side of the tunnel. The 99 isn't a stuck value, if I add more routes in the central network it will go up to 100, 101, 102 etc. With the nearly empty routing table, all traffic towards "the other side of the tunnel" goes happily via the fxp0 on to the internet... With the full routing table, all traffic towards "the other side of the tunnel" goes happily over the gif1 tunnel to the other side, but the answers are although received on this side never appear in this end of the gif1 tunnel: fxp0: 13:59:23.291934 IP 218.185.88.254 > 192.168.1.1: IP 10.10.10.3 > 10.10.12.2: icmp 64: echo reply seq 743 (ipip-proto-4) 13:59:24.256239 IP 192.168.1.1 > 218.185.88.254: IP 10.10.12.2 > 10.10.10.3: icmp 64: echo request seq 744 (ipip-proto-4) 13:59:24.350126 IP 218.185.88.254 > 192.168.1.1: IP 10.10.10.3 > 10.10.12.2: icmp 64: echo reply seq 744 (ipip-proto-4) 13:59:25.265971 IP 192.168.1.1 > 218.185.88.254: IP 10.10.12.2 > 10.10.10.3: icmp 64: echo request seq 745 (ipip-proto-4) 13:59:25.335384 IP 218.185.88.254 > 192.168.1.1: IP 10.10.10.3 > 10.10.12.2: icmp 64: echo reply seq 745 (ipip-proto-4) 13:59:26.276325 IP 192.168.1.1 > 218.185.88.254: IP 10.10.12.2 > 10.10.10.3: icmp 64: echo request seq 746 (ipip-proto-4) gif1: 13:59:23.246677 IP 10.10.12.2 > 10.10.10.3: icmp 64: echo request seq 743 13:59:24.256193 IP 10.10.12.2 > 10.10.10.3: icmp 64: echo request seq 744 13:59:25.265928 IP 10.10.12.2 > 10.10.10.3: icmp 64: echo request seq 745 13:59:26.276274 IP 10.10.12.2 > 10.10.10.3: icmp 64: echo request seq 746 Does anybody know a good reason why a packet arrived for a gif-tunnel doesn't get delivered properly into the gif-tunnel, depending on the size of the routing table? More information can be supplied if required. Edwin -- Edwin Groothuis | Personal website: http://www.mavetju.org edwin@mavetju.org | Weblog: http://weblog.barnet.com.au/edwin/ From owner-freebsd-net@FreeBSD.ORG Sun Sep 19 04:30:14 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2557C16A4CF for ; Sun, 19 Sep 2004 04:30:14 +0000 (GMT) Received: from mailout2.barnet.com.au (mailout2.barnet.com.au [218.185.88.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF54B43D2F for ; Sun, 19 Sep 2004 04:30:13 +0000 (GMT) (envelope-from edwin@mavetju.org) Received: by mailout2.barnet.com.au (Postfix, from userid 27) id 124F5707485; Sun, 19 Sep 2004 14:30:13 +1000 (EST) X-Viruscan-Id: <414D0B54000102E5C339FE@BarNet> Received: from mail2-auth.barnet.com.au (localhost.barnet.com.au [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) Authority" (verified OK)) by mail2.barnet.com.au (Postfix) with ESMTP id 97E57707484 for ; Sun, 19 Sep 2004 14:30:12 +1000 (EST) Received: from k7.mavetju (edwin-3.int.barnet.com.au [10.10.12.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) Certificate Authority" (verified OK)) by mail2-auth.barnet.com.au (Postfix) with ESMTP id 12EC7707483 for ; Sun, 19 Sep 2004 14:30:12 +1000 (EST) Received: by k7.mavetju (Postfix, from userid 1001) id 157F461B4; Sun, 19 Sep 2004 14:30:11 +1000 (EST) Date: Sun, 19 Sep 2004 14:30:11 +1000 From: Edwin Groothuis To: freebsd-net@freebsd.org Message-ID: <20040919043011.GA22566@k7.mavetju> References: <20040919041146.GA32274@k7.mavetju> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040919041146.GA32274@k7.mavetju> User-Agent: Mutt/1.5.6i Subject: Re: ospf / gif / packets not pushed into gif tunnel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 19 Sep 2004 04:30:14 -0000 On Sun, Sep 19, 2004 at 02:11:46PM +1000, Edwin Groothuis wrote: > gif-interface on server: > 13:28:30.220792 10.10.12.1 > 10.10.12.2: icmp: echo request > fxp-interface on server: > 13:28:30.291934 IP 218.185.88.254 > 192.168.1.1: IP 10.10.12.1 > 10.10.12.2: icmp 64: echo request seq 512 (ipip-proto-4) > > fxp-interface on remote: > 13:28:30.220823 218.185.88.254 > 203.111.122.2: 10.10.12.1 > 10.10.12.2: icmp: echo request (ipip-proto-4) > gif-interface on remote: > nothing The two fxp-interfaces are swapped. It should be: gif-interface on server: 13:28:30.220792 10.10.12.1 > 10.10.12.2: icmp: echo request fxp-interface on server: 13:28:30.220823 218.185.88.254 > 203.111.122.2: 10.10.12.1 > 10.10.12.2: icmp: echo request (ipip-proto-4) fxp-interface on remote: 13:28:30.291934 IP 218.185.88.254 > 192.168.1.1: IP 10.10.12.1 > 10.10.12.2: icmp 64: echo request seq 512 (ipip-proto-4) gif-interface on remote: nothing Edwi -- Edwin Groothuis | Personal website: http://www.mavetju.org edwin@mavetju.org | Weblog: http://weblog.barnet.com.au/edwin/ From owner-freebsd-net@FreeBSD.ORG Sun Sep 19 21:53:21 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1C10016A4CE for ; Sun, 19 Sep 2004 21:53:21 +0000 (GMT) Received: from smtp1.jazztel.es (smtp1.jazztel.es [62.14.3.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id C828843D31 for ; Sun, 19 Sep 2004 21:53:20 +0000 (GMT) (envelope-from josemi@freebsd.jazztel.es) Received: from antivirus by smtp1.jazztel.es with antivirus id 1C99cn-00028k-00 for net@freebsd.org Sun, 19 Sep 2004 23:53:37 +0200 Received: from [212.106.207.12] (helo=rguez.homeunix.net) by smtp1.jazztel.es with esmtp id 1C99cn-000287-00 for net@freebsd.org Sun, 19 Sep 2004 23:53:37 +0200 Received: from localhost.redesjm.local (orion.redesjm.local [192.168.254.16]) by rguez.homeunix.net (8.13.1/8.13.1) with ESMTP id i8JLrI3s063851 for ; Sun, 19 Sep 2004 23:53:18 +0200 (CEST) (envelope-from josemi@freebsd.jazztel.es) To: net@freebsd.org Date: Sun, 19 Sep 2004 23:53:18 +0200 From: "Jose M Rodriguez" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: User-Agent: Opera M2/7.54 (FreeBSD, build 751) X-AntiVirus: checked by AntiVir Milter 1.1-beta; AVE 6.27.0.11; VDF 6.27.0.67 (host: antares.redesjm.local) X-Virus-Scanned: by antivirus Subject: X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 19 Sep 2004 21:53:21 -0000 Can someone take a look on PR bin/67550? The protocol correctness maybe not important, but the tftp blocksize option speed up our net boots a lot. thanks in advance, -- josemi -- Using Opera's revolutionary e-mail client: http://www.opera.com/m2/ From owner-freebsd-net@FreeBSD.ORG Mon Sep 20 00:51:53 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1DDE716A4CE; Mon, 20 Sep 2004 00:51:53 +0000 (GMT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC23043D2F; Mon, 20 Sep 2004 00:51:52 +0000 (GMT) (envelope-from max@love2party.net) Received: from [212.227.126.155] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1C9CPH-0007iV-00; Mon, 20 Sep 2004 02:51:51 +0200 Received: from [217.227.156.246] (helo=donor.laier.local) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1C9CPH-0007Jw-00; Mon, 20 Sep 2004 02:51:51 +0200 From: Max Laier To: freebsd-arch@freebsd.org Date: Mon, 20 Sep 2004 02:50:40 +0200 User-Agent: KMail/1.7 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3113315.aWgR6iTeVk"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200409200250.49518.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:61c499deaeeba3ba5be80f48ecc83056 cc: freebsd-hackers@freebsd.org cc: freebsd-standards@freebsd.org cc: freebsd-net@freebsd.org Subject: Global (non _KERNEL) place for sockaddr_union? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 20 Sep 2004 00:51:53 -0000 --nextPart3113315.aWgR6iTeVk Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/71836 is the symptom. Now= I am=20 looking for a clean solution to it. What is needed is an include file that= =20 defines union sockaddr_union in a way that is useable from kernel and=20 userland. Historically it seems that this union first apeared in context of= =20 ipsec within the kernel. pf has adopted it, but uses it in the userland as= =20 well. I am sure that it can be usefull in a lot of places that have to deal= =20 with/store different address formats. My question now is, what would be a good place to define this? Are there an= y=20 fromal standarts that might define it already? (Couldn't find anything) Is= =20 there anything else that I must consider? At some point I though netinet/in.h might be a good place, but that'd requi= re=20 inclusion of sys/socket.h, which certainly is not a good solution. Opinions? Ideas? > #include > #include >=20 > union sockaddr_union { > struct sockaddr sa; > struct sockaddr_in sin; > struct sockaddr_in6 sin6; > struct sockaddr_storage __su_pad; /* maybe not a bad idea */ > }; =46reeBSD: netipsec/keydb.h, line 43 (_KERNEL) NetBSD: netipsec/keydb.h, line 46 (_KERNEL) OpenBSD: netinet/ip_ipsp.h, line 50 (non _KERNEL) KAME: net/pfvar.h, line 699 (non _KERNEL, ! __OpenBSD__) Linux: Doesn't seem to have it. Or has it under a different name? =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart3113315.aWgR6iTeVk Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBBTilpXyyEoT62BG0RAmpDAJ9IVZ1sV1GhHYyMXaAIx2hBZ9Bo1QCfaIYn XH9Pl7Y8VcPBVr9kgjdhvc8= =QH3p -----END PGP SIGNATURE----- --nextPart3113315.aWgR6iTeVk-- From owner-freebsd-net@FreeBSD.ORG Mon Sep 20 02:26:56 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D3C5116A4CE; Mon, 20 Sep 2004 02:26:56 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id B033843D2F; Mon, 20 Sep 2004 02:26:56 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id i8K2SqAq027289; Sun, 19 Sep 2004 19:28:52 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id i8K2SqpY027288; Sun, 19 Sep 2004 19:28:52 -0700 Date: Sun, 19 Sep 2004 19:28:52 -0700 From: Brooks Davis To: Max Laier Message-ID: <20040920022852.GA21281@odin.ac.hmc.edu> References: <200409200250.49518.max@love2party.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3MwIy2ne0vdjdPXF" Content-Disposition: inline In-Reply-To: <200409200250.49518.max@love2party.net> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=3.0 required=8.0 tests=SUSPICIOUS_RECIPS autolearn=no version=2.63 X-Spam-Level: *** X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: freebsd-hackers@freebsd.org cc: freebsd-net@freebsd.org cc: freebsd-standards@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: Global (non _KERNEL) place for sockaddr_union? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 20 Sep 2004 02:26:57 -0000 --3MwIy2ne0vdjdPXF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 20, 2004 at 02:50:40AM +0200, Max Laier wrote: > Hi, >=20 > http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/71836 is the symptom. N= ow I am=20 > looking for a clean solution to it. What is needed is an include file tha= t=20 > defines union sockaddr_union in a way that is useable from kernel and=20 > userland. Historically it seems that this union first apeared in context = of=20 > ipsec within the kernel. pf has adopted it, but uses it in the userland a= s=20 > well. I am sure that it can be usefull in a lot of places that have to de= al=20 > with/store different address formats. >=20 > My question now is, what would be a good place to define this? Are there = any=20 > fromal standarts that might define it already? (Couldn't find anything) I= s=20 > there anything else that I must consider? >=20 > At some point I though netinet/in.h might be a good place, but that'd req= uire=20 > inclusion of sys/socket.h, which certainly is not a good solution. >=20 > Opinions? Ideas? >=20 > > #include > > #include > >=20 > > union sockaddr_union { > > struct sockaddr sa; > > struct sockaddr_in sin; > > struct sockaddr_in6 sin6; > > struct sockaddr_storage __su_pad; /* maybe not a bad idea */ > > }; I don't see an elegant solution. Stuffing it off in its own file may be the best thing if you're going to use it. Overall, I'd say it's bad idea that PF be better off without. It appears to save a few casts, but nothing worth the pain of generalizing the declaration. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --3MwIy2ne0vdjdPXF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBTkBkXY6L6fI4GtQRAkN5AJ4vSbihrYfqgTxU4MrgF4vNXFYr6ACeJ0Uh aeCoFMPqPGpWIYLi5DDzc4c= =WKvT -----END PGP SIGNATURE----- --3MwIy2ne0vdjdPXF-- From owner-freebsd-net@FreeBSD.ORG Mon Sep 20 03:40:54 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 784C016A4CE; Mon, 20 Sep 2004 03:40:54 +0000 (GMT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.185]) by mx1.FreeBSD.org (Postfix) with ESMTP id AE95643D54; Mon, 20 Sep 2004 03:40:53 +0000 (GMT) (envelope-from max@love2party.net) Received: from [212.227.126.179] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1C9F2o-0002Lr-00; Mon, 20 Sep 2004 05:40:50 +0200 Received: from [217.227.156.246] (helo=donor.laier.local) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1C9F2n-0007vz-00; Mon, 20 Sep 2004 05:40:50 +0200 From: Max Laier To: Brooks Davis Date: Mon, 20 Sep 2004 05:39:38 +0200 User-Agent: KMail/1.7 References: <200409200250.49518.max@love2party.net> <20040920022852.GA21281@odin.ac.hmc.edu> In-Reply-To: <20040920022852.GA21281@odin.ac.hmc.edu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3010729.AUYAN69HKC"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200409200539.48073.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:61c499deaeeba3ba5be80f48ecc83056 cc: freebsd-hackers@freebsd.org cc: freebsd-net@freebsd.org cc: freebsd-standards@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: Global (non _KERNEL) place for sockaddr_union? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 20 Sep 2004 03:40:54 -0000 --nextPart3010729.AUYAN69HKC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 20 September 2004 04:28, Brooks Davis wrote: > On Mon, Sep 20, 2004 at 02:50:40AM +0200, Max Laier wrote: > > Hi, > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/71836 is the symptom.= Now > > I am looking for a clean solution to it. What is needed is an include > > file that defines union sockaddr_union in a way that is useable from > > kernel and userland. Historically it seems that this union first apeared > > in context of ipsec within the kernel. pf has adopted it, but uses it in > > the userland as well. I am sure that it can be usefull in a lot of plac= es > > that have to deal with/store different address formats. > > > > My question now is, what would be a good place to define this? Are there > > any fromal standarts that might define it already? (Couldn't find > > anything) Is there anything else that I must consider? > > > > At some point I though netinet/in.h might be a good place, but that'd > > require inclusion of sys/socket.h, which certainly is not a good > > solution. > > > > Opinions? Ideas? > > > > > #include > > > #include > > > > > > union sockaddr_union { > > > struct sockaddr sa; > > > struct sockaddr_in sin; > > > struct sockaddr_in6 sin6; > > > struct sockaddr_storage __su_pad; /* maybe not a bad idea */ > > > }; > > I don't see an elegant solution. Stuffing it off in its own file may > be the best thing if you're going to use it. Overall, I'd say it's bad > idea that PF be better off without. It appears to save a few casts, > but nothing worth the pain of generalizing the declaration. > > -- Brooks =46irst of all, the padding is bogus as sin6 is big enough. Especially sinc= e one=20 point here is to save space. I was a bit confused there, sorry. Especially= =20 since this is an important point: In pf this union is uses to - for example= -=20 store address information in tables. It allows to store IPv4 and IPv6=20 addresses in the same table without creating overhead in the memory footpri= nt=20 or having to deal with different objects for every address type. The fewer= =20 casts are just an additional benefit. Maybe you are right and a new header is the easiest way out. Moving this ou= t=20 of under _KERNEL would require all includer of netipsec/keydb.h to include= =20 sys/socket.h and netinet/in.h. As I was saying, I don't have a good idea=20 either. The only thing that came to my mind just now is to add a protecting= =20 define and #ifdef around the two places that define it. But I have no idea= =20 how clean (in terms of style) such a solution is. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart3010729.AUYAN69HKC Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBBTlEEXyyEoT62BG0RAr9TAJ42DYbnMVi2Cgj9TICFk7YXCo0YFgCfQdyg ORVq+9JZZUGaOxLFYXMf82U= =cYA3 -----END PGP SIGNATURE----- --nextPart3010729.AUYAN69HKC-- From owner-freebsd-net@FreeBSD.ORG Mon Sep 20 04:22:20 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2F71A16A4CE; Mon, 20 Sep 2004 04:22:20 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id D5D7F43D39; Mon, 20 Sep 2004 04:22:19 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id i8K4OHI6010640; Sun, 19 Sep 2004 21:24:17 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id i8K4OHbu010635; Sun, 19 Sep 2004 21:24:17 -0700 Date: Sun, 19 Sep 2004 21:24:17 -0700 From: Brooks Davis To: Max Laier Message-ID: <20040920042417.GB9460@odin.ac.hmc.edu> References: <200409200250.49518.max@love2party.net> <20040920022852.GA21281@odin.ac.hmc.edu> <200409200539.48073.max@love2party.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GRPZ8SYKNexpdSJ7" Content-Disposition: inline In-Reply-To: <200409200539.48073.max@love2party.net> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: freebsd-hackers@freebsd.org cc: freebsd-net@freebsd.org cc: freebsd-standards@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: Global (non _KERNEL) place for sockaddr_union? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 20 Sep 2004 04:22:20 -0000 --GRPZ8SYKNexpdSJ7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 20, 2004 at 05:39:38AM +0200, Max Laier wrote: > On Monday 20 September 2004 04:28, Brooks Davis wrote: > > On Mon, Sep 20, 2004 at 02:50:40AM +0200, Max Laier wrote: > > > Hi, > > > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/71836 is the sympto= m. Now > > > I am looking for a clean solution to it. What is needed is an include > > > file that defines union sockaddr_union in a way that is useable from > > > kernel and userland. Historically it seems that this union first apea= red > > > in context of ipsec within the kernel. pf has adopted it, but uses it= in > > > the userland as well. I am sure that it can be usefull in a lot of pl= aces > > > that have to deal with/store different address formats. > > > > > > My question now is, what would be a good place to define this? Are th= ere > > > any fromal standarts that might define it already? (Couldn't find > > > anything) Is there anything else that I must consider? > > > > > > At some point I though netinet/in.h might be a good place, but that'd > > > require inclusion of sys/socket.h, which certainly is not a good > > > solution. > > > > > > Opinions? Ideas? > > > > > > > #include > > > > #include > > > > > > > > union sockaddr_union { > > > > struct sockaddr sa; > > > > struct sockaddr_in sin; > > > > struct sockaddr_in6 sin6; > > > > struct sockaddr_storage __su_pad; /* maybe not a bad idea */ > > > > }; > > > > I don't see an elegant solution. Stuffing it off in its own file may > > be the best thing if you're going to use it. Overall, I'd say it's bad > > idea that PF be better off without. It appears to save a few casts, > > but nothing worth the pain of generalizing the declaration. >=20 > First of all, the padding is bogus as sin6 is big enough. Especially sinc= e one=20 > point here is to save space. I was a bit confused there, sorry. Especiall= y=20 > since this is an important point: In pf this union is uses to - for examp= le -=20 > store address information in tables. It allows to store IPv4 and IPv6=20 > addresses in the same table without creating overhead in the memory footp= rint=20 > or having to deal with different objects for every address type. The fewe= r=20 > casts are just an additional benefit. > > Maybe you are right and a new header is the easiest way out. Moving this = out=20 > of under _KERNEL would require all includer of netipsec/keydb.h to includ= e=20 > sys/socket.h and netinet/in.h. As I was saying, I don't have a good idea= =20 > either. The only thing that came to my mind just now is to add a protecti= ng=20 > define and #ifdef around the two places that define it. But I have no ide= a=20 > how clean (in terms of style) such a solution is. If it's primairly for well defined storage, why not remove the sa and put it in netinet/in.h? If you're just looking for the family and length, it doesn't matter if you access it as .sa, .sin, or .sin6. You might have to name it something else which could be problematic for portability, but it might be worth the pain if you could push it back to OpenBSD. -- Brooks -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --GRPZ8SYKNexpdSJ7 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBTltvXY6L6fI4GtQRApA7AKC4bgZvLAzTVpzVhHVfXEwQd+JWtACgrBrG wdii84flDaNUq1uEym+j+Ms= =P8eR -----END PGP SIGNATURE----- --GRPZ8SYKNexpdSJ7-- From owner-freebsd-net@FreeBSD.ORG Mon Sep 20 11:02:13 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C210116A4D6 for ; Mon, 20 Sep 2004 11:02:13 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id B992043D4C for ; Mon, 20 Sep 2004 11:02:13 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.11/8.12.11) with ESMTP id i8KB2Dw6001438 for ; Mon, 20 Sep 2004 11:02:13 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id i8KB2CDN001432 for freebsd-net@freebsd.org; Mon, 20 Sep 2004 11:02:12 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 20 Sep 2004 11:02:12 GMT Message-Id: <200409201102.i8KB2CDN001432@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Subject: Current problem reports assigned to you X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 20 Sep 2004 11:02:13 -0000 Current FreeBSD problem reports Critical problems Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2002/07/26] kern/41007 net overfull traffic on third and fourth adap o [2002/10/21] kern/44355 net After deletion of an IPv6 alias, the rout o [2003/10/14] kern/57985 net [patch] Missing splx in ether_output_fram 3 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2001/02/08] kern/24959 net proper TCP_NOPUSH/TCP_CORK compatibility o [2003/07/11] kern/54383 net [nfs] [patch] NFS root configurations wit 2 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Sep 20 19:09:04 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1999516A4CE for ; Mon, 20 Sep 2004 19:09:04 +0000 (GMT) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id BBFC943D55 for ; Mon, 20 Sep 2004 19:09:03 +0000 (GMT) (envelope-from mikehavard@gmail.com) Received: by mproxy.gmail.com with SMTP id 79so1295783rnk for ; Mon, 20 Sep 2004 12:09:00 -0700 (PDT) Received: by 10.38.74.50 with SMTP id w50mr1822681rna; Mon, 20 Sep 2004 12:08:59 -0700 (PDT) Received: by 10.38.79.77 with HTTP; Mon, 20 Sep 2004 12:08:58 -0700 (PDT) Message-ID: <71b668fd040920120854fbe7b4@mail.gmail.com> Date: Mon, 20 Sep 2004 12:08:58 -0700 From: Mike Havard To: freebsd-net@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Mike Havard List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Sep 2004 19:09:04 -0000 From owner-freebsd-net@FreeBSD.ORG Mon Sep 20 19:57:41 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0E5CE16A4CE; Mon, 20 Sep 2004 19:57:41 +0000 (GMT) Received: from silver.he.iki.fi (helenius.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id D603C43D41; Mon, 20 Sep 2004 19:57:39 +0000 (GMT) (envelope-from pete@he.iki.fi) Received: from [193.64.42.134] (h86.vuokselantie10.fi [193.64.42.134]) by silver.he.iki.fi (8.12.10/8.11.4) with ESMTP id i8KJvbm1007926; Mon, 20 Sep 2004 22:57:37 +0300 (EEST) (envelope-from pete@he.iki.fi) Message-ID: <414F3636.1040807@he.iki.fi> Date: Mon, 20 Sep 2004 22:57:42 +0300 From: Petri Helenius User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andre Oppermann References: <20040905121111.GA78276@cell.sick.ru> <4140834C.3000306@freebsd.org> <20040909171018.GA11540@cell.sick.ru> <4140A8F5.92E4A2DF@freebsd.org> In-Reply-To: <4140A8F5.92E4A2DF@freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: Gleb Smirnoff cc: net@freebsd.org Subject: pfil question X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 20 Sep 2004 19:57:41 -0000 Andre Oppermann wrote: >BTW: You may be better off using pfil_hooks instead of netgraph for your >tool. You'll save one m_copym and m_freem for each packet. > > > Is pfil zero copy or one copy by default? If the driver supports it, does a packet get directly DMA'd in mbufs and passed over the pf which then drops the packet if applicable? Also, did the locking work for network stack in 5.3 make pf fully parallel so packets arriving can be processed by multiple CPU's? Do these need to be coming in from multiple interfaces or can even packets from one interface be distributed among multiple CPU's? Pete From owner-freebsd-net@FreeBSD.ORG Mon Sep 20 20:53:10 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D30CA16A4CE for ; Mon, 20 Sep 2004 20:53:10 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B06643D41 for ; Mon, 20 Sep 2004 20:53:10 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 41634 invoked from network); 20 Sep 2004 20:47:28 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 20 Sep 2004 20:47:28 -0000 Message-ID: <414F433F.97A1A789@freebsd.org> Date: Mon, 20 Sep 2004 22:53:19 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Petri Helenius References: <20040905121111.GA78276@cell.sick.ru> <4140834C.3000306@freebsd.org> <20040909171018.GA11540@cell.sick.ru> <4140A8F5.92E4A2DF@freebsd.org> <414F3636.1040807@he.iki.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: Gleb Smirnoff cc: net@freebsd.org Subject: Re: pfil question X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 20 Sep 2004 20:53:10 -0000 Petri Helenius wrote: > > Andre Oppermann wrote: > > >BTW: You may be better off using pfil_hooks instead of netgraph for your > >tool. You'll save one m_copym and m_freem for each packet. > > > Is pfil zero copy or one copy by default? If the driver supports it, > does a packet get directly DMA'd in mbufs and passed over the pf which > then drops the packet if applicable? pfil is in the ip_input() and ip_output() path. pfil stands for packet filter hooks. You chose to hook yourself into both of them or either of input or output. You get a reference to the mbuf passed when being called from the pfil hook. You can modify the packet (but it must still be a valid packet of that address family afterwards) or you can 'consume' the packet. That means you can take the packet and move it somewhere else (like dummynet into a queue for example) or you can decide to drop it (m_freem). pfil is zero-copy because of the mbuf pointer passing. The packet has been DMA'd to memory before naturally (otherwise we don't have access to it). > Also, did the locking work for network stack in 5.3 make pf fully > parallel so packets arriving can be processed by multiple CPU's? Do > these need to be coming in from multiple interfaces or can even packets > from one interface be distributed among multiple CPU's? The pfil hooks mechnism doesn't have any locking (other than for configuration changes) in itself. Which means more than one CPU can enter a pfil hook at the same time. All pfil hooks consumers have to do their own locking. If your pfil hook consumer doesn't require any internal locking then as many packets as you have CPUs can be in there at the same time. Which CPU handles a packet depends on which one is servicing the interrupt to collect the packet from the network interface. If the network driver is fully SMP capable then everthing can work fully in parallel. -- Andre From owner-freebsd-net@FreeBSD.ORG Mon Sep 20 23:37:29 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B018716A4CE for ; Mon, 20 Sep 2004 23:37:29 +0000 (GMT) Received: from mail.geek.sh (decoder.geek.sh [196.36.198.81]) by mx1.FreeBSD.org (Postfix) with ESMTP id E212943D54 for ; Mon, 20 Sep 2004 23:37:27 +0000 (GMT) (envelope-from aragon@geek.sh) Received: by mail.geek.sh (Postfix, from userid 1000) id F115924D14; Mon, 20 Sep 2004 20:44:31 +0200 (SAST) Date: Mon, 20 Sep 2004 20:44:31 +0200 From: Aragon Gouveia To: freebsd-net@freebsd.org Message-ID: <20040920184431.GA89606@phat.za.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-Operating-System: FreeBSD 4.8-RELEASE-p1 i386 Subject: Wierd tunnel+MTU issue X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 20 Sep 2004 23:37:29 -0000 Hi, A while ago I setup a vtun tunnel between a FreeBSD 4.10-RELEASE machine and a 5.2.1-RELEASE-p9 machine. Initially everything appeared to work great, but I've just stumbled upon a seriously wierd problem that I can't figure out. I know this is not a support forum for the vtun package, but the problem I'm having is consistently reproducable with another VPN type package - OpenVPN. I'm beginning to think the problem is not related to vtun/OpenVPN and was hoping someone could shed some light on my problem. My setup is as follows. My notebook is running 5.2.1-REALEASE-p9 using userland ppp to establish a PPPoE session over an ADSL bridge. Above that, it runs vtun to establish a UDP tunnel to my VPN server sitting at an ISP. The VPN server is the 4.10-RELEASE machine also running vtun 1.6 configured in server mode. The link is configured for no compression, but encryption enabled. Now the link comes up 100% and passes most data fine. I've set my interface MTU down to 1200 on both sides. I'm also source routing on my notebook with ipfw fwd to make sure traffic flows out the links I want them to flow. This is working 100% too. The problem is this: I'm running Apache 2.0.50 on my notebook. If I request a page from my notebook from an outside machine via the VPN, request responses that exceed the interface MTU are simply not sent. For example, if I request a file sized at 1100 bytes, this is the tcpdump transcript running on my notebook, sniffing the VPN interface: tcpdump: listening on tun1 20:31:01.892060 196.15.a.z.3159 > 196.15.a.x.80: S 4115956342:4115956342(0) win 57344 (DF) [tos 0x10] 20:31:01.892228 196.15.a.x.80 > 196.15.a.z.3159: S 1941194202:1941194202(0) ack 4115956343 win 65535 (DF) 20:31:01.974087 196.15.a.z.3159 > 196.15.a.x.80: . ack 1 win 57600 (DF) [tos 0x10] 20:31:08.417478 196.15.a.z.3159 > 196.15.a.x.80: P 1:21(20) ack 1 win 57600 (DF) [tos 0x10] 20:31:08.517285 196.15.a.x.80 > 196.15.a.z.3159: . ack 21 win 33120 (DF) 20:31:10.340468 196.15.a.z.3159 > 196.15.a.x.80: P 21:23(2) ack 1 win 57600 (DF) [tos 0x10] 20:31:10.341371 196.15.a.x.80 > 196.15.a.z.3159: P 1:286(285) ack 23 win 33120 (DF) 20:31:10.341412 196.15.a.x.80 > 196.15.a.z.3159: P 286:1386(1100) ack 23 win 33120 (DF) 20:31:10.342143 196.15.a.x.80 > 196.15.a.z.3159: F 1386:1386(0) ack 23 win 33120 (DF) 20:31:10.568480 196.15.a.z.3159 > 196.15.a.x.80: . ack 286 win 57600 (DF) [tos 0x10] 20:31:10.618594 196.15.a.z.3159 > 196.15.a.x.80: . ack 1387 win 57600 (DF) [tos 0x10] 20:31:10.626417 196.15.a.z.3159 > 196.15.a.x.80: F 23:23(0) ack 1387 win 57600 (DF) [tos 0x10] 20:31:10.626532 196.15.a.x.80 > 196.15.a.z.3159: . ack 24 win 33119 (DF) The two important lines being: 20:31:10.341371 196.15.a.x.80 > 196.15.a.z.3159: P 1:286(285) ack 23 win 33120 (DF) 20:31:10.341412 196.15.a.x.80 > 196.15.a.z.3159: P 286:1386(1100) ack 23 win 33120 (DF) The first of these two is the HTTP response header, and the second the actual requested data (1100 bytes as shown). If I try request a file 1400 bytes large (MTU is 1200): tcpdump: listening on tun1 20:35:06.588068 196.15.a.z.3161 > 196.15.a.x.80: S 1461068997:1461068997(0) win 57344 (DF) [tos 0x10] 20:35:06.588242 196.15.a.x.80 > 196.15.a.z.3161: S 1654337904:1654337904(0) ack 1461068998 win 65535 (DF) 20:35:06.659998 196.15.a.z.3161 > 196.15.a.x.80: . ack 1 win 57600 (DF) [tos 0x10] 20:35:10.490089 196.15.a.z.3161 > 196.15.a.x.80: P 1:21(20) ack 1 win 57600 (DF) [tos 0x10] 20:35:10.589617 196.15.a.x.80 > 196.15.a.z.3161: . ack 21 win 33120 (DF) 20:35:11.506613 196.15.a.z.3161 > 196.15.a.x.80: P 21:23(2) ack 1 win 57600 (DF) [tos 0x10] 20:35:11.507306 196.15.a.x.80 > 196.15.a.z.3161: P 1:286(285) ack 23 win 33120 (DF) 20:35:11.716698 196.15.a.z.3161 > 196.15.a.x.80: . ack 286 win 57600 (DF) [tos 0x10] 20:35:16.619379 196.15.a.z.3161 > 196.15.a.x.80: F 23:23(0) ack 286 win 57600 (DF) [tos 0x10] 20:35:17.815936 196.15.a.z.3161 > 196.15.a.x.80: F 23:23(0) ack 286 win 57600 (DF) [tos 0x10] 20:35:20.017123 196.15.a.z.3161 > 196.15.a.x.80: F 23:23(0) ack 286 win 57600 (DF) [tos 0x10] 20:35:24.227404 196.15.a.z.3161 > 196.15.a.x.80: F 23:23(0) ack 286 win 57600 (DF) [tos 0x10] The two important lines being: 20:35:11.507306 196.15.a.x.80 > 196.15.a.z.3161: P 1:286(285) ack 23 win 33120 (DF) 20:35:11.716698 196.15.a.z.3161 > 196.15.a.x.80: . ack 286 win 57600 (DF) [tos 0x10] The first line of the important ones is the HTTP response header. The second one obviously just the TCP acknowledgement. The expected next few packets that should follow the header never get sent. I'm stumped. As I said, I've tried OpenVPN as well but the behaviour is precisely the same. Does anyone have any ideas? Thanks, Aragon From owner-freebsd-net@FreeBSD.ORG Mon Sep 20 23:57:46 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0842F16A4CF for ; Mon, 20 Sep 2004 23:57:46 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 35E6E43D31 for ; Mon, 20 Sep 2004 23:57:45 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 42741 invoked from network); 20 Sep 2004 23:52:02 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.54]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 20 Sep 2004 23:52:02 -0000 Message-ID: <414F6E82.59E5A16@freebsd.org> Date: Tue, 21 Sep 2004 01:57:54 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: John-Mark Gurney References: <20040906050435.GA72089@funkthat.com> <41408D4C.E33B6F98@freebsd.org> <20040918231719.GV72089@funkthat.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: better MTU support... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 20 Sep 2004 23:57:46 -0000 John-Mark Gurney wrote: > > Andre Oppermann wrote this message on Thu, Sep 09, 2004 at 19:05 +0200: > > Ok, finally got a switch (and gige cards, if_re needs work) capable of > jumbo frames.. > > > John-Mark Gurney wrote: > > > In a recent experiment w/ Jumbo frames, I found out that sending ip > > > frames completely ignores the MTU set on host routes. This makes it > > > difficult (or next to impossible) to support a network that has both > > > regular and jumbo frames on it as you can't restrict some hosts to the > > > smaller frames. > > > > What you should do instead is to set the MTU on the interface to 9018 > > or so and then have a default route with MTU 1500 for everything else. > > Now you can specify larger MTUs for hosts that support it. > > > > Otherwise you are opening a can of worms... > > This doesn't fix it, since the output still doesn't honor the mtu on > the route.. Note, I'm not testing tcp, only udp and icmp since I've > seen that TCP already works fine... > # netstat -rnWfinet > Routing tables > > Internet: > Destination Gateway Flags Refs Use Mtu Netif Expire > default 192.168.0.14 UGS 0 11 1500 em0 > 127.0.0.1 127.0.0.1 UH 0 40 16384 lo0 > 192.168.0 link#5 UC 0 0 9000 em0 > 192.168.0.1 00:a0:c9:59:8b:6c UHLW 0 33 1500 em0 175 > 192.168.0.3 00:0a:95:9e:8b:88 UHLW 0 1988 9000 em0 374 > 192.168.0.14 00:a0:c9:31:30:5e UHLW 1 8 1500 em0 955 > 192.168.0.20 00:07:e9:0d:aa:ca UHLW 0 18 9000 em0 187 > 192.168.0.21 00:07:e9:0d:ad:06 UHLW 0 2 9000 lo0 > > tcpdump output: > 16:02:14.311079 IP 192.168.0.21 > 192.168.0.1: icmp 5008: echo request seq 14 > 16:02:15.320981 IP 192.168.0.21 > 192.168.0.1: icmp 5008: echo request seq 15 > 16:04:54.720890 IP 192.168.0.21 > 128.223.122.47: icmp 5008: echo request seq 0 > 16:04:55.727148 IP 192.168.0.21 > 128.223.122.47: icmp 5008: echo request seq 1 > 16:05:02.288989 IP 192.168.0.21 > 192.168.0.20: icmp 5008: echo request seq 0 > 16:05:02.289856 IP 192.168.0.20 > 192.168.0.21: icmp 5008: echo reply seq 0 > 16:05:03.296481 IP 192.168.0.21 > 192.168.0.20: icmp 5008: echo request seq 1 > 16:05:03.297282 IP 192.168.0.20 > 192.168.0.21: icmp 5008: echo reply seq 1 > > So, as you can see, it's broken... > > with my patch, ip properly fragments the packets to machines with > smaller mtu... > > > > I now have a patch to ip_output that makes it obay the MTU set on the > > > route instead of that of the interface. > > > > Your patch corrects a problem in ip_output where a smaller MTU on an > > rtentry was ignored but that is only for the non-TCP cases. When you > > open a TCP session the MTU will be honored (see tcp_subr.c:tcp_maxmtu). > > If not it would be a bug. > > > > Could you try your large MTU setup again using the procedure I desribed > > above? > > > > That should solve your immediate problem. > > Nope, it doesn't... > > > For the general 'bug' in ip_output that it doesn't honour a smaller MTU > > on a route I'd like to do a more throughout fix. Routes should be > > created with MTU 0 if the MTU is not different from the if_mtu. Only > > in those cases where you want to have a lower MTU you set it. For cloned > > routes the MTU would be cloned from the parent. This range of changes is > > more intrusive. On top of that comes the new ARP code which will have a > > MTU field as well. This one is supposed to store different MTUs for mixed > > MTU L2 networks. How to transport the MTU information is a separate > > discussion. > > > > If the fix above works for you I'd like to do the real fix later (< end > > of year) and not change the current behaviour in ip_output at the moment. > > It wouldn't be hard to add to my patch the check to see if the route's > mtu is 0 and just use the if mtu... which then solves the ip part of > your more complete fix... Then when you finally fix the route/arp stuff > nothing else should be necessary... > > Sound good? Moving the check upwards as you have done in ip_output() works in your case but is not a real and clean fix. Ideally the routes should never have any MTU assigned to them unless someone explicitly sets it. So the MTU for the routes should always be zero and ignored. If it is zero then only the link MTU will be used. If there is an MTU on a route it should be observed not only for host routes (as you do in your patch) but also for network routes. Getting this right requires disabling the copying of the MTU when a route is cloned or created. We also have to check that all consumers of the MTU field in the kernel and userland can cope with zero MTU and these semantics (ignoring it). I'll get to doing that till end of the week. If get some of those earlier please send me the patches so we don't duplicate work. Then we have next week something ready to commit to 6-current. -- Andre From owner-freebsd-net@FreeBSD.ORG Tue Sep 21 06:02:15 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8F17916A4CE for ; Tue, 21 Sep 2004 06:02:15 +0000 (GMT) Received: from diaspar.rdsnet.ro (diaspar.rdsnet.ro [213.157.165.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7141A43D58 for ; Tue, 21 Sep 2004 06:02:14 +0000 (GMT) (envelope-from dudu@diaspar.rdsnet.ro) Received: (qmail 50844 invoked by uid 89); 12 Jan 1970 00:26:59 -0000 Received: from unknown (HELO snakepit) (dudu@diaspar.rdsnet.ro@62.231.127.38) by 0 with AES256-SHA encrypted SMTP; 12 Jan 1970 00:26:59 -0000 Date: Tue, 21 Sep 2004 09:03:13 +0300 From: Vlad GALU To: freebsd-net@freebsd.org Message-Id: <20040921090313.2c49f2c6.dudu@diaspar.rdsnet.ro> In-Reply-To: <20040920184431.GA89606@phat.za.net> References: <20040920184431.GA89606@phat.za.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; i386-portbld-freebsd4.10) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: Wierd tunnel+MTU issue X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 21 Sep 2004 06:02:15 -0000 On Mon, 20 Sep 2004 20:44:31 +0200 Aragon Gouveia wrote: It looks like your PMTUD doesn't work. Have you somehow disabled incoming ICMP traffic to the box you've noticed these issues ? > Hi, > > A while ago I setup a vtun tunnel between a FreeBSD 4.10-RELEASE > machine and a 5.2.1-RELEASE-p9 machine. Initially everything appeared > to work great, but I've just stumbled upon a seriously wierd problem > that I can't figure out. > > I know this is not a support forum for the vtun package, but the > problem I'm having is consistently reproducable with another VPN type > package - OpenVPN. I'm beginning to think the problem is not related > to vtun/OpenVPN and was hoping someone could shed some light on my > problem. > > My setup is as follows. > > My notebook is running 5.2.1-REALEASE-p9 using userland ppp to > establish a PPPoE session over an ADSL bridge. Above that, it runs > vtun to establish a UDP tunnel to my VPN server sitting at an ISP. > > The VPN server is the 4.10-RELEASE machine also running vtun 1.6 > configured in server mode. The link is configured for no compression, > but encryption enabled. > > Now the link comes up 100% and passes most data fine. I've set my > interface MTU down to 1200 on both sides. I'm also source routing on > my notebook with ipfw fwd to make sure traffic flows out the links I > want them to flow. This is working 100% too. > > The problem is this: I'm running Apache 2.0.50 on my notebook. If I > request a page from my notebook from an outside machine via the VPN, > request responses that exceed the interface MTU are simply not sent. > > For example, if I request a file sized at 1100 bytes, this is the > tcpdump transcript running on my notebook, sniffing the VPN interface: > > tcpdump: listening on tun1 > 20:31:01.892060 196.15.a.z.3159 > 196.15.a.x.80: S > 4115956342:4115956342(0) win 57344 0,nop,nop,timestamp 606530904 0> (DF) [tos 0x10] 20:31:01.892228 > 196.15.a.x.80 > 196.15.a.z.3159: S 1941194202:1941194202(0) ack > 4115956343 win 65535 269446043 606530904> (DF) 20:31:01.974087 196.15.a.z.3159 > > 196.15.a.x.80: . ack 1 win 57600 269446043> (DF) [tos 0x10] 20:31:08.417478 196.15.a.z.3159 > > 196.15.a.x.80: P 1:21(20) ack 1 win 57600 269446043> (DF) [tos 0x10] 20:31:08.517285 196.15.a.x.80 > > 196.15.a.z.3159: . ack 21 win 33120 606531558> (DF) 20:31:10.340468 196.15.a.z.3159 > 196.15.a.x.80: P > 21:23(2) ack 1 win 57600 (DF) > [tos 0x10] 20:31:10.341371 196.15.a.x.80 > 196.15.a.z.3159: P > 1:286(285) ack 23 win 33120 > (DF) 20:31:10.341412 196.15.a.x.80 > 196.15.a.z.3159: P 286:1386(1100) > ack 23 win 33120 (DF) > 20:31:10.342143 196.15.a.x.80 > 196.15.a.z.3159: F 1386:1386(0) ack 23 > win 33120 (DF) 20:31:10.568480 > 196.15.a.z.3159 > 196.15.a.x.80: . ack 286 win 57600 > (DF) [tos 0x10] > 20:31:10.618594 196.15.a.z.3159 > 196.15.a.x.80: . ack 1387 win 57600 > (DF) [tos 0x10] > 20:31:10.626417 196.15.a.z.3159 > 196.15.a.x.80: F 23:23(0) ack 1387 > win 57600 (DF) [tos 0x10] > 20:31:10.626532 196.15.a.x.80 > 196.15.a.z.3159: . ack 24 win 33119 > (DF) > > > The two important lines being: > > 20:31:10.341371 196.15.a.x.80 > 196.15.a.z.3159: P 1:286(285) ack 23 > win 33120 (DF) 20:31:10.341412 > 196.15.a.x.80 > 196.15.a.z.3159: P 286:1386(1100) ack 23 win 33120 > (DF) > > The first of these two is the HTTP response header, and the second the > actual requested data (1100 bytes as shown). > > If I try request a file 1400 bytes large (MTU is 1200): > > tcpdump: listening on tun1 > 20:35:06.588068 196.15.a.z.3161 > 196.15.a.x.80: S > 1461068997:1461068997(0) win 57344 0,nop,nop,timestamp 606555375 0> (DF) [tos 0x10] 20:35:06.588242 > 196.15.a.x.80 > 196.15.a.z.3161: S 1654337904:1654337904(0) ack > 1461068998 win 65535 269690732 606555375> (DF) 20:35:06.659998 196.15.a.z.3161 > > 196.15.a.x.80: . ack 1 win 57600 269690732> (DF) [tos 0x10] 20:35:10.490089 196.15.a.z.3161 > > 196.15.a.x.80: P 1:21(20) ack 1 win 57600 269690732> (DF) [tos 0x10] 20:35:10.589617 196.15.a.x.80 > > 196.15.a.z.3161: . ack 21 win 33120 606555765> (DF) 20:35:11.506613 196.15.a.z.3161 > 196.15.a.x.80: P > 21:23(2) ack 1 win 57600 (DF) > [tos 0x10] 20:35:11.507306 196.15.a.x.80 > 196.15.a.z.3161: P > 1:286(285) ack 23 win 33120 > (DF) 20:35:11.716698 196.15.a.z.3161 > 196.15.a.x.80: . ack 286 win > 57600 (DF) [tos 0x10] > 20:35:16.619379 196.15.a.z.3161 > 196.15.a.x.80: F 23:23(0) ack 286 > win 57600 (DF) [tos 0x10] > 20:35:17.815936 196.15.a.z.3161 > 196.15.a.x.80: F 23:23(0) ack 286 > win 57600 (DF) [tos 0x10] > 20:35:20.017123 196.15.a.z.3161 > 196.15.a.x.80: F 23:23(0) ack 286 > win 57600 (DF) [tos 0x10] > 20:35:24.227404 196.15.a.z.3161 > 196.15.a.x.80: F 23:23(0) ack 286 > win 57600 (DF) [tos 0x10] > > > The two important lines being: > > 20:35:11.507306 196.15.a.x.80 > 196.15.a.z.3161: P 1:286(285) ack 23 > win 33120 (DF) 20:35:11.716698 > 196.15.a.z.3161 > 196.15.a.x.80: . ack 286 win 57600 > (DF) [tos 0x10] > > > The first line of the important ones is the HTTP response header. The > second one obviously just the TCP acknowledgement. The expected next > few packets that should follow the header never get sent. > > I'm stumped. As I said, I've tried OpenVPN as well but the behaviour > is precisely the same. Does anyone have any ideas? > > > Thanks, > Aragon > _______________________________________________ > 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" ---- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. From owner-freebsd-net@FreeBSD.ORG Tue Sep 21 08:41:17 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B1FE716A4EB for ; Tue, 21 Sep 2004 08:41:17 +0000 (GMT) Received: from mail.geek.sh (decoder.geek.sh [196.36.198.81]) by mx1.FreeBSD.org (Postfix) with ESMTP id E501643D49 for ; Tue, 21 Sep 2004 08:41:15 +0000 (GMT) (envelope-from aragon@geek.sh) Received: by mail.geek.sh (Postfix, from userid 1000) id 4619124D15; Tue, 21 Sep 2004 10:41:12 +0200 (SAST) Date: Tue, 21 Sep 2004 10:41:12 +0200 From: Aragon Gouveia To: freebsd-net@freebsd.org Message-ID: <20040921084112.GA21160@phat.za.net> Mail-Followup-To: freebsd-net@freebsd.org References: <20040920184431.GA89606@phat.za.net> <20040921090313.2c49f2c6.dudu@diaspar.rdsnet.ro> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040921090313.2c49f2c6.dudu@diaspar.rdsnet.ro> User-Agent: Mutt/1.4i X-Operating-System: FreeBSD 4.8-RELEASE-p1 i386 Subject: Re: Wierd tunnel+MTU issue X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 21 Sep 2004 08:41:17 -0000 Hi, No, it's not that. No filtering is taking place. I've figured out the problem, but I'm not sure how to solve it. Here's what I think is the problem. >From a tcpdump transcript: 09:56:37.652907 .4185 > .80: S 487952620:487952620(0) win 57344 (DF) [tos 0x10] 09:56:37.653076 .80 > .4185: S 4069940133:4069940133(0) ack 487952621 win 65535 (DF) is my notebook running Apache. As can be seen above, it's negotiating an MSS of 1452 with the peer, which it should not be doing. The reason it's doing that is because my default route is via an interface with an MTU of 1492 - the tun interface opened by userland ppp for the PPPoE session over my ADSL bridge. As I said, I'm using ipfw fwd to source route packets from (the vtun tunnel interface address) to the vtun tunnel's remote end-point. But I'm guessing MSS is chosen based on the host's routing table. Which makes perfect sense. So to prove my suspicion I added a route on my notebook as follows: route add -host 196.15.a.y 196.15.a.y being the vtun tunnel's remote end-point. Now the tcpdump transcript looks like this: 10:10:21.227506 .2404 > .80: S 996010957:996010957(0) win 57344 (DF) [tos 0x10] 10:10:21.227717 .80 > .2404: S 2935622965:2935622965(0) ack 996010958 win 65535 (DF) The tunnel's interface MTU was set at 1256 when I did this. So the negotiated MSS is now correct and things are working. But I need to be able to route based on source address and ipfw fwd is the only way I know how to do it. Can anyone think of a clever workaround for this? Is there a way to force the TCP stack to use a set MSS regardless of what the routing table and interface MTU say? Thanks, Aragon | By Vlad GALU | [ 2004-09-21 08:02 +0200 ] > On Mon, 20 Sep 2004 20:44:31 +0200 > Aragon Gouveia wrote: > > It looks like your PMTUD doesn't work. Have you somehow disabled > incoming ICMP traffic to the box you've noticed these issues ? > > > Hi, > > > > A while ago I setup a vtun tunnel between a FreeBSD 4.10-RELEASE > > machine and a 5.2.1-RELEASE-p9 machine. Initially everything appeared > > to work great, but I've just stumbled upon a seriously wierd problem > > that I can't figure out. > > > > I know this is not a support forum for the vtun package, but the > > problem I'm having is consistently reproducable with another VPN type > > package - OpenVPN. I'm beginning to think the problem is not related > > to vtun/OpenVPN and was hoping someone could shed some light on my > > problem. > > > > My setup is as follows. > > > > My notebook is running 5.2.1-REALEASE-p9 using userland ppp to > > establish a PPPoE session over an ADSL bridge. Above that, it runs > > vtun to establish a UDP tunnel to my VPN server sitting at an ISP. > > > > The VPN server is the 4.10-RELEASE machine also running vtun 1.6 > > configured in server mode. The link is configured for no compression, > > but encryption enabled. > > > > Now the link comes up 100% and passes most data fine. I've set my > > interface MTU down to 1200 on both sides. I'm also source routing on > > my notebook with ipfw fwd to make sure traffic flows out the links I > > want them to flow. This is working 100% too. > > > > The problem is this: I'm running Apache 2.0.50 on my notebook. If I > > request a page from my notebook from an outside machine via the VPN, > > request responses that exceed the interface MTU are simply not sent. > > > > For example, if I request a file sized at 1100 bytes, this is the > > tcpdump transcript running on my notebook, sniffing the VPN interface: > > > > tcpdump: listening on tun1 > > 20:31:01.892060 196.15.a.z.3159 > 196.15.a.x.80: S > > 4115956342:4115956342(0) win 57344 > 0,nop,nop,timestamp 606530904 0> (DF) [tos 0x10] 20:31:01.892228 > > 196.15.a.x.80 > 196.15.a.z.3159: S 1941194202:1941194202(0) ack > > 4115956343 win 65535 > 269446043 606530904> (DF) 20:31:01.974087 196.15.a.z.3159 > > > 196.15.a.x.80: . ack 1 win 57600 > 269446043> (DF) [tos 0x10] 20:31:08.417478 196.15.a.z.3159 > > > 196.15.a.x.80: P 1:21(20) ack 1 win 57600 > 269446043> (DF) [tos 0x10] 20:31:08.517285 196.15.a.x.80 > > > 196.15.a.z.3159: . ack 21 win 33120 > 606531558> (DF) 20:31:10.340468 196.15.a.z.3159 > 196.15.a.x.80: P > > 21:23(2) ack 1 win 57600 (DF) > > [tos 0x10] 20:31:10.341371 196.15.a.x.80 > 196.15.a.z.3159: P > > 1:286(285) ack 23 win 33120 > > (DF) 20:31:10.341412 196.15.a.x.80 > 196.15.a.z.3159: P 286:1386(1100) > > ack 23 win 33120 (DF) > > 20:31:10.342143 196.15.a.x.80 > 196.15.a.z.3159: F 1386:1386(0) ack 23 > > win 33120 (DF) 20:31:10.568480 > > 196.15.a.z.3159 > 196.15.a.x.80: . ack 286 win 57600 > > (DF) [tos 0x10] > > 20:31:10.618594 196.15.a.z.3159 > 196.15.a.x.80: . ack 1387 win 57600 > > (DF) [tos 0x10] > > 20:31:10.626417 196.15.a.z.3159 > 196.15.a.x.80: F 23:23(0) ack 1387 > > win 57600 (DF) [tos 0x10] > > 20:31:10.626532 196.15.a.x.80 > 196.15.a.z.3159: . ack 24 win 33119 > > (DF) > > > > > > The two important lines being: > > > > 20:31:10.341371 196.15.a.x.80 > 196.15.a.z.3159: P 1:286(285) ack 23 > > win 33120 (DF) 20:31:10.341412 > > 196.15.a.x.80 > 196.15.a.z.3159: P 286:1386(1100) ack 23 win 33120 > > (DF) > > > > The first of these two is the HTTP response header, and the second the > > actual requested data (1100 bytes as shown). > > > > If I try request a file 1400 bytes large (MTU is 1200): > > > > tcpdump: listening on tun1 > > 20:35:06.588068 196.15.a.z.3161 > 196.15.a.x.80: S > > 1461068997:1461068997(0) win 57344 > 0,nop,nop,timestamp 606555375 0> (DF) [tos 0x10] 20:35:06.588242 > > 196.15.a.x.80 > 196.15.a.z.3161: S 1654337904:1654337904(0) ack > > 1461068998 win 65535 > 269690732 606555375> (DF) 20:35:06.659998 196.15.a.z.3161 > > > 196.15.a.x.80: . ack 1 win 57600 > 269690732> (DF) [tos 0x10] 20:35:10.490089 196.15.a.z.3161 > > > 196.15.a.x.80: P 1:21(20) ack 1 win 57600 > 269690732> (DF) [tos 0x10] 20:35:10.589617 196.15.a.x.80 > > > 196.15.a.z.3161: . ack 21 win 33120 > 606555765> (DF) 20:35:11.506613 196.15.a.z.3161 > 196.15.a.x.80: P > > 21:23(2) ack 1 win 57600 (DF) > > [tos 0x10] 20:35:11.507306 196.15.a.x.80 > 196.15.a.z.3161: P > > 1:286(285) ack 23 win 33120 > > (DF) 20:35:11.716698 196.15.a.z.3161 > 196.15.a.x.80: . ack 286 win > > 57600 (DF) [tos 0x10] > > 20:35:16.619379 196.15.a.z.3161 > 196.15.a.x.80: F 23:23(0) ack 286 > > win 57600 (DF) [tos 0x10] > > 20:35:17.815936 196.15.a.z.3161 > 196.15.a.x.80: F 23:23(0) ack 286 > > win 57600 (DF) [tos 0x10] > > 20:35:20.017123 196.15.a.z.3161 > 196.15.a.x.80: F 23:23(0) ack 286 > > win 57600 (DF) [tos 0x10] > > 20:35:24.227404 196.15.a.z.3161 > 196.15.a.x.80: F 23:23(0) ack 286 > > win 57600 (DF) [tos 0x10] > > > > > > The two important lines being: > > > > 20:35:11.507306 196.15.a.x.80 > 196.15.a.z.3161: P 1:286(285) ack 23 > > win 33120 (DF) 20:35:11.716698 > > 196.15.a.z.3161 > 196.15.a.x.80: . ack 286 win 57600 > > (DF) [tos 0x10] > > > > > > The first line of the important ones is the HTTP response header. The > > second one obviously just the TCP acknowledgement. The expected next > > few packets that should follow the header never get sent. > > > > I'm stumped. As I said, I've tried OpenVPN as well but the behaviour > > is precisely the same. Does anyone have any ideas? > > > > > > Thanks, > > Aragon > > _______________________________________________ > > 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" > > > ---- > If it's there, and you can see it, it's real. > If it's not there, and you can see it, it's virtual. > If it's there, and you can't see it, it's transparent. > If it's not there, and you can't see it, you erased it. > _______________________________________________ > 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 Sep 21 08:51:08 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A8DA816A4CF for ; Tue, 21 Sep 2004 08:51:08 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id DA35243D1D for ; Tue, 21 Sep 2004 08:51:07 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 45117 invoked from network); 21 Sep 2004 08:45:21 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.54]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 21 Sep 2004 08:45:21 -0000 Message-ID: <414FEB86.5CA8694F@freebsd.org> Date: Tue, 21 Sep 2004 10:51:18 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Aragon Gouveia References: <20040920184431.GA89606@phat.za.net> <20040921084112.GA21160@phat.za.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: Wierd tunnel+MTU issue X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 21 Sep 2004 08:51:08 -0000 Aragon Gouveia wrote: > > Hi, > > No, it's not that. No filtering is taking place. I've figured out the > problem, but I'm not sure how to solve it. Here's what I think is the > problem. > > >From a tcpdump transcript: > > 09:56:37.652907 .4185 > .80: S 487952620:487952620(0) win 57344 (DF) [tos 0x10] > 09:56:37.653076 .80 > .4185: S 4069940133:4069940133(0) ack 487952621 win 65535 (DF) > > is my notebook running Apache. As can be seen above, it's > negotiating an MSS of 1452 with the peer, which it should not be doing. The > reason it's doing that is because my default route is via an interface with > an MTU of 1492 - the tun interface opened by userland ppp for the PPPoE > session over my ADSL bridge. > > As I said, I'm using ipfw fwd to source route packets from > (the vtun tunnel interface address) to the vtun tunnel's remote end-point. > But I'm guessing MSS is chosen based on the host's routing table. Which > makes perfect sense. > > So to prove my suspicion I added a route on my notebook as follows: > > route add -host 196.15.a.y > > 196.15.a.y being the vtun tunnel's remote end-point. > > Now the tcpdump transcript looks like this: > > 10:10:21.227506 .2404 > .80: S 996010957:996010957(0) win 57344 (DF) [tos 0x10] > 10:10:21.227717 .80 > .2404: S 2935622965:2935622965(0) ack 996010958 win 65535 (DF) > > The tunnel's interface MTU was set at 1256 when I did this. So the > negotiated MSS is now correct and things are working. > > But I need to be able to route based on source address and ipfw fwd is the > only way I know how to do it. Can anyone think of a clever workaround for > this? Is there a way to force the TCP stack to use a set MSS regardless of > what the routing table and interface MTU say? You are onto something. It seems tcp_output() doesn't handle the error cases it gets from ip_output() all too well these days. I suspect this is the same problem we have in kern/71184. I'll look into it later today. Could you please file a PR with all information you have provided so far and your observations etc. Just merge your emails together and submit it as text. Then give me the PR number so I can take it over. -- Andre From owner-freebsd-net@FreeBSD.ORG Tue Sep 21 10:02:25 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D87CF16A4CE; Tue, 21 Sep 2004 10:02:25 +0000 (GMT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9051743D4C; Tue, 21 Sep 2004 10:02:25 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id B72AD653B5; Tue, 21 Sep 2004 11:02:24 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 22905-02; Tue, 21 Sep 2004 11:02:24 +0100 (BST) Received: from empiric.dek.spc.org (adsl-67-121-95-65.dsl.snfc21.pacbell.net [67.121.95.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id A265E65213; Tue, 21 Sep 2004 11:02:23 +0100 (BST) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id 0F3BA6455; Tue, 21 Sep 2004 03:02:20 -0700 (PDT) Date: Tue, 21 Sep 2004 03:02:20 -0700 From: Bruce M Simpson To: Max Laier Message-ID: <20040921100220.GC842@empiric.icir.org> Mail-Followup-To: Max Laier , freebsd-arch@freebsd.org, freebsd-hackers@freebsd.org, freebsd-standards@freebsd.org, freebsd-net@freebsd.org References: <200409200250.49518.max@love2party.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FCuugMFkClbJLl1L" Content-Disposition: inline In-Reply-To: <200409200250.49518.max@love2party.net> cc: freebsd-hackers@freebsd.org cc: freebsd-net@freebsd.org cc: freebsd-standards@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: Global (non _KERNEL) place for sockaddr_union? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 21 Sep 2004 10:02:26 -0000 --FCuugMFkClbJLl1L Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 20, 2004 at 02:50:40AM +0200, Max Laier wrote: > My question now is, what would be a good place to define this? Are there = any=20 > fromal standarts that might define it already? (Couldn't find anything) I= s=20 > there anything else that I must consider? I think Brooks' recommendation is sound and should probably be followed as it's fairly close to my original recommendation to you in private. The problem is that the definition of the union depends on what you wish to use it for, and which address families are visible to the application or kernel module which is using the definition. You may find that such a definition has to have conditionalized members. This is usually not a problem so long as they are all the same size. And a sockaddr union embedded in a struct probably should have a member with type 'struct sockaddr_storage' if it's to support all address families in future, although this commits more storage in the enclosing struct and may waste space in some cases. As you point out, you cannot do this in pf, as it defeats the intent of keeping larger members out of the table in the first place, and the union is there to make some casts go away. If it's any consolation, I'm going through very similar pain with XORP's new firewall manager right now with respect to address families (and templatized C++ classes). Regards, BMS --FCuugMFkClbJLl1L Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Comment: '' iD8DBQFBT/wsueUpAYYNtTsRAnCbAKCZrI2SsVz6q/Uu0loceoJREQc/zACggs6O e98ZL0h6Z/r8TWtUkJ8P+30= =buDH -----END PGP SIGNATURE----- --FCuugMFkClbJLl1L-- From owner-freebsd-net@FreeBSD.ORG Tue Sep 21 10:05:43 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0D57716A4CE for ; Tue, 21 Sep 2004 10:05:43 +0000 (GMT) Received: from mail.geek.sh (decoder.geek.sh [196.36.198.81]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4571143D3F for ; Tue, 21 Sep 2004 10:05:42 +0000 (GMT) (envelope-from aragon@geek.sh) Received: by mail.geek.sh (Postfix, from userid 1000) id 5BAC924D14; Tue, 21 Sep 2004 12:05:40 +0200 (SAST) Date: Tue, 21 Sep 2004 12:05:40 +0200 From: Aragon Gouveia To: freebsd-net@freebsd.org Message-ID: <20040921100540.GA27605@phat.za.net> Mail-Followup-To: freebsd-net@freebsd.org References: <20040920184431.GA89606@phat.za.net> <20040921090313.2c49f2c6.dudu@diaspar.rdsnet.ro> <20040921084112.GA21160@phat.za.net> <414FEB86.5CA8694F@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <414FEB86.5CA8694F@freebsd.org> User-Agent: Mutt/1.4i X-Operating-System: FreeBSD 4.8-RELEASE-p1 i386 Subject: Re: Wierd tunnel+MTU issue X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 21 Sep 2004 10:05:43 -0000 | By Andre Oppermann | [ 2004-09-21 10:51 +0200 ] > Could you please file a PR with all information you have provided so far > and your observations etc. Just merge your emails together and submit it > as text. Then give me the PR number so I can take it over. Done - kern/71965 Please let me know if you need more info about my setup. Thank you. :) Regards, Aragon From owner-freebsd-net@FreeBSD.ORG Tue Sep 21 12:30:18 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DBA4B16A4CE for ; Tue, 21 Sep 2004 12:30:18 +0000 (GMT) Received: from melusine.cuivre.fr.eu.org (melusine.cuivre.fr.eu.org [82.225.155.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7FEAD43D2F for ; Tue, 21 Sep 2004 12:30:18 +0000 (GMT) (envelope-from thomas@FreeBSD.ORG) Received: by melusine.cuivre.fr.eu.org (Postfix, from userid 1000) id 531632C3D0; Tue, 21 Sep 2004 14:30:16 +0200 (CEST) Date: Tue, 21 Sep 2004 14:30:16 +0200 From: Thomas Quinot To: freebsd-net@freebsd.org Message-ID: <20040921123016.GA41677@melusine.cuivre.fr.eu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-message-flag: WARNING! Using Outlook can damage your computer. User-Agent: Mutt/1.5.6i Subject: freeaddrinfo(NULL) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 21 Sep 2004 12:30:19 -0000 Currently a call to freeaddrinfo (NULL) causes a segfault. Is there any reason why we should not make that a no-op? This would make freeaddrinfo behave in a manner consistent with free(3), and also with what happens on Linux. Thomas. -- Thomas.Quinot@Cuivre.FR.EU.ORG From owner-freebsd-net@FreeBSD.ORG Tue Sep 21 13:38:29 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BB32216A4CE for ; Tue, 21 Sep 2004 13:38:29 +0000 (GMT) Received: from mail.geek.sh (decoder.geek.sh [196.36.198.81]) by mx1.FreeBSD.org (Postfix) with ESMTP id CF28743D45 for ; Tue, 21 Sep 2004 13:38:27 +0000 (GMT) (envelope-from aragon@geek.sh) Received: by mail.geek.sh (Postfix, from userid 1000) id 825BA24D14; Tue, 21 Sep 2004 15:38:25 +0200 (SAST) Date: Tue, 21 Sep 2004 15:38:25 +0200 From: Aragon Gouveia To: freebsd-net@freebsd.org Message-ID: <20040921133825.GB37317@phat.za.net> Mail-Followup-To: freebsd-net@freebsd.org References: <20040920184431.GA89606@phat.za.net> <20040921084112.GA21160@phat.za.net> <414FEB86.5CA8694F@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <414FEB86.5CA8694F@freebsd.org> User-Agent: Mutt/1.4i X-Operating-System: FreeBSD 4.8-RELEASE-p1 i386 Subject: Re: Wierd tunnel+MTU issue X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 21 Sep 2004 13:38:29 -0000 | By Andre Oppermann | [ 2004-09-21 10:51 +0200 ] > You are onto something. It seems tcp_output() doesn't handle the error > cases it gets from ip_output() all too well these days. I suspect this > is the same problem we have in kern/71184. I'll look into it later today. Andre, don't let me stop your bughunting, but I think I've found a nifty workaround for now. :) OpenVPN has an "mssfix" setting. (something vtun seems to lack) It looks like it does nothing more than rewrite the MSS field of TCP SYN packets that flow over the tunnel. It is making things work now. Here are two tcpdump transcripts, one from each machine: >From : 15:20:01.440318 .1580 > .80: S 1953310673:1953310673(0) win 57344 (DF) [tos 0x10] 15:20:01.628822 .80 > .1580: S 4026187601:4026187601(0) ack 1953310674 win 65535 (DF) >From : 15:20:01.603596 .1580 > .80: S 1953310673:1953310673(0) win 57344 (DF) [tos 0x10] 15:20:01.603771 .80 > .1580: S 4026187601:4026187601(0) ack 1953310674 win 65535 (DF) Notice the altered MSS after it's passed through the tunnel. The above example was performed after increasing the tunnel interface's MTU to 1412 as well (I felt like experimenting further). So far so good. Everything that was broken prior to this change is now working. In case anyone else has this problem, here are the settings I added to my openvpn config: link-mtu 1456 mssfix 1412 The mssfix setting should only need to be set on one of the VPN end-points, but setting it on both shouldn't break anything (I think). I increased link-mtu just for the sake of maybe getting better performance. If you decide to stick with OpenVPN's default MTU you'll probably need an mssfix value of about 1200. Regards, Aragon From owner-freebsd-net@FreeBSD.ORG Tue Sep 21 16:12:10 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9A32916A4D1; Tue, 21 Sep 2004 16:12:10 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 65E9343D1F; Tue, 21 Sep 2004 16:12:06 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id i8LGEKR4023672; Tue, 21 Sep 2004 09:14:21 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id i8LGEKi4023671; Tue, 21 Sep 2004 09:14:20 -0700 Date: Tue, 21 Sep 2004 09:14:20 -0700 From: Brooks Davis To: Max Laier , freebsd-arch@freebsd.org, freebsd-hackers@freebsd.org, freebsd-standards@freebsd.org, freebsd-net@freebsd.org Message-ID: <20040921161420.GA17290@odin.ac.hmc.edu> References: <200409200250.49518.max@love2party.net> <20040921100220.GC842@empiric.icir.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="k+w/mQv8wyuph6w0" Content-Disposition: inline In-Reply-To: <20040921100220.GC842@empiric.icir.org> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=3.0 required=8.0 tests=SUSPICIOUS_RECIPS autolearn=no version=2.63 X-Spam-Level: *** X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Subject: Re: Global (non _KERNEL) place for sockaddr_union? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 21 Sep 2004 16:12:10 -0000 --k+w/mQv8wyuph6w0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 21, 2004 at 03:02:20AM -0700, Bruce M Simpson wrote: > On Mon, Sep 20, 2004 at 02:50:40AM +0200, Max Laier wrote: > > My question now is, what would be a good place to define this? Are ther= e any=20 > > fromal standarts that might define it already? (Couldn't find anything)= Is=20 > > there anything else that I must consider? >=20 > I think Brooks' recommendation is sound and should probably be followed > as it's fairly close to my original recommendation to you in private. >=20 > The problem is that the definition of the union depends on what you wish > to use it for, and which address families are visible to the application > or kernel module which is using the definition. The real problem may be that KAME mistakenly gave sockaddr_union a general name when it isn't and such a type would be hell to actually work with. A custom union that does exactly what pf needs may be the best approach. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --k+w/mQv8wyuph6w0 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBUFNcXY6L6fI4GtQRAmqKAKDCDS6aW5tOLvwi5OE7cOny3qj6xgCfRBDr 0QaUauCEGn2Ij3DHL0SBPwg= =5V32 -----END PGP SIGNATURE----- --k+w/mQv8wyuph6w0-- From owner-freebsd-net@FreeBSD.ORG Tue Sep 21 17:09:29 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0EA5416A4CE; Tue, 21 Sep 2004 17:09:29 +0000 (GMT) Received: from cheer.mahoroba.org (gw4.mahoroba.org [218.45.22.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 77B2043D3F; Tue, 21 Sep 2004 17:09:28 +0000 (GMT) (envelope-from ume@FreeBSD.org) Received: from lyrics.mahoroba.org (IDENT:9kBdVg6hWs9CTiaZ5lSoJ4DoJ3SyWu3oLpw0YErULbFeN7uGd/W9zJAlIDdVvliL@lyrics.mahoroba.org [IPv6:3ffe:501:185b:8010:280:88ff:fe03:4841]) (user=ume mech=CRAM-MD5 bits=0)i8LH9CAr031165 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Sep 2004 02:09:20 +0900 (JST) (envelope-from ume@FreeBSD.org) Date: Wed, 22 Sep 2004 02:09:11 +0900 Message-ID: From: Hajimu UMEMOTO To: Brooks Davis In-Reply-To: <20040921161420.GA17290@odin.ac.hmc.edu> References: <200409200250.49518.max@love2party.net> <20040921100220.GC842@empiric.icir.org> <20040921161420.GA17290@odin.ac.hmc.edu> User-Agent: xcite1.38> Wanderlust/2.11.3 (Wonderwall) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.3 (i386--freebsd) MULE/5.0 (SAKAKI) X-Operating-System: FreeBSD 5.3-BETA5 MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on cheer.mahoroba.org cc: Max Laier cc: freebsd-net@freebsd.org cc: freebsd-standards@freebsd.org cc: freebsd-hackers@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: Global (non _KERNEL) place for sockaddr_union? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 21 Sep 2004 17:09:29 -0000 Hi, >>>>> On Tue, 21 Sep 2004 09:14:20 -0700 >>>>> Brooks Davis said: brooks> The real problem may be that KAME mistakenly gave sockaddr_union a brooks> general name when it isn't and such a type would be hell to actually brooks> work with. A custom union that does exactly what pf needs may be the brooks> best approach. I believe KAME doesn't use non standard struct such as sock_union. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-net@FreeBSD.ORG Tue Sep 21 17:13:24 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AE7CD16A4CE; Tue, 21 Sep 2004 17:13:24 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7BCDF43D31; Tue, 21 Sep 2004 17:13:24 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id i8LHFdOe031312; Tue, 21 Sep 2004 10:15:39 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id i8LHFd0h031311; Tue, 21 Sep 2004 10:15:39 -0700 Date: Tue, 21 Sep 2004 10:15:39 -0700 From: Brooks Davis To: Hajimu UMEMOTO Message-ID: <20040921171539.GA30996@odin.ac.hmc.edu> References: <200409200250.49518.max@love2party.net> <20040921100220.GC842@empiric.icir.org> <20040921161420.GA17290@odin.ac.hmc.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="sdtB3X0nJg68CQEu" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: freebsd-net@FreeBSD.org cc: freebsd-arch@FreeBSD.org cc: freebsd-hackers@FreeBSD.org cc: Max Laier cc: freebsd-standards@FreeBSD.org Subject: Re: Global (non _KERNEL) place for sockaddr_union? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 21 Sep 2004 17:13:25 -0000 --sdtB3X0nJg68CQEu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Sep 22, 2004 at 02:09:11AM +0900, Hajimu UMEMOTO wrote: > Hi, >=20 > >>>>> On Tue, 21 Sep 2004 09:14:20 -0700 > >>>>> Brooks Davis said: >=20 > brooks> The real problem may be that KAME mistakenly gave sockaddr_union a > brooks> general name when it isn't and such a type would be hell to actua= lly > brooks> work with. A custom union that does exactly what pf needs may be= the > brooks> best approach. >=20 > I believe KAME doesn't use non standard struct such as sock_union. Oops, you are correct, it's part of fastipsec, not KAME. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --sdtB3X0nJg68CQEu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBUGG7XY6L6fI4GtQRAmuhAJ9RmMTuSRuAs9YIhRNJ55xq0k1KgwCfY/y3 zqiSVO6mzuxWu2C7MB4GKi8= =lDSM -----END PGP SIGNATURE----- --sdtB3X0nJg68CQEu-- From owner-freebsd-net@FreeBSD.ORG Tue Sep 21 17:31:01 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 92AFC16A4CE; Tue, 21 Sep 2004 17:31:01 +0000 (GMT) Received: from cheer.mahoroba.org (gw4.mahoroba.org [218.45.22.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2000B43D48; Tue, 21 Sep 2004 17:31:01 +0000 (GMT) (envelope-from ume@FreeBSD.org) Received: from lyrics.mahoroba.org (IDENT:fdX/vnGIgJHJh3Z3M4kmt/muiY23zk454XVLJwXlV+Pd5u/xLZbJQ+1mTf3EbfnQ@lyrics.mahoroba.org [IPv6:3ffe:501:185b:8010:280:88ff:fe03:4841]) (user=ume mech=CRAM-MD5 bits=0)i8LHUuIu033522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Sep 2004 02:30:56 +0900 (JST) (envelope-from ume@FreeBSD.org) Date: Wed, 22 Sep 2004 02:30:54 +0900 Message-ID: From: Hajimu UMEMOTO To: Thomas Quinot In-Reply-To: <20040921123016.GA41677@melusine.cuivre.fr.eu.org> References: <20040921123016.GA41677@melusine.cuivre.fr.eu.org> User-Agent: xcite1.38> Wanderlust/2.11.3 (Wonderwall) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.3 (i386--freebsd) MULE/5.0 (SAKAKI) X-Operating-System: FreeBSD 5.3-BETA5 MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on cheer.mahoroba.org cc: freebsd-net@freebsd.org Subject: Re: freeaddrinfo(NULL) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 21 Sep 2004 17:31:01 -0000 Hi, >>>>> On Tue, 21 Sep 2004 14:30:16 +0200 >>>>> Thomas Quinot said: thomas> Currently a call to freeaddrinfo (NULL) causes a segfault. Is there any thomas> reason why we should not make that a no-op? This would make freeaddrinfo thomas> behave in a manner consistent with free(3), and also with what happens thomas> on Linux. Because, the behavior of freeaddrinfo (NULL) is undefined in RFC 2553 nor RFC 3493. Having such an assumption is a potentially bug and lose portability. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-net@FreeBSD.ORG Tue Sep 21 18:07:50 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2E29D16A4CE; Tue, 21 Sep 2004 18:07:50 +0000 (GMT) Received: from melusine.cuivre.fr.eu.org (melusine.cuivre.fr.eu.org [82.225.155.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5DCD543D49; Tue, 21 Sep 2004 18:07:49 +0000 (GMT) (envelope-from thomas@FreeBSD.ORG) Received: by melusine.cuivre.fr.eu.org (Postfix, from userid 1000) id 8EC082A42B; Tue, 21 Sep 2004 20:07:46 +0200 (CEST) Date: Tue, 21 Sep 2004 20:07:46 +0200 From: Thomas Quinot To: Hajimu UMEMOTO Message-ID: <20040921180746.GB49259@melusine.cuivre.fr.eu.org> References: <20040921123016.GA41677@melusine.cuivre.fr.eu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-message-flag: WARNING! Using Outlook can damage your computer. User-Agent: Mutt/1.5.6i cc: freebsd-net@freebsd.org cc: Thomas Quinot Subject: Re: freeaddrinfo(NULL) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 21 Sep 2004 18:07:50 -0000 * Hajimu UMEMOTO, 2004-09-21 : > Because, the behavior of freeaddrinfo (NULL) is undefined in RFC 2553 > nor RFC 3493. Having such an assumption is a potentially bug and > lose portability. That a construct has no defined meaning does not imply that we must make every effort to break applications that (erroneously) make use of it. Would there be any significant drawback for conforming applications if we made our best to deploy a safety net againt buggy user programs by not segfaulting in this case? There are many situations where the system already detects an invalid pointer and reports it gracefully as an error rather than triggering a fatal signal. Thomas. -- Thomas.Quinot@Cuivre.FR.EU.ORG From owner-freebsd-net@FreeBSD.ORG Tue Sep 21 18:19:10 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6D77216A4CE; Tue, 21 Sep 2004 18:19:10 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 41C9F43D1D; Tue, 21 Sep 2004 18:19:10 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id i8LILQC5009301; Tue, 21 Sep 2004 11:21:26 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id i8LILQsb009300; Tue, 21 Sep 2004 11:21:26 -0700 Date: Tue, 21 Sep 2004 11:21:25 -0700 From: Brooks Davis To: Thomas Quinot Message-ID: <20040921182125.GA7566@odin.ac.hmc.edu> References: <20040921123016.GA41677@melusine.cuivre.fr.eu.org> <20040921180746.GB49259@melusine.cuivre.fr.eu.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0OAP2g/MAC+5xKAE" Content-Disposition: inline In-Reply-To: <20040921180746.GB49259@melusine.cuivre.fr.eu.org> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: freebsd-net@freebsd.org cc: Hajimu UMEMOTO Subject: Re: freeaddrinfo(NULL) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 21 Sep 2004 18:19:10 -0000 --0OAP2g/MAC+5xKAE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 21, 2004 at 08:07:46PM +0200, Thomas Quinot wrote: > * Hajimu UMEMOTO, 2004-09-21 : >=20 > > Because, the behavior of freeaddrinfo (NULL) is undefined in RFC 2553 > > nor RFC 3493. Having such an assumption is a potentially bug and > > lose portability. >=20 > That a construct has no defined meaning does not imply that we must make > every effort to break applications that (erroneously) make use of it. > Would there be any significant drawback for conforming applications > if we made our best to deploy a safety net againt buggy user programs > by not segfaulting in this case? >=20 > There are many situations where the system already detects an invalid > pointer and reports it gracefully as an error rather than triggering a > fatal signal. If it wouldn't be too evil, making freeaddrinfo die when malloc's A flag was set and succeed otherwise might be a reasionable compromise. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --0OAP2g/MAC+5xKAE Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBUHElXY6L6fI4GtQRAn62AKCnB1ywmRnF1+Cbg9tlM2+AFJPo8QCfWWNi 2ZXUSrXjbKkN4MAWdQ+kb6s= =hisd -----END PGP SIGNATURE----- --0OAP2g/MAC+5xKAE-- From owner-freebsd-net@FreeBSD.ORG Tue Sep 21 18:58:06 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B12F016A4D8; Tue, 21 Sep 2004 18:58:06 +0000 (GMT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5966343D5D; Tue, 21 Sep 2004 18:58:04 +0000 (GMT) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:b975:fedf:fb7f:f7d7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 15C4215263; Wed, 22 Sep 2004 03:58:01 +0900 (JST) Date: Wed, 22 Sep 2004 03:58:05 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Thomas Quinot In-Reply-To: <20040921180746.GB49259@melusine.cuivre.fr.eu.org> References: <20040921123016.GA41677@melusine.cuivre.fr.eu.org> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII cc: freebsd-net@freebsd.org cc: Hajimu UMEMOTO Subject: Re: freeaddrinfo(NULL) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 21 Sep 2004 18:58:06 -0000 >>>>> On Tue, 21 Sep 2004 20:07:46 +0200, >>>>> Thomas Quinot said: >> Because, the behavior of freeaddrinfo (NULL) is undefined in RFC 2553 >> nor RFC 3493. Having such an assumption is a potentially bug and >> lose portability. > Would there be any significant drawback for conforming applications > if we made our best to deploy a safety net againt buggy user programs > by not segfaulting in this case? As Umemoto-san said, if we made freeaddrinfo(NULL) "safe", the application programmers might tend to rely on the "safety net" and the uncareful coding style. This can be worse than the segfault here, because the reason for the NULL argument might be a bug in the program, and, as a result of hiding the bug by making freeaddrinfo(NULL) "safe", it might cause much more serious effects later in the program. In my understanding, this kind of discussion has always been controversial; whether we want to make more explicit errors (even if those are segfaults), or whether we want to "spoil" bad programmers by making the library interface "safe". I personally prefer the former idea. Ideally, freeaddrinfo() should have provided a return value which is a binary "success" or "fail", so that the application programmers can check the value to be sure that they pass a valid pointer. With the fact that freeaddrinfo() is actually a void function, however, I'd rather keep the current behavior (i.e., segfaulting) as an evil error indication. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp From owner-freebsd-net@FreeBSD.ORG Tue Sep 21 19:07:27 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EB34F16A4CE; Tue, 21 Sep 2004 19:07:27 +0000 (GMT) Received: from burka.carrier.kiev.ua (burka.carrier.kiev.ua [193.193.193.107]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1AA1943D5E; Tue, 21 Sep 2004 19:07:27 +0000 (GMT) (envelope-from netch@lucky.net) Received: from burka.carrier.kiev.ua (netch@localhost [127.0.0.1]) by burka.carrier.kiev.ua with ESMTP id i8LJ7H4o016390; Tue, 21 Sep 2004 22:07:20 +0300 (EEST) (envelope-from netch@burka.carrier.kiev.ua) Received: (from netch@localhost) by burka.carrier.kiev.ua (8.12.11/8.12.11/Submit) id i8LJ7H5B016383; Tue, 21 Sep 2004 22:07:17 +0300 (EEST) (envelope-from netch) Date: Tue, 21 Sep 2004 22:07:17 +0300 From: Valentin Nechayev To: "JINMEI Tatuya / ?$B?@L@C#:H" Message-ID: <20040921190717.GG84228@lucky.net> References: <20040921123016.GA41677@melusine.cuivre.fr.eu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-42: On X-Verify-Sender: Address has been verified (burka.carrier.kiev.ua) cc: freebsd-net@freebsd.org cc: Hajimu UMEMOTO cc: Thomas Quinot Subject: Re: freeaddrinfo(NULL) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: netch@lucky.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Sep 2004 19:07:28 -0000 Wed, Sep 22, 2004 at 03:58:05, jinmei wrote about "Re: freeaddrinfo(NULL)": > As Umemoto-san said, if we made freeaddrinfo(NULL) "safe", the > application programmers might tend to rely on the "safety net" and > the uncareful coding style. This can be worse than the segfault here, Let you try to apply the same arguments to free() and you'll see nonsense. If free(NULL) is freely allowed, what's the problem with freeaddrinfo()? > because the reason for the NULL argument might be a bug in the > program, and, as a result of hiding the bug by making NULL was specially designed by C authors as special value, "no valid pointer here". One may wrap anything with "if(p) freeaddrinfo(p);", but this has no deep sense and leads only to style flames. > freeaddrinfo(NULL) "safe", it might cause much more serious effects > later in the program. What effects? Why they doesn't appear with another pointer? > In my understanding, this kind of discussion has always been > controversial; whether we want to make more explicit errors (even if > those are segfaults), or whether we want to "spoil" bad programmers by > making the library interface "safe". Segfaulting on NULL makes nothing more safe. -netch- From owner-freebsd-net@FreeBSD.ORG Tue Sep 21 20:07:14 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5DE9F16A4E5; Tue, 21 Sep 2004 20:07:13 +0000 (GMT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1E68743D49; Tue, 21 Sep 2004 20:07:11 +0000 (GMT) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:b975:fedf:fb7f:f7d7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id E1CE615265; Wed, 22 Sep 2004 05:07:08 +0900 (JST) Date: Wed, 22 Sep 2004 05:07:13 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: netch@lucky.net In-Reply-To: <20040921190717.GG84228@lucky.net> References: <20040921123016.GA41677@melusine.cuivre.fr.eu.org> <20040921190717.GG84228@lucky.net> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII cc: freebsd-net@freebsd.org cc: Hajimu UMEMOTO cc: Thomas Quinot Subject: Re: freeaddrinfo(NULL) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 21 Sep 2004 20:07:14 -0000 >>>>> On Tue, 21 Sep 2004 22:07:17 +0300, >>>>> Valentin Nechayev said: >> As Umemoto-san said, if we made freeaddrinfo(NULL) "safe", the >> application programmers might tend to rely on the "safety net" and >> the uncareful coding style. This can be worse than the segfault here, > Let you try to apply the same arguments to free() and you'll see nonsense. > If free(NULL) is freely allowed, what's the problem with freeaddrinfo()? One major problem is that the result when we pass NULL to freeaddrinfo is not documented, while C90 (if I understand it correctly) explicitly says the result is no-op. In my preference (note that I admit this is a controversial issue), I'd say the decision of C90 about free(NULL) is also bad, but I can live with it since the standard is clear on this. >> because the reason for the NULL argument might be a bug in the >> program, and, as a result of hiding the bug by making > NULL was specially designed by C authors as special value, "no valid pointer > here". One may wrap anything with "if(p) freeaddrinfo(p);", but this > has no deep sense and leads only to style flames. >> freeaddrinfo(NULL) "safe", it might cause much more serious effects >> later in the program. > What effects? Why they doesn't appear with another pointer? I was not talking about things like whether NULL had been specially designed or not. I was basically talking about any invalid argument to freeaddrinfo. More specifically, I was talking about the following type of coding: foo(addrinfo) struct *addrinfo; /* this should be non NULL */ { .... freeaddrinfo(addrinfo); ... } Here the programmer imposes an assumption that addrinfo is non NULL (or is valid for freeaddrinfo). It's the caller's responsibility to ensure that this is a valid pointer. But consider the case where the caller-side code has a bug and passes a NULL pointer to foo(). If freeaddrinfo(NULL) segfaults, we found the bug at this point. If freeaddrinfo(NULL) does no-op, the latter part of the function is executed whereas the assumption isn't met. This may or may not cause a bad effect. But the real point of the bug that led to the NULL argument is hidden, which may cause another serious problem in some other part of the code. Of course, a careful programmer would always check the assumption somewhere in the function foo() (probably at the head of the function), regardless of the behavior of freeaddrinfo(NULL). This is desirable. However, I can easily imagine that a lazy programmer will tend to omit the check if freeaddrinfo(NULL) does no-op, since the function itself seems to work without a problem whereas it actually just hides a bug. I admit the scenario is not so specific and some others may think it's not so convincing. I basically talk about a general practice (which I personally believe) that it's always better to catch an error than to ignore it and the sooner is the better. >> In my understanding, this kind of discussion has always been >> controversial; whether we want to make more explicit errors (even if >> those are segfaults), or whether we want to "spoil" bad programmers by >> making the library interface "safe". > Segfaulting on NULL makes nothing more safe. This statement is too short to tell if it's valid, but I believe Segfaulting on freeaddrinfo(NULL) can make something safer for the reason I described above. That is, catching a bug earlier *can* make a safer result. Again, note that I admit this is a controversial issue. Regarding whether we should change FreeBSD's implementation of freeaddrinfo() so that it does no-op against NULL, I won't strongly oppose to that if the vast majority supports the idea. However, since the API specification is silent on this, I'd then request that the man page make an explicit note that the application programmer should be check if the argument to freeaddrinfo() is valid because passing a NULL pointer may cause an unexpected result, including segfaulting, on other systems. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp From owner-freebsd-net@FreeBSD.ORG Tue Sep 21 21:32:36 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6CE4C16A4CE; Tue, 21 Sep 2004 21:32:36 +0000 (GMT) Received: from melusine.cuivre.fr.eu.org (melusine.cuivre.fr.eu.org [82.225.155.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE99543D31; Tue, 21 Sep 2004 21:32:35 +0000 (GMT) (envelope-from thomas@FreeBSD.ORG) Received: by melusine.cuivre.fr.eu.org (Postfix, from userid 1000) id BFAE12C3D3; Tue, 21 Sep 2004 23:32:33 +0200 (CEST) Date: Tue, 21 Sep 2004 23:32:33 +0200 From: Thomas Quinot To: "JINMEI Tatuya / ?$B?@L@C#:H" Message-ID: <20040921213233.GA84392@melusine.cuivre.fr.eu.org> References: <20040921123016.GA41677@melusine.cuivre.fr.eu.org> <20040921190717.GG84228@lucky.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-message-flag: WARNING! Using Outlook can damage your computer. User-Agent: Mutt/1.5.6i cc: netch@lucky.net cc: freebsd-net@freebsd.org cc: Hajimu UMEMOTO cc: Thomas Quinot Subject: Re: freeaddrinfo(NULL) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 21 Sep 2004 21:32:36 -0000 * JINMEI Tatuya / ?$B?@L@C#:H, 2004-09-21 : > (or is valid for freeaddrinfo). It's the caller's responsibility to > ensure that this is a valid pointer. But consider the case where the Exactly. And it is the callee's responsibility to enforce the invariants he expects. If freeaddrinfo did noop in face of a NULL argument, the programmer could very well *know* that the pointer may be NULL, and would not bother to check that. > freeaddrinfo(NULL) segfaults, we found the bug at this point. If > freeaddrinfo(NULL) does no-op, the latter part of the function is > executed whereas the assumption isn't met. Not a problem unless the code after that call does rely on that assumption, which may or may not be the case. And thus the fact that freeaddrinfo segfaults in face of a NULL pointer is something potentially useful in only a very specific case. > cause a bad effect. But the real point of the bug that led to the > NULL argument is hidden, which may cause another serious problem in > some other part of the code. Well, a segv definitely causes serious trouble to the application as well. > function itself seems to work without a problem whereas it actually > just hides a bug. You cannot make that assumption! There are many valid scenarios that could lead to that situation that are not necessarily erroneous. > not so convincing. I basically talk about a general practice (which I > personally believe) that it's always better to catch an error than to > ignore it and the sooner is the better. I basically talk about a general practice that the system is supposed to provide mechanism, not policy. :-) > >> In my understanding, this kind of discussion has always been > >> controversial; whether we want to make more explicit errors (even if > >> those are segfaults), or whether we want to "spoil" bad programmers by > >> making the library interface "safe". (I hope I haven't started a flame fest !) > This statement is too short to tell if it's valid, but I believe > Segfaulting on freeaddrinfo(NULL) can make something safer for the > reason I described above. That is, catching a bug earlier *can* > make a safer result. In some conditions. But we have to take into account the fact that other systems do behave differently with a NULL pointer in freeaddrinfo (yes, I am specicly thinking of Linux and Windows), and we may also want to take *that* into account and find out how we can offer a consistent interface to programmers. I also believe that it would be friendlier to programmers to offer a behaviour more similar to free(3). > the vast majority supports the idea. However, since the API > specification is silent on this, I'd then request that the man page > make an explicit note that the application programmer should be check > if the argument to freeaddrinfo() is valid because passing a NULL > pointer may cause an unexpected result, including segfaulting, on > other systems. That sounds perfectly fair to me. Thomas. -- Thomas.Quinot@Cuivre.FR.EU.ORG From owner-freebsd-net@FreeBSD.ORG Tue Sep 21 22:37:18 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D576916A4CE; Tue, 21 Sep 2004 22:37:18 +0000 (GMT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7462C43D41; Tue, 21 Sep 2004 22:37:18 +0000 (GMT) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:edfb:ed25:1690:7523]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id A3DE61525D; Wed, 22 Sep 2004 07:37:15 +0900 (JST) Date: Wed, 22 Sep 2004 07:37:20 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Thomas Quinot In-Reply-To: <20040921213233.GA84392@melusine.cuivre.fr.eu.org> References: <20040921123016.GA41677@melusine.cuivre.fr.eu.org> <20040921190717.GG84228@lucky.net> <20040921213233.GA84392@melusine.cuivre.fr.eu.org> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII cc: netch@lucky.net cc: freebsd-net@freebsd.org cc: Hajimu UMEMOTO cc: Thomas Quinot Subject: Re: freeaddrinfo(NULL) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 21 Sep 2004 22:37:19 -0000 >>>>> On Tue, 21 Sep 2004 23:32:33 +0200, >>>>> Thomas Quinot said: [...snip] It seems that all these points simply show this is a controversial issue. I was not convinced with the argument for the no-op approach, and still believe segfaulting is better. But at the same time I seem to have failed to convince others who believe in no-op. So I won't make further comments on those. (If you feel this is unfair, please raise the points again.) One last comment about consistency: >> This statement is too short to tell if it's valid, but I believe >> Segfaulting on freeaddrinfo(NULL) can make something safer for the >> reason I described above. That is, catching a bug earlier *can* >> make a safer result. > In some conditions. But we have to take into account the fact that other > systems do behave differently with a NULL pointer in freeaddrinfo (yes, > I am specicly thinking of Linux and Windows), and we may also want to > take *that* into account and find out how we can offer a consistent > interface to programmers. I also believe that it would be friendlier to > programmers to offer a behaviour more similar to free(3). Note also that other *BSDs and Solaris use the "segfault" logic. The freeaddrinfo implementation in the "libbind" library as a part of the ISC BIND package, which many UNIX-like OS vendors adopt (perhaps with vendor-specific modifications though), also segfaults against a NULL argument. So, although consistency might in general be a good thing, the real world's examples show we just have variations. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp From owner-freebsd-net@FreeBSD.ORG Tue Sep 21 23:45:01 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4E24116A4CE; Tue, 21 Sep 2004 23:45:01 +0000 (GMT) Received: from outbound0.sv.meer.net (outbound0.sv.meer.net [205.217.152.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0768443D1D; Tue, 21 Sep 2004 23:45:01 +0000 (GMT) (envelope-from gnn@neville-neil.com) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) i8LNiKr6099452; Tue, 21 Sep 2004 16:44:23 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (pc1.oakwoodazabu1-unet.ocn.ne.jp [220.110.140.201]) by mail.meer.net (8.12.1/8.12.2/meer) with ESMTP id i8LNi3lS011986; Tue, 21 Sep 2004 16:44:03 -0700 (PDT) (envelope-from gnn@neville-neil.com) Date: Wed, 22 Sep 2004 08:44:01 +0900 Message-ID: From: "George V. Neville-Neil" To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= In-Reply-To: References: <20040921123016.GA41677@melusine.cuivre.fr.eu.org> <20040921190717.GG84228@lucky.net> <20040921213233.GA84392@melusine.cuivre.fr.eu.org> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.5 Emacs/21.2 (powerpc-apple-darwin) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=ISO-2022-JP cc: netch@lucky.net cc: freebsd-net@freebsd.org cc: Hajimu UMEMOTO cc: Thomas Quinot Subject: Re: freeaddrinfo(NULL) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 21 Sep 2004 23:45:01 -0000 At Wed, 22 Sep 2004 07:37:20 +0900, JINMEI Tatuya / 神明達哉 wrote: > Note also that other *BSDs and Solaris use the "segfault" logic. The > freeaddrinfo implementation in the "libbind" library as a part of the > ISC BIND package, which many UNIX-like OS vendors adopt (perhaps with > vendor-specific modifications though), also segfaults against a NULL > argument. > > So, although consistency might in general be a good thing, the real > world's examples show we just have variations. > Sorry to come in late on this, but you know I was asleep. One quick comment. It is easier to find and fix the bug that relating to a NULL pointer if the program seg faults than if it continues blithely on. I think we should stick with failing early. Later, George From owner-freebsd-net@FreeBSD.ORG Wed Sep 22 02:10:00 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 030C016A4CE for ; Wed, 22 Sep 2004 02:10:00 +0000 (GMT) Received: from green.homeunix.org (pcp04368961pcs.nrockv01.md.comcast.net [69.140.212.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 37B4843D1D for ; Wed, 22 Sep 2004 02:09:59 +0000 (GMT) (envelope-from green@green.homeunix.org) Received: from green.homeunix.org (green@localhost [127.0.0.1]) by green.homeunix.org (8.13.1/8.13.1) with ESMTP id i8M29wVV069323 for ; Tue, 21 Sep 2004 22:09:58 -0400 (EDT) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.13.1/8.13.1/Submit) id i8M29v0s069322 for net@FreeBSD.org; Tue, 21 Sep 2004 22:09:57 -0400 (EDT) (envelope-from green) Date: Tue, 21 Sep 2004 22:09:57 -0400 From: Brian Fundakowski Feldman To: net@FreeBSD.org Message-ID: <20040922020957.GE84424@green.homeunix.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i Subject: IPv6 route mutex recursion (crash) and fix X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 22 Sep 2004 02:10:00 -0000 I've already made noise about this before, so I'll be brief. I plan on committing the following fix that prevents the routing code from being recursed upon such that RTM_RESOLVE causes the embryonic new route to be looked up again. I realize that probably no one will bother trying to see this bug in action, but all you need to do is send some UDP6 to ff02::1% as a user, with INVARIANTS turned on. Are there any objections? It would be nice to have this in 5-STABLE, in case anyone actually wants to have IPv6. Index: nd6.c =================================================================== RCS file: /usr/ncvs/src/sys/netinet6/nd6.c,v retrieving revision 1.43 diff -u -r1.43 nd6.c --- nd6.c 26 Apr 2004 20:31:46 -0000 1.43 +++ nd6.c 21 Sep 2004 21:15:05 -0000 @@ -105,6 +105,8 @@ int nd6_recalc_reachtm_interval = ND6_RECALC_REACHTM_INTERVAL; static struct sockaddr_in6 all1_sa; +static int nd6_is_new_addr_neighbor __P((struct sockaddr_in6 *, + struct ifnet *)); static void nd6_setmtu0 __P((struct ifnet *, struct nd_ifinfo *)); static void nd6_slowtimo __P((void *)); static int regen_tmpaddr __P((struct in6_ifaddr *)); @@ -869,11 +871,11 @@ } /* - * Detect if a given IPv6 address identifies a neighbor on a given link. - * XXX: should take care of the destination of a p2p link? + * Test whether a given IPv6 address is a neighbor or not, ignoring + * the actual neighbor cache. */ -int -nd6_is_addr_neighbor(addr, ifp) +static int +nd6_is_new_addr_neighbor(addr, ifp) struct sockaddr_in6 *addr; struct ifnet *ifp; { @@ -918,6 +920,23 @@ return (1); } + return (0); +} + + +/* + * Detect if a given IPv6 address identifies a neighbor on a given link. + * XXX: should take care of the destination of a p2p link? + */ +int +nd6_is_addr_neighbor(addr, ifp) + struct sockaddr_in6 *addr; + struct ifnet *ifp; +{ + + if (nd6_is_new_addr_neighbor(addr, ifp)) + return (1); + /* * Even if the address matches none of our addresses, it might be * in the neighbor cache. @@ -1101,7 +1120,8 @@ if (req == RTM_RESOLVE && (nd6_need_cache(ifp) == 0 || /* stf case */ - !nd6_is_addr_neighbor((struct sockaddr_in6 *)rt_key(rt), ifp))) { + !nd6_is_new_addr_neighbor((struct sockaddr_in6 *)rt_key(rt), + ifp))) { /* * FreeBSD and BSD/OS often make a cloned host route based * on a less-specific route (e.g. the default route). -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ From owner-freebsd-net@FreeBSD.ORG Wed Sep 22 02:44:12 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 62C4316A4CE; Wed, 22 Sep 2004 02:44:12 +0000 (GMT) Received: from outbound0.sv.meer.net (outbound0.sv.meer.net [205.217.152.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3FED743D2D; Wed, 22 Sep 2004 02:44:10 +0000 (GMT) (envelope-from gnn@neville-neil.com) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) i8M2hLr2002408; Tue, 21 Sep 2004 19:43:22 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (pc1.oakwoodazabu1-unet.ocn.ne.jp [220.110.140.201]) by mail.meer.net (8.12.1/8.12.2/meer) with ESMTP id i8M2hJlS041865; Tue, 21 Sep 2004 19:43:19 -0700 (PDT) (envelope-from gnn@neville-neil.com) Date: Wed, 22 Sep 2004 11:43:17 +0900 Message-ID: From: "George V. Neville-Neil" To: Brian Fundakowski Feldman In-Reply-To: <20040922020957.GE84424@green.homeunix.org> References: <20040922020957.GE84424@green.homeunix.org> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.5 Emacs/21.2 (powerpc-apple-darwin) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII cc: net@freebsd.org Subject: Re: IPv6 route mutex recursion (crash) and fix X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 22 Sep 2004 02:44:12 -0000 At Tue, 21 Sep 2004 22:09:57 -0400, Brian Fundakowski Feldman wrote: > > I've already made noise about this before, so I'll be brief. I plan on > committing the following fix that prevents the routing code from being > recursed upon such that RTM_RESOLVE causes the embryonic new route to > be looked up again. I realize that probably no one will bother trying > to see this bug in action, but all you need to do is send some UDP6 to > ff02::1% as a user, with INVARIANTS turned on. > > Are there any objections? It would be nice to have this in 5-STABLE, > in case anyone actually wants to have IPv6. Unless I am missing something (I have not applied the patch) it's not doing anything. What does the new code actually do? I'll try to try this patch out later. Later, George From owner-freebsd-net@FreeBSD.ORG Wed Sep 22 02:53:30 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4FC9B16A4CE for ; Wed, 22 Sep 2004 02:53:30 +0000 (GMT) Received: from green.homeunix.org (pcp04368961pcs.nrockv01.md.comcast.net [69.140.212.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id C17FC43D54 for ; Wed, 22 Sep 2004 02:53:29 +0000 (GMT) (envelope-from green@green.homeunix.org) Received: from green.homeunix.org (green@localhost [127.0.0.1]) by green.homeunix.org (8.13.1/8.13.1) with ESMTP id i8M2rT1I069509; Tue, 21 Sep 2004 22:53:29 -0400 (EDT) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.13.1/8.13.1/Submit) id i8M2rLLN069508; Tue, 21 Sep 2004 22:53:21 -0400 (EDT) (envelope-from green) Date: Tue, 21 Sep 2004 22:53:20 -0400 From: Brian Fundakowski Feldman To: "George V. Neville-Neil" Message-ID: <20040922025320.GF84424@green.homeunix.org> References: <20040922020957.GE84424@green.homeunix.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i cc: net@freebsd.org Subject: Re: IPv6 route mutex recursion (crash) and fix X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 22 Sep 2004 02:53:30 -0000 On Wed, Sep 22, 2004 at 11:43:17AM +0900, George V. Neville-Neil wrote: > At Tue, 21 Sep 2004 22:09:57 -0400, > Brian Fundakowski Feldman wrote: > > > > I've already made noise about this before, so I'll be brief. I plan on > > committing the following fix that prevents the routing code from being > > recursed upon such that RTM_RESOLVE causes the embryonic new route to > > be looked up again. I realize that probably no one will bother trying > > to see this bug in action, but all you need to do is send some UDP6 to > > ff02::1% as a user, with INVARIANTS turned on. > > > > Are there any objections? It would be nice to have this in 5-STABLE, > > in case anyone actually wants to have IPv6. > > Unless I am missing something (I have not applied the patch) it's not > doing anything. What does the new code actually do? > > I'll try to try this patch out later. Sorry, I should have provided a higher number of lines of context. It prevents a call to nd6_lookup() and reentry into the route table when entered via RTM_RESOLVE. I.e. nd6_rtrequest(), nd6_is_addr_neighbor(), nd6_lookup(). I appreciate you looking at it; I've had the problem for a year and no one bothered to really look at it. -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ From owner-freebsd-net@FreeBSD.ORG Wed Sep 22 05:55:36 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CCA3D16A4CF for ; Wed, 22 Sep 2004 05:55:36 +0000 (GMT) Received: from terra.ane.cmc.osaka-u.ac.jp (terra.ane.cmc.osaka-u.ac.jp [133.1.74.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 503CF43D53 for ; Wed, 22 Sep 2004 05:55:32 +0000 (GMT) (envelope-from zhang@ist.osaka-u.ac.jp) Received: from [192.168.1.99] (muse.ane.cmc.osaka-u.ac.jp [133.1.74.180]) (authenticated bits=0)i8M5tTet025358 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 22 Sep 2004 14:55:29 +0900 Message-ID: <415113D0.6060302@ist.osaka-u.ac.jp> Date: Wed, 22 Sep 2004 14:55:28 +0900 From: Zongsheng Zhang User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: which parameter == txqueuelen of linux ?? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 22 Sep 2004 05:55:36 -0000 Hello! In Linux, txqueuelen (the length of the transmit queue of the device) can be set by 'ifconfig' command. Is there a corresponding parameter or command in BSD?? -- Zongsheng Zhang zhang@ist.osaka-u.ac.jp From owner-freebsd-net@FreeBSD.ORG Wed Sep 22 07:09:35 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 053EE16A4CE for ; Wed, 22 Sep 2004 07:09:35 +0000 (GMT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id B794243D31 for ; Wed, 22 Sep 2004 07:09:34 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 034476542F for ; Wed, 22 Sep 2004 08:09:34 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 38124-07-2 for ; Wed, 22 Sep 2004 08:09:33 +0100 (BST) Received: from empiric.dek.spc.org (adsl-64-171-185-245.dsl.snfc21.pacbell.net [64.171.185.245]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id 572EC6542A for ; Wed, 22 Sep 2004 08:09:33 +0100 (BST) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id C24066455; Wed, 22 Sep 2004 00:09:30 -0700 (PDT) Date: Wed, 22 Sep 2004 00:09:30 -0700 From: Bruce M Simpson To: freebsd-net@freebsd.org Message-ID: <20040922070930.GB4985@empiric.icir.org> Mail-Followup-To: freebsd-net@freebsd.org References: <20040920184431.GA89606@phat.za.net> <20040921084112.GA21160@phat.za.net> <414FEB86.5CA8694F@freebsd.org> <20040921133825.GB37317@phat.za.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040921133825.GB37317@phat.za.net> Subject: Re: Wierd tunnel+MTU issue X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 22 Sep 2004 07:09:35 -0000 On Tue, Sep 21, 2004 at 03:38:25PM +0200, Aragon Gouveia wrote: > Andre, don't let me stop your bughunting, but I think I've found a nifty > workaround for now. :) > > OpenVPN has an "mssfix" setting. (something vtun seems to lack) Try using ports/net/tcpmssd with vtund and see if you get similar improvements? BMS From owner-freebsd-net@FreeBSD.ORG Wed Sep 22 07:39:51 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A19F716A4CE; Wed, 22 Sep 2004 07:39:51 +0000 (GMT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 54C3E43D49; Wed, 22 Sep 2004 07:39:51 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 39EC3653B5; Wed, 22 Sep 2004 08:39:50 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 39063-01-3; Wed, 22 Sep 2004 08:39:49 +0100 (BST) Received: from empiric.dek.spc.org (adsl-64-171-185-245.dsl.snfc21.pacbell.net [64.171.185.245]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id 1E05D653AD; Wed, 22 Sep 2004 08:39:49 +0100 (BST) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id 1DC7A6455; Wed, 22 Sep 2004 00:39:46 -0700 (PDT) Date: Wed, 22 Sep 2004 00:39:46 -0700 From: Bruce M Simpson To: Brian Fundakowski Feldman Message-ID: <20040922073946.GC4985@empiric.icir.org> References: <20040922020957.GE84424@green.homeunix.org> <20040922025320.GF84424@green.homeunix.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040922025320.GF84424@green.homeunix.org> cc: net@freebsd.org Subject: Re: IPv6 route mutex recursion (crash) and fix X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 22 Sep 2004 07:39:51 -0000 On Tue, Sep 21, 2004 at 10:53:20PM -0400, Brian Fundakowski Feldman wrote: > Sorry, I should have provided a higher number of lines of context. > It prevents a call to nd6_lookup() and reentry into the route table > when entered via RTM_RESOLVE. I.e. nd6_rtrequest(), nd6_is_addr_neighbor(), > nd6_lookup(). I haven't tested your patch but the rationale for this sounds fine. Recursive locking attempts via the lookup code by way of neighbour discovery is a Bad Thing, and it would be useful to keep these semantics working for IPv6. So it looks good to me. BMS From owner-freebsd-net@FreeBSD.ORG Wed Sep 22 07:47:10 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1C4AB16A4CE for ; Wed, 22 Sep 2004 07:47:10 +0000 (GMT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB07643D48 for ; Wed, 22 Sep 2004 07:47:09 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 0AA9C65381; Wed, 22 Sep 2004 08:47:09 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 39063-02; Wed, 22 Sep 2004 08:47:08 +0100 (BST) Received: from empiric.dek.spc.org (adsl-64-171-185-245.dsl.snfc21.pacbell.net [64.171.185.245]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id 4D9CD65339; Wed, 22 Sep 2004 08:47:07 +0100 (BST) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id E37186455; Wed, 22 Sep 2004 00:47:04 -0700 (PDT) Date: Wed, 22 Sep 2004 00:47:04 -0700 From: Bruce M Simpson To: Zongsheng Zhang Message-ID: <20040922074704.GD4985@empiric.icir.org> Mail-Followup-To: Zongsheng Zhang , freebsd-net@freebsd.org References: <415113D0.6060302@ist.osaka-u.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <415113D0.6060302@ist.osaka-u.ac.jp> cc: freebsd-net@freebsd.org Subject: Re: which parameter == txqueuelen of linux ?? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 22 Sep 2004 07:47:10 -0000 On Wed, Sep 22, 2004 at 02:55:28PM +0900, Zongsheng Zhang wrote: > In Linux, txqueuelen (the length of the transmit queue of the device) > can be set by 'ifconfig' command. Is there a corresponding parameter or > command in BSD?? I assume that in Linux, 'txqueuelen' actually refers to the maximum (bounded) size of the device's transmit queue before Linux's equivalent of the IFF_OACTIVE flag is set (device transmit queue full and no more data may be queued). The short answer is no. The long answer is it depends; some device drivers offer a means of doing so, but it's not standard by any means. Most network interfaces in FreeBSD set their if_snd.ifq_maxlen to IFQ_MAXLEN, which is 50 by default. In some cases the device driver won't permit you to touch this value because it's hardcoded to match the size of a descriptor ring which the chip uses for data transmission. BMS From owner-freebsd-net@FreeBSD.ORG Wed Sep 22 08:07:30 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D3C1716A4CE for ; Wed, 22 Sep 2004 08:07:30 +0000 (GMT) Received: from burka.carrier.kiev.ua (burka.carrier.kiev.ua [193.193.193.107]) by mx1.FreeBSD.org (Postfix) with ESMTP id 17F2843D2D for ; Wed, 22 Sep 2004 08:07:30 +0000 (GMT) (envelope-from netch@lucky.net) Received: from burka.carrier.kiev.ua (netch@localhost [127.0.0.1]) by burka.carrier.kiev.ua with ESMTP id i8M87NG2023449; Wed, 22 Sep 2004 11:07:24 +0300 (EEST) (envelope-from netch@burka.carrier.kiev.ua) Received: (from netch@localhost) by burka.carrier.kiev.ua (8.12.11/8.12.11/Submit) id i8M87MPg023446; Wed, 22 Sep 2004 11:07:22 +0300 (EEST) (envelope-from netch) Date: Wed, 22 Sep 2004 11:07:22 +0300 From: Valentin Nechayev To: "JINMEI Tatuya / ?$B?@L@C#:H" Message-ID: <20040922080722.GS89036@lucky.net> References: <20040921123016.GA41677@melusine.cuivre.fr.eu.org> <20040921190717.GG84228@lucky.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-42: On X-Verify-Sender: Address has been verified (burka.carrier.kiev.ua) cc: freebsd-net@freebsd.org Subject: Re: freeaddrinfo(NULL) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: netch@lucky.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Sep 2004 08:07:30 -0000 Wed, Sep 22, 2004 at 05:07:13, jinmei wrote about "Re: freeaddrinfo(NULL)": > I was not talking about things like whether NULL had been specially > designed or not. I was basically talking about any invalid argument > to freeaddrinfo. Well, garbage in pointer is unquestionably invalid, but whether NULL is invalid it's discussable (and flammable) question. Initing pointer to NULL is popular method and it's reasonable to keep it working without extra actions, as verifying !=NULL at freeing. As this discussion has no common with -net questions, I propose to move it to some another list. > However, since the API > specification is silent on this, I'd then request that the man page > make an explicit note that the application programmer should be check > if the argument to freeaddrinfo() is valid because passing a NULL > pointer may cause an unexpected result, including segfaulting, on > other systems. Agreed. -netch- From owner-freebsd-net@FreeBSD.ORG Wed Sep 22 16:18:06 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 38A2916A4CE for ; Wed, 22 Sep 2004 16:18:06 +0000 (GMT) Received: from beer.ux6.net (beer.ux6.net [64.62.253.29]) by mx1.FreeBSD.org (Postfix) with SMTP id D414043D1F for ; Wed, 22 Sep 2004 16:18:03 +0000 (GMT) (envelope-from miha@ghuug.org) Received: (qmail 61612 invoked by uid 113); 22 Sep 2004 09:18:03 -0700 Received: from 205.177.65.128 by beer.ux6.net (envelope-from , uid 112) with qmail-scanner-1.23 (clamdscan: 0.70. spamassassin: 2.64. Clear:RC:0(205.177.65.128):SA:0(2.3/6.0):. Processed in 0.894836 secs); 22 Sep 2004 16:18:03 -0000 X-Spam-Status: No, hits=2.3 required=6.0 X-Spam-Level: ++ Received: from unknown (HELO ?192.168.0.3?) (miha@beer.ux6.net@205.177.65.128) by localhost with SMTP; 22 Sep 2004 09:18:02 -0700 From: "Mikhail P." Organization: Ghana Unix Users Group To: net@freebsd.org Date: Wed, 22 Sep 2004 16:17:59 +0000 User-Agent: KMail/1.7 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200409221617.59860.miha@ghuug.org> Subject: question on tunnels (VPN) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: miha@ghuug.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Sep 2004 16:18:06 -0000 Dear users, I have been experimenting with simple gif tunnels (no IPSec) in local network (192.168.0.0/24). I have used the following scenario between two hosts (both running FreeBSD-5.2.1): HOST_A [192.168.0.1]: ifconfig gif0 create ifconfig gif0 tunnel 192.168.0.1 192.168.0.2 ifconfig gif0 10.0.0.1 10.0.0.2 netmask 255.255.255.255 and on - HOST_B [192.168.0.2]: ifconfig gif0 create ifconfig gif0 tunnel 192.168.0.2 192.168.0.1 ifconfig gif0 10.0.0.2 10.0.0.1 netmask 255.255.255.255 The above works well for me, and I can send traffic on 10.0.0.1 and 10.0.0.2. The next thing I wanted to implement is to create similar tunnel from our local router (which is FreeBSD too) to remote server, however there is small problem which stops me - router has no public IP, and it sees internet through DSL router, so basically that router is NAT'ed behind DSL router. As far as I understand, it appears to be that I won't be able to create such a simple tunnel, unless my router gets public IP address. What I tried next was MPD pptp link (which is known to work behind NAT, unlike above example), but something (ISP? DSL router?) cuts GRE packets on their way, so MPD can't establish LCP connection with remote host. I'm now in loss as to what to try next - could someone please advise what other techniques will work in my scenario (where I want to connect machine which is behind NAT and no GRE packets will go through)? regards, M. From owner-freebsd-net@FreeBSD.ORG Wed Sep 22 21:26:47 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2E78816A4CE for ; Wed, 22 Sep 2004 21:26:47 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 11CD643D1F for ; Wed, 22 Sep 2004 21:26:47 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 941277A3D2; Wed, 22 Sep 2004 14:26:46 -0700 (PDT) Message-ID: <4151EE16.1020100@elischer.org> Date: Wed, 22 Sep 2004 14:26:46 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: miha@ghuug.org References: <200409221617.59860.miha@ghuug.org> In-Reply-To: <200409221617.59860.miha@ghuug.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: net@freebsd.org Subject: Re: question on tunnels (VPN) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 22 Sep 2004 21:26:47 -0000 Mikhail P. wrote: >Dear users, > >I have been experimenting with simple gif tunnels (no IPSec) in local network >(192.168.0.0/24). I have used the following scenario between two hosts (both >running FreeBSD-5.2.1): > >HOST_A [192.168.0.1]: >ifconfig gif0 create >ifconfig gif0 tunnel 192.168.0.1 192.168.0.2 >ifconfig gif0 10.0.0.1 10.0.0.2 netmask 255.255.255.255 > >and on - > >HOST_B [192.168.0.2]: >ifconfig gif0 create >ifconfig gif0 tunnel 192.168.0.2 192.168.0.1 >ifconfig gif0 10.0.0.2 10.0.0.1 netmask 255.255.255.255 > >The above works well for me, and I can send traffic on 10.0.0.1 and 10.0.0.2. > >The next thing I wanted to implement is to create similar tunnel from our >local router (which is FreeBSD too) to remote server, however there is small >problem which stops me - router has no public IP, and it sees internet >through DSL router, so basically that router is NAT'ed behind DSL router. >As far as I understand, it appears to be that I won't be able to create such a >simple tunnel, unless my router gets public IP address. > >What I tried next was MPD pptp link (which is known to work behind NAT, unlike >above example), but something (ISP? DSL router?) cuts GRE packets on their >way, so MPD can't establish LCP connection with remote host. > >I'm now in loss as to what to try next - could someone please advise what >other techniques will work in my scenario (where I want to connect machine >which is behind NAT and no GRE packets will go through)? > I use MPD using the "UDP" transport. in other words packets get sent as udp packets. I then set up IPSEC to encrypt the UDP packets.. when I had a NAT in the way I did further encapsulate the GRE packets in UDP again :-) From owner-freebsd-net@FreeBSD.ORG Wed Sep 22 23:04:23 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A6D0616A4CE for ; Wed, 22 Sep 2004 23:04:23 +0000 (GMT) Received: from beer.ux6.net (beer.ux6.net [64.62.253.29]) by mx1.FreeBSD.org (Postfix) with SMTP id 74E1143D1F for ; Wed, 22 Sep 2004 23:04:23 +0000 (GMT) (envelope-from miha@ghuug.org) Received: (qmail 83571 invoked by uid 113); 22 Sep 2004 16:04:21 -0700 Received: from 205.177.65.128 by beer.ux6.net (envelope-from , uid 112) with qmail-scanner-1.23 (clamdscan: 0.70. spamassassin: 2.64. Clear:RC:0(205.177.65.128):SA:0(2.3/6.0):. Processed in 0.679993 secs); 22 Sep 2004 23:04:21 -0000 X-Spam-Status: No, hits=2.3 required=6.0 X-Spam-Level: ++ Received: from unknown (HELO ?192.168.0.3?) (miha@beer.ux6.net@205.177.65.128) by localhost with SMTP; 22 Sep 2004 16:04:20 -0700 From: "Mikhail P." Organization: Ghana Unix Users Group To: freebsd-net@freebsd.org Date: Wed, 22 Sep 2004 23:04:18 +0000 User-Agent: KMail/1.7 References: <200409221617.59860.miha@ghuug.org> <4151EE16.1020100@elischer.org> In-Reply-To: <4151EE16.1020100@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200409222304.18427.miha@ghuug.org> cc: Julian Elischer Subject: Re: question on tunnels (VPN) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: miha@ghuug.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Sep 2004 23:04:23 -0000 On Wednesday 22 September 2004 21:26, Julian Elischer wrote: > I use MPD using the "UDP" transport. > > in other words packets get sent as udp packets. > > I then set up IPSEC to encrypt the UDP packets.. > > when I had a NAT in the way I did further encapsulate the GRE packets in > UDP again :-) Julian, Thank you for your quick response. Do you have any pointers on how to implement such setup to send traffic as UDP in MPD? regards, M. From owner-freebsd-net@FreeBSD.ORG Wed Sep 22 23:18:35 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5FCF416A4CE for ; Wed, 22 Sep 2004 23:18:35 +0000 (GMT) Received: from mailout2.barnet.com.au (mailout2.barnet.com.au [218.185.88.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id A322E43D53 for ; Wed, 22 Sep 2004 23:18:34 +0000 (GMT) (envelope-from edwin@mavetju.org) Received: by mailout2.barnet.com.au (Postfix, from userid 27) id 0C2E570749D; Thu, 23 Sep 2004 09:18:33 +1000 (EST) X-Viruscan-Id: <4152084800015B308BF4F6@BarNet> Received: from mail2-auth.barnet.com.au (localhost.barnet.com.au [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) Authority" (verified OK)) by mail2.barnet.com.au (Postfix) with ESMTP id BB6F470749C; Thu, 23 Sep 2004 09:18:32 +1000 (EST) Received: from k7.mavetju (edwin-3.int.barnet.com.au [10.10.12.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) Certificate Authority" (verified OK)) by mail2-auth.barnet.com.au (Postfix) with ESMTP id 2E9EC707455; Thu, 23 Sep 2004 09:18:32 +1000 (EST) Received: by k7.mavetju (Postfix, from userid 1001) id CB8E761C5; Thu, 23 Sep 2004 09:18:30 +1000 (EST) Date: Thu, 23 Sep 2004 09:18:30 +1000 From: Edwin Groothuis To: "Mikhail P." Message-ID: <20040922231830.GA1234@k7.mavetju> References: <200409221617.59860.miha@ghuug.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200409221617.59860.miha@ghuug.org> User-Agent: Mutt/1.5.6i cc: net@freebsd.org Subject: Re: question on tunnels (VPN) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 22 Sep 2004 23:18:35 -0000 On Wed, Sep 22, 2004 at 04:17:59PM +0000, Mikhail P. wrote: > HOST_A [192.168.0.1]: > ifconfig gif0 create > ifconfig gif0 tunnel 192.168.0.1 192.168.0.2 > ifconfig gif0 10.0.0.1 10.0.0.2 netmask 255.255.255.255 > > and on - > > HOST_B [192.168.0.2]: > ifconfig gif0 create > ifconfig gif0 tunnel 192.168.0.2 192.168.0.1 > ifconfig gif0 10.0.0.2 10.0.0.1 netmask 255.255.255.255 > > The above works well for me, and I can send traffic on 10.0.0.1 and 10.0.0.2. > > The next thing I wanted to implement is to create similar tunnel from our > local router (which is FreeBSD too) to remote server, however there is small > problem which stops me - router has no public IP, and it sees internet > through DSL router, so basically that router is NAT'ed behind DSL router. > As far as I understand, it appears to be that I won't be able to create such a > simple tunnel, unless my router gets public IP address. I have the same situation here and the solution was to let the ADSL router forward all unknown traffic to my router. How to do that is router specific, but it can be done. Then, with the tunnels: central# ifconfig gif1 inet gif1: flags=8051 mtu 1280 tunnel inet 218.185.88.66 --> 203.111.122.8 inet 10.10.12.1 --> 10.10.12.2 netmask 0xffffffff remote# ifconfig gif1 inet gif1: flags=8051 mtu 1280 tunnel inet 192.168.1.1 --> 218.185.88.66 inet 10.10.12.2 --> 10.10.12.1 netmask 0xffffff00 203.111.122.8 is my ADSL routers address. 192.168.1.1 is my computers RFC1918 address. Two static routes, one on each machine, and it works. Edwin -- Edwin Groothuis | Personal website: http://www.mavetju.org edwin@mavetju.org | Weblog: http://weblog.barnet.com.au/edwin/ From owner-freebsd-net@FreeBSD.ORG Wed Sep 22 23:51:12 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7FAF916A4CE for ; Wed, 22 Sep 2004 23:51:12 +0000 (GMT) Received: from beer.ux6.net (beer.ux6.net [64.62.253.29]) by mx1.FreeBSD.org (Postfix) with SMTP id 55CEA43D49 for ; Wed, 22 Sep 2004 23:51:12 +0000 (GMT) (envelope-from miha@ghuug.org) Received: (qmail 33316 invoked by uid 113); 22 Sep 2004 16:51:12 -0700 Received: from 205.177.65.128 by beer.ux6.net (envelope-from , uid 112) with qmail-scanner-1.23 (clamdscan: 0.70. spamassassin: 2.64. Clear:RC:0(205.177.65.128):SA:0(2.3/6.0):. Processed in 0.62118 secs); 22 Sep 2004 23:51:12 -0000 X-Spam-Status: No, hits=2.3 required=6.0 X-Spam-Level: ++ Received: from unknown (HELO ?192.168.0.3?) (miha@beer.ux6.net@205.177.65.128) by localhost with SMTP; 22 Sep 2004 16:51:11 -0700 From: "Mikhail P." Organization: Ghana Unix Users Group To: freebsd-net@freebsd.org Date: Wed, 22 Sep 2004 23:51:09 +0000 User-Agent: KMail/1.7 References: <200409221617.59860.miha@ghuug.org> <20040922231830.GA1234@k7.mavetju> In-Reply-To: <20040922231830.GA1234@k7.mavetju> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200409222351.09475.miha@ghuug.org> cc: Edwin Groothuis Subject: Re: question on tunnels (VPN) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: miha@ghuug.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Sep 2004 23:51:12 -0000 On Wednesday 22 September 2004 23:18, Edwin Groothuis wrote: > I have the same situation here and the solution was to let the ADSL > router forward all unknown traffic to my router. How to do that is > router specific, but it can be done. > > Then, with the tunnels: > > central# ifconfig gif1 inet > gif1: flags=3D8051 mtu 1280 > =9A =9A =9A =9A tunnel inet 218.185.88.66 --> 203.111.122.8 > =9A=9A=9A=9A=9A=9A=9A=9Ainet 10.10.12.1 --> 10.10.12.2 netmask 0xffffffff > > remote# ifconfig gif1 inet > gif1: flags=3D8051 mtu 1280 > =9A =9A =9A =9A tunnel inet 192.168.1.1 --> 218.185.88.66 > =9A=9A=9A=9A=9A=9A=9A=9Ainet 10.10.12.2 --> 10.10.12.1 netmask 0xffffff00 > > 203.111.122.8 is my ADSL routers address. > 192.168.1.1 is my computers RFC1918 address. > > Two static routes, one on each machine, and it works. > Thanks for pointer! I will check this with DSL router I have. There, however, might be another problem - my DSL router could be also NAT'= ed=20 (and most likely it is), so it draws us the following picture: (LAN) <-NAT-> (FreeBSD) <-NAT-> DSL Router <- ??? -> ISP/Internet Basically I'm unsure whether "???" is a normal, direct connection to intern= et=20 via ISP, or it is also NAT'ed. I'm most sure that it is NAT, because I've been getting one IP (e.g. my pub= lic=20 IP on the net as I appear) for ~1 month (e.g. it never changed, although=20 there is DHCP of course). Well, hell knows how many further NATs I have there - at least I know about= =20 two already. I guess time to visit ISP.. > Edwin regards, M. From owner-freebsd-net@FreeBSD.ORG Thu Sep 23 00:15:20 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6643B16A4CF; Thu, 23 Sep 2004 00:15:07 +0000 (GMT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5C60443D49; Thu, 23 Sep 2004 00:15:07 +0000 (GMT) (envelope-from max@love2party.net) Received: from [212.227.126.209] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1CAHGM-0004lG-00; Thu, 23 Sep 2004 02:15:06 +0200 Received: from [217.83.8.169] (helo=donor.laier.local) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1CAHGM-0007dJ-00; Thu, 23 Sep 2004 02:15:06 +0200 From: Max Laier To: freebsd-arch@freebsd.org Date: Thu, 23 Sep 2004 02:14:00 +0200 User-Agent: KMail/1.7 References: <200409200250.49518.max@love2party.net> In-Reply-To: <200409200250.49518.max@love2party.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2497037.U2RBP6rdQP"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200409230214.08477.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:61c499deaeeba3ba5be80f48ecc83056 cc: freebsd-hackers@freebsd.org cc: freebsd-standards@freebsd.org cc: freebsd-net@freebsd.org Subject: Re: Global (non _KERNEL) place for sockaddr_union? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 23 Sep 2004 00:15:21 -0000 --nextPart2497037.U2RBP6rdQP Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 20 September 2004 02:50, Max Laier wrote: > Hi, > > http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/71836 is the symptom. N= ow I > am looking for a clean solution to it. What is needed is an include file > that defines union sockaddr_union in a way that is useable from kernel and > userland. Historically it seems that this union first apeared in context = of > ipsec within the kernel. pf has adopted it, but uses it in the userland as > well. I am sure that it can be usefull in a lot of places that have to de= al > with/store different address formats. > > My question now is, what would be a good place to define this? Are there > any fromal standarts that might define it already? (Couldn't find anythin= g) > Is there anything else that I must consider? > > At some point I though netinet/in.h might be a good place, but that'd > require inclusion of sys/socket.h, which certainly is not a good solution. > > Opinions? Ideas? As no real solution has come up and we couldn't agree what to do with it=20 either, I'll resort to an easy hack:=20 http://people.freebsd.org/~mlaier/sockaddr_union.fix.diff This will fix the issue and not create new problems. With the small excepti= on=20 for userland programs that try to include before=20 and make use of sockaddr_union. Those programs do not exist,= =20 however, and have been broken before. Any objections? [ I know it's ugly already. ] =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart2497037.U2RBP6rdQP Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBBUhVQXyyEoT62BG0RAoYnAJ9SzMK7ZPV3NYZ36DYJlj53KFNqjgCfQ2YO J3R7FE7EG21pdyvCi0DM6aA= =I8lU -----END PGP SIGNATURE----- --nextPart2497037.U2RBP6rdQP-- From owner-freebsd-net@FreeBSD.ORG Thu Sep 23 01:19:54 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5237A16A4CF for ; Thu, 23 Sep 2004 01:19:54 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D25743D5E for ; Thu, 23 Sep 2004 01:19:54 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id CFE027A3D2; Wed, 22 Sep 2004 18:19:53 -0700 (PDT) Message-ID: <415224B9.6070603@elischer.org> Date: Wed, 22 Sep 2004 18:19:53 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: miha@ghuug.org References: <200409221617.59860.miha@ghuug.org> <4151EE16.1020100@elischer.org> <200409222304.18427.miha@ghuug.org> In-Reply-To: <200409222304.18427.miha@ghuug.org> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: question on tunnels (VPN) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 23 Sep 2004 01:19:54 -0000 Mikhail P. wrote: >On Wednesday 22 September 2004 21:26, Julian Elischer wrote: > > >>I use MPD using the "UDP" transport. >> >>in other words packets get sent as udp packets. >> >>I then set up IPSEC to encrypt the UDP packets.. >> >>when I had a NAT in the way I did further encapsulate the GRE packets in >>UDP again :-) >> >> > >Julian, > >Thank you for your quick response. >Do you have any pointers on how to implement such setup to send traffic as UDP >in MPD? > > look under 'link commands' in the mpd docs. here are my (obfuscated) config files.. # cat mpd.conf default: set login ConsoleLogin log -console load vpn-lax load vpn-chi vpn_standard: set iface disable on-demand set iface idle 0 set iface mtu 1500 set ipcp yes vjcomp set bundle enable multilink # set bundle enable round-robin tun_standard: set link yes acfcomp protocomp set link no pap set link no chap set link keep-alive 2 15 set link mru 900 set link mtu 900 # set link bandwidth 1440000 ############### per-link settings ################# vpn-lax: new -i ng0 vpn-lax lax-ISP-B lax-ISP-A set iface addrs 10.x.x.x 10.z.z.z set iface route 192.168.aa.0/24 set ipcp ranges 10.x.x.x/32 10.z.z.z/32 load vpn_standard link lax-ISP-B load tun_standard link lax-ISP-A load tun_standard open vpn-chi: new -i ng1 vpn-chi chi-ISP-B chi-ISP-A set iface addrs 10.x.x.x 10.y.y.y set iface route 192.168.bb.0/24 set ipcp ranges 10.x.x.x/32 10.y.y.y/32 load vpn_standard link chi-ISP-B load tun_standard link chi-ISP-A load tun_standard open # cat mpd.links lax-ISP-B: set link type udp set udp self bb.bb.bb.bb 4029 set udp peer aa.aa.aa.aa 4029 lax-ISP-A: set link type udp set udp self dd.dd.dd.dd 4029 set udp peer cc.cc.cc.cc 4029 chi-ISP-B: set link type udp set udp self bb.bb.bb.bb 4028 set udp peer ee.ee.ee.ee 4028 chi-ISP-A: set link type udp set udp self dd.dd.dd.dd 4028 set udp peer ff.ff.ff.ff 4028 these are the config files for a machine on the internet that is connected to 2 other sites. in LA and Chicago for example, Each site has a network behind it in the 192.168 range. The links themselves are in the 10.xx.xx.xx range. There are two LINKs for each bundle as we connect to the interent via 2 ISPs at each site and use MPDs bonding to provide failover and soft degradation. probably you don't have 2 ISPs.. In addition to this we have ipsec set up as follows: # cat /etc/ipsec.conf flush; spdflush; # LAX spdadd aa.aa.aa.aa bb.bb.bb.bb any -P in ipsec esp/transport//require; spdadd bb.bb.bb.bb aa.aa.aa.aa any -P out ipsec esp/transport//require; spdadd cc.cc.cc.cc dd.dd.dd.dd any -P in ipsec esp/transport//require; spdadd dd.dd.dd.dd cc.cc.cc.cc any -P out ipsec esp/transport//require; # Chicago spdadd bb.bb.bb.bb ee.ee.ee.ee any -P out ipsec esp/transport//require; spdadd ee.ee.ee.ee bb.bb.bb.bb any -P in ipsec esp/transport//require; spdadd dd.dd.dd.dd ff.ff.ff.ff any -P out ipsec esp/transport//require; spdadd ff.ff.ff.ff dd.dd.dd.dd any -P in ipsec esp/transport//require; and we run racoon for key serving.. this is the simplest config file we sometimes use: (when we have just pre-shared secrets to start off the sequence) normally we use certs but it gets trickier.. path pre_shared_key "/usr/local/etc/racoon/psk.txt" ; path certificate "/usr/local/etc/cert" ; log notify; padding { maximum_length 20; # maximum padding length. randomize off; # enable randomize length. strict_check off; # enable strict check. exclusive_tail off; # extract last one octet. } listen { isakmp bb.bb.bb.bb [500]; isakmp dd.dd.dd.dd [500]; strict_address; # required all addresses must be bound. } timer { # These value can be changed per remote node. counter 5; # maximum trying count to send. interval 20 sec; # maximum interval to resend. persend 1; # the number of packets per a send. # timer for waiting to complete each phase. phase1 30 sec; phase2 15 sec; } remote anonymous { #exchange_mode main,aggressive; exchange_mode aggressive,main; doi ipsec_doi; situation identity_only; my_identifier address; nonce_size 16; lifetime time 10 min; # sec,min,hour initial_contact on; support_mip6 off; proposal_check obey; # obey, strict or claim proposal { encryption_algorithm 3des; hash_algorithm sha1; authentication_method pre_shared_key ; dh_group 2 ; } } sainfo anonymous { pfs_group 1; lifetime time 10 min; encryption_algorithm 3des ; authentication_algorithm hmac_sha1; compression_algorithm deflate ; } don't forget to set.. sysctl net.key.prefered_oldsa=0 I'll leave the firewalls and routing to you :-) >regards, >M. > > From owner-freebsd-net@FreeBSD.ORG Thu Sep 23 06:19:46 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B094B16A4CE; Thu, 23 Sep 2004 06:19:46 +0000 (GMT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1B62E43D2F; Thu, 23 Sep 2004 06:19:46 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 63E04651F7; Thu, 23 Sep 2004 07:19:44 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 56232-03; Thu, 23 Sep 2004 07:19:43 +0100 (BST) Received: from empiric.dek.spc.org (adsl-64-171-185-240.dsl.snfc21.pacbell.net [64.171.185.240]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id 49AA5651F4; Thu, 23 Sep 2004 07:19:43 +0100 (BST) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id 4E70F63D3; Wed, 22 Sep 2004 23:19:40 -0700 (PDT) Date: Wed, 22 Sep 2004 23:19:40 -0700 From: Bruce M Simpson To: Max Laier Message-ID: <20040923061940.GA870@empiric.icir.org> Mail-Followup-To: Max Laier , freebsd-arch@freebsd.org, freebsd-hackers@freebsd.org, freebsd-standards@freebsd.org, freebsd-net@freebsd.org References: <200409200250.49518.max@love2party.net> <200409230214.08477.max@love2party.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NzB8fVQJ5HfG6fxh" Content-Disposition: inline In-Reply-To: <200409230214.08477.max@love2party.net> cc: freebsd-hackers@freebsd.org cc: freebsd-net@freebsd.org cc: freebsd-standards@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: Global (non _KERNEL) place for sockaddr_union? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 23 Sep 2004 06:19:47 -0000 --NzB8fVQJ5HfG6fxh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Greetings earthmen, On Thu, Sep 23, 2004 at 02:14:00AM +0200, Max Laier wrote: > As no real solution has come up and we couldn't agree what to do with it= =20 > either, I'll resort to an easy hack:=20 > http://people.freebsd.org/~mlaier/sockaddr_union.fix.diff =2E.. > Any objections? [ I know it's ugly already. ] Looks fine to me; I agree that this workaround is not ideal but it is acceptable given the circumstances. Regards, BMS --NzB8fVQJ5HfG6fxh Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Comment: '' iD8DBQFBUmr7ueUpAYYNtTsRAk91AJ4/PL+dXh5v+8ne91fS0n/RGtZlkgCfavC8 I38NJmMOCN9m0ZgiR8+uQX8= =mtHb -----END PGP SIGNATURE----- --NzB8fVQJ5HfG6fxh-- From owner-freebsd-net@FreeBSD.ORG Thu Sep 23 07:55:37 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 90CDD16A4CE for ; Thu, 23 Sep 2004 07:55:37 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 25F0C43D68 for ; Thu, 23 Sep 2004 07:55:37 +0000 (GMT) (envelope-from ilmar@watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.13.1/8.13.1) with ESMTP id i8N7stQx055273 for ; Thu, 23 Sep 2004 03:54:55 -0400 (EDT) (envelope-from ilmar@watson.org) Received: from localhost (ilmar@localhost)i8N7ssF0055270 for ; Thu, 23 Sep 2004 03:54:55 -0400 (EDT) (envelope-from ilmar@watson.org) X-Authentication-Warning: fledge.watson.org: ilmar owned process doing -bs Date: Thu, 23 Sep 2004 03:54:53 -0400 (EDT) From: "Ilmar S. Habibulin" To: freebsd-net@freebsd.org In-Reply-To: <20040923061940.GA870@empiric.icir.org> Message-ID: <20040923034027.I54861@fledge.watson.org> References: <200409200250.49518.max@love2party.net> <200409230214.08477.max@love2party.net> <20040923061940.GA870@empiric.icir.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: How to insert ip option? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 23 Sep 2004 07:55:37 -0000 I'm trying to use TrustedBSD MAC network subsytem hooks to implement MLS packet labeling. These hooks are mac_update_mbuf_from_cipso() and mac_create_inpcb_from_socket(). The first one is called in ip_dooptions() in order to label mbuf with packets' label. The second fills inp->inp_options. As i understand this must point to mbuf, holding ip options (struct ipoptions), which later will be inserted in the outgoing packet. Options are inserted, peer IP level recognizes and processes them correctly. But TCP level drops the packet because of invalid check sum. I've used this scheme in 2.2.5 and 5.0-current(april or may 2002), but it didn't work in 5.2.1. How can i figure out my mistake, or what may i do wrong? thanks in advance From owner-freebsd-net@FreeBSD.ORG Thu Sep 23 10:13:48 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1CD7E16A4CE for ; Thu, 23 Sep 2004 10:13:48 +0000 (GMT) Received: from smtp07.web.de (smtp07.web.de [217.72.192.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id CA5E743D53 for ; Thu, 23 Sep 2004 10:13:47 +0000 (GMT) (envelope-from Waldemar.Kornewald@web.de) Received: from [80.134.73.165] (helo=[80.134.73.165]) by smtp07.web.de with asmtp (TLSv1:RC4-MD5:128) (WEB.DE 4.101 #44) id 1CAQbj-000286-00 for freebsd-net@freebsd.org; Thu, 23 Sep 2004 12:13:47 +0200 Message-ID: <4152A184.9020301@web.de> Date: Thu, 23 Sep 2004 12:12:20 +0200 From: Waldemar Kornewald User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: FreeBSD-net X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: Waldemar.Kornewald@web.de X-Sender: Waldemar.Kornewald@web.de Subject: creating default route in kernel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 23 Sep 2004 10:13:48 -0000 Hi, could you please tell me how I can create a default route from within the kernel? I am a member of the Haiku (OS) networking team and maintainer of the PPP stack and for dial-on-demand support there must be a default route which does not work. BTW, we use a port of your netstack (from the 4.x releases, I think). Which values should the default route get (netmask, destination, etc.) and which function(s) should I call (our PPP stack lives in the kernel)? Thank you. Bye, Waldemar Kornewald From owner-freebsd-net@FreeBSD.ORG Thu Sep 23 10:24:01 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3AFED16A4CE for ; Thu, 23 Sep 2004 10:24:01 +0000 (GMT) Received: from smtp08.web.de (smtp08.web.de [217.72.192.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id F241543D5A for ; Thu, 23 Sep 2004 10:24:00 +0000 (GMT) (envelope-from Waldemar.Kornewald@web.de) Received: from [80.134.73.165] (helo=[80.134.73.165]) by smtp08.web.de with asmtp (TLSv1:RC4-MD5:128) (WEB.DE 4.101 #44) id 1CAQlb-0008RA-00 for freebsd-net@freebsd.org; Thu, 23 Sep 2004 12:24:00 +0200 Message-ID: <4152A3E9.8080700@web.de> Date: Thu, 23 Sep 2004 12:22:33 +0200 From: Waldemar Kornewald User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: FreeBSD-net X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: Waldemar.Kornewald@web.de X-Sender: Waldemar.Kornewald@web.de Subject: locking X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 23 Sep 2004 10:24:01 -0000 Hi again, we at the Haiku networking team are considering a port of your 5.3 netstack because it is thread-safe and making the old one (4.x, I think) thread-safe is probably a much bigger task. Now, I saw that the routing code seems to use macros for the locking code. Do you use macros everywhere? We would prefer having native threads and locks. Haiku only has semaphores, not mutexes, is that a problem? Could you think of some other difficulties we could run into when porting it? Thank you. Bye, Waldemar Kornewald From owner-freebsd-net@FreeBSD.ORG Thu Sep 23 12:03:58 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0F49116A4CE for ; Thu, 23 Sep 2004 12:03:58 +0000 (GMT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id D16C843D4C for ; Thu, 23 Sep 2004 12:03:56 +0000 (GMT) (envelope-from pekkas@netcore.fi) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i8NC3li07158; Thu, 23 Sep 2004 15:03:47 +0300 Date: Thu, 23 Sep 2004 15:03:47 +0300 (EEST) From: Pekka Savola To: snap-users@kame.net Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org Subject: Weird memory exhaustion with FreeBSD 4.10-STABLE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 23 Sep 2004 12:03:58 -0000 Hi, I've been suffering from a weird memory exhaustion problem (or so it looks?!) on FreeBSD 4.10 -STABLE for a year or two now (obviously, then it was something like 4.5 or the like :). After the system has been up for a while (a couple of weeks) and/or the ethernet link has gone up/down for some time (I suspect this is related to the Neighbor Discovery cache contents), I get dmesg errors like: nd6_lookup: failed to add route for a neighbor(fe80:0001::0290:6900:4276:4d7b), errno=55 nd6_lookup: failed to add route for a neighbor(2001:0708:0:0001::0625), errno=55 (55 is 'No buffer space available'.) (However, if you look at the 'top' output below, the whole swap is still pretty much unused..) Some other commands then also cease to work, e.g., 'ifconfig' displays nothing, and gives something like 'interface stf0 does not exist' for interfaces that are up and running. The system still works otherwise. There's nothing really fancy about this system, it's just a 6to4 relay router. The "weirdest" thing is probably that it has address 2001:0708:0:1::624/125 [ie, not /64] configured on its xl0 interface. I can reproduce this on this particular box, so I can do some tests or debugging if needed. Ideas? ... A few outputs (when there is a problem) which might help: sixpack# netstat -m 129/2048/6144 mbufs in use (current/peak/max): 129 mbufs allocated to data 128/232/1536 mbuf clusters in use (current/peak/max) 976 Kbytes allocated to network (21% of mb_map in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines sixpack# top last pid: 78282; load averages: 0.00, 0.00, 0.00 up 33+09:44:56 17:22:47 20 processes: 1 running, 19 sleeping CPU states: % user, % nice, % system, % interrupt, % idle Mem: 12M Active, 20M Inact, 24M Wired, 3424K Cache, 14M Buf, 780K Free Swap: 132M Total, 112K Used, 132M Free PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND 34357 root 2 0 5288K 1612K select 0:00 0.05% 0.05% sshd 104 root 2 0 984K 548K select 426:12 0.00% 0.00% syslogd 146 root 2 0 1896K 944K select 404:35 0.00% 0.00% zebra 148 root 2 0 3644K 2512K select 17:30 0.00% 0.00% bgpd 121 root 2 0 3048K 1628K select 7:06 0.00% 0.00% sendmail 116 root 2 0 2588K 1364K select 1:33 0.00% 0.00% sshd 114 root 10 0 1000K 600K nanslp 1:02 0.00% 0.00% cron 77556 root 3 0 956K 532K ttyin 0:57 0.00% 0.00% getty 124 smmsp 18 0 2928K 1412K pause 0:08 0.00% 0.00% sendmail 112 root 2 0 1076K 616K select 0:08 0.00% 0.00% inetd 34359 root 18 0 1368K 872K pause 0:00 0.00% 0.00% csh 78282 root 31 0 1892K 888K RUN 0:00 0.00% 0.00% top 197 root 3 0 956K 532K ttyin 0:00 0.00% 0.00% getty 198 root 3 0 956K 532K ttyin 0:00 0.00% 0.00% getty 200 root 3 0 956K 532K ttyin 0:00 0.00% 0.00% getty 201 root 3 0 956K 532K ttyin 0:00 0.00% 0.00% getty 199 root 3 0 956K 532K ttyin 0:00 0.00% 0.00% getty 195 root 3 0 956K 532K ttyin 0:00 0.00% 0.00% getty 196 root 3 0 956K 532K ttyin 0:00 0.00% 0.00% getty 24 root 18 0 212K 68K pause 0:00 0.00% 0.00% adjkerntz sixpack# dmesg nd6_lookup: failed to add route for a neighbor(fe80:0001::0290:6900:4276:4d7b), errno=55 nd6_lookup: failed to add route for a neighbor(fe80:0001::0290:6900:4276:4d7b), errno=55 nd6_lookup: failed to add route for a neighbor(2001:0708:0:0001::0625), errno=55 nd6_lookup: failed to add route for a neighbor(fe80:0001::0290:6900:4276:4d7b), errno=55 nd6_lookup: failed to add route for a neighbor(fe80:0001::0290:6900:4276:4d7b), errno=55 nd6_lookup: failed to add route for a neighbor(2001:0708:0:0001::0625), errno=55 [snipped like 50-100 other such messages] sixpack# ifconfig sixpack# ps auxwww USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND root 0 0.0 0.0 0 0 ?? DLs 19Aug04 0:00.00 (swapper) root 77556 0.0 0.9 956 532 v0 Ss+ 1:52PM 0:56.89 /usr/libexec/getty Pc ttyv0 root 34359 0.0 1.4 1368 872 p1 Ss 13Sep04 0:00.22 -csh (csh) root 34357 0.0 2.6 5288 1612 ?? S 13Sep04 0:00.44 sshd: root@ttyp1 (sshd) root 201 0.0 0.9 956 532 v7 Is+ 19Aug04 0:00.02 /usr/libexec/getty Pc ttyv7 root 200 0.0 0.9 956 532 v6 Is+ 19Aug04 0:00.02 /usr/libexec/getty Pc ttyv6 root 199 0.0 0.9 956 532 v5 Is+ 19Aug04 0:00.02 /usr/libexec/getty Pc ttyv5 root 198 0.0 0.9 956 532 v4 Is+ 19Aug04 0:00.02 /usr/libexec/getty Pc ttyv4 root 197 0.0 0.9 956 532 v3 Is+ 19Aug04 0:00.02 /usr/libexec/getty Pc ttyv3 root 196 0.0 0.9 956 532 v2 Is+ 19Aug04 0:00.02 /usr/libexec/getty Pc ttyv2 root 195 0.0 0.9 956 532 v1 Is+ 19Aug04 0:00.02 /usr/libexec/getty Pc ttyv1 quagga 148 0.0 4.1 3644 2512 ?? Ss 19Aug04 17:29.51 /usr/local/sbin/bgpd -d quagga 146 0.0 1.6 1896 944 ?? Ss 19Aug04 404:34.68 /usr/local/sbin/zebra -d smmsp 124 0.0 2.3 2928 1412 ?? Is 19Aug04 0:08.22 sendmail: Queue runner@00:30:00 for /var/spool/clientmqueue (sendmail) root 121 0.0 2.7 3048 1628 ?? Ss 19Aug04 7:05.86 sendmail: accepting connections (sendmail) root 116 0.0 2.2 2588 1364 ?? Is 19Aug04 1:32.52 /usr/sbin/sshd root 114 0.0 1.0 1000 600 ?? Ss 19Aug04 1:01.90 /usr/sbin/cron root 112 0.0 1.0 1076 616 ?? Is 19Aug04 0:08.14 /usr/sbin/inetd -wW root 104 0.0 0.9 984 548 ?? Ss 19Aug04 426:12.11 /usr/sbin/syslogd -ss root 24 0.0 0.1 212 68 ?? Is 19Aug04 0:00.00 adjkerntz -i root 7 0.0 0.0 0 0 ?? DL 19Aug04 24:49.48 (syncer) root 6 0.0 0.0 0 0 ?? DL 19Aug04 1:08.24 (vnlru) root 5 0.0 0.0 0 0 ?? DL 19Aug04 0:47.40 (bufdaemon) root 4 0.0 0.0 0 0 ?? DL 19Aug04 0:00.00 (vmdaemon) root 3 0.0 0.0 0 0 ?? DL 19Aug04 0:32.02 (pagedaemon) root 2 0.0 0.0 0 0 ?? DL 19Aug04 0:00.00 (taskqueue) root 1 0.0 0.3 544 200 ?? ILs 19Aug04 0:01.09 /sbin/init -- root 78285 0.0 0.4 420 216 p1 R+ 5:23PM 0:00.00 ps auxwww -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-freebsd-net@FreeBSD.ORG Thu Sep 23 12:45:17 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D11CD16A4FC for ; Thu, 23 Sep 2004 12:45:17 +0000 (GMT) Received: from phuket.psconsult.nl (ps226.psconsult.nl [213.222.19.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 22A8043D1F for ; Thu, 23 Sep 2004 12:45:16 +0000 (GMT) (envelope-from fb-net@psconsult.nl) Received: from phuket.psconsult.nl (localhost [127.0.0.1]) by phuket.psconsult.nl (8.12.8p2/8.12.8) with ESMTP id i8NCjEYe000324 for ; Thu, 23 Sep 2004 14:45:14 +0200 (CEST) (envelope-from fb-net@psconsult.nl) Received: (from paul@localhost) by phuket.psconsult.nl (8.12.8p2/8.12.8/Submit) id i8NCjEbr000323 for net@freebsd.org; Thu, 23 Sep 2004 14:45:14 +0200 (CEST) Date: Thu, 23 Sep 2004 14:45:14 +0200 From: Paul Schenkeveld To: net@freebsd.org Message-ID: <20040923124514.GA99929@psconsult.nl> Mail-Followup-To: net@freebsd.org References: <200409221617.59860.miha@ghuug.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200409221617.59860.miha@ghuug.org> User-Agent: Mutt/1.5.6i Subject: Re: question on tunnels (VPN) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 23 Sep 2004 12:45:17 -0000 On Wed, Sep 22, 2004 at 04:17:59PM +0000, Mikhail P. wrote: > Dear users, > > I have been experimenting with simple gif tunnels (no IPSec) in local network > (192.168.0.0/24). I have used the following scenario between two hosts (both > running FreeBSD-5.2.1): > > HOST_A [192.168.0.1]: > ifconfig gif0 create > ifconfig gif0 tunnel 192.168.0.1 192.168.0.2 > ifconfig gif0 10.0.0.1 10.0.0.2 netmask 255.255.255.255 > > and on - > > HOST_B [192.168.0.2]: > ifconfig gif0 create > ifconfig gif0 tunnel 192.168.0.2 192.168.0.1 > ifconfig gif0 10.0.0.2 10.0.0.1 netmask 255.255.255.255 > > The above works well for me, and I can send traffic on 10.0.0.1 and 10.0.0.2. > > The next thing I wanted to implement is to create similar tunnel from our > local router (which is FreeBSD too) to remote server, however there is small > problem which stops me - router has no public IP, and it sees internet > through DSL router, so basically that router is NAT'ed behind DSL router. > As far as I understand, it appears to be that I won't be able to create such a > simple tunnel, unless my router gets public IP address. > > What I tried next was MPD pptp link (which is known to work behind NAT, unlike > above example), but something (ISP? DSL router?) cuts GRE packets on their > way, so MPD can't establish LCP connection with remote host. > > I'm now in loss as to what to try next - could someone please advise what > other techniques will work in my scenario (where I want to connect machine > which is behind NAT and no GRE packets will go through)? Have a look at /usr/ports/net/vtun. It allows you to create tunnels over virtually any transport you can find including TCP and UDP (but also raw IP, serial lines, ssh tunnels ...). Tunnel endpoints are tunN devices. It has built in encryption (openssl) en compression (lzo, zlib and even a traffic shaper. > regards, > M. HTH Paul Schenkeveld, Consultant PSconsult ICT Services BV From owner-freebsd-net@FreeBSD.ORG Thu Sep 23 16:20:34 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B578F16A4DB for ; Thu, 23 Sep 2004 16:20:34 +0000 (GMT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3F2B343D3F for ; Thu, 23 Sep 2004 16:20:34 +0000 (GMT) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:d0bf:23a3:52d1:4b5a]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 1CEB61525D; Fri, 24 Sep 2004 01:20:31 +0900 (JST) Date: Fri, 24 Sep 2004 01:20:36 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: snap-users@kame.net In-Reply-To: References: User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII cc: freebsd-net@freebsd.org Subject: Re: (KAME-snap 8789) Weird memory exhaustion with FreeBSD 4.10-STABLE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 23 Sep 2004 16:20:34 -0000 >>>>> On Thu, 23 Sep 2004 15:03:47 +0300 (EEST), >>>>> Pekka Savola said: > After the system has been up for a while (a couple of weeks) and/or > the ethernet link has gone up/down for some time (I suspect this is > related to the Neighbor Discovery cache contents), I get dmesg errors > like: (snip) > Ideas? Could you also provide the result of "vmstat -m"? The difference between the result of the stable state and that of the exhausted state may also help. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp From owner-freebsd-net@FreeBSD.ORG Thu Sep 23 18:13:26 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B321616A4CE for ; Thu, 23 Sep 2004 18:13:26 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 92C6B43D2D for ; Thu, 23 Sep 2004 18:13:26 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id i8NIG5cL024218; Thu, 23 Sep 2004 11:16:05 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id i8NIG5Wg024217; Thu, 23 Sep 2004 11:16:05 -0700 Date: Thu, 23 Sep 2004 11:16:05 -0700 From: Brooks Davis To: Waldemar Kornewald Message-ID: <20040923181605.GC25699@odin.ac.hmc.edu> References: <4152A3E9.8080700@web.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1SQmhf2mF2YjsYvc" Content-Disposition: inline In-Reply-To: <4152A3E9.8080700@web.de> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: FreeBSD-net Subject: Re: locking X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 23 Sep 2004 18:13:26 -0000 --1SQmhf2mF2YjsYvc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 23, 2004 at 12:22:33PM +0200, Waldemar Kornewald wrote: > Hi again, > we at the Haiku networking team are considering a port of your 5.3=20 > netstack because it is thread-safe and making the old one (4.x, I think)= =20 > thread-safe is probably a much bigger task. It depends on the model you want. You may also wish to consider the direction DragonFly BSD is taking. It's interesting if unproven. I don't really know enough about Haiku OS to comment more. > Now, I saw that the routing code seems to use macros for the locking=20 > code. Do you use macros everywhere? We usually use macros for locking. It allows us to hid the details of the calls since they aren't very informative. In other cases like ifnet we use macros as though we were using reader-writer locks, but in fact we currently use mutexes since sx locks are more expensive. > We would prefer having native threads and locks. Haiku only has=20 > semaphores, not mutexes, is that a problem? You can implement mutexes using semaphores, but semaphores tend to be a more expensive since they are more expressive them mutexes. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --1SQmhf2mF2YjsYvc Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBUxLlXY6L6fI4GtQRAolCAJ9FY208hGaqQeMht/RdkrIYRM7ORwCgw5ad 5gK506YjXGs8BY/nI+BM+SI= =w5gO -----END PGP SIGNATURE----- --1SQmhf2mF2YjsYvc-- From owner-freebsd-net@FreeBSD.ORG Thu Sep 23 18:47:20 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 40DD316A4CE; Thu, 23 Sep 2004 18:47:20 +0000 (GMT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by mx1.FreeBSD.org (Postfix) with ESMTP id D3A0643D31; Thu, 23 Sep 2004 18:47:19 +0000 (GMT) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:d0bf:23a3:52d1:4b5a]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id AC3431525D; Fri, 24 Sep 2004 03:47:17 +0900 (JST) Date: Fri, 24 Sep 2004 03:47:22 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Brian Fundakowski Feldman In-Reply-To: <20040922020957.GE84424@green.homeunix.org> References: <20040922020957.GE84424@green.homeunix.org> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII cc: net@FreeBSD.org Subject: Re: IPv6 route mutex recursion (crash) and fix X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 23 Sep 2004 18:47:20 -0000 >>>>> On Tue, 21 Sep 2004 22:09:57 -0400, >>>>> Brian Fundakowski Feldman said: > I've already made noise about this before, so I'll be brief. I plan on > committing the following fix that prevents the routing code from being > recursed upon such that RTM_RESOLVE causes the embryonic new route to > be looked up again. I realize that probably no one will bother trying > to see this bug in action, but all you need to do is send some UDP6 to > ff02::1% as a user, with INVARIANTS turned on. > Are there any objections? It would be nice to have this in 5-STABLE, > in case anyone actually wants to have IPv6. The patch itself looks okay with the rationale you explained in a follow-up message. However, I have some related comments. As commented in nd6_rtrequest(), the purpose for checking nd6_is_addr_neighbor() in this function was to avoid creating a neighbor cache for the destination of some special host-routes. For FreeBSD, this can happen with the route which has the RTF_PRCLONING flag. However, since recent versions of FreeBSD (seems to) have got rid of this flag, we might even remove the check in nd6_rtrequest() altogether. (Then we'd not need to modify nd6_is_addr_neighbor().) But removing the check may be too radical and may have unexpected side-effect. Also, it'd be nice if we could keep the difference between the FreeBSD repository code and the KAME snap code as small as possible, in terms of future merge efforts. In this sense, removing the nd6_is_addr_neighbor() check from nd6_rtrequest() might be a suboptimal solution. So, as a result, I tend to think the proposed patch is a reasonable fix to the problem. But please add the rationale as comments, since the background intent is a bit vague as shown by the question from George. Thanks, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp From owner-freebsd-net@FreeBSD.ORG Thu Sep 23 18:58:44 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D4EB116A4CE for ; Thu, 23 Sep 2004 18:58:44 +0000 (GMT) Received: from green.homeunix.org (pcp04368961pcs.nrockv01.md.comcast.net [69.140.212.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4808C43D2F for ; Thu, 23 Sep 2004 18:58:44 +0000 (GMT) (envelope-from green@green.homeunix.org) Received: from green.homeunix.org (green@localhost [127.0.0.1]) by green.homeunix.org (8.13.1/8.13.1) with ESMTP id i8NIwhDb017796; Thu, 23 Sep 2004 14:58:43 -0400 (EDT) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.13.1/8.13.1/Submit) id i8NIwgbo017795; Thu, 23 Sep 2004 14:58:42 -0400 (EDT) (envelope-from green) Date: Thu, 23 Sep 2004 14:58:41 -0400 From: Brian Fundakowski Feldman To: "JINMEI Tatuya / ?$B?@L@C#:H" Message-ID: <20040923185841.GD959@green.homeunix.org> References: <20040922020957.GE84424@green.homeunix.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i cc: net@FreeBSD.org Subject: Re: IPv6 route mutex recursion (crash) and fix X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 23 Sep 2004 18:58:45 -0000 On Fri, Sep 24, 2004 at 03:47:22AM +0900, JINMEI Tatuya / ?$B?@L@C#:H wrote: > >>>>> On Tue, 21 Sep 2004 22:09:57 -0400, > >>>>> Brian Fundakowski Feldman said: > > > I've already made noise about this before, so I'll be brief. I plan on > > committing the following fix that prevents the routing code from being > > recursed upon such that RTM_RESOLVE causes the embryonic new route to > > be looked up again. I realize that probably no one will bother trying > > to see this bug in action, but all you need to do is send some UDP6 to > > ff02::1% as a user, with INVARIANTS turned on. > > > Are there any objections? It would be nice to have this in 5-STABLE, > > in case anyone actually wants to have IPv6. > > The patch itself looks okay with the rationale you explained in a > follow-up message. However, I have some related comments. > > As commented in nd6_rtrequest(), the purpose for checking > nd6_is_addr_neighbor() in this function was to avoid creating a > neighbor cache for the destination of some special host-routes. For > FreeBSD, this can happen with the route which has the RTF_PRCLONING > flag. However, since recent versions of FreeBSD (seems to) have got > rid of this flag, we might even remove the check in nd6_rtrequest() > altogether. (Then we'd not need to modify nd6_is_addr_neighbor().) > > But removing the check may be too radical and may have unexpected > side-effect. Also, it'd be nice if we could keep the difference > between the FreeBSD repository code and the KAME snap code as small as > possible, in terms of future merge efforts. In this sense, removing > the nd6_is_addr_neighbor() check from nd6_rtrequest() might be a > suboptimal solution. > > So, as a result, I tend to think the proposed patch is a reasonable > fix to the problem. But please add the rationale as comments, since > the background intent is a bit vague as shown by the question from > George. Thank you for your review. As you certainly are more knowledgable in KAME code than I am, would you mind redoing this so that the style is more closely matched; then I could take the change from the KAME repository? -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ From owner-freebsd-net@FreeBSD.ORG Fri Sep 24 02:30:07 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 288F816A4CE for ; Fri, 24 Sep 2004 02:30:07 +0000 (GMT) Received: from outbound0.sv.meer.net (outbound0.sv.meer.net [205.217.152.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id D8CBB43D48 for ; Fri, 24 Sep 2004 02:30:06 +0000 (GMT) (envelope-from gnn@neville-neil.com) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) i8O2TVr2047167; Thu, 23 Sep 2004 19:29:31 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (pc1.oakwoodazabu1-unet.ocn.ne.jp [220.110.140.201]) by mail.meer.net (8.12.1/8.12.2/meer) with ESMTP id i8O2TS71022052; Thu, 23 Sep 2004 19:29:28 -0700 (PDT) (envelope-from gnn@neville-neil.com) Date: Fri, 24 Sep 2004 11:29:25 +0900 Message-ID: From: "George V. Neville-Neil" To: Waldemar Kornewald In-Reply-To: <4152A184.9020301@web.de> References: <4152A184.9020301@web.de> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.5 Emacs/21.2 (powerpc-apple-darwin) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII cc: FreeBSD-net Subject: Re: creating default route in kernel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 24 Sep 2004 02:30:07 -0000 At Thu, 23 Sep 2004 12:12:20 +0200, Waldemar Kornewald wrote: > > Hi, > could you please tell me how I can create a default route from within > the kernel? I am a member of the Haiku (OS) networking team and > maintainer of the PPP stack and for dial-on-demand support there must be > a default route which does not work. BTW, we use a port of your netstack > (from the 4.x releases, I think). > Which values should the default route get (netmask, destination, etc.) > and which function(s) should I call (our PPP stack lives in the kernel)? If you look at src/sys/net/route.c you will find a function (in -CURRENT) called rtrequest1(). Read through that routine to see how to do an RTM_ADD. You will need a destination and netmask, yes. The destination for the default route is 0 and you need to set the gateway to the correct gateway. For debuggging this you should have something listening to a routing socket and printing out the messages. In userland on FreeBSD we do this with "route monitor", see the route(8) man page for more information. Later, George From owner-freebsd-net@FreeBSD.ORG Fri Sep 24 06:04:39 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3B2FD16A4CE for ; Fri, 24 Sep 2004 06:04:39 +0000 (GMT) Received: from smtp05.web.de (smtp05.web.de [217.72.192.209]) by mx1.FreeBSD.org (Postfix) with ESMTP id C1DD643D58 for ; Fri, 24 Sep 2004 06:04:38 +0000 (GMT) (envelope-from Waldemar.Kornewald@web.de) Received: from [80.134.69.149] (helo=[80.134.69.149]) by smtp05.web.de with asmtp (TLSv1:RC4-MD5:128) (WEB.DE 4.101 #44) id 1CAjC2-0005lr-00; Fri, 24 Sep 2004 08:04:30 +0200 Message-ID: <4153B897.9040807@web.de> Date: Fri, 24 Sep 2004 08:03:03 +0200 From: Waldemar Kornewald User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brooks Davis References: <4152A3E9.8080700@web.de> <20040923181605.GC25699@odin.ac.hmc.edu> <415339A1.6090905@web.de> <20040923211703.GA23574@odin.ac.hmc.edu> In-Reply-To: <20040923211703.GA23574@odin.ac.hmc.edu> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: Waldemar.Kornewald@web.de X-Sender: Waldemar.Kornewald@web.de cc: FreeBSD-net Subject: Re: locking & iovecs X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 24 Sep 2004 06:04:39 -0000 Brooks Davis wrote: >>Oh, now that we talk about alternatives: did you consider using iovecs >>instead of mbufs? Be Inc. said that BONE, the new netstack of BeOS (now >>Zeta), can handle huge amounts of data much better than mbufs because >>iovecs reduce the number of copies made when fragmenting...though, there >>has never been a real comparison. > > Rewriting the network stack to use an alternate method of storing > network data is a hugh undertaking. It's not an idea that's likely to > get any sort of traction in the project unless someone presented running > code and a massive performance improvement across the entire spectrum of > applications. Unless you mean splitting buffers up into TCP packets, > fragmentations is a network configuration bug in 99% of all cases. :) Sorry, that is no bug. :) Maybe we will try it after we get our code/port stable. As we will not port all of your protocols it should be less of a problem to change our stack. I can post the results here (in some years ;). >>>You can implement mutexes using semaphores, but semaphores tend to be a >>>more expensive since they are more expressive them mutexes. >> >>Using a benaphore instead would improve speed significantly and as you >>only use macros we can easily replace those with our benaphore code, is >>that really so simple? Sorry, I cannot believe that. :) > > Once GIANT is really gone, it may be nearly that easy. We're a ways > from that though. So, the code is not fully thread-safe yet (we want to drop GIANT)? Then, I misunderstood something. Will 5.3 be freed of GIANT? Bye, Waldemar Kornewald From owner-freebsd-net@FreeBSD.ORG Fri Sep 24 08:51:15 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BA0E716A4CE for ; Fri, 24 Sep 2004 08:51:15 +0000 (GMT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id E091D43D49 for ; Fri, 24 Sep 2004 08:51:13 +0000 (GMT) (envelope-from pekkas@netcore.fi) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i8O8p7705465; Fri, 24 Sep 2004 11:51:08 +0300 Date: Fri, 24 Sep 2004 11:51:07 +0300 (EEST) From: Pekka Savola To: snap-users@kame.net In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1589707168-126566817-1096015867=:5289" cc: freebsd-net@freebsd.org Subject: Re: (KAME-snap 8790) Re: Weird memory exhaustion with FreeBSD 4.10-STABLE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 24 Sep 2004 08:51:15 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --1589707168-126566817-1096015867=:5289 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 On Fri, 24 Sep 2004, JINMEI Tatuya / [ISO-2022-JP] 神明達哉 wrote: > >>>>> On Thu, 23 Sep 2004 15:03:47 +0300 (EEST), > >>>>> Pekka Savola said: > > > After the system has been up for a while (a couple of weeks) and/or > > the ethernet link has gone up/down for some time (I suspect this is > > related to the Neighbor Discovery cache contents), I get dmesg errors > > like: > > Could you also provide the result of "vmstat -m"? The difference > between the result of the stable state and that of the exhausted state > may also help. Thanks for interest, Jinmei. Hopefully these will be useful. Attached (-wrk is done just after a reboot) is a comparison. In -brk, I didn't (at least yet) see nd6_lookup errors in dmesg, but ifconfig doesn't work at least. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings --1589707168-126566817-1096015867=:5289 Content-Type: TEXT/plain; name="vmstat-wrk.txt" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="vmstat-wrk.txt" TWVtb3J5IHN0YXRpc3RpY3MgYnkgYnVja2V0IHNpemUNClNpemUgICBJbiBV c2UgICBGcmVlICAgUmVxdWVzdHMgIEhpZ2hXYXRlciAgQ291bGRmcmVlDQog IDE2ICAgICAgMzYzICAgIDE0OSAgICAgICAyODU0ICAgIDEyODAgICAgICAg ICAgMA0KICAzMiAgICAgIDMzMCAgICAgNTQgICAgICAgIDg3OSAgICAgNjQw ICAgICAgICAgIDANCiAgNjQgICAgIDIxOTYgICAgIDQ0ICAgICAgIDUxNjUg ICAgIDMyMCAgICAgICAgICAwDQogMTI4ICAgICAxNDM3ICAgICAgMyAgICAg ICAyNzkxICAgICAxNjAgICAgICAgICAgMA0KIDI1NiAgICAgMTUxMSAgICAg IDkgICAgICAgMjA2MiAgICAgIDgwICAgICAgICAgIDANCiA1MTIgICAgICAg NjQgICAgICA4ICAgICAgICA1NjIgICAgICA0MCAgICAgICAgICAwDQogIDFL ICAgICAgIDQ5ICAgICAgMyAgICAgICAgMTQ3ICAgICAgMjAgICAgICAgICAg MA0KICAySyAgICAgICAyNCAgICAgIDAgICAgICAgICAzOCAgICAgIDEwICAg ICAgICAgIDANCiAgNEsgICAgICAgMTYgICAgICAxICAgICAgICAgNDkgICAg ICAgNSAgICAgICAgICAwDQogIDhLICAgICAgICAzICAgICAgMCAgICAgICAg ICAzICAgICAgIDUgICAgICAgICAgMA0KIDE2SyAgICAgICAxNSAgICAgIDAg ICAgICAgICAxOSAgICAgICA1ICAgICAgICAgIDANCiAzMksgICAgICAgIDIg ICAgICAwICAgICAgICAgIDIgICAgICAgNSAgICAgICAgICAwDQoxMjhLICAg ICAgICAxICAgICAgMCAgICAgICAgICAxICAgICAgIDUgICAgICAgICAgMA0K NTEySyAgICAgICAgMCAgICAgIDAgICAgICAgICAgMiAgICAgICA1ICAgICAg ICAgIDANCg0KTWVtb3J5IHVzYWdlIHR5cGUgYnkgYnVja2V0IHNpemUNClNp emUgIFR5cGUocykNCiAgMTYgIHVjX2Rldmxpc3QsIG5leHVzZGV2LCBwMTAw My4xYiwgcHJvYy1hcmdzLCBrZXkgbWdtdCwgaXA2X21vcHRpb25zLA0KCSAg SXA2RncvSXA2QWNjdCwgcm91dGV0YmwsIGV0aGVyX211bHRpLCB2bm9kZXMs IG1vdW50LCBwY2IsIHNvbmFtZSwNCgkgIHRhZywga2xkLCBBVEEgZ2VuZXJp YywgTUQgZGlzaywgcm1hbiwgYnVzLCBzeXNjdGwsIHRlbXAsIGRldmJ1ZiwN CgkgIGF0ZXhpdA0KICAzMiAgYXRrYmRkZXYsIGxpbnV4LCBpbmRpcmRlcCwg Ym1zYWZlbWFwLCBuZXdibGssIHByb2MtYXJncywgaW5fbXVsdGksDQoJICBy b3V0ZXRibCwgZXRoZXJfbXVsdGksIGlmYWRkciwgQlBGLCB2bm9kZXMsIGNs dXN0ZXJfc2F2ZSBidWZmZXIsIHBjYiwNCgkgIHNvbmFtZSwgc2lnaW8sIGts ZCwgdGFza3F1ZXVlLCBTV0FQLCBldmVudGhhbmRsZXIsIGJ1cywgc3lzY3Rs LA0KCSAgdWlkaW5mbywgc3VicHJvYywgcGdycCwgQVRBUEkgZ2VuZXJpYywg dGVtcCwgZGV2YnVmDQogIDY0ICBpc2FkZXYsIGFsbG9jaW5kaXIsIHByb2Mt YXJncywgaW42X211bHRpLCByb3V0ZXRibCwgZXRoZXJfbXVsdGksDQoJICBp ZmFkZHIsIHZub2RlcywgdmZzY2FjaGUsIHBjYiwgdGFnLCBmaWxlLCBBUiBk cml2ZXIsIEFEIGRyaXZlciwgcm1hbiwNCgkgIGV2ZW50aGFuZGxlciwgYnVz LCBzdWJwcm9jLCBzZXNzaW9uLCBpcDZuZHAsIHRlbXAsIGRldmJ1ZiwgbG9j a2YNCiAxMjggIFpPTkUsIHpvbWJpZSwgcHJvYy1hcmdzLCByb3V0ZXRibCwg dm5vZGVzLCBtb3VudCwgc29uYW1lLCB0dHlzLA0KCSAgZGV2X3QsIHRpbWVj b3VudGVyLCBrbGQsIGJ1cywgY3JlZCwgQVRBUEkgZ2VuZXJpYywgaXA2bmRw LCB0ZW1wLA0KCSAgZGV2YnVmDQogMjU2ICBGRlMgbm9kZSwgbmV3YmxrLCBO RlMgZGFlbW9uLCBJcDZGdy9JcDZBY2N0LCBJcEZ3L0lwQWNjdCwgcm91dGV0 YmwsDQoJICBzdGYsIGZhaXRoLCBpZmFkZHIsIHZub2Rlcywga3F1ZXVlLCB0 dHlzLCBmaWxlIGRlc2MsIEFDRCBkcml2ZXIsIGJ1cywNCgkgIHVpZGluZm8s IHN1YnByb2MsIHRlbXAsIGRldmJ1Zg0KIDUxMiAgVUZTIG1vdW50LCBrZXkg bWdtdCwgcm91dGV0YmwsIGlmYWRkciwgbW91bnQsIEJJTyBidWZmZXIsIHB0 eXMsDQoJICBBVEEgZ2VuZXJpYywgQVIgZHJpdmVyLCBtc2csIGlvY3Rsb3Bz LCBidXMsIHRlbXAsIGRldmJ1Zg0KICAxSyAgdWNfZGV2bGlzdCwgTlFORlMg TGVhc2UsIEV4cG9ydCBIb3N0LCBpZmFkZHIsIEJJTyBidWZmZXIsIGtxdWV1 ZSwNCgkgIE1EIGRpc2ssIHNlbSwgQUQgZHJpdmVyLCBpb2N0bG9wcywgYnVz LCBwcm9jLCBpcDZuZHAsIHRlbXAsIGRldmJ1Zg0KICAySyAgVUZTIG1vdW50 LCBwYWdlZGVwLCBpZmFkZHIsIEJJTyBidWZmZXIsIHBjYiwgQVIgZHJpdmVy LCBpb2N0bG9wcywNCgkgIEFDRCBkcml2ZXIsIGJ1cywgZGV2YnVmDQogIDRL ICBtYnVmLCBWTSBwZ2RhdGEsIFVGUyBtb3VudCwgc2VtLCBtc2csIGlvY3Rs b3BzLCBidXMsIHRlbXAsIGRldmJ1Zg0KICA4SyAgVUZTIG1vdW50LCBzeW5j YWNoZSwgTVNET1NGUyBtb3VudA0KIDE2SyAgVUZTIGloYXNoLCBpbm9kZWRl cCwgTkZTIGhhc2gsIHNobSwgSVNPRlMgbW91bnQsIG1zZywgYnVzLCBkZXZi dWYNCiAzMksgIHZmc2NhY2hlLCB0ZW1wDQoxMjhLICBTV0FQDQo1MTJLICB0 ZW1wDQoNCk1lbW9yeSBzdGF0aXN0aWNzIGJ5IHR5cGUgICAgICAgICAgICAg ICAgICAgICAgICAgIFR5cGUgIEtlcm4NCiAgICAgICAgVHlwZSAgSW5Vc2Ug TWVtVXNlIEhpZ2hVc2UgIExpbWl0IFJlcXVlc3RzIExpbWl0IExpbWl0IFNp emUocykNCiAgICAgYXRrYmRkZXYgICAgIDIgICAgIDFLICAgICAgMUsgMTAx NDhLICAgICAgICAyICAgIDAgICAgIDAgIDMyDQogICAgICAgIGxpbnV4ICAg ICA4ICAgICAxSyAgICAgIDFLIDEwMTQ4SyAgICAgICAgOCAgICAwICAgICAw ICAzMg0KICAgdWNfZGV2bGlzdCAgICAgMCAgICAgMEsgICAgICAySyAxMDE0 OEsgICAgICAgMTggICAgMCAgICAgMCAgMTYsMUsNCiAgICAgbmV4dXNkZXYg ICAgIDQgICAgIDFLICAgICAgMUsgMTAxNDhLICAgICAgICA0ICAgIDAgICAg IDAgIDE2DQogICAgICAgICBtYnVmICAgICAxICAgICA0SyAgICAgIDRLIDEw MTQ4SyAgICAgICAgMSAgICAwICAgICAwICA0Sw0KICAgICAgIGlzYWRldiAg ICAxMyAgICAgMUsgICAgICAxSyAxMDE0OEsgICAgICAgMTMgICAgMCAgICAg MCAgNjQNCiAgICAgICAgIFpPTkUgICAgMTUgICAgIDJLICAgICAgMksgMTAx NDhLICAgICAgIDE1ICAgIDAgICAgIDAgIDEyOA0KICAgIFZNIHBnZGF0YSAg ICAgMSAgICAgNEsgICAgICA0SyAxMDE0OEsgICAgICAgIDEgICAgMCAgICAg MCAgNEsNCiAgICAgICB6b21iaWUgICAgIDAgICAgIDBLICAgICAgMUsgMTAx NDhLICAgICAgMTk0ICAgIDAgICAgIDAgIDEyOA0KICAgIFVGUyBtb3VudCAg ICAxMiAgICAyNksgICAgIDI2SyAxMDE0OEsgICAgICAgMTIgICAgMCAgICAg MCAgNTEyLDJLLDRLLDhLDQogICAgVUZTIGloYXNoICAgICAxICAgIDE2SyAg ICAgMTZLIDEwMTQ4SyAgICAgICAgMSAgICAwICAgICAwICAxNksNCiAgICAg RkZTIG5vZGUgIDExMDIgICAyNzZLICAgIDI3NksgMTAxNDhLICAgICAxMTIy ICAgIDAgICAgIDAgIDI1Ng0KICAgYWxsb2NpbmRpciAgICAgNCAgICAgMUsg ICAgICAxSyAxMDE0OEsgICAgICAgIDQgICAgMCAgICAgMCAgNjQNCiAgICAg aW5kaXJkZXAgICAgIDEgICAgIDFLICAgICAgMUsgMTAxNDhLICAgICAgICAx ICAgIDAgICAgIDAgIDMyDQogICAgYm1zYWZlbWFwICAgICAxICAgICAxSyAg ICAgIDFLIDEwMTQ4SyAgICAgICAgMSAgICAwICAgICAwICAzMg0KICAgICAg IG5ld2JsayAgICAgMSAgICAgMUsgICAgICAxSyAxMDE0OEsgICAgICAgIDUg ICAgMCAgICAgMCAgMzIsMjU2DQogICAgIGlub2RlZGVwICAgICAxICAgIDE2 SyAgICAgMTZLIDEwMTQ4SyAgICAgICAgMSAgICAwICAgICAwICAxNksNCiAg ICAgIHBhZ2VkZXAgICAgIDEgICAgIDJLICAgICAgMksgMTAxNDhLICAgICAg ICAxICAgIDAgICAgIDAgIDJLDQogICAgIHAxMDAzLjFiICAgICAxICAgICAx SyAgICAgIDFLIDEwMTQ4SyAgICAgICAgMSAgICAwICAgICAwICAxNg0KICAg IHByb2MtYXJncyAgICAyMSAgICAgMksgICAgICAySyAxMDE0OEsgICAgICAx ODQgICAgMCAgICAgMCAgMTYsMzIsNjQsMTI4DQogICAgIE5GUyBoYXNoICAg ICAxICAgIDE2SyAgICAgMTZLIDEwMTQ4SyAgICAgICAgMSAgICAwICAgICAw ICAxNksNCiAgTlFORlMgTGVhc2UgICAgIDEgICAgIDFLICAgICAgMUsgMTAx NDhLICAgICAgICAxICAgIDAgICAgIDAgIDFLDQogICBORlMgZGFlbW9uICAg ICAxICAgICAxSyAgICAgIDFLIDEwMTQ4SyAgICAgICAgMSAgICAwICAgICAw ICAyNTYNCiAgICAga2V5IG1nbXQgICAgNTEgICAgMThLICAgICAyMEsgMTAx NDhLICAgICAgNDg3ICAgIDAgICAgIDAgIDE2LDUxMg0KIGlwNl9tb3B0aW9u cyAgICAgMSAgICAgMUsgICAgICAxSyAxMDE0OEsgICAgICAgIDEgICAgMCAg ICAgMCAgMTYNCklwNkZ3L0lwNkFjY3QgICAgMzAgICAgIDRLICAgICAgNEsg MTAxNDhLICAgICAgIDMwICAgIDAgICAgIDAgIDE2LDI1Ng0KICAgIGluNl9t dWx0aSAgICAxMCAgICAgMUsgICAgICAxSyAxMDE0OEsgICAgICAgMTAgICAg MCAgICAgMCAgNjQNCiAgICAgc3luY2FjaGUgICAgIDEgICAgIDhLICAgICAg OEsgMTAxNDhLICAgICAgICAxICAgIDAgICAgIDAgIDhLDQogIElwRncvSXBB Y2N0ICAgICA1ICAgICAySyAgICAgIDJLIDEwMTQ4SyAgICAgICAgNSAgICAw ICAgICAwICAyNTYNCiAgRXhwb3J0IEhvc3QgICAgIDEgICAgIDFLICAgICAg MUsgMTAxNDhLICAgICAgICAxICAgIDAgICAgIDAgIDFLDQogICAgIGluX211 bHRpICAgICAyICAgICAxSyAgICAgIDFLIDEwMTQ4SyAgICAgICAgMiAgICAw ICAgICAwICAzMg0KICAgICByb3V0ZXRibCAgIDQ2MSAgICA2N0sgICAgIDY3 SyAxMDE0OEsgICAgICA1MzggICAgMCAgICAgMCAgMTYsMzIsNjQsMTI4LDI1 Niw1MTINCiAgICAgICAgICBzdGYgICAgIDEgICAgIDFLICAgICAgMUsgMTAx NDhLICAgICAgICAxICAgIDAgICAgIDAgIDI1Ng0KICAgICAgICBmYWl0aCAg ICAgNCAgICAgMUsgICAgICAxSyAxMDE0OEsgICAgICAgIDQgICAgMCAgICAg MCAgMjU2DQogIGV0aGVyX211bHRpICAgIDM5ICAgICAySyAgICAgIDJLIDEw MTQ4SyAgICAgICAzOSAgICAwICAgICAwICAxNiwzMiw2NA0KICAgICAgIGlm YWRkciAgICAzOSAgICAxM0sgICAgIDEzSyAxMDE0OEsgICAgICAgMzkgICAg MCAgICAgMCAgMzIsNjQsMjU2LDUxMiwxSywySw0KICAgICAgICAgIEJQRiAg ICAgOSAgICAgMUsgICAgICAxSyAxMDE0OEsgICAgICAgIDkgICAgMCAgICAg MCAgMzINCk1TRE9TRlMgbW91bnQgICAgIDEgICAgIDhLICAgICAgOEsgMTAx NDhLICAgICAgICAxICAgIDAgICAgIDAgIDhLDQogICAgICAgdm5vZGVzICAg IDI1ICAgICA2SyAgICAgIDdLIDEwMTQ4SyAgICAgIDM1NyAgICAwICAgICAw ICAxNiwzMiw2NCwxMjgsMjU2DQogICAgICAgIG1vdW50ICAgICA1ICAgICAz SyAgICAgIDNLIDEwMTQ4SyAgICAgICAgNyAgICAwICAgICAwICAxNiwxMjgs NTEyDQpjbHVzdGVyX3NhdmUgYnVmZmVyICAgICAwICAgICAwSyAgICAgIDFL IDEwMTQ4SyAgICAgICAgMSAgICAwICAgICAwICAzMg0KICAgICB2ZnNjYWNo ZSAgMTY0MyAgIDEzNUsgICAgMTM1SyAxMDE0OEsgICAgIDE3NDYgICAgMCAg ICAgMCAgNjQsMzJLDQogICBCSU8gYnVmZmVyICAgIDQzICAgIDUxSyAgICAg NTFLIDEwMTQ4SyAgICAgICA4OCAgICAwICAgICAwICA1MTIsMUssMksNCiAg ICAgICBrcXVldWUgICAgIDIgICAgIDJLICAgICAgM0sgMTAxNDhLICAgICAg IDMwICAgIDAgICAgIDAgIDI1NiwxSw0KICAgICAgICAgIHBjYiAgICAxOSAg ICAgNUsgICAgICA1SyAxMDE0OEsgICAgICAgNzEgICAgMCAgICAgMCAgMTYs MzIsNjQsMksNCiAgICAgICBzb25hbWUgICAgIDcgICAgIDFLICAgICAgMUsg MTAxNDhLICAgICAgMTUxICAgIDAgICAgIDAgIDE2LDMyLDEyOA0KICAgICAg ICAgIHRhZyAgICAgMCAgICAgMEsgICAgICAxSyAxMDE0OEsgICAgIDE3MDgg ICAgMCAgICAgMCAgMTYsNjQNCiAgICAgICAgc2lnaW8gICAgIDEgICAgIDFL ICAgICAgMUsgMTAxNDhLICAgICAgICAxICAgIDAgICAgIDAgIDMyDQogICAg ICAgICBwdHlzICAgICAyICAgICAxSyAgICAgIDFLIDEwMTQ4SyAgICAgICAg MiAgICAwICAgICAwICA1MTINCiAgICAgICAgIHR0eXMgICA0MDkgICAgNTNL ICAgICA1M0sgMTAxNDhLICAgICAgOTk0ICAgIDAgICAgIDAgIDEyOCwyNTYN CiAgICAgICAgIGZpbGUgICAgNzYgICAgIDVLICAgICAgNUsgMTAxNDhLICAg ICAxMDY0ICAgIDAgICAgIDAgIDY0DQogICAgZmlsZSBkZXNjICAgIDI3ICAg ICA3SyAgICAgIDhLIDEwMTQ4SyAgICAgIDIyMSAgICAwICAgICAwICAyNTYN CiAgICAgICAgZGV2X3QgICA4OTggICAxMTNLICAgIDExM0sgMTAxNDhLICAg ICAgODk4ICAgIDAgICAgIDAgIDEyOA0KICB0aW1lY291bnRlciAgICAgNSAg ICAgMUsgICAgICAxSyAxMDE0OEsgICAgICAgIDUgICAgMCAgICAgMCAgMTI4 DQogICAgICAgICAgc2htICAgICAxICAgIDEySyAgICAgMTJLIDEwMTQ4SyAg ICAgICAgMSAgICAwICAgICAwICAxNksNCiAgICAgICAgICBrbGQgICAgIDQg ICAgIDFLICAgICAgMUsgMTAxNDhLICAgICAgIDUxICAgIDAgICAgIDAgIDE2 LDMyLDEyOA0KICBBVEEgZ2VuZXJpYyAgICAgNiAgICAgMksgICAgICAySyAx MDE0OEsgICAgICAgIDcgICAgMCAgICAgMCAgMTYsNTEyDQogICAgQVIgZHJp dmVyICAgICAxICAgICAxSyAgICAgIDNLIDEwMTQ4SyAgICAgICAgNSAgICAw ICAgICAwICA2NCw1MTIsMksNCiAgSVNPRlMgbW91bnQgICAgIDEgICAgMTZL ICAgICAxNksgMTAxNDhLICAgICAgICAxICAgIDAgICAgIDAgIDE2Sw0KICAg ICAgTUQgZGlzayAgICAgMiAgICAgMksgICAgICAySyAxMDE0OEsgICAgICAg IDIgICAgMCAgICAgMCAgMTYsMUsNCiAgICAgICAgICBzZW0gICAgIDMgICAg IDZLICAgICAgNksgMTAxNDhLICAgICAgICAzICAgIDAgICAgIDAgIDFLLDRL DQogICAgQUQgZHJpdmVyICAgICAyICAgICAySyAgICAgIDNLIDEwMTQ4SyAg ICAgIDk4OSAgICAwICAgICAwICA2NCwxSw0KICAgICAgICAgIG1zZyAgICAg NCAgICAyNUsgICAgIDI1SyAxMDE0OEsgICAgICAgIDQgICAgMCAgICAgMCAg NTEyLDRLLDE2Sw0KICAgICAgICAgcm1hbiAgICA1NSAgICAgNEsgICAgICA0 SyAxMDE0OEsgICAgICA0MjAgICAgMCAgICAgMCAgMTYsNjQNCiAgICAgaW9j dGxvcHMgICAgIDAgICAgIDBLICAgICAgNEsgMTAxNDhLICAgICAgIDYxICAg IDAgICAgIDAgIDUxMiwxSywySyw0Sw0KICAgIHRhc2txdWV1ZSAgICAgMiAg ICAgMUsgICAgICAxSyAxMDE0OEsgICAgICAgIDIgICAgMCAgICAgMCAgMzIN CiAgICAgICAgIFNXQVAgICAgIDIgICAgNzNLICAgICA3M0sgMTAxNDhLICAg ICAgICAyICAgIDAgICAgIDAgIDMyLDEyOEsNCiAgIEFDRCBkcml2ZXIgICAg IDIgICAgIDNLICAgICAgM0sgMTAxNDhLICAgICAgICAyICAgIDAgICAgIDAg IDI1NiwySw0KIGV2ZW50aGFuZGxlciAgICAxMiAgICAgMUsgICAgICAxSyAx MDE0OEsgICAgICAgMTIgICAgMCAgICAgMCAgMzIsNjQNCiAgICAgICAgICBi dXMgICA0NTAgICAgNDdLICAgICA1MksgMTAxNDhLICAgICAgODQ2ICAgIDAg ICAgIDAgIDE2LDMyLDY0LDEyOCwyNTYsNTEyLDFLLDJLLDRLLDE2Sw0KICAg ICAgIHN5c2N0bCAgICAgMCAgICAgMEsgICAgICAxSyAxMDE0OEsgICAgICAg MzIgICAgMCAgICAgMCAgMTYsMzINCiAgICAgIHVpZGluZm8gICAgIDQgICAg IDFLICAgICAgMUsgMTAxNDhLICAgICAgICA4ICAgIDAgICAgIDAgIDMyLDI1 Ng0KICAgICAgICAgY3JlZCAgICAxNyAgICAgM0sgICAgICAzSyAxMDE0OEsg ICAgICAyMTUgICAgMCAgICAgMCAgMTI4DQogICAgICBzdWJwcm9jICAgIDY2 ICAgICA2SyAgICAgIDZLIDEwMTQ4SyAgICAgIDQ1NyAgICAwICAgICAwICAz Miw2NCwyNTYNCiAgICAgICAgIHByb2MgICAgIDIgICAgIDJLICAgICAgMksg MTAxNDhLICAgICAgICAyICAgIDAgICAgIDAgIDFLDQogICAgICBzZXNzaW9u ICAgIDE5ICAgICAySyAgICAgIDJLIDEwMTQ4SyAgICAgICAyMiAgICAwICAg ICAwICA2NA0KICAgICAgICAgcGdycCAgICAyMCAgICAgMUsgICAgICAxSyAx MDE0OEsgICAgICAgMjQgICAgMCAgICAgMCAgMzINCkFUQVBJIGdlbmVyaWMg ICAgIDEgICAgIDFLICAgICAgMUsgMTAxNDhLICAgICAgICAzICAgIDAgICAg IDAgIDMyLDEyOA0KICAgICAgIGlwNm5kcCAgICAgNiAgICAgMksgICAgICAy SyAxMDE0OEsgICAgICAgIDggICAgMCAgICAgMCAgNjQsMTI4LDFLDQogICAg ICAgICB0ZW1wICAgMjI4ICAgIDM3SyAgIDEwMTVLIDEwMTQ4SyAgICAgMTE1 MiAgICAwICAgICAwICAxNiwzMiw2NCwxMjgsMjU2LDUxMiwxSyw0SywzMkss NTEySw0KICAgICAgIGRldmJ1ZiAgICA4NSAgIDE4M0sgICAgMTgzSyAxMDE0 OEsgICAgICAxMzEgICAgMCAgICAgMCAgMTYsMzIsNjQsMTI4LDI1Niw1MTIs MUssMkssNEssMTZLDQogICAgICAgIGxvY2tmICAgICA1ICAgICAxSyAgICAg IDFLIDEwMTQ4SyAgICAgICAgNyAgICAwICAgICAwICA2NA0KICAgICAgIGF0 ZXhpdCAgICAgMSAgICAgMUsgICAgICAxSyAxMDE0OEsgICAgICAgIDEgICAg MCAgICAgMCAgMTYNCg0KTWVtb3J5IFRvdGFsczogIEluIFVzZSAgICAgICBG cmVlICAgIFJlcXVlc3RzDQogICAgICAgICAgICAgICAgIDEyODhLICAgICAg ICAyMUsgICAgICAgMTQ1NzQNCg== --1589707168-126566817-1096015867=:5289 Content-Type: TEXT/plain; name="vmstat-brk.txt" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="vmstat-brk.txt" TWVtb3J5IHN0YXRpc3RpY3MgYnkgYnVja2V0IHNpemUNClNpemUgICBJbiBV c2UgICBGcmVlICAgUmVxdWVzdHMgIEhpZ2hXYXRlciAgQ291bGRmcmVlDQog IDE2ICAgICAgMzYzICAgIDE0OSAgIDE4OTIwNzAxICAgIDEyODAgICAgICAg ICAgMA0KICAzMiAgICAgIDIzOCAgIDMyMTggICAgIDMzNjU2MiAgICAgNjQw ICAgICAxNDIzNzMNCiAgNjQgICAgMzc4NjUgICAyNTgzICAgIDUzMTUwNDcg ICAgIDMyMCAgICAgICAxMDc1DQogMTI4ICAgICAxNDc1ICAgIDQ3NyAgICAg NDc4NzI1ICAgICAxNjAgICAgIDE2ODc0OA0KIDI1NiAgICAzNzI4NSAgICAx MDcgICAgMzMyNTAxNiAgICAgIDgwICAgICAgICAgMjUNCiA1MTIgICAgICAg NjQgICAgIDE2ICAgICAgMTgzMzUgICAgICA0MCAgICAgICAgICAwDQogIDFL ICAgICAgIDE0ICAgIDczMCAgICAgIDcxOTc1ICAgICAgMjAgICAgICAzNjIw NA0KICAySyAgICAgICAxNiAgICAgMjYgICAgICAgIDUyNyAgICAgIDEwICAg ICAgICAzMDANCiAgNEsgICAgICAgMTcgICAgICAxICAgICAgIDE0MzIgICAg ICAgNSAgICAgICAgICAwDQogIDhLICAgICAgICAzICAgICAgMyAgICAgICA3 NjEyICAgICAgIDUgICAgICAgICAgMA0KIDE2SyAgICAgICAxNSAgICAgIDAg ICAgICAgICAxOSAgICAgICA1ICAgICAgICAgIDANCiAzMksgICAgICAgIDIg ICAgICAwICAgICAgICAgIDIgICAgICAgNSAgICAgICAgICAwDQoxMjhLICAg ICAgICAxICAgICAgMCAgICAgICAgICAxICAgICAgIDUgICAgICAgICAgMA0K NTEySyAgICAgICAgMCAgICAgIDAgICAgICAgICAgMiAgICAgICA1ICAgICAg ICAgIDANCg0KTWVtb3J5IHVzYWdlIHR5cGUgYnkgYnVja2V0IHNpemUNClNp emUgIFR5cGUocykNCiAgMTYgIHVjX2Rldmxpc3QsIG5leHVzZGV2LCBwMTAw My4xYiwgcHJvYy1hcmdzLCBrZXkgbWdtdCwgaXA2X21vcHRpb25zLA0KCSAg SXA2RncvSXA2QWNjdCwgcm91dGV0YmwsIGV0aGVyX211bHRpLCB2bm9kZXMs IG1vdW50LCBwY2IsIHNvbmFtZSwNCgkgIHRhZywga2xkLCBBVEEgZ2VuZXJp YywgTUQgZGlzaywgcm1hbiwgYnVzLCBzeXNjdGwsIHRlbXAsIGRldmJ1ZiwN CgkgIGF0ZXhpdA0KICAzMiAgYXRrYmRkZXYsIGxpbnV4LCBkaXJyZW0sIGRp cmFkZCwgZnJlZWZpbGUsIGZyZWVmcmFnLCBpbmRpcmRlcCwNCgkgIGJtc2Fm ZW1hcCwgbmV3YmxrLCBwcm9jLWFyZ3MsIHRzZWdfcWVudCwgaW5fbXVsdGks IHJvdXRldGJsLA0KCSAgZXRoZXJfbXVsdGksIGlmYWRkciwgQlBGLCB2bm9k ZXMsIGNsdXN0ZXJfc2F2ZSBidWZmZXIsIHBjYiwgc29uYW1lLA0KCSAgc2ln aW8sIGtsZCwgdGFza3F1ZXVlLCBTV0FQLCBldmVudGhhbmRsZXIsIGJ1cywg c3lzY3RsLCB1aWRpbmZvLA0KCSAgc3VicHJvYywgcGdycCwgQVRBUEkgZ2Vu ZXJpYywgdGVtcCwgZGV2YnVmDQogIDY0ICBpc2FkZXYsIGFsbG9jaW5kaXIs IGFsbG9jZGlyZWN0LCBwYWdlZGVwLCBwcm9jLWFyZ3MsIGluNl9tdWx0aSwN CgkgIHJvdXRldGJsLCBldGhlcl9tdWx0aSwgaWZhZGRyLCB2bm9kZXMsIGNs dXN0ZXJfc2F2ZSBidWZmZXIsIHZmc2NhY2hlLA0KCSAgcGNiLCB0YWcsIGZp bGUsIEFSIGRyaXZlciwgQUQgZHJpdmVyLCBybWFuLCBldmVudGhhbmRsZXIs IGJ1cywNCgkgIHN1YnByb2MsIHNlc3Npb24sIGlwNm5kcCwgdGVtcCwgZGV2 YnVmLCBsb2NrZg0KIDEyOCAgWk9ORSwgem9tYmllLCBmcmVlYmxrcywgaW5v ZGVkZXAsIHByb2MtYXJncywgcm91dGV0YmwsIHZub2RlcywgbW91bnQsDQoJ ICBjbHVzdGVyX3NhdmUgYnVmZmVyLCB2ZnNjYWNoZSwgc29uYW1lLCB0dHlz LCBkZXZfdCwgdGltZWNvdW50ZXIsIGtsZCwNCgkgIGJ1cywgY3JlZCwgQVRB UEkgZ2VuZXJpYywgaXA2bmRwLCB0ZW1wLCBkZXZidWYNCiAyNTYgIEZGUyBu b2RlLCBuZXdibGssIHByb2MtYXJncywgTkZTIGRhZW1vbiwgSXA2RncvSXA2 QWNjdCwgSXBGdy9JcEFjY3QsDQoJICByb3V0ZXRibCwgc3RmLCBmYWl0aCwg aWZhZGRyLCB2bm9kZXMsIGtxdWV1ZSwgdHR5cywgZmlsZSBkZXNjLA0KCSAg QUNEIGRyaXZlciwgYnVzLCB1aWRpbmZvLCBzdWJwcm9jLCB0ZW1wLCBkZXZi dWYNCiA1MTIgIFVGUyBtb3VudCwga2V5IG1nbXQsIHJvdXRldGJsLCBpZmFk ZHIsIG1vdW50LCBCSU8gYnVmZmVyLCBwdHlzLA0KCSAgQVRBIGdlbmVyaWMs IEFSIGRyaXZlciwgbXNnLCBpb2N0bG9wcywgYnVzLCB0ZW1wLCBkZXZidWYN CiAgMUsgIHVjX2Rldmxpc3QsIE5RTkZTIExlYXNlLCBFeHBvcnQgSG9zdCwg aWZhZGRyLCBCSU8gYnVmZmVyLCBrcXVldWUsDQoJICBNRCBkaXNrLCBzZW0s IEFEIGRyaXZlciwgaW9jdGxvcHMsIGJ1cywgcHJvYywgaXA2bmRwLCB0ZW1w LCBkZXZidWYNCiAgMksgIFVGUyBtb3VudCwgcGFnZWRlcCwgaWZhZGRyLCBC SU8gYnVmZmVyLCBwY2IsIEFSIGRyaXZlciwgaW9jdGxvcHMsDQoJICBBQ0Qg ZHJpdmVyLCBidXMsIGRldmJ1Zg0KICA0SyAgbWJ1ZiwgVk0gcGdkYXRhLCBV RlMgbW91bnQsIHNlbSwgbXNnLCBpb2N0bG9wcywgYnVzLCB0ZW1wLCBkZXZi dWYNCiAgOEsgIFVGUyBtb3VudCwgaW5kaXJkZXAsIHN5bmNhY2hlLCBNU0RP U0ZTIG1vdW50DQogMTZLICBVRlMgaWhhc2gsIGlub2RlZGVwLCBORlMgaGFz aCwgc2htLCBJU09GUyBtb3VudCwgbXNnLCBidXMsIGRldmJ1Zg0KIDMySyAg dmZzY2FjaGUsIHRlbXANCjEyOEsgIFNXQVANCjUxMksgIHRlbXANCg0KTWVt b3J5IHN0YXRpc3RpY3MgYnkgdHlwZSAgICAgICAgICAgICAgICAgICAgICAg ICAgVHlwZSAgS2Vybg0KICAgICAgICBUeXBlICBJblVzZSBNZW1Vc2UgSGln aFVzZSAgTGltaXQgUmVxdWVzdHMgTGltaXQgTGltaXQgU2l6ZShzKQ0KICAg ICBhdGtiZGRldiAgICAgMiAgICAgMUsgICAgICAxSyAxMDE0OEsgICAgICAg IDIgICAgMCAgICAgMCAgMzINCiAgICAgICAgbGludXggICAgIDggICAgIDFL ICAgICAgMUsgMTAxNDhLICAgICAgICA4ICAgIDAgICAgIDAgIDMyDQogICB1 Y19kZXZsaXN0ICAgICAwICAgICAwSyAgICAgIDJLIDEwMTQ4SyAgICAgICAx OCAgICAwICAgICAwICAxNiwxSw0KICAgICBuZXh1c2RldiAgICAgNCAgICAg MUsgICAgICAxSyAxMDE0OEsgICAgICAgIDQgICAgMCAgICAgMCAgMTYNCiAg ICAgICAgIG1idWYgICAgIDEgICAgIDRLICAgICAgNEsgMTAxNDhLICAgICAg ICAxICAgIDAgICAgIDAgIDRLDQogICAgICAgaXNhZGV2ICAgIDEzICAgICAx SyAgICAgIDFLIDEwMTQ4SyAgICAgICAxMyAgICAwICAgICAwICA2NA0KICAg ICAgICAgWk9ORSAgICAxNSAgICAgMksgICAgICAySyAxMDE0OEsgICAgICAg MTUgICAgMCAgICAgMCAgMTI4DQogICAgVk0gcGdkYXRhICAgICAxICAgICA0 SyAgICAgIDRLIDEwMTQ4SyAgICAgICAgMSAgICAwICAgICAwICA0Sw0KICAg ICAgIHpvbWJpZSAgICAgMCAgICAgMEsgICAgICAxSyAxMDE0OEsgICAxNjcw NjUgICAgMCAgICAgMCAgMTI4DQogICAgVUZTIG1vdW50ICAgIDEyICAgIDI2 SyAgICAgMjZLIDEwMTQ4SyAgICAgICAxMiAgICAwICAgICAwICA1MTIsMkss NEssOEsNCiAgICBVRlMgaWhhc2ggICAgIDEgICAgMTZLICAgICAxNksgMTAx NDhLICAgICAgICAxICAgIDAgICAgIDAgIDE2Sw0KICAgICBGRlMgbm9kZSAg NDYyNiAgMTE1N0sgICAxMTc0SyAxMDE0OEsgICA3MzY3MzUgICAgMCAgICAg MCAgMjU2DQogICAgICAgZGlycmVtICAgICAwICAgICAwSyAgICAgIDFLIDEw MTQ4SyAgICAgICAxMiAgICAwICAgICAwICAzMg0KICAgICAgIGRpcmFkZCAg ICAgMCAgICAgMEsgICAgICAxSyAxMDE0OEsgICAgICAgMjEgICAgMCAgICAg MCAgMzINCiAgICAgZnJlZWZpbGUgICAgIDAgICAgIDBLICAgICAgMUsgMTAx NDhLICAgICAgICA2ICAgIDAgICAgIDAgIDMyDQogICAgIGZyZWVibGtzICAg ICAwICAgICAwSyAgICAgIDFLIDEwMTQ4SyAgICAgICAgNiAgICAwICAgICAw ICAxMjgNCiAgICAgZnJlZWZyYWcgICAgIDAgICAgIDBLICAgICAgMUsgMTAx NDhLICAgICAxNDE2ICAgIDAgICAgIDAgIDMyDQogICBhbGxvY2luZGlyICAg ICAyICAgICAxSyAgICAgIDJLIDEwMTQ4SyAgICA4NDUwNCAgICAwICAgICAw ICA2NA0KICAgICBpbmRpcmRlcCAgICAgMSAgICAgMUsgICAgIDI1SyAxMDE0 OEsgICAgIDc3NTAgICAgMCAgICAgMCAgMzIsOEsNCiAgYWxsb2NkaXJlY3Qg ICAgIDAgICAgIDBLICAgICAgMksgMTAxNDhLICAgICAgNTMyICAgIDAgICAg IDAgIDY0DQogICAgYm1zYWZlbWFwICAgICAxICAgICAxSyAgICAgIDFLIDEw MTQ4SyAgICAgNzk1NiAgICAwICAgICAwICAzMg0KICAgICAgIG5ld2JsayAg ICAgMSAgICAgMUsgICAgICAxSyAxMDE0OEsgICAgODUwMzcgICAgMCAgICAg MCAgMzIsMjU2DQogICAgIGlub2RlZGVwICAgICAxICAgIDE2SyAgICAgMTdL IDEwMTQ4SyAgICAgICAyNyAgICAwICAgICAwICAxMjgsMTZLDQogICAgICBw YWdlZGVwICAgICAxICAgICAySyAgICAgIDNLIDEwMTQ4SyAgICAgICAxNiAg ICAwICAgICAwICA2NCwySw0KICAgICBwMTAwMy4xYiAgICAgMSAgICAgMUsg ICAgICAxSyAxMDE0OEsgICAgICAgIDEgICAgMCAgICAgMCAgMTYNCiAgICBw cm9jLWFyZ3MgICAgMjEgICAgIDJLICAgICAgNEsgMTAxNDhLICAgMTgzMjc3 ICAgIDAgICAgIDAgIDE2LDMyLDY0LDEyOCwyNTYNCiAgICAgTkZTIGhhc2gg ICAgIDEgICAgMTZLICAgICAxNksgMTAxNDhLICAgICAgICAxICAgIDAgICAg IDAgIDE2Sw0KICBOUU5GUyBMZWFzZSAgICAgMSAgICAgMUsgICAgICAxSyAx MDE0OEsgICAgICAgIDEgICAgMCAgICAgMCAgMUsNCiAgIE5GUyBkYWVtb24g ICAgIDEgICAgIDFLICAgICAgMUsgMTAxNDhLICAgICAgICAxICAgIDAgICAg IDAgIDI1Ng0KICAgICBrZXkgbWdtdCAgICA1MSAgICAxOEsgICAgIDIzSyAx MDE0OEsgICAgIDk0NTkgICAgMCAgICAgMCAgMTYsNTEyDQogaXA2X21vcHRp b25zICAgICAxICAgICAxSyAgICAgIDFLIDEwMTQ4SyAgICAgICAgMSAgICAw ICAgICAwICAxNg0KSXA2RncvSXA2QWNjdCAgICAzMCAgICAgNEsgICAgICA0 SyAxMDE0OEsgICAgICAgMzAgICAgMCAgICAgMCAgMTYsMjU2DQogICAgaW42 X211bHRpICAgIDEwICAgICAxSyAgICAgIDFLIDEwMTQ4SyAgICAgICAxMCAg ICAwICAgICAwICA2NA0KICAgICBzeW5jYWNoZSAgICAgMSAgICAgOEsgICAg ICA4SyAxMDE0OEsgICAgICAgIDEgICAgMCAgICAgMCAgOEsNCiAgICB0c2Vn X3FlbnQgICAgIDAgICAgIDBLICAgICAgMUsgMTAxNDhLICAgICAxNDMzICAg IDAgICAgIDAgIDMyDQogIElwRncvSXBBY2N0ICAgICA1ICAgICAySyAgICAg IDJLIDEwMTQ4SyAgICAgICAgNSAgICAwICAgICAwICAyNTYNCiAgRXhwb3J0 IEhvc3QgICAgIDEgICAgIDFLICAgICAgMUsgMTAxNDhLICAgICAgICAxICAg IDAgICAgIDAgIDFLDQogICAgIGluX211bHRpICAgICAyICAgICAxSyAgICAg IDFLIDEwMTQ4SyAgICAgICAgMiAgICAwICAgICAwICAzMg0KICAgICByb3V0 ZXRibCA2NDk1OSAxMDE0OEsgIDEwMTQ4SyAxMDE0OEsgIDI0NDUzMDYgICAg MCAgICAgMCAgMTYsMzIsNjQsMTI4LDI1Niw1MTINCiAgICAgICAgICBzdGYg ICAgIDEgICAgIDFLICAgICAgMUsgMTAxNDhLICAgICAgICAxICAgIDAgICAg IDAgIDI1Ng0KICAgICAgICBmYWl0aCAgICAgNCAgICAgMUsgICAgICAxSyAx MDE0OEsgICAgICAgIDQgICAgMCAgICAgMCAgMjU2DQogIGV0aGVyX211bHRp ICAgIDM5ICAgICAySyAgICAgIDJLIDEwMTQ4SyAgICAgICAzOSAgICAwICAg ICAwICAxNiwzMiw2NA0KICAgICAgIGlmYWRkciAgICAzOSAgICAxM0sgICAg IDEzSyAxMDE0OEsgICAgICAgMzkgICAgMCAgICAgMCAgMzIsNjQsMjU2LDUx MiwxSywySw0KICAgICAgICAgIEJQRiAgICAgOSAgICAgMUsgICAgICAxSyAx MDE0OEsgICAgICAgIDkgICAgMCAgICAgMCAgMzINCk1TRE9TRlMgbW91bnQg ICAgIDEgICAgIDhLICAgICAgOEsgMTAxNDhLICAgICAgICAxICAgIDAgICAg IDAgIDhLDQogICAgICAgdm5vZGVzICAgIDI1ICAgICA2SyAgICAgIDdLIDEw MTQ4SyAgICAgIDM1NyAgICAwICAgICAwICAxNiwzMiw2NCwxMjgsMjU2DQog ICAgICAgIG1vdW50ICAgICA1ICAgICAzSyAgICAgIDNLIDEwMTQ4SyAgICAg ICAgNyAgICAwICAgICAwICAxNiwxMjgsNTEyDQpjbHVzdGVyX3NhdmUgYnVm ZmVyICAgICAwICAgICAwSyAgICAgIDFLIDEwMTQ4SyAgICAgNDcyMiAgICAw ICAgICAwICAzMiw2NCwxMjgNCiAgICAgdmZzY2FjaGUgIDQ5NzYgICAzNDNL ICAgIDUyMEsgMTAxNDhLICAxMDYyNDMyICAgIDAgICAgIDAgIDY0LDEyOCwz MksNCiAgIEJJTyBidWZmZXIgICAgIDAgICAgIDBLICAgIDcyOUsgMTAxNDhL ICAgIDMzNjM3ICAgIDAgICAgIDAgIDUxMiwxSywySw0KICAgICAgIGtxdWV1 ZSAgICAgMiAgICAgMksgICAgICA3SyAxMDE0OEsgICAgICAyNjIgICAgMCAg ICAgMCAgMjU2LDFLDQogICAgICAgICAgcGNiICAgIDE5ICAgICA1SyAgICAg IDVLIDEwMTQ4SyAgICAgMjc5MSAgICAwICAgICAwICAxNiwzMiw2NCwySw0K ICAgICAgIHNvbmFtZSAgICAgNyAgICAgMUsgICAgICAxSyAxMDE0OEsgICAg MTEwNDMgICAgMCAgICAgMCAgMTYsMzIsMTI4DQogICAgICAgICAgdGFnICAg ICAwICAgICAwSyAgICAgIDFLIDEwMTQ4SyAxODk1MTUwNiAgICAwICAgICAw ICAxNiw2NA0KICAgICAgICBzaWdpbyAgICAgMSAgICAgMUsgICAgICAxSyAx MDE0OEsgICAgICAgIDEgICAgMCAgICAgMCAgMzINCiAgICAgICAgIHB0eXMg ICAgIDIgICAgIDFLICAgICAgMUsgMTAxNDhLICAgICAgICAyICAgIDAgICAg IDAgIDUxMg0KICAgICAgICAgdHR5cyAgIDQ0OCAgICA1N0sgICAgIDU3SyAx MDE0OEsgICAgIDE5MzAgICAgMCAgICAgMCAgMTI4LDI1Ng0KICAgICAgICAg ZmlsZSAgICA3NCAgICAgNUsgICAgICA4SyAxMDE0OEsgIDMwMDMyMDQgICAg MCAgICAgMCAgNjQNCiAgICBmaWxlIGRlc2MgICAgMjcgICAgIDdLICAgICAx NEsgMTAxNDhLICAgMTY3MDkyICAgIDAgICAgIDAgIDI1Ng0KICAgICAgICBk ZXZfdCAgIDg5OCAgIDExM0sgICAgMTEzSyAxMDE0OEsgICAgICA4OTggICAg MCAgICAgMCAgMTI4DQogIHRpbWVjb3VudGVyICAgICA1ICAgICAxSyAgICAg IDFLIDEwMTQ4SyAgICAgICAgNSAgICAwICAgICAwICAxMjgNCiAgICAgICAg ICBzaG0gICAgIDEgICAgMTJLICAgICAxMksgMTAxNDhLICAgICAgICAxICAg IDAgICAgIDAgIDE2Sw0KICAgICAgICAgIGtsZCAgICAgNCAgICAgMUsgICAg ICAxSyAxMDE0OEsgICAgICAgNTEgICAgMCAgICAgMCAgMTYsMzIsMTI4DQog IEFUQSBnZW5lcmljICAgICA2ICAgICAySyAgICAgIDJLIDEwMTQ4SyAgICAg ICAgNyAgICAwICAgICAwICAxNiw1MTINCiAgICBBUiBkcml2ZXIgICAgIDEg ICAgIDFLICAgICAgM0sgMTAxNDhLICAgICAgICA1ICAgIDAgICAgIDAgIDY0 LDUxMiwySw0KICBJU09GUyBtb3VudCAgICAgMSAgICAxNksgICAgIDE2SyAx MDE0OEsgICAgICAgIDEgICAgMCAgICAgMCAgMTZLDQogICAgICBNRCBkaXNr ICAgICAyICAgICAySyAgICAgIDJLIDEwMTQ4SyAgICAgICAgMiAgICAwICAg ICAwICAxNiwxSw0KICAgICAgICAgIHNlbSAgICAgMyAgICAgNksgICAgICA2 SyAxMDE0OEsgICAgICAgIDMgICAgMCAgICAgMCAgMUssNEsNCiAgICBBRCBk cml2ZXIgICAgIDIgICAgIDJLICAgICAgM0sgMTAxNDhLICAgNjQzOTk1ICAg IDAgICAgIDAgIDY0LDFLDQogICAgICAgICAgbXNnICAgICA0ICAgIDI1SyAg ICAgMjVLIDEwMTQ4SyAgICAgICAgNCAgICAwICAgICAwICA1MTIsNEssMTZL DQogICAgICAgICBybWFuICAgIDU1ICAgICA0SyAgICAgIDRLIDEwMTQ4SyAg ICAgIDQyMCAgICAwICAgICAwICAxNiw2NA0KICAgICBpb2N0bG9wcyAgICAg MCAgICAgMEsgICAgICA0SyAxMDE0OEsgICAgICAgMzEgICAgMCAgICAgMCAg NTEyLDFLLDJLLDRLDQogICAgdGFza3F1ZXVlICAgICAyICAgICAxSyAgICAg IDFLIDEwMTQ4SyAgICAgICAgMiAgICAwICAgICAwICAzMg0KICAgICAgICAg U1dBUCAgICAgMiAgICA3M0sgICAgIDczSyAxMDE0OEsgICAgICAgIDIgICAg MCAgICAgMCAgMzIsMTI4Sw0KICAgQUNEIGRyaXZlciAgICAgMiAgICAgM0sg ICAgICAzSyAxMDE0OEsgICAgICAgIDIgICAgMCAgICAgMCAgMjU2LDJLDQog ZXZlbnRoYW5kbGVyICAgIDEyICAgICAxSyAgICAgIDFLIDEwMTQ4SyAgICAg ICAxMiAgICAwICAgICAwICAzMiw2NA0KICAgICAgICAgIGJ1cyAgIDQ1MCAg ICA0N0sgICAgIDUySyAxMDE0OEsgICAgICA4NDYgICAgMCAgICAgMCAgMTYs MzIsNjQsMTI4LDI1Niw1MTIsMUssMkssNEssMTZLDQogICAgICAgc3lzY3Rs ICAgICAwICAgICAwSyAgICAgIDFLIDEwMTQ4SyAgICAgOTI0OSAgICAwICAg ICAwICAxNiwzMg0KICAgICAgdWlkaW5mbyAgICAgNCAgICAgMUsgICAgICAx SyAxMDE0OEsgICAgICA3OTYgICAgMCAgICAgMCAgMzIsMjU2DQogICAgICAg ICBjcmVkICAgIDE3ICAgICAzSyAgICAgIDNLIDEwMTQ4SyAgIDI0MjI2OCAg ICAwICAgICAwICAxMjgNCiAgICAgIHN1YnByb2MgICAgNjYgICAgIDZLICAg ICAxMEsgMTAxNDhLICAgMzc1MTQxICAgIDAgICAgIDAgIDMyLDY0LDI1Ng0K ICAgICAgICAgcHJvYyAgICAgMiAgICAgMksgICAgICAySyAxMDE0OEsgICAg ICAgIDIgICAgMCAgICAgMCAgMUsNCiAgICAgIHNlc3Npb24gICAgMTkgICAg IDJLICAgICAgMksgMTAxNDhLICAgICAyMDAzICAgIDAgICAgIDAgIDY0DQog ICAgICAgICBwZ3JwICAgIDIwICAgICAxSyAgICAgIDFLIDEwMTQ4SyAgICAg MjA0MCAgICAwICAgICAwICAzMg0KQVRBUEkgZ2VuZXJpYyAgICAgMSAgICAg MUsgICAgICAxSyAxMDE0OEsgICAgICAgIDMgICAgMCAgICAgMCAgMzIsMTI4 DQogICAgICAgaXA2bmRwICAgICA2ICAgICAySyAgICAgIDJLIDEwMTQ4SyAg ICAgICAgOCAgICAwICAgICAwICA2NCwxMjgsMUsNCiAgICAgICAgIHRlbXAg ICAyMzAgICAgNDFLICAgMTAxNUsgMTAxNDhLICAgMjI3OTcwICAgIDAgICAg IDAgIDE2LDMyLDY0LDEyOCwyNTYsNTEyLDFLLDRLLDMySyw1MTJLDQogICAg ICAgZGV2YnVmICAgIDg1ICAgMTgzSyAgICAxODNLIDEwMTQ4SyAgICAgIDEz MSAgICAwICAgICAwICAxNiwzMiw2NCwxMjgsMjU2LDUxMiwxSywySyw0Sywx NksNCiAgICAgICAgbG9ja2YgICAgIDMgICAgIDFLICAgICAgMUsgMTAxNDhL ICAgICAgMjkxICAgIDAgICAgIDAgIDY0DQogICAgICAgYXRleGl0ICAgICAx ICAgICAxSyAgICAgIDFLIDEwMTQ4SyAgICAgICAgMSAgICAwICAgICAwICAx Ng0KDQpNZW1vcnkgVG90YWxzOiAgSW4gVXNlICAgICAgIEZyZWUgICAgUmVx dWVzdHMNCiAgICAgICAgICAgICAgICAxMjQxNksgICAgICAxMTY5SyAgICAy ODQ3NTk1Ng0K --1589707168-126566817-1096015867=:5289-- From owner-freebsd-net@FreeBSD.ORG Fri Sep 24 11:58:06 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 12AF116A4D1 for ; Fri, 24 Sep 2004 11:58:06 +0000 (GMT) Received: from mxb.rambler.ru (mxb.rambler.ru [81.19.66.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8995C43D45 for ; Fri, 24 Sep 2004 11:58:05 +0000 (GMT) (envelope-from pij@rambler.ru) Received: from mail5.rambler.ru (mail5.rambler.ru [81.19.66.7]) by mxb.rambler.ru (Postfix) with ESMTP id 3672884498 for ; Fri, 24 Sep 2004 15:58:03 +0400 (MSD) Received: from [81.19.66.146] (account pij@rambler.ru) by mail5.rambler.ru (CommuniGate Pro WebUser 4.2) with HTTP id 74855704 for freebsd-net@freebsd.org; Fri, 24 Sep 2004 15:58:03 +0400 From: "Pavel V.Zheltobryukhov" To: freebsd-net@freebsd.org X-Mailer: CommuniGate Pro WebUser Interface v.4.2 Date: Fri, 24 Sep 2004 15:58:03 +0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="KOI8-R"; format="flowed" Content-Transfer-Encoding: 8bit Subject: Intel PRO/1000 CT (82547EI) - em0: watchdog timeout X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 24 Sep 2004 11:58:06 -0000 I have Intel 7210 Server Board with Intel PRO/1000 CT (82547EI) on-board. This NIC work fine under Win2K, but then I boot FreeBSD 5.2.1 I've got a message on console: em0: Link up 100Mbit full duplex and boot process suspended at this moment. After approx. 1 minute next messages appear em0: Watchdog timeout -- resetting em0: Link up 100Mbit full duplex em0: Watchdog timeout -- resetting I send Ctrl+C and boot process was continued. But network card doesn't work. I check cable - it's good. I can't send any ping packet to other computers. I tried other transmit modes - I switch NIC to 10Mbit half duplex and 10Mbit full duplex via ifconfig options. No result. What is a problem? Bad driver? That is not a card problem, because (as I wrote above) it work in Windows. From owner-freebsd-net@FreeBSD.ORG Fri Sep 24 12:30:24 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5936416A4CF for ; Fri, 24 Sep 2004 12:30:24 +0000 (GMT) Received: from mail.borderware.com (mail.borderware.com [207.236.65.231]) by mx1.FreeBSD.org (Postfix) with ESMTP id 50D4743D1F for ; Fri, 24 Sep 2004 12:30:17 +0000 (GMT) (envelope-from fming@borderware.com) Message-ID: <41541355.50800@borderware.com> Date: Fri, 24 Sep 2004 08:30:13 -0400 From: ming fu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040413 Debian/1.6-5 X-Accept-Language: en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: promisc coding question X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 24 Sep 2004 12:30:24 -0000 Hi, in if.h #define IFF_PROMISC 0x100 /* receive all packets */ #define IFF_PPROMISC 0x20000 /* user-requested promisc mode */ Do I have to set both on for the promisc to work? If I only need one of them, then what is the difference? Regards, Ming From owner-freebsd-net@FreeBSD.ORG Fri Sep 24 13:20:04 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C667A16A4CE for ; Fri, 24 Sep 2004 13:20:04 +0000 (GMT) Received: from silver.he.iki.fi (helenius.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6AD3E43D2D for ; Fri, 24 Sep 2004 13:20:03 +0000 (GMT) (envelope-from pete@he.iki.fi) Received: from [195.163.185.142] (i2-142.rommon.fi [195.163.185.142]) by silver.he.iki.fi (8.12.10/8.11.4) with ESMTP id i8ODK0m1009661; Fri, 24 Sep 2004 16:20:00 +0300 (EEST) (envelope-from pete@he.iki.fi) Message-ID: <41541F01.5070906@he.iki.fi> Date: Fri, 24 Sep 2004 16:20:01 +0300 From: Petri Helenius User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pavel V.Zheltobryukhov" References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: Intel PRO/1000 CT (82547EI) - em0: watchdog timeout X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 24 Sep 2004 13:20:04 -0000 Pavel V.Zheltobryukhov wrote: > > I send Ctrl+C and boot process was continued. But network card doesn't > work. I check cable - it's good. I can't send any ping packet to other > computers. I tried other transmit modes - I switch NIC to 10Mbit half > duplex and 10Mbit full duplex via ifconfig options. No result. What is > a problem? Bad driver? That is not a card problem, because (as I wrote > above) it work in Windows. This is a BIOS problem. Many BIOSes which come with CSA ethernet chips have broken interrupt routing information. Pete From owner-freebsd-net@FreeBSD.ORG Fri Sep 24 13:41:33 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8BEC416A4CE for ; Fri, 24 Sep 2004 13:41:33 +0000 (GMT) Received: from smtp010.tiscali.dk (smtp010.tiscali.dk [212.54.64.103]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3A31543D39 for ; Fri, 24 Sep 2004 13:41:32 +0000 (GMT) (envelope-from news@undercover.dk) Received: from TBS0016 (62.79.20.143.adsl.suoe.tiscali.dk [62.79.20.143]) by smtp010.tiscali.dk (8.12.10/8.12.10) with SMTP id i8ODWdC1004527 for ; Fri, 24 Sep 2004 15:32:39 +0200 (MEST) Message-ID: <002301c4a23c$3222b790$1b6d18ac@TBS0016> From: "Thomas" To: Date: Fri, 24 Sep 2004 15:41:28 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Subject: Driver for SURECOM EP-320X-S 100/10M Ethernet PCI Adapter X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 24 Sep 2004 13:41:33 -0000 Hi All I have a Surecom Ethernet Adapter where there's a FreeBSD driver available for download at the manufactors website. However I think it is for FreeBSD 4.x because it won't compile on my FreeBSD 5.2.1-release system. Is anybody up for converting the driver to 5.x, or does anybody know if there's an alternate driver for this NIC? Thanks. Driver consists of 2 files: if_fet.c & if_fetreg.h (see below): if_fet.c -------------------------------------------------------------- /* * fast ethernet PCI NIC driver */ #include "bpfilter.h" #include #include #include #include #include #include #include #include #include #include #include #include #if NBPFILTER > 0 #include #endif #include /* for vtophys */ #include /* for vtophys */ #include /* for DELAY */ #include #include #include #include #include /* #define FET_USEIOSPACE */ static int FET_USEIOSPACE=1; #include #ifndef lint static const char rcsid[] = "$Id: if_fet.c,v 1.30 2000/12/29 09:28:52 wpaul Exp $"; #endif /* * Various supported device vendors/types and their names. */ struct fet_type *fet_info_tmp; static struct fet_type fet_devs[] = { { FETVENDORID, ID0, "100/10M Ethernet PCI Adapter" }, { FETVENDORID, ID1, "100/10M Ethernet PCI Adapter" }, { FETVENDORID, ID2, "1000/100/10M Ethernet PCI Adapter" }, { 0, 0, NULL } }; /* * Various supported PHY vendors/types and their names. Note that * this driver will work with pretty much any MII-compliant PHY, * so failure to positively identify the chip is not a fatal error. */ static struct fet_type fet_phys[] = { { MysonPHYID0, MysonPHYID0, ""}, { SeeqPHYID0, SeeqPHYID0, "" }, { AhdocPHYID0, AhdocPHYID0, "" }, { MarvellPHYID0, MarvellPHYID0, ""}, { LevelOnePHYID0, LevelOnePHYID0, ""}, { 0, 0, "" } }; static unsigned long fet_count = 0; static const char *fet_probe __P((pcici_t, pcidi_t)); static void fet_attach __P((pcici_t, int)); static int fet_newbuf __P((struct fet_softc *, struct fet_chain_onefrag *)); static int fet_encap __P((struct fet_softc *, struct fet_chain *, struct mbuf *)); static void fet_rxeof __P((struct fet_softc *)); static void fet_txeof __P((struct fet_softc *)); static void fet_txeoc __P((struct fet_softc *)); static void fet_intr __P((void *)); static void fet_start __P((struct ifnet *)); static int fet_ioctl __P((struct ifnet *, u_long, caddr_t)); static void fet_init __P((void *)); static void fet_stop __P((struct fet_softc *)); static void fet_watchdog __P((struct ifnet *)); static void fet_shutdown __P((int, void *)); static int fet_ifmedia_upd __P((struct ifnet *)); static void fet_ifmedia_sts __P((struct ifnet *, struct ifmediareq *)); static u_int16_t fet_phy_readreg __P((struct fet_softc *, int)); static void fet_phy_writereg __P((struct fet_softc *, int, int)); static void fet_autoneg_xmit __P((struct fet_softc *)); static void fet_autoneg_mii __P((struct fet_softc *, int, int)); static void fet_setmode_mii __P((struct fet_softc *, int)); static void fet_getmode_mii __P((struct fet_softc *)); static void fet_setcfg __P((struct fet_softc *, int)); static u_int8_t fet_calchash __P((caddr_t)); static void fet_setmulti __P((struct fet_softc *)); static void fet_reset __P((struct fet_softc *)); static int fet_list_rx_init __P((struct fet_softc *)); static int fet_list_tx_init __P((struct fet_softc *)); static long fet_send_cmd_to_phy __P((struct fet_softc *, int, int)); #define FET_SETBIT(sc, reg, x) CSR_WRITE_4(sc, reg, CSR_READ_4(sc, reg) | x) #define FET_CLRBIT(sc, reg, x) CSR_WRITE_4(sc, reg, CSR_READ_4(sc, reg) & ~x) static long fet_send_cmd_to_phy(sc, opcode, regad) struct fet_softc *sc; int opcode; int regad; { long miir; int i; int mask, data; /* enable MII output */ miir=CSR_READ_4(sc, FET_MANAGEMENT); miir&=0xfffffff0; miir|=FET_MASK_MIIR_MII_WRITE+FET_MASK_MIIR_MII_MDO; /* send 32 1's preamble */ for (i=0;i<32;i++) { /* low MDC; MDO is already high (miir) */ miir&=~FET_MASK_MIIR_MII_MDC; CSR_WRITE_4(sc, FET_MANAGEMENT, miir); /* high MDC */ miir|=FET_MASK_MIIR_MII_MDC; CSR_WRITE_4(sc, FET_MANAGEMENT, miir); } /* calculate ST+OP+PHYAD+REGAD+TA */ data=opcode|(sc->fet_phy_addr<<7)|(regad<<2); /* sent out */ mask=0x8000; while (mask) { /* low MDC, prepare MDO */ miir&=~(FET_MASK_MIIR_MII_MDC+FET_MASK_MIIR_MII_MDO); if (mask & data) miir|=FET_MASK_MIIR_MII_MDO; CSR_WRITE_4(sc, FET_MANAGEMENT, miir); /* high MDC */ miir|=FET_MASK_MIIR_MII_MDC; CSR_WRITE_4(sc, FET_MANAGEMENT, miir); DELAY(30); /* next */ mask>>=1; if (mask==0x2 && opcode==FET_OP_READ) miir&=~FET_MASK_MIIR_MII_WRITE; } return miir; } static u_int16_t fet_phy_readreg(sc, reg) struct fet_softc *sc; int reg; { long miir; int mask, data; if (sc->fet_info->fet_did == ID1) data = CSR_READ_2(sc, FET_PHYBASE+reg*2); else { miir=fet_send_cmd_to_phy(sc, FET_OP_READ, reg); /* read data */ mask=0x8000; data=0; while (mask) { /* low MDC */ miir&=~FET_MASK_MIIR_MII_MDC; CSR_WRITE_4(sc, FET_MANAGEMENT, miir); /* read MDI */ miir=CSR_READ_4(sc, FET_MANAGEMENT); if (miir & FET_MASK_MIIR_MII_MDI) data|=mask; /* high MDC, and wait */ miir|=FET_MASK_MIIR_MII_MDC; CSR_WRITE_4(sc, FET_MANAGEMENT, miir); DELAY(30); /* next */ mask>>=1; } /* low MDC */ miir&=~FET_MASK_MIIR_MII_MDC; CSR_WRITE_4(sc, FET_MANAGEMENT, miir); } return (u_int16_t)data; } static void fet_phy_writereg(sc, reg, data) struct fet_softc *sc; int reg; int data; { long miir; int mask; if (sc->fet_info->fet_did == ID1) CSR_WRITE_2(sc, FET_PHYBASE+reg*2, data); else { miir=fet_send_cmd_to_phy(sc, FET_OP_WRITE, reg); /* write data */ mask=0x8000; while (mask) { /* low MDC, prepare MDO */ miir&=~(FET_MASK_MIIR_MII_MDC+FET_MASK_MIIR_MII_MDO); if (mask&data) miir|=FET_MASK_MIIR_MII_MDO; CSR_WRITE_4(sc, FET_MANAGEMENT, miir); DELAY(1); /* high MDC */ miir|=FET_MASK_MIIR_MII_MDC; CSR_WRITE_4(sc, FET_MANAGEMENT, miir); DELAY(1); /* next */ mask>>=1; } /* low MDC */ miir&=~FET_MASK_MIIR_MII_MDC; CSR_WRITE_4(sc, FET_MANAGEMENT, miir); } return; } static u_int8_t fet_calchash(addr) caddr_t addr; { u_int32_t crc, carry; int i, j; u_int8_t c; /* Compute CRC for the address value. */ crc = 0xFFFFFFFF; /* initial value */ for (i = 0; i < 6; i++) { c = *(addr + i); for (j = 0; j < 8; j++) { carry = ((crc & 0x80000000) ? 1 : 0) ^ (c & 0x01); crc <<= 1; c >>= 1; if (carry) crc = (crc ^ 0x04c11db6) | carry; } } /* * return the filter bit position * Note: I arrived at the following nonsense * through experimentation. It's not the usual way to * generate the bit position but it's the only thing * I could come up with that works. */ return(~(crc >> 26) & 0x0000003F); } /* * Program the 64-bit multicast hash filter. */ static void fet_setmulti(sc) struct fet_softc *sc; { struct ifnet *ifp; int h = 0; u_int32_t hashes[2] = { 0, 0 }; struct ifmultiaddr *ifma; u_int32_t rxfilt; int mcnt = 0; ifp = &sc->arpcom.ac_if; rxfilt = CSR_READ_4(sc, FET_TCRRCR); if (ifp->if_flags & IFF_ALLMULTI || ifp->if_flags & IFF_PROMISC) { rxfilt |= FET_AM; CSR_WRITE_4(sc, FET_TCRRCR, rxfilt); CSR_WRITE_4(sc, FET_MAR0, 0xFFFFFFFF); CSR_WRITE_4(sc, FET_MAR1, 0xFFFFFFFF); return; } /* first, zot all the existing hash bits */ CSR_WRITE_4(sc, FET_MAR0, 0); CSR_WRITE_4(sc, FET_MAR1, 0); /* now program new ones */ for (ifma = ifp->if_multiaddrs.lh_first; ifma != NULL; ifma = ifma->ifma_link.le_next) { if (ifma->ifma_addr->sa_family != AF_LINK) continue; h = fet_calchash(LLADDR((struct sockaddr_dl *)ifma->ifma_addr)); if (h < 32) hashes[0] |= (1 << h); else hashes[1] |= (1 << (h - 32)); mcnt++; } if (mcnt) rxfilt |= FET_AM; else rxfilt &= ~FET_AM; CSR_WRITE_4(sc, FET_MAR0, hashes[0]); CSR_WRITE_4(sc, FET_MAR1, hashes[1]); CSR_WRITE_4(sc, FET_TCRRCR, rxfilt); return; } /* * Initiate an autonegotiation session. */ static void fet_autoneg_xmit(sc) struct fet_softc *sc; { u_int16_t phy_sts; fet_phy_writereg(sc, PHY_BMCR, PHY_BMCR_RESET); DELAY(500); while(fet_phy_readreg(sc, PHY_BMCR) & PHY_BMCR_RESET); phy_sts = fet_phy_readreg(sc, PHY_BMCR); phy_sts |= PHY_BMCR_AUTONEGENBL|PHY_BMCR_AUTONEGRSTR; fet_phy_writereg(sc, PHY_BMCR, phy_sts); return; } /* * Invoke autonegotiation on a PHY. */ static void fet_autoneg_mii(sc, flag, verbose) struct fet_softc *sc; int flag; int verbose; { u_int16_t phy_sts = 0, media, advert, ability; u_int16_t ability2 = 0; struct ifnet *ifp; struct ifmedia *ifm; ifm = &sc->ifmedia; ifp = &sc->arpcom.ac_if; ifm->ifm_media = IFM_ETHER | IFM_AUTO; #ifndef FORCE_AUTONEG_TFOUR /* * First, see if autoneg is supported. If not, there's * no point in continuing. */ phy_sts = fet_phy_readreg(sc, PHY_BMSR); if (!(phy_sts & PHY_BMSR_CANAUTONEG)) { if (verbose) printf("fet%d: autonegotiation not supported\n", sc->fet_unit); ifm->ifm_media = IFM_ETHER|IFM_10_T|IFM_HDX; return; } #endif switch (flag) { case FET_FLAG_FORCEDELAY: /* * XXX Never use this option anywhere but in the probe * routine: making the kernel stop dead in its tracks * for three whole seconds after we've gone multi-user * is really bad manners. */ fet_autoneg_xmit(sc); DELAY(5000000); break; case FET_FLAG_SCHEDDELAY: /* * Wait for the transmitter to go idle before starting * an autoneg session, otherwise fet_start() may clobber * our timeout, and we don't want to allow transmission * during an autoneg session since that can screw it up. */ if (sc->fet_cdata.fet_tx_head != NULL) { sc->fet_want_auto = 1; return; } fet_autoneg_xmit(sc); ifp->if_timer = 5; sc->fet_autoneg = 1; sc->fet_want_auto = 0; return; case FET_FLAG_DELAYTIMEO: ifp->if_timer = 0; sc->fet_autoneg = 0; break; default: printf("fet%d: invalid autoneg flag: %d\n", sc->fet_unit, flag); return; } if (fet_phy_readreg(sc, PHY_BMSR) & PHY_BMSR_AUTONEGCOMP) { if (verbose) printf("fet%d: autoneg complete, ", sc->fet_unit); phy_sts = fet_phy_readreg(sc, PHY_BMSR); } else { if (verbose) printf("fet%d: autoneg not complete, ", sc->fet_unit); } media = fet_phy_readreg(sc, PHY_BMCR); /* Link is good. Report modes and set duplex mode. */ if (fet_phy_readreg(sc, PHY_BMSR) & PHY_BMSR_LINKSTAT) { if (verbose) printf("fet%d: link status good. ", sc->fet_unit); advert = fet_phy_readreg(sc, PHY_ANAR); ability = fet_phy_readreg(sc, PHY_LPAR); if ( (sc->fet_pinfo->fet_vid == MarvellPHYID0) || (sc->fet_pinfo->fet_vid == LevelOnePHYID0) ) { ability2 = fet_phy_readreg(sc, PHY_1000SR); if (ability2 & PHY_1000SR_1000BTXFULL) { advert = 0; ability = 0; /* this version did not support 1000M, ifm->ifm_media = IFM_ETHER|IFM_1000_TX|IFM_FDX; */ ifm->ifm_media = IFM_ETHER|IFM_100_TX|IFM_FDX; media &= ~PHY_BMCR_SPEEDSEL; media |= PHY_BMCR_1000; media |= PHY_BMCR_DUPLEX; printf("(full-duplex, 1000Mbps)\n"); } else if (ability2 & PHY_1000SR_1000BTXHALF) { advert = 0; ability = 0; /* this version did not support 1000M, ifm->ifm_media = IFM_ETHER|IFM_1000_TX; */ ifm->ifm_media = IFM_ETHER|IFM_100_TX; media &= ~PHY_BMCR_SPEEDSEL; media &= ~PHY_BMCR_DUPLEX; media |= PHY_BMCR_1000; printf("(half-duplex, 1000Mbps)\n"); } } if (advert & PHY_ANAR_100BT4 && ability & PHY_ANAR_100BT4) { ifm->ifm_media = IFM_ETHER|IFM_100_T4; media |= PHY_BMCR_SPEEDSEL; media &= ~PHY_BMCR_DUPLEX; printf("(100baseT4)\n"); } else if (advert & PHY_ANAR_100BTXFULL && ability & PHY_ANAR_100BTXFULL) { ifm->ifm_media = IFM_ETHER|IFM_100_TX|IFM_FDX; media |= PHY_BMCR_SPEEDSEL; media |= PHY_BMCR_DUPLEX; printf("(full-duplex, 100Mbps)\n"); } else if (advert & PHY_ANAR_100BTXHALF && ability & PHY_ANAR_100BTXHALF) { ifm->ifm_media = IFM_ETHER|IFM_100_TX|IFM_HDX; media |= PHY_BMCR_SPEEDSEL; media &= ~PHY_BMCR_DUPLEX; printf("(half-duplex, 100Mbps)\n"); } else if (advert & PHY_ANAR_10BTFULL && ability & PHY_ANAR_10BTFULL) { ifm->ifm_media = IFM_ETHER|IFM_10_T|IFM_FDX; media &= ~PHY_BMCR_SPEEDSEL; media |= PHY_BMCR_DUPLEX; printf("(full-duplex, 10Mbps)\n"); } else if (advert) { ifm->ifm_media = IFM_ETHER|IFM_10_T|IFM_HDX; media &= ~PHY_BMCR_SPEEDSEL; media &= ~PHY_BMCR_DUPLEX; printf("(half-duplex, 10Mbps)\n"); } media &= ~PHY_BMCR_AUTONEGENBL; /* Set ASIC's duplex mode to match the PHY. */ fet_phy_writereg(sc, PHY_BMCR, media); fet_setcfg(sc, media); } else { if (verbose) printf("fet%d: no carrier\n", sc->fet_unit); } fet_init(sc); if (sc->fet_tx_pend) { sc->fet_autoneg = 0; sc->fet_tx_pend = 0; fet_start(ifp); } return; } /* * To get PHY ability. */ static void fet_getmode_mii(sc) struct fet_softc *sc; { u_int16_t bmsr; struct ifnet *ifp; ifp = &sc->arpcom.ac_if; bmsr = fet_phy_readreg(sc, PHY_BMSR); if (bootverbose) printf("fet%d: PHY status word: %x\n", sc->fet_unit, bmsr); /* fallback */ sc->ifmedia.ifm_media = IFM_ETHER|IFM_10_T|IFM_HDX; if (bmsr & PHY_BMSR_10BTHALF) { if (bootverbose) printf("fet%d: 10Mbps half-duplex mode supported\n", sc->fet_unit); ifmedia_add(&sc->ifmedia, IFM_ETHER|IFM_10_T|IFM_HDX, 0, NULL); ifmedia_add(&sc->ifmedia, IFM_ETHER|IFM_10_T, 0, NULL); } if (bmsr & PHY_BMSR_10BTFULL) { if (bootverbose) printf("fet%d: 10Mbps full-duplex mode supported\n", sc->fet_unit); ifmedia_add(&sc->ifmedia, IFM_ETHER|IFM_10_T|IFM_FDX, 0, NULL); sc->ifmedia.ifm_media = IFM_ETHER|IFM_10_T|IFM_FDX; } if (bmsr & PHY_BMSR_100BTXHALF) { if (bootverbose) printf("fet%d: 100Mbps half-duplex mode supported\n", sc->fet_unit); ifp->if_baudrate = 100000000; ifmedia_add(&sc->ifmedia, IFM_ETHER|IFM_100_TX, 0, NULL); ifmedia_add(&sc->ifmedia, IFM_ETHER|IFM_100_TX|IFM_HDX, 0, NULL); sc->ifmedia.ifm_media = IFM_ETHER|IFM_100_TX|IFM_HDX; } if (bmsr & PHY_BMSR_100BTXFULL) { if (bootverbose) printf("fet%d: 100Mbps full-duplex mode supported\n", sc->fet_unit); ifp->if_baudrate = 100000000; ifmedia_add(&sc->ifmedia, IFM_ETHER|IFM_100_TX|IFM_FDX, 0, NULL); sc->ifmedia.ifm_media = IFM_ETHER|IFM_100_TX|IFM_FDX; } /* Some also support 100BaseT4. */ if (bmsr & PHY_BMSR_100BT4) { if (bootverbose) printf("fet%d: 100baseT4 mode supported\n", sc->fet_unit); ifp->if_baudrate = 100000000; ifmedia_add(&sc->ifmedia, IFM_ETHER|IFM_100_T4, 0, NULL); sc->ifmedia.ifm_media = IFM_ETHER|IFM_100_T4; #ifdef FORCE_AUTONEG_TFOUR if (bootverbose) printf("fet%d: forcing on autoneg support for BT4\n", sc->fet_unit); ifmedia_add(&sc->ifmedia, IFM_ETHER|IFM_AUTO, 0 NULL): sc->ifmedia.ifm_media = IFM_ETHER|IFM_AUTO; #endif } /* this version did not support 1000M, if (sc->fet_pinfo->fet_vid == MarvellPHYID0) { if (bootverbose) printf("fet%d: 1000Mbps half-duplex mode supported\n", sc->fet_unit); ifp->if_baudrate = 1000000000; ifmedia_add(&sc->ifmedia, IFM_ETHER|IFM_1000_TX, 0, NULL); ifmedia_add(&sc->ifmedia, IFM_ETHER|IFM_1000_TX|IFM_HDX, 0, NULL); if (bootverbose) printf("fet%d: 1000Mbps full-duplex mode supported\n", sc->fet_unit); ifp->if_baudrate = 1000000000; ifmedia_add(&sc->ifmedia, IFM_ETHER|IFM_1000_TX|IFM_FDX, 0, NULL); sc->ifmedia.ifm_media = IFM_ETHER|IFM_1000_TX|IFM_FDX; } */ if (bmsr & PHY_BMSR_CANAUTONEG) { if (bootverbose) printf("fet%d: autoneg supported\n", sc->fet_unit); ifmedia_add(&sc->ifmedia, IFM_ETHER|IFM_AUTO, 0, NULL); sc->ifmedia.ifm_media = IFM_ETHER|IFM_AUTO; } return; } /* * Set speed and duplex mode. */ static void fet_setmode_mii(sc, media) struct fet_softc *sc; int media; { u_int16_t bmcr; struct ifnet *ifp; ifp = &sc->arpcom.ac_if; printf("enter fet_setmode_mii()\n"); /* * If an autoneg session is in progress, stop it. */ if (sc->fet_autoneg) { printf("fet%d: canceling autoneg session\n", sc->fet_unit); ifp->if_timer = sc->fet_autoneg = sc->fet_want_auto = 0; bmcr = fet_phy_readreg(sc, PHY_BMCR); bmcr &= ~PHY_BMCR_AUTONEGENBL; fet_phy_writereg(sc, PHY_BMCR, bmcr); } printf("fet%d: selecting MII, ", sc->fet_unit); bmcr = fet_phy_readreg(sc, PHY_BMCR); bmcr &= ~(PHY_BMCR_AUTONEGENBL|PHY_BMCR_SPEEDSEL|PHY_BMCR_1000| PHY_BMCR_DUPLEX|PHY_BMCR_LOOPBK); /* this version did not support 1000M, if (IFM_SUBTYPE(media) == IFM_1000_TX) { printf("1000Mbps/T4, half-duplex\n"); bmcr &= ~PHY_BMCR_SPEEDSEL; bmcr &= ~PHY_BMCR_DUPLEX; bmcr |= PHY_BMCR_1000; } */ if (IFM_SUBTYPE(media) == IFM_100_T4) { printf("100Mbps/T4, half-duplex\n"); bmcr |= PHY_BMCR_SPEEDSEL; bmcr &= ~PHY_BMCR_DUPLEX; } if (IFM_SUBTYPE(media) == IFM_100_TX) { printf("100Mbps, "); bmcr |= PHY_BMCR_SPEEDSEL; } if (IFM_SUBTYPE(media) == IFM_10_T) { printf("10Mbps, "); bmcr &= ~PHY_BMCR_SPEEDSEL; } if ((media & IFM_GMASK) == IFM_FDX) { printf("full duplex\n"); bmcr |= PHY_BMCR_DUPLEX; } else { printf("half duplex\n"); bmcr &= ~PHY_BMCR_DUPLEX; } fet_phy_writereg(sc, PHY_BMCR, bmcr); fet_setcfg(sc, bmcr); return; } /* * The Myson manual states that in order to fiddle with the * 'full-duplex' and '100Mbps' bits in the netconfig register, we * first have to put the transmit and/or receive logic in the idle state. */ static void fet_setcfg(sc, bmcr) struct fet_softc *sc; int bmcr; { int i, restart = 0; if (CSR_READ_4(sc, FET_TCRRCR) & (FET_TE|FET_RE)) { restart = 1; FET_CLRBIT(sc, FET_TCRRCR, (FET_TE|FET_RE)); for (i = 0; i < FET_TIMEOUT; i++) { DELAY(10); if (!(CSR_READ_4(sc, FET_TCRRCR)&(FET_TXRUN|FET_RXRUN))) break; } if (i == FET_TIMEOUT) printf("fet%d: failed to force tx and rx to idle state\n", sc->fet_unit); } FET_CLRBIT(sc, FET_TCRRCR, FET_PS1000); FET_CLRBIT(sc, FET_TCRRCR, FET_PS10); if (bmcr & PHY_BMCR_1000) FET_SETBIT(sc, FET_TCRRCR, FET_PS1000); else if (!(bmcr & PHY_BMCR_SPEEDSEL)) FET_SETBIT(sc, FET_TCRRCR, FET_PS10); if (bmcr & PHY_BMCR_DUPLEX) FET_SETBIT(sc, FET_TCRRCR, FET_FD); else FET_CLRBIT(sc, FET_TCRRCR, FET_FD); if (restart) FET_SETBIT(sc, FET_TCRRCR, FET_TE|FET_RE); return; } static void fet_reset(sc) struct fet_softc *sc; { register int i; FET_SETBIT(sc, FET_BCR, FET_SWR); for (i = 0; i < FET_TIMEOUT; i++) { DELAY(10); if (!(CSR_READ_4(sc, FET_BCR) & FET_SWR)) break; } if (i == FET_TIMEOUT) printf("m0x%d: reset never completed!\n", sc->fet_unit); /* Wait a little while for the chip to get its brains in order. */ DELAY(1000); return; } /* * Probe for a Myson chip. Check the PCI vendor and device * IDs against our list and return a device name if we find a match. */ static const char *fet_probe(config_id, device_id) pcici_t config_id; pcidi_t device_id; { struct fet_type *t; t = fet_devs; while(t->fet_name != NULL) { if ((device_id & 0xFFFF) == t->fet_vid && ((device_id >> 16) & 0xFFFF) == t->fet_did) { fet_info_tmp = t; return(t->fet_name); } t++; } return(NULL); } /* * Attach the interface. Allocate softc structures, do ifmedia * setup and ethernet/BPF attach. */ static void fet_attach(config_id, unit) pcici_t config_id; int unit; { int s, i; vm_offset_t pbase, vbase; u_char eaddr[ETHER_ADDR_LEN]; u_int32_t command, iobase; struct fet_softc *sc; struct ifnet *ifp; int media = IFM_ETHER|IFM_100_TX|IFM_FDX; unsigned int round; caddr_t roundptr; struct fet_type *p; u_int16_t phy_vid, phy_did, phy_sts; s = splimp(); sc = malloc(sizeof(struct fet_softc), M_DEVBUF, M_NOWAIT); if (sc == NULL) { printf("fet%d: no memory for softc struct!\n", unit); return; } bzero(sc, sizeof(struct fet_softc)); /* * Map control/status registers. */ command = pci_conf_read(config_id, PCI_COMMAND_STATUS_REG); command |= (PCIM_CMD_PORTEN|PCIM_CMD_MEMEN|PCIM_CMD_BUSMASTEREN); pci_conf_write(config_id, PCI_COMMAND_STATUS_REG, command); command = pci_conf_read(config_id, PCI_COMMAND_STATUS_REG); if (fet_info_tmp->fet_did==ID0) { iobase = pci_conf_read(config_id, FET_PCI_LOIO); if (iobase & 0x300) FET_USEIOSPACE=0; } if (FET_USEIOSPACE) { if (!(command & PCIM_CMD_PORTEN)) { printf("fet%d: failed to enable I/O ports!\n", unit); free(sc, M_DEVBUF); goto fail; } if (!pci_map_port(config_id, FET_PCI_LOIO, (u_int16_t *)&(sc->fet_bhandle))) { printf ("fet%d: couldn't map ports\n", unit); goto fail; } sc->fet_btag = I386_BUS_SPACE_IO; } else { if (!(command & PCIM_CMD_MEMEN)) { printf("fet%d: failed to enable memory mapping!\n", unit); goto fail; } if (!pci_map_mem(config_id, FET_PCI_LOMEM, &vbase, &pbase)) { printf ("fet%d: couldn't map memory\n", unit); goto fail; } /* sc->csr = (volatile caddr_t)vbase; */ sc->fet_btag = I386_BUS_SPACE_MEM; sc->fet_bhandle = vbase; } /* Allocate interrupt */ if (!pci_map_int(config_id, fet_intr, sc, &net_imask)) { printf("fet%d: couldn't map interrupt\n", unit); goto fail; } sc->fet_info = fet_info_tmp; /* Reset the adapter. */ fet_reset(sc); /* * Get station address */ for (i = 0; i < ETHER_ADDR_LEN; ++i) eaddr[i] = CSR_READ_1(sc, FET_PAR0+i); /* * A Myson chip was detected. Inform the world. */ printf("fet%d: Ethernet address: %6D\n", unit, eaddr, ":"); sc->fet_unit = unit; bcopy(eaddr, (char *)&sc->arpcom.ac_enaddr, ETHER_ADDR_LEN); sc->fet_ldata_ptr = malloc(sizeof(struct fet_list_data) + 8, M_DEVBUF, M_NOWAIT); if (sc->fet_ldata_ptr == NULL) { free(sc, M_DEVBUF); printf("fet%d: no memory for list buffers!\n", unit); return; } sc->fet_ldata = (struct fet_list_data *)sc->fet_ldata_ptr; round = (unsigned int)sc->fet_ldata_ptr & 0xF; roundptr = sc->fet_ldata_ptr; for (i = 0; i < 8; i++) { if (round % 8) { round++; roundptr++; } else break; } sc->fet_ldata = (struct fet_list_data *)roundptr; bzero(sc->fet_ldata, sizeof(struct fet_list_data)); ifp = &sc->arpcom.ac_if; ifp->if_softc = sc; ifp->if_unit = unit; ifp->if_name = "fet"; ifp->if_mtu = ETHERMTU; ifp->if_flags = IFF_BROADCAST | IFF_SIMPLEX | IFF_MULTICAST; ifp->if_ioctl = fet_ioctl; ifp->if_output = ether_output; ifp->if_start = fet_start; ifp->if_watchdog = fet_watchdog; ifp->if_init = fet_init; ifp->if_baudrate = 10000000; if (sc->fet_info->fet_did == ID1) sc->fet_pinfo = fet_phys; else { if (bootverbose) printf("fet%d: probing for a PHY\n", sc->fet_unit); for (i = FET_PHYADDR_MIN; i < FET_PHYADDR_MAX + 1; i++) { if (bootverbose) printf("fet%d: checking address: %d\n", sc->fet_unit, i); sc->fet_phy_addr = i; phy_sts = fet_phy_readreg(sc, PHY_BMSR); if ( (phy_sts!=0)&&(phy_sts!=0xffff) ) break; else phy_sts = 0; } if (phy_sts) { phy_vid = fet_phy_readreg(sc, PHY_VENID); phy_did = fet_phy_readreg(sc, PHY_DEVID); if (bootverbose) { printf("fet%d: found PHY at address %d, ", sc->fet_unit, sc->fet_phy_addr); printf("vendor id: %x device id: %x\n", phy_vid, phy_did); } p = fet_phys; while(p->fet_vid) { if (phy_vid == p->fet_vid) { sc->fet_pinfo = p; break; } p++; } if (sc->fet_pinfo == NULL) sc->fet_pinfo = &fet_phys[PHY_UNKNOWN]; if (bootverbose) printf("fet%d: PHY type: %s\n", sc->fet_unit, sc->fet_pinfo->fet_name); } else { printf("fet%d: MII without any phy!\n", sc->fet_unit); goto fail; } } /* * Do ifmedia setup. */ ifmedia_init(&sc->ifmedia, 0, fet_ifmedia_upd, fet_ifmedia_sts); fet_getmode_mii(sc); fet_autoneg_mii(sc, FET_FLAG_FORCEDELAY, 1); media = sc->ifmedia.ifm_media; fet_stop(sc); ifmedia_set(&sc->ifmedia, media); /* * Call MI attach routines. */ if_attach(ifp); ether_ifattach(ifp); #if NBPFILTER > 0 bpfattach(ifp, DLT_EN10MB, sizeof(struct ether_header)); #endif at_shutdown(fet_shutdown, sc, SHUTDOWN_POST_SYNC); fail: splx(s); return; } /* * Initialize the transmit descriptors. */ static int fet_list_tx_init(sc) struct fet_softc *sc; { struct fet_chain_data *cd; struct fet_list_data *ld; int i; cd = &sc->fet_cdata; ld = sc->fet_ldata; for (i = 0; i < FET_TX_LIST_CNT; i++) { cd->fet_tx_chain[i].fet_ptr = &ld->fet_tx_list[i]; if (i == (FET_TX_LIST_CNT - 1)) cd->fet_tx_chain[i].fet_nextdesc = &cd->fet_tx_chain[0]; else cd->fet_tx_chain[i].fet_nextdesc = &cd->fet_tx_chain[i + 1]; } cd->fet_tx_free = &cd->fet_tx_chain[0]; cd->fet_tx_tail = cd->fet_tx_head = NULL; return(0); } /* * Initialize the RX descriptors and allocate mbufs for them. Note that * we arrange the descriptors in a closed ring, so that the last descriptor * points back to the first. */ static int fet_list_rx_init(sc) struct fet_softc *sc; { struct fet_chain_data *cd; struct fet_list_data *ld; int i; cd = &sc->fet_cdata; ld = sc->fet_ldata; for (i = 0; i < FET_RX_LIST_CNT; i++) { cd->fet_rx_chain[i].fet_ptr = (struct fet_desc *)&ld->fet_rx_list[i]; if (fet_newbuf(sc, &cd->fet_rx_chain[i]) == ENOBUFS) return(ENOBUFS); if (i == (FET_RX_LIST_CNT - 1)) { cd->fet_rx_chain[i].fet_nextdesc = &cd->fet_rx_chain[0]; ld->fet_rx_list[i].fet_next = vtophys(&ld->fet_rx_list[0]); } else { cd->fet_rx_chain[i].fet_nextdesc = &cd->fet_rx_chain[i + 1]; ld->fet_rx_list[i].fet_next = vtophys(&ld->fet_rx_list[i + 1]); } } cd->fet_rx_head = &cd->fet_rx_chain[0]; return(0); } /* * Initialize an RX descriptor and attach an MBUF cluster. */ static int fet_newbuf(sc, c) struct fet_softc *sc; struct fet_chain_onefrag *c; { struct mbuf *m_new = NULL; MGETHDR(m_new, M_DONTWAIT, MT_DATA); if (m_new == NULL) { printf("fet%d: no memory for rx list -- packet dropped!\n", sc->fet_unit); return(ENOBUFS); } MCLGET(m_new, M_DONTWAIT); if (!(m_new->m_flags & M_EXT)) { printf("fet%d: no memory for rx list -- packet dropped!\n", sc->fet_unit); m_freem(m_new); return(ENOBUFS); } c->fet_mbuf = m_new; c->fet_ptr->fet_data = vtophys(mtod(m_new, caddr_t)); c->fet_ptr->fet_ctl = (MCLBYTES - 1)<fet_ptr->fet_status = FET_OWNByNIC; return(0); } /* * A frame has been uploaded: pass the resulting mbuf chain up to * the higher level protocols. */ static void fet_rxeof(sc) struct fet_softc *sc; { struct ether_header *eh; struct mbuf *m; struct ifnet *ifp; struct fet_chain_onefrag *cur_rx; int total_len = 0; u_int32_t rxstat; ifp = &sc->arpcom.ac_if; while (!((rxstat = sc->fet_cdata.fet_rx_head->fet_ptr->fet_status)&FET_OWNByNIC)) { cur_rx = sc->fet_cdata.fet_rx_head; sc->fet_cdata.fet_rx_head = cur_rx->fet_nextdesc; if (rxstat & FET_ES) /* error summary */ { /* give up this rx pkt */ ifp->if_ierrors++; cur_rx->fet_ptr->fet_status = FET_OWNByNIC; continue; } /* No errors; receive the packet. */ total_len = (rxstat & FET_FLNGMASK) >> FET_FLNGShift; total_len -= ETHER_CRC_LEN; if (total_len < MINCLSIZE) { m = m_devget(mtod(cur_rx->fet_mbuf, char *), total_len, 0, ifp, NULL); cur_rx->fet_ptr->fet_status = FET_OWNByNIC; if (m == NULL) { ifp->if_ierrors++; continue; } } else { m = cur_rx->fet_mbuf; /* * Try to conjure up a new mbuf cluster. If that * fails, it means we have an out of memory condition and * should leave the buffer in place and continue. This will * result in a lost packet, but there's little else we * can do in this situation. */ if (fet_newbuf(sc, cur_rx) == ENOBUFS) { ifp->if_ierrors++; cur_rx->fet_ptr->fet_status = FET_OWNByNIC; continue; } m->m_pkthdr.rcvif = ifp; m->m_pkthdr.len = m->m_len = total_len; } ifp->if_ipackets++; eh = mtod(m, struct ether_header *); #if NBPFILTER > 0 /* * Handle BPF listeners. Let the BPF user see the packet, but * don't pass it up to the ether_input() layer unless it's * a broadcast packet, multicast packet, matches our ethernet * address or the interface is in promiscuous mode. */ if (ifp->if_bpf) { bpf_mtap(ifp, m); if (ifp->if_flags & IFF_PROMISC && (bcmp(eh->ether_dhost, sc->arpcom.ac_enaddr, ETHER_ADDR_LEN) && (eh->ether_dhost[0] & 1) == 0)) { m_freem(m); continue; } } #endif /* Remove header from mbuf and pass it on. */ m_adj(m, sizeof(struct ether_header)); ether_input(ifp, eh, m); } return; } /* * A frame was downloaded to the chip. It's safe for us to clean up * the list buffers. */ static void fet_txeof(sc) struct fet_softc *sc; { struct fet_chain *cur_tx; struct ifnet *ifp; ifp = &sc->arpcom.ac_if; /* Clear the timeout timer. */ ifp->if_timer = 0; if (sc->fet_cdata.fet_tx_head == NULL) return; /* * Go through our tx list and free mbufs for those * frames that have been transmitted. */ while (sc->fet_cdata.fet_tx_head->fet_mbuf != NULL) { u_int32_t txstat; cur_tx = sc->fet_cdata.fet_tx_head; txstat = FET_TXSTATUS(cur_tx); if ((txstat & FET_OWNByNIC) || txstat == FET_UNSENT) break; if (!(CSR_READ_4(sc, FET_TCRRCR)&FET_Enhanced)) { if (txstat & FET_TXERR) { ifp->if_oerrors++; if (txstat & FET_EC) /* excessive collision */ ifp->if_collisions++; if (txstat & FET_LC) /* late collision */ ifp->if_collisions++; } ifp->if_collisions += (txstat & FET_NCRMASK) >> FET_NCRShift; } ifp->if_opackets++; m_freem(cur_tx->fet_mbuf); cur_tx->fet_mbuf = NULL; if (sc->fet_cdata.fet_tx_head == sc->fet_cdata.fet_tx_tail) { sc->fet_cdata.fet_tx_head = NULL; sc->fet_cdata.fet_tx_tail = NULL; break; } sc->fet_cdata.fet_tx_head = cur_tx->fet_nextdesc; } if (CSR_READ_4(sc, FET_TCRRCR)&FET_Enhanced) { ifp->if_collisions += (CSR_READ_4(sc, FET_TSR)&FET_NCRMask); } return; } /* * TX 'end of channel' interrupt handler. */ static void fet_txeoc(sc) struct fet_softc *sc; { struct ifnet *ifp; ifp = &sc->arpcom.ac_if; ifp->if_timer = 0; if (sc->fet_cdata.fet_tx_head == NULL) { ifp->if_flags &= ~IFF_OACTIVE; sc->fet_cdata.fet_tx_tail = NULL; if (sc->fet_want_auto) fet_autoneg_mii(sc, FET_FLAG_SCHEDDELAY, 1); } else { if (FET_TXOWN(sc->fet_cdata.fet_tx_head) == FET_UNSENT) { FET_TXOWN(sc->fet_cdata.fet_tx_head) = FET_OWNByNIC; ifp->if_timer = 5; CSR_WRITE_4(sc, FET_TXPDR, 0xFFFFFFFF); } } return; } static void fet_intr(arg) void *arg; { struct fet_softc *sc; struct ifnet *ifp; u_int32_t status; sc = arg; ifp = &sc->arpcom.ac_if; if (!(ifp->if_flags & IFF_UP)) return; /* Disable interrupts. */ CSR_WRITE_4(sc, FET_IMR, 0x00000000); for (;;) { status = CSR_READ_4(sc, FET_ISR); status &= FET_INTRS; if (status) CSR_WRITE_4(sc, FET_ISR, status); else break; if (status & FET_RI) /* receive interrupt */ fet_rxeof(sc); if ((status & FET_RBU) || (status & FET_RxErr)) { /* rx buffer unavailable or rx error */ ifp->if_ierrors++; #ifdef foo fet_stop(sc); fet_reset(sc); fet_init(sc); #endif } if (status & FET_TI) /* tx interrupt */ fet_txeof(sc); if (status & FET_ETI) /* tx early interrupt */ fet_txeof(sc); if (status & FET_TBU) /* tx buffer unavailable */ fet_txeoc(sc); /* 90/1/18 delete if (status & FET_FBE) { fet_reset(sc); fet_init(sc); } */ } /* Re-enable interrupts. */ CSR_WRITE_4(sc, FET_IMR, FET_INTRS); if (ifp->if_snd.ifq_head != NULL) fet_start(ifp); return; } /* * Encapsulate an mbuf chain in a descriptor by coupling the mbuf data * pointers to the fragment pointers. */ static int fet_encap(sc, c, m_head) struct fet_softc *sc; struct fet_chain *c; struct mbuf *m_head; { struct fet_desc *f = NULL; int total_len; struct mbuf *m, *m_new=NULL; /* calculate the total tx pkt length */ total_len = 0; for (m = m_head; m != NULL; m = m->m_next) total_len += m->m_len; /* * Start packing the mbufs in this chain into * the fragment pointers. Stop when we run out * of fragments or hit the end of the mbuf chain. */ m = m_head; MGETHDR(m_new, M_DONTWAIT, MT_DATA); if (m_new == NULL) { printf("fet%d: no memory for tx list", sc->fet_unit); return(1); } if (m_head->m_pkthdr.len > MHLEN) { MCLGET(m_new, M_DONTWAIT); if (!(m_new->m_flags & M_EXT)) { m_freem(m_new); printf("fet%d: no memory for tx list", sc->fet_unit); return(1); } } m_copydata(m_head, 0, m_head->m_pkthdr.len, mtod(m_new, caddr_t)); m_new->m_pkthdr.len = m_new->m_len = m_head->m_pkthdr.len; m_freem(m_head); m_head = m_new; f = &c->fet_ptr->fet_frag[0]; f->fet_status = 0; f->fet_data = vtophys(mtod(m_new, caddr_t)); total_len = m_new->m_len; f->fet_ctl = FET_TXFD|FET_TXLD|FET_CRCEnable|FET_PADEnable; f->fet_ctl |= total_len<fet_ctl |= total_len; /* buffer size */ /* 89/12/29 add, for mtd891 */ if (sc->fet_info->fet_did==ID2) f->fet_ctl |= FET_ETIControl|FET_RetryTxLC; c->fet_mbuf = m_head; c->fet_lastdesc = 0; FET_TXNEXT(c) = vtophys(&c->fet_nextdesc->fet_ptr->fet_frag[0]); return(0); } /* * Main transmit routine. To avoid having to do mbuf copies, we put pointers * to the mbuf data regions directly in the transmit lists. We also save a * copy of the pointers since the transmit list fragment pointers are * physical addresses. */ static void fet_start(ifp) struct ifnet *ifp; { struct fet_softc *sc; struct mbuf *m_head = NULL; struct fet_chain *cur_tx = NULL, *start_tx; sc = ifp->if_softc; if (sc->fet_autoneg) { sc->fet_tx_pend = 1; return; } /* * Check for an available queue slot. If there are none, * punt. */ if (sc->fet_cdata.fet_tx_free->fet_mbuf != NULL) { ifp->if_flags |= IFF_OACTIVE; return; } start_tx = sc->fet_cdata.fet_tx_free; while (sc->fet_cdata.fet_tx_free->fet_mbuf == NULL) { IF_DEQUEUE(&ifp->if_snd, m_head); if (m_head == NULL) break; /* Pick a descriptor off the free list. */ cur_tx = sc->fet_cdata.fet_tx_free; sc->fet_cdata.fet_tx_free = cur_tx->fet_nextdesc; /* Pack the data into the descriptor. */ fet_encap(sc, cur_tx, m_head); if (cur_tx != start_tx) FET_TXOWN(cur_tx) = FET_OWNByNIC; #if NBPFILTER > 0 /* * If there's a BPF listener, bounce a copy of this frame * to him. */ if (ifp->if_bpf) bpf_mtap(ifp, cur_tx->fet_mbuf); #endif } /* * If there are no packets queued, bail. */ if (cur_tx == NULL) return; /* * Place the request for the upload interrupt * in the last descriptor in the chain. This way, if * we're chaining several packets at once, we'll only * get an interupt once for the whole chain rather than * once for each packet. */ FET_TXCTL(cur_tx) |= FET_TXIC; cur_tx->fet_ptr->fet_frag[0].fet_ctl |= FET_TXIC; sc->fet_cdata.fet_tx_tail = cur_tx; if (sc->fet_cdata.fet_tx_head == NULL) sc->fet_cdata.fet_tx_head = start_tx; FET_TXOWN(start_tx) = FET_OWNByNIC; CSR_WRITE_4(sc, FET_TXPDR, 0xFFFFFFFF); /* tx polling demand */ /* * Set a timeout in case the chip goes out to lunch. */ ifp->if_timer = 5; return; } static void fet_init(xsc) void *xsc; { struct fet_softc *sc = xsc; struct ifnet *ifp = &sc->arpcom.ac_if; int s, i; u_int16_t phy_bmcr = 0; if (sc->fet_autoneg) return; s = splimp(); if (sc->fet_pinfo != NULL) phy_bmcr = fet_phy_readreg(sc, PHY_BMCR); /* * Cancel pending I/O and free all RX/TX buffers. */ fet_stop(sc); fet_reset(sc); /* * Set cache alignment and burst length. */ /* 89/9/1 modify, CSR_WRITE_4(sc, FET_BCR, FET_RPBLE512); CSR_WRITE_4(sc, FET_TCRRCR, FET_TFTSF); */ CSR_WRITE_4(sc, FET_BCR, FET_PBL8); CSR_WRITE_4(sc, FET_TCRRCR, FET_TFTSF|FET_RBLEN|FET_RPBLE512); /* 89/12/29 add, for mtd891, */ if (sc->fet_info->fet_did==ID2) { FET_SETBIT(sc, FET_BCR, FET_PROG); FET_SETBIT(sc, FET_TCRRCR, FET_Enhanced); } fet_setcfg(sc, phy_bmcr); /* Init circular RX list. */ if (fet_list_rx_init(sc) == ENOBUFS) { printf("fet%d: initialization failed: no memory for rx buffers\n", sc->fet_unit); fet_stop(sc); (void)splx(s); return; } /* Init TX descriptors. */ fet_list_tx_init(sc); /* If we want promiscuous mode, set the allframes bit. */ if (ifp->if_flags & IFF_PROMISC) FET_SETBIT(sc, FET_TCRRCR, FET_PROM); else FET_CLRBIT(sc, FET_TCRRCR, FET_PROM); /* * Set capture broadcast bit to capture broadcast frames. */ if (ifp->if_flags & IFF_BROADCAST) FET_SETBIT(sc, FET_TCRRCR, FET_AB); else FET_CLRBIT(sc, FET_TCRRCR, FET_AB); /* * Program the multicast filter, if necessary. */ fet_setmulti(sc); /* * Load the address of the RX list. */ FET_CLRBIT(sc, FET_TCRRCR, FET_RE); CSR_WRITE_4(sc, FET_RXLBA, vtophys(&sc->fet_ldata->fet_rx_list[0])); /* * Enable interrupts. */ CSR_WRITE_4(sc, FET_IMR, FET_INTRS); CSR_WRITE_4(sc, FET_ISR, 0xFFFFFFFF); /* Enable receiver and transmitter. */ FET_SETBIT(sc, FET_TCRRCR, FET_RE); FET_CLRBIT(sc, FET_TCRRCR, FET_TE); CSR_WRITE_4(sc, FET_TXLBA, vtophys(&sc->fet_ldata->fet_tx_list[0])); FET_SETBIT(sc, FET_TCRRCR, FET_TE); /* Restore state of BMCR */ if (sc->fet_pinfo != NULL) fet_phy_writereg(sc, PHY_BMCR, phy_bmcr); ifp->if_flags |= IFF_RUNNING; ifp->if_flags &= ~IFF_OACTIVE; (void)splx(s); return; } /* * Set media options. */ static int fet_ifmedia_upd(ifp) struct ifnet *ifp; { struct fet_softc *sc; struct ifmedia *ifm; sc = ifp->if_softc; ifm = &sc->ifmedia; if (IFM_TYPE(ifm->ifm_media) != IFM_ETHER) return(EINVAL); if (IFM_SUBTYPE(ifm->ifm_media) == IFM_AUTO) fet_autoneg_mii(sc, FET_FLAG_SCHEDDELAY, 1); else fet_setmode_mii(sc, ifm->ifm_media); return(0); } /* * Report current media status. */ static void fet_ifmedia_sts(ifp, ifmr) struct ifnet *ifp; struct ifmediareq *ifmr; { struct fet_softc *sc; u_int16_t advert = 0, ability = 0, ability2 = 0; sc = ifp->if_softc; ifmr->ifm_active = IFM_ETHER; if (!(fet_phy_readreg(sc, PHY_BMCR) & PHY_BMCR_AUTONEGENBL)) { /* this version did not support 1000M, if (fet_phy_readreg(sc, PHY_BMCR) & PHY_BMCR_1000) ifmr->ifm_active = IFM_ETHER|IFM_1000TX; */ if (fet_phy_readreg(sc, PHY_BMCR) & PHY_BMCR_SPEEDSEL) ifmr->ifm_active = IFM_ETHER|IFM_100_TX; else ifmr->ifm_active = IFM_ETHER|IFM_10_T; if (fet_phy_readreg(sc, PHY_BMCR) & PHY_BMCR_DUPLEX) ifmr->ifm_active |= IFM_FDX; else ifmr->ifm_active |= IFM_HDX; return; } ability = fet_phy_readreg(sc, PHY_LPAR); advert = fet_phy_readreg(sc, PHY_ANAR); /* this version did not support 1000M, if (sc->fet_pinfo->fet_vid = MarvellPHYID0) { ability2 = fet_phy_readreg(sc, PHY_1000SR); if (ability2 & PHY_1000SR_1000BTXFULL) { advert = 0; ability = 0; ifmr->ifm_active = IFM_ETHER|IFM_1000_TX|IFM_FDX; } else if (ability & PHY_1000SR_1000BTXHALF) { advert = 0; ability = 0; ifmr->ifm_active = IFM_ETHER|IFM_1000_TX|IFM_HDX; } } */ if (advert & PHY_ANAR_100BT4 && ability & PHY_ANAR_100BT4) ifmr->ifm_active = IFM_ETHER|IFM_100_T4; else if (advert & PHY_ANAR_100BTXFULL && ability & PHY_ANAR_100BTXFULL) ifmr->ifm_active = IFM_ETHER|IFM_100_TX|IFM_FDX; else if (advert & PHY_ANAR_100BTXHALF && ability & PHY_ANAR_100BTXHALF) ifmr->ifm_active = IFM_ETHER|IFM_100_TX|IFM_HDX; else if (advert & PHY_ANAR_10BTFULL && ability & PHY_ANAR_10BTFULL) ifmr->ifm_active = IFM_ETHER|IFM_10_T|IFM_FDX; else if (advert & PHY_ANAR_10BTHALF && ability & PHY_ANAR_10BTHALF) ifmr->ifm_active = IFM_ETHER|IFM_10_T|IFM_HDX; return; } static int fet_ioctl(ifp, command, data) struct ifnet *ifp; u_long command; caddr_t data; { struct fet_softc *sc = ifp->if_softc; struct ifreq *ifr = (struct ifreq *)data; int s, error = 0; s = splimp(); switch(command) { case SIOCSIFADDR: case SIOCGIFADDR: case SIOCSIFMTU: error = ether_ioctl(ifp, command, data); break; case SIOCSIFFLAGS: if (ifp->if_flags & IFF_UP) fet_init(sc); else if (ifp->if_flags & IFF_RUNNING) fet_stop(sc); error = 0; break; case SIOCADDMULTI: case SIOCDELMULTI: fet_setmulti(sc); error = 0; break; case SIOCGIFMEDIA: case SIOCSIFMEDIA: error = ifmedia_ioctl(ifp, ifr, &sc->ifmedia, command); break; default: error = EINVAL; break; } (void)splx(s); return(error); } static void fet_watchdog(ifp) struct ifnet *ifp; { struct fet_softc *sc; sc = ifp->if_softc; if (sc->fet_autoneg) { fet_autoneg_mii(sc, FET_FLAG_DELAYTIMEO, 1); return; } ifp->if_oerrors++; printf("fet%d: watchdog timeout\n", sc->fet_unit); if (!(fet_phy_readreg(sc, PHY_BMSR) & PHY_BMSR_LINKSTAT)) printf("fet%d: no carrier - transceiver cable problem?\n", sc->fet_unit); fet_stop(sc); fet_reset(sc); fet_init(sc); if (ifp->if_snd.ifq_head != NULL) fet_start(ifp); return; } /* * Stop the adapter and free any mbufs allocated to the * RX and TX lists. */ static void fet_stop(sc) struct fet_softc *sc; { register int i; struct ifnet *ifp; ifp = &sc->arpcom.ac_if; ifp->if_timer = 0; FET_CLRBIT(sc, FET_TCRRCR, (FET_RE|FET_TE)); CSR_WRITE_4(sc, FET_IMR, 0x00000000); CSR_WRITE_4(sc, FET_TXLBA, 0x00000000); CSR_WRITE_4(sc, FET_RXLBA, 0x00000000); /* * Free data in the RX lists. */ for (i = 0; i < FET_RX_LIST_CNT; i++) { if (sc->fet_cdata.fet_rx_chain[i].fet_mbuf != NULL) { m_freem(sc->fet_cdata.fet_rx_chain[i].fet_mbuf); sc->fet_cdata.fet_rx_chain[i].fet_mbuf = NULL; } } bzero((char *)&sc->fet_ldata->fet_rx_list, sizeof(sc->fet_ldata->fet_rx_list)); /* * Free the TX list buffers. */ for (i = 0; i < FET_TX_LIST_CNT; i++) { if (sc->fet_cdata.fet_tx_chain[i].fet_mbuf != NULL) { m_freem(sc->fet_cdata.fet_tx_chain[i].fet_mbuf); sc->fet_cdata.fet_tx_chain[i].fet_mbuf = NULL; } } bzero((char *)&sc->fet_ldata->fet_tx_list, sizeof(sc->fet_ldata->fet_tx_list)); ifp->if_flags &= ~(IFF_RUNNING | IFF_OACTIVE); return; } /* * Stop all chip I/O so that the kernel's probe routines don't * get confused by errant DMAs when rebooting. */ static void fet_shutdown(howto, arg) int howto; void *arg; { struct fet_softc *sc = (struct fet_softc *)arg; fet_stop(sc); return; } static struct pci_device fet_device = { "fet", fet_probe, fet_attach, &fet_count, NULL }; DATA_SET(pcidevice_set, fet_device); -------------------------------------------------------------- if_fetreg.h -------------------------------------------------------------- /* * register definitions. */ #define FET_PAR0 0x0 /* physical address 0-3 */ #define FET_PAR1 0x04 /* physical address 4-5 */ #define FET_MAR0 0x08 /* multicast address 0-3 */ #define FET_MAR1 0x0C /* multicast address 4-7 */ #define FET_FAR0 0x10 /* flow-control address 0-3 */ #define FET_FAR1 0x14 /* flow-control address 4-5 */ #define FET_TCRRCR 0x18 /* receive & transmit configuration */ #define FET_BCR 0x1C /* bus command */ #define FET_TXPDR 0x20 /* transmit polling demand */ #define FET_RXPDR 0x24 /* receive polling demand */ #define FET_RXCWP 0x28 /* receive current word pointer */ #define FET_TXLBA 0x2C /* transmit list base address */ #define FET_RXLBA 0x30 /* receive list base address */ #define FET_ISR 0x34 /* interrupt status */ #define FET_IMR 0x38 /* interrupt mask */ #define FET_FTH 0x3C /* flow control high/low threshold */ #define FET_MANAGEMENT 0x40 /* bootrom/eeprom and mii management */ #define FET_TALLY 0x44 /* tally counters for crc and mpa */ #define FET_TSR 0x48 /* tally counter for transmit status */ #define FET_PHYBASE 0x4c /* * Receive Configuration Register */ #define FET_RXRUN 0x00008000 /* receive running status */ #define FET_EIEN 0x00004000 /* early interrupt enable */ #define FET_RFCEN 0x00002000 /* receive flow control packet enable */ #define FET_NDFA 0x00001000 /* not defined flow control address */ #define FET_RBLEN 0x00000800 /* receive burst length enable */ #define FET_RPBLE1 0x00000000 /* 1 word */ #define FET_RPBLE4 0x00000100 /* 4 words */ #define FET_RPBLE8 0x00000200 /* 8 words */ #define FET_RPBLE16 0x00000300 /* 16 words */ #define FET_RPBLE32 0x00000400 /* 32 words */ #define FET_RPBLE64 0x00000500 /* 64 words */ #define FET_RPBLE128 0x00000600 /* 128 words */ #define FET_RPBLE512 0x00000700 /* 512 words */ #define FET_PROM 0x000000080 /* promiscuous mode */ #define FET_AB 0x000000040 /* accept broadcast */ #define FET_AM 0x000000020 /* accept mutlicast */ #define FET_ARP 0x000000008 /* receive runt pkt */ #define FET_ALP 0x000000004 /* receive long pkt */ #define FET_SEP 0x000000002 /* receive error pkt */ #define FET_RE 0x000000001 /* receive enable */ /* * Transmit Configuration Register */ #define FET_TXRUN 0x04000000 /* transmit running status */ #define FET_Enhanced 0x02000000 /* transmit enhanced mode */ #define FET_TFCEN 0x01000000 /* tx flow control packet enable */ #define FET_TFT64 0x00000000 /* 64 bytes */ #define FET_TFT32 0x00200000 /* 32 bytes */ #define FET_TFT128 0x00400000 /* 128 bytes */ #define FET_TFT256 0x00600000 /* 256 bytes */ #define FET_TFT512 0x00800000 /* 512 bytes */ #define FET_TFT768 0x00A00000 /* 768 bytes */ #define FET_TFT1024 0x00C00000 /* 1024 bytes */ #define FET_TFTSF 0x00E00000 /* store and forward */ #define FET_FD 0x00100000 /* full duplex mode */ #define FET_PS10 0x00080000 /* port speed is 10M */ #define FET_TE 0x00040000 /* transmit enable */ #define FET_PS1000 0x00010000 /* port speed is 1000M */ /* * Bus Command Register */ #define FET_PROG 0x00000200 /* programming */ #define FET_RLE 0x00000100 /* read line command enable */ #define FET_RME 0x00000080 /* read multiple command enable */ #define FET_WIE 0x00000040 /* write and invalidate cmd enable */ #define FET_PBL1 0x00000000 /* 1 dword */ #define FET_PBL4 0x00000008 /* 4 dwords */ #define FET_PBL8 0x00000010 /* 8 dwords */ #define FET_PBL16 0x00000018 /* 16 dwords */ #define FET_PBL32 0x00000020 /* 32 dwords */ #define FET_PBL64 0x00000028 /* 64 dwords */ #define FET_PBL128 0x00000030 /* 128 dwords */ #define FET_PBL512 0x00000038 /* 512 dwords */ #define FET_ABR 0x00000004 /* arbitration rule */ #define FET_BLS 0x00000002 /* big/little endian select */ #define FET_SWR 0x00000001 /* software reset */ /* * Transmit Poll Demand Register */ #define FET_TxPollDemand 0x1 /* * Receive Poll Demand Register */ #define FET_RxPollDemand 0x01 /* * Interrupt Status Register */ #define FET_RFCON 0x00020000 /* receive flow control xon packet */ #define FET_RFCOFF 0x00010000 /* receive flow control xoff packet */ #define FET_LSCStatus 0x00008000 /* link status change */ #define FET_ANCStatus 0x00004000 /* autonegotiation completed */ #define FET_FBE 0x00002000 /* fatal bus error */ #define FET_FBEMask 0x00001800 #define FET_ParityErr 0x00000000 /* parity error */ #define FET_MasterErr 0x00000800 /* master error */ #define FET_TargetErr 0x00001000 /* target abort */ #define FET_TUNF 0x00000400 /* transmit underflow */ #define FET_ROVF 0x00000200 /* receive overflow */ #define FET_ETI 0x00000100 /* transmit early int */ #define FET_ERI 0x00000080 /* receive early int */ #define FET_CNTOVF 0x00000040 /* counter overflow */ #define FET_RBU 0x00000020 /* receive buffer unavailable */ #define FET_TBU 0x00000010 /* transmit buffer unavilable */ #define FET_TI 0x00000008 /* transmit interrupt */ #define FET_RI 0x00000004 /* receive interrupt */ #define FET_RxErr 0x00000002 /* receive error */ /* * Interrupt Mask Register */ #define FET_MRFCON 0x00020000 /* receive flow control xon packet */ #define FET_MRFCOFF 0x00010000 /* receive flow control xoff packet */ #define FET_MLSCStatus 0x00008000 /* link status change */ #define FET_MANCStatus 0x00004000 /* autonegotiation completed */ #define FET_MFBE 0x00002000 /* fatal bus error */ #define FET_MFBEMask 0x00001800 #define FET_MTUNF 0x00000400 /* transmit underflow */ #define FET_MROVF 0x00000200 /* receive overflow */ #define FET_METI 0x00000100 /* transmit early int */ #define FET_MERI 0x00000080 /* receive early int */ #define FET_MCNTOVF 0x00000040 /* counter overflow */ #define FET_MRBU 0x00000020 /* receive buffer unavailable */ #define FET_MTBU 0x00000010 /* transmit buffer unavilable */ #define FET_MTI 0x00000008 /* transmit interrupt */ #define FET_MRI 0x00000004 /* receive interrupt */ #define FET_MRxErr 0x00000002 /* receive error */ /* 90/1/18 delete */ /* #define FET_INTRS FET_FBE|FET_MRBU|FET_TBU|FET_MTI|FET_MRI|FET_METI */ #define FET_INTRS FET_MRBU|FET_TBU|FET_MTI|FET_MRI|FET_METI /* * Flow Control High/Low Threshold Register */ #define FET_FCHTShift 16 /* flow control high threshold */ #define FET_FCLTShift 0 /* flow control low threshold */ /* * BootROM/EEPROM/MII Management Register */ #define FET_MASK_MIIR_MII_READ 0x00000000 #define FET_MASK_MIIR_MII_WRITE 0x00000008 #define FET_MASK_MIIR_MII_MDO 0x00000004 #define FET_MASK_MIIR_MII_MDI 0x00000002 #define FET_MASK_MIIR_MII_MDC 0x00000001 /* * Tally Counter for CRC and MPA */ #define FET_TCOVF 0x80000000 /* crc tally counter overflow */ #define FET_CRCMask 0x7fff0000 /* crc number: bit 16-30 */ #define FET_CRCShift 16 #define FET_TMOVF 0x00008000 /* mpa tally counter overflow */ #define FET_MPAMask 0x00007fff /* mpa number: bit 0-14 */ #define FET_MPAShift 0 /* * Tally Counters for transmit status */ #define FET_AbortMask 0xff000000 /* transmit abort number */ #define FET_AbortShift 24 #define FET_LColMask 0x00ff0000 /* transmit late collisions */ #define FET_LColShift 16 #define FET_NCRMask 0x0000ffff /* transmit retry number */ #define FET_NCRShift 0 /* * Myson TX/RX descriptor structure. */ struct fet_desc { u_int32_t fet_status; u_int32_t fet_ctl; u_int32_t fet_data; u_int32_t fet_next; }; /* * for tx/rx descriptors */ #define FET_OWNByNIC 0x80000000 #define FET_OWNByDriver 0x0 /* * receive descriptor 0 */ #define FET_RXOWN 0x80000000 /* own bit */ #define FET_FLNGMASK 0x0fff0000 /* frame length */ #define FET_FLNGShift 16 #define FET_MARSTATUS 0x00004000 /* multicast address received */ #define FET_BARSTATUS 0x00002000 /* broadcast address received */ #define FET_PHYSTATUS 0x00001000 /* physical address received */ #define FET_RXFSD 0x00000800 /* first descriptor */ #define FET_RXLSD 0x00000400 /* last descriptor */ #define FET_ES 0x00000080 /* error summary */ #define FET_RUNT 0x00000040 /* runt packet received */ #define FET_LONG 0x00000020 /* long packet received */ #define FET_FAE 0x00000010 /* frame align error */ #define FET_CRC 0x00000008 /* crc error */ #define FET_RXER 0x00000004 /* receive error */ #define FET_RDES0CHECK 0x000078fc /* only check MAR, BAR, PHY, ES, RUNT, LONG, FAE, CRC and RXER bits */ /* * receive descriptor 1 */ #define FET_RXIC 0x00800000 /* interrupt control */ #define FET_RBSMASK 0x000007ff /* receive buffer size */ #define FET_RBSShift 0 /* * transmit descriptor 0 */ #define FET_TXERR 0x00008000 /* transmit error */ #define FET_JABTO 0x00004000 /* jabber timeout */ #define FET_CSL 0x00002000 /* carrier sense lost */ #define FET_LC 0x00001000 /* late collision */ #define FET_EC 0x00000800 /* excessive collision */ #define FET_UDF 0x00000400 /* fifo underflow */ #define FET_DFR 0x00000200 /* deferred */ #define FET_HF 0x00000100 /* heartbeat fail */ #define FET_NCRMASK 0x000000ff /* collision retry count */ #define FET_NCRShift 0 /* * tx descriptor 1 */ #define FET_TXIC 0x80000000 /* interrupt control */ #define FET_ETIControl 0x40000000 /* early transmit interrupt */ #define FET_TXLD 0x20000000 /* last descriptor */ #define FET_TXFD 0x10000000 /* first descriptor */ #define FET_CRCDisable 0x00000000 /* crc control */ #define FET_CRCEnable 0x08000000 #define FET_PADDisable 0x00000000 /* padding control */ #define FET_PADEnable 0x04000000 #define FET_RetryTxLC 0x02000000 /* retry late collision */ #define FET_PKTShift 11 /* transmit pkt size */ #define FET_TBSMASK 0x000007ff #define FET_TBSShift 0 /* transmit buffer size */ #define FET_MAXFRAGS 1 #define FET_RX_LIST_CNT 64 #define FET_TX_LIST_CNT 64 #define FET_MIN_FRAMELEN 60 /* * A transmit 'super descriptor' is actually FET_MAXFRAGS regular * descriptors clumped together. The idea here is to emulate the * multi-fragment descriptor layout found in devices such as the * Texas Instruments ThunderLAN and 3Com boomerang and cylone chips. * The advantage to using this scheme is that it avoids buffer copies. * The disadvantage is that there's a certain amount of overhead due * to the fact that each 'fragment' is 16 bytes long. In fet tests, * this limits top speed to about 10.5MB/sec. It should be more like * 11.5MB/sec. However, the upshot is that you can achieve better * results on slower machines: a Pentium 200 can pump out packets at * same speed as a PII 400. */ struct fet_txdesc { struct fet_desc fet_frag[FET_MAXFRAGS]; }; #define FET_TXSTATUS(x) x->fet_ptr->fet_frag[x->fet_lastdesc].fet_status #define FET_TXCTL(x) x->fet_ptr->fet_frag[x->fet_lastdesc].fet_ctl #define FET_TXDATA(x) x->fet_ptr->fet_frag[x->fet_lastdesc].fet_data #define FET_TXNEXT(x) x->fet_ptr->fet_frag[x->fet_lastdesc].fet_next #define FET_TXOWN(x) x->fet_ptr->fet_frag[0].fet_status #define FET_UNSENT 0x1234 struct fet_list_data { struct fet_desc fet_rx_list[FET_RX_LIST_CNT]; struct fet_txdesc fet_tx_list[FET_TX_LIST_CNT]; }; struct fet_chain { struct fet_txdesc *fet_ptr; struct mbuf *fet_mbuf; struct fet_chain *fet_nextdesc; u_int8_t fet_lastdesc; }; struct fet_chain_onefrag { struct fet_desc *fet_ptr; struct mbuf *fet_mbuf; struct fet_chain_onefrag *fet_nextdesc; u_int8_t fet_rlast; }; struct fet_chain_data { struct fet_chain_onefrag fet_rx_chain[FET_RX_LIST_CNT]; struct fet_chain fet_tx_chain[FET_TX_LIST_CNT]; struct fet_chain_onefrag *fet_rx_head; struct fet_chain *fet_tx_head; struct fet_chain *fet_tx_tail; struct fet_chain *fet_tx_free; }; struct fet_type { u_int16_t fet_vid; u_int16_t fet_did; char *fet_name; }; #define FET_FLAG_FORCEDELAY 1 #define FET_FLAG_SCHEDDELAY 2 #define FET_FLAG_DELAYTIMEO 3 struct fet_softc { struct arpcom arpcom; /* interface info */ struct ifmedia ifmedia; /* media info */ bus_space_handle_t fet_bhandle; bus_space_tag_t fet_btag; struct fet_type *fet_info; /* adapter info */ struct fet_type *fet_pinfo; /* phy info */ u_int8_t fet_unit; /* interface number */ u_int8_t fet_type; u_int8_t fet_phy_addr; /* PHY address */ u_int8_t fet_tx_pend; /* TX pending */ u_int8_t fet_want_auto; u_int8_t fet_autoneg; u_int16_t fet_txthresh; caddr_t fet_ldata_ptr; struct fet_list_data *fet_ldata; struct fet_chain_data fet_cdata; }; /* * register space access macros */ #define CSR_WRITE_4(sc, reg, val) \ bus_space_write_4(sc->fet_btag, sc->fet_bhandle, reg, val) #define CSR_WRITE_2(sc, reg, val) \ bus_space_write_2(sc->fet_btag, sc->fet_bhandle, reg, val) #define CSR_WRITE_1(sc, reg, val) \ bus_space_write_1(sc->fet_btag, sc->fet_bhandle, reg, val) #define CSR_READ_4(sc, reg) \ bus_space_read_4(sc->fet_btag, sc->fet_bhandle, reg) #define CSR_READ_2(sc, reg) \ bus_space_read_2(sc->fet_btag, sc->fet_bhandle, reg) #define CSR_READ_1(sc, reg) \ bus_space_read_1(sc->fet_btag, sc->fet_bhandle, reg) #define FET_TIMEOUT 1000 /* * General constants that are fun to know. * * PCI vendor ID */ #define FETVENDORID 0x1516 /* * FETSON device IDs. */ #define ID0 0x0800 #define ID1 0x0803 #define ID2 0x0891 /* * ST+OP+PHYAD+REGAD+TA */ #define FET_OP_READ 0x6000 /* ST:01+OP:10+PHYAD+REGAD+TA:Z0 */ #define FET_OP_WRITE 0x5002 /* ST:01+OP:01+PHYAD+REGAD+TA:10 */ /* * Constansts for Myson PHY */ #define MysonPHYID0 0x0300 /* * Constansts for Seeq 80225 PHY */ #define SeeqPHYID0 0x0016 #define SEEQ_MIIRegister18 18 #define SEEQ_SPD_DET_100 0x80 #define SEEQ_DPLX_DET_FULL 0x40 /* * Constansts for Ahdoc 101 PHY */ #define AhdocPHYID0 0x0022 #define AHDOC_DiagnosticReg 18 #define AHDOC_DPLX_FULL 0x0800 #define AHDOC_Speed_100 0x0400 /* * Constansts for Marvell 88E1000/88E1000S PHY and LevelOne PHY */ #define MarvellPHYID0 0x0141 #define LevelOnePHYID0 0x0013 #define Marvell_SpecificStatus 17 #define Marvell_Speed1000 0x8000 #define Marvell_Speed100 0x4000 #define Marvell_FullDuplex 0x2000 /* * PCI low memory base and low I/O base register, and * other PCI registers. Note: some are only available on * the 3c905B, in particular those that related to power management. */ #define FET_PCI_VENDOR_ID 0x00 #define FET_PCI_DEVICE_ID 0x02 #define FET_PCI_COMMAND 0x04 #define FET_PCI_STATUS 0x06 #define FET_PCI_CLASSCODE 0x09 #define FET_PCI_LATENCY_TIMER 0x0D #define FET_PCI_HEADER_TYPE 0x0E #define FET_PCI_LOIO 0x10 #define FET_PCI_LOMEM 0x14 #define FET_PCI_BIOSROM 0x30 #define FET_PCI_INTLINE 0x3C #define FET_PCI_INTPIN 0x3D #define FET_PCI_MINGNT 0x3E #define FET_PCI_MINLAT 0x0F #define FET_PCI_RESETOPT 0x48 #define FET_PCI_EEPROM_DATA 0x4C #define PHY_UNKNOWN 3 #define FET_PHYADDR_MIN 0x00 #define FET_PHYADDR_MAX 0x1F #define PHY_BMCR 0x00 #define PHY_BMSR 0x01 #define PHY_VENID 0x02 #define PHY_DEVID 0x03 #define PHY_ANAR 0x04 #define PHY_LPAR 0x05 #define PHY_ANEXP 0x06 #define PHY_NPTR 0x07 #define PHY_LPNPR 0x08 #define PHY_1000CR 0x09 #define PHY_1000SR 0x0a #define PHY_ANAR_NEXTPAGE 0x8000 #define PHY_ANAR_RSVD0 0x4000 #define PHY_ANAR_TLRFLT 0x2000 #define PHY_ANAR_RSVD1 0x1000 #define PHY_ANAR_RSVD2 0x0800 #define PHY_ANAR_RSVD3 0x0400 #define PHY_ANAR_100BT4 0x0200L #define PHY_ANAR_100BTXFULL 0x0100 #define PHY_ANAR_100BTXHALF 0x0080 #define PHY_ANAR_10BTFULL 0x0040 #define PHY_ANAR_10BTHALF 0x0020 #define PHY_ANAR_PROTO4 0x0010 #define PHY_ANAR_PROTO3 0x0008 #define PHY_ANAR_PROTO2 0x0004 #define PHY_ANAR_PROTO1 0x0002 #define PHY_ANAR_PROTO0 0x0001 #define PHY_1000SR_1000BTXFULL 0x0800 #define PHY_1000SR_1000BTXHALF 0x0400 /* * These are the register definitions for the PHY (physical layer * interface chip). */ /* * PHY BMCR Basic Mode Control Register */ #define PHY_BMCR_RESET 0x8000 #define PHY_BMCR_LOOPBK 0x4000 #define PHY_BMCR_SPEEDSEL 0x2000 #define PHY_BMCR_AUTONEGENBL 0x1000 #define PHY_BMCR_RSVD0 0x0800 /* write as zero */ #define PHY_BMCR_ISOLATE 0x0400 #define PHY_BMCR_AUTONEGRSTR 0x0200 #define PHY_BMCR_DUPLEX 0x0100 #define PHY_BMCR_COLLTEST 0x0080 #define PHY_BMCR_1000 0x0040 /* only used for Marvell PHY */ #define PHY_BMCR_RSVD2 0x0020 /* write as zero, don't care */ #define PHY_BMCR_RSVD3 0x0010 /* write as zero, don't care */ #define PHY_BMCR_RSVD4 0x0008 /* write as zero, don't care */ #define PHY_BMCR_RSVD5 0x0004 /* write as zero, don't care */ #define PHY_BMCR_RSVD6 0x0002 /* write as zero, don't care */ #define PHY_BMCR_RSVD7 0x0001 /* write as zero, don't care */ /* * RESET: 1 == software reset, 0 == normal operation * Resets status and control registers to default values. * Relatches all hardware config values. * * LOOPBK: 1 == loopback operation enabled, 0 == normal operation * * SPEEDSEL: 1 == 100Mb/s, 0 == 10Mb/s * Link speed is selected byt his bit or if auto-negotiation if bit * 12 (AUTONEGENBL) is set (in which case the value of this register * is ignored). * * AUTONEGENBL: 1 == Autonegotiation enabled, 0 == Autonegotiation disabled * Bits 8 and 13 are ignored when autoneg is set, otherwise bits 8 and 13 * determine speed and mode. Should be cleared and then set if PHY configured * for no autoneg on startup. * * ISOLATE: 1 == isolate PHY from MII, 0 == normal operation * * AUTONEGRSTR: 1 == restart autonegotiation, 0 = normal operation * * DUPLEX: 1 == full duplex mode, 0 == half duplex mode * * COLLTEST: 1 == collision test enabled, 0 == normal operation */ /* * PHY, BMSR Basic Mode Status Register */ #define PHY_BMSR_100BT4 0x8000 #define PHY_BMSR_100BTXFULL 0x4000 #define PHY_BMSR_100BTXHALF 0x2000 #define PHY_BMSR_10BTFULL 0x1000 #define PHY_BMSR_10BTHALF 0x0800 #define PHY_BMSR_RSVD1 0x0400 /* write as zero, don't care */ #define PHY_BMSR_RSVD2 0x0200 /* write as zero, don't care */ #define PHY_BMSR_RSVD3 0x0100 /* write as zero, don't care */ #define PHY_BMSR_RSVD4 0x0080 /* write as zero, don't care */ #define PHY_BMSR_MFPRESUP 0x0040 #define PHY_BMSR_AUTONEGCOMP 0x0020 #define PHY_BMSR_REMFAULT 0x0010 #define PHY_BMSR_CANAUTONEG 0x0008 #define PHY_BMSR_LINKSTAT 0x0004 #define PHY_BMSR_JABBER 0x0002 #define PHY_BMSR_EXTENDED 0x0001 From owner-freebsd-net@FreeBSD.ORG Fri Sep 24 13:53:08 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ACE3A16A4CE for ; Fri, 24 Sep 2004 13:53:08 +0000 (GMT) Received: from hanoi.cronyx.ru (hanoi.cronyx.ru [144.206.181.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6E97943D53 for ; Fri, 24 Sep 2004 13:53:07 +0000 (GMT) (envelope-from rik@cronyx.ru) Received: (from root@localhost) by hanoi.cronyx.ru id i8ODo34I040881 for freebsd-net@freebsd.org.checked; (8.12.8/vak/2.1) Fri, 24 Sep 2004 17:50:03 +0400 (MSD) (envelope-from rik@cronyx.ru) Received: from cronyx.ru (hi.cronyx.ru [144.206.181.94]) by hanoi.cronyx.ru with ESMTP id i8ODnguc040863 for ; (8.12.8/vak/2.1) Fri, 24 Sep 2004 17:49:43 +0400 (MSD) (envelope-from rik@cronyx.ru) Message-ID: <4154268C.1040400@cronyx.ru> Date: Fri, 24 Sep 2004 17:52:12 +0400 From: Roman Kurakin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031208 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Subject: DSLAM X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 24 Sep 2004 13:53:08 -0000 Hi, I wonder if there is any ADSL DSLAM PCI adapter? rik From owner-freebsd-net@FreeBSD.ORG Fri Sep 24 15:50:14 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7E82316A5A2; Fri, 24 Sep 2004 15:50:14 +0000 (GMT) Received: from post5.inre.asu.edu (post5.inre.asu.edu [129.219.110.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id EAB9543D1D; Fri, 24 Sep 2004 15:50:13 +0000 (GMT) (envelope-from David.Bear@asu.edu) Received: from conversion.post5.inre.asu.edu by asu.edu (PMDF V6.1-1X6 #30769) id <0I4J00A01YGX6Y@asu.edu>; Fri, 24 Sep 2004 08:46:10 -0700 (MST) Received: from smtp.asu.edu (smtp.asu.edu [129.219.110.107]) <0I4J00A0NYGX5Y@asu.edu>; Fri, 24 Sep 2004 08:46:09 -0700 (MST) Received: from moroni.pp.asu.edu (moroni.pp.asu.edu [129.219.69.200]) (8.12.10/8.12.10/asu_smtp_relay,nullclient,tcp_wrapped) with ESMTP id i8OFk671011433; Fri, 24 Sep 2004 08:46:06 -0700 (MST) Received: by moroni.pp.asu.edu (Postfix, from userid 500) id 539A0E40; Fri, 24 Sep 2004 08:45:58 -0700 (MST) Received: from post1.inre.asu.edu (post1.inre.asu.edu [129.219.110.72]) by imap1.asu.edu (8.11.0/8.11.0/asu_cyrus,tcp_wrapped) with ESMTP id fB6L1J015130 for ; Thu, 06 Dec 2001 14:01:20 -0700 (MST) Received: from conversion.post1.inre.asu.edu by asu.edu (PMDF V6.1 #40110) david.bear@asu.edu) ; Thu, 06 Dec 2001 14:01:19 -0700 (MST) Received: from mx2.freebsd.org (mx2.FreeBSD.org [216.136.204.119]) by asu.edu (PMDF V6.1 #40110) with ESMTP id <0GNX00F5IX21B7@asu.edu> for iddwb@IMAP1.ASU.EDU (ORCPT david.bear@asu.edu); Thu, 06 Dec 2001 14:01:13 -0700 (MST) Received: from hub.freebsd.org (hub.FreeBSD.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id 88D4F55AAB; Thu, 06 Dec 2001 13:00:52 -0800 Received: by hub.freebsd.org (Postfix, from userid 538) id 730EE37B419; Thu, 06 Dec 2001 12:59:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with SMTP id C548C2E8002; Thu, 06 Dec 2001 12:59:44 -0800 (PST) Received: by hub.freebsd.org (bulk_mailer v1.12); Thu, 06 Dec 2001 12:59:44 -0800 Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by hub.freebsd.org (Postfix) with ESMTP id 0BA6937B405; Thu, 06 Dec 2001 12:59:41 -0800 (PST) Received: from alliance.research.att.commail-green.research.att.com (Postfix) with ESMTP id 7E1EF1E07C; Thu, 06 Dec 2001 15:59:40 -0500 (EST) Received: from windsor.research.att.comalliance.research.att.com (8.8.7/8.8.7) with ESMTP id PAA27865; Thu, 06 Dec 2001 15:59:39 -0500 (EST) Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id MAA02282; Thu, 06 Dec 2001 12:59:39 -0800 (PST) From: Bill Fenner Sender: owner-freebsd-security@FreeBSD.ORG To: dwbear75@gmail.com Message-id: <200112062059.MAA02282@windsor.research.att.com> MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Precedence: bulk X-Loop: FreeBSD.org Delivered-to: freebsd-security@freebsd.org Old-To: cjclark@alum.mit.edu Versions: dmail (solaris) 2.2j/makemail 2.9b Lines: 16 References: <20011205124430.A83642@svzserv.kemerovo.su> <20011205040316.H40864@blossom.cjclark.org> <20011205231735.A1361@grosbein.pp.ru> <20011205193859.B79705@sunbay.com> <200112051835.fB5IZqH95521@whizzo.transsys.com> <20011205204526.B89520@sunbay.com> <200112051852.fB5IqmH95809@whizzo.transsys.com> <20011205121928.A3061@blossom.cjclark.org> X-Keywords: cc: security@FreeBSD.ORG cc: net@FreeBSD.ORG Subject: Re: NOARP - gateway must answer and have frozen ARP table X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Fri, 24 Sep 2004 15:50:14 -0000 X-Original-Date: Thu, 06 Dec 2001 12:59:39 -0800 X-List-Received-Date: Fri, 24 Sep 2004 15:50:14 -0000 Garrett and I discussed what IFF_NOARP should mean about 4-5 years ago; we decided that it probably menat "no ARP". We discussed the idea of seperating it out into two flags; "Don't reply to ARP" and "don't pay attention to ARP" but decided to wait and see what people thought. 4-5 years is probably enough time to wait =) My proposal: keep IFF_NOARP, but add IFF_NOSENDARP and IFF_NOREPLYARP (or something, I'm no good at making up names). I agree with Louie that it makes sense for these to be per-interface as opposed to Ruslan's sysctl. Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-net@FreeBSD.ORG Fri Sep 24 15:50:43 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 18B2A16A5AB; Fri, 24 Sep 2004 15:50:43 +0000 (GMT) Received: from post5.inre.asu.edu (post5.inre.asu.edu [129.219.110.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id 57D3F43D9D; Fri, 24 Sep 2004 15:50:38 +0000 (GMT) (envelope-from David.Bear@asu.edu) Received: from conversion.post5.inre.asu.edu by asu.edu (PMDF V6.1-1X6 #30769) id <0I4J00A01YIBNL@asu.edu>; Fri, 24 Sep 2004 08:46:59 -0700 (MST) Received: from smtp.asu.edu (smtp.asu.edu [129.219.110.107]) <0I4J009FYYIASO@asu.edu>; Fri, 24 Sep 2004 08:46:59 -0700 (MST) Received: from moroni.pp.asu.edu (moroni.pp.asu.edu [129.219.69.200]) (8.12.10/8.12.10/asu_smtp_relay,nullclient,tcp_wrapped) with ESMTP id i8OFks71012650; Fri, 24 Sep 2004 08:46:54 -0700 (MST) Received: by moroni.pp.asu.edu (Postfix, from userid 500) id 7023DE37; Fri, 24 Sep 2004 08:46:33 -0700 (MST) Received: from post1.inre.asu.edu (post1.inre.asu.edu [129.219.110.72]) by imap1.asu.edu (8.11.0/8.11.0/asu_cyrus,tcp_wrapped) with ESMTP id g489GfE28797 for ; Wed, 08 May 2002 02:16:41 -0700 (MST) Received: from conversion.post1.inre.asu.edu by asu.edu (PMDF V6.1 #40110) david.bear@asu.edu) ; Wed, 08 May 2002 02:16:41 -0700 (MST) Received: from mx2.freebsd.org (mx2.FreeBSD.org [216.136.204.119]) by asu.edu (PMDF V6.1 #40110) with ESMTP id <0GVS00JA2CFT7A@asu.edu> for iddwb@IMAP1.ASU.EDU (ORCPT david.bear@asu.edu); Wed, 08 May 2002 02:16:41 -0700 (MST) Received: from hub.freebsd.org (hub.FreeBSD.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id 1332A55FFF; Wed, 08 May 2002 02:16:37 -0700 Received: by hub.freebsd.org (Postfix, from userid 538) id BBAB437B403; Wed, 08 May 2002 02:16:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with SMTP id C34BB2E801F; Wed, 08 May 2002 02:16:21 -0700 (PDT) Received: by hub.freebsd.org (bulk_mailer v1.12); Wed, 08 May 2002 02:16:20 -0700 Received: from cairo.anu.edu.au (cairo.anu.edu.au [150.203.224.11]) by hub.freebsd.org (Postfix) with ESMTP id 85C5237B408; Wed, 08 May 2002 02:16:16 -0700 (PDT) Received: from cairo.anu.edu.au (localhost [127.0.0.1]) by cairo.anu.edu.au (8.12.0/8.12.0) with ESMTP id g489GD3g019357; Wed, 08 May 2002 19:16:13 +1000 (EST) Received: (from avalon@localhost) by cairo.anu.edu.au (8.12.0/8.12.0.Beta16) id g489GDec019355; Wed, 08 May 2002 19:16:13 +1000 (EST) From: Darren Reed In-reply-to: <20020507231529.8B55C2744@tesla.foo.is> Sender: owner-freebsd-security@FreeBSD.ORG To: dwbear75@gmail.com Message-id: <200205080916.g489GDec019355@cairo.anu.edu.au> MIME-version: 1.0 X-Mailer: ELM [version 2.5 PL1] Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Precedence: bulk X-Loop: FreeBSD.org Delivered-to: freebsd-security@freebsd.org Old-To: baldur@foo.is (Baldur Gislason) Lines: 28 X-Keywords: cc: Tom Limoncelli cc: freebsd-security@FreeBSD.ORG cc: freebsd-net@FreeBSD.ORG Subject: Re: ipf vs. ipfw X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Fri, 24 Sep 2004 15:50:43 -0000 X-Original-Date: Wed, 08 May 2002 19:16:13 +1000 (Australia/NSW) X-List-Received-Date: Fri, 24 Sep 2004 15:50:43 -0000 In some mail from Baldur Gislason, sie said: > > ipfw is in no way related to the linux firewalls (ipfwadm, ipchains or > iptables). It is a specially designed firewall for FreeBSD. It isn't > dependent on ipf, it has it's own in-kernel mechanism. It has a totally > different syntax. Why FreeBSD has both I can't answer, ipfw and ipf each have > their own advantages over each other. In my experience, ipfw is easier to > work with, but it's also limited in some ways. Ipf tends to have a more > complex ruleset, and more stateful functionality (ipfw can do stateful > filtering but ipf has more customisable state keeping rules IIRC), however > ipfw does have the ability to apply rules by uid's if you're doing a firewall > for the local machine, and it does have a packet/byte counter for each > individual rule. I'm not sure how this is with ipf as I haven't used is as > much as I have used ipfw. ipf has a completely separate set of rules you can use for accounting and is minus any os-specific hacks (such as uid filtering) ipfw does share its roots with the linux ipfw but linux long ago dropped its one and the freebsd one is now much different. ipf used to be more "leading edge" than any of the others and hence offered more features and a bigger coolness factor but I've been slack for the last year or two on that front. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-net@FreeBSD.ORG Fri Sep 24 17:24:22 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5A07F16A4CE for ; Fri, 24 Sep 2004 17:24:22 +0000 (GMT) Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 241DF43D54 for ; Fri, 24 Sep 2004 17:24:22 +0000 (GMT) (envelope-from cristjc@comcast.net) Received: from blossom.cjclark.org (c-24-6-187-112.client.comcast.net[24.6.187.112]) by comcast.net (rwcrmhc12) with ESMTP id <20040924172421014001u8lte>; Fri, 24 Sep 2004 17:24:21 +0000 Received: from blossom.cjclark.org (localhost. [127.0.0.1]) by blossom.cjclark.org (8.12.11/8.12.8) with ESMTP id i8OHOJbG091507 for ; Fri, 24 Sep 2004 10:24:20 -0700 (PDT) (envelope-from cristjc@comcast.net) Received: (from cjc@localhost) by blossom.cjclark.org (8.12.11/8.12.11/Submit) id i8OHOIQI091506 for freebsd-net@freebsd.org; Fri, 24 Sep 2004 10:24:18 -0700 (PDT) (envelope-from cristjc@comcast.net) X-Authentication-Warning: blossom.cjclark.org: cjc set sender to cristjc@comcast.net using -f Date: Fri, 24 Sep 2004 10:24:18 -0700 From: "Crist J. Clark" To: freebsd-net@freebsd.org Message-ID: <20040924172418.GA91417@blossom.cjclark.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="1yeeQ81UyVL57Vl7" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-URL: http://people.freebsd.org/~cjc/ Subject: nsupdate(8) rc.d Script X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: cjclark@alum.mit.edu List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Sep 2004 17:24:22 -0000 --1yeeQ81UyVL57Vl7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline As I was setting up DNS for IPv6 on a test network, I started to get really tired of entering 128-bit addresses, for both forward and reverse lookups, into DNS by hand. It seemed somewhat silly to be doing all of this manually when the actual IPv6 hosts pretty much configure themselves with rtsol(8). So I went ahead setting up an nsupdate script to have the systems automatically use DNS updates to "register" themselves. I figured I might as well do IPv4 while I was at it. Now I'm wondering if this is something other people may find useful and whether I should commit it. I think there are enough knobs to make it work for most people. But there very well may be some assumptions that may make it totally unsuitable for a lot of systems too. I'm not 100% sure where to drop it into the rc.d order. Obviously, it is a network service, but it would be nice to sign up in DNS early so we have entries in DNS when other machines might try to look us up when we contact them in later rc.d scripts. One thing that might be nice is if we wait until a local DNS server starts in the case we are the server, but having a DNS server auto-update its own info... kinda a chicken-and-egg problem there, may not be a best practice. Finally, that is one long awk script. Is there a better tool or method for converting an IPv6 presentation address into the ip6.arpa format? And the script is not optimized to do the updates in the fewest number of packets. An update can only contain updates for a single zone. It makes the only safe assumption that any two domain names are not in the same zone unless they are the same. I do not know how to reduce the number of updates without making things a LOT more complicated and doing more total DNS queries to find out SOA information. To enable the updates, just add, nsupdate_enable="YES" To rc.conf(5). The patch to the default rc.conf has it disabled by default. IPv4 and IPv6 updates may be toggled individually, but IPv6 only works if ipv6_enable is also "on." Patch is against RELENG_5, but it should work fine in CURRENT. Suggestions, comments, or criticisms, public or private, are welcome. -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org --1yeeQ81UyVL57Vl7 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="rc.nsupdate.patch" Index: src/etc/defaults/rc.conf =================================================================== RCS file: /ncvs/src/etc/defaults/rc.conf,v retrieving revision 1.212 diff -u -r1.212 rc.conf --- src/etc/defaults/rc.conf 27 Jul 2004 00:28:16 -0000 1.212 +++ src/etc/defaults/rc.conf 24 Sep 2004 16:54:34 -0000 @@ -139,6 +139,22 @@ # Choose correct tunnel addrs. #gifconfig_gif0="10.1.1.1 10.1.2.1" # Examples typically for a router. #gifconfig_gif1="10.1.1.2 10.1.2.2" # Examples typically for a router. +# Nsupdate(8) allows the machine to send DNS updates to "register" in DNS. +# IPv4 loopback (127/8), and IPv6 loopback (::1) and link-local (fe80::/17) +# addresses are not registered. +nsupdate_enable="NO" # Do any DNS updates. +nsupdate_flags="" # Pass additional arguments, e.g. to use DNSSEC TSIG, + # "-k /etc/namedb:MY_DYN_DNS_KEY" +nsupdate_command="/usr/sbin/nsupdate" # Default is base system's BIND. +nsupdate_ipv4="YES" # Register IPv4 addresses associated with interfaces. +nsupdate_ipv6="YES" # Register IPv6 addresses associated with interfaces. +nsupdate_ifaces="auto" # List interfaces, 'auto,' 'dhcp,' or 'nodhcp.' +nsupdate_ttl="3600" # Time-to-live for the DNS records. +nsupdate_reverse="YES" # Attempt to add "reverse" records, in-addr.arpa + # and ip6.arpa trees. +nsupdate_shutdown_remove="YES" # Remove our records at shutdown. +#nsupdate_hostname_ed0="dynamic-host.example.com" # Associate a hostname + # with an interface, otherwise system hostname used. # User ppp configuration. ppp_enable="NO" # Start user-ppp (or NO). Index: src/etc/rc.d/nsupdate =================================================================== RCS file: src/etc/rc.d/nsupdate diff -N src/etc/rc.d/nsupdate --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ src/etc/rc.d/nsupdate 24 Sep 2004 16:50:49 -0000 @@ -0,0 +1,124 @@ +#!/bin/sh +# +# $FreeBSD$ +# + +# PROVIDE: nsupdate +# REQUIRE: NETWORKING +# KEYWORD: FreeBSD + +. /etc/rc.subr +. /etc/network.subr + +name="nsupdate" +rcvar=`set_rcvar` +start_cmd="nsupdate_start" +stop_cmd="nsupdate_stop" + +nsupdate_run() +{ + checkyesno nsupdate_ipv4 + _ipv4_enable="$?" + checkyesno ipv6_enable && checkyesno nsupdate_ipv6 + _ipv6_enable="$?" + checkyesno nsupdate_reverse + _do_reverse="$?" + case "$1" in + 'add') + _action='add' + _ttl="${nsupdate_ttl}" + ;; + 'delete') + _action='delete' + _ttl='' + ;; + *) + return 1 + ;; + esac + case "${nsupdate_ifaces}" in + 'auto') + _interfaces=`list_net_interfaces` + ;; + 'dhcp') + _interfaces=`list_net_interfaces dhcp` + ;; + 'nodhcp') + _interfaces=`list_net_interfaces nodhcp` + ;; + *) + _interfaces="${nsupdate_ifaces}" + esac + for _iface in ${_interfaces}; do + eval _hostname="\$nsupdate_hostname_${_iface}" + if [ -z "${_hostname}" ]; then + _hostname=`hostname` + fi + ifconfig "${_iface}" | + awk -v "inet4=${_ipv4_enable}" -v "inet6=${_ipv6_enable}" \ + -v "hostname=${_hostname}" -v "ttl=${_ttl}" \ + -v "do_reverse=${_do_reverse}" -v "action=${_action}" \ + '! inet4 && /inet / && $2 !~ /^127\./ { + printf "update %s %s %s a %s\n", action, + hostname, ttl, $2; + ip4[++i] = $2; + } + ! inet6 && /inet6 / && $2 !~ /^(fe80:|::1)/ { + printf "update %s %s %s aaaa %s\n", action, + hostname, ttl, $2; + ip6[++j] = $2; + } + END { + print ""; + if (do_reverse != 0) { + exit 0; + } + for (i in ip4) { + split(ip4[i], oct, /\./); + printf "update %s %d.%d.%d.%d.in-addr.arpa %s ptr %s\n", + action, + oct[4], oct[3], oct[2], oct[1], + ttl, hostname; + print ""; + } + for (j in ip6) { + cols = gsub(/:/, ":", ip6[j]); + zeroes = ""; + for (i = cols; i < 8; i++) { + zeros = zeros ":0"; + } + zeros = zeros ":"; + sub(/::/, zeros, ip6[j]); + split(ip6[j], shorts, /:/); + ip6str = ""; + for (i = 1; i <= 8; i++) { + shorts[i] = substr("000" shorts[i], + length(shorts[i])); + ip6str = ip6str shorts[i]; + } + revstr = ""; + for (i = 1; i <= length(ip6str); i++) { + revstr = substr(ip6str, i, 1) "." revstr; + } + printf "update %s %sip6.arpa %s ptr %s\n", + action, revstr, ttl, hostname; + print ""; + } + }' + done | + "${nsupdate_command}" ${nsupdate_flags} +} + +nsupdate_start() +{ + nsupdate_run add +} + +nsupdate_stop() +{ + checkyesno nsupdate_shutdown_remove || return 0 + nsupdate_run delete +} + +load_rc_config $name +run_rc_command "$1" --1yeeQ81UyVL57Vl7-- From owner-freebsd-net@FreeBSD.ORG Fri Sep 24 17:27:51 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BA6E016A4CF for ; Fri, 24 Sep 2004 17:27:51 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8A3B643D5C for ; Fri, 24 Sep 2004 17:27:51 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id i8OHUgfL027133; Fri, 24 Sep 2004 10:30:42 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id i8OHUglZ027131; Fri, 24 Sep 2004 10:30:42 -0700 Date: Fri, 24 Sep 2004 10:30:42 -0700 From: Brooks Davis To: Waldemar Kornewald Message-ID: <20040924173042.GB6672@odin.ac.hmc.edu> References: <4152A3E9.8080700@web.de> <20040923181605.GC25699@odin.ac.hmc.edu> <415339A1.6090905@web.de> <20040923211703.GA23574@odin.ac.hmc.edu> <4153B897.9040807@web.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Y7xTucakfITjPcLV" Content-Disposition: inline In-Reply-To: <4153B897.9040807@web.de> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: FreeBSD-net Subject: Re: locking & iovecs X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 24 Sep 2004 17:27:51 -0000 --Y7xTucakfITjPcLV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 24, 2004 at 08:03:03AM +0200, Waldemar Kornewald wrote: > Brooks Davis wrote: > >>>You can implement mutexes using semaphores, but semaphores tend to be a > >>>more expensive since they are more expressive them mutexes. > >> > >>Using a benaphore instead would improve speed significantly and as you= =20 > >>only use macros we can easily replace those with our benaphore code, is= =20 > >>that really so simple? Sorry, I cannot believe that. :) > > > >Once GIANT is really gone, it may be nearly that easy. We're a ways > >from that though. >=20 > So, the code is not fully thread-safe yet (we want to drop GIANT)? Then,= =20 > I misunderstood something. Will 5.3 be freed of GIANT? I believe IPv4 is pretty close other then NIC drivers, but IPv6 is largely not done yet. GIANT will definatly not be gone in 5.3. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --Y7xTucakfITjPcLV Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBVFnBXY6L6fI4GtQRAkYpAJ9tUPXY78XyFmI/t0YgnNLIDPtcgQCg1rrm 5QXNhImBKljewDgIi9iFE/g= =ErUF -----END PGP SIGNATURE----- --Y7xTucakfITjPcLV-- From owner-freebsd-net@FreeBSD.ORG Fri Sep 24 17:39:42 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E66E916A4CE for ; Fri, 24 Sep 2004 17:39:42 +0000 (GMT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id C48A143D1D for ; Fri, 24 Sep 2004 17:39:41 +0000 (GMT) (envelope-from pekkas@netcore.fi) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i8OHdWI17924; Fri, 24 Sep 2004 20:39:32 +0300 Date: Fri, 24 Sep 2004 20:39:32 +0300 (EEST) From: Pekka Savola To: snap-users@kame.net In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 cc: freebsd-net@freebsd.org Subject: Re: (KAME-snap 8792) Re: Weird memory exhaustion with FreeBSD 4.10-STABLE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 24 Sep 2004 17:39:43 -0000 On Sat, 25 Sep 2004, JINMEI Tatuya / [ISO-2022-JP] 神明達哉 wrote: > Apparently the most significant change is the memory consumption > regarding routing table: > > In "wrk" > Memory statistics by bucket size > Size In Use Free Requests HighWater Couldfree > 64 2196 44 5165 320 0 > Memory statistics by type Type Kern > Type InUse MemUse HighUse Limit Requests Limit Limit Size(s) > routetbl 461 67K 67K 10148K 538 0 0 16,32,64,128,256,512 > > In "brk" > Memory statistics by bucket size > Size In Use Free Requests HighWater Couldfree > 64 37865 2583 5315047 320 1075 > Memory statistics by type Type Kern > Type InUse MemUse HighUse Limit Requests Limit Limit Size(s) > routetbl 64959 10148K 10148K 10148K 2445306 0 0 16,32,64,128,256,512 OK.. > Some random thoughts, which may or may not help, at the moment: > > 1. do you see massive number of entries with "netstat -rna"? Yes. # netstat -nra | wc -l 32468 # A couple of examples: 2002:41a:1e23::41a:1e23 2002:c058:6301::1741 UHW3 stf0 2002:41a:1eaa::41a:1eaa 2002:c058:6301::1741 UHW3 stf0 2002:41a:6b0e::41a:6b0e 2002:c058:6301::1741 UHW3 stf0 2002:41a:6f4b::41a:6f4b 2002:c058:6301::1741 UHW3 stf0 2002:41a:70f5::41a:70f5 2002:c058:6301::1741 UHW3 stf0 1433 2002:41a:7411::41a:7411 2002:c058:6301::1741 UHW3 stf0 2002:41a:8e81::41a:8e81 2002:c058:6301::1741 UHW3 stf0 That's basically about all the 2002:xxx addresses which have been relayed through. I'd suspect the number is maxed and garbage-collected around 2^15 though, because the box is relaying w/ much many more addresses than that. I guess this provides a hint at a very probable source of leakage. > 2. if you specify the "link2" flag on the stf interface, what if you > do not specify it? (if such operation is acceptable in your > environment) The flag is not specified. > 3. if you can replace the kernel with KAME snap versions, do you see > any difference in the memory consumption? This would be a bit difficult, so I'd like to avoid it if possible. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-freebsd-net@FreeBSD.ORG Fri Sep 24 18:08:15 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2E1A016A4CE for ; Fri, 24 Sep 2004 18:08:15 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id CED7E43D1D for ; Fri, 24 Sep 2004 18:08:14 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.13.1/8.13.1) with ESMTP id i8OI7T5f099608; Fri, 24 Sep 2004 14:07:29 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i8OI7SaR099605; Fri, 24 Sep 2004 14:07:28 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Fri, 24 Sep 2004 14:07:28 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Waldemar Kornewald In-Reply-To: <4152A3E9.8080700@web.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: FreeBSD-net Subject: Re: locking X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 24 Sep 2004 18:08:15 -0000 On Thu, 23 Sep 2004, Waldemar Kornewald wrote: > we at the Haiku networking team are considering a port of your 5.3 > netstack because it is thread-safe and making the old one (4.x, I think) > thread-safe is probably a much bigger task. > > Now, I saw that the routing code seems to use macros for the locking > code. Do you use macros everywhere? > > We would prefer having native threads and locks. Haiku only has > semaphores, not mutexes, is that a problem? > > Could you think of some other difficulties we could run into when > porting it? There are some sections of the network stack, such as the KAME IPSEC implementation, parts of IPv6, and some device drivers, which are not yet completely MPSAFE. This may or may not be an issue depending on what your requirements are. If you have any bug fixes or improvements, we would love to hear about them -- right now our locking is fairly coarse-grained but we'll be looking at contention issues over the next few months to see how best to refine our locking strategy. Regarding synchronization -- semaphores can be used to implement mutual exclusion, and so you could simply implement the locking macros in terms of semaphores rather than mutexes. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research From owner-freebsd-net@FreeBSD.ORG Fri Sep 24 18:09:41 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B9DD216A4CE for ; Fri, 24 Sep 2004 18:09:41 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A69A43D4C for ; Fri, 24 Sep 2004 18:09:41 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.13.1/8.13.1) with ESMTP id i8OI8tu3099792; Fri, 24 Sep 2004 14:08:55 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i8OI8trY099789; Fri, 24 Sep 2004 14:08:55 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Fri, 24 Sep 2004 14:08:55 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Waldemar Kornewald In-Reply-To: <4153B897.9040807@web.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: FreeBSD-net Subject: Re: locking & iovecs X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 24 Sep 2004 18:09:41 -0000 On Fri, 24 Sep 2004, Waldemar Kornewald wrote: > > Once GIANT is really gone, it may be nearly that easy. We're a ways > > from that though. > > So, the code is not fully thread-safe yet (we want to drop GIANT)? Then, > I misunderstood something. Will 5.3 be freed of GIANT? Including some components in the kernel will force the Giant lock back over the network stack. For example, if you compile with KAME IPSEC or IPX. There is active work in many of those areas to remove that requirement. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research From owner-freebsd-net@FreeBSD.ORG Fri Sep 24 18:40:02 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 941A416A4CE; Fri, 24 Sep 2004 18:40:02 +0000 (GMT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by mx1.FreeBSD.org (Postfix) with ESMTP id DCEC143D1F; Fri, 24 Sep 2004 18:40:01 +0000 (GMT) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:a883:d32e:3c11:f22d]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 7250415272; Sat, 25 Sep 2004 03:39:59 +0900 (JST) Date: Sat, 25 Sep 2004 03:40:04 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Brian Fundakowski Feldman In-Reply-To: <20040923185841.GD959@green.homeunix.org> References: <20040922020957.GE84424@green.homeunix.org> <20040923185841.GD959@green.homeunix.org> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII cc: net@FreeBSD.org Subject: Re: IPv6 route mutex recursion (crash) and fix X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 24 Sep 2004 18:40:02 -0000 (resending, since the first attempt seems to have failed due to some DNS-related error) >>>>> On Thu, 23 Sep 2004 14:58:41 -0400, >>>>> Brian Fundakowski Feldman said: >> So, as a result, I tend to think the proposed patch is a reasonable >> fix to the problem. But please add the rationale as comments, since >> the background intent is a bit vague as shown by the question from >> George. > Thank you for your review. As you certainly are more knowledgable in KAME > code than I am, would you mind redoing this so that the style is more > closely matched; then I could take the change from the KAME repository? I'm willing to help you, but please let me check to be sure. Are you asking me to modify the KAME snap code based on your patch first, which you'll then merge back to FreeBSD? JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp From owner-freebsd-net@FreeBSD.ORG Fri Sep 24 18:46:26 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 539D416A4CF for ; Fri, 24 Sep 2004 18:46:26 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2E32943D2D for ; Fri, 24 Sep 2004 18:46:24 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id DB0357A424; Fri, 24 Sep 2004 11:46:23 -0700 (PDT) Message-ID: <41546B7F.2010009@elischer.org> Date: Fri, 24 Sep 2004 11:46:23 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: Waldemar Kornewald References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: FreeBSD-net Subject: Re: Haiku X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 24 Sep 2004 18:46:26 -0000 >On Thu, 23 Sep 2004, Waldemar Kornewald wrote: > > > >>we at the Haiku networking team are considering a port of your 5.3 >>netstack because it is thread-safe and making the old one (4.x, I think) >>thread-safe is probably a much bigger task. >> >> >> do you have a web page that describes what you are doing? From owner-freebsd-net@FreeBSD.ORG Fri Sep 24 18:51:41 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BB54A16A4CF for ; Fri, 24 Sep 2004 18:51:41 +0000 (GMT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by mx1.FreeBSD.org (Postfix) with ESMTP id 24BC943D3F for ; Fri, 24 Sep 2004 18:51:41 +0000 (GMT) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:a883:d32e:3c11:f22d]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 0047E1525D; Sat, 25 Sep 2004 03:51:39 +0900 (JST) Date: Sat, 25 Sep 2004 03:51:44 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: snap-users@kame.net In-Reply-To: References: User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII cc: freebsd-net@freebsd.org Subject: Re: (KAME-snap 8793) Re: Weird memory exhaustion with FreeBSD 4.10-STABLE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 24 Sep 2004 18:51:41 -0000 >>>>> On Fri, 24 Sep 2004 20:39:32 +0300 (EEST), >>>>> Pekka Savola said: >> 1. do you see massive number of entries with "netstat -rna"? > Yes. > # netstat -nra | wc -l > 32468 > # Okay, to be sure, most of them are IPv6 routing entries, right? Then please provide some additional information. 1. the result of netstat -rnal. A digest of the output is probably enough, but if you could provide the entire output (on the web, for example) it would also be helpful. 2. how did you configure the route to the stf interface? I guess you installed some static route for 2002::/16 to the interface. The command line argument (or the rc.conf parameters) that made the route and the corresponding route entry shown by netstat -rn are both helpful. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp From owner-freebsd-net@FreeBSD.ORG Fri Sep 24 22:18:26 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ACE4A16A4CE for ; Fri, 24 Sep 2004 22:18:26 +0000 (GMT) Received: from smtp2.jazztel.es (smtp2.jazztel.es [62.14.3.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 738F843D31 for ; Fri, 24 Sep 2004 22:18:26 +0000 (GMT) (envelope-from josemi@freebsd.jazztel.es) Received: from antivirus by smtp2.jazztel.es with antivirus id 1CAyOT-0003JU-00 for net@freebsd.org Sat, 25 Sep 2004 00:18:21 +0200 Received: from [212.106.252.44] (helo=rguez.homeunix.net) by smtp2.jazztel.es with esmtp id 1CAyOS-0003JD-00 for net@freebsd.org Sat, 25 Sep 2004 00:18:20 +0200 Received: from localhost.redesjm.local (orion.redesjm.local [192.168.254.16]) by rguez.homeunix.net (8.13.1/8.13.1) with ESMTP id i8OMIObC000537 for ; Sat, 25 Sep 2004 00:18:24 +0200 (CEST) (envelope-from josemi@freebsd.jazztel.es) References: Message-ID: To: "net@freebsd.org" Date: Sat, 25 Sep 2004 00:18:24 +0200 From: "Jose M Rodriguez" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Opera M2/7.54 (FreeBSD, build 751) X-AntiVirus: checked by AntiVir Milter 1.1-beta; AVE 6.27.0.11; VDF 6.27.0.70 (host: antares.redesjm.local) X-Virus-Scanned: by antivirus Subject: Fwd: tftp block size server support X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 24 Sep 2004 22:18:26 -0000 I'm not sure if this hot the list. Sorry, smtp realy problems ------- Forwarded message ------- From: "Jose M Rodriguez" To: net@freebsd.org Subject:Date: Sun, 19 Sep 2004 23:53:18 +0200 Can someone take a look on PR bin/67550? The protocol correctness maybe not important, but the tftp blocksize option speed up our net boots a lot. thanks in advance, -- josemi -- Using Opera's revolutionary e-mail client: http://www.opera.com/m2/ From owner-freebsd-net@FreeBSD.ORG Fri Sep 24 23:00:14 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 64E4416A4CE for ; Fri, 24 Sep 2004 23:00:14 +0000 (GMT) Received: from green.homeunix.org (pcp04368961pcs.nrockv01.md.comcast.net [69.140.212.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 065EE43D1D for ; Fri, 24 Sep 2004 23:00:14 +0000 (GMT) (envelope-from green@green.homeunix.org) Received: from green.homeunix.org (green@localhost [127.0.0.1]) by green.homeunix.org (8.13.1/8.13.1) with ESMTP id i8ON0DgM001900; Fri, 24 Sep 2004 19:00:13 -0400 (EDT) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.13.1/8.13.1/Submit) id i8ON0COx001899; Fri, 24 Sep 2004 19:00:12 -0400 (EDT) (envelope-from green) Date: Fri, 24 Sep 2004 19:00:12 -0400 From: Brian Fundakowski Feldman To: "JINMEI Tatuya / ?$B?@L@C#:H" Message-ID: <20040924230011.GA1164@green.homeunix.org> References: <20040922020957.GE84424@green.homeunix.org> <20040923185841.GD959@green.homeunix.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i cc: net@FreeBSD.org Subject: Re: IPv6 route mutex recursion (crash) and fix X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 24 Sep 2004 23:00:14 -0000 On Sat, Sep 25, 2004 at 03:40:04AM +0900, JINMEI Tatuya / ?$B?@L@C#:H wrote: > (resending, since the first attempt seems to have failed due to some > DNS-related error) > > >>>>> On Thu, 23 Sep 2004 14:58:41 -0400, > >>>>> Brian Fundakowski Feldman said: > > >> So, as a result, I tend to think the proposed patch is a reasonable > >> fix to the problem. But please add the rationale as comments, since > >> the background intent is a bit vague as shown by the question from > >> George. > > > Thank you for your review. As you certainly are more knowledgable in KAME > > code than I am, would you mind redoing this so that the style is more > > closely matched; then I could take the change from the KAME repository? > > I'm willing to help you, but please let me check to be sure. Are you > asking me to modify the KAME snap code based on your patch first, > which you'll then merge back to FreeBSD? Yes, that is the way I would prefer things to be done, but either way is fine with me. -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ From owner-freebsd-net@FreeBSD.ORG Sat Sep 25 03:07:51 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D3A6D16A4CE for ; Sat, 25 Sep 2004 03:07:51 +0000 (GMT) Received: from outbound0.sv.meer.net (outbound0.sv.meer.net [205.217.152.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id B65B243D54 for ; Sat, 25 Sep 2004 03:07:51 +0000 (GMT) (envelope-from gnn@neville-neil.com) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) i8P374r2069224; Fri, 24 Sep 2004 20:07:05 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (pc1.oakwoodazabu1-unet.ocn.ne.jp [220.110.140.201]) by mail.meer.net (8.12.1/8.12.2/meer) with ESMTP id i8P372uZ083645; Fri, 24 Sep 2004 20:07:02 -0700 (PDT) (envelope-from gnn@neville-neil.com) Date: Sat, 25 Sep 2004 12:07:00 +0900 Message-ID: From: "George V. Neville-Neil" To: ming fu In-Reply-To: <41541355.50800@borderware.com> References: <41541355.50800@borderware.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.5 Emacs/21.2 (powerpc-apple-darwin) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII cc: freebsd-net@freebsd.org Subject: Re: promisc coding question X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 25 Sep 2004 03:07:52 -0000 At Fri, 24 Sep 2004 08:30:13 -0400, ming fu wrote: > > Hi, > > in if.h > #define IFF_PROMISC 0x100 /* receive all packets */ > #define IFF_PPROMISC 0x20000 /* user-requested promisc mode */ > > Do I have to set both on for the promisc to work? > If I only need one of them, then what is the difference? > The first flag (IFF_PROMISC) is the one that the kernel code uses and sets on an interface's ifp structure. The second one is the one that comes from user space programs and is sent to the routine ifhwioctl() to set the first flag. Having reviewed this flags usage I believe that there are at least two bugs in the kernel related to its handling: I beleieve it is only used correctly at: if.c[1160] if (new_flags & IFF_PPROMISC) { but that at: if.c[1478] if (ifp->if_flags & IFF_PPROMISC) { and if_ethersubr.c[664] && (ifp->if_flags & IFF_PPROMISC)== 0) { neither of those checks can ever succeed because I can find nowhere in the code that the IFF_PPROMISCx flag is set on an interface. I suggest two changes to remedy this: 1) Change IFF_PPROMISC to IFF_USERPROMISC to disambiguate the names. 2) Change if.c[1478] and if_ethersubr.c[664] to check for the correct flag, IFF_PROMISC. Or, someone can tell me that I'm wrong :-) I will send out a patch next. Later, George From owner-freebsd-net@FreeBSD.ORG Sat Sep 25 04:41:58 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2F34316A4CE for ; Sat, 25 Sep 2004 04:41:58 +0000 (GMT) Received: from zabspu.ru (mail.zabspu.ru [213.59.235.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3425343D1F for ; Sat, 25 Sep 2004 04:41:57 +0000 (GMT) (envelope-from FosteR@zabspu.ru) Received: from foster.local.zabspu.ru FosteR [172.27.1.7]NetWare via secured & encrypted transport (TLS); Sat, 25 Sep 2004 14:41:53 +1000 Date: Sat, 25 Sep 2004 14:41:49 +1000 From: "Yuri A. Mischenko" X-Mailer: The Bat! (v2.04.7) Educational Organization: ZabSPU X-Priority: 3 (Normal) Message-ID: <1748526491.20040925144149@zabspu.ru> To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-AutoSignature-Version: Novell IMS Auto Signature Agent $Revision: 1.1.1.1 $ Subject: test X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: "Yuri A. Mischenko" List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Sep 2004 04:41:58 -0000 Hi! _____________________ With best regards, Yuri A. Mischenko (aka FosteR) Systems Administrator Zabaikalye State Pedagogical University named after N. Tchernishevsky, CIT foster@zabspu.ru www.zabspu.ru tel: +7(3022) 267-462 ICQ: 1333253 ================================================================== Zabaikalye State Pedagogical University named after N. Tchernishevsky www.zabspu.ru From owner-freebsd-net@FreeBSD.ORG Sat Sep 25 07:13:06 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8AC9516A4CE for ; Sat, 25 Sep 2004 07:13:06 +0000 (GMT) Received: from mail.iinet.net.au (mail-05.iinet.net.au [203.59.3.37]) by mx1.FreeBSD.org (Postfix) with SMTP id 0FC0343D48 for ; Sat, 25 Sep 2004 07:13:04 +0000 (GMT) (envelope-from darrenr@reed.wattle.id.au) Received: (qmail 8519 invoked from network); 25 Sep 2004 07:13:02 -0000 Received: from unknown (HELO firewall.reed.wattle.id.au) (203.217.38.241) by mail.iinet.net.au with SMTP; 25 Sep 2004 07:13:01 -0000 Received: (from root@localhost) by firewall.reed.wattle.id.au (8.11.0/8.11.0) id i8P7EXT20923; Sat, 25 Sep 2004 17:14:33 +1000 (EST) From: Darren Reed Message-Id: <200409250714.RAA28547@avalon.reed.wattle.id.au> In-Reply-To: <5A076AAC-01C9-11D9-8193-000A958097E4@alum.mit.edu> To: tcpdump-workers@lists.tcpdump.org Date: Sat, 25 Sep 2004 17:14:18 +1000 (EST) X-Mailer: ELM [version 2.4ME+ PL99d (25)] MIME-Version: 1.0 cc: freebsd-net@FreeBSD.org Subject: Re: [tcpdump-workers] [PATCH] Add ioctl to disable bpf timestamping X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 25 Sep 2004 07:13:06 -0000 In some email I received from Guy Harris, sie wrote: > On Sep 8, 2004, at 2:26 AM, Bruce M Simpson wrote: > > > Here's a patch against 5.3 to add a per-instance switch which allows > > the user to specify if captured packets should be timestamped (and, > > if so, whether microtime() or the faster but less accurate > > getmicrotime() call should be used). > > This is probably a pointless optimization, as you probably relatively > rarely have multiple BPF devices bound to the same interface receiving > the bulk of the packets (as opposed to some daemon with a filter that > passes only the packets it's interested in), but would there be any > advantage to having "bpf_tap()" and "bpf_mtap()" fetch the time stamp > and pass that to "catchpacket()", so that in the case where there *is* > more than one tap, the time stamp is only fetched once? That makes sense and allows you to correllate packet time stamps from a daemon collecting packets with those you see in tcpdump output when you run that in parallel to make sure things are moving. Darren From owner-freebsd-net@FreeBSD.ORG Sat Sep 25 07:51:08 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0196316A4CE for ; Sat, 25 Sep 2004 07:51:08 +0000 (GMT) Received: from smtp06.web.de (smtp06.web.de [217.72.192.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id BAE7243D3F for ; Sat, 25 Sep 2004 07:51:07 +0000 (GMT) (envelope-from Waldemar.Kornewald@web.de) Received: from [80.134.87.206] (helo=[80.134.87.206]) by smtp06.web.de with asmtp (TLSv1:RC4-MD5:128) (WEB.DE 4.101 #44) id 1CB7Kb-0002kV-00; Sat, 25 Sep 2004 09:50:57 +0200 Message-ID: <4155230A.2000303@web.de> Date: Sat, 25 Sep 2004 09:49:30 +0200 From: Waldemar Kornewald User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Elischer , FreeBSD-net References: <41546B7F.2010009@elischer.org> In-Reply-To: <41546B7F.2010009@elischer.org> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: Waldemar.Kornewald@web.de X-Sender: Waldemar.Kornewald@web.de Subject: Re: Haiku X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 25 Sep 2004 07:51:08 -0000 Julian Elischer wrote: >>>we at the Haiku networking team are considering a port of your 5.3 >>>netstack because it is thread-safe and making the old one (4.x, I think) >>>thread-safe is probably a much bigger task. > > do you have a web page that describes what you are doing? Of course: http://www.haiku-os.org The networking team can be found under "team listing" on the right. Bye, Waldemar Kornewald From owner-freebsd-net@FreeBSD.ORG Sat Sep 25 07:55:05 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 47EB116A4CE for ; Sat, 25 Sep 2004 07:55:05 +0000 (GMT) Received: from smtp05.web.de (smtp05.web.de [217.72.192.209]) by mx1.FreeBSD.org (Postfix) with ESMTP id 09C5043D48 for ; Sat, 25 Sep 2004 07:55:05 +0000 (GMT) (envelope-from Waldemar.Kornewald@web.de) Received: from [80.134.87.206] (helo=[80.134.87.206]) by smtp05.web.de with asmtp (TLSv1:RC4-MD5:128) (WEB.DE 4.101 #44) id 1CB7OZ-00032h-00; Sat, 25 Sep 2004 09:55:04 +0200 Message-ID: <41552400.1000608@web.de> Date: Sat, 25 Sep 2004 09:53:36 +0200 From: Waldemar Kornewald User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: FreeBSD-net References: <4152A184.9020301@web.de> In-Reply-To: X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: Waldemar.Kornewald@web.de X-Sender: Waldemar.Kornewald@web.de Subject: Re: creating default route in kernel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 25 Sep 2004 07:55:05 -0000 George V. Neville-Neil wrote: >>could you please tell me how I can create a default route from within >>the kernel? I am a member of the Haiku (OS) networking team and >>maintainer of the PPP stack and for dial-on-demand support there must be >>a default route which does not work. BTW, we use a port of your netstack >>(from the 4.x releases, I think). >>Which values should the default route get (netmask, destination, etc.) >>and which function(s) should I call (our PPP stack lives in the kernel)? > > > If you look at src/sys/net/route.c you will find a function (in > -CURRENT) called rtrequest1(). Read through that routine to see how > to do an RTM_ADD. > > You will need a destination and netmask, yes. The destination for the > default route is 0 and you need to set the gateway to the correct > gateway. The normal default route works correctly. The problem is just that I cannot create an undefined default route (because one cannot know the gateway while being disconnected). Using a temporary gateway (10.10.10.1) or just 0 did not work when I tried it, but now I am in the process of changing the way dial-on-demand is handled and cannot test it. :( Maybe our port of your old netstack is buggy. I hope all problems will be gone with the new port. Bye, Waldemar From owner-freebsd-net@FreeBSD.ORG Sat Sep 25 09:35:05 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0D97616A4CE for ; Sat, 25 Sep 2004 09:35:05 +0000 (GMT) Received: from smtp05.web.de (smtp05.web.de [217.72.192.209]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE9F443D39 for ; Sat, 25 Sep 2004 09:35:04 +0000 (GMT) (envelope-from Waldemar.Kornewald@web.de) Received: from [80.134.95.235] (helo=[80.134.95.235]) by smtp05.web.de with asmtp (TLSv1:RC4-MD5:128) (WEB.DE 4.101 #44) id 1CB8xL-0006zW-00 for freebsd-net@freebsd.org; Sat, 25 Sep 2004 11:35:03 +0200 Message-ID: <41553B70.409@web.de> Date: Sat, 25 Sep 2004 11:33:36 +0200 From: Waldemar Kornewald User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: FreeBSD-net References: In-Reply-To: X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: Waldemar.Kornewald@web.de X-Sender: Waldemar.Kornewald@web.de Subject: Re: locking X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 25 Sep 2004 09:35:05 -0000 Robert Watson wrote: > There are some sections of the network stack, such as the KAME IPSEC > implementation, parts of IPv6, and some device drivers, which are not yet > completely MPSAFE. This may or may not be an issue depending on what > your requirements are. If you have any bug fixes or improvements, we > would love to hear about them -- right now our locking is fairly > coarse-grained but we'll be looking at contention issues over the next few > months to see how best to refine our locking strategy. We wanted to have fine-grained locking (BeOS/Haiku emphasizes on threading very much), but at least having some locking is better than our current situation (nearly no locking ;). Our first aim is to get a stable modularized netstack, finally. The next steps would be fine-grained locking and maybe trying out iovecs instead of mbufs. Having IPv4 ready is a good start. IPv6 is not too urgent at the moment. Bye, Waldemar Kornewald From owner-freebsd-net@FreeBSD.ORG Sat Sep 25 10:54:49 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 06C4E16A4D0 for ; Sat, 25 Sep 2004 10:54:49 +0000 (GMT) Received: from grunt1.ihug.co.nz (grunt1.ihug.co.nz [203.109.254.41]) by mx1.FreeBSD.org (Postfix) with ESMTP id 409A543D1F for ; Sat, 25 Sep 2004 10:54:48 +0000 (GMT) (envelope-from mjl@luckie.org.nz) Received: from 203-118-173-111.adsl.ihug.co.nz (lycra.luckie.org.nz) [203.118.173.111] by grunt1.ihug.co.nz with esmtp (Exim 3.35 #1 (Debian)) id 1CBACT-000180-00; Sat, 25 Sep 2004 22:54:45 +1200 Received: from 203-118-171-223.adsl.ihug.co.nz ([203.118.171.223] helo=[192.168.1.2]) by lycra.luckie.org.nz with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.42 (FreeBSD)) id 1CBACH-0002o1-Pr; Sat, 25 Sep 2004 22:54:34 +1200 Message-ID: <41554E71.3020708@luckie.org.nz> Date: Sat, 25 Sep 2004 22:54:41 +1200 From: Matthew Luckie User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040911 X-Accept-Language: en-us, en MIME-Version: 1.0 To: tcpdump-workers@lists.tcpdump.org References: <200409250714.RAA28547@avalon.reed.wattle.id.au> In-Reply-To: <200409250714.RAA28547@avalon.reed.wattle.id.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@FreeBSD.org Subject: Re: [tcpdump-workers] [PATCH] Add ioctl to disable bpf timestamping X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 25 Sep 2004 10:54:49 -0000 >>This is probably a pointless optimization, as you probably relatively >>rarely have multiple BPF devices bound to the same interface receiving >>the bulk of the packets (as opposed to some daemon with a filter that >>passes only the packets it's interested in), but would there be any >>advantage to having "bpf_tap()" and "bpf_mtap()" fetch the time stamp >>and pass that to "catchpacket()", so that in the case where there *is* >>more than one tap, the time stamp is only fetched once? > > That makes sense and allows you to correllate packet time stamps from > a daemon collecting packets with those you see in tcpdump output when > you run that in parallel to make sure things are moving. i've generated a patch to accomplish this on FreeBSD 4.10 and submitted a PR for it just a couple of weeks ago, when i noticed a small difference between the timestamp I captured in an application compared to what i saw with tcpdump. http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/71711 The motivation for this patch was to obtain something resembling the timestamp closest to when a packet I generated and transmitted hit the wire, to infer a more accurate RTT with an associated response packet. I'm not sure if what I've used BPF for in this case is 'correct' in that I've not done any real study to see how the timestamp compares to what a DAG would report. There is an argument to be made for generating the timestamp just the once after it actually passes a filter, but I've not done that in my patch. Feedback appreciated. Matthew From owner-freebsd-net@FreeBSD.ORG Sat Sep 25 11:34:51 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C7D8B16A4CE for ; Sat, 25 Sep 2004 11:34:51 +0000 (GMT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id D93E943D2F for ; Sat, 25 Sep 2004 11:34:50 +0000 (GMT) (envelope-from pekkas@netcore.fi) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i8PBYd107487; Sat, 25 Sep 2004 14:34:40 +0300 Date: Sat, 25 Sep 2004 14:34:39 +0300 (EEST) From: Pekka Savola To: snap-users@kame.net In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 cc: freebsd-net@freebsd.org Subject: Re: (KAME-snap 8794) Re: Weird memory exhaustion with FreeBSD 4.10-STABLE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 25 Sep 2004 11:34:51 -0000 On Sat, 25 Sep 2004, JINMEI Tatuya / [ISO-2022-JP] 神明達哉 wrote: > >>>>> On Fri, 24 Sep 2004 20:39:32 +0300 (EEST), > >>>>> Pekka Savola said: > > >> 1. do you see massive number of entries with "netstat -rna"? > > > Yes. > > > # netstat -nra | wc -l > > 32468 > > # > > Okay, to be sure, most of them are IPv6 routing entries, right? Yes, 99.99%. > Then please provide some additional information. > > 1. the result of netstat -rnal. A digest of the output is probably > enough, but if you could provide the entire output (on the web, for > example) it would also be helpful. Mailing to you directly off-list. > 2. how did you configure the route to the stf interface? I guess you > installed some static route for 2002::/16 to the interface. The > command line argument (or the rc.conf parameters) that made the > route and the corresponding route entry shown by netstat -rn are > both helpful. The only things I've done are, in rc.conf: stf_interface_ipv4addr="192.88.99.1" stf_interface_ipv6_ifid="::" and in rc.local: ifconfig stf0 inet6 2002:c058:6301::1741 prefixlen 16 i.e., just created the address which added the on-link route. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-freebsd-net@FreeBSD.ORG Sat Sep 25 22:00:07 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7129E16A4CF for ; Sat, 25 Sep 2004 22:00:07 +0000 (GMT) Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1964843D54 for ; Sat, 25 Sep 2004 22:00:07 +0000 (GMT) (envelope-from guy@alum.mit.edu) Received: from [192.168.0.5] (adsl-209-204-185-249.sonic.net [209.204.185.249]) by b.mail.sonic.net (8.12.11/8.12.11) with ESMTP id i8PM06mP020409 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sat, 25 Sep 2004 15:00:06 -0700 Message-ID: <4155EA65.50606@alum.mit.edu> Date: Sat, 25 Sep 2004 15:00:05 -0700 From: Guy Harris User-Agent: Mozilla Thunderbird 0.8 (Macintosh/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: tcpdump-workers@lists.tcpdump.org References: <200409250714.RAA28547@avalon.reed.wattle.id.au> <41554E71.3020708@luckie.org.nz> In-Reply-To: <41554E71.3020708@luckie.org.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@FreeBSD.org Subject: Re: [tcpdump-workers] [PATCH] Add ioctl to disable bpf timestamping X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 25 Sep 2004 22:00:07 -0000 Matthew Luckie wrote: > The motivation for this patch was to obtain something resembling the > timestamp closest to when a packet I generated and transmitted hit the > wire, to infer a more accurate RTT with an associated response packet. That's certainly a worthy goal, but the patch might not help much there - if you're getting time stamps for packets being transmitted by the machine running the BPF-based application, the time stamps you'll get are the time when the packet gets wrapped around by BPF in the driver, but there's more time spent in the CPU handing the packet to the network adapter and possibly time spent in the network adapter, especially if it has to wait for others to finish transmitting, or deal with collisions, on Ethernet, wait to get the token on a token-based network, etc.. It also wouldn't help get time stamps closer to the *received* time stamp, as it'd include time between the time when the last octet of the packet was received and when the driver handed it to BPF. On the other hand, one could perhaps argue that those times *should* be counted in RTT, if you're trying to measure application RTT rather than low-level link-layer RTT.... > There is an argument to be made for generating the timestamp just the > once after it actually passes a filter, I.e., so you don't spend CPU time generating the time stamp for packets that'll be discarded? That might be worthwhile, given that I think people have found that getting time stamps *can* be a bottleneck when capturing lots of traffic, so it might be a bottleneck if you're receiving a lot of traffic and discarding most of that traffic.