From owner-freebsd-net Sun Dec 1 16:31:48 2002 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 2EC0337B404 for ; Sun, 1 Dec 2002 16:31:47 -0800 (PST) Received: from ns1.interbgc.com (mail.interbgc.com [217.9.224.3]) by mx1.FreeBSD.org (Postfix) with SMTP id 0754243E4A for ; Sun, 1 Dec 2002 16:31:43 -0800 (PST) (envelope-from mihail.balikov@interbgc.com) Received: (qmail 50666 invoked by uid 1005); 2 Dec 2002 00:31:29 -0000 Received: from mihail.balikov@interbgc.com by keeper.interbgc.com by uid 1002 with qmail-scanner-1.14 (uvscan: v4.1.60/v4235. Clear:. Processed in 4.362414 secs); 02 Dec 2002 00:31:29 -0000 Received: from unknown (HELO misho) (217.9.231.229) by mail.interbgc.com with SMTP; 2 Dec 2002 00:31:24 -0000 Message-ID: <002401c2999a$252091e0$e5e709d9@interbgc.com> Reply-To: "Mihail Balikov" From: "Mihail Balikov" To: Subject: bug : if_nge and vlan_input_tag Date: Mon, 2 Dec 2002 02:31:24 +0200 Organization: Inter-BG-Com Ltd. MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello, Last night I have a lot of troubles with D-Link DGE-500T (nge) gigabit card with vlan subinterfaces. After some tests I found that NIC send vlan tags in network byte order , but vlan_input_tag expects them in host byte order. Is this a bug for this particular card or for whole nge driver? Can somebody make tests with other kind of nge cards? regards, Mihail To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Dec 1 17:22:50 2002 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 2791B37B401 for ; Sun, 1 Dec 2002 17:22:49 -0800 (PST) Received: from seed.net.tw (sn14.seed.net.tw [139.175.54.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 566AB43E9C for ; Sun, 1 Dec 2002 17:22:43 -0800 (PST) (envelope-from leafy@leafy.idv.tw) Received: from [61.59.152.87] (port=49186 helo=leafy.idv.tw) by seed.net.tw with esmtp (Seednet 4.10:2) id 18IfII-0007M8-00 for freebsd-net@freebsd.org; Mon, 02 Dec 2002 09:22:42 +0800 Received: from leafy.idv.tw (localhost [127.0.0.1]) by leafy.idv.tw (8.12.6/8.12.6) with ESMTP id gB21MfRD001818 for ; Mon, 2 Dec 2002 09:22:41 +0800 (CST) (envelope-from leafy@leafy.idv.tw) Received: (from leafy@localhost) by leafy.idv.tw (8.12.6/8.12.6/Submit) id gB21MfYJ001817 for freebsd-net@freebsd.org; Mon, 2 Dec 2002 09:22:41 +0800 (CST) Date: Mon, 2 Dec 2002 09:22:41 +0800 From: JY To: freebsd-net@freebsd.org Subject: [leafy@leafy.idv.tw: Kernel PPPoE problem] Message-ID: <20021202012241.GA1796@leafy.idv.tw> Mime-Version: 1.0 Content-Type: text/plain; charset=big5 Content-Disposition: inline User-Agent: Mutt/1.5.1i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org ----- Forwarded message from JY ----- Date: Mon, 2 Dec 2002 01:23:57 +0800 From: JY To: freebsd-current@FreeBSD.ORG Subject: Kernel PPPoE problem I installed mpd from ports and edited corresponding files, but when running mpd as root, the following messgae kept appearing [PPPoE] can't create pppoe peer to fxp0:,orphans: File exists The man page or the docs were not clear about what file mpd creates during runtime nor are there indications of solving such problems. What could I have missed? Thank you, JY To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message ----- End forwarded message ----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Dec 1 17:45:15 2002 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 3D87237B401 for ; Sun, 1 Dec 2002 17:45:08 -0800 (PST) Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7481143EAF for ; Sun, 1 Dec 2002 17:45:07 -0800 (PST) (envelope-from archie@dellroad.org) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id RAA62180; Sun, 1 Dec 2002 17:34:00 -0800 (PST) Received: from arch20m.dellroad.org (localhost [127.0.0.1]) by arch20m.dellroad.org (8.12.6/8.12.6) with ESMTP id gB21XdFF043729; Sun, 1 Dec 2002 17:33:39 -0800 (PST) (envelope-from archie@arch20m.dellroad.org) Received: (from archie@localhost) by arch20m.dellroad.org (8.12.6/8.12.6/Submit) id gB21XcqG043728; Sun, 1 Dec 2002 17:33:38 -0800 (PST) From: Archie Cobbs Message-Id: <200212020133.gB21XcqG043728@arch20m.dellroad.org> Subject: Re: [leafy@leafy.idv.tw: Kernel PPPoE problem] In-Reply-To: <20021202012241.GA1796@leafy.idv.tw> To: JY Date: Sun, 1 Dec 2002 17:33:38 -0800 (PST) Cc: freebsd-net@freebsd.org X-Mailer: ELM [version 2.4ME+ PL99b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org JY wrote: > I installed mpd from ports and edited corresponding files, but when running mpd as root, the following messgae kept appearing > > [PPPoE] can't create pppoe peer to fxp0:,orphans: File exists Is some other netgraph node already connected to the 'orphans' hook of fxp0: ? Are you trying to create more than one PPPOE link on the same Ethernet interface? What is the output of "ngctl ls | grep fxp0 | awk '{print $NF}'" ? If it's not zero when mpd tries to start up the link then it won't work. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Dec 2 1:15:33 2002 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 E992837B401 for ; Mon, 2 Dec 2002 01:15:31 -0800 (PST) Received: from smtp.uc3m.es (smtp01.uc3m.es [163.117.136.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id C8EAC43E88 for ; Mon, 2 Dec 2002 01:15:26 -0800 (PST) (envelope-from jrh@it.uc3m.es) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 9F2A143256 for ; Mon, 2 Dec 2002 10:15:25 +0100 (CET) Received: from itserv2.lab.it.uc3m.es (itserv2.lab.it.uc3m.es [163.117.144.121]) by smtp01.uc3m.es (Postfix) with ESMTP id 59AD099E72 for ; Mon, 2 Dec 2002 10:15:25 +0100 (CET) Received: from it.uc3m.es (zangano.it.uc3m.es [163.117.140.41]) by itserv2.lab.it.uc3m.es (8.9.3/8.9.3) with ESMTP id KAA27146 for ; Mon, 2 Dec 2002 10:15:25 +0100 Message-ID: <3DEB248E.9333E90@it.uc3m.es> Date: Mon, 02 Dec 2002 10:14:54 +0100 From: Juan Francisco Rodriguez Hervella X-Mailer: Mozilla 4.74 [es] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-net@FreeBSD.ORG Subject: Re: Sysctl and root privileges, how could I avoid them ? References: <3DE7A145.18986834@it.uc3m.es> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org JINMEI Tatuya / $B?@L@C#:H(B escribió: > > >>>>> On Fri, 29 Nov 2002 18:17:57 +0100, > >>>>> Juan Francisco Rodriguez Hervella said: > > > I'm implementing a modification in the > > file "getaddrinfo.c", which calls a sysctlbyname > > function, but the problem is that > > this sysctlbyname function call requires "root" privileges. > > > But I can not expect all the programs linked to > > libinet6 (where getaddrinfo is used) to be executed as root ! > > Perhaps your code tries the write operation of sysctl, in which case > the super user privilege is required by default. If your goal can be > achieved without a write operation, the easiest way would be to just > avoid the write. If you really need a write operation for every user, > you may probably have to reconsider the library design. Since sysctl > tends to affect fundamental behavior of kernel, the required privilege > is basically reasonable and should not be overridden as an easy > compromise. > Are you talking about the flag CTLFLAG_RW ? I'm using req->oldptr == NULL and req->newptr != NULL to add a new element into a kernel table.... and I plan to use req->oldptr & req->newptr != NULL to show the elements of the table... could I instead use CTLFLAG_RO and keep the same access to the buffers ? Excuse me because it might be a foolish question, but I don't know how these flags can affect the behaviour of the sysctl operations... Anyway, I'm going to try different options today :) Thanks! -- JFRH. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Dec 2 2: 7:35 2002 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 8C46A37B401 for ; Mon, 2 Dec 2002 02:07:34 -0800 (PST) Received: from smtp.uc3m.es (smtp03.uc3m.es [163.117.136.123]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6522243E88 for ; Mon, 2 Dec 2002 02:07:23 -0800 (PST) (envelope-from jrh@it.uc3m.es) Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 4164843181; Mon, 2 Dec 2002 11:07:22 +0100 (CET) Received: from it.uc3m.es (zangano.it.uc3m.es [163.117.140.41]) by smtp03.uc3m.es (Postfix) with ESMTP id A495C99DE4; Mon, 2 Dec 2002 11:07:21 +0100 (CET) Message-ID: <3DEB30D9.A290D483@it.uc3m.es> Date: Mon, 02 Dec 2002 11:07:21 +0100 From: Juan Francisco Rodriguez Hervella X-Mailer: Mozilla 4.74 [es] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Helge Oldach Cc: freebsd-net@FreeBSD.ORG, marcelo@it.uc3m.es Subject: Re: Multihoming - implementing RFC 1122 References: <200211282148.gASLmpas025733@sep.oldach.net> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Helge Oldach escribió: > > All, > > I wonder whether there are plans to complete implementation of the > "strong ES" model as described in RFC 1122 for multihoming hosts on > FreeBSD. Essentially this would assure that a multihomed host would > send and receive IP packets through the "correct" interface (that is, > the physical interface that is configured with the IP address used in > the packets). > I don't like the strong ES model. IMHO, with weak ES model we can obtain the best of multihoming benefits. the strong ES model makes use of source routing, which might forbid the communication where it could be possible. I don't see why a host should discard a packet for him, only because it has arrived at other interface. -- JFRH. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Dec 2 2:10:32 2002 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 8BF9037B401 for ; Mon, 2 Dec 2002 02:10:30 -0800 (PST) Received: from smtp.uc3m.es (smtp03.uc3m.es [163.117.136.123]) by mx1.FreeBSD.org (Postfix) with ESMTP id A52D343EBE for ; Mon, 2 Dec 2002 02:10:29 -0800 (PST) (envelope-from jrh@it.uc3m.es) Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id DB94B4319B for ; Mon, 2 Dec 2002 11:10:28 +0100 (CET) Received: from it.uc3m.es (zangano.it.uc3m.es [163.117.140.41]) by smtp03.uc3m.es (Postfix) with ESMTP id CC89599E30 for ; Mon, 2 Dec 2002 11:10:28 +0100 (CET) Message-ID: <3DEB3194.6C6AA674@it.uc3m.es> Date: Mon, 02 Dec 2002 11:10:28 +0100 From: Juan Francisco Rodriguez Hervella X-Mailer: Mozilla 4.74 [es] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 Cc: freebsd-net@FreeBSD.ORG Subject: Re: Sysctl and root privileges, how could I avoid them ? References: <3DE7A145.18986834@it.uc3m.es> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi: I'm thinking in implement a new system call to make my stuff... is it very difficult ? Could you point me to any guide/boot/whatever to learn about it ? Thanks again. JINMEI Tatuya / $B?@L@C#:H(B escribió: > > >>>>> On Fri, 29 Nov 2002 18:17:57 +0100, > >>>>> Juan Francisco Rodriguez Hervella said: > > > I'm implementing a modification in the > > file "getaddrinfo.c", which calls a sysctlbyname > > function, but the problem is that > > this sysctlbyname function call requires "root" privileges. > > > But I can not expect all the programs linked to > > libinet6 (where getaddrinfo is used) to be executed as root ! > > Perhaps your code tries the write operation of sysctl, in which case > the super user privilege is required by default. If your goal can be > achieved without a write operation, the easiest way would be to just > avoid the write. If you really need a write operation for every user, > you may probably have to reconsider the library design. Since sysctl > tends to affect fundamental behavior of kernel, the required privilege > is basically reasonable and should not be overridden as an easy > compromise. > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message -- JFRH. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Dec 2 2:16:40 2002 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 5F4A837B401 for ; Mon, 2 Dec 2002 02:16:39 -0800 (PST) Received: from smtp.uc3m.es (smtp03.uc3m.es [163.117.136.123]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8589743EAF for ; Mon, 2 Dec 2002 02:16:38 -0800 (PST) (envelope-from jrh@it.uc3m.es) Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id BB824432CA for ; Mon, 2 Dec 2002 11:16:37 +0100 (CET) Received: from it.uc3m.es (zangano.it.uc3m.es [163.117.140.41]) by smtp03.uc3m.es (Postfix) with ESMTP id ADBCF99DE4 for ; Mon, 2 Dec 2002 11:16:37 +0100 (CET) Message-ID: <3DEB3305.AA33364C@it.uc3m.es> Date: Mon, 02 Dec 2002 11:16:37 +0100 From: Juan Francisco Rodriguez Hervella X-Mailer: Mozilla 4.74 [es] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Any how-to/online book/guide to implement a new system call in FreeBSD ? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Thanks. -- JFRH. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Dec 2 2:23:24 2002 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 42C6E37B401 for ; Mon, 2 Dec 2002 02:23:23 -0800 (PST) Received: from itesec.hsc.fr (itesec.hsc.fr [192.70.106.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4A40943EAF for ; Mon, 2 Dec 2002 02:23:22 -0800 (PST) (envelope-from yb@sainte-barbe.org) Received: from taz.hsc.fr (ogoun.hsc.fr [192.70.106.75]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "taz.hsc.fr", Issuer "HSC CA" (verified OK)) by itesec.hsc.fr (Postfix) with ESMTP id 1B1BE20FE6 for ; Mon, 2 Dec 2002 11:23:21 +0100 (CET) Received: by taz.hsc.fr (Postfix, from userid 1000) id 24D9BFF; Mon, 2 Dec 2002 11:23:01 +0100 (CET) Date: Mon, 2 Dec 2002 11:23:01 +0100 From: Yann Berthier To: freebsd-net@FreeBSD.ORG Subject: Re: Multihoming - implementing RFC 1122 Message-ID: <20021202102301.GA63681@hsc.fr> Mail-Followup-To: freebsd-net@FreeBSD.ORG References: <200211282148.gASLmpas025733@sep.oldach.net> <3DEB30D9.A290D483@it.uc3m.es> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3DEB30D9.A290D483@it.uc3m.es> X-Organization: Herve Schauer Consultants X-Web: http://www.hsc.fr/ X-Operating-System: FreeBSD 5.0-CURRENT User-Agent: Mutt/1.5.1i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, 02 Dec 2002, Juan Francisco Rodriguez Hervella wrote: > Helge Oldach escribió: > > > > All, > > > > I wonder whether there are plans to complete implementation of the > > "strong ES" model as described in RFC 1122 for multihoming hosts on > > FreeBSD. Essentially this would assure that a multihomed host would > > send and receive IP packets through the "correct" interface (that is, > > the physical interface that is configured with the IP address used in > > the packets). > > > > I don't like the strong ES model. IMHO, with weak ES model we can > obtain the best of multihoming benefits. the strong ES model > makes use of source routing, which might forbid the communication > where it could be possible. > > I don't see why a host should discard a packet for him, only > because it has arrived at other interface. I see good reasons indeed. For example when I bind a daemon on a given IP, I have sometimes good reasons to have the multihomed host discard packets coming from the 'wrong' interface. As long as the model (strong vs weak) is tunable via a sysctl (as it is already with net.inet.ip.check_interface), I think that this is the perfect behavior: I can select whatever fits best my needs in a given situation. Cheers, - yann To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Dec 2 2:47:47 2002 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 7BB2937B401 for ; Mon, 2 Dec 2002 02:47:46 -0800 (PST) Received: from sep.oldach.net (sep.oldach.net [194.180.25.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2613043EAF for ; Mon, 2 Dec 2002 02:47:45 -0800 (PST) (envelope-from hmo@sep.oldach.net) Received: from sep.oldach.net (localhost [127.0.0.1]) by sep.oldach.net (8.12.6/8.12.6/hmo29jun02) with ESMTP id gB2Albr6065561 (version=TLSv1/SSLv3 cipher=EDH-DSS-DES-CBC3-SHA bits=168 verify=NO); Mon, 2 Dec 2002 11:47:38 +0100 (CET) (envelope-from hmo@sep.oldach.net) Received: (from hmo@localhost) by sep.oldach.net (8.12.6/8.12.6/Submit) id gB2AlbLL065560; Mon, 2 Dec 2002 11:47:37 +0100 (CET) (envelope-from hmo) Message-Id: <200212021047.gB2AlbLL065560@sep.oldach.net> Subject: Re: Multihoming - implementing RFC 1122 In-Reply-To: <3DEB30D9.A290D483@it.uc3m.es> from Juan Francisco Rodriguez Hervella at "Dec 2, 2002 11: 7:21 am" To: jrh@it.uc3m.es (Juan Francisco Rodriguez Hervella) Date: Mon, 2 Dec 2002 11:47:37 +0100 (CET) Cc: freebsdnet28nov02@oldach.net, freebsd-net@FreeBSD.ORG, marcelo@it.uc3m.es From: Helge Oldach MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Juan Francisco Rodriguez Hervella: > Helge Oldach escribió: > > I wonder whether there are plans to complete implementation of the > > "strong ES" model as described in RFC 1122 for multihoming hosts on > > FreeBSD. Essentially this would assure that a multihomed host would > > send and receive IP packets through the "correct" interface (that is, > > the physical interface that is configured with the IP address used in > > the packets). > I don't like the strong ES model. Then, don't use it. I am not asking to modify the default behaviour, I am just asking for extra functionality that you may use or not. > the strong ES model > makes use of source routing, You are mixing up source routing and policy routing. > I don't see why a host should discard a packet for him, only > because it has arrived at other interface. Anti-spoofing policies, for example. Helge To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Dec 2 5:48:45 2002 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 AC18037B401; Mon, 2 Dec 2002 05:48:43 -0800 (PST) Received: from sdf.lonestar.org (sdf.lonestar.org [207.202.214.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3BED943EC5; Mon, 2 Dec 2002 05:48:43 -0800 (PST) (envelope-from omestre@sdf.lonestar.org) Received: by sdf.lonestar.org (8.11.6+3.4W/8.11.6) id gB2DmVN20732; Mon, 2 Dec 2002 13:48:31 GMT Date: Mon, 2 Dec 2002 13:48:31 +0000 (UTC) From: omestre To: freebsd-hackers@freebsd.org Cc: freebsd-net@freebsd.org Subject: fh Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Thanks, Tim Kientzle, but i still need one "c code" to add to autoconf.c, and gets a NFS file handle to my root directory. We have the solution (diskless) with dhcp/bootp... but we do not want this anymore, due the things that i have sad before. Thanks. All that i need, is that c code... :) In vfs_syscalls.c i have found this "code": --- /* * Get (NFS) file handle */ #ifndef _SYS_SYSPROTO_H_ struct getfh_args { char *fname; fhandle_t *fhp; }; #endif int getfh(p, uap) struct proc *p; register struct getfh_args *uap; { struct nameidata nd; fhandle_t fh; register struct vnode *vp; int error; /* * Must be super user */ error = suser(p); if (error) return (error); NDINIT(&nd, LOOKUP, FOLLOW | LOCKLEAF, UIO_USERSPACE, uap->fname, p); error = namei(&nd); if (error) return (error); NDFREE(&nd, NDF_ONLY_PNBUF); vp = nd.ni_vp; bzero(&fh, sizeof(fh)); fh.fh_fsid = vp->v_mount->mnt_stat.f_fsid; error = VFS_VPTOFH(vp, &fh.fh_fid); vput(vp); if (error) return (error); error = copyout(&fh, uap->fhp, sizeof (fh)); return (error); } --- Can i adapt it for my porpouses? I need help, and i guess that here is the place... :) Somebody can help? omestre@sdf.lonestar.org SDF Public Access UNIX System - http://sdf.lonestar.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Dec 2 6:49: 8 2002 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 4067137B401 for ; Mon, 2 Dec 2002 06:49:07 -0800 (PST) Received: from mail.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id AD58C43E9C for ; Mon, 2 Dec 2002 06:49:06 -0800 (PST) (envelope-from don@sandvine.com) Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19) id ; Mon, 2 Dec 2002 09:49:05 -0500 Message-ID: From: Don Bowman To: "'freebsd-net@freebsd.org'" Subject: SO_DONTROUTE, arp's, ipfw fwd, etc Date: Mon, 2 Dec 2002 09:49:03 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I have a setup where I have a transparent proxy using ipfw fwd (to localhost). Data is sent to this device using a MAC rewrite so that packets arrive with my MAC, but the original source and destination IP. When I receive the SYN, i accept the connection, which causes an ARP to be emitted for the source address, and then the SYN/ACK. Now, I would like to have my default route not be on the 'data' interface which has the ipfw rule. It seems like this would work if: a) the MAC address for the source address (the router which sent me the packet) was entered into the ARP cache automatically when the SYN was received. b) I used SO_DONTROUTE in my proxy application. Does anybody have any comments on that? Is there a reason that learning ARP entries isn't done passively? I assume that since the receive interface is cached in the syncache, and then proxied through to the PCB, that the SO_DONTROUTE will cause the return packets to go back through that same interface? Is there a simpler way? --don (don@sandvine.com www.sandvine.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Dec 2 6:55:43 2002 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 AB76A37B401 for ; Mon, 2 Dec 2002 06:55:40 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2B08D43EB2 for ; Mon, 2 Dec 2002 06:55:40 -0800 (PST) (envelope-from larse@ISI.EDU) Received: from isi.edu (dsl-64-130-107-85.telocity.com [64.130.107.85]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id gB2EtJC08241; Mon, 2 Dec 2002 06:55:19 -0800 (PST) Message-ID: <3DEB7452.4090408@isi.edu> Date: Mon, 02 Dec 2002 06:55:14 -0800 From: Lars Eggert Organization: USC Information Sciences Institute User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2) Gecko/20021126 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Juan Francisco Rodriguez Hervella Cc: Helge Oldach , freebsd-net@FreeBSD.ORG, marcelo@it.uc3m.es Subject: Re: Multihoming - implementing RFC 1122 References: <200211282148.gASLmpas025733@sep.oldach.net> <3DEB30D9.A290D483@it.uc3m.es> In-Reply-To: <3DEB30D9.A290D483@it.uc3m.es> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010405070606030407070006" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a cryptographically signed message in MIME format. --------------ms010405070606030407070006 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Juan Francisco Rodriguez Hervella wrote: > > I don't like the strong ES model. IMHO, with weak ES model we can > obtain the best of multihoming benefits. the strong ES model > makes use of source routing, which might forbid the communication > where it could be possible. > > I don't see why a host should discard a packet for him, only > because it has arrived at other interface. Layer 2 protocols do. Layer 3 has traditionally followed the weak host model, while layer 2 protocols usually follow the strong host model. Having the option of enabling strong host for layer 3 is beneficial for layer 3 VPNs, where IP is used as both link and network protocol. Lars -- Lars Eggert USC Information Sciences Institute --------------ms010405070606030407070006 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJtjCC AzgwggKhoAMCAQICEGZFcrfMdPXPY3ZFhNAukQEwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vydmlj ZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkG CSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAw MDBaFw0wNDA4MjcyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2Vy dGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAw LjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZ gpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqd knWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYALQmJ7JRr6aFp AgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTI5NzAS BgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQAxsUtH XfkBceX1U2xdedY9mMAmE2KBIqcS+CKV6BtJtyd7BDm6/ObyJOuR+r3sDSo491BVqGz3Da1M G7wD9LXrokefbKIMWI0xQgkRbLAaadErErJAXWr5edDqLiXdiuT82w0fnQLzWtvKPPZE6iZp h39Ins6ln+eE2MliYq0FxjCCAzkwggKioAMCAQICAwglQTANBgkqhkiG9w0BAQQFADCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMB4XDTAyMDgyNDE4NTMzOVoX DTAzMDgyNDE4NTMzOVowVDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYD VQQDEwtMYXJzIEVnZ2VydDEcMBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBANI2Rrt4ggaQ/IrOsDeOm2H4/R5FRIL6JjDY3StE aogp1r23WKniQ1Vj98Nu5WxlaZ3Iam3Jen5T66H8u7rtMNpK4qAeAGoBsVeyVr1+CTFeuv+m xCh7BvBJwhLdm0zDaoDT05YKYZaqtsT+F286FWJQg31Xtf+vTKLVVrHcsafnteyal2NEt7Ac yZZfjsVLwxp2Lq3cwYfRQRoo7/yCVzS7HsgM6jmbO4taEMo4yC2rpnUbWEUCDTaCYgpAXzAl oiNk7GDh0wz2s5ZSnHRvNSBMAjCmpNtSYHfXFI1ANwrrrHIJ7Ei83+XN32PWY4OPzO3iown9 VR+vM+8lNx9OX28CAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIBBAQTTDJ1TXlmZkJO VWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEEBQADgYEAXcrIlKmPLM/r8r3oz2ZLPLaT1AyMjYTZY2qq/R7SUtFa9BNlTIFh DG78QKfJ9lo2LMzTPQqMZgNLmj95GbNPI8P8OIq2K6MeCZWz08ROackqTFP6xWbIFIfXcBVR 1dZnDDyDKBBh05KkvyTPawSQyOBUeNBfQUyO4TE+3o58U8UwggM5MIICoqADAgECAgMIJUEw DQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MDAeFw0wMjA4MjQxODUzMzlaFw0wMzA4MjQxODUzMzlaMFQxDzANBgNVBAQTBkVnZ2VydDEN MAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkqhkiG9w0BCQEWDWxh cnNlQGlzaS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDSNka7eIIGkPyK zrA3jpth+P0eRUSC+iYw2N0rRGqIKda9t1ip4kNVY/fDbuVsZWmdyGptyXp+U+uh/Lu67TDa SuKgHgBqAbFXsla9fgkxXrr/psQoewbwScIS3ZtMw2qA09OWCmGWqrbE/hdvOhViUIN9V7X/ r0yi1Vax3LGn57XsmpdjRLewHMmWX47FS8Madi6t3MGH0UEaKO/8glc0ux7IDOo5mzuLWhDK OMgtq6Z1G1hFAg02gmIKQF8wJaIjZOxg4dMM9rOWUpx0bzUgTAIwpqTbUmB31xSNQDcK66xy CexIvN/lzd9j1mODj8zt4qMJ/VUfrzPvJTcfTl9vAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIB ADAaMBgCAQQEE0wydU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVk dTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAF3KyJSpjyzP6/K96M9mSzy2k9QM jI2E2WNqqv0e0lLRWvQTZUyBYQxu/ECnyfZaNizM0z0KjGYDS5o/eRmzTyPD/DiKtiujHgmV s9PETmnJKkxT+sVmyBSH13AVUdXWZww8gygQYdOSpL8kz2sEkMjgVHjQX0FMjuExPt6OfFPF MYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MAIDCCVBMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTAyMTIwMjE0NTUxNFowIwYJKoZIhvcNAQkEMRYEFJGqmACsjKLSyJIJlMfW TgQJq6X8MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3EAQxgZ0w gZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNh cGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNl czEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCCVBMIGtBgsq hkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2Fw ZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRp ZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44 LjMwAgMIJUEwDQYJKoZIhvcNAQEBBQAEggEANzxj68tHH3KtxbNFYcuUFA6ePIL/kWGcusyV 0ZxdC/Iyptyk7sE1uBMvhL9+geQKSGXluNGELUnUGXbFlQ3iaQF0ZxNJB6P8HKQyfPhdb2PU +XD7bUToMnZKA6z5Nf8Cfwhxo2g2DHdE0lwlVy3Jl2dMMM5XjBH+XL35ufJiyiGp8tZdCVkb DySEpSMvtn7BEHVLUabLGAdlYVSMe9gjpvqO6d2aRfJ2ID3sXHVIUFTIyTBiZKWZ7LFmwFOj 6cbB4vtzRvqHVXfsKEFuN5NXuAMeV3xx+FbpsDW4ivLQsG53l20QSMUyQNe/4bVtMEGuBi5/ ZpFJ6gjwJojpyJeyxwAAAAAAAA== --------------ms010405070606030407070006-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Dec 2 7: 9: 7 2002 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 CDA4537B401 for ; Mon, 2 Dec 2002 07:08:53 -0800 (PST) Received: from aramis.rutgers.edu (aramis.rutgers.edu [128.6.4.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id AB4AC43EA9 for ; Mon, 2 Dec 2002 07:08:52 -0800 (PST) (envelope-from bohra@cs.rutgers.edu) Received: from cs.rutgers.edu (sirtaki.rutgers.edu [128.6.171.146]) by aramis.rutgers.edu (8.11.6+Sun/8.8.8) with ESMTP id gB2F8kH25315 for ; Mon, 2 Dec 2002 10:08:47 -0500 (EST) Message-ID: <3DEB76D2.1040300@cs.rutgers.edu> Date: Mon, 02 Dec 2002 10:05:54 -0500 From: Aniruddha Bohra User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: bge driver problems Content-Type: multipart/mixed; boundary="------------030103010002060901070105" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a multi-part message in MIME format. --------------030103010002060901070105 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello I have been trying to get the 3Com 996 BT gigabit network interface (bge) to work on FreeBSD 4.3 Release. I got the driver from : http://www.freebsd.org/~wpaul/Broadcom/4.x/bcm570x_drv.tar.gz I have two machines with the interfaces connected via a crossover cable and have not been able to make the devices talk to each other. They work under Linux without problem. The dmesg is attached and so is the kernel configuration and the ifconfig message. I use a modified kernel so cannot upgrade to the Stable or 4.[4-7]. It would be a big help if you could provide more information about how to get these drivers to work. I was following some discussion on the buggy card on this list - I hope things have improved since then. Please cc me on the message as I am not subscribed to this list. Thanks Aniruddha --------------030103010002060901070105 Content-Type: text/plain; name="ifconfig.1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; filename="ifconfig.1" bge0: flags=3D8802 mtu 1500 ether 00:04:76:dd:2e:bb=20 media: autoselect (100baseTX ) status: active supported media: autoselect 100baseTX 100baseTX 10baseT/UT= P 10baseT/UTP none autoselect 100baseTX 100ba= seTX 10baseT/UTP 10baseT/UTP none autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none autoselect= 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP = none autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none autoselect 100baseTX 100baseTX 10baseT/= UTP 10baseT/UTP none autoselect 100baseTX 100= baseTX 10baseT/UTP 10baseT/UTP none autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none autosele= ct 100baseTX 100baseTX 10baseT/UTP 10baseT/UT= P none autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none autoselect 100baseTX 100baseTX 10base= T/UTP 10baseT/UTP none autoselect 100baseTX 1= 00baseTX 10baseT/UTP 10baseT/UTP none autoselect 100baseTX = 100baseTX 10baseT/UTP 10baseT/UTP none autose= lect 100baseTX 100baseTX 10baseT/UTP 10baseT/= UTP none autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none autoselect 100baseTX 100baseTX 10ba= seT/UTP 10baseT/UTP none autoselect 100baseTX = 100baseTX 10baseT/UTP 10baseT/UTP none autoselect 100baseT= X 100baseTX 10baseT/UTP 10baseT/UTP none auto= select 100baseTX 100baseTX 10baseT/UTP 10base= T/UTP none autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none autoselect 100baseTX 100baseTX 10= baseT/UTP 10baseT/UTP none autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none autoselect 100bas= eTX 100baseTX 10baseT/UTP 10baseT/UTP none au= toselect 100baseTX 100baseTX 10baseT/UTP 10ba= seT/UTP none autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none autoselect 100baseTX 100baseTX = 10baseT/UTP 10baseT/UTP none autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none autoselect 100b= aseTX 100baseTX 10baseT/UTP 10baseT/UTP none = autoselect 100baseTX 100baseTX 10baseT/UTP 10= baseT/UTP none autoselect 100baseTX 100baseTX 10baseT/UTP <= full-duplex> 10baseT/UTP none autoselect 100baseTX 100baseT= X 10baseT/UTP 10baseT/UTP none 100baseTX 100b= aseTX none bge1: flags=3D8843 mtu 1500 inet 10.10.10.10 netmask 0xffffff00 broadcast 10.10.10.255 ether 00:04:76:df:ce:58=20 media: autoselect (none) status: no carrier supported media: autoselect 100baseTX 100baseTX 10baseT/UT= P 10baseT/UTP none autoselect 100baseTX 100ba= seTX 10baseT/UTP 10baseT/UTP none autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none autoselect= 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP = none autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none autoselect 100baseTX 100baseTX 10baseT/= UTP 10baseT/UTP none autoselect 100baseTX 100= baseTX 10baseT/UTP 10baseT/UTP none autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none autosele= ct 100baseTX 100baseTX 10baseT/UTP 10baseT/UT= P none autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none autoselect 100baseTX 100baseTX 10base= T/UTP 10baseT/UTP none autoselect 100baseTX 1= 00baseTX 10baseT/UTP 10baseT/UTP none autoselect 100baseTX = 100baseTX 10baseT/UTP 10baseT/UTP none autose= lect 100baseTX 100baseTX 10baseT/UTP 10baseT/= UTP none autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none autoselect 100baseTX 100baseTX 10ba= seT/UTP 10baseT/UTP none autoselect 100baseTX = 100baseTX 10baseT/UTP 10baseT/UTP none autoselect 100baseT= X 100baseTX 10baseT/UTP 10baseT/UTP none auto= select 100baseTX 100baseTX 10baseT/UTP 10base= T/UTP none autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none autoselect 100baseTX 100baseTX 10= baseT/UTP 10baseT/UTP none autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none autoselect 100bas= eTX 100baseTX 10baseT/UTP 10baseT/UTP none au= toselect 100baseTX 100baseTX 10baseT/UTP 10ba= seT/UTP none autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none autoselect 100baseTX 100baseTX = 10baseT/UTP 10baseT/UTP none autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none autoselect 100b= aseTX 100baseTX 10baseT/UTP 10baseT/UTP none = autoselect 100baseTX 100baseTX 10baseT/UTP 10= baseT/UTP none autoselect 100baseTX 100baseTX 10baseT/UTP <= full-duplex> 10baseT/UTP none autoselect 100baseTX 100baseT= X 10baseT/UTP 10baseT/UTP none 100baseTX 100b= aseTX none xl0: flags=3D8843 mtu 1500 inet 128.6.171.184 netmask 0xffffff80 broadcast 128.6.171.255 ether 00:60:08:cc:1e:94=20 media: autoselect (100baseTX ) status: active supported media: autoselect 100baseTX 100baseTX 10baseT/UT= P 10baseT/UTP 100baseTX lp0: flags=3D8810 mtu 1500 lo0: flags=3D8049 mtu 16384 inet 127.0.0.1 netmask 0xff000000=20 --------------030103010002060901070105 Content-Type: text/plain; name="kern.conf" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="kern.conf" # # GENERIC -- Generic kernel configuration file for FreeBSD/i386 # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # # http://www.FreeBSD.org/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ./LINT configuration file. If you are # in doubt as to the purpose or necessity of a line, check first in LINT. # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.246.2.24 2001/04/05 17:23:10 sos Exp $ machine i386 #cpu I386_CPU #cpu I486_CPU #cpu I586_CPU cpu I686_CPU ident M-TCP-TUNED maxusers 512 #makeoptions DEBUG=-g #Build kernel with gdb(1) debug symbols # BEGIN Florin # These options added for debugging, core dumping, instrumentation etc. makeoptions DEBUG=-g #Build kernel with gdb(1) debug symbols options DDB #Build for debug with ddb # enable KTRACE for consystency checks. See /sys/sys/systm.h options INVARIANTS options INVARIANT_SUPPORT #options MAXMEM=268435456 # MAXMEM specifies the amount of RAM on the machine; if this is not # specified, FreeBSD will first read the amount of memory from the CMOS # RAM, so the amount of memory will initially be limited to 64MB or 16MB # depending on the BIOS. If the BIOS reports 64MB, a memory probe will # then attempt to detect the installed amount of RAM. If this probe # fails to detect >64MB RAM you will have to use the MAXMEM option. # The amount is in kilobytes, so for a machine with 128MB of RAM, it would # be 131072 (128 * 1024). # See http://listserver.uk.freebsd.org/pipermail/freebsd-users/2000-December/002733.html # Increase nmbclusters for tests with Apache under stress (load generated by httperf). # Set the number of mbuf clusters to be allocated. options NMBCLUSTERS=32768 options CLK_USE_TSC_CALIBRATION # cpu freq calibration via sysctl machdep.tsc_freq # END Florin options MATH_EMULATE #Support for x87 emulation options INET #InterNETworking #options INET6 #IPv6 communications protocols options FFS #Berkeley Fast Filesystem options FFS_ROOT #FFS usable as root device [keep this!] options SOFTUPDATES #Enable FFS soft updates support options MFS #Memory Filesystem options MD_ROOT #MD is a potential root device options NFS #Network Filesystem #options NFS_ROOT #NFS usable as root device, NFS required options MSDOSFS #MSDOS Filesystem options CD9660 #ISO 9660 Filesystem options CD9660_ROOT #CD-ROM usable as root, CD9660 required options PROCFS #Process filesystem options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options SCSI_DELAY=15000 #Delay (in ms) before probing SCSI options UCONSOLE #Allow users to grab the console options USERCONFIG #boot -c editor options VISUAL_USERCONFIG #visual boot -c editor options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options P1003_1B #Posix P1003_1B real-time extensions options _KPOSIX_PRIORITY_SCHEDULING options ICMP_BANDLIM #Rate limit bad replies options KBD_INSTALL_CDEV # install a CDEV entry in /dev options EXT2FS # LATER test w/ SMP on gav # To make an SMP kernel, the next two are needed # USE ONLY ON WALTZ!!!!! #options SMP # Symmetric MultiProcessor Kernel #options APIC_IO # Symmetric (APIC) I/O device isa device eisa device pci # Floppy drives device fdc0 at isa? port IO_FD1 irq 6 drq 2 device fd0 at fdc0 drive 0 device fd1 at fdc0 drive 1 # ATA and ATAPI devices device ata0 at isa? port IO_WD1 irq 14 device ata1 at isa? port IO_WD2 irq 15 device ata device atadisk # ATA disk drives device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives #device atapist # ATAPI tape drives #options ATA_STATIC_ID #Static device numbering # SCSI Controllers #device ahb # EISA AHA1742 family device ahc # AHA2940 and onboard AIC7xxx devices #device amd # AMD 53C974 (Tekram DC-390(T)) #device isp # Qlogic family device ncr # NCR/Symbios Logic device sym # NCR/Symbios Logic (newer chipsets) #options SYM_SETUP_LP_PROBE_MAP=0x40 # Allow ncr to attach legacy NCR devices when # both sym and ncr are configured #device adv0 at isa? #device adw #device bt0 at isa? #device aha0 at isa? #device aic0 at isa? #device ncv # NCR 53C500 #device nsp # Workbit Ninja SCSI-3 #device stg # TMC 18C30/18C50 # SCSI peripherals device scbus # SCSI bus (required) device da # Direct Access (disks) #device sa # Sequential Access (tape etc) device cd # CD device pass # Passthrough device (direct SCSI access) # RAID controllers interfaced to the SCSI subsystem #device asr # DPT SmartRAID V, VI and Adaptec SCSI RAID #device dpt # DPT Smartcache - See LINT for options! #device mly # Mylex AcceleRAID/eXtremeRAID # RAID controllers #device aac # Adaptec FSA RAID, Dell PERC2/PERC3 #device ida # Compaq Smart RAID #device amr # AMI MegaRAID #device mlx # Mylex DAC960 family #device twe # 3ware Escalade # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc0 at isa? port IO_KBD device atkbd0 at atkbdc? irq 1 flags 0x1 device psm0 at atkbdc? irq 12 device vga0 at isa? # splash screen/screen saver #pseudo-device splash # syscons is the default console driver, resembling an SCO console device sc0 at isa? flags 0x100 # Enable this and PCVT_FREEBSD for pcvt vt220 compatible console driver #device vt0 at isa? #options XSERVER # support for X server on a vt console #options FAT_CURSOR # start with block cursor # If you have a ThinkPAD, uncomment this along with the rest of the PCVT lines #options PCVT_SCANSET=2 # IBM keyboards are non-std # Floating point support - do not disable. device npx0 at nexus? port IO_NPX irq 13 # Power management support (see LINT for more options) #device apm0 at nexus? disable flags 0x20 # Advanced Power Management # PCCARD (PCMCIA) support #device card #device pcic0 at isa? irq 0 port 0x3e0 iomem 0xd0000 #device pcic1 at isa? irq 0 port 0x3e2 iomem 0xd4000 disable # Serial (COM) ports device sio0 at isa? port IO_COM1 flags 0x10 irq 4 device sio1 at isa? port IO_COM2 irq 3 #device sio2 at isa? disable port IO_COM3 irq 5 #device sio3 at isa? disable port IO_COM4 irq 9 # Parallel port device ppc0 at isa? irq 7 device ppbus # Parallel port bus (required) device lpt # Printer device plip # TCP/IP over parallel device ppi # Parallel port interface device #device vpo # Requires scbus and da # PCI Ethernet NICs. device de # DEC/Intel DC21x4x (``Tulip'') device fxp # Intel EtherExpress PRO/100B (82557, 82558) device tx # SMC 9432TX (83c170 ``EPIC'') #device vx # 3Com 3c590, 3c595 (``Vortex'') #device wx # Intel Gigabit Ethernet Card (``Wiseman'') # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! device miibus # MII bus support device dc # DEC/Intel 21143 and various workalikes #device pcn # AMD Am79C79x PCI 10/100 NICs #device rl # RealTek 8129/8139 #device sf # Adaptec AIC-6915 (``Starfire'') #device sis # Silicon Integrated Systems SiS 900/SiS 7016 #device ste # Sundance ST201 (D-Link DFE-550TX) #device tl # Texas Instruments ThunderLAN #device vr # VIA Rhine, Rhine II #device wb # Winbond W89C840F device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') # ISA Ethernet NICs. #device ed0 at isa? port 0x280 irq 10 iomem 0xd8000 #device ex #device ep #device fe0 at isa? port 0x300 # Xircom Ethernet device xe # PRISM I IEEE 802.11b wireless NIC. device awi # WaveLAN/IEEE 802.11 wireless NICs. Note: the WaveLAN/IEEE really # exists only as a PCMCIA device, so there is no ISA attachment needed # and resources will always be dynamically assigned by the pccard code. #device wi # Aironet 4500/4800 802.11 wireless NICs. Note: the declaration below will # work for PCMCIA and PCI cards, as well as ISA cards set to ISA PnP # mode (the factory default). If you set the switches on your ISA # card for a manually chosen I/O address and IRQ, you must specify # those parameters here. #device an # The probe order of these is presently determined by i386/isa/isa_compat.c. #device ie0 at isa? port 0x300 irq 10 iomem 0xd0000 #device le0 at isa? port 0x300 irq 5 iomem 0xd0000 #device lnc0 at isa? port 0x280 irq 10 drq 0 #device cs0 at isa? port 0x300 #device sn0 at isa? port 0x300 irq 10 # Pseudo devices - the number indicates how many units to allocate. pseudo-device loop # Network loopback pseudo-device ether # Ethernet support #pseudo-device sl 1 # Kernel SLIP #pseudo-device ppp 1 # Kernel PPP pseudo-device tun # Packet tunnel. pseudo-device pty # Pseudo-ttys (telnet etc) pseudo-device md # Memory "disks" #pseudo-device gif 4 # IPv6 and IPv4 tunneling #pseudo-device faith 1 # IPv6-to-IPv4 relaying (translation) # The `bpf' pseudo-device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! pseudo-device bpf #Berkeley packet filter # USB support #device uhci # UHCI PCI->USB interface #device ohci # OHCI PCI->USB interface #device usb # USB Bus (required) #device ugen # Generic #device uhid # "Human Interface Devices" #device ukbd # Keyboard #device ulpt # Printer #device umass # Disks/Mass storage - Requires scbus and da #device ums # Mouse #device uscanner # Scanners # USB Ethernet, requires mii #device aue # ADMtek USB ethernet #device cue # CATC USB ethernet #device kue # Kawasaki LSI USB ethernet # audio #device pcm --------------030103010002060901070105 Content-Type: text/plain; name="dmesg.1" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="dmesg.1" FreeBSD 4.3-RELEASE #38: Mon Nov 25 19:41:55 EST 2002 root@gavotte.rutgers.edu:/usr/src/sys/compile/M-TCP-tuned Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 549845934 Hz CPU: Pentium III/Pentium III Xeon/Celeron (549.85-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x673 Stepping = 3 Features=0x383fbff real memory = 1073725440 (1048560K bytes) config> en ed0 No such device: ed0 Invalid command or syntax. Type `?' for help. config> po ed0 0x280 No such device: ed0 Invalid command or syntax. Type `?' for help. config> ir ed0 10 No such device: ed0 Invalid command or syntax. Type `?' for help. config> iom ed0 0xd8000 No such device: ed0 Invalid command or syntax. Type `?' for help. config> f ed0 0 No such device: ed0 Invalid command or syntax. Type `?' for help. config> en cs0 No such device: cs0 Invalid command or syntax. Type `?' for help. config> po cs0 0x300 No such device: cs0 Invalid command or syntax. Type `?' for help. config> ir cs0 0 No such device: cs0 Invalid command or syntax. Type `?' for help. config> f cs0 0 No such device: cs0 Invalid command or syntax. Type `?' for help. config> q avail memory = 1041272832 (1016868K bytes) Preloaded elf kernel "kernel" at 0xc0377000. Preloaded userconfig_script "/boot/kernel.conf" at 0xc037709c. Preloaded elf module "bcmphy.ko" at 0xc03770ec. Preloaded elf module "if_bge.ko" at 0xc037718c. Pentium Pro MTRR support enabled md0: Malloc disk npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard pci0: on pcib0 bge0: mem 0xc6ef0000-0xc6efffff irq 9 at device 1.0 on pci0 miibus0: on bge0 ukphy0: on miibus0 ukphy0: ukphy1: on miibus0 ukphy1: ukphy2: on miibus0 ukphy2: ukphy3: on miibus0 ukphy3: ukphy4: on miibus0 ukphy4: ukphy5: on miibus0 ukphy5: ukphy6: on miibus0 ukphy6: ukphy7: on miibus0 ukphy7: ukphy8: on miibus0 ukphy8: ukphy9: on miibus0 ukphy9: ukphy10: on miibus0 ukphy10: ukphy11: on miibus0 ukphy11: ukphy12: on miibus0 ukphy12: ukphy13: on miibus0 ukphy13: ukphy14: on miibus0 ukphy14: ukphy15: on miibus0 ukphy15: ukphy16: on miibus0 ukphy16: ukphy17: on miibus0 ukphy17: ukphy18: on miibus0 ukphy18: ukphy19: on miibus0 ukphy19: ukphy20: on miibus0 ukphy20: ukphy21: on miibus0 ukphy21: ukphy22: on miibus0 ukphy22: ukphy23: on miibus0 ukphy23: ukphy24: on miibus0 ukphy24: ukphy25: on miibus0 ukphy25: ukphy26: on miibus0 ukphy26: ukphy27: on miibus0 ukphy27: ukphy28: on miibus0 ukphy28: ukphy29: on miibus0 ukphy29: ukphy30: on miibus0 ukphy30: ukphy31: on miibus0 ukphy31: pci0: (vendor=0x135b, dev=0x0001) at 2.0 irq 11 pci0: (vendor=0x0e11, dev=0xa0f7) at 11.0 irq 3 pci0: (vendor=0x0e11, dev=0xa0f0) at 12.0 sym0: <875> port 0x2000-0x20ff mem 0xc4fb0000-0xc4fb0fff,0xc4fc0000-0xc4fc00ff irq 5 at device 13.0 on pci0 sym0: No NVRAM, ID 7, Fast-20, SE, parity checking sym1: <875> port 0x2400-0x24ff mem 0xc4f90000-0xc4f90fff,0xc4fa0000-0xc4fa00ff irq 10 at device 13.1 on pci0 sym1: No NVRAM, ID 7, Fast-20, SE, parity checking pci0: at 14.0 isab0: at device 15.0 on pci0 isa0: on isab0 atapci0: port 0x2c00-0x2c0f at device 15.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 pci0: at 15.2 chip0: port 0x1240-0x124f at device 15.3 on pci0 pcib1: at device 18.0 on pci0 pcib2: at device 20.0 on pci0 pcib4: on motherboard pci4: on pcib4 bge1: mem 0xc6ff0000-0xc6ffffff irq 15 at device 3.0 on pci4 miibus1: on bge1 ukphy32: on miibus1 ukphy32: ukphy33: on miibus1 ukphy33: ukphy34: on miibus1 ukphy34: ukphy35: on miibus1 ukphy35: ukphy36: on miibus1 ukphy36: ukphy37: on miibus1 ukphy37: ukphy38: on miibus1 ukphy38: ukphy39: on miibus1 ukphy39: ukphy40: on miibus1 ukphy40: ukphy41: on miibus1 ukphy41: ukphy42: on miibus1 ukphy42: ukphy43: on miibus1 ukphy43: ukphy44: on miibus1 ukphy44: ukphy45: on miibus1 ukphy45: ukphy46: on miibus1 ukphy46: ukphy47: on miibus1 ukphy47: ukphy48: on miibus1 ukphy48: ukphy49: on miibus1 ukphy49: ukphy50: on miibus1 ukphy50: ukphy51: on miibus1 ukphy51: ukphy52: on miibus1 ukphy52: ukphy53: on miibus1 ukphy53: ukphy54: on miibus1 ukphy54: ukphy55: on miibus1 ukphy55: ukphy56: on miibus1 ukphy56: ukphy57: on miibus1 ukphy57: ukphy58: on miibus1 ukphy58: ukphy59: on miibus1 ukphy59: ukphy60: on miibus1 ukphy60: ukphy61: on miibus1 ukphy61: ukphy62: on miibus1 ukphy62: ukphy63: on miibus1 ukphy63: xl0: <3Com 3c905-TX Fast Etherlink XL> port 0x3000-0x303f irq 15 at device 4.0 on pci4 miibus2: on xl0 nsphy0: on miibus2 nsphy0: pci4: (vendor=0x0e11, dev=0xa0f7) at 11.0 irq 3 eisa0: on motherboard mainboard0: on eisa0 slot 0 fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1: configured irq 3 not in bitmap of probed irqs 0 ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ata0-slave: ata_command: timeout waiting for intr ata0-slave: identify failed acd0: CDROM at ata0-master using PIO4 Waiting 15 seconds for SCSI devices to settle Mounting root from ufs:/dev/da1s1a da0 at sym0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers (20.000MHz, offset 16, 16bit), Tagged Queueing Enabled da0: 8678MB (17773524 512 byte sectors: 255H 63S/T 1106C) da1 at sym0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 40.000MB/s transfers (20.000MHz, offset 16, 16bit), Tagged Queueing Enabled da1: 8678MB (17773524 512 byte sectors: 255H 63S/T 1106C) link_elf: symbol splash_register undefined 4 MTCP TRACES ALLOCATED MTCP traceread enabled --------------030103010002060901070105-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Dec 2 7:56:19 2002 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 01BB137B401 for ; Mon, 2 Dec 2002 07:56:19 -0800 (PST) Received: from neo.tamu.edu (scarran.tamu.edu [165.91.252.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2E6EC43E4A for ; Mon, 2 Dec 2002 07:56:18 -0800 (PST) (envelope-from daved@tamu.edu) Received: from tamu.edu (csce-fire-1.net.tamu.edu [165.91.250.94]) by neo.tamu.edu (Switch-2.2.0/Switch-2.2.0) with ESMTP id gB2FuH913526 for ; Mon, 2 Dec 2002 09:56:17 -0600 (CST) Date: Mon, 2 Dec 2002 09:56:18 -0600 Mime-Version: 1.0 (Apple Message framework v548) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: Redundant NIC/Connections From: David J Duchscher To: freebsd-net@FreeBSD.ORG Content-Transfer-Encoding: 7bit Message-Id: <980278D4-060E-11D7-B8C7-0003930B3DA4@tamu.edu> X-Mailer: Apple Mail (2.548) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I was wondering how people are handling redundant connections? We would like to have dual NICs in the FreeBSD box with each NIC connected to a different switch. Both switches are in the same broadcast domain. In pointers, hints on this may done would be greatly appreciated. DaveD To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Dec 2 23:57:15 2002 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 424D937B401 for ; Mon, 2 Dec 2002 23:57:14 -0800 (PST) Received: from moof.catpipe.net (moof.catpipe.net [195.249.214.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 28EC343EBE for ; Mon, 2 Dec 2002 23:57:13 -0800 (PST) (envelope-from nicolai@catpipe.net) Received: from unlink.catpipe.net (unlink.catpipe.net [195.249.214.172]) by moof.catpipe.net (8.11.6/8.11.6) with ESMTP id gB37v0u18781; Tue, 3 Dec 2002 08:57:00 +0100 (CET) (envelope-from nicolai@catpipe.net) Content-Type: text/plain; charset="iso-8859-1" From: Nicolai Petri Organization: catpipe Systems ApS To: Andre Oppermann Subject: Re: DNAT on freebsd Date: Tue, 3 Dec 2002 08:57:49 +0100 User-Agent: KMail/1.4.3 References: <20021129095422.GA15876@migla.ktu.lt> <3DE761D1.F5F96F8C@pipeline.ch> In-Reply-To: <3DE761D1.F5F96F8C@pipeline.ch> Cc: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200212030857.49306.nicolai@catpipe.net> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, All. Please note that natd supports the proxy_rule command which enables some = of=20 this functionality. The only issues is the missing UDP support (which I h= ave=20 patches for locally) and the lack of rewriting urls embedded in packets. Best regards, Nicolai Petri On Friday 29 November 2002 13:47, Andre Oppermann wrote: > Nerijus Bendziunas wrote: > > Hi, > > i need to do something like DNAT in iptables on freebsd. > > I mean to rewrite packets which match some rule dst ip/port. > > ie: all smtp traffic (any 25) redirect to some ip 25. or if user trie= s > > to connect to www.yahoo.com:80 i rewrite dst and he realy connects to > > www.google.lt:80 or smth. > > We have written one which can do that: > > http://diehard.n-r-g.com/stuff/freebsd/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Dec 3 3:34:19 2002 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 9460837B404 for ; Tue, 3 Dec 2002 03:34:17 -0800 (PST) Received: from psknet.com (voyager.psknet.com [63.171.251.15]) by mx1.FreeBSD.org (Postfix) with SMTP id 430CE43E9C for ; Tue, 3 Dec 2002 03:34:16 -0800 (PST) (envelope-from troy@psknet.com) Received: (qmail 49781 invoked by uid 85); 3 Dec 2002 11:34:04 -0000 Received: from troy@psknet.com by voyager.psknet.com with qmail-scanner-1.02 (uvscan: v4.1.40/v4100. . Clean. Processed in 0.415848 secs); 03 Dec 2002 11:34:04 -0000 Received: from rad-va-20-pc-178.cablenet-va.com (HELO abyss) (24.197.20.178) by voyager.psknet.com with SMTP; 3 Dec 2002 11:34:03 -0000 From: "Troy Settle" To: "'Eric Brunner-Williams in Portland Maine'" , Cc: Subject: RE: dial-in recommendations please Date: Tue, 3 Dec 2002 06:34:03 -0500 Message-ID: <001901c29abf$e27896e0$562efea9@psknet.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <200211230347.gAN3lBjU001226@nic-naa.net> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Eric, If you're not concerned with v92, you can pick up a Max 6096 on ebay for less than $2000, or a 4048 for less than $1000. You can also get portmasters for less than $1000. If you expect to have more than a few hundred ports, you may want to look at the Max TNT, which can be had for a few grand + ~$1500 per 96 port modem card. If you want something new, check out www.patton.com. Everything I've heard about these guys is good stuff. -- Troy Settle Pulaski Networks 540.994.4254 - 866.477.5638 http://www.psknet.com > -----Original Message----- > From: owner-freebsd-isp@FreeBSD.ORG > [mailto:owner-freebsd-isp@FreeBSD.ORG] On Behalf Of Eric > Brunner-Williams in Portland Maine > Sent: Friday, November 22, 2002 10:47 PM > To: freebsd-net@FreeBSD.ORG > Cc: freebsd-isp@FreeBSD.ORG > Subject: dial-in recommendations please > > > Hi, > > I'm looking at the isp-in-my-basement problem. > > The dial-in problem is one I haven't solved-for in over ten years. > > I'd like to pick the brains of anyone who's started a small isp > recently. > > Thanks in advance, > Eric > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-isp" in the body of the message > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Dec 3 4:43:11 2002 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 C487E37B401 for ; Tue, 3 Dec 2002 04:43:09 -0800 (PST) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with SMTP id 7625143EC2 for ; Tue, 3 Dec 2002 04:43:08 -0800 (PST) (envelope-from oppermann@pipeline.ch) Received: (qmail 27606 invoked from network); 3 Dec 2002 12:42:42 -0000 Received: from unknown (HELO pipeline.ch) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 3 Dec 2002 12:42:42 -0000 Message-ID: <3DECA67E.81857BA2@pipeline.ch> Date: Tue, 03 Dec 2002 13:41:34 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Nicolai Petri Cc: freebsd-net@freebsd.org Subject: Re: DNAT on freebsd References: <20021129095422.GA15876@migla.ktu.lt> <3DE761D1.F5F96F8C@pipeline.ch> <200212030857.49306.nicolai@catpipe.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Nicolai Petri wrote: > > Hi, All. > > Please note that natd supports the proxy_rule command which enables some of Yes, but natd's current config syntax is very cumbersome and not very logical. The rewritten natd has a much cleaner and more understandable syntax more like ipfilters or pfs nat functionality. -- Andre > this functionality. The only issues is the missing UDP support (which I have > patches for locally) and the lack of rewriting urls embedded in packets. > > Best regards, > Nicolai Petri > > On Friday 29 November 2002 13:47, Andre Oppermann wrote: > > Nerijus Bendziunas wrote: > > > Hi, > > > i need to do something like DNAT in iptables on freebsd. > > > I mean to rewrite packets which match some rule dst ip/port. > > > ie: all smtp traffic (any 25) redirect to some ip 25. or if user tries > > > to connect to www.yahoo.com:80 i rewrite dst and he realy connects to > > > www.google.lt:80 or smth. > > > > We have written one which can do that: > > > > http://diehard.n-r-g.com/stuff/freebsd/ > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Dec 3 9:41:57 2002 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 CC8B137B401 for ; Tue, 3 Dec 2002 09:41:54 -0800 (PST) Received: from mordrede.visionsix.com (mordrede.visionsix.com [65.202.119.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4DED043EC5 for ; Tue, 3 Dec 2002 09:41:50 -0800 (PST) (envelope-from lists@visionsix.com) Received: from yogi (unverified [65.202.119.169]) by mordrede.visionsix.com (Vircom SMTPRS 1.4.232) with SMTP id for ; Tue, 3 Dec 2002 11:41:42 -0600 Message-ID: <00b301c29af2$c27f9720$a977ca41@yogi> From: "Lewis Watson" To: "freebsd-net" References: <005d01c297dc$6939f340$a977ca41@yogi><3DE8745D.8030201@ccrle.nec.de> <000e01c29850$ae535e20$a977ca41@yogi> <1038684192.13717.7.camel@nivomede.internal.lustygrapes.net> Subject: Re: FreeBSD Gateway Question / Problem Date: Tue, 3 Dec 2002 11:38:15 -0600 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.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Sorry for the lengthy delay and thank you all for the responses. I think the response below explains what was happening because the entire Internet could find the way to the new network, all hosts on my network could as well except for the linux machines. Once I set a static route for the linux machines they could find it too. Thanks. Lewis ----- Original Message ----- From: "Brian McDonald" To: "Lewis Watson" Sent: Saturday, November 30, 2002 1:23 PM Subject: Re: FreeBSD Gateway Question / Problem > You might check to see if the machines are using a different policy for > icmp redirects. When a gateway receives a packet destined for a network > who's next hop is on the same interface the packet came in on, it can > issue an ICMP redirect message to the sender, instructing it who the > next hop is, thus preventing the expense of having the packet traverse > the LAN twice. Some machines listen to these, but some don't, since it > can be a security problem on unsecured (border/external) networks. > > If the gateway is sending a redirect and not forwarding the packet (most > do this) and the linux box isn't accepting the redirect but the BSD and > Windows machines are, you'd see exactly the behavior you describe. You > can check the value of the sysctl net.inet.icmp.drop_redirect, which is > 0 (accept them) on my 4.7 box. If you change that to 1, and the BSD > boxes lose contact with your interior network (might take a while for > it's learned routes to disappear) then you have some good evidence. > > Unfortunately, I'm not super-up-to-date on how to check the behavior > with respect to redirects in linux, but you should be able to google > around for more information. I believe Windows listens to them by > default. > > Brian > > On Sat, 2002-11-30 at 04:13, Lewis Watson wrote: . I went > > ahead and did a route add for each linux machine (there were three) now they > > can find the new network as if nothing was wrong. I am still just really > > confused about it. Maybe they have to have a static route entered even > > though the router for the old network knows where the new network is.... I > > have tried every host over the Internet and all seem to find the new network > > hosts ok.... See below for a simple layout.... > > > > Internet --- Old Network --- New Network > > | > > | > > Another Network > > > > > > Anyways, Any other ideas? > > Thank you for your time and thoghts, > > Lewis > > > > > > > > > > Lewis Watson wrote: > > > > Hello, > > > > I am currently trying to add another /24 network to my existing network > > with > > > > a FreeBSD machine as the gateway to it. Currently, I have a /24 network > > > > connected to the Internet w/ a cisco router. I have specified to the > > cisco > > > > router that the new /24 network is connected to 192.168.0.14, which is > > the > > > > external ip address of the bsd gateway machine. The internal ip address > > for > > > > that machine is 192.168.1.1. which is what I have specified to all > > systems > > > > on > > > > the new network as the gateway. > > > > > > > > I thought I had everything exactly the way it should be, except that > > > > specifically my Linux machines on the old network cannot find the new > > > > network at all. My windows machines on the old network can find the new > > > > network. The bsd machines on the old network can find the new network. > > Other > > > > non-Linux machines on the Internet can find the new network. The > > machines on > > > > the new network can find everything but the linux machines on the old > > > > network. It appears that only Linux machines cannot figure out where the > > new > > > > network is and I am not so sure that I have set up the bsd gateway > > properly. > > > > Its only one static route that has to be added so I think that routed > > and > > > > certainly gated is overkill. > > > > > > > > Please tell me what I need other than to specify enable_gateway="YES". I > > > > have tried enable_firewall="YES" and set it to "open" but yet I still am > > > > having these problems. What do I need to add here to get this going? > > > > Thanks. > > > > Lewis To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Dec 3 14:22:26 2002 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 7312337B401; Tue, 3 Dec 2002 14:22:24 -0800 (PST) Received: from aramis.rutgers.edu (aramis.rutgers.edu [128.6.4.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id B583943EDC; Tue, 3 Dec 2002 14:22:23 -0800 (PST) (envelope-from bohra@cs.rutgers.edu) Received: from cs.rutgers.edu (sirtaki.rutgers.edu [128.6.171.146]) by aramis.rutgers.edu (8.11.6+Sun/8.8.8) with ESMTP id gB3MMHH06847; Tue, 3 Dec 2002 17:22:17 -0500 (EST) Message-ID: <3DED2DE3.7040002@cs.rutgers.edu> Date: Tue, 03 Dec 2002 17:19:15 -0500 From: Aniruddha Bohra User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net , freebsd-hackers@freebsd.org Cc: bohra@cs.rutgers.edu Subject: tcp_usrreq bug ?? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello The following code snippet is from netinet/tcp_usrreq.c As in the comment (and presumably correct behaviour) a RST should be sent on close if the connection is embryonic. However, if (tp->t_state < TCPS_ESTABLISHED) tp = tcp_close(tp); does not do it. One can imagine a scenario when a client would just do a connect() and close() and an overloaded server would have its listen queue crowded by connections that were not synchronized but closed. I have seen this happen in my lab test, where I use httperf to measure Apache webserver throughput. There are several listen queue overflows and resets. The interesting part is that the client _NEVER_ has more than 3200 open descriptors yet a queue of 4096 on the server gets filled up. Is there a reason for not sending a RST or is it a bug? Please help. Thanks Aniruddha /* * Initiate (or continue) disconnect. * If embryonic state, just send reset (once). * If in ``let data drain'' option and linger null, just drop. * Otherwise (hard), mark socket disconnecting and drop * current input data; switch states based on user close, and * send segment to peer (with FIN). */ static struct tcpcb * tcp_disconnect(tp) register struct tcpcb *tp; { struct socket *so = tp->t_inpcb->inp_socket; if (tp->t_state < TCPS_ESTABLISHED) tp = tcp_close(tp); else if ((so->so_options & SO_LINGER) && so->so_linger == 0) tp = tcp_drop(tp, 0); else { soisdisconnecting(so); sbflush(&so->so_rcv); tp = tcp_usrclosed(tp); if (tp) (void) tcp_output(tp); } return (tp); } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 4 2: 6:49 2002 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 B309237B401; Wed, 4 Dec 2002 02:06:47 -0800 (PST) Received: from falcon.mail.pas.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id 50C7F43EAF; Wed, 4 Dec 2002 02:06:47 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0040.cvx40-bradley.dialup.earthlink.net ([216.244.42.40] helo=mindspring.com) by falcon.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 18JWQM-0001Fv-00; Wed, 04 Dec 2002 02:06:35 -0800 Message-ID: <3DEDD35B.A1E7638E@mindspring.com> Date: Wed, 04 Dec 2002 02:05:15 -0800 From: Terry Lambert Reply-To: net@freebsd.org X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Tony Finch Cc: wacky@ns1.vrx.net, hackers@freebsd.org, net@freebsd.org Subject: Re: jail: multiple ip's References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Note: Cross-post and "Reply-To:" of freebsd-net! Tony Finch wrote: > wacky@ns1.vrx.net (Mike Ghunt) wrote: > > Has anyone hacked the jail code to support more than one ip? > >Would it be wise to hack at the code to add such a feature? > > Probably the best way to address this issue is to incorporate the > network stack virtualization patch, then change the jail ID from > an IPv4 address into a network stack ID. I'm really tempted to say that the network virtualization patch is special purpose, and introduces a lot of overhead that would not be there without the network virtualization patch. It's the type of thing, IMO, that should be possible for an experimenter, but not integrated into the FreeBSD kernel itself. I'm also alarmed at the mbuf header bloat, in general, for some very specific and not very common uses, including the pushing up of the full Ethernet packet. The only use I can see for that particular trick is supporting VIPs on cards in promiscuous mode, which normally would not support VIPs (e.g. the Intele Gigabit ethernet car supports 16 of them) and did not support abusing the multicast mask to obtain VIPs (e.g. the FXP driver method). Finally, with the integration of the IPSEC stuff from OpenBSD that Sam Leffler has been doing, I worry that the IPSEC implementation is not going to be fixed. Specifically, the IPSEC data is cloned per socket opened in IPv4, if IPSEC is in the kernel at all, and it bloats the per connection memory cost considerably, even if the IPSEC is never used, or the security association never varies from the default. It's all well and good to have an IPSEC axe to grind (8-)) relative to the SSL stuff, but it's not a good idea to grind it against people's memory footprint unnecessarily. Note that Sam did not introduce this problem, KAME did, with the poor IPSEC integration into IPv4 (it looks very much like an afterthought), but his addition to the code perpetuates it. There are some things it's important to integrate/fix so that they are always there, there are some things which should be optioned, and there are some things which should remain in academia, until they are standardized, forcing them on everyone. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 4 2:41:44 2002 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 AE06837B401 for ; Wed, 4 Dec 2002 02:41:42 -0800 (PST) Received: from mail.iskon.hr (inje.iskon.hr [213.191.128.16]) by mx1.FreeBSD.org (Postfix) with SMTP id 8FA5C43E4A for ; Wed, 4 Dec 2002 02:41:41 -0800 (PST) (envelope-from zec@tel.fer.hr) Received: (qmail 8372 invoked from network); 4 Dec 2002 11:41:30 +0100 Received: from zg05-208.dialin.iskon.hr (HELO tel.fer.hr) (213.191.138.209) by mail.iskon.hr with SMTP; 4 Dec 2002 11:41:30 +0100 Message-ID: <3DEDDBD5.3FEF6F04@tel.fer.hr> Date: Wed, 04 Dec 2002 11:41:25 +0100 From: Marko Zec X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Terry Lambert Cc: net@freebsd.org, Tony Finch , wacky@ns1.vrx.net, hackers@freebsd.org Subject: Re: jail: multiple ip's References: <3DEDD35B.A1E7638E@mindspring.com> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Terry Lambert wrote: > Tony Finch wrote: > > wacky@ns1.vrx.net (Mike Ghunt) wrote: > > > Has anyone hacked the jail code to support more than one ip? > > >Would it be wise to hack at the code to add such a feature? > > > > Probably the best way to address this issue is to incorporate the > > network stack virtualization patch, then change the jail ID from > > an IPv4 address into a network stack ID. > > I'm really tempted to say that the network virtualization patch > is special purpose, and introduces a lot of overhead that would > not be there without the network virtualization patch. Just the contrary, the network stack virtualization concept is mostly general-purpose oriented. The (minor) penalty of "a lot of overhead" introduced by the patch is measurable only on loopback traffic, however in practice the NIC media sets the limit on traffic throughput, so in most cases no performance degradation can be observed. Some measurement results can be found at http://www.tel.fer.hr/zec/papers/zec-bsdconeurope-2002.pdf On the other hand, I agree with you that this stuff is still in early experimental phase, but the patch has been proven to work reliably with 4.7-RELEASE as announced, with a -CURRENT version to follow soon... Marko To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 4 4:15:11 2002 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 24BD537B401; Wed, 4 Dec 2002 04:15:10 -0800 (PST) Received: from beavis.abacus.co.uk (beavis.abacus.co.uk [212.137.18.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id CCCA943EA9; Wed, 4 Dec 2002 04:15:08 -0800 (PST) (envelope-from antony@abacus.co.uk) Received: from borat.abacus.co.uk (borat.abacus.co.uk [192.168.50.32]) by beavis.abacus.co.uk (8.11.6/8.11.6) with ESMTP id gB4CF8c36778; Wed, 4 Dec 2002 12:15:08 GMT (envelope-from antony@abacus.co.uk) Received: from borat (localhost [127.0.0.1]) by borat.abacus.co.uk (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id EF4CF296B6F; Wed, 4 Dec 2002 12:14:52 +0000 (GMT) Message-ID: <3DEDF1CB.6010807@abacus.co.uk> Date: Wed, 04 Dec 2002 12:15:07 +0000 From: Antony T Curtis Organization: Abacus Group PLC (UK) User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0.1) Gecko/20020916 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-stable@freebsd.org, freebsd-net@freebsd.org Subject: Anyone know about the WANic 520 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Please CC to me replies as I am not subscribed to all the lists. SBS's Datasheet for the WANic 520 lists it having drivers for FreeBSD... Does anyone have any experience with this card and FreeBSD, eg with Netgraph, frame relay, etc. Otherwise, could people suggest other serial cards? (I have looked at the WANic 40x but I don't think 2mbps will satisfy my needs) Thanks. -- ANTONY T CURTIS Tel: +44 (1635) 36222 Abacus Polar Holdings Ltd Fax: +44 (1635) 38670 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 4 7: 4:45 2002 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 CF10337B401 for ; Wed, 4 Dec 2002 07:04:42 -0800 (PST) Received: from moebius2.Space.Net (moebius2.Space.Net [195.30.1.100]) by mx1.FreeBSD.org (Postfix) with SMTP id 8BCA543EC2 for ; Wed, 4 Dec 2002 07:04:41 -0800 (PST) (envelope-from maex@Space.Net) Received: (qmail 88060 invoked by uid 1013); 4 Dec 2002 15:04:39 -0000 Date: Wed, 4 Dec 2002 16:04:39 +0100 From: Markus Stumpf To: freebsd-net@freebsd.org Subject: FreeBSD <-> PIX IP comm problem - no ACK received Message-ID: <20021204160439.A66263@Space.Net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Organization: SpaceNet AG, Muenchen, Germany X-PGP-Fingerprint: 66 F3 75 79 01 D0 B8 5F 1A C7 77 88 4A B6 70 DF Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I have searched with google and on freebsd.org but my problem is I don't know what exactly to search for :( The machine is a FreeBSD 4.4-RELEASE #0: Fri Oct 26 23:34:42 CEST 2001 CPU: Pentium III/Pentium III Xeon/Celeron (995.68-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x686 Stepping = 6 Features=0x383fbff the nic is a fxp0: port 0x2800-0x283f mem 0xf4000000-0xf40fffff,0xf4102000-0xf4102fff irq 5 at device 14.0 on pci0 fxp0: Ethernet address 00:03:47:11:2b:ea Problem: I have an email message that is 3374 Bytes. It should be sent via SMTP to another server that is behind a PIX Firewall. The communiction gets tricky at the end of the message, because instead of CR LF "." CR LF packet N contains data CR LF "." CR and the following packet would only contain LF so far so good, but the problem is a) the PIX does never ACK packet N b) packet N+1 never gets out despite the fact that it could be sent according to the window size. I have also tried sysctl -w net.inet.tcp.newreno=0 without any changes as to the behaviour. While I think this surely is a bug in the PIX state machine / TPCI/IP stack I wonder why the FreeBSD doesn't send out the N+1 packet? The window size would be big enough AFAIK. Here's a tcpdump of such a session. The FreeBSD "hangs" sending 2107:3475 on and on because it gets no ACK und doesn't send the final packet. 14:00:36.904944 vmail.space.net.2924 > 10.0.0.1.smtp: S 424064848:424064848(0) win 16384 (DF) 14:00:36.915759 10.0.0.1.smtp > vmail.space.net.2924: S 1023758129:1023758129(0) ack 424064849 win 64240 (DF) 14:00:36.915790 vmail.space.net.2924 > 10.0.0.1.smtp: . ack 1 win 16416 (DF) 14:00:36.952765 10.0.0.1.smtp > vmail.space.net.2924: P 1:115(114) ack 1 win 64240 (DF) 14:00:36.952895 vmail.space.net.2924 > 10.0.0.1.smtp: P 1:23(22) ack 115 win 16416 (DF) 14:00:36.964287 10.0.0.1.smtp > vmail.space.net.2924: P 115:159(44) ack 23 win 64218 (DF) 14:00:36.964334 vmail.space.net.2924 > 10.0.0.1.smtp: P 23:45(22) ack 159 win 16416 (DF) 14:00:36.981656 10.0.0.1.smtp > vmail.space.net.2924: P 159:209(50) ack 45 win 64196 (DF) 14:00:36.981781 vmail.space.net.2924 > 10.0.0.1.smtp: P 45:82(37) ack 209 win 16416 (DF) 14:00:36.993773 10.0.0.1.smtp > vmail.space.net.2924: P 209:251(42) ack 82 win 64159 (DF) 14:00:36.993825 vmail.space.net.2924 > 10.0.0.1.smtp: P 82:123(41) ack 251 win 16416 (DF) 14:00:37.009846 10.0.0.1.smtp > vmail.space.net.2924: P 251:300(49) ack 123 win 64118 (DF) 14:00:37.009966 vmail.space.net.2924 > 10.0.0.1.smtp: P 123:129(6) ack 300 win 16416 (DF) 14:00:37.023160 10.0.0.1.smtp > vmail.space.net.2924: P 300:362(62) ack 129 win 64112 (DF) 14:00:37.023273 vmail.space.net.2924 > 10.0.0.1.smtp: . 129:1497(1368) ack 362 win 16416 (DF) 14:00:37.023284 vmail.space.net.2924 > 10.0.0.1.smtp: P 1497:2107(610) ack 362 win 16416 (DF) 14:00:37.023338 vmail.space.net.2924 > 10.0.0.1.smtp: . 2107:3475(1368) ack 362 win 16416 (DF) 14:00:37.046653 10.0.0.1.smtp > vmail.space.net.2924: . ack 2107 win 64240 (DF) 14:01:41.038062 vmail.space.net.2924 > 10.0.0.1.smtp: . 2107:3475(1368) ack 362 win 16416 (DF) 14:02:45.031617 vmail.space.net.2924 > 10.0.0.1.smtp: . 2107:3475(1368) ack 362 win 16416 (DF) Any ideas what goes wrong? Is there also a problem in the FreeBSD TCP/IP stack? Is it fixed in a later release or is there a chance to get it working with 4.4 ? Thanks in advance \Maex -- SpaceNet AG | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0 Research & Development | D-80807 Muenchen | Fax: +49 (89) 32356-299 "The security, stability and reliability of a computer system is reciprocally proportional to the amount of vacuity between the ears of the admin" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 4 7:12:11 2002 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 7B69C37B401 for ; Wed, 4 Dec 2002 07:12:10 -0800 (PST) Received: from skynet.stack.nl (skynet.stack.nl [131.155.140.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id BF83B43EA9 for ; Wed, 4 Dec 2002 07:12:09 -0800 (PST) (envelope-from dean@dragon.stack.nl) Received: by skynet.stack.nl (Postfix, from userid 65534) id 5DAE74018; Wed, 4 Dec 2002 16:14:12 +0100 (CET) Received: from dragon.stack.nl (dragon.stack.nl [2001:610:1108:5011:207:e9ff:fe09:230]) by skynet.stack.nl (Postfix) with ESMTP id 5E9CA4012; Wed, 4 Dec 2002 16:14:06 +0100 (CET) Received: by dragon.stack.nl (Postfix, from userid 1600) id 22D4C9895; Wed, 4 Dec 2002 16:12:02 +0100 (CET) Date: Wed, 4 Dec 2002 16:12:02 +0100 From: Dean Strik To: Markus Stumpf Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD <-> PIX IP comm problem - no ACK received Message-ID: <20021204151201.GA98370@dragon.stack.nl> References: <20021204160439.A66263@Space.Net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021204160439.A66263@Space.Net> X-Editor: VIM Rulez! http://www.vim.org/ X-MUD: Outerspace - telnet://mud.stack.nl:3333 X-Really: Yes User-Agent: Mutt/1.5.1i X-Spam-Status: No, hits=-3.3 required=8.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MUTT version=2.43 X-Spam-Level: Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Markus Stumpf wrote: > Problem: > I have an email message that is 3374 Bytes. It should be sent via SMTP > to another server that is behind a PIX Firewall. > The communiction gets tricky at the end of the message, because instead of > CR LF "." CR LF > packet N contains > data CR LF "." CR > and the following packet would only contain > LF > so far so good, but the problem is > a) the PIX does never ACK packet N > b) packet N+1 never gets out despite the fact that it could be sent > according to the window size. This is a known problem with PIXes. The solution is to either disable the PIX SMTP firewall or to upgrade the OS to at least 5.2(4) or 6.0(1). Indeed this only happens if the '.' is in one packet and the CR/LF in the next. I think Postfix has a workaround for this; don't know about other software. -- Dean C. Strik Eindhoven University of Technology dean@stack.nl | dean@ipnet6.org | http://www.ipnet6.org/ "This isn't right. This isn't even wrong." -- Wolfgang Pauli To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 4 9:47:18 2002 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 90F1A37B401; Wed, 4 Dec 2002 09:47:17 -0800 (PST) Received: from musique.teaser.net (musique.teaser.net [213.91.2.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1BD8043EB2; Wed, 4 Dec 2002 09:47:17 -0800 (PST) (envelope-from e-masson@kisoft-services.com) Received: from notbsdems.nantes.kisoft-services.com (nantes.kisoft-services.com [193.56.60.243]) by musique.teaser.net (Postfix) with ESMTP id EB28272530; Wed, 4 Dec 2002 18:47:15 +0100 (CET) Received: by notbsdems.nantes.kisoft-services.com (Postfix, from userid 1001) id 514D75ADC0; Wed, 4 Dec 2002 18:39:12 +0100 (CET) To: Mailing List FreeBSD Stable , Mailing List FreeBSD Network Subject: Cjc's Ipfilter/Bridge patch From: Eric Masson X-Operating-System: FreeBSD 4.7-STABLE i386 Date: Wed, 04 Dec 2002 18:39:11 +0100 Message-ID: <86y975znsw.fsf@notbsdems.nantes.kisoft-services.com> User-Agent: Gnus/5.090008 (Oort Gnus v0.08) XEmacs/21.4 (Common Lisp, i386--freebsd) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello, I'd like to know whether the ipf/bridge patch located at : http://people.freebsd.org/~cjc/ could be merged in the tree (-current then MFC) ? Is there any showstopper ? TIA Eric Masson -- (...) mais le niveau des eaux a été l'oeuvre de grandes vallée dut aux glissements de terrains etc. ainsi les montagnes ont été élevées par l'abaissement du terrain dut aux masses d'eau etc. -+- binji in http://www.le-gnu.net : Et Dieu créa le neuneu. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 4 10:31:20 2002 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 6829137B401; Wed, 4 Dec 2002 10:31:19 -0800 (PST) Received: from isber.ucsb.edu (research.isber.ucsb.edu [128.111.147.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 12EE443E88; Wed, 4 Dec 2002 10:31:19 -0800 (PST) (envelope-from randall@isber.ucsb.edu) Received: from localhost ([127.0.0.1] helo=research.isber.ucsb.edu) by isber.ucsb.edu with esmtp (Exim 3.36 #2) id 18JeIi-0000Tt-00; Wed, 04 Dec 2002 10:31:12 -0800 Date: Wed, 4 Dec 2002 10:31:12 -0800 (PST) From: randall ehren To: Eric Masson Cc: Mailing List FreeBSD Stable , Mailing List FreeBSD Network Subject: Re: Cjc's Ipfilter/Bridge patch In-Reply-To: <86y975znsw.fsf@notbsdems.nantes.kisoft-services.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanner: exiscan *18JeIi-0000Tt-00*Pmtd4V5R86U* (ISBER - Institute for Social, Behavioral, and Economic Research) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > I'd like to know whether the ipf/bridge patch located at : > http://people.freebsd.org/~cjc/ > > could be merged in the tree (-current then MFC) ? hasn't it been merged? root@heat[~]% uname -a FreeBSD fw.redigital.org 4.7-STABLE FreeBSD 4.7-STABLE #1: Tue Nov 26 19:42:57 PST 2002 root@fw.redigital.org:/usr/src/sys/compile/HEAT i386 root@heat[~]% sysctl -a | grep ipf | grep bridge net.link.ether.bridge_ipfw: 0 net.link.ether.bridge_ipf: 0 -randall -- :// randall s. ehren :// voice 805.893.5632 :// systems administrator :// isber|survey|avss.ucsb.edu :// institute for social, behavioral, and economic research To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 4 11: 9:25 2002 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 5719E37B404; Wed, 4 Dec 2002 11:09:23 -0800 (PST) Received: from math.teaser.net (math.teaser.net [213.91.2.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5DF2E43EA9; Wed, 4 Dec 2002 11:09:22 -0800 (PST) (envelope-from e-masson@kisoft-services.com) Received: from notbsdems.nantes.kisoft-services.com (nantes.kisoft-services.com [193.56.60.243]) by math.teaser.net (Postfix) with ESMTP id 40A296C82C; Wed, 4 Dec 2002 20:09:21 +0100 (CET) Received: by notbsdems.nantes.kisoft-services.com (Postfix, from userid 1001) id DE36D5943C; Wed, 4 Dec 2002 20:04:22 +0100 (CET) To: randall ehren Cc: Mailing List FreeBSD Stable , Mailing List FreeBSD Network Subject: Re: Cjc's Ipfilter/Bridge patch References: From: Eric Masson In-Reply-To: (randall ehren's message of "Wed, 4 Dec 2002 10:31:12 -0800 (PST)") X-Operating-System: FreeBSD 4.7-STABLE i386 Date: Wed, 04 Dec 2002 20:04:22 +0100 Message-ID: <86lm35zjux.fsf@notbsdems.nantes.kisoft-services.com> User-Agent: Gnus/5.090008 (Oort Gnus v0.08) XEmacs/21.4 (Common Lisp, i386--freebsd) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >>>>> "randall" == randall ehren writes: randall> hasn't it been merged? Can't find any trace in the cvsweb interface : http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/net/bridge.c?f=u&only_with_tag=RELENG_4&logsort=date And found the following comment in /sys/net/bridge.c #if 0 /* XXX bridge+ipfilter not yet supported in RELENG_4 */ #include /* for ipfilter */ #endif But maybe I'm wrong. Regards Eric Masson -- B > Ah ben bravo ! a quand l'html dans les entetes ? CB> Hein ? tu lis pas l'iso-8859-1 dans le champ approved ?? Elle répond. Comment veux-tu qu'en plus elle ait le temps de lire ? -+- SJ in : Les joyeuses commčres d'Usenet -+- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 4 11:32:22 2002 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 62AB137B404 for ; Wed, 4 Dec 2002 11:32:21 -0800 (PST) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7967B43E9C for ; Wed, 4 Dec 2002 11:32:20 -0800 (PST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: from khavrinen.lcs.mit.edu (localhost [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.6/8.12.6) with ESMTP id gB4JWJlI049280 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 4 Dec 2002 14:32:19 -0500 (EST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.6/8.12.6/Submit) id gB4JWJVs049277; Wed, 4 Dec 2002 14:32:19 -0500 (EST) (envelope-from wollman) Date: Wed, 4 Dec 2002 14:32:19 -0500 (EST) From: Garrett Wollman Message-Id: <200212041932.gB4JWJVs049277@khavrinen.lcs.mit.edu> To: randall ehren Cc: Mailing List FreeBSD Network Subject: Re: Cjc's Ipfilter/Bridge patch In-Reply-To: References: <86y975znsw.fsf@notbsdems.nantes.kisoft-services.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org < said: > root@heat[~]% sysctl -a | grep ipf | grep bridge > net.link.ether.bridge_ipfw: 0 > net.link.ether.bridge_ipf: 0 Grrr... Who's responsible for creating non-protocol nodes under net.link.ether? -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 4 11:40:29 2002 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 62D7437B401 for ; Wed, 4 Dec 2002 11:40:28 -0800 (PST) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id C7BDA43EAF for ; Wed, 4 Dec 2002 11:40:27 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.3/8.12.3) with ESMTP id gB4JeRTO042524; Wed, 4 Dec 2002 11:40:27 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.3/8.12.3/Submit) id gB4JeRLe042523; Wed, 4 Dec 2002 11:40:27 -0800 (PST) (envelope-from rizzo) Date: Wed, 4 Dec 2002 11:40:27 -0800 From: Luigi Rizzo To: Garrett Wollman Cc: randall ehren , Mailing List FreeBSD Network Subject: Re: Cjc's Ipfilter/Bridge patch Message-ID: <20021204114027.B42287@xorpc.icir.org> References: <86y975znsw.fsf@notbsdems.nantes.kisoft-services.com> <200212041932.gB4JWJVs049277@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200212041932.gB4JWJVs049277@khavrinen.lcs.mit.edu>; from wollman@lcs.mit.edu on Wed, Dec 04, 2002 at 02:32:19PM -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, Dec 04, 2002 at 02:32:19PM -0500, Garrett Wollman wrote: > < said: > > > root@heat[~]% sysctl -a | grep ipf | grep bridge > > net.link.ether.bridge_ipfw: 0 > > net.link.ether.bridge_ipf: 0 > > Grrr... Who's responsible for creating non-protocol nodes under > net.link.ether? that would be me. But what is a 'protocol node' and what is so upsetting in the above two sysctls ? The entire net tree contains all sort of parameters, and i would not know how to classify them. cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 4 12: 8:30 2002 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 8C0E237B404 for ; Wed, 4 Dec 2002 12:08:28 -0800 (PST) Received: from mail.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7902D43ED4 for ; Wed, 4 Dec 2002 12:08:24 -0800 (PST) (envelope-from don@sandvine.com) Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19) id ; Wed, 4 Dec 2002 15:08:16 -0500 Message-ID: From: Don Bowman To: Don Bowman , "'freebsd-net@freebsd.org'" Subject: RE: SO_DONTROUTE, arp's, ipfw fwd, etc Date: Wed, 4 Dec 2002 15:08:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > From: Don Bowman [mailto:don@sandvine.com] > I have a setup where I have a transparent proxy using ipfw fwd (to > localhost). > Data is sent to this device using a MAC rewrite so that > packets arrive with > my MAC, but the original source and destination IP. > When I receive the SYN, i accept the connection, which causes an ARP > to be emitted for the source address, and then the SYN/ACK. I didn't get much response from this, so I'm going to re-phrase. Is there any reason that I shouldn't modify the TCP passive accept so that it remembers both the MAC address of the sender, and the interface the packet came in on? By doing so, I will avoid having to issue an ARP for each incoming connection (which adds latency, and more importantly for me, breaks the ability to use ipfw 'fwd' rules the way I want). [This is with FreeBSD 4.7 if it matters]. What's happening is I have >1 router feeding me sessions which I'm transparently proxying (e.g. squid). Obviously I can't have a default route back to each of them. So I have something like: [Router1]---\ \ [Router2]--------[BSD] / [Router3]---/ This is done with a layer-2 mac rewrite, ie the router takes the packet, doesn't modify the IP header, but changes the destination MAC to be that of the BSD machine. So, e.g, a packet comes into router1 above (from somewhere on its left hand side). It may have IPsrc=1.0.0.1, IPdst=2.0.0.1. It then arrives @ the BSD machine, which will cheerfully say, yup, I'm 2.0.0.1 (using the beauty of 'ipfw fwd localhost...'). Problem is, it then wants to send a SYN/ACK, there's no route, so no where to go. I can't make the route be one of those routers, and the routing tables are too complicated to install (since there may be BGP on the left of them, etc, etc). Its important for me the response packets go back through the same path (to avoid reordering etc). The next step for me is to use a separate VLAN from each of those routers to the BSD box (so that the packets appear to come from different interfaces). I'd like to memorize the interface the packet came in, and the mac header to use, and just use that without making an enormous arp table, and going back to the place the SYN came from. Is there a reason it doesn't work this way currently (before I dive in and make changes). If I were to change it to work the way I want, would other people be interested? Would this be interesting as a whole-sale change in behaviour, or as a sysctl-changeable or #ifdef settable? Comments greatly appreciated. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 4 12:20:40 2002 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 8496D37B401; Wed, 4 Dec 2002 12:20:38 -0800 (PST) Received: from mail.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id C5A6843EC2; Wed, 4 Dec 2002 12:20:37 -0800 (PST) (envelope-from don@sandvine.com) Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19) id ; Wed, 4 Dec 2002 15:20:36 -0500 Message-ID: From: Don Bowman To: Don Bowman , "'freebsd-net@freebsd.org'" Cc: "'freebsd-stable@freebsd.org'" Subject: RE: SO_DONTROUTE, arp's, ipfw fwd, etc Date: Wed, 4 Dec 2002 15:20:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > From: Don Bowman [mailto:don@sandvine.com] > I have a setup where I have a transparent proxy using ipfw fwd (to > localhost). > Data is sent to this device using a MAC rewrite so that > packets arrive with > my MAC, but the original source and destination IP. > When I receive the SYN, i accept the connection, which causes an ARP > to be emitted for the source address, and then the SYN/ACK. I didn't get much response from this, so I'm going to re-phrase. Is there any reason that I shouldn't modify the TCP passive accept so that it remembers both the MAC address of the sender, and the interface the packet came in on? By doing so, I will avoid having to issue an ARP for each incoming connection (which adds latency, and more importantly for me, breaks the ability to use ipfw 'fwd' rules the way I want). [This is with FreeBSD 4.7 if it matters]. What's happening is I have >1 router feeding me sessions which I'm transparently proxying (e.g. squid). Obviously I can't have a default route back to each of them. So I have something like: [Router1]---\ \ [Router2]--------[BSD] / [Router3]---/ This is done with a layer-2 mac rewrite, ie the router takes the packet, doesn't modify the IP header, but changes the destination MAC to be that of the BSD machine. So, e.g, a packet comes into router1 above (from somewhere on its left hand side). It may have IPsrc=1.0.0.1, IPdst=2.0.0.1. It then arrives @ the BSD machine, which will cheerfully say, yup, I'm 2.0.0.1 (using the beauty of 'ipfw fwd localhost...'). Problem is, it then wants to send a SYN/ACK, there's no route, so no where to go. I can't make the route be one of those routers, and the routing tables are too complicated to install (since there may be BGP on the left of them, etc, etc). Its important for me the response packets go back through the same path (to avoid reordering etc). The next step for me is to use a separate VLAN from each of those routers to the BSD box (so that the packets appear to come from different interfaces). I'd like to memorize the interface the packet came in, and the mac header to use, and just use that without making an enormous arp table, and going back to the place the SYN came from. Is there a reason it doesn't work this way currently (before I dive in and make changes). If I were to change it to work the way I want, would other people be interested? Would this be interesting as a whole-sale change in behaviour, or as a sysctl-changeable or #ifdef settable? Comments greatly appreciated. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 4 12:31:21 2002 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 16E9D37B401 for ; Wed, 4 Dec 2002 12:31:20 -0800 (PST) Received: from smtpout.mac.com (A17-250-248-88.apple.com [17.250.248.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id AFF6443EBE for ; Wed, 4 Dec 2002 12:31:19 -0800 (PST) (envelope-from cswiger@mac.com) Received: from asmtp01.mac.com (asmtp01-qfe3 [10.13.10.65]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id gB4KVJxh026797 for ; Wed, 4 Dec 2002 12:31:19 -0800 (PST) Received: from bust ([12.38.161.88]) by asmtp01.mac.com (Netscape Messaging Server 4.15) with ESMTP id H6M3O600.H8R; Wed, 4 Dec 2002 12:31:18 -0800 Date: Wed, 4 Dec 2002 15:31:17 -0500 Subject: Re: SO_DONTROUTE, arp's, ipfw fwd, etc Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: "'freebsd-net@freebsd.org'" To: Don Bowman From: Chuck Swiger In-Reply-To: Message-Id: <5717ED58-07C7-11D7-A933-000A27D85A7E@mac.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wednesday, December 4, 2002, at 03:20 PM, Don Bowman wrote: > What's happening is I have >1 router feeding me sessions which > I'm transparently proxying (e.g. squid). > Obviously I can't have a default route back to each of them. > > So I have something like: > > [Router1]---\ > \ > [Router2]--------[BSD] > / > [Router3]---/ > > This is done with a layer-2 mac rewrite, ie the router takes the packet, > doesn't modify the IP header, but changes the destination MAC to > be that of the BSD machine. You can't have more than one default route, but you certainly can have several static or dynamic routes to select the appropriate router to send responses back. You could also look into policy-based routing or multihoming the connections, but I guess that depends on what you're doing. > I can't make the route be one of those routers, > and the routing tables are too complicated to install (since there > may be BGP on the left of them, etc, etc). Its important for > me the response packets go back through the same path (to avoid > reordering etc). What happens if incoming traffic comes via more than one router at a time-- how should your system decide which path to send replies back? Based on the source IP? -Chuck Chuck Swiger | chuck@codefab.com | All your packets are belong to us. -------------+-------------------+----------------------------------- "The human race's favorite method for being in control of the facts is to ignore them." -Celia Green To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 4 12:37:53 2002 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 0C36C37B401 for ; Wed, 4 Dec 2002 12:37:51 -0800 (PST) Received: from mail.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6212543EBE for ; Wed, 4 Dec 2002 12:37:50 -0800 (PST) (envelope-from don@sandvine.com) Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19) id ; Wed, 4 Dec 2002 15:37:49 -0500 Message-ID: From: Don Bowman To: 'Chuck Swiger' , Don Bowman Cc: "'freebsd-net@freebsd.org'" Subject: RE: SO_DONTROUTE, arp's, ipfw fwd, etc Date: Wed, 4 Dec 2002 15:37:44 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > -----Original Message----- > From: Chuck Swiger [mailto:cswiger@mac.com] > On Wednesday, December 4, 2002, at 03:20 PM, Don Bowman wrote: > > > What's happening is I have >1 router feeding me sessions which > > I'm transparently proxying (e.g. squid). > > Obviously I can't have a default route back to each of them. > > > > So I have something like: > > > > [Router1]---\ > > \ > > [Router2]--------[BSD] > > / > > [Router3]---/ > > > > This is done with a layer-2 mac rewrite, ie the router > takes the packet, > > doesn't modify the IP header, but changes the destination MAC to > > be that of the BSD machine. > > You can't have more than one default route, but you certainly > can have > several static or dynamic routes to select the appropriate > router to send > responses back. You could also look into policy-based routing or > multihoming the connections, but I guess that depends on what > you're doing. > > > I can't make the route be one of those routers, > > and the routing tables are too complicated to install (since there > > may be BGP on the left of them, etc, etc). Its important for > > me the response packets go back through the same path (to avoid > > reordering etc). > > What happens if incoming traffic comes via more than one router at a > time-- how should your system decide which path to send > replies back? > Based on the source IP? These are isp-sized routers (complicated networks with different peering points to other networks). Static routes don't work since they are much too dynamic. Additionally, the widget which is picking the traffic to send (like Cisco WCCP) is load-balancing, so there's another striping of data going on. I'd like to just send it back to the router it came from. I won't have a single TCP session come from more than one router, but will have the same source or destination IP come from the different routers concurrently. I'm not sure what you mean by policy-based routing. If its the same thing as on a router, then its not appropriate since it will be based on IP. In the example diagram above, I might have a case where host 'A' sends host 'B' two concurrent TCP sessions. These will both transparently arrive @ the BSD box, one via router1, one via router2. Triangulation breaks the application, so A->B(session1) needs to always flow via the same router it started on. I'm thinking this is achieved by just caching the interface & destination MAC etc in the PCB for the TCP session. It does this anyway once its finished sending the SYN/ACK, its just that it follows routing rules and ARP's for the SYN/ACK. This is a common application for e.g. Squid when being fed by more than one router. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 4 12:50:14 2002 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 66D7C37B401 for ; Wed, 4 Dec 2002 12:50:11 -0800 (PST) Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id EF09D43E9C for ; Wed, 4 Dec 2002 12:50:10 -0800 (PST) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by rwcrmhc51.attbi.com (rwcrmhc51) with ESMTP id <20021204205006051007rng6e>; Wed, 4 Dec 2002 20:50:08 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA27700; Wed, 4 Dec 2002 12:45:28 -0800 (PST) Date: Wed, 4 Dec 2002 12:45:27 -0800 (PST) From: Julian Elischer To: Don Bowman Cc: "'freebsd-net@freebsd.org'" Subject: RE: SO_DONTROUTE, arp's, ipfw fwd, etc In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, 4 Dec 2002, Don Bowman wrote: > > From: Don Bowman [mailto:don@sandvine.com] > > I have a setup where I have a transparent proxy using ipfw fwd (to > > localhost). > > Data is sent to this device using a MAC rewrite so that > > packets arrive with > > my MAC, but the original source and destination IP. > > When I receive the SYN, i accept the connection, which causes an ARP > > to be emitted for the source address, and then the SYN/ACK. > > I didn't get much response from this, so I'm going to re-phrase. > > Is there any reason that I shouldn't modify the TCP passive accept > so that it remembers both the MAC address of the sender, and the > interface the packet came in on? By doing so, I will avoid > having to issue an ARP for each incoming connection (which adds > latency, and more importantly for me, breaks the ability to use > ipfw 'fwd' rules the way I want). [This is with FreeBSD 4.7 if > it matters]. > The arp is issued because the TCP stack is responding to the SYN packet with it's own SYN, but it doesn't have a route to the origianal source, so it creates one, as it's local. this means that it allocates an ARP entry for it which in turn causes an arp request to be sent. The response will result in the SYN being transmitted. This is all pretty normal. there will not be another ARP sent for 18 minutes for that host.. thw question is.. Why does it think the source is local? are the routers below doing proxy arp? Did you give your interface a netmask of 0,0.0.0? Who responds to the arp? > What's happening is I have >1 router feeding me sessions which > I'm transparently proxying (e.g. squid). > Obviously I can't have a default route back to each of them. > > So I have something like: > > [Router1]---\ > \ > [Router2]--------[BSD] > / > [Router3]---/ > > This is done with a layer-2 mac rewrite, ie the router takes the packet, > doesn't modify the IP header, but changes the destination MAC to > be that of the BSD machine. yes the ipfw fwd command does the same thing if you were using a freeBSD box as such a router. (it sends the packet on with a different MAC header) (if you were not using localhost as the destination of the fwd. > > So, e.g, a packet comes into router1 above (from somewhere on its > left hand side). It may have IPsrc=1.0.0.1, IPdst=2.0.0.1. > It then arrives @ the BSD machine, which will cheerfully say, yup, > I'm 2.0.0.1 (using the beauty of 'ipfw fwd localhost...'). > Problem is, it then wants to send a SYN/ACK, there's no route, > so no where to go. I can't make the route be one of those routers, > and the routing tables are too complicated to install (since there > may be BGP on the left of them, etc, etc). Its important for > me the response packets go back through the same path (to avoid > reordering etc). if there is bgp to the left, you could make this machine take part.. do the routers do bgp? You COULD write a netgraph node that adds routes as it receives packets in fact it could keep it's own cache of IP/MAC mappings and switch the MACs appropriatly on outgoing packets. Possibly adding routes would be best. It would identify the source from the src mac address, and add add the appropriate entry to the routing table. a bit like a learning bridge. > > The next step for me is to use a separate VLAN from each of those > routers to the BSD box (so that the packets appear to come from different > interfaces). I'd like to memorize the interface the packet came in, > and the mac header to use, and just use that without making an enormous > arp table, and going back to the place the SYN came from. You could use divert sockets for this.. as the packets arrive they are diverted up.. part of the info a divert socket provides is the receiving interface. A divert daemon cound examine the packet and add teh appropriate route into the routing table, depending on the incoming interface. (just ideas). > > Is there a reason it doesn't work this way currently (before I dive > in and make changes). I'm not sure what you mean.. Is there a reason that return routes are not added every time a packet is received? Well, yes. For a start it may not be what everyone wants. I have made great use of asymetrical routing many times (e.g. some satelite internet connections are via modem for outgoing and via the satelite for incoming.) > If I were to change it to work the way I want, would other people > be interested? > Would this be interesting as a whole-sale change in behaviour, or as > a sysctl-changeable or #ifdef settable? I think you could do what you want without modifying the current system. Either by packet rewriting using a netgraph module, or by adaptively modifying the routing tables, either from the kernel, or from userland. > > Comments greatly appreciated. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 4 13: 3:32 2002 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 4D0C137B401 for ; Wed, 4 Dec 2002 13:03:30 -0800 (PST) Received: from mail.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 78C8043EAF for ; Wed, 4 Dec 2002 13:03:29 -0800 (PST) (envelope-from don@sandvine.com) Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19) id ; Wed, 4 Dec 2002 16:03:29 -0500 Message-ID: From: Don Bowman To: 'Julian Elischer' , Don Bowman Cc: "'freebsd-net@freebsd.org'" Subject: RE: SO_DONTROUTE, arp's, ipfw fwd, etc Date: Wed, 4 Dec 2002 16:03:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org From: Julian Elischer [mailto:julian@elischer.org] > The arp is issued because the TCP stack is responding to the > SYN packet with it's own SYN, but it doesn't have a route to the > origianal source, so it creates one, as it's local. this means that it > allocates an ARP entry for it which in turn causes an arp > request to be sent. The response will result in the SYN being > transmitted. This is all pretty normal. there will not be another > ARP sent for 18 minutes for that host.. thw question is.. > > Why does it think the source is local? are the routers below > doing proxy > arp? Did you give your interface a netmask of 0,0.0.0? > > Who responds to the arp? Its a layer-2 MAC rewrite, so it arrives on a local segment, but subnetting rules don't apply. No-one responds to the ARP, hence my problem :) I know what its doing now is normal, its just that it doesn't work in my configuration (which isn't typical). The interface in question has no IP or netmask (or at least, i would like it to not have one, its not needed). >You COULD write a netgraph node that adds routes as it receives packets >in fact it could keep it's own cache of IP/MAC mappings >and switch the MACs appropriatly on outgoing packets. >Possibly adding routes would be best. >It would identify the source from the src mac address, and >add add the appropriate entry to the routing table. >a bit like a learning bridge. I'm not sure I can write a route-rule for a connection since I could have a different path back to the same IP for a different TCP connection. Thus my idea just to let the PCB take care of it. >if there is bgp to the left, you could make this machine take part.. >do the routers do bgp? Not in all cases :( >Is there a reason that return routes are not added every time >a packet is received? Well, yes. For a start it may not be what everyone >wants. I have made great use of asymetrical routing many times >(e.g. some satelite internet connections are via modem for outgoing >and via the satelite for incoming.) OK, I understand. So if I make this change, it would only be useful if it were not the default / disableable. Perhaps it would be a socket option on the listen() socket... Similar to the SO_DONTROUTE I guess. Maybe that is what SO_DONTROUTE should mean for listen()? This is only an issue for passively accepted connections. This issue comes about due to the way WCCP works with its hashing buckets and with multiple routers feeding multiple caching servers: the routers load balance across caches (so each will distribute the sources addresses on its left to more than one cache). --don (don@sandvine.com www.sandvine.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 4 13:17:10 2002 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 1726937B401 for ; Wed, 4 Dec 2002 13:17:08 -0800 (PST) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9237043E4A for ; Wed, 4 Dec 2002 13:17:07 -0800 (PST) (envelope-from cswiger@mac.com) Received: from asmtp01.mac.com (asmtp01-qfe3 [10.13.10.65]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id gB4LH7Zu019333 for ; Wed, 4 Dec 2002 13:17:07 -0800 (PST) Received: from bust ([12.38.161.88]) by asmtp01.mac.com (Netscape Messaging Server 4.15) with ESMTP id H6M5SI00.RB2; Wed, 4 Dec 2002 13:17:06 -0800 Date: Wed, 4 Dec 2002 16:16:44 -0500 Subject: Re: SO_DONTROUTE, arp's, ipfw fwd, etc Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: "'freebsd-net@freebsd.org'" To: Don Bowman From: Chuck Swiger In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wednesday, December 4, 2002, at 03:37 PM, Don Bowman wrote: [ ... ] > These are isp-sized routers (complicated networks with different > peering points to other networks). Static routes don't work since > they are much too dynamic. Additionally, the widget which is > picking the traffic to send (like Cisco WCCP) is load-balancing, > so there's another striping of data going on. Yes, but the complicated internal routes maintained within those networks isn't your problem if your machine or network isn't BGP peering with them. > I'd like to just send it back to the router it came from. > I won't have a single TCP session come from more than one router, > but will have the same source or destination IP come from the different > routers concurrently. So these routers are multihomed in practice? > I'm not sure what you mean by policy-based routing. If its the same > thing as on a router, then its not appropriate since it will be > based on IP. Huh? Determining which network interface to send a packet is exactly what a layer-3 router _does_...it uses the IP address to decide how to route the packet. Anyway, I meant things like dynamic routing protocols (RIP, RIPv2, OSPF, BGP, etc) via something like gated. > In the example diagram above, I might have a case where host 'A' > sends host 'B' two concurrent TCP sessions. These will both transparently > arrive @ the BSD box, one via router1, one via router2. Triangulation > breaks the application, so A->B(session1) needs to always flow via > the same router it started on. Why? This sounds like a pretty classic example of A being on a multihomed network, and you should let IP-level routing deal with the problem. But there are alternatives, I guess-- maybe try putting a buncha interfaces on the BSD box, one for each router being connected to it, and put each pair on their own /30. That way, the BSD box can quite easily return the traffic back to the originating router.... > I'm thinking this is achieved by just caching the interface & destination > MAC etc in the PCB for the TCP session. It does this anyway once its > finished sending the SYN/ACK, its just that it follows routing rules and > ARP's for the SYN/ACK. Yes. Pretending machines which are on remote networks are local can be done by re-writing MAC addresses, but that can be achieved by NAT or VPN solutions as well. Why are you trying to override normal routing behavior when you probably can use it to help solve the problem? -Chuck Chuck Swiger | chuck@codefab.com | All your packets are belong to us. -------------+-------------------+----------------------------------- "The human race's favorite method for being in control of the facts is to ignore them." -Celia Green To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 4 13:55: 9 2002 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 2428837B401 for ; Wed, 4 Dec 2002 13:55:07 -0800 (PST) Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id BB1AC43EBE for ; Wed, 4 Dec 2002 13:55:06 -0800 (PST) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by rwcrmhc51.attbi.com (rwcrmhc51) with ESMTP id <20021204215506051007sgvle>; Wed, 4 Dec 2002 21:55:06 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id NAA28208; Wed, 4 Dec 2002 13:50:21 -0800 (PST) Date: Wed, 4 Dec 2002 13:50:20 -0800 (PST) From: Julian Elischer To: Don Bowman Cc: "'freebsd-net@freebsd.org'" Subject: RE: SO_DONTROUTE, arp's, ipfw fwd, etc In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, 4 Dec 2002, Don Bowman wrote: > > Why does it think the source is local? are the routers below > > doing proxy > > arp? Did you give your interface a netmask of 0,0.0.0? > > > > Who responds to the arp? > > Its a layer-2 MAC rewrite, so it arrives on a local segment, but > subnetting rules don't apply. > No-one responds to the ARP, hence my problem :) Someone must be responding, because the SYN is eventually sent. > > I know what its doing now is normal, its just that it doesn't work > in my configuration (which isn't typical). > > The interface in question has no IP or netmask (or at least, i would > like it to not have one, its not needed). It could have no IP address. Just ifconfig fxp0 up without giving it one.. however IP will refuse to send a packet out that interface. Well maybe.. hmm you could add the default route to be out that interface route add default -face fxp0 but that would still require an ARP because there is no place for the code to get the MAC address from, and an ARP requires a return address. I'm definitly missing some part of the picture here. It works now, but you have extra arps. HOW does it work? Where does it get the destination MAC address from? Here's my suggestion: write a netgraph node that does all the MAC rewriting. Code from the ng_bridge node would be useful. attach it to a ng_iface node. make the netgraph iface the default route. (route add default -iface ng0) basically if has two hooks. On e to attach to the ethernet interface, and one for the ng_iface node that exports ng0. Information gleaned from the incoming packets is used to send out the outgoing packets. Not a very hard node to write but rather specialised. :-) You wouldn't have to touch any General code.. it would be entirely contained within your node. Basically it would look to the system as if you have a point-to-point link to somewhere that is your default route. you send in IP packets and they magically come out the ethernet interface with the correct MAC header on the front. If you startd with the bridge node as a start you could handle having multiple interfaces. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 4 14:21:13 2002 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 C324F37B407 for ; Wed, 4 Dec 2002 14:21:11 -0800 (PST) Received: from mail.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2146443EC5 for ; Wed, 4 Dec 2002 14:21:11 -0800 (PST) (envelope-from don@sandvine.com) Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19) id ; Wed, 4 Dec 2002 17:21:09 -0500 Message-ID: From: Don Bowman To: 'Julian Elischer' , Don Bowman Cc: "'freebsd-net@freebsd.org'" Subject: RE: SO_DONTROUTE, arp's, ipfw fwd, etc Date: Wed, 4 Dec 2002 17:21:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > From: Julian Elischer [mailto:julian@elischer.org] > On Wed, 4 Dec 2002, Don Bowman wrote: > > > Why does it think the source is local? are the routers below > > > doing proxy > > > arp? Did you give your interface a netmask of 0,0.0.0? > > > > > > Who responds to the arp? > > > > Its a layer-2 MAC rewrite, so it arrives on a local segment, but > > subnetting rules don't apply. > > No-one responds to the ARP, hence my problem :) > > Someone must be responding, because the SYN is eventually sent. Ah, its working currently with a single router. Adding the 2nd router is breaking it. I currently have a default route back to the first router. Adding the 2nd router, the back-path always goes through the first router, which gets confused. (I'm using the term router, but its actually a content switching device operating @ layer 4, like cisco WCCP or Cisco CSM or nortel Alteon). > Here's my suggestion: > > write a netgraph node that does all the MAC rewriting. > Code from the ng_bridge node would be useful. > attach it to a ng_iface node. > make the netgraph iface the default route. > (route add default -iface ng0) Let me chew on that for a bit. I'm not sure where it would get the destination mac from, wouldn't it have to cache the information the PCB is holding? Wouldn't it be more efficient for me to just create the ether-header when the SYN comes in, store it in the PCB, and use that on each outgoing packet for that tcp connection, add a sockopt (or use SO_DONTROUTE for this on the listen socket)? Thanks for the great suggestions, keep them coming :) --don (don@sandvine.com www.sandvine.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 4 14:34: 4 2002 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 4789B37B401 for ; Wed, 4 Dec 2002 14:34:01 -0800 (PST) Received: from mail.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8E15043EA9 for ; Wed, 4 Dec 2002 14:34:00 -0800 (PST) (envelope-from don@sandvine.com) Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19) id ; Wed, 4 Dec 2002 17:33:59 -0500 Message-ID: From: Don Bowman To: 'Chuck Swiger' , Don Bowman Cc: "'freebsd-net@freebsd.org'" Subject: RE: SO_DONTROUTE, arp's, ipfw fwd, etc Date: Wed, 4 Dec 2002 17:33:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > From: Chuck Swiger [mailto:cswiger@mac.com] > On Wednesday, December 4, 2002, at 03:37 PM, Don Bowman wrote: > [ ... ] > > These are isp-sized routers (complicated networks with different > > peering points to other networks). Static routes don't work since > > they are much too dynamic. Additionally, the widget which is > > picking the traffic to send (like Cisco WCCP) is load-balancing, > > so there's another striping of data going on. > > Yes, but the complicated internal routes maintained within > those networks > isn't your problem if your machine or network isn't BGP > peering with them. It is in the sense that I have to figure out which one to send data back to. More than one of them may 'own' a source address at a given time (for a TCP session). > > > In the example diagram above, I might have a case where host 'A' > > sends host 'B' two concurrent TCP sessions. These will both > transparently > > arrive @ the BSD box, one via router1, one via router2. > Triangulation > > breaks the application, so A->B(session1) needs to always flow via > > the same router it started on. > > Why? This sounds like a pretty classic example of A being on > a multihomed > network, and you should let IP-level routing deal with the > problem. But > there are alternatives, I guess-- maybe try putting a buncha > interfaces on > the BSD box, one for each router being connected to it, and > put each pair > on their own /30. That way, the BSD box can quite easily return the > traffic back to the originating router.... Only if its routing, not for L2 redirection. > > > I'm thinking this is achieved by just caching the interface > & destination > > MAC etc in the PCB for the TCP session. It does this anyway once its > > finished sending the SYN/ACK, its just that it follows > routing rules and > > ARP's for the SYN/ACK. > > Yes. Pretending machines which are on remote networks are > local can be > done by re-writing MAC addresses, but that can be achieved by > NAT or VPN > solutions as well. Why are you trying to override normal > routing behavior > when you probably can use it to help solve the problem? This is a transparent proxy. The proxy needs to know where the real destination was (in case it needs to open a connection there). The HTTP protocol solved this by putting the real-ip address in the header, but most other protocols didn't. I don't have control of the content switching routers which feeds this. They work the way they do. Say for the sake of example you wished to load balance 2 farms of telnet servers. You had a device which picked off port 23, and sent it to you without alterations. You would then look @ the intended destination address, and pick the right group of telnet servers, and send the data there. Now say that those devices themselves where load-balanced. So if a user telneted twice to the same destination, one path might go through the first redirector, and one through the 2nd. The path back is based on the path it came in. [client] | -------------------------- | Load Balancer | -------------------------- | | | | [Redirector1] [Redirector2] \ / \ / --------------------- | | [BSD1] [BSD2] | | ----------------------------- | | | | | | | | | | Telnet servers(A) Telnet (B) So in this case, [client] sends a SYN to port 23 on the virtual address of telnet(A). The load balancer sends this (and all other traffic) aribtrarily to Redirector1 or 2. These devices say, Aha!, port 23, let me use this clever policy based route, and just rewrite the destination MAC to be either BSD1 or BSD2 (based on some feedback on their load, availability, etc). BSD1 and 2 have a rule like: ipfw fwd localhost,9000 tcp from any to any recv bge0 23 and then on localhost:9000 have listening a clever little app that does: accept(), look @ intended destination IP, pick a telnet server in the farm it so addresses, connect, and then proxy the accepted() connection to the actively initiated one. Now, BSD1 / 2 can't use Redirector1/2 as a default route, since they will be treating them as equals. One of them sent the SYN packet, I'd love the SYN/ACK to go back to the same one. I know the MAC it came from, that's where the response should go. Making it all layer 3 doesn't help me, then I don't have the intended destination address. Additionally I have the problem that if I have two routers on my net, and one sends me traffic, I can only respond to it if its my default route, or if I have a static route for an IP behind it. Maybe those routers both lead to the same locations? I can't really use a VPN (GRE etc) tunnel since then I'll have to fragment, and I'd prefer to avoid that. My first thought was to create a GRE tunnel from Redirect(1,2) to BSD(1,2), and send the data down the tunnel with the original info intact. Sadly, this extra 24-bytes of overhead costs performance in adding/deleting, I lose the hardware assist I have for IP/TCP checksum offload, and the intervening devices don't support jumbo frames so I have to double the number of packets, sending a 1500 and then a 24 byte frame. Thanks for the input, keep it coming! Talk me down from this ledge :) --don (don@sandvine.com www.sandvine.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 4 14:55:10 2002 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 8096A37B401 for ; Wed, 4 Dec 2002 14:55:08 -0800 (PST) Received: from sccrmhc01.attbi.com (sccrmhc01.attbi.com [204.127.202.61]) by mx1.FreeBSD.org (Postfix) with ESMTP id E2CE243E9C for ; Wed, 4 Dec 2002 14:55:07 -0800 (PST) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by sccrmhc01.attbi.com (sccrmhc01) with ESMTP id <2002120422550600100rnfode>; Wed, 4 Dec 2002 22:55:07 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id OAA28672; Wed, 4 Dec 2002 14:51:28 -0800 (PST) Date: Wed, 4 Dec 2002 14:51:27 -0800 (PST) From: Julian Elischer To: Don Bowman Cc: "'freebsd-net@freebsd.org'" Subject: RE: SO_DONTROUTE, arp's, ipfw fwd, etc In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, 4 Dec 2002, Don Bowman wrote: > > From: Julian Elischer [mailto:julian@elischer.org] > > On Wed, 4 Dec 2002, Don Bowman wrote: > > > > Why does it think the source is local? are the routers below > > > > doing proxy > > > > arp? Did you give your interface a netmask of 0,0.0.0? > > > > > > > > Who responds to the arp? > > > > > > Its a layer-2 MAC rewrite, so it arrives on a local segment, but > > > subnetting rules don't apply. > > > No-one responds to the ARP, hence my problem :) > > > > Someone must be responding, because the SYN is eventually sent. > > Ah, its working currently with a single router. Adding the 2nd router > is breaking it. I currently have a default route back to the first > router. Adding the 2nd router, the back-path always goes through > the first router, which gets confused. (I'm using the term router, > but its actually a content switching device operating @ layer 4, > like cisco WCCP or Cisco CSM or nortel Alteon). > > > Here's my suggestion: > > > > write a netgraph node that does all the MAC rewriting. > > Code from the ng_bridge node would be useful. > > attach it to a ng_iface node. > > make the netgraph iface the default route. > > (route add default -iface ng0) > > Let me chew on that for a bit. I'm not sure where it would get the > destination mac from, wouldn't it have to cache the information > the PCB is holding? It gets the destination MAC address from the SRC AMC field of the preceding incoming packets with that IP src, dst and port combination.... i.e. the node would look within the IP header. > Wouldn't it be more efficient for me to > just create the ether-header when the SYN comes in, store it > in the PCB, and use that on each outgoing packet for that tcp > connection, add a sockopt (or use SO_DONTROUTE for this on the > listen socket)? yes and no... you would be breaking the layering in the standard code and you'd get crucified for it. start with the ng_bridge node and make it look within the IP header and use that information in it's hash tables instead of MAC addresses. It'll need some hosekeeping code too. (to flush old info, though you could reduce this by removing entries when you see the FIN packets go past.) > > Thanks for the great suggestions, keep them coming :) > > --don (don@sandvine.com www.sandvine.com) > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 4 16:29: 4 2002 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 2FD2137B401 for ; Wed, 4 Dec 2002 16:29:03 -0800 (PST) Received: from mail.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E6DC43E4A for ; Wed, 4 Dec 2002 16:29:02 -0800 (PST) (envelope-from don@sandvine.com) Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19) id ; Wed, 4 Dec 2002 19:29:01 -0500 Message-ID: From: Don Bowman To: 'Julian Elischer' , Don Bowman Cc: "'freebsd-net@freebsd.org'" Subject: RE: SO_DONTROUTE, arp's, ipfw fwd, etc Date: Wed, 4 Dec 2002 19:28:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > From: Julian Elischer [mailto:julian@elischer.org] > On Wed, 4 Dec 2002, Don Bowman wrote: ... > It gets the destination MAC address from the SRC AMC field of the > preceding incoming packets with that IP src, dst and port > combination.... i.e. the node would look within the IP header. > > > > Wouldn't it be more efficient for me to > > just create the ether-header when the SYN comes in, store it > > in the PCB, and use that on each outgoing packet for that tcp > > connection, add a sockopt (or use SO_DONTROUTE for this on the > > listen socket)? > > yes and no... you would be breaking the layering in > the standard code and you'd get crucified for it. > > start with the ng_bridge node and make it look within > the IP header and use that information in it's hash tables instead of > MAC addresses. It'll need some hosekeeping code too. > (to flush old info, though you could reduce this by removing > entries when you see the FIN packets go past.) Perhaps I can do this within ipfw? Its only ipfw that is bringing up this situation, making me respond to things that normally wouldn't be routed to me. Perhaps 'ipfw' is missing something when it does a 'fwd' to localhost, another step to make this all work? FIN are pretty rare :) Too often things just shut off. I'm nervous about trying to cache the info outside the PCB since it has to stay in sync (its not like the arp cache, there's no way to get the info back if you drop it early). RST is even more problematic since I have to decide if its in-window. --don (don@sandvine.com www.sandvine.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 4 21:24:22 2002 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 42F5C37B401 for ; Wed, 4 Dec 2002 21:24:21 -0800 (PST) Received: from tp.databus.com (p70-227.acedsl.com [66.114.70.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8CB6C43EC2 for ; Wed, 4 Dec 2002 21:24:20 -0800 (PST) (envelope-from barney@tp.databus.com) Received: from tp.databus.com (localhost.databus.com [127.0.0.1]) by tp.databus.com (8.12.6/8.12.6) with ESMTP id gB55OEMG011821; Thu, 5 Dec 2002 00:24:14 -0500 (EST) (envelope-from barney@tp.databus.com) Received: (from barney@localhost) by tp.databus.com (8.12.6/8.12.6/Submit) id gB55OEYY011820; Thu, 5 Dec 2002 00:24:14 -0500 (EST) (envelope-from barney) Date: Thu, 5 Dec 2002 00:24:14 -0500 From: Barney Wolff To: Don Bowman Cc: "'Chuck Swiger'" , "'freebsd-net@freebsd.org'" Subject: Re: SO_DONTROUTE, arp's, ipfw fwd, etc Message-ID: <20021205052414.GA11711@tp.databus.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Scanned-By: MIMEDefang 2.26 (www . roaringpenguin . com / mimedefang) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, Dec 04, 2002 at 05:33:50PM -0500, Don Bowman wrote: > [client] > | > -------------------------- > | Load Balancer | > -------------------------- > | | > | | > [Redirector1] [Redirector2] > \ / > \ / > --------------------- > | | > [BSD1] [BSD2] > | | > ----------------------------- > | | | | | | | | | | > Telnet servers(A) Telnet (B) > > Thanks for the input, keep it coming! Talk me down from this ledge :) Well, if you really don't want to jump, just break the switch between the redirectors and the BSDs into two crossover cables, so redir1 talks only to BSD1 and redir2 talks only to BSD2. You have equal immunity to single failures, no obscure failure modes, and no need for custom kernel stuff. I'd bet anything that actually observed availability would be better, not worse, because of the decreased chance for interesting bugs taking the whole complex down. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 4 21:40:12 2002 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 47A8A37B401 for ; Wed, 4 Dec 2002 21:40:10 -0800 (PST) Received: from sccrmhc01.attbi.com (sccrmhc01.attbi.com [204.127.202.61]) by mx1.FreeBSD.org (Postfix) with ESMTP id A58E043EBE for ; Wed, 4 Dec 2002 21:40:09 -0800 (PST) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by sccrmhc01.attbi.com (sccrmhc01) with ESMTP id <200212050540080010074eqme>; Thu, 5 Dec 2002 05:40:08 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id VAA31280; Wed, 4 Dec 2002 21:36:27 -0800 (PST) Date: Wed, 4 Dec 2002 21:36:26 -0800 (PST) From: Julian Elischer To: Don Bowman Cc: "'freebsd-net@freebsd.org'" Subject: RE: SO_DONTROUTE, arp's, ipfw fwd, etc In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, 4 Dec 2002, Don Bowman wrote: > > From: Julian Elischer [mailto:julian@elischer.org] > > On Wed, 4 Dec 2002, Don Bowman wrote: > ... > > > It gets the destination MAC address from the SRC AMC field of the > > preceding incoming packets with that IP src, dst and port > > combination.... i.e. the node would look within the IP header. > > > > > > > Wouldn't it be more efficient for me to > > > just create the ether-header when the SYN comes in, store it > > > in the PCB, and use that on each outgoing packet for that tcp > > > connection, add a sockopt (or use SO_DONTROUTE for this on the > > > listen socket)? > > > > yes and no... you would be breaking the layering in > > the standard code and you'd get crucified for it. > > > > start with the ng_bridge node and make it look within > > the IP header and use that information in it's hash tables instead of > > MAC addresses. It'll need some hosekeeping code too. > > (to flush old info, though you could reduce this by removing > > entries when you see the FIN packets go past.) > > Perhaps I can do this within ipfw? Its only ipfw that is bringing up > this situation, making me respond to things that normally wouldn't > be routed to me. Perhaps 'ipfw' is missing something when it does > a 'fwd' to localhost, another step to make this all work? 'divert' sockets are to allow you to do things in ipfw.. > > FIN are pretty rare :) Too often things just shut off. I'm nervous > about trying to cache the info outside the PCB since it has to > stay in sync (its not like the arp cache, there's no way to get > the info back if you drop it early). > RST is even more problematic since I have to decide if its in-window. doesn't really matter.. if you remove a cache entry, you'll just recreate it on teh next incoming packet. > > --don (don@sandvine.com www.sandvine.com) > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Dec 5 4: 6:41 2002 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 2C03B37B401 for ; Thu, 5 Dec 2002 04:06:39 -0800 (PST) Received: from smtp0.euronet.nl (smtp0.euronet.nl [194.134.35.141]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6ED7343EB2 for ; Thu, 5 Dec 2002 04:06:33 -0800 (PST) (envelope-from pieter@dustpuppy.no-ip.biz) Received: from dustpuppy.no-ip.biz (3eea6118.cable.wanadoo.nl [62.234.97.24]) by smtp0.euronet.nl (Postfix) with ESMTP id 8389A24F16 for ; Thu, 5 Dec 2002 13:06:26 +0100 (MET) Received: from dustpuppy.no-ip.biz (localhost.wanadoo.nl [127.0.0.1]) by dustpuppy.no-ip.biz (8.12.3/8.12.3) with ESMTP id gB5C6RVr042044 for ; Thu, 5 Dec 2002 13:06:28 +0100 (CET) (envelope-from pieter@dustpuppy.no-ip.biz) Received: (from pieter@localhost) by dustpuppy.no-ip.biz (8.12.3/8.12.3/Submit) id gB5C6RR2042043 for freebsd-net@freebsd.org; Thu, 5 Dec 2002 13:06:27 +0100 (CET) Date: Thu, 5 Dec 2002 13:06:26 +0100 From: Pieter Westland To: freebsd-net@freebsd.org Subject: IPSEC over wireless link Message-ID: <20021205130626.A41963@dustpuppy.no-ip.biz> Reply-To: Pieter Westland Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-OS: FreeBSD dustpuppy.no-ip.biz 4.7-STABLE FreeBSD 4.7-STABLE Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, At home I am trying to set the following up properly: laptop -- (wireless, ipsec) --- gateway (4.7 STABLE) -- (PPPoE) -- Internet Laptop has 10.0.0.3, gateway has 10.0.0.1 on the internal sid, rl0. Between laptop and gateway the encrypted ipsec-connection (with racoon) works fine: # setkey -D 10.0.0.1 10.0.0.3 esp mode=transport spi=3634164961(0xd89cf4e1) reqid=0(0x00000000) E: 3des-cbc e8a6bc4b a8df41c3 84ce4915 7b2e1098 b6f223bd 1f63aeef A: hmac-md5 4c2ef855 7b04c03a bf2cdd93 7fea04b9 seq=0x00000008 replay=4 flags=0x00000000 state=mature created: Dec 2 12:45:09 2002 current: Dec 2 12:54:33 2002 diff: 564(s) hard: 28800(s) soft: 23040(s) last: Dec 2 12:53:31 2002 hard: 0(s) soft: 0(s) current: 1168(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 8 hard: 0 soft: 0 sadb_seq=1 pid=20801 refcnt=2 10.0.0.3 10.0.0.1 esp mode=transport spi=267555277(0x0ff291cd) reqid=0(0x00000000) E: 3des-cbc b2b15686 36ad0b6e b0f20bcb 321999c9 2895b898 80c1a85f A: hmac-md5 c69b094e 53c1f1ca 6d5b44b0 5588dd15 seq=0x00000014 replay=4 flags=0x00000000 state=mature created: Dec 2 12:45:09 2002 current: Dec 2 12:54:33 2002 diff: 564(s) hard: 28800(s) soft: 23040(s) last: Dec 2 12:54:29 2002 hard: 0(s) soft: 0(s) current: 4682(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 20 hard: 0 soft: 0 sadb_seq=0 pid=20801 refcnt=1 The gateway is connected to the net via a PPPoE-connection, using ppp(8) nat is being done. Is working for other machines on the 10.0.0.x-lan well. The problem is that I see packets (with tcpdump) from the laptop to outside being sent ipsec-encrypted by the laptop to the gateway. After that, the _encrypted_ packets are forwarded to the net, while they should be decrypted by the gateway first. If the gateway would decrypt all packets, I can work safely behind the 802.11b-link with all functionality (not only to the gateway, but also behind it). I hope someone can help me on this! The mailinglist archives and usenet archive did not help me... Configs: setkey -c << EOF spdadd 10.0.0.3 0.0.0.0/0 any -P in ipsec esp/transport//require; spdadd 10.0.0.0/0 10.0.0.3 any -P out ipsec esp/transport//require; EOF # ipfw show 00100 228 29370 allow ip from any to any via lo0 00300 0 0 deny ip from 127.0.0.0/8 to any 01000 123 25028 allow udp from 10.0.0.3 500 to any 500 in recv rl0 01000 29 5600 allow udp from any 500 to 10.0.0.3 500 out xmit rl0 01010 70 14560 allow esp from 10.0.0.3 to any via rl0 01010 36 6648 allow esp from any to 10.0.0.3 via rl0 02000 19 1280 allow ip from any to 10.0.0.3 via rl0 02000 83 11403 allow ip from 10.0.0.3 to any via rl0 03000 19 4314 deny ip from any to any via rl0 65000 2822 1043754 allow ip from any to any 65535 0 0 allow ip from any to any Pieter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Dec 5 10:20:36 2002 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 9241837B401 for ; Thu, 5 Dec 2002 10:20:34 -0800 (PST) Received: from smtpout.mac.com (A17-250-248-89.apple.com [17.250.248.89]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2646943E9C for ; Thu, 5 Dec 2002 10:20:34 -0800 (PST) (envelope-from cswiger@mac.com) Received: from asmtp02.mac.com (asmtp02-qfe3 [10.13.10.66]) by smtpout.mac.com (8.12.2/MantshX 2.0) with ESMTP id gB5IKX80004377 for ; Thu, 5 Dec 2002 10:20:34 -0800 (PST) Received: from bust ([12.38.161.88]) by asmtp02.mac.com (Netscape Messaging Server 4.15) with ESMTP id H6NSA900.KOI for ; Thu, 5 Dec 2002 10:20:33 -0800 Date: Thu, 5 Dec 2002 13:20:32 -0500 Subject: Re: SO_DONTROUTE, arp's, ipfw fwd, etc Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) From: Chuck Swiger To: "'freebsd-net@freebsd.org'" Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: <3DDA4578-087E-11D7-A933-000A27D85A7E@mac.com> X-Mailer: Apple Mail (2.482) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wednesday, December 4, 2002, at 05:33 PM, Don Bowman wrote: > From: Chuck Swiger [mailto:cswiger@mac.com] [ ... ] >> Yes, but the complicated internal routes maintained within >> those networks isn't your problem if your machine or network isn't BGP >> peering with them. > > It is in the sense that I have to figure out which one to send > data back to. More than one of them may 'own' a source address > at a given time (for a TCP session). If that is the case, then you either need to have a central point which knows which interface the original request came from, or you need to be able to send replies to a valid IP address back via any route which is up and offers reachability to the IP addr. >> Why? This sounds like a pretty classic example of A being on >> a multihomed network, and you should let IP-level routing deal with the >> problem. But there are alternatives, I guess-- maybe try putting a >> buncha >> interfaces on the BSD box, one for each router being connected to it, and >> put each pair on their own /30. That way, the BSD box can quite easily >> return the >> traffic back to the originating router.... > > Only if its routing, not for L2 redirection. You want your machine (or load-balancer feeding a pool of server machines) to send replies back via the "router it came from", right? If you're NAT'ing a bunch of traffic to a particular IP address on the router via the interface you connect to, why are you doing L2 rewriting? If you simply want your machine to "see" traffic not addressed to it, set the ethernet interface to promiscuous. > This is a transparent proxy. The proxy needs to know where the > real destination was (in case it needs to open a connection there). > The HTTP protocol solved this by putting the real-ip address in the > header, but most other protocols didn't. Sure; but the "real destination" isn't changed. (Unless you're re-writing that, too.) Your transparent proxy should be able to fetch the content from that location. > I don't have control of the content switching routers which feeds > this. They work the way they do. Fine. That means you don't have control over how the "content switching routers" route, NAT, rewrite, fold, spindle, or otherwise mutilate packets from "client", correct? They just send input packets to your part of the system, and you just need to feed replies back the same way. It's the "content switching routers" job to route (un-re-write, un-NAT, whatever) your replies. > Say for the sake of example you wished to load balance 2 farms > of telnet servers. You had a device which picked off port 23, > and sent it to you without alterations. You would then look @ the > intended destination address, and pick the right group of telnet > servers, and send the data there. Now say that those devices themselves > where load-balanced. So if a user telneted twice to the same destination, > one path might go through the first redirector, and one through the > 2nd. The path back is based on the path it came in. All of this can be handled by multihoming your redirector connections and using a dynamic link state protocol to detect failures, be it OSPF at layer 3 or spanning tree or whatever at layer 2. The redirectors *have* to communicate amongst themselves in order to distribute transactions around a downed redirector, right? -Chuck Chuck Swiger | chuck@codefab.com | All your packets are belong to us. -------------+-------------------+----------------------------------- "The human race's favorite method for being in control of the facts is to ignore them." -Celia Green To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Dec 5 10:33:19 2002 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 6688A37B401 for ; Thu, 5 Dec 2002 10:33:16 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 07B8843EBE for ; Thu, 5 Dec 2002 10:33:16 -0800 (PST) (envelope-from larse@ISI.EDU) Received: from isi.edu (nik.isi.edu [128.9.168.58]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id gB5IXDC15817; Thu, 5 Dec 2002 10:33:13 -0800 (PST) Message-ID: <3DEF9BE7.5090708@isi.edu> Date: Thu, 05 Dec 2002 10:33:11 -0800 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.2b) Gecko/20021202 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: Pieter Westland Cc: freebsd-net@freebsd.org Subject: Re: IPSEC over wireless link References: <20021205130626.A41963@dustpuppy.no-ip.biz> In-Reply-To: <20021205130626.A41963@dustpuppy.no-ip.biz> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000201060501060306020708" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a cryptographically signed message in MIME format. --------------ms000201060501060306020708 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Pieter Westland wrote: > At home I am trying to set the following up properly: > > laptop -- (wireless, ipsec) --- gateway (4.7 STABLE) -- (PPPoE) -- > Internet > > Laptop has 10.0.0.3, gateway has 10.0.0.1 on the internal sid, rl0. ... > setkey -c << EOF > spdadd 10.0.0.3 0.0.0.0/0 any -P in ipsec esp/transport//require; > spdadd 10.0.0.0/0 10.0.0.3 any -P out ipsec esp/transport//require; > EOF These look fishy. Shouldn't they simply be: spdadd 10.0.0.3 10.0.0.1 any -P in ipsec esp/transport//require; spdadd 10.0.0.1 10.0.0.3 any -P out ipsec esp/transport//require; Lars -- Lars Eggert USC Information Sciences Institute --------------ms000201060501060306020708 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJtjCC AzgwggKhoAMCAQICEGZFcrfMdPXPY3ZFhNAukQEwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vydmlj ZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkG CSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAw MDBaFw0wNDA4MjcyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2Vy dGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAw LjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZ gpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqd knWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYALQmJ7JRr6aFp AgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTI5NzAS BgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQAxsUtH XfkBceX1U2xdedY9mMAmE2KBIqcS+CKV6BtJtyd7BDm6/ObyJOuR+r3sDSo491BVqGz3Da1M G7wD9LXrokefbKIMWI0xQgkRbLAaadErErJAXWr5edDqLiXdiuT82w0fnQLzWtvKPPZE6iZp h39Ins6ln+eE2MliYq0FxjCCAzkwggKioAMCAQICAwglQTANBgkqhkiG9w0BAQQFADCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMB4XDTAyMDgyNDE4NTMzOVoX DTAzMDgyNDE4NTMzOVowVDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYD VQQDEwtMYXJzIEVnZ2VydDEcMBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBANI2Rrt4ggaQ/IrOsDeOm2H4/R5FRIL6JjDY3StE aogp1r23WKniQ1Vj98Nu5WxlaZ3Iam3Jen5T66H8u7rtMNpK4qAeAGoBsVeyVr1+CTFeuv+m xCh7BvBJwhLdm0zDaoDT05YKYZaqtsT+F286FWJQg31Xtf+vTKLVVrHcsafnteyal2NEt7Ac yZZfjsVLwxp2Lq3cwYfRQRoo7/yCVzS7HsgM6jmbO4taEMo4yC2rpnUbWEUCDTaCYgpAXzAl oiNk7GDh0wz2s5ZSnHRvNSBMAjCmpNtSYHfXFI1ANwrrrHIJ7Ei83+XN32PWY4OPzO3iown9 VR+vM+8lNx9OX28CAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIBBAQTTDJ1TXlmZkJO VWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEEBQADgYEAXcrIlKmPLM/r8r3oz2ZLPLaT1AyMjYTZY2qq/R7SUtFa9BNlTIFh DG78QKfJ9lo2LMzTPQqMZgNLmj95GbNPI8P8OIq2K6MeCZWz08ROackqTFP6xWbIFIfXcBVR 1dZnDDyDKBBh05KkvyTPawSQyOBUeNBfQUyO4TE+3o58U8UwggM5MIICoqADAgECAgMIJUEw DQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MDAeFw0wMjA4MjQxODUzMzlaFw0wMzA4MjQxODUzMzlaMFQxDzANBgNVBAQTBkVnZ2VydDEN MAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkqhkiG9w0BCQEWDWxh cnNlQGlzaS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDSNka7eIIGkPyK zrA3jpth+P0eRUSC+iYw2N0rRGqIKda9t1ip4kNVY/fDbuVsZWmdyGptyXp+U+uh/Lu67TDa SuKgHgBqAbFXsla9fgkxXrr/psQoewbwScIS3ZtMw2qA09OWCmGWqrbE/hdvOhViUIN9V7X/ r0yi1Vax3LGn57XsmpdjRLewHMmWX47FS8Madi6t3MGH0UEaKO/8glc0ux7IDOo5mzuLWhDK OMgtq6Z1G1hFAg02gmIKQF8wJaIjZOxg4dMM9rOWUpx0bzUgTAIwpqTbUmB31xSNQDcK66xy CexIvN/lzd9j1mODj8zt4qMJ/VUfrzPvJTcfTl9vAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIB ADAaMBgCAQQEE0wydU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVk dTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAF3KyJSpjyzP6/K96M9mSzy2k9QM jI2E2WNqqv0e0lLRWvQTZUyBYQxu/ECnyfZaNizM0z0KjGYDS5o/eRmzTyPD/DiKtiujHgmV s9PETmnJKkxT+sVmyBSH13AVUdXWZww8gygQYdOSpL8kz2sEkMjgVHjQX0FMjuExPt6OfFPF MYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MAIDCCVBMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTAyMTIwNTE4MzMxMlowIwYJKoZIhvcNAQkEMRYEFJzYta2t+Rvg/kbGjuV9 m78uN9VeMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3EAQxgZ0w gZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNh cGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNl czEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCCVBMIGtBgsq hkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2Fw ZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRp ZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44 LjMwAgMIJUEwDQYJKoZIhvcNAQEBBQAEggEALBBPr9mKiAToneTMWPJyQmuMBnNS4gFLm/eL O2/pA41HK7NQjP1iHiL0Q0KT8585YmSScJTwBtthpSQYZsPLsurKyTwwO5JDK0rw7Zoyjc4I T0HIjLK9eMN7pOuO7HSnnAOGoUKU2G/f1uf+ZIAo853ZXf8ul0YeADgpKEpn3iV/7HHGpW9g Du0LtSUGpjSFFc3Ac4LSsGr36MFTcKmr8KEw9pUc427jev6uxZrBK+wr3hDXoqwP5LCu63Ep 0ibcWdQrUeq0BwFhRC2lJnYaBaD7pAxH4s2LQq2cma1JXBoMyhB8DeyTsCmDqn2/LGV/ytGG 37UVNQeVBOCkV/ZeLwAAAAAAAA== --------------ms000201060501060306020708-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Dec 5 11:41: 8 2002 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 E283437B401 for ; Thu, 5 Dec 2002 11:41:07 -0800 (PST) Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id 26B4843ECD for ; Thu, 5 Dec 2002 11:41:07 -0800 (PST) (envelope-from jgraessley@apple.com) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id gB5Jf6w00738 for ; Thu, 5 Dec 2002 11:41:06 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 5 Dec 2002 11:40:44 -0800 Received: from apple.com (graejo.apple.com [17.202.40.111]) by scv1.apple.com (8.11.3/8.11.3) with ESMTP id gB5Jf6u18558 for ; Thu, 5 Dec 2002 11:41:06 -0800 (PST) Date: Thu, 5 Dec 2002 11:41:05 -0800 Mime-Version: 1.0 (Apple Message framework v548) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: broadcast over loopback From: Joshua Graessley To: freebsd-net@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: <7E2B1140-0889-11D7-9DEC-000393760260@apple.com> X-Mailer: Apple Mail (2.548) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Is there a reason that the broadcast flag is not set on the loopback interface? It seems like it might be useful to allow applications that use broadcast to continue to work even when loopback is the only interface. -josh To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Dec 5 13:45:38 2002 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 4B0E037B401; Thu, 5 Dec 2002 13:45:37 -0800 (PST) Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F26643EBE; Thu, 5 Dec 2002 13:45:36 -0800 (PST) (envelope-from crist.clark@attbi.com) Received: from blossom.cjclark.org (12-234-91-48.client.attbi.com[12.234.91.48]) by sccrmhc02.attbi.com (sccrmhc02) with ESMTP id <2002120521453500200sp9ove>; Thu, 5 Dec 2002 21:45:35 +0000 Received: from blossom.cjclark.org (localhost. [127.0.0.1]) by blossom.cjclark.org (8.12.6/8.12.3) with ESMTP id gB5LjYeq090360; Thu, 5 Dec 2002 13:45:34 -0800 (PST) (envelope-from crist.clark@attbi.com) Received: (from cjc@localhost) by blossom.cjclark.org (8.12.6/8.12.6/Submit) id gB5LjXGP090359; Thu, 5 Dec 2002 13:45:33 -0800 (PST) X-Authentication-Warning: blossom.cjclark.org: cjc set sender to crist.clark@attbi.com using -f Date: Thu, 5 Dec 2002 13:45:29 -0800 From: "Crist J. Clark" To: Eric Masson Cc: randall ehren , Mailing List FreeBSD Stable , Mailing List FreeBSD Network Subject: Re: Cjc's Ipfilter/Bridge patch Message-ID: <20021205214529.GA90324@blossom.cjclark.org> Reply-To: "Crist J. Clark" References: <86lm35zjux.fsf@notbsdems.nantes.kisoft-services.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86lm35zjux.fsf@notbsdems.nantes.kisoft-services.com> User-Agent: Mutt/1.4i X-URL: http://people.freebsd.org/~cjc/ Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, Dec 04, 2002 at 08:04:22PM +0100, Eric Masson wrote: > >>>>> "randall" == randall ehren writes: > > randall> hasn't it been merged? > > Can't find any trace in the cvsweb interface : > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/net/bridge.c?f=u&only_with_tag=RELENG_4&logsort=date > > And found the following comment in /sys/net/bridge.c > #if 0 /* XXX bridge+ipfilter not yet supported in RELENG_4 */ > #include /* for ipfilter */ > #endif > > But maybe I'm wrong. No, it's not there. I've just been way to busy with my day-job to do much FreeBSD work for the last few months. But I'll try to add this code today. -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Dec 5 15:21:46 2002 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 EC0BC37B401; Thu, 5 Dec 2002 15:21:43 -0800 (PST) Received: from out2.mx.nwbl.wi.voyager.net (out2.mx.nwbl.wi.voyager.net [169.207.3.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5B4D343EC2; Thu, 5 Dec 2002 15:21:43 -0800 (PST) (envelope-from silby@silby.com) Received: from [10.1.1.6] (d134.as2.nwbl0.wi.voyager.net [169.207.95.8]) by out2.mx.nwbl.wi.voyager.net (Postfix) with ESMTP id 0939A2A2DD; Thu, 5 Dec 2002 17:21:36 -0600 (CST) Date: Thu, 5 Dec 2002 17:28:58 -0600 (CST) From: Mike Silbersack To: Aniruddha Bohra Cc: freebsd-net , "" Subject: Re: tcp_usrreq bug ?? In-Reply-To: <3DED2DE3.7040002@cs.rutgers.edu> Message-ID: <20021203185455.D37731-100000@patrocles.silby.com> References: <3DED2DE3.7040002@cs.rutgers.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, 3 Dec 2002, Aniruddha Bohra wrote: > Hello > The following code snippet is from netinet/tcp_usrreq.c > > As in the comment (and presumably correct behaviour) a RST should > be sent on close if the connection is embryonic. However, > if (tp->t_state < TCPS_ESTABLISHED) > tp = tcp_close(tp); > does not do it. One can imagine a scenario when a client would just > do a connect() and close() and an overloaded server would have its > listen queue crowded by connections that were not synchronized but closed. > > I have seen this happen in my lab test, where I use httperf to measure > Apache > webserver throughput. There are several listen queue overflows and resets. > The interesting part is that the client _NEVER_ has more than 3200 open > descriptors > yet a queue of 4096 on the server gets filled up. > > Is there a reason for not sending a RST or is it a bug? Please help. > > Thanks > Aniruddha I took a quick look, and I agree that the comment doesn't seem to match reality. Looking back, it appears that the code/comment have been exactly the same since FreeBSD 2, back in 1994. Note that I haven't actually doublechecked this with tcpdump, so my comments are based off of what you stated... There are two sides to examine this problem from: The server side, and the client side. Server side: Getting flooded with SYN packets is an unfortunate reality that all OSes must deal with these days. Even if you're using a pre-syncache version of FreeBSD, you shouldn't be seeing too many problems due to listen queue overflows. If performance is terrible, you may consider moving to FreeBSD 4.7, or doing further examination to determine if listen queue overflows are really hurting you. Client side: #1 - Why is your benchmark program terminating connections before they finish connecting? #2 - I've been thinking about how FreBSD should handle the situation where a connection is closed before it has become established, and I think that silently dropping the connection is best. Here's why: Normal usage, single connection closed like this: Client receives syn-ack packet, responds with reset. Had a reset been preemptively sent, it would have crossed with the syn-ack on the wire, and two syn-acks would be sent. Either way, the connection gets reset. Flooded server, single connection closed: Same as above; preemptive reset wastes bandwidth. Client used to perform a synflood: Again, same as above. If a reset was sent, you'd double the PPS the server was flooded with. That being said, I don't think that a connect/close pair would be used for a synflood. Such a flood would be easily blockable and tracable with extreme ease. Note that FreeBSD's rst rate limiting would limit the number of connections / second that would be reset, but the server's built-in anti-syn flood countermeasures should do fine. Hence, I'm not sure that we can do anything better than what we are doing now. Once the 5.0 codefreeze is over, I'll go in and take out the misleading comment. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Dec 5 16:19: 6 2002 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 DBF7037B404 for ; Thu, 5 Dec 2002 16:19:05 -0800 (PST) Received: from isber.ucsb.edu (research.isber.ucsb.edu [128.111.147.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 11D3943EB2 for ; Thu, 5 Dec 2002 16:19:05 -0800 (PST) (envelope-from randall@isber.ucsb.edu) Received: from localhost ([127.0.0.1] helo=research.isber.ucsb.edu) by isber.ucsb.edu with esmtp (Exim 3.36 #2) id 18K6Ck-0008pb-00 for freebsd-net@freebsd.org; Thu, 05 Dec 2002 16:18:55 -0800 Date: Thu, 5 Dec 2002 16:18:54 -0800 (PST) From: randall ehren To: Subject: concurrent connections Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanner: exiscan *18K6Ck-0008pb-00*jwISkyqzOm.* (ISBER - Institute for Social, Behavioral, and Economic Research) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org hi, is there a simple way to measure the amount of concurrent network (tcp) connections to a freebsd host? also, not exactly related to freebsd, but is there a way to measure the amount of concurrent connections while running ipfilter on the host? thanks, -- :// randall s. ehren :// voice 805.893.5632 :// systems administrator :// isber|survey|avss.ucsb.edu :// institute for social, behavioral, and economic research To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Dec 5 16:50:19 2002 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 29FD137B401 for ; Thu, 5 Dec 2002 16:50:18 -0800 (PST) Received: from majordomo.vol.cz (smtp4.vol.cz [195.250.128.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 50B6443E4A for ; Thu, 5 Dec 2002 16:50:17 -0800 (PST) (envelope-from dan@obluda.cz) Received: from obluda.cz (xkulesh.vol.cz [195.250.154.106]) by majordomo.vol.cz (8.12.6/8.12.6) with ESMTP id gB60oBDR064063 for ; Fri, 6 Dec 2002 01:50:15 +0100 (CET) (envelope-from dan@obluda.cz) Message-ID: <3DEFF442.6030203@obluda.cz> Date: Fri, 06 Dec 2002 01:50:10 +0100 From: Dan Lukes User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.2b) Gecko/20021106 X-Accept-Language: en, cs MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: broadcast over loopback References: <7E2B1140-0889-11D7-9DEC-000393760260_apple.com@ns.sol.net> In-Reply-To: <7E2B1140-0889-11D7-9DEC-000393760260_apple.com@ns.sol.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org jgraessley@apple.com wrote, On 12/05/02 20:41: > Is there a reason that the broadcast flag is not set on the loopback > interface? It seems like it might be useful to allow applications that > use broadcast to continue to work even when loopback is the only > interface. Your application shouldn't use broadcast unless it knows it run in broadcast capable environment or it shouldn't refuse to run when it cannot send a packet - as it doesn't care where it's packets are sent to. BTW, the broadcast are handled in mad way in TCP/IP stack already - the destination of 255.255.255.255 is silently rewritten to network broadcast and sent over first interface (if it is broadcast capable) or it is routed (often to default route). You can't send the non-network broadcast to interface of your choice (unless you use bpf). Dan -- Dan Lukes tel: +420 2 21914205, fax: +420 2 21914206 root of FIONet, KolejNET, webmaster of www.freebsd.cz AKA: dan@obluda.cz, dan@freebsd.cz,dan@kolej.mff.cuni.cz To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Dec 5 16:59:50 2002 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 A387537B401 for ; Thu, 5 Dec 2002 16:59:49 -0800 (PST) Received: from tp.databus.com (p70-227.acedsl.com [66.114.70.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id E1EA243ECD for ; Thu, 5 Dec 2002 16:59:48 -0800 (PST) (envelope-from barney@tp.databus.com) Received: from tp.databus.com (localhost.databus.com [127.0.0.1]) by tp.databus.com (8.12.6/8.12.6) with ESMTP id gB60xgMG019715; Thu, 5 Dec 2002 19:59:42 -0500 (EST) (envelope-from barney@tp.databus.com) Received: (from barney@localhost) by tp.databus.com (8.12.6/8.12.6/Submit) id gB60xgx7019714; Thu, 5 Dec 2002 19:59:42 -0500 (EST) (envelope-from barney) Date: Thu, 5 Dec 2002 19:59:42 -0500 From: Barney Wolff To: randall ehren Cc: freebsd-net@FreeBSD.ORG Subject: Re: concurrent connections Message-ID: <20021206005942.GA19655@tp.databus.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Scanned-By: MIMEDefang 2.26 (www . roaringpenguin . com / mimedefang) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org netstat -n |grep EST |wc -l If that's too much overhead, steal from the netstat source. On Thu, Dec 05, 2002 at 04:18:54PM -0800, randall ehren wrote: > is there a simple way to measure the amount of concurrent network (tcp) > connections to a freebsd host? -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Dec 5 21:34: 1 2002 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 6228037B404 for ; Thu, 5 Dec 2002 21:34:00 -0800 (PST) Received: from isber.ucsb.edu (research.isber.ucsb.edu [128.111.147.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0E11543EB2 for ; Thu, 5 Dec 2002 21:34:00 -0800 (PST) (envelope-from randall@isber.ucsb.edu) Received: from localhost ([127.0.0.1] helo=research.isber.ucsb.edu) by isber.ucsb.edu with esmtp (Exim 3.36 #2) id 18KB7V-000A2S-00; Thu, 05 Dec 2002 21:33:49 -0800 Date: Thu, 5 Dec 2002 21:33:49 -0800 (PST) From: randall ehren To: Barney Wolff Cc: , Subject: Re: concurrent connections In-Reply-To: <20021206005942.GA19655@tp.databus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanner: exiscan *18KB7V-000A2S-00*ET0e0YlLTkY* (ISBER - Institute for Social, Behavioral, and Economic Research) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > netstat -n |grep EST |wc -l thank you. let me make the grain a little bit finer: i have a freebsd box acting as a IPFilter bridge for a class c subnet - is there any way i can view how many concurrent connections this machine is handling? netstat -s returns: root@fw[~]% netstat -s tcp: 81157 packets sent ... 83237 packets received ... 360 connection requests 4466 connection accepts 4783 connections established (including accepts) 4823 connections closed (including 0 drops) ... are any of the stats returned by netstat -s an indication of the current amount of connections? -- :// randall s. ehren :// voice 805.893.5632 :// systems administrator :// isber|survey|avss.ucsb.edu :// institute for social, behavioral, and economic research To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Dec 5 22:25:47 2002 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 C369237B401 for ; Thu, 5 Dec 2002 22:25:46 -0800 (PST) Received: from tp.databus.com (p70-227.acedsl.com [66.114.70.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id EDE5543EB2 for ; Thu, 5 Dec 2002 22:25:45 -0800 (PST) (envelope-from barney@tp.databus.com) Received: from tp.databus.com (localhost.databus.com [127.0.0.1]) by tp.databus.com (8.12.6/8.12.6) with ESMTP id gB66PdMG021805; Fri, 6 Dec 2002 01:25:39 -0500 (EST) (envelope-from barney@tp.databus.com) Received: (from barney@localhost) by tp.databus.com (8.12.6/8.12.6/Submit) id gB66PdJV021804; Fri, 6 Dec 2002 01:25:39 -0500 (EST) (envelope-from barney) Date: Fri, 6 Dec 2002 01:25:39 -0500 From: Barney Wolff To: randall ehren Cc: freebsd-net@freebsd.org Subject: Re: concurrent connections Message-ID: <20021206062539.GA21770@tp.databus.com> References: <20021206005942.GA19655@tp.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Scanned-By: MIMEDefang 2.26 (www . roaringpenguin . com / mimedefang) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org If your rules keep state, then ipfstat should display the saved states. Otherwise, no, as nothing else will be aware of connections for frames not directly to/from the box itself. On Thu, Dec 05, 2002 at 09:33:49PM -0800, randall ehren wrote: > let me make the grain a little bit finer: > i have a freebsd box acting as a IPFilter bridge for a class c subnet - is > there any way i can view how many concurrent connections this machine is > handling? -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Dec 5 22:51:20 2002 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 0D2BA37B401; Thu, 5 Dec 2002 22:51:18 -0800 (PST) Received: from delivery.infowest.com (delivery.infowest.com [204.17.177.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id A5BE943EBE; Thu, 5 Dec 2002 22:51:17 -0800 (PST) (envelope-from agifford@infowest.com) Received: from infowest.com (eq.net [208.186.104.163]) by delivery.infowest.com (Postfix) with ESMTP id 293E9E3ACBB; Thu, 5 Dec 2002 23:51:12 -0700 (MST) Message-ID: <3DF048B3.3030806@infowest.com> Date: Thu, 05 Dec 2002 23:50:27 -0700 From: "Aaron D. Gifford" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: questions@freebsd.org, freebsd-net@freebsd.org Subject: Re: wi0: wi_cmd: busy bit won't clear. Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Andrew (andrew@ugh.net.au) wrote: >Hi, > >I have a Linksys WMP11 802.11b card running in hostap mode. Every now >and then my wireless network dissappears. If I ssh into the box over a >different interface everything looks OK. To get things going I run >ifconfig wi0 down. The whole machines seems to lock up - it doesn't >even respond to pings on other interfaces. If I wait long enough (30 >secs approx) everything comes back. I find emitted from the kernel: > >wi0: wi_cmd: busy bit won't clear. > >multiple times. > >Anyone seen this? Any ideas? > >I'm running 4.7-STABLE as of a few days ago. > >Thanks, > >Andrew I see almost the exact same thing here. I'm running probably the same card. My hardware is detected during boot thus: wi0: mem 0xffbeb000-0xffbebfff irq 10 at device 16.0 on pci0 wi0: 802.11 address: de:ad:be:ef:fa:fa wi0: using RF:PRISM2.5 MAC:ISL3874A(Mini-PCI) wi0: Intersil Firmware: Primary 1.01.00, Station 1.04.02 The card is set up during boot thus: ifconfig wi0 inet 10.0.1.1/24 ssid my_ssid station my_station channel 7 wepmode on wepkey my_key mediaopt ibss Every now and then, the network will disappear, then return anywhere from 30 seconds to three minutes later. On the console and in the logs are entries much like Andrews: Dec 5 13:15:29 mybox /kernel: wi0: timeout in wi_cmd 0x010b; event status 0x8000 Dec 5 13:15:29 mybox /kernel: wi0: xmit failed Dec 5 13:17:51 mybox /kernel: wi0: watchdog timeout Dec 5 13:17:51 mybox /kernel: wi0: timeout in wi_cmd 0x0002; event status 0x8000 Dec 5 13:17:51 mybox /kernel: wi0: wi_cmd: busy bit won't clear. Dec 5 13:17:51 mybox last message repeated 2 times Dec 5 13:17:51 mybox /kernel: wi0: init failed Dec 5 13:17:51 mybox /kernel: wi0: wi_cmd: busy bit won't clear. Dec 5 13:17:51 mybox last message repeated 22 times Dec 5 13:17:51 mybox /kernel: wi0: failed to allocate 1594 bytes on NIC Dec 5 13:17:51 mybox /kernel: wi0: tx buffer allocation failed Dec 5 13:17:51 mybox /kernel: wi0: wi_cmd: busy bit won't clear. Dec 5 13:17:51 mybox /kernel: wi0: failed to allocate 1594 bytes on NIC Dec 5 13:17:51 mybox /kernel: wi0: mgmt. buffer allocation failed Dec 5 13:17:51 mybox /kernel: wi0: timeout in wi_seek to 0/0; last status 4000 Dec 5 13:17:51 mybox /kernel: wi0: timeout in wi_seek to 0/44; last status 4044 Dec 5 13:17:56 mybox /kernel: wi0: watchdog timeout The logs are very similar during each "event" and the host becomes unreachable whether via the wireless network or wired network. I haven't been able to get to the console quickly enough to check if the console is also unresponsive, but I wouldn't be surprised. It seems these "outages" occur more often during heavier traffic. They also have increased in frequency since WEP was enabled on the network. Any ideas, anyone? Aaron out. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Dec 6 1:22:49 2002 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 EA47137B401; Fri, 6 Dec 2002 01:22:47 -0800 (PST) Received: from musique.teaser.net (musique.teaser.net [213.91.2.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id 080C743ED4; Fri, 6 Dec 2002 01:22:47 -0800 (PST) (envelope-from e-masson@kisoft-services.com) Received: from notbsdems.nantes.kisoft-services.com (nantes.kisoft-services.com [193.56.60.243]) by musique.teaser.net (Postfix) with ESMTP id AF28D7252C; Fri, 6 Dec 2002 10:22:40 +0100 (CET) Received: by notbsdems.nantes.kisoft-services.com (Postfix, from userid 1001) id 28D505A2C4; Fri, 6 Dec 2002 09:29:16 +0100 (CET) To: "Crist J. Clark" Cc: randall ehren , Mailing List FreeBSD Stable , Mailing List FreeBSD Network Subject: Re: Cjc's Ipfilter/Bridge patch References: <86lm35zjux.fsf@notbsdems.nantes.kisoft-services.com> <20021205214529.GA90324@blossom.cjclark.org> From: Eric Masson In-Reply-To: <20021205214529.GA90324@blossom.cjclark.org> ("Crist J. Clark"'s message of "Thu, 5 Dec 2002 13:45:29 -0800") X-Operating-System: FreeBSD 4.7-STABLE i386 Date: Fri, 06 Dec 2002 09:29:15 +0100 Message-ID: <86el8v1rfo.fsf@notbsdems.nantes.kisoft-services.com> User-Agent: Gnus/5.090008 (Oort Gnus v0.08) XEmacs/21.4 (Common Lisp, i386--freebsd) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >>>>> "Crist" == Crist J Clark writes: Crist> No, it's not there. I've just been way to busy with my day-job Crist> to do much FreeBSD work for the last few months. Welcome to the real world :) Crist> But I'll try to add this code today. Thanks a lot. Eric Masson -- Bref, me dire que j'ai peut-ętre contribué, ne serait-ce que d'un epsilon, ŕ la propagation de serveurs "compatibles avec FrontPage" me flanque des remontées gastriques peu reluisantes. -+- FM in Guide du Macounet Pervers : Bien préparer sa digestion -+- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Dec 6 6:10:56 2002 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 3D89137B401; Fri, 6 Dec 2002 06:10:55 -0800 (PST) Received: from darkstar.wavenet.com.br (darkstar.wavenet.com.br [200.223.81.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 39D0C43E4A; Fri, 6 Dec 2002 06:10:54 -0800 (PST) (envelope-from jcrr@ieee.org) Received: (from root@localhost) by darkstar.wavenet.com.br (8.12.6/8.12.2) id gB6ECYDe039246; Fri, 6 Dec 2002 12:12:34 -0200 (BRST) Received: from mobile (acc-01-1E.radio.wavenet.com.br [200.223.81.30]) by darkstar.wavenet.com.br (8.12.6/8.12.2av) with SMTP id gB6ECUom039237; Fri, 6 Dec 2002 12:12:33 -0200 (BRST) Message-ID: <037701c29d39$85fecc00$1e01a8c0@mobile> From: "Joao Carlos" To: Cc: Subject: Squid and NATD with Redirect of ports Date: Fri, 6 Dec 2002 12:09:49 -0300 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.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Virus-Scanned: by AMaViS perl-10 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I'm having the following problem. FreeBSD 4.7-STABLE (but with any version it does not work either) I've a FreeBSD connected to a cable network, with only one IP Address. My FreeBSD has three network cards. One is connected to my internal network, other is connected to the cable, and the other is connected to a server that has some serves something to the Internet. I'm using IPFIREWALL and NATD, and without squid everything works fine. But I have to use SQUID + SQUIDGUARD to block some content and urls. The problem is: When the client is using squid, it requests www.somesite.com that is hosted at the server conected to this FreeBSD and has a non valid IP address. External access works because NATD redirects the port 80 to the internal address, but SQUID, that is located at the firewall, resolves the www.somesite.com to the local ip address and tries to connect to the localhost port 80. It does not pass the packets to the natd to redirect because it is a local ip address. Then i get Connection Refused because there is no web server at the firewall. Any ideas how i can solve this problem? I really need the clients using the squid at the IE configuration. Thanks. --- Joao Carlos jcrr@ieee.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Dec 6 7:45:31 2002 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 F0A6137B401 for ; Fri, 6 Dec 2002 07:45:29 -0800 (PST) Received: from artemis.wszib.edu.pl (artemis.wszib.edu.pl [217.96.89.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2216443EC5 for ; Fri, 6 Dec 2002 07:45:27 -0800 (PST) (envelope-from butyn@wszib.edu.pl) Received: (from butyn@localhost) by artemis.wszib.edu.pl (8.11.6/8.11.6) id gB6FjOG13742 for freebsd-net@freebsd.org; Fri, 6 Dec 2002 16:45:24 +0100 Date: Fri, 6 Dec 2002 16:45:24 +0100 From: Bartlomiej Butyn To: freebsd-net@freebsd.org Subject: FreeBSD 4.7 and shapeing bridge Message-ID: <20021206164524.A13690@artemis.wszib.edu.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi. I'm trying to configure shapeing bridge on FreeBSD and I have problems with putting packets to pipe with ipfw. My configuration is: %uname -a FreeBSD bridge1.milc.com.pl 4.7-RELEASE-p2 FreeBSD 4.7-RELEASE-p2 #0: Fri Dec 6 13:31:37 CET 2002 root@bridge1.milc.com.pl:/usr/obj/usr/src/sys/MYKERNEL i386 cvsuped about 2 hours ago. I'm configuring test pipes with: bridge1# ipfw pipe 1 config bw 64Kbit/s bridge1# ipfw pipe 2 config bw 64Kbit/s bridge1# ipfw add pipe 1 ip from any to any out recv rl0 xmit vr0 bridge1# ipfw add pipe 2 ip from any to any out recv vr0 xmit rl0 then, I make some nettwork traffic going throught that bridge, and: bridge1# ipfw show 00100 0 0 pipe 1 ip from any to any out recv rl0 xmit vr0 00200 0 0 pipe 2 ip from any to any out recv vr0 xmit rl0 65535 2626 283073 allow ip from any to any Can you explain me why didn't any packet match rules 100 and 200? Measured network traffic is about 7Mbit/s. (that's because there is HUB between vr0 and test host), but why this bridge does not shapeing any traffic? Because I'm new on this list I don't know that I gave you all informations needed to answer to me. If not, tell me and I'll give you more with plaesure. TIA. -- Bartłomiej Butyn aka Yoss Nie ma tego złego co by na gorsze nie wyszło. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Dec 6 7:51:33 2002 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 0A74A37B401 for ; Fri, 6 Dec 2002 07:51:32 -0800 (PST) Received: from shell.dragondata.com (shell.dragondata.com [66.250.147.249]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2729C43EA9 for ; Fri, 6 Dec 2002 07:51:31 -0800 (PST) (envelope-from toasty@dragondata.com) Received: (from root@localhost) by shell.dragondata.com (8.11.4/8.11.3) id gB6FpUJ02420; Fri, 6 Dec 2002 09:51:30 -0600 (CST) (envelope-from toasty@dragondata.com) Received: from KEVIN-AW.dragondata.com (dsl092-133-143.chi1.dsl.speakeasy.net [66.92.133.143]) by shell.dragondata.com (8.11.4/8.11.3av) with ESMTP id gB6FpT702340; Fri, 6 Dec 2002 09:51:29 -0600 (CST) (envelope-from toasty@dragondata.com) Message-Id: <5.1.1.5.2.20021206095103.034102f8@127.0.0.1> X-Sender: toasty@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Fri, 06 Dec 2002 09:51:22 -0600 To: Bartlomiej Butyn , freebsd-net@freebsd.org From: Kevin Day Subject: Re: FreeBSD 4.7 and shapeing bridge In-Reply-To: <20021206164524.A13690@artemis.wszib.edu.pl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by dragondata.com virus scanner Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org At 09:45 AM 12/6/2002, Bartlomiej Butyn wrote: >Hi. >I'm trying to configure shapeing bridge on FreeBSD and I have problems >with putting packets to pipe with ipfw. My configuration is: > >%uname -a >FreeBSD bridge1.milc.com.pl 4.7-RELEASE-p2 FreeBSD 4.7-RELEASE-p2 #0: >Fri Dec 6 13:31:37 CET 2002 >root@bridge1.milc.com.pl:/usr/obj/usr/src/sys/MYKERNEL i386 > >cvsuped about 2 hours ago. I'm configuring test pipes with: > >bridge1# ipfw pipe 1 config bw 64Kbit/s >bridge1# ipfw pipe 2 config bw 64Kbit/s >bridge1# ipfw add pipe 1 ip from any to any out recv rl0 xmit vr0 >bridge1# ipfw add pipe 2 ip from any to any out recv vr0 xmit rl0 > >then, I make some nettwork traffic going throught that bridge, and: > >bridge1# ipfw show >00100 0 0 pipe 1 ip from any to any out recv rl0 xmit vr0 >00200 0 0 pipe 2 ip from any to any out recv vr0 xmit rl0 >65535 2626 283073 allow ip from any to any > >Can you explain me why didn't any packet match rules 100 and 200? >Measured network traffic is about 7Mbit/s. (that's because there is >HUB between vr0 and test host), but why this bridge does not shapeing >any traffic? > >Because I'm new on this list I don't know that I gave you all >informations needed to answer to me. If not, tell me and I'll give you more >with plaesure. >TIA. Have you turned on ipfw for bridging? Try this: sysctl -w net.link.ether.bridge_ipfw=1 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Dec 6 8: 4:19 2002 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 18D1A37B401 for ; Fri, 6 Dec 2002 08:04:19 -0800 (PST) Received: from artemis.wszib.edu.pl (artemis.wszib.edu.pl [217.96.89.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C3E443E9C for ; Fri, 6 Dec 2002 08:04:17 -0800 (PST) (envelope-from bartek@milc.pl) Received: from localhost (butyn@localhost) by artemis.wszib.edu.pl (8.11.6/8.11.6) with ESMTP id gB6G4Gq14467 for ; Fri, 6 Dec 2002 17:04:16 +0100 X-Authentication-Warning: artemis.wszib.edu.pl: butyn owned process doing -bs Date: Fri, 6 Dec 2002 17:04:16 +0100 (CET) From: Yoss X-X-Sender: butyn@artemis.wszib.edu.pl To: freebsd-net@freebsd.org Subject: Re: FreeBSD 4.7 and shapeing bridge Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-2 Content-Transfer-Encoding: 8BIT Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, Dec 06, 2002 at 09:51:22AM -0600, Kevin Day wrote: > Have you turned on ipfw for bridging? Try this: > sysctl -w net.link.ether.bridge_ipfw=1 bridge1# sysctl net.link.ether | grep bridge net.link.ether.bridge_cfg: rl0,vr0,vr1,vr2 net.link.ether.bridge: 1 net.link.ether.bridge_ipfw: 1 net.link.ether.bridge_ipf: 0 net.link.ether.bridge_ipfw_drop: 0 net.link.ether.bridge_ipfw_collisions: 0 -- Bartłomiej Butyn aka Yoss Nie ma tego złego co by na gorsze nie wyszło To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Dec 6 8:32:34 2002 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 27E5237B401 for ; Fri, 6 Dec 2002 08:32:33 -0800 (PST) Received: from artemis.wszib.edu.pl (artemis.wszib.edu.pl [217.96.89.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id C4D0A43EA9 for ; Fri, 6 Dec 2002 08:32:30 -0800 (PST) (envelope-from bartek@milc.pl) Received: from localhost (butyn@localhost) by artemis.wszib.edu.pl (8.11.6/8.11.6) with ESMTP id gB6GWPU15077 for ; Fri, 6 Dec 2002 17:32:25 +0100 X-Authentication-Warning: artemis.wszib.edu.pl: butyn owned process doing -bs Date: Fri, 6 Dec 2002 17:32:25 +0100 (CET) From: Yoss X-X-Sender: butyn@artemis.wszib.edu.pl To: freebsd-net@freebsd.org Subject: Re: FreeBSD 4.7 and shapeing bridge Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-2 Content-Transfer-Encoding: 8BIT Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, Dec 06, 2002 at 09:51:22AM -0600, Kevin Day wrote: > Have you turned on ipfw for bridging? Try this: > sysctl -w net.link.ether.bridge_ipfw=1 bridge1# sysctl net.link.ether | grep bridge net.link.ether.bridge_cfg: rl0,vr0,vr1,vr2 net.link.ether.bridge: 1 net.link.ether.bridge_ipfw: 1 net.link.ether.bridge_ipf: 0 net.link.ether.bridge_ipfw_drop: 0 net.link.ether.bridge_ipfw_collisions: 0 -- Bartłomiej Butyn aka Yoss Nie ma tego złego co by na gorsze nie wyszło To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Dec 6 9:31:59 2002 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 7271D37B401 for ; Fri, 6 Dec 2002 09:31:58 -0800 (PST) Received: from bps.jodocus.org (c115139.upc-c.chello.nl [212.187.115.139]) by mx1.FreeBSD.org (Postfix) with ESMTP id F161943EA9 for ; Fri, 6 Dec 2002 09:31:56 -0800 (PST) (envelope-from joost@bps.jodocus.org) Received: (from joost@localhost) by bps.jodocus.org (8.11.6/8.11.6) id gB6HVtp48083 for freebsd-net@FreeBSD.ORG; Fri, 6 Dec 2002 18:31:55 +0100 (CET) (envelope-from joost) Date: Fri, 6 Dec 2002 18:31:55 +0100 From: Joost Bekkers To: freebsd-net@FreeBSD.ORG Subject: Re: FreeBSD 4.7 and shapeing bridge Message-ID: <20021206173155.GB48015@bps.jodocus.org> Mail-Followup-To: Joost Bekkers , freebsd-net@FreeBSD.ORG References: <20021206164524.A13690@artemis.wszib.edu.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021206164524.A13690@artemis.wszib.edu.pl> User-Agent: Mutt/1.4i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, Dec 06, 2002 at 04:45:24PM +0100, Bartlomiej Butyn wrote: > bridge1# ipfw pipe 1 config bw 64Kbit/s > bridge1# ipfw pipe 2 config bw 64Kbit/s > bridge1# ipfw add pipe 1 ip from any to any out recv rl0 xmit vr0 > bridge1# ipfw add pipe 2 ip from any to any out recv vr0 xmit rl0 > > /usr/src/sys/net/bridge.c says: /* * The third parameter to the firewall code is the dst. interface. * Since we apply checks only on input pkts we use NULL. * The firewall knows this is a bridged packet as the cookie ptr * is NULL. */ so if you use ipfw add pipe 1 ip from any to any in recv rl0 bridged ipfw add pipe 2 ip from any to any in recv vr0 bridged things should be fine. -- greetz Joost joost@jodocus.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Dec 6 10:21:16 2002 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 61BE237B401 for ; Fri, 6 Dec 2002 10:21:15 -0800 (PST) Received: from artemis.wszib.edu.pl (artemis.wszib.edu.pl [217.96.89.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 39C3E43ED1 for ; Fri, 6 Dec 2002 10:21:14 -0800 (PST) (envelope-from bartek@milc.pl) Received: from localhost (butyn@localhost) by artemis.wszib.edu.pl (8.11.6/8.11.6) with ESMTP id gB6ILCW17862 for ; Fri, 6 Dec 2002 19:21:12 +0100 X-Authentication-Warning: artemis.wszib.edu.pl: butyn owned process doing -bs Date: Fri, 6 Dec 2002 19:21:12 +0100 (CET) From: Yoss X-X-Sender: butyn@artemis.wszib.edu.pl To: freebsd-net@freebsd.org Subject: Re: FreeBSD 4.7 and shapeing bridge Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-2 Content-Transfer-Encoding: 8BIT Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, Dec 06, 2002 at 06:31:55PM +0100, Joost Bekkers wrote: > so if you use > ipfw add pipe 1 ip from any to any in recv rl0 bridged > ipfw add pipe 2 ip from any to any in recv vr0 bridged > things should be fine. Yes, now packets are going through pipes. But it doesn't help me in the matter of fact. I have four xDSL links concentrated in one point and connected to the router. I have to cut down speed via these links to 1Mbit to be sure that every link will have 2Mbit bandwidth from router. Now I can shape bandwidth incoming from every link, but there is possibility that hosts on 2 of them will send data to host on third link, and then third one will be full. Is there any possibility do shape outgoing bandwidth on bridge in depend of interface it is going out? TIA -- Bartłomiej Butyn aka Yoss Nie ma tego złego co by na gorsze nie wyszło To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Dec 6 15:28:21 2002 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 90CF437B401 for ; Fri, 6 Dec 2002 15:28:19 -0800 (PST) Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1E46A43EBE for ; Fri, 6 Dec 2002 15:28:19 -0800 (PST) (envelope-from jgraessley@apple.com) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id gB6NSII26946 for ; Fri, 6 Dec 2002 15:28:18 -0800 (PST) Received: from scv3.apple.com (scv3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 6 Dec 2002 15:27:56 -0800 Received: from apple.com (graejo.apple.com [17.202.40.111]) by scv3.apple.com (8.11.3/8.11.3) with ESMTP id gB6NSI920668 for ; Fri, 6 Dec 2002 15:28:18 -0800 (PST) Date: Fri, 6 Dec 2002 15:28:15 -0800 Subject: Re: broadcast over loopback Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) From: Joshua Graessley To: freebsd-net@FreeBSD.ORG Content-Transfer-Encoding: 7bit In-Reply-To: <3DEFF442.6030203@obluda.cz> Message-Id: <65242A88-0972-11D7-AE67-000393760260@apple.com> X-Mailer: Apple Mail (2.548) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Thank you for the reply Dan! I am aware of the issues with broadcast, and I strongly urge people to use multicast instead of broadcast for a variety of reasons. All the same, I've been asked to address this issue and I wanted to understand why FreeBSD doesn't allow broadcast on the loopback interface. Conceptually, it sort of makes sense to allow it. Using a broadcast should result in everyone on some link receiving your packet. If loopback is your only interface that's up, then why not use that? In the case of loopback, you are the only one on your link, so you should still receive your broadcast. Is there a technical reason this was done (i.e. if I set the broadcast flag on loopback I'll be chasing down other bugs until my hair turns grey or falls out) or is it a conceptual reason (i.e. broadcast, on loopback, are you out of your mind?). Other platforms out there will handle broadcast on the loopback interface. Is it desirable to make changes to the FreeBSD stack to get this behavior? Thanks, -josh On Thursday, December 5, 2002, at 04:50 PM, Dan Lukes wrote: > jgraessley@apple.com wrote, On 12/05/02 20:41: > >> Is there a reason that the broadcast flag is not set on the loopback >> interface? It seems like it might be useful to allow applications that >> use broadcast to continue to work even when loopback is the only >> interface. > > Your application shouldn't use broadcast unless it knows it run in > broadcast capable environment or it shouldn't refuse to run when it > cannot send a packet - as it doesn't care where it's packets are sent > to. > > > BTW, the broadcast are handled in mad way in TCP/IP stack already - > the destination of 255.255.255.255 is silently rewritten to network > broadcast and sent over first interface (if it is broadcast capable) > or it is routed (often to default route). You can't send the > non-network broadcast to interface of your choice (unless you use > bpf). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Dec 6 16:15:32 2002 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 E1BF737B401 for ; Fri, 6 Dec 2002 16:15:30 -0800 (PST) Received: from eurus.primus.ca (mail.tor.primus.ca [216.254.136.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4021043EC5 for ; Fri, 6 Dec 2002 16:15:30 -0800 (PST) (envelope-from leth@primus.ca) Received: from dialin-162-187.tor.primus.ca ([216.254.162.187]) by eurus.primus.ca with esmtp (Exim 3.33 #16) id 18KScs-0004js-0A; Fri, 06 Dec 2002 19:15:23 -0500 Date: Fri, 6 Dec 2002 19:15:28 -0500 (EST) From: Jason Hunt X-X-Sender: leth@lethargic.dyndns.org To: freebsd-net@FreeBSD.ORG Cc: Joshua Graessley Subject: Re: broadcast over loopback In-Reply-To: <65242A88-0972-11D7-AE67-000393760260@apple.com> Message-ID: <20021206185424.P19254-100000@lethargic.dyndns.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, 6 Dec 2002, Joshua Graessley wrote: > I am aware of the issues with broadcast, and I strongly urge people to > use multicast instead of broadcast for a variety of reasons. All the > same, I've been asked to address this issue and I wanted to understand > why FreeBSD doesn't allow broadcast on the loopback interface. > Conceptually, it sort of makes sense to allow it. Using a broadcast > should result in everyone on some link receiving your packet. If > loopback is your only interface that's up, then why not use that? In > the case of loopback, you are the only one on your link, so you should > still receive your broadcast. > > Is there a technical reason this was done (i.e. if I set the broadcast > flag on loopback I'll be chasing down other bugs until my hair turns > grey or falls out) or is it a conceptual reason (i.e. broadcast, on > loopback, are you out of your mind?). > With any kind of broadcast media, unless this is specific to Ethernet, or there are some exceptions, a broadcast packet sent by a station is received on every port other than the port that the packet came from. As far as I know, a station should never receive it's own broadcast packets unless you have a loop somewhere in your Layer 2 infrastructure. I believe that the above applies to IP broadcasts (or any other Layer 3 protocols) as well. > Other platforms out there will handle broadcast on the loopback > interface. Is it desirable to make changes to the FreeBSD stack to get > this behavior? Any examples? I cannot think of a practical case where this would be required. I would think that an application will know if it sent a broadcast or not, so it shouldn't have to receive that broadcast itself. Anyone disagree? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Dec 6 19:46:21 2002 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 DCEF437B401 for ; Fri, 6 Dec 2002 19:46:20 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by mx1.FreeBSD.org (Postfix) with ESMTP id BD08543EB2 for ; Fri, 6 Dec 2002 19:46:19 -0800 (PST) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from localhost ([3ffe:501:4819:2000:7490:870e:d079:b1ab]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id gB73k2R91563; Sat, 7 Dec 2002 12:46:07 +0900 (JST) Date: Sat, 07 Dec 2002 12:46:12 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Juan Francisco Rodriguez Hervella Cc: freebsd-net@FreeBSD.ORG Subject: Re: Sysctl and root privileges, how could I avoid them ? In-Reply-To: <3DEB248E.9333E90@it.uc3m.es> References: <3DE7A145.18986834@it.uc3m.es> <3DEB248E.9333E90@it.uc3m.es> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 17 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >>>>> On Mon, 02 Dec 2002 10:14:54 +0100, >>>>> Juan Francisco Rodriguez Hervella said: > Are you talking about the flag CTLFLAG_RW ? I'm using req->oldptr == > NULL and req-> newptr != NULL to add a new element into a kernel table.... and I > plan > to use req->oldptr & req->newptr != NULL to show the elements of the > table... If you just want to show (get) the elements, you don't have to have a non NULL newptr. Then the root privilege won't be required. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Dec 7 2:50: 5 2002 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 77DDF37B401 for ; Sat, 7 Dec 2002 02:50:04 -0800 (PST) Received: from hotmail.com (f5.law15.hotmail.com [64.4.23.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3E49043EA9 for ; Sat, 7 Dec 2002 02:50:04 -0800 (PST) (envelope-from soheil_hh@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 7 Dec 2002 02:50:04 -0800 Received: from 81.31.160.37 by lw15fd.law15.hotmail.msn.com with HTTP; Sat, 07 Dec 2002 10:50:03 GMT X-Originating-IP: [81.31.160.37] From: "soheil soheil" To: freebsd-net@freebsd.org Subject: Indirect TCP lib Date: Sat, 07 Dec 2002 10:50:03 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 07 Dec 2002 10:50:04.0153 (UTC) FILETIME=[6620EE90:01C29DDE] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Dear All I read the paper for snoop tcp and i see it says , we can use i-tcp for tcp connection splitting i want to know if the i-tcp lib is available ? or not? THANX _________________________________________________________________ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Dec 7 11:39:50 2002 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 CED4A37B401 for ; Sat, 7 Dec 2002 11:39:49 -0800 (PST) Received: from mx1.purplecat.net (mx1.purplecat.net [208.133.44.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id 41C9743EC2 for ; Sat, 7 Dec 2002 11:39:49 -0800 (PST) (envelope-from peter@skyrunner.net) Received: (qmail 70371 invoked from network); 7 Dec 2002 19:40:14 -0000 Received: from unknown (HELO micron) (208.150.25.130) by mx1.skyrunner.net with SMTP; 7 Dec 2002 19:40:14 -0000 From: "Peter Brezny" To: Subject: or syntx for ipfw Date: Sat, 7 Dec 2002 14:39:27 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I'm having problems with the syntax (i think) of using "or" in ipfw rules. Does this work only with ipfw2? i'm attempting: ipfw add 300 deny log all from \{ not 208.133.x.x/2x or 12.150.x.x/2x \} to any out via oif and i'm getting: ipfw: hostname ``{'' unknown TIA Peter Brezny Skyrunner.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Dec 7 11:56:48 2002 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 9733F37B401 for ; Sat, 7 Dec 2002 11:56:47 -0800 (PST) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 17C6643EC2 for ; Sat, 7 Dec 2002 11:56:47 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.3/8.12.3) with ESMTP id gB7JukTO044568; Sat, 7 Dec 2002 11:56:46 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.3/8.12.3/Submit) id gB7JukFI044567; Sat, 7 Dec 2002 11:56:46 -0800 (PST) (envelope-from rizzo) Date: Sat, 7 Dec 2002 11:56:46 -0800 From: Luigi Rizzo To: Peter Brezny Cc: freebsd-net@FreeBSD.ORG Subject: Re: or syntx for ipfw Message-ID: <20021207115646.A44555@xorpc.icir.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from peter@skyrunner.net on Sat, Dec 07, 2002 at 02:39:27PM -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sat, Dec 07, 2002 at 02:39:27PM -0500, Peter Brezny wrote: > I'm having problems with the syntax (i think) of using "or" in ipfw rules. > > Does this work only with ipfw2? yes it only works with ipfw2 luigi > i'm attempting: > > ipfw add 300 deny log all from \{ not 208.133.x.x/2x or 12.150.x.x/2x \} to > any out via oif > > and i'm getting: > ipfw: hostname ``{'' unknown > > TIA > > Peter Brezny > Skyrunner.net > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message