From owner-freebsd-net Sun Jun 23 9:22: 3 2002 Delivered-To: freebsd-net@freebsd.org Received: from pacbell.net (adsl-63-199-179-203.dsl.snfc21.pacbell.net [63.199.179.203]) by hub.freebsd.org (Postfix) with ESMTP id 7E40037B401; Sun, 23 Jun 2002 09:21:33 -0700 (PDT) Received: (from paleph@localhost) by pacbell.net (8.11.0/8.9.3) id g5NFqS002122; Sun, 23 Jun 2002 08:52:28 -0700 From: paleph@pacbell.net Message-Id: <200206231552.g5NFqS002122@pacbell.net> Subject: Re: Re: bge driver issue To: freebsd-hackers@freebsd.org Date: Sun, 23 Jun 2002 08:52:28 -0700 (PDT) Cc: freebsd-net@freebsd.org X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org John. Thanks for the tip. I changed ETHER_ALIGN to 0 and the driver started to work. I am not sure about the performance since I seem to get only 50 Mbit over a 100 Mbit line. However this is much better than the timeout warnings... Thanks for the input. It is really appreciated. Do you need any other experiments done? We're going to ship the 2650 back to Dell for other reasons (form factor and noise). Paul Fronberg paleph@pacbell.net >In article <200206182206.g5IM6P003388@pacbell.net>, > wrote: >> We have a Dell poweredge 2650 (successor to 2550). >> >> We also saw the same problem with 4.5. I tried the current bge driver from 4.6> without success. The problem seems to be a size problem. When we ftp a small >> file, things work fine. However, when we try a 18 Megabyte file, the ftp >> hands and we see the problem descriped below. The linux system that came >> with the hardware (from dell) worked fine. > >On the 2650 or any other x86 PCI-X system, please try the following >simple experiment. Edit "src/sys/dev/bge/if_bgereg.h". Find this >line: > > #define ETHER_ALIGN 2 > >Change the "2" to "0". Build and install a new kernel. See whether >it solves the problem. > >Here is the reasoning behind the experiment. The bge driver sets >things up so that the NIC DMAs received packets into mbuf clusters >starting ETHER_ALIGN bytes from the beginning of the buffer. That is >done so the payload after the 14- or 18-byte Ethernet header will be >aligned in memory at a 4-byte boundary. The Linux driver from 3Com >for the 3c996B-T does the same thing. However, on PCI-X busses only, >that driver disables the 2-byte offsetting and stores received packets >at the very beginning of the buffer in memory. It is reasonable to >assume that they went to all that trouble for a reason -- for example, >a chip bug. > >This change will impact performance on the x86 architecture, and it >will flat-out break Alphas and most other architectures. The actual >fix would have to be more intelligent, but this is just an experiment. > >Please report back after you have tried this change. I know two >people who have reported that it solved the problems they were having >with BCM5701 chips in PCI-X systems. > >John >-- > John Polstra > John D. Polstra & Co., Inc. Seattle, Washington USA > "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jun 23 16:10:13 2002 Delivered-To: freebsd-net@freebsd.org Received: from coal.sentex.ca (coal.sentex.ca [209.112.4.16]) by hub.freebsd.org (Postfix) with ESMTP id 1349337B40A for ; Sun, 23 Jun 2002 16:09:44 -0700 (PDT) Received: from coal.sentex.ca (localhost.sentex.ca [127.0.0.1]) by coal.sentex.ca (8.12.2/8.12.2) with ESMTP id g5NN9a8X001947 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 23 Jun 2002 19:09:36 -0400 (EDT) (envelope-from freebsd@coal.sentex.ca) Received: (from freebsd@localhost) by coal.sentex.ca (8.12.2/8.12.2/Submit) id g5NN9asS001943; Sun, 23 Jun 2002 19:09:36 -0400 (EDT) (envelope-from freebsd) Date: Sun, 23 Jun 2002 19:09:36 -0400 (EDT) From: Damian Gerow Message-Id: <200206232309.g5NN9asS001943@coal.sentex.ca> To: freebsd-net@freebsd.org Subject: Native PPPoE broken (4.6-STABLE), RP-PPPoE working?! Cc: julian@elischer.org, brian@awfulhak.org Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I've been working with Mike Tancsa for the past little while, trying to figure out why the new concentrators that are being deployed in Canada are causing problems with some (notably the FreeBSD) PPPoE implementations -- the end result being horribly slow to nonexistant speeds. After spending a couple of hours getting it to compile, I got Roaring Penguin (latest release) and pppd-3.11 compiled and installed on my 4.6-STABLE (June 17) box, and connected it just fine. Speeds are exactly as expected, and there's *no* slowness at all. So it appears that the in-kernel PPPoE implementation is broken, and Roaring Pengiun's is working? (Or that the new concentrator is breaking from the spec, and causing problems with the in-kernel implementation...) - Damian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jun 23 16:48:41 2002 Delivered-To: freebsd-net@freebsd.org Received: from priv-edtnes16-hme0.telusplanet.net (defout.telus.net [199.185.220.240]) by hub.freebsd.org (Postfix) with ESMTP id E23D237B400 for ; Sun, 23 Jun 2002 16:48:36 -0700 (PDT) Received: from gcooper ([209.107.97.90]) by priv-edtnes16-hme0.telusplanet.net (InterMail vM.5.01.04.02 201-253-122-122-102-20011128) with SMTP id <20020623234836.FSMP7316.priv-edtnes16-hme0.telusplanet.net@gcooper> for ; Sun, 23 Jun 2002 17:48:36 -0600 Message-ID: <001b01c21b17$ef29ffa0$5a616bd1@ab.hsia.telus.net> From: "Grant Cooper" To: References: <200206231552.g5NFqS002122@pacbell.net> Subject: Re: Re: bge driver issue Date: Sun, 23 Jun 2002 18:41:52 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Disposition-Notification-To: "Grant Cooper" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Ok, I have a small problem. I just bought 2 PCI Ethernet cards. I feel kind of stupid. But after I got the first one to connect to the internet to register my Card I decided to add the second. Not knowing I was getting the wrong MAC address's. I'm not getting all 0's like the rest, but 4:0:4:0:4:0 I think I can get around this problem by calling my ISP and manally setting the IP because I know I can reach there login Page. Is this a problem? I have a ADMtek AN985 10/100BaseTX made by CICERO. I know both cards work because I tested them out on my Windows box. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jun 23 19: 0:45 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id 67D5337B411 for ; Sun, 23 Jun 2002 19:00:12 -0700 (PDT) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020624020011.CIDL2751.rwcrmhc52.attbi.com@InterJet.elischer.org>; Mon, 24 Jun 2002 02:00:11 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id SAA49467; Sun, 23 Jun 2002 18:53:33 -0700 (PDT) Date: Sun, 23 Jun 2002 18:53:32 -0700 (PDT) From: Julian Elischer To: Damian Gerow Cc: freebsd-net@freebsd.org, brian@awfulhak.org Subject: Re: Native PPPoE broken (4.6-STABLE), RP-PPPoE working?! In-Reply-To: <200206232309.g5NN9asS001943@coal.sentex.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sun, 23 Jun 2002, Damian Gerow wrote: > I've been working with Mike Tancsa for the past little while, > trying to figure out why the new concentrators that are being > deployed in Canada are causing problems with some (notably > the FreeBSD) PPPoE implementations -- the end result being > horribly slow to nonexistant speeds. > > After spending a couple of hours getting it to compile, I > got Roaring Penguin (latest release) and pppd-3.11 compiled > and installed on my 4.6-STABLE (June 17) box, and connected > it just fine. Speeds are exactly as expected, and there's > *no* slowness at all. define "slowness"? Does RP attach to 'ppp' or does it supply it's own? > > So it appears that the in-kernel PPPoE implementation is > broken, and Roaring Pengiun's is working? (Or that the > new concentrator is breaking from the spec, and causing > problems with the in-kernel implementation...) This is my guess, I've seen this before.. some manufacturers asssume that if it works with W95 they can stop testing and often thay make assumptions about the parts of the spec that they shouldn't.... for example, I send a 32 bit integer as the binary 'cookie' but some assume it must be ascii becasue that's what some Microsoft implememtation used. The spec just specifies N unique bytes. > > - Damian > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jun 23 20:30:49 2002 Delivered-To: freebsd-net@freebsd.org Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by hub.freebsd.org (Postfix) with ESMTP id 65D2037B403 for ; Sun, 23 Jun 2002 20:30:45 -0700 (PDT) Received: from house (cage.simianscience.com [64.7.134.1]) by smtp1.sentex.ca (8.12.3/8.12.3) with SMTP id g5O3UgdR056337; Sun, 23 Jun 2002 23:30:42 -0400 (EDT) (envelope-from mike@sentex.net) From: Mike Tancsa To: Julian Elischer Cc: freebsd-net@freebsd.org Subject: Re: Native PPPoE broken (4.6-STABLE), RP-PPPoE working?! Date: Sun, 23 Jun 2002 23:29:01 -0400 Message-ID: References: <200206232309.g5NN9asS001943@coal.sentex.ca> In-Reply-To: X-Mailer: Forte Agent 1.8/32.548 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sun, 23 Jun 2002 18:53:32 -0700 (PDT), in sentex.lists.freebsd.net you wrote: >> After spending a couple of hours getting it to compile, I >> got Roaring Penguin (latest release) and pppd-3.11 compiled >> and installed on my 4.6-STABLE (June 17) box, and connected >> it just fine. Speeds are exactly as expected, and there's >> *no* slowness at all. > >define "slowness"? Hi, about 300 or 400 bytes per second (yes, bytes per second, not kBytes or kbits) >Does RP attach to 'ppp' or does it supply it's own? I think Damian had to compile an update PPPd (3.11) to make it work >> So it appears that the in-kernel PPPoE implementation is >> broken, and Roaring Pengiun's is working? (Or that the >> new concentrator is breaking from the spec, and causing >> problems with the in-kernel implementation...) > >This is my guess, I've seen this before.. >some manufacturers asssume that if it works with W95 they >can stop testing and often thay make assumptions about the >parts of the spec that they shouldn't.... Quite possibly. The hard part to explain to the manufacture is that it works with Windows 95,98, XP, 2000, Linux and a Cisco 827. It does not work with =46reeBSD ---Mike Mike Tancsa (mdtancsa@sentex.net) =09 Sentex Communications Corp, =09 Waterloo, Ontario, Canada "Given enough time, 100 monkeys on 100 routers=20 could setup a national IP network." (KDW2) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jun 23 22:36:37 2002 Delivered-To: freebsd-net@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 7922237B401; Sun, 23 Jun 2002 22:36:29 -0700 (PDT) Received: (from ken@localhost) by panzer.kdm.org (8.11.6/8.9.1) id g5O5aSp44275; Sun, 23 Jun 2002 23:36:28 -0600 (MDT) (envelope-from ken) Date: Sun, 23 Jun 2002 23:36:28 -0600 From: "Kenneth D. Merry" To: current@FreeBSD.org Cc: net@FreeBSD.org, gallatin@FreeBSD.org, wpaul@FreeBSD.org, bmilekic@FreeBSD.org, alc@FreeBSD.org Subject: zero copy code checkin in 2 days, new snapshot Message-ID: <20020623233627.A44237@panzer.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I'm planning on checking in the zero copy sockets code Tuesday evening, MDT. If there are any concerns, I'm more than willing to delay it. I've also released a new snapshot, based on -current from June 23rd, 2002: http://people.freebsd.org/~ken/zero_copy/ The following changes went into this snapshot: - Added a zero_copy(9) man page that describes the general characteristics of the zero copy send and receive code, and what an application author should do to take advantage of the code. - Update the ti(4) man page to include information on the ioctl interface and the TI_JUMBO_HDRSPLIT and TI_PRIVATE_JUMBOS kernel options. - Added information to NOTES about the ZERO_COPY_SOCKETS, TI_PRIVATE_JUMBOS, TI_JUMBO_HDRSPLIT, MSIZE and MCLSHIFT kernel config options. - ti(4) driver cleanup: cleaned up some unused code, commented out some stray diagnostic printfs, and added a problem describing the transmit flow control problem for posterity. - Added a new jumbo(9) man page that describes the jumbo allocator. I haven't run this through the usual array of regression tests just yet, but that will be done before checkin. (I used the time to run through a buildworld and a LINT build instead.) Feedback and comments are welcome. Again, if there are any concerns, I'm more than willing to delay the checkin. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jun 23 23: 0:22 2002 Delivered-To: freebsd-net@freebsd.org Received: from sccrmhc03.attbi.com (sccrmhc03.attbi.com [204.127.202.63]) by hub.freebsd.org (Postfix) with ESMTP id 527C937B406 for ; Sun, 23 Jun 2002 23:00:12 -0700 (PDT) Received: from InterJet.elischer.org ([12.232.206.8]) by sccrmhc03.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020624060011.KYA20219.sccrmhc03.attbi.com@InterJet.elischer.org>; Mon, 24 Jun 2002 06:00:11 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id WAA50411; Sun, 23 Jun 2002 22:54:33 -0700 (PDT) Date: Sun, 23 Jun 2002 22:54:32 -0700 (PDT) From: Julian Elischer To: Mike Tancsa Cc: freebsd-net@freebsd.org Subject: Re: Native PPPoE broken (4.6-STABLE), RP-PPPoE working?! In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sun, 23 Jun 2002, Mike Tancsa wrote: > On Sun, 23 Jun 2002 18:53:32 -0700 (PDT), in sentex.lists.freebsd.net you > wrote: > >> After spending a couple of hours getting it to compile, I > >> got Roaring Penguin (latest release) and pppd-3.11 compiled > >> and installed on my 4.6-STABLE (June 17) box, and connected > >> it just fine. Speeds are exactly as expected, and there's > >> *no* slowness at all. > > > >define "slowness"? > Hi, > > about 300 or 400 bytes per second (yes, bytes per second, not kBytes or > kbits) > > >Does RP attach to 'ppp' or does it supply it's own? > > I think Damian had to compile an update PPPd (3.11) to make it work It seems hard to understand how the pppoe node in the kernel can slow things down. It takes the ethernet packets decapsulates them and passes them to the next layer. However if there is some latency added it should show up in a comparative analysis of tcpdump and ppp logs. (comparing the times that a packet arrived at the interface and the time that PPP thiks it got the packet. > > >> So it appears that the in-kernel PPPoE implementation is > >> broken, and Roaring Pengiun's is working? (Or that the > >> new concentrator is breaking from the spec, and causing > >> problems with the in-kernel implementation...) > > > >This is my guess, I've seen this before.. > >some manufacturers asssume that if it works with W95 they > >can stop testing and often thay make assumptions about the > >parts of the spec that they shouldn't.... > > Quite possibly. The hard part to explain to the manufacture is that it > works with > Windows 95,98, XP, 2000, Linux and a Cisco 827. > It does not work with > FreeBSD I undertsand and we want to try figure out what the problem is.. regardless of who is doing what wrong according to the standard.. > > ---Mike > Mike Tancsa (mdtancsa@sentex.net) > Sentex Communications Corp, > Waterloo, Ontario, Canada > "Given enough time, 100 monkeys on 100 routers > could setup a national IP network." (KDW2) > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jun 23 23:15: 3 2002 Delivered-To: freebsd-net@freebsd.org Received: from patrocles.silby.com (d160.as28.nwbl0.wi.voyager.net [169.207.71.226]) by hub.freebsd.org (Postfix) with ESMTP id 2F7D837B401; Sun, 23 Jun 2002 23:14:58 -0700 (PDT) Received: from patrocles.silby.com (localhost [127.0.0.1]) by patrocles.silby.com (8.12.4/8.12.4) with ESMTP id g5O6H7cv051276; Mon, 24 Jun 2002 01:17:07 -0500 (CDT) (envelope-from silby@silby.com) Received: from localhost (silby@localhost) by patrocles.silby.com (8.12.4/8.12.4/Submit) with ESMTP id g5O6H4D4051273; Mon, 24 Jun 2002 01:17:06 -0500 (CDT) X-Authentication-Warning: patrocles.silby.com: silby owned process doing -bs Date: Mon, 24 Jun 2002 01:17:03 -0500 (CDT) From: Mike Silbersack To: "Kenneth D. Merry" Cc: net@freebsd.org, Subject: Re: zero copy code checkin in 2 days, new snapshot In-Reply-To: <20020623233627.A44237@panzer.kdm.org> Message-ID: <20020624011221.L50974-100000@patrocles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sun, 23 Jun 2002, Kenneth D. Merry wrote: > I'm planning on checking in the zero copy sockets code Tuesday evening, > MDT. If there are any concerns, I'm more than willing to delay it. Out of curiousity, what happens when the page being write()n is a mmap'd page shared by multiple processes? Will the page be shared? That could be a big reduction in mbuf cluster usage on some http/ftp systems, I'd guess. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jun 23 23:21:30 2002 Delivered-To: freebsd-net@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id BD8B337B401; Sun, 23 Jun 2002 23:21:18 -0700 (PDT) Received: (from ken@localhost) by panzer.kdm.org (8.11.6/8.9.1) id g5O6L6W44543; Mon, 24 Jun 2002 00:21:06 -0600 (MDT) (envelope-from ken) Date: Mon, 24 Jun 2002 00:21:06 -0600 From: "Kenneth D. Merry" To: Mike Silbersack Cc: net@freebsd.org, current@freebsd.org Subject: Re: zero copy code checkin in 2 days, new snapshot Message-ID: <20020624002106.A44519@panzer.kdm.org> References: <20020623233627.A44237@panzer.kdm.org> <20020624011221.L50974-100000@patrocles.silby.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020624011221.L50974-100000@patrocles.silby.com>; from silby@silby.com on Mon, Jun 24, 2002 at 01:17:03AM -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, Jun 24, 2002 at 01:17:03 -0500, Mike Silbersack wrote: > On Sun, 23 Jun 2002, Kenneth D. Merry wrote: > > > I'm planning on checking in the zero copy sockets code Tuesday evening, > > MDT. If there are any concerns, I'm more than willing to delay it. > > Out of curiousity, what happens when the page being write()n is a mmap'd > page shared by multiple processes? Will the page be shared? That could > be a big reduction in mbuf cluster usage on some http/ftp systems, I'd > guess. The page would be shared, until one of the processes decides to write to it while it is still referenced in the kernel. If that happens, it'll get copied. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jun 24 9:10:13 2002 Delivered-To: freebsd-net@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 1381437B400; Mon, 24 Jun 2002 09:10:09 -0700 (PDT) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 44CAD5361; Mon, 24 Jun 2002 18:10:06 +0200 (CEST) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: "Kenneth D. Merry" Cc: current@FreeBSD.org, net@FreeBSD.org, gallatin@FreeBSD.org, wpaul@FreeBSD.org, bmilekic@FreeBSD.org, alc@FreeBSD.org Subject: Re: zero copy code checkin in 2 days, new snapshot References: <20020623233627.A44237@panzer.kdm.org> From: Dag-Erling Smorgrav Date: 24 Jun 2002 18:10:06 +0200 In-Reply-To: <20020623233627.A44237@panzer.kdm.org> Message-ID: Lines: 9 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org "Kenneth D. Merry" writes: > I'm planning on checking in the zero copy sockets code Tuesday evening, > MDT. Great! DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jun 24 10: 2:59 2002 Delivered-To: freebsd-net@freebsd.org Received: from patrocles.silby.com (d91.as7.nwbl0.wi.voyager.net [169.207.128.219]) by hub.freebsd.org (Postfix) with ESMTP id 9327037B40B; Mon, 24 Jun 2002 10:02:04 -0700 (PDT) Received: from patrocles.silby.com (localhost [127.0.0.1]) by patrocles.silby.com (8.12.4/8.12.4) with ESMTP id g5OH4Hcv053382; Mon, 24 Jun 2002 12:04:17 -0500 (CDT) (envelope-from silby@silby.com) Received: from localhost (silby@localhost) by patrocles.silby.com (8.12.4/8.12.4/Submit) with ESMTP id g5OH4Fqg053379; Mon, 24 Jun 2002 12:04:16 -0500 (CDT) X-Authentication-Warning: patrocles.silby.com: silby owned process doing -bs Date: Mon, 24 Jun 2002 12:04:14 -0500 (CDT) From: Mike Silbersack To: "Kenneth D. Merry" Cc: net@freebsd.org, Subject: Re: zero copy code checkin in 2 days, new snapshot In-Reply-To: <20020624002106.A44519@panzer.kdm.org> Message-ID: <20020624120341.K53369-100000@patrocles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, 24 Jun 2002, Kenneth D. Merry wrote: > On Mon, Jun 24, 2002 at 01:17:03 -0500, Mike Silbersack wrote: > > On Sun, 23 Jun 2002, Kenneth D. Merry wrote: > > > > > I'm planning on checking in the zero copy sockets code Tuesday evening, > > > MDT. If there are any concerns, I'm more than willing to delay it. > > > > Out of curiousity, what happens when the page being write()n is a mmap'd > > page shared by multiple processes? Will the page be shared? That could > > be a big reduction in mbuf cluster usage on some http/ftp systems, I'd > > guess. > > The page would be shared, until one of the processes decides to write to it > while it is still referenced in the kernel. If that happens, it'll get > copied. > > Ken Cool, thttpd / others should benefit greatly then. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jun 24 10:13: 7 2002 Delivered-To: freebsd-net@freebsd.org Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by hub.freebsd.org (Postfix) with SMTP id 2F76037B40A for ; Mon, 24 Jun 2002 10:12:52 -0700 (PDT) Received: (qmail 94370 invoked from network); 24 Jun 2002 17:12:02 -0000 Received: from unknown (HELO tix.ch) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 24 Jun 2002 17:12:02 -0000 Message-ID: <3D1752CC.B21627F1@tix.ch> Date: Mon, 24 Jun 2002 19:11:40 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mike Silbersack Cc: "Kenneth D. Merry" , net@freebsd.org, current@freebsd.org Subject: Re: zero copy code checkin in 2 days, new snapshot References: <20020624120341.K53369-100000@patrocles.silby.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Mike Silbersack wrote: > > On Mon, 24 Jun 2002, Kenneth D. Merry wrote: > > > On Mon, Jun 24, 2002 at 01:17:03 -0500, Mike Silbersack wrote: > > > On Sun, 23 Jun 2002, Kenneth D. Merry wrote: > > > > > > > I'm planning on checking in the zero copy sockets code Tuesday evening, > > > > MDT. If there are any concerns, I'm more than willing to delay it. > > > > > > Out of curiousity, what happens when the page being write()n is a mmap'd > > > page shared by multiple processes? Will the page be shared? That could > > > be a big reduction in mbuf cluster usage on some http/ftp systems, I'd > > > guess. > > > > The page would be shared, until one of the processes decides to write to it > > while it is still referenced in the kernel. If that happens, it'll get > > copied. > > > > Ken > > Cool, thttpd / others should benefit greatly then. The last time I checked thttpd didn't even use sendfile(2). It does use accf_http(9). Maybe kqueue(2) could speed it up further. -- Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jun 24 10:21:39 2002 Delivered-To: freebsd-net@freebsd.org Received: from patrocles.silby.com (d91.as7.nwbl0.wi.voyager.net [169.207.128.219]) by hub.freebsd.org (Postfix) with ESMTP id 0308937B41B; Mon, 24 Jun 2002 10:20:58 -0700 (PDT) Received: from patrocles.silby.com (localhost [127.0.0.1]) by patrocles.silby.com (8.12.4/8.12.4) with ESMTP id g5OHNBcv053469; Mon, 24 Jun 2002 12:23:11 -0500 (CDT) (envelope-from silby@silby.com) Received: from localhost (silby@localhost) by patrocles.silby.com (8.12.4/8.12.4/Submit) with ESMTP id g5OHN997053466; Mon, 24 Jun 2002 12:23:11 -0500 (CDT) X-Authentication-Warning: patrocles.silby.com: silby owned process doing -bs Date: Mon, 24 Jun 2002 12:23:09 -0500 (CDT) From: Mike Silbersack To: Andre Oppermann Cc: "Kenneth D. Merry" , , Subject: Re: zero copy code checkin in 2 days, new snapshot In-Reply-To: <3D1752CC.B21627F1@tix.ch> Message-ID: <20020624122147.G53369-100000@patrocles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, 24 Jun 2002, Andre Oppermann wrote: > Mike Silbersack wrote: > > Cool, thttpd / others should benefit greatly then. > > The last time I checked thttpd didn't even use sendfile(2). It does > use accf_http(9). Maybe kqueue(2) could speed it up further. > > -- > Andre I thought that thttpd used kqueue (as of recent versions), and write()s from mmap'd files. I could be wrong, of course. (The program seems to evolve relatively quickly.) Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jun 24 10:33:46 2002 Delivered-To: freebsd-net@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id 46ECD37B40C; Mon, 24 Jun 2002 10:33:05 -0700 (PDT) Received: by elvis.mu.org (Postfix, from userid 1192) id A29CCAE147; Mon, 24 Jun 2002 10:33:05 -0700 (PDT) Date: Mon, 24 Jun 2002 10:33:05 -0700 From: Alfred Perlstein To: Mike Silbersack Cc: Andre Oppermann , "Kenneth D. Merry" , net@freebsd.org, current@freebsd.org Subject: Re: zero copy code checkin in 2 days, new snapshot Message-ID: <20020624173305.GW53232@elvis.mu.org> References: <3D1752CC.B21627F1@tix.ch> <20020624122147.G53369-100000@patrocles.silby.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020624122147.G53369-100000@patrocles.silby.com> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org * Mike Silbersack [020624 10:24] wrote: > > On Mon, 24 Jun 2002, Andre Oppermann wrote: > > > Mike Silbersack wrote: > > > Cool, thttpd / others should benefit greatly then. > > > > The last time I checked thttpd didn't even use sendfile(2). It does > > use accf_http(9). Maybe kqueue(2) could speed it up further. > > > > -- > > Andre > > I thought that thttpd used kqueue (as of recent versions), and write()s > from mmap'd files. I could be wrong, of course. (The program seems to > evolve relatively quickly.) I submitted some patches to use sendfile(2) that weren't accepted for some reason. It's not too hard, you just have to adjust the code not to close(2) the descriptors and make the mmap() function a stub type thing. really out of date... http://people.freebsd.org/~alfred/thttpd/thttpd-sendfile-acceptfilter.diff -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jun 24 12:22: 6 2002 Delivered-To: freebsd-net@freebsd.org Received: from earth.hub.org (earth.hub.org [64.49.215.11]) by hub.freebsd.org (Postfix) with ESMTP id 3363437B403 for ; Mon, 24 Jun 2002 12:22:01 -0700 (PDT) Received: from earth.hub.org (earth.hub.org [64.49.215.11]) by earth.hub.org (Postfix) with ESMTP id 410F22CCA87 for ; Mon, 24 Jun 2002 16:21:59 -0300 (ADT) Date: Mon, 24 Jun 2002 16:21:59 -0300 (ADT) From: "Marc G. Fournier" To: freebsd-net@freebsd.org Subject: using natd to proxy through a jail ... ? Message-ID: <20020624162019.P20796-100000@mail1.hub.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Looking at the man page, I'm wondering if its possible to use natd to proxy port X coming into a jail to an IP:port that is sitting behind that jail ... For instance, I have two machines ... one holds the jail, the other holds a database server ... jail is accessible from the 'Net, but the database server is only accessible to the jail, so I want to proxy a connection *through* the jail to the database itself ... Would this work? Thanks ... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jun 24 12:51:16 2002 Delivered-To: freebsd-net@freebsd.org Received: from jhs.muc.de (pD9EB72AA.dip.t-dialin.net [217.235.114.170]) by hub.freebsd.org (Postfix) with ESMTP id B103337B40C for ; Mon, 24 Jun 2002 12:49:45 -0700 (PDT) Received: from lapa.jhs.private (lapa.jhs.private [192.168.91.45]) by jhs.muc.de (8.11.6/8.11.6) with ESMTP id g5OJnlF03492; Mon, 24 Jun 2002 21:49:47 +0200 (MET DST) (envelope-from jhs@jhs.muc.de) Received: from lapa.jhs.private (localhost [127.0.0.1]) by lapa.jhs.private (8.11.6/8.11.6) with ESMTP id g5OJnjq01221; Mon, 24 Jun 2002 19:49:46 GMT (envelope-from jhs@lapa.jhs.private) Message-Id: <200206241949.g5OJnjq01221@lapa.jhs.private> To: Mike Tancsa Cc: freebsd-net@FreeBSD.ORG, Udo.Erdelhoff@gmx.net Subject: Re: tracking down strange MTU issues with PPPoE) In-Reply-To: Message from Mike Tancsa of "Tue, 18 Jun 2002 16:54:49 EDT." <5.1.0.14.0.20020618163928.05018cf0@marble.sentex.ca> Date: Mon, 24 Jun 2002 21:49:45 +0200 From: "Julian H. Stacey" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Mike Tancsa wrote: Re DSL ... > (Note, I have tried various MTU and MRU settings. > Thanks for any pointers. Perhaps you need /usr/ports/net/tcpmssd - TCP Maximum Segment Size option corrector I recently got DSL with Deutsche Telekom, then read the very enjoyable http://www.ruhr.de/home/nathan/FreeBSD/tdsl-freebsd.html Author: Udo.Erdelhoff@gmx.net Language: German (which luckily I speak, but config fragments are readable by all of course) & I got the impression I too would have a problem & need to install tcpmssd, but your mail has reminded I haven't seemed to need to yet, & on looking with netstat -I tun0 Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll tun0 1492 116652 0 83310 0 0 tun0 1492 fe80:14::20 fe80:14::200:b4ff 0 - 0 - - tun0 1492 217.235.114 pD9EB72AA.dip.t 103126 - 72229 - - so with 1492 I guess I havent noticed many failed connections. Good luck, I hope tcpmssd helps. Julian Stacey Munich Unix (FreeBSD, Linux etc) Independent Consultant jhs@bim.bsn.com http://bim.bsn.com/~jhs/ Ihr Rauchen = mein allergischer Kopfschmerz ! Schnupftabak probieren ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jun 24 12:56:55 2002 Delivered-To: freebsd-net@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id DBFAD37B404; Mon, 24 Jun 2002 12:56:24 -0700 (PDT) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.4/8.12.2) with ESMTP id g5OJuNo3003371; Mon, 24 Jun 2002 12:56:23 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.4/8.12.4/Submit) id g5OJuMf8003368; Mon, 24 Jun 2002 12:56:22 -0700 (PDT) Date: Mon, 24 Jun 2002 12:56:22 -0700 From: "David O'Brien" To: Alfred Perlstein Cc: Mike Silbersack , Andre Oppermann , "Kenneth D. Merry" , net@freebsd.org, current@freebsd.org Subject: Re: zero copy code checkin in 2 days, new snapshot Message-ID: <20020624125622.B3130@dragon.nuxi.com> Reply-To: obrien@freebsd.org Mail-Followup-To: David O'Brien , Alfred Perlstein , Mike Silbersack , Andre Oppermann , "Kenneth D. Merry" , net@freebsd.org, current@freebsd.org References: <3D1752CC.B21627F1@tix.ch> <20020624122147.G53369-100000@patrocles.silby.com> <20020624173305.GW53232@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020624173305.GW53232@elvis.mu.org>; from bright@mu.org on Mon, Jun 24, 2002 at 10:33:05AM -0700 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, Jun 24, 2002 at 10:33:05AM -0700, Alfred Perlstein wrote: > I submitted some patches to use sendfile(2) that weren't accepted > for some reason. It's not too hard, you just have to adjust the code > not to close(2) the descriptors and make the mmap() function a stub > type thing. > > really out of date... > http://people.freebsd.org/~alfred/thttpd/thttpd-sendfile-acceptfilter.diff Why don't you add them as patches to the port? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jun 24 12:58:24 2002 Delivered-To: freebsd-net@freebsd.org Received: from obsidian.sentex.ca (obsidian.sentex.ca [64.7.128.101]) by hub.freebsd.org (Postfix) with ESMTP id D3F4437B445 for ; Mon, 24 Jun 2002 12:56:51 -0700 (PDT) Received: from simian.sentex.net (pyroxene.sentex.ca [199.212.134.18]) by obsidian.sentex.ca (8.12.2/8.12.2) with ESMTP id g5OJunMn094850; Mon, 24 Jun 2002 15:56:50 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <5.1.0.14.0.20020624155731.0205c700@marble.sentex.ca> X-Sender: mdtpop@marble.sentex.ca X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 24 Jun 2002 15:59:39 -0400 To: "Julian H. Stacey" From: Mike Tancsa Subject: Re: tracking down strange MTU issues with PPPoE) Cc: freebsd-net@FreeBSD.ORG, Udo.Erdelhoff@gmx.net In-Reply-To: <200206241949.g5OJnjq01221@lapa.jhs.private> References: <5.1.0.14.0.20020618163928.05018cf0@marble.sentex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: By Sentex Communications (obsidian/20020220) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, Thanks for the suggestion. If I recall correctly, the tcpmssd daemon was to fix client connection issue behind the FreeBSD box, not directly from the FreeBSD box. The problems we are seeing are directly on the FreeBSD box, but only with certain DSL concentrators. Also, I thought the ppp client on FreeBSD has the mss fix built in. from the ppp man pages, [tcp]mssfixup Default: Enabled. This option tells ppp to adjust TCP SYN pack- ets so that the maximum receive segment size is not greater than the amount allowed by the interface MTU. ---Mike At 09:49 PM 24/06/2002 +0200, Julian H. Stacey wrote: >Mike Tancsa wrote: >Re DSL ... > > > (Note, I have tried various MTU and MRU settings. > > Thanks for any pointers. > >Perhaps you need /usr/ports/net/tcpmssd > - TCP Maximum Segment Size option corrector > >I recently got DSL with Deutsche Telekom, then read the very enjoyable > http://www.ruhr.de/home/nathan/FreeBSD/tdsl-freebsd.html > Author: Udo.Erdelhoff@gmx.net > Language: German (which luckily I speak, but config fragments > are readable by all of course) >& I got the impression I too would have a problem & need to install >tcpmssd, but your mail has reminded I haven't seemed to need to yet, >& on looking with netstat -I tun0 > Name Mtu Network Address Ipkts Ierrs Opkts > Oerrs Coll > tun0 1492 116652 0 83310 0 > 0 > tun0 1492 fe80:14::20 > fe80:14::200:b4ff 0 - 0 - - > tun0 1492 217.235.114 pD9EB72AA.dip.t 103126 - 72229 - > - >so with 1492 I guess I havent noticed many failed connections. >Good luck, I hope tcpmssd helps. > >Julian Stacey Munich Unix (FreeBSD, Linux etc) Independent >Consultant >jhs@bim.bsn.com http://bim.bsn.com/~jhs/ > Ihr Rauchen = mein allergischer Kopfschmerz ! Schnupftabak > probieren ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jun 24 14:20:46 2002 Delivered-To: freebsd-net@freebsd.org Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by hub.freebsd.org (Postfix) with ESMTP id DAC8C37B4A6 for ; Mon, 24 Jun 2002 14:20:15 -0700 (PDT) Received: from InterJet.elischer.org ([12.232.206.8]) by sccrmhc02.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020624212015.WISX10417.sccrmhc02.attbi.com@InterJet.elischer.org> for ; Mon, 24 Jun 2002 21:20:15 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id OAA54144 for ; Mon, 24 Jun 2002 14:20:12 -0700 (PDT) Date: Mon, 24 Jun 2002 14:20:05 -0700 (PDT) From: Julian Elischer To: net@freebsd.org Subject: apache and option USE_FLOCK_SERIALIZED_ACCEPT Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org for FreeBSD we seem to get this option set.. this seems bogus.. it assumes that multiple processes can't listen on the accept at one time... does anyone know if FreeBSD is safe for having multiple processes do accept() on the same listenning socket? My perusal of the code suggests it should be but I'm unsure why the option is set by default for FreeBSD. WHat it does is allow only one process to do an accept at one time, by using a file flock() as a semaphore... seems to be it should be un-needed. am I dreaming? what am I missing? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jun 24 14:34:32 2002 Delivered-To: freebsd-net@freebsd.org Received: from alive.znep.com (sense-sea-MegaSub-1-448.oz.net [216.39.145.194]) by hub.freebsd.org (Postfix) with ESMTP id A75B037B401 for ; Mon, 24 Jun 2002 14:34:27 -0700 (PDT) Received: from localhost (marcs@localhost) by alive.znep.com (8.9.3/8.9.3) with ESMTP id OAA88437; Mon, 24 Jun 2002 14:34:24 -0700 (PDT) (envelope-from marcs@znep.com) Date: Mon, 24 Jun 2002 14:34:24 -0700 (PDT) From: Marc Slemko To: Julian Elischer Cc: net@FreeBSD.ORG Subject: Re: apache and option USE_FLOCK_SERIALIZED_ACCEPT In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, 24 Jun 2002, Julian Elischer wrote: > > for FreeBSD we seem to get this option set.. > > this seems bogus.. > > it assumes that multiple processes can't listen on the accept > at one time... That is one use for accept serialization. However, the other reason has to do with multiple listening sockets and how Apache deals with them. Apache does a select() on all listening sockets, waiting for a connection to be ready on one. eg. different virtual hosts. That select() returns a set of sockets, we then do an accept() on one. Without accept serialization, there is a race condition where one child could do the select(), then another child could come in, do the select() do the accept() and accept the connection, then the first child's accept() blocks. If this happens too much, you end up with children blocked in accept() on one listening socket, which leaves no children to process requests from other listening sockets. > does anyone know if FreeBSD is safe for having multiple processes do > accept() on the same listenning socket? Yes, it is. FreeBSD also gets SINGLE_LISTEN_UNSERIALIZED_ACCEPT set, which says to not use accept serialization if you only have a single listen socket, since then the above worry doesn't matter. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jun 24 14:38:30 2002 Delivered-To: freebsd-net@freebsd.org Received: from mta7.pltn13.pbi.net (mta7.pltn13.pbi.net [64.164.98.8]) by hub.freebsd.org (Postfix) with ESMTP id 993A637B40B for ; Mon, 24 Jun 2002 14:37:59 -0700 (PDT) Received: from FreeBSD.org ([63.193.112.125]) by mta7.pltn13.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GY8008XFC3BEQ@mta7.pltn13.pbi.net> for net@freebsd.org; Mon, 24 Jun 2002 14:37:59 -0700 (PDT) Date: Mon, 24 Jun 2002 14:38:37 -0700 From: Jeffrey Hsu Subject: Re: apache and option USE_FLOCK_SERIALIZED_ACCEPT In-reply-to: Message from Julian Elischer "of Mon, 24 Jun 2002 14:20:05 PDT." To: Julian Elischer Cc: net@freebsd.org Message-id: <0GY8008XGC3BEQ@mta7.pltn13.pbi.net> MIME-version: 1.0 X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > does anyone know if FreeBSD is safe for having multiple processes do > accept() on the same listenning socket? I wrote a program on FreeBSD several years ago that does exactly this with multiple rforked child processes. In fact, someone recompiled my program on FreeBSD 4.5 last month to move it to a new server and the whole thing still works. Jeffrey To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jun 24 14:50:44 2002 Delivered-To: freebsd-net@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id 1D0DC37B401 for ; Mon, 24 Jun 2002 14:50:42 -0700 (PDT) Received: by elvis.mu.org (Postfix, from userid 1192) id E8D0FAE163; Mon, 24 Jun 2002 14:50:41 -0700 (PDT) Date: Mon, 24 Jun 2002 14:50:41 -0700 From: Alfred Perlstein To: Julian Elischer Cc: net@freebsd.org Subject: Re: apache and option USE_FLOCK_SERIALIZED_ACCEPT Message-ID: <20020624215041.GA53232@elvis.mu.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org * Julian Elischer [020624 14:20] wrote: > > for FreeBSD we seem to get this option set.. > > this seems bogus.. > > it assumes that multiple processes can't listen on the accept > at one time... > > does anyone know if FreeBSD is safe for having multiple processes do > accept() on the same listenning socket? > > My perusal of the code suggests it should be but > I'm unsure why the option is set by default for FreeBSD. > > WHat it does is allow only one process to do an accept at one time, > by using a file flock() as a semaphore... > > seems to be it should be un-needed. > > am I dreaming? what am I missing? Having multiple processes blocked in accept(2) is ok, however having multiple processes blocking in select(2) on the same objects can cause select collisions which cause superfolous wakeup()s and much pain. The flock when listening on multiple sockets mitigates this _somewhat_, but still causes all processes to be woken up each time an accept succeeds because the flock is dropped. I think by using some sort of signalling between a single process doing select and the rest which get a signal telling them to call accept, or perhaps using fd passing might work better, but I'm unsure as I haven't had the time to actually do these modifications. Basically using some token passing mechanism instead of a broadcast system, however doing so introduces complexity of course. :) -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jun 24 15:20:33 2002 Delivered-To: freebsd-net@freebsd.org Received: from sccrmhc03.attbi.com (sccrmhc03.attbi.com [204.127.202.63]) by hub.freebsd.org (Postfix) with ESMTP id 3055C37B403 for ; Mon, 24 Jun 2002 15:20:08 -0700 (PDT) Received: from InterJet.elischer.org ([12.232.206.8]) by sccrmhc03.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020624222007.WRQS903.sccrmhc03.attbi.com@InterJet.elischer.org>; Mon, 24 Jun 2002 22:20:07 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id PAA54473; Mon, 24 Jun 2002 15:11:01 -0700 (PDT) Date: Mon, 24 Jun 2002 15:11:00 -0700 (PDT) From: Julian Elischer To: Marc Slemko Cc: net@FreeBSD.ORG Subject: Re: apache and option USE_FLOCK_SERIALIZED_ACCEPT In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, 24 Jun 2002, Marc Slemko wrote: > On Mon, 24 Jun 2002, Julian Elischer wrote: > > > > > for FreeBSD we seem to get this option set.. > > > > this seems bogus.. > > > > it assumes that multiple processes can't listen on the accept > > at one time... > > That is one use for accept serialization. > > However, the other reason has to do with multiple listening sockets and > how Apache deals with them. > > Apache does a select() on all listening sockets, waiting for a > connection to be ready on one. eg. different virtual hosts. > > That select() returns a set of sockets, we then do an accept() on one. OK then if we know we have only one listenning socket, (I presume that's what SINGLE_LISTEN_UNSERIALIZED_ACCEPT means) then it just uses a raw accept right? The proble we are seeing is apache occasionally has a process freeze while it has the token (flock) and everything comes to a grinding halt after a while... Since we have to upgrate now anyhow due to chunking (whatever that is) we'll see if maybe the problem is fixed with the upgrade..... > > Without accept serialization, there is a race condition where one child > could do the select(), then another child could come in, do the select() > do the accept() and accept the connection, then the first child's accept() > blocks. If this happens too much, you end up with children blocked in > accept() on one listening socket, which leaves no children to process > requests from other listening sockets. > > > does anyone know if FreeBSD is safe for having multiple processes do > > accept() on the same listenning socket? > > Yes, it is. > > FreeBSD also gets SINGLE_LISTEN_UNSERIALIZED_ACCEPT set, which says to > not use accept serialization if you only have a single listen socket, since > then the above worry doesn't matter. > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jun 24 15:33:52 2002 Delivered-To: freebsd-net@freebsd.org Received: from alive.znep.com (sense-sea-MegaSub-1-448.oz.net [216.39.145.194]) by hub.freebsd.org (Postfix) with ESMTP id 6DA6437B688 for ; Mon, 24 Jun 2002 15:32:46 -0700 (PDT) Received: from localhost (marcs@localhost) by alive.znep.com (8.9.3/8.9.3) with ESMTP id PAA89004; Mon, 24 Jun 2002 15:32:44 -0700 (PDT) (envelope-from marcs@znep.com) Date: Mon, 24 Jun 2002 15:32:44 -0700 (PDT) From: Marc Slemko To: Julian Elischer Cc: net@FreeBSD.ORG Subject: Re: apache and option USE_FLOCK_SERIALIZED_ACCEPT In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, 24 Jun 2002, Julian Elischer wrote: > OK then if we know we have only one listenning socket, > (I presume that's what SINGLE_LISTEN_UNSERIALIZED_ACCEPT means) > then it just uses a raw accept right? Yes. > The proble we are seeing is apache occasionally has a process > freeze while it has the token (flock) and everything comes to a grinding > halt after a while... "freeze"? Typically issues in this area have been due to flakey locking implementations, eg. doing file locking on a file mounted over NFS, but that shouldn't apply to freebsd. You could try disabling accept filters I guess (AcceptFilter off) if the current version is 1.3.21 or higher and they are supported in the kernel in use. > Since we have to upgrate now anyhow due to chunking (whatever that is) > we'll see if maybe the problem is fixed with the upgrade..... Possible, but likely not unless perhaps you are upgrading from a really old version. Also note that current versions of Apache 1.3 let you specify what accept mutex to use at runtime, so you should be able to play around with other options. Well, fcntl at least, not sure if anything else is supported on Apache on FreeBSD. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jun 24 16: 3:30 2002 Delivered-To: freebsd-net@freebsd.org Received: from mailsrv.otenet.gr (mailsrv.otenet.gr [195.170.0.5]) by hub.freebsd.org (Postfix) with ESMTP id 3BCA537B400; Mon, 24 Jun 2002 16:03:11 -0700 (PDT) Received: from hades.hell.gr (patr530-a110.otenet.gr [212.205.215.110]) by mailsrv.otenet.gr (8.12.3/8.12.3) with ESMTP id g5ON3515023962; Tue, 25 Jun 2002 02:03:06 +0300 (EEST) Received: from hades.hell.gr (hades [127.0.0.1]) by hades.hell.gr (8.12.4/8.12.4) with ESMTP id g5ON34IO003610; Tue, 25 Jun 2002 02:03:04 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from charon@localhost) by hades.hell.gr (8.12.4/8.12.4/Submit) id g5ON31MX003609; Tue, 25 Jun 2002 02:03:01 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Date: Tue, 25 Jun 2002 02:03:01 +0300 From: Giorgos Keramidas To: "David O'Brien" Cc: Alfred Perlstein , Mike Silbersack , Andre Oppermann , "Kenneth D. Merry" , net@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: zero copy code checkin in 2 days, new snapshot Message-ID: <20020624230301.GB3469@hades.hell.gr> References: <3D1752CC.B21627F1@tix.ch> <20020624122147.G53369-100000@patrocles.silby.com> <20020624173305.GW53232@elvis.mu.org> <20020624125622.B3130@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020624125622.B3130@dragon.nuxi.com> X-Operating-System: FreeBSD 5.0-CURRENT #0: Sun Jun 23 22:51:33 EEST 2002 X-PGP-Fingerprint: C1EB 0653 DB8B A557 3829 00F9 D60F 941A 3186 03B6 X-Phone: +30-944-116520 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On 2002-06-24 12:56 +0000, David O'Brien wrote: > On Mon, Jun 24, 2002 at 10:33:05AM -0700, Alfred Perlstein wrote: > > I submitted some patches to use sendfile(2) that weren't accepted > > for some reason. It's not too hard, you just have to adjust the code > > not to close(2) the descriptors and make the mmap() function a stub > > type thing. > > > > really out of date... > > http://people.freebsd.org/~alfred/thttpd/thttpd-sendfile-acceptfilter.diff > > Why don't you add them as patches to the port? Because he isn't prepared to maintain an external patch for an ever changing part of the vendor code? I don't blame him or anyone else much, if that's why... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jun 24 21:27:40 2002 Delivered-To: freebsd-net@freebsd.org Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by hub.freebsd.org (Postfix) with ESMTP id 8C7EB37B406 for ; Mon, 24 Jun 2002 21:27:28 -0700 (PDT) Received: from house (cage.simianscience.com [64.7.134.1]) by smtp2.sentex.ca (8.12.3/8.12.3) with SMTP id g5P4RPSU080177; Tue, 25 Jun 2002 00:27:25 -0400 (EDT) (envelope-from mike@sentex.net) From: Mike Tancsa To: Julian Elischer Cc: freebsd-net@freebsd.org Subject: Re: Native PPPoE broken (4.6-STABLE), RP-PPPoE working?! Date: Tue, 25 Jun 2002 00:25:49 -0400 Message-ID: <2trfhu0tbekq67seicn4amdovp7564ji62@4ax.com> References: In-Reply-To: X-Mailer: Forte Agent 1.8/32.548 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sun, 23 Jun 2002 22:54:32 -0700 (PDT), in sentex.lists.freebsd.net you wrote: > > >On Sun, 23 Jun 2002, Mike Tancsa wrote: > >> On Sun, 23 Jun 2002 18:53:32 -0700 (PDT), in sentex.lists.freebsd.net = you >> wrote: >> >> After spending a couple of hours getting it to compile, I >> >> got Roaring Penguin (latest release) and pppd-3.11 compiled >> >> and installed on my 4.6-STABLE (June 17) box, and connected >> >> it just fine. Speeds are exactly as expected, and there's >> >> *no* slowness at all. >> > >> >define "slowness"? >> Hi, >>=20 >> about 300 or 400 bytes per second (yes, bytes per second, not kBytes = or >> kbits) >>=20 >> >Does RP attach to 'ppp' or does it supply it's own? >>=20 >> I think Damian had to compile an update PPPd (3.11) to make it work > >It seems hard to understand how the pppoe node in the kernel can slow >things down.=20 Here is an example iscar% fetch ftp://ftp.sentex.net/netscape95.exe Receiving netscape95.exe (3512832 bytes): 100% 3512832 bytes transferred in 28.0 seconds (122.50 kBps) iscar%=20 But to=20 iscar% fetch ftp://ftp.isc.org/isc/bind9/9.2.1/bind-9.2.1.tar.gz Receiving bind-9.2.1.tar.gz (5021044 bytes): 0%^C 24684 bytes transferred in 153.6 seconds (160.71 Bps) fetch: transfer interrupted This was after about 2.5 minutes. This same machine connected to an SMS works fine. e.g. from my home (farther away from the CO) cage# fetch ftp://ftp.isc.org/isc/bind9/9.2.1/bind-9.2.1.tar.gz Receiving bind-9.2.1.tar.gz (5021044 bytes): 9%^C 480612 bytes transferred in 4.9 seconds (95.12 kBps) fetch: transfer interrupted No problems. Before deploying the machine connected to the ERX, it worked great against the SMS as did/does all our other deployed FreeBSD boxes. But with Roaring Penguin installed, no problems. With a machine behind a ciso 827, no problem. Running LINUX, no problem. Any thoughts on what to try next ? ---Mike Mike Tancsa (mdtancsa@sentex.net) =09 Sentex Communications Corp, =09 Waterloo, Ontario, Canada "Given enough time, 100 monkeys on 100 routers=20 could setup a national IP network." (KDW2) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jun 24 22:58:58 2002 Delivered-To: freebsd-net@freebsd.org Received: from mail.ruhr.de (in-ruhr4.ruhr.de [212.23.134.2]) by hub.freebsd.org (Postfix) with SMTP id 00C7E37B401 for ; Mon, 24 Jun 2002 22:58:47 -0700 (PDT) Received: (qmail 7191 invoked by uid 10); 25 Jun 2002 05:58:45 -0000 Received: (from ue@localhost) by nathan.ruhr.de (8.11.6/8.11.2) id g5P5uWP00973; Tue, 25 Jun 2002 07:56:32 +0200 (CEST) (envelope-from ue) Date: Tue, 25 Jun 2002 07:56:32 +0200 From: Udo Erdelhoff To: Mike Tancsa Cc: "Julian H. Stacey" , freebsd-net@FreeBSD.ORG Subject: Re: tracking down strange MTU issues with PPPoE) Message-ID: <20020625055632.GI67408@nathan.ruhr.de> Mail-Followup-To: Mike Tancsa , "Julian H. Stacey" , freebsd-net@FreeBSD.ORG References: <5.1.0.14.0.20020618163928.05018cf0@marble.sentex.ca> <5.1.0.14.0.20020624155731.0205c700@marble.sentex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.1.0.14.0.20020624155731.0205c700@marble.sentex.ca> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, On Mon, Jun 24, 2002 at 03:59:39PM -0400, Mike Tancsa wrote: > If I recall correctly, the tcpmssd > daemon was to fix client connection issue behind the FreeBSD box, not > directly from the FreeBSD box. exactly. The daemon enforces an upper limit on the MSS of any packet passing over the 'DSL link'. > Also, I thought the ppp client on FreeBSD has the mss fix built in. Yes, but the solution in PPP only allows you to lower the MSS to 1452 so that the return packet is never bigger than 1492 bytes. However, if you need an even lower MSS, you are still stuck with tcpmssd. I need to lower my MSS to about 1410 to get cvsup to work correctly. /s/Udo -- Abandon the search for Truth; settle for a good fantasy. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jun 24 23:41:10 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id 5B1EA37B49D for ; Mon, 24 Jun 2002 23:40:13 -0700 (PDT) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020625064012.JTKX26243.rwcrmhc52.attbi.com@InterJet.elischer.org>; Tue, 25 Jun 2002 06:40:12 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id XAA56343; Mon, 24 Jun 2002 23:37:06 -0700 (PDT) Date: Mon, 24 Jun 2002 23:37:05 -0700 (PDT) From: Julian Elischer To: Mike Tancsa Cc: freebsd-net@freebsd.org Subject: Re: Native PPPoE broken (4.6-STABLE), RP-PPPoE working?! In-Reply-To: <2trfhu0tbekq67seicn4amdovp7564ji62@4ax.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, 25 Jun 2002, Mike Tancsa wrote: > > > >It seems hard to understand how the pppoe node in the kernel can slow > >things down. > > Here is an example > I wasn;t saying there was a problem, just that my imagination is having a hard time coming up with an explanation.. I know that the answer has to be in tcpdump traces.. you can tcpdump on both the tun interface or the ethernet interface.. it may be worth doing both to see if there is any delay between the two.. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 25 2:22:34 2002 Delivered-To: freebsd-net@freebsd.org Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by hub.freebsd.org (Postfix) with SMTP id 3E96037B400 for ; Tue, 25 Jun 2002 02:22:24 -0700 (PDT) Received: (qmail 38339 invoked from network); 25 Jun 2002 09:21:33 -0000 Received: from unknown (HELO tix.ch) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 25 Jun 2002 09:21:33 -0000 Message-ID: <3D183606.BBD1DE54@tix.ch> Date: Tue, 25 Jun 2002 11:21:10 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mike Tancsa Cc: Julian Elischer , freebsd-net@freebsd.org Subject: Re: Native PPPoE broken (4.6-STABLE), RP-PPPoE working?! References: <2trfhu0tbekq67seicn4amdovp7564ji62@4ax.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Mike Tancsa wrote: > > On Sun, 23 Jun 2002 22:54:32 -0700 (PDT), in sentex.lists.freebsd.net you > wrote: > > > > > > >On Sun, 23 Jun 2002, Mike Tancsa wrote: > > > >> On Sun, 23 Jun 2002 18:53:32 -0700 (PDT), in sentex.lists.freebsd.net you > >> wrote: > >> >> After spending a couple of hours getting it to compile, I > >> >> got Roaring Penguin (latest release) and pppd-3.11 compiled > >> >> and installed on my 4.6-STABLE (June 17) box, and connected > >> >> it just fine. Speeds are exactly as expected, and there's > >> >> *no* slowness at all. > >> > > >> >define "slowness"? > >> Hi, > >> > >> about 300 or 400 bytes per second (yes, bytes per second, not kBytes or > >> kbits) > >> > >> >Does RP attach to 'ppp' or does it supply it's own? > >> > >> I think Damian had to compile an update PPPd (3.11) to make it work > > > >It seems hard to understand how the pppoe node in the kernel can slow > >things down. > > Here is an example > > iscar% fetch ftp://ftp.sentex.net/netscape95.exe > Receiving netscape95.exe (3512832 bytes): 100% > 3512832 bytes transferred in 28.0 seconds (122.50 kBps) > iscar% > > But to > > iscar% fetch ftp://ftp.isc.org/isc/bind9/9.2.1/bind-9.2.1.tar.gz > Receiving bind-9.2.1.tar.gz (5021044 bytes): 0%^C > 24684 bytes transferred in 153.6 seconds (160.71 Bps) > fetch: transfer interrupted > > This was after about 2.5 minutes. > > This same machine connected to an SMS works fine. > > e.g. from my home (farther away from the CO) > cage# fetch ftp://ftp.isc.org/isc/bind9/9.2.1/bind-9.2.1.tar.gz > Receiving bind-9.2.1.tar.gz (5021044 bytes): 9%^C > 480612 bytes transferred in 4.9 seconds (95.12 kBps) > fetch: transfer interrupted > > No problems. Before deploying the machine connected to the ERX, it worked > great against the SMS as did/does all our other deployed FreeBSD boxes. > > But with Roaring Penguin installed, no problems. With a machine behind a > ciso 827, no problem. Running LINUX, no problem. > > Any thoughts on what to try next ? > > ---Mike > > Mike Tancsa (mdtancsa@sentex.net) > Sentex Communications Corp, > Waterloo, Ontario, Canada > "Given enough time, 100 monkeys on 100 routers > could setup a national IP network." (KDW2) > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message There can be two problem areas: 1) some problem in the PPPoE part (unlikely) 2) some problem in the ppp part (probably) I suggest 2 because with pppd it seems to work. Could you put this into the ppp.conf and make the log available? set log All -- Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 25 3: 1:10 2002 Delivered-To: freebsd-net@freebsd.org Received: from hotmail.com (oe24.pav2.hotmail.com [64.4.36.81]) by hub.freebsd.org (Postfix) with ESMTP id 8A8E137B686; Tue, 25 Jun 2002 02:55:14 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 25 Jun 2002 02:55:11 -0700 X-Originating-IP: [203.144.144.233] From: "mont" To: Subject: =?windows-874?B?cGFydC10aW1lIDUsMDAwLTEwLDAwMCCk2LOh57fT5LTpICEhIQ==?= Date: Tue, 25 Jun 2002 16:45:57 +0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0205_01C21C67.C7D305E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 25 Jun 2002 09:55:11.0687 (UTC) FILETIME=[6581BD70:01C21C2E] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a multi-part message in MIME format. ------=_NextPart_000_0205_01C21C67.C7D305E0 Content-Type: text/plain; charset="windows-874" Content-Transfer-Encoding: quoted-printable = =C3=D0=BA=BA=A1=D2=C3=B7=D3=A7=D2=B9=A2=CD=A7=B8=D8=C3=A1=D4=A8=E3=B9=CD=B9= =D2=A4=B5 =B7=D3=E4=B4=E9=A7=E8=D2=C2 = =E1=C5=D0=CA=C3=E9=D2=A7=C3=D2=C2=E4=B4=E9=A7=D2=C1=A8=D2=A1=A1=D2=C3=B7=D3= =A7=D2=B9=BC=E8=D2=B9=C3=D0=BA=BA =BC=C1=C1=D5=C3=D2=C2=E4=B4=E9=C1=D2=A1=A1=C7=E8=D2 30,000 / = =E0=B4=D7=CD=B9 = =A8=D2=A1=A1=D2=C3=B7=D3=A7=D2=B9=E0=BE=D5=C2=A7=C7=D1=B9=C5=D0 2-3 = =AA=D1=E8=C7=E2=C1=A7=E0=B7=E8=D2=B9=D1=E9=B9 =E2=CD=A1=D2=CA=C1=D2=B6=D6=A7=A4=D8=B3=E1=C5=E9=C7 ! = =E0=CB=C5=D7=CD=E1=B5=E8=E0=BE=D5=C2=A7=A4=D8=B3=A8=D0=A4=C7=E9=D2=C1=D1=B9= =CB=C3=D7=CD=E0=BB=C5=E8=D2 =A1=D2=C3=BA=C3=C3=C2=D2=C2=E1=B9=D0=B9=D3=B8=D8=C3=A1=D4=A8 = International E-Business =E0=C3=D5=C2=B9=C3=D9=E9=C7=D4=B8=D5=A1=D2=C3=B7=D3=A7=D2=B9 = =B8=D8=C3=A1=D4=A8=B9=D2=B9=D2=AA=D2=B5=D4 =BA=B9 Internet=20 = =E0=C3=D5=C2=B9=C3=D9=E9=E1=BC=B9=A1=D2=C3=B7=D3=A7=D2=B9=E0=BE=D4=E8=C1=C3= =D2=C2=E4=B4=E9=BE=D4=E0=C8=C9=E3=B9=E1=B5=E8=C5=D0=E0=B4=D7=CD=B9 = =E1=BC=B9=C3=D2=C2=E4=B4=E9=CD=C2=E8=D2=A7=A8=C3=D4=A7=A8=D1=A7=E1=BA=BA=B7= =D3=A7=D2=B9 Part-time 15,000 =B6=D6=A7 60,000 =BA=D2=B7/=E0=B4=D7=CD=B9 =E0=C7=C5=D2=B7=D5=E8=B5=E9=CD=A7=E3=AA=E9 : 7- 14 =AA=C1. = /=CA=D1=BB=B4=D2=CB=EC=20 = =E1=BC=B9=C3=D2=C2=E4=B4=E9=CD=C2=E8=D2=A7=A8=C3=D4=A7=A8=D1=A7=E1=BA=BA=B7= =D3=A7=D2=B9 full-time 30,000 =B6=D6=A7 170,000 =BA=D2=B7/=E0=B4=D7=CD=B9 =E0=C7=C5=D2=B7=D5=E8=B5=E9=CD=A7=E3=AA=E9 : 20- 40 =AA=C1. = /=CA=D1=BB=B4=D2=CB=EC=20 =A2=E8=D2=C7=B4=D5 ! =CA=D3=CB=C3=D1=BA = =BC=D9=E9=B7=D5=E8=CD=C2=D9=E8=E3=B9=E0=A2=B5 =A1=C3=D8=A7=E0=B7=BE=CF = =E1=C5=D0=BB=C3=D4=C1=C5=B1=C5 = =CA=D3=C3=CD=A7=B7=D5=E8=B9=D1=E8=A7=E0=BE=D7=E8=CD=BF=D1=A7=A1=D2=C3=BA=C3= =C3=C2=D2=C2 =BF=C3=D5 !!! = ************************************************************* = =A2=CD=CD=C0=D1=C2=CB=D2=A1=A2=E9=CD=A4=C7=D2=C1=B9=D5=E9=E4=BB=B6=D6=A7=A4= =D8=B3=E2=B4=C2=BA=D1=A7=E0=CD=D4=AD=CB=D2=A1=A4=D8=B3=E4=C1=E8=B5=E9=CD=A7= =A1=D2=C3=C3=D1=BA=A2=E9=CD=A4=C7=D2=C1=B9=D5=E9=CD=D5=A1 =A1=C3=D8=B3=D2 =E1=A8=E9=A7 Mail = =A2=CD=A7=A4=D8=B3=B7=D5=E8=B5=E9=CD=A7=A1=D2=C3=C5=BA=C1=D2=B7=D5=E8 = "Unsubscribe" =20 =20 ------=_NextPart_000_0205_01C21C67.C7D305E0 Content-Type: text/html; charset="windows-874" Content-Transfer-Encoding: quoted-printable

=C3=D0=BA=BA=A1=D2=C3=B7=D3=A7=D2=B9=A2=CD=A7=B8=D8=C3=A1=D4=A8= =E3=B9=CD=B9=D2=A4=B5
=B7=D3=E4=B4=E9=A7=E8=D2=C2=20 = =E1=C5=D0=CA=C3=E9=D2=A7=C3=D2=C2=E4=B4=E9=A7=D2=C1=A8=D2=A1=A1=D2=C3=B7=D3= =A7=D2=B9=BC=E8=D2=B9=C3=D0=BA=BA
=BC=C1=C1=D5=C3=D2=C2=E4=B4=E9=C1=D2=A1=A1=C7=E8=D2=20 30,000 / =E0=B4=D7=CD=B9 = =A8=D2=A1=A1=D2=C3=B7=D3=A7=D2=B9=E0=BE=D5=C2=A7=C7=D1=B9=C5=D0 2-3=20 = =AA=D1=E8=C7=E2=C1=A7=E0=B7=E8=D2=B9=D1=E9=B9
=E2=CD=A1=D2=CA=C1=D2=B6=D6=A7=A4=D8=B3=E1=C5=E9=C7=20 !
=E0=CB=C5=D7=CD=E1=B5=E8=E0=BE=D5=C2=A7=A4=D8=B3=A8=D0=A4=C7= =E9=D2=C1=D1=B9=CB=C3=D7=CD=E0=BB=C5=E8=D2

=A1=D2=C3=BA=C3=C3=C2=D2=C2=E1=B9=D0=B9=D3=B8=D8=C3=A1=D4= =A8 International=20 E-Business
=E0=C3=D5=C2=B9=C3=D9=E9=C7=D4=B8=D5=A1=D2=C3=B7=D3=A7=D2= =B9 =B8=D8=C3=A1=D4=A8=B9=D2=B9=D2=AA=D2=B5=D4 =BA=B9 Internet=20
=E0=C3=D5=C2=B9=C3=D9=E9=E1=BC=B9=A1=D2=C3=B7=D3=A7=D2=B9= =E0=BE=D4=E8=C1=C3=D2=C2=E4=B4=E9=BE=D4=E0=C8=C9=E3=B9=E1=B5=E8=C5=D0=E0=B4= =D7=CD=B9

=E1=BC=B9=C3=D2=C2=E4=B4=E9=CD=C2=E8=D2=A7=A8=C3=D4=A7=A8=D1=A7=E1=BA= =BA=B7=D3=A7=D2=B9 Part-time
15,000 =B6=D6=A7 = 60,000=20 = =BA=D2=B7/=E0=B4=D7=CD=B9
=E0=C7=C5=D2=B7=D5=E8=B5=E9=CD=A7=E3=AA=E9 = : 7- 14 =AA=C1. /=CA=D1=BB=B4=D2=CB=EC=20 =
=E1=BC=B9=C3=D2=C2=E4=B4=E9=CD=C2=E8=D2=A7=A8=C3=D4=A7=A8=D1=A7=E1=BA= =BA=B7=D3=A7=D2=B9 full-time
30,000 =B6=D6=A7 170,000=20 = =BA=D2=B7/=E0=B4=D7=CD=B9
=E0=C7=C5=D2=B7=D5=E8=B5=E9=CD=A7=E3=AA=E9 = : 20- 40 =AA=C1. /=CA=D1=BB=B4=D2=CB=EC

=A2=E8=D2=C7=B4=D5=20 !     = =CA=D3=CB=C3=D1=BA = =BC=D9=E9=B7=D5=E8=CD=C2=D9=E8=E3=B9=E0=A2=B5=20 =A1=C3=D8=A7=E0=B7=BE=CF  = =E1=C5=D0=BB=C3=D4=C1=C5=B1=C5
=CA=D3=C3=CD=A7=B7=D5=E8=B9=D1=E8=A7=E0=BE=D7=E8=CD=BF=D1=A7=A1=D2= =C3=BA=C3=C3=C2=D2=C2   = =BF=C3=D5 !!!
*************************************************************
          &nbs= p; =20 =A2=CD=CD=C0=D1=C2=CB=D2=A1=A2=E9=CD=A4=C7=D2=C1=B9=D5=E9=E4=BB= =B6=D6=A7=A4=D8=B3=E2=B4=C2=BA=D1=A7=E0=CD=D4=AD=CB=D2=A1=A4=D8=B3=E4=C1=E8= =B5=E9=CD=A7=A1=D2=C3=C3=D1=BA=A2=E9=CD=A4=C7=D2=C1=B9=D5=E9=CD=D5=A1
=   =20 =            =        =20 =A1=C3=D8=B3=D2 =E1=A8=E9=A7 Mail=20 = =A2=CD=A7=A4=D8=B3=B7=D5=E8=B5=E9=CD=A7=A1=D2=C3=C5=BA=C1=D2=B7=D5=E8 = "Unsubscribe"

------=_NextPart_000_0205_01C21C67.C7D305E0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 25 5: 9:54 2002 Delivered-To: freebsd-net@freebsd.org Received: from vinyl2.sentex.ca (vinyl2.sentex.ca [199.212.134.13]) by hub.freebsd.org (Postfix) with ESMTP id E4DC237B401 for ; Tue, 25 Jun 2002 05:09:46 -0700 (PDT) Received: from house.sentex.net (cage.simianscience.com [64.7.134.1]) (authenticated bits=0) by vinyl2.sentex.ca (8.12.4/8.12.2) with ESMTP id g5PC9ha2009457; Tue, 25 Jun 2002 08:09:45 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <5.1.0.14.0.20020625080603.07897008@192.168.0.12> X-Sender: mdtancsa@192.168.0.12 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 25 Jun 2002 08:08:07 -0400 To: Udo Erdelhoff From: Mike Tancsa Subject: Re: tracking down strange MTU issues with PPPoE) Cc: "Julian H. Stacey" , freebsd-net@FreeBSD.ORG In-Reply-To: <20020625055632.GI67408@nathan.ruhr.de> References: <5.1.0.14.0.20020624155731.0205c700@marble.sentex.ca> <5.1.0.14.0.20020618163928.05018cf0@marble.sentex.ca> <5.1.0.14.0.20020624155731.0205c700@marble.sentex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org At 07:56 AM 6/25/2002 +0200, Udo Erdelhoff wrote: >Yes, but the solution in PPP only allows you to lower the MSS to >1452 so that the return packet is never bigger than 1492 bytes. >However, if you need an even lower MSS, you are still stuck with >tcpmssd. I need to lower my MSS to about 1410 to get cvsup to work >correctly. Interesting, I didnt realize that. In your case, is it consistent with all sites ? i.e. does it work with some, but not all ? Which cvsup server do you see this problem with or is it all of them ? I run a local mirror so I am able to cvsup to it no problem. ---Mike -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 25 6:48:44 2002 Delivered-To: freebsd-net@freebsd.org Received: from obsidian.sentex.ca (obsidian.sentex.ca [64.7.128.101]) by hub.freebsd.org (Postfix) with ESMTP id EB8D237B401 for ; Tue, 25 Jun 2002 06:48:15 -0700 (PDT) Received: from simian.sentex.net (pyroxene.sentex.ca [199.212.134.18]) by obsidian.sentex.ca (8.12.4/8.12.4) with ESMTP id g5PDmAe0004475; Tue, 25 Jun 2002 09:48:10 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <5.1.0.14.0.20020625092221.050b1008@marble.sentex.ca> X-Sender: mdtpop@marble.sentex.ca X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 25 Jun 2002 09:51:01 -0400 To: Julian Elischer From: Mike Tancsa Subject: Re: Native PPPoE broken (4.6-STABLE), RP-PPPoE working?! Cc: freebsd-net@freebsd.org In-Reply-To: References: <2trfhu0tbekq67seicn4amdovp7564ji62@4ax.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_1109705762==_" X-Virus-Scanned: By Sentex Communications (obsidian/20020220) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --=====================_1109705762==_ Content-Type: text/plain; charset="us-ascii"; format=flowed At 11:37 PM 24/06/2002 -0700, Julian Elischer wrote: >On Tue, 25 Jun 2002, Mike Tancsa wrote: > > > > > > >It seems hard to understand how the pppoe node in the kernel can slow > > >things down. > > > > Here is an example > > > >I wasn;t saying there was a problem, just that my imagination is having a >hard time coming up with an explanation.. Sorry, the example was just to quantify with a little more accuracy my use of the word "slow" :-) >I know that the answer has to be in tcpdump traces.. > >you can tcpdump on both the tun interface or the ethernet interface.. > >it may be worth doing both to see if there is any delay between the two.. Hmmm... Some more strangeness. fxp1 is the interface physically connected to the modem. iscar# tcpdump -i tun0 -lenpvv > /tmp/tun0.out & tcpdump -i fxp1 -lenpvv > /tmp/fxp1.out & [1] 480 [2] 481 iscar# tcpdump: listening on fxp1 tcpdump: listening on tun0 Then on another console, I start up the ftp session to the problem site iscar% fetch ftp://ftp.isc.org/isc/bind9/9.2.1/bind-9.2.1.tar.gz Receiving bind-9.2.1.tar.gz (5021044 bytes): 0%^C 7260 bytes transferred in 11.1 seconds (653.23 Bps) fetch: transfer interrupted switch back iscar# fg tcpdump -i tun0 -lenpvv > /tmp/tun0.out ^C 90 packets received by filter 0 packets dropped by kernel iscar# fg tcpdump -i fxp1 -lenpvv > /tmp/fxp1.out ^C 133 packets received by filter 0 packets dropped by kernel iscar# Why the disparity in packets ? Attached are the results of the dump. If you need me to re-run them with different tcpdump options let me know. ---Mike --=====================_1109705762==_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="fxp1.txt" 09:35:51.033644 0:d0:b7:92:c8:b5 0:90:1a:40:2b:21 8864 138: PPPoE [ses 0xc28] VJNC 118: 09:35:51.034405 0:d0:b7:92:c8:b5 0:90:1a:40:2b:21 8864 154: PPPoE [ses 0xc28] VJNC 134: 09:35:51.043726 0:d0:b7:92:c8:b5 0:90:1a:40:2b:21 8864 90: PPPoE [ses 0xc28] VJC 70: 09:35:51.056881 0:90:1a:40:2b:21 0:d0:b7:92:c8:b5 8864 74: PPPoE [ses 0xc28] IP 54: 199.212.134.18.2411 > 64.7.134.131.22: . [tcp sum ok] 2630293162:2630293162(0) ack 4206889626 win 33088 (DF) [tos 0x10] (ttl 61, id 1498, len 52) 09:35:51.075596 0:90:1a:40:2b:21 0:d0:b7:92:c8:b5 8864 74: PPPoE [ses 0xc28] IP 54: 199.212.134.18.2411 > 64.7.134.131.22: . [tcp sum ok] 0:0(0) ack 145 win 33088 (DF) [tos 0x10] (ttl 61, id 14778, len 52) 09:35:54.035231 0:90:1a:40:2b:21 0:d0:b7:92:c8:b5 8864 122: PPPoE [ses 0xc28] IP 102: 199.212.134.18.2408 > 64.7.134.131.22: P 3655225707:3655225755(48) ack 343315932 win 33120 (DF) [tos 0x10] (ttl 61, id 40418, len 100) 09:35:54.036346 0:d0:b7:92:c8:b5 0:90:1a:40:2b:21 8864 170: PPPoE [ses 0xc28] VJNC 150: 09:35:54.150493 0:90:1a:40:2b:21 0:d0:b7:92:c8:b5 8864 74: PPPoE [ses 0xc28] IP 54: 199.212.134.18.2408 > 64.7.134.131.22: . [tcp sum ok] 48:48(0) ack 97 win 33120 (DF) [tos 0x10] (ttl 61, id 31105, len 52) 09:35:54.466126 0:90:1a:40:2b:21 0:d0:b7:92:c8:b5 8864 122: PPPoE [ses 0xc28] IP 102: 199.212.134.18.2408 > 64.7.134.131.22: P 48:96(48) ack 97 win 33120 (DF) [tos 0x10] (ttl 61, id 27799, len 100) 09:35:54.467913 0:d0:b7:92:c8:b5 0:90:1a:40:2b:21 8864 122: PPPoE [ses 0xc28] VJNC 102: 09:35:54.473629 0:d0:b7:92:c8:b5 0:90:1a:40:2b:21 8864 79: PPPoE [ses 0xc28] IP 59: 64.7.134.131.1080 > 199.212.134.11.53: [udp sum ok] 18299+ AAAA? ftp.isc.org. [|domain] (ttl 64, id 1840, len 57) 09:35:54.497693 0:90:1a:40:2b:21 0:d0:b7:92:c8:b5 8864 160: PPPoE [ses 0xc28] IP 140: 199.212.134.11.53 > 64.7.134.131.1080: 18299 q: AAAA? ftp.isc.org. 1/1/0 ftp.isc.org. CNAME[|domain] (ttl 62, id 44706, len 138) 09:35:54.498404 0:d0:b7:92:c8:b5 0:90:1a:40:2b:21 8864 79: PPPoE [ses 0xc28] IP 59: 64.7.134.131.1081 > 199.212.134.11.53: [udp sum ok] 18300+ A? ftp.isc.org. [|domain] (ttl 64, id 1841, len 57) 09:35:54.521960 0:90:1a:40:2b:21 0:d0:b7:92:c8:b5 8864 313: PPPoE [ses 0xc28] IP 293: 199.212.134.11.53 > 64.7.134.131.1081: 18300 q: A? ftp.isc.org. 2/5/5 ftp.isc.org. CNAME[|domain] (ttl 62, id 44708, len 291) 09:35:54.522734 0:d0:b7:92:c8:b5 0:90:1a:40:2b:21 8864 82: PPPoE [ses 0xc28] IP 62: 64.7.134.131.1034 > 204.152.184.27.21: S [tcp sum ok] 3360925822:3360925822(0) win 57344 (DF) (ttl 64, id 1842, len 60) 09:35:54.581138 0:90:1a:40:2b:21 0:d0:b7:92:c8:b5 8864 74: PPPoE [ses 0xc28] IP 54: 199.212.134.18.2408 > 64.7.134.131.22: . [tcp sum ok] 96:96(0) ack 145 win 33120 (DF) [tos 0x10] (ttl 61, id 474, len 52) 09:35:54.621045 0:90:1a:40:2b:21 0:d0:b7:92:c8:b5 8864 70: PPPoE [ses 0xc28] IP 50: 204.152.184.27.21 > 64.7.134.131.1034: S [tcp sum ok] 396459901:396459901(0) ack 3360925823 win 61440 (ttl 46, id 32254, len 48) 09:35:54.621514 0:d0:b7:92:c8:b5 0:90:1a:40:2b:21 8864 62: PPPoE [ses 0xc28] VJNC 42: 09:35:54.743069 0:90:1a:40:2b:21 0:d0:b7:92:c8:b5 8864 150: PPPoE [ses 0xc28] IP 130: 204.152.184.27.21 > 64.7.134.131.1034: P 1:89(88) ack 1 win 61440 (DF) [tos 0x10] (ttl 46, id 32282, len 128) 09:35:54.744448 0:d0:b7:92:c8:b5 0:90:1a:40:2b:21 8864 43: PPPoE [ses 0xc28] VJC 23: 09:35:55.744233 0:d0:b7:92:c8:b5 0:90:1a:40:2b:21 8864 78: PPPoE [ses 0xc28] VJNC 58: 09:35:55.843802 0:90:1a:40:2b:21 0:d0:b7:92:c8:b5 8864 130: PPPoE [ses 0xc28] IP 110: 204.152.184.27.21 > 64.7.134.131.1034: P 89:157(68) ack 17 win 61440 (DF) [tos 0x10] (ttl 46, id 32453, len 108) 09:35:55.845082 0:d0:b7:92:c8:b5 0:90:1a:40:2b:21 8864 57: PPPoE [ses 0xc28] VJC 37: 09:35:57.844260 0:d0:b7:92:c8:b5 0:90:1a:40:2b:21 8864 91: PPPoE [ses 0xc28] VJNC 71: 09:35:57.972395 0:90:1a:40:2b:21 0:d0:b7:92:c8:b5 8864 110: PPPoE [ses 0xc28] IP 90: 204.152.184.27.21 > 64.7.134.131.1034: P 157:205(48) ack 46 win 61440 (DF) [tos 0x10] (ttl 46, id 32665, len 88) 09:35:57.973357 0:d0:b7:92:c8:b5 0:90:1a:40:2b:21 8864 36: PPPoE [ses 0xc28] VJC 16: 09:36:01.964321 0:d0:b7:92:c8:b5 0:90:1a:40:2b:21 8864 70: PPPoE [ses 0xc28] VJNC 50: 09:36:02.060311 0:90:1a:40:2b:21 0:d0:b7:92:c8:b5 8864 82: PPPoE [ses 0xc28] IP 62: 204.152.184.27.21 > 64.7.134.131.1034: P [tcp sum ok] 205:225(20) ack 54 win 61440 [tos 0x10] (ttl 46, id 33043, len 60) 09:36:02.061134 0:d0:b7:92:c8:b5 0:90:1a:40:2b:21 8864 50: PPPoE [ses 0xc28] VJC 30: 09:36:10.054412 0:d0:b7:92:c8:b5 0:90:1a:40:2b:21 8864 84: PPPoE [ses 0xc28] VJNC 64: 09:36:10.160825 0:90:1a:40:2b:21 0:d0:b7:92:c8:b5 8864 91: PPPoE [ses 0xc28] IP 71: 204.152.184.27.21 > 64.7.134.131.1034: P [tcp sum ok] 225:254(29) ack 76 win 61440 (DF) [tos 0x10] (ttl 46, id 34610, len 69) 09:36:10.161570 0:d0:b7:92:c8:b5 0:90:1a:40:2b:21 8864 52: PPPoE [ses 0xc28] VJC 32: 09:36:23.014692 0:90:1a:40:2b:21 0:d0:b7:92:c8:b5 8864 60: PPPoE [ses 0xc28] LCP 14: Echo-Req(121), Magic-Num=13065102 09:36:23.015525 0:d0:b7:92:c8:b5 0:90:1a:40:2b:21 8864 34: PPPoE [ses 0xc28] LCP 14: Echo-Rep(121), Magic-Num=d2e7883b 09:36:26.154528 0:d0:b7:92:c8:b5 0:90:1a:40:2b:21 8864 86: PPPoE [ses 0xc28] VJNC 66: 09:36:26.251199 0:90:1a:40:2b:21 0:d0:b7:92:c8:b5 8864 75: PPPoE [ses 0xc28] IP 55: 204.152.184.27.21 > 64.7.134.131.1034: P [tcp sum ok] 254:267(13) ack 100 win 61440 [tos 0x10] (ttl 46, id 38967, len 53) 09:36:26.251832 0:d0:b7:92:c8:b5 0:90:1a:40:2b:21 8864 52: PPPoE [ses 0xc28] VJC 32: 09:36:43.013422 0:90:1a:40:2b:21 0:d0:b7:92:c8:b5 8864 60: PPPoE [ses 0xc28] LCP 14: Echo-Req(122), Magic-Num=13065102 09:36:43.014281 0:d0:b7:92:c8:b5 0:90:1a:40:2b:21 8864 34: PPPoE [ses 0xc28] LCP 14: Echo-Rep(122), Magic-Num=d2e7883b 09:36:53.013395 0:90:1a:40:2b:21 0:d0:b7:92:c8:b5 8864 60: PPPoE [ses 0xc28] LCP 14: Echo-Req(123), Magic-Num=13065102 09:36:53.014203 0:d0:b7:92:c8:b5 0:90:1a:40:2b:21 8864 34: PPPoE [ses 0xc28] LCP 14: Echo-Rep(123), Magic-Num=d2e7883b 09:36:58.244834 0:d0:b7:92:c8:b5 0:90:1a:40:2b:21 8864 86: PPPoE [ses 0xc28] VJNC 66: 09:36:58.345257 0:90:1a:40:2b:21 0:d0:b7:92:c8:b5 8864 82: PPPoE [ses 0xc28] IP 62: 204.152.184.27.21 > 64.7.134.131.1034: P [tcp sum ok] 267:287(20) ack 124 win 61440 [tos 0x10] (ttl 46, id 48964, len 60) 09:36:58.346389 0:d0:b7:92:c8:b5 0:90:1a:40:2b:21 8864 34: PPPoE [ses 0xc28] VJC 14: 09:37:13.013364 0:90:1a:40:2b:21 0:d0:b7:92:c8:b5 8864 60: PPPoE [ses 0xc28] LCP 14: Echo-Req(124), Magic-Num=13065102 09:37:13.014196 0:d0:b7:92:c8:b5 0:90:1a:40:2b:21 8864 34: PPPoE [ses 0xc28] LCP 14: Echo-Rep(124), Magic-Num=d2e7883b 09:37:23.012364 0:90:1a:40:2b:21 0:d0:b7:92:c8:b5 8864 60: PPPoE [ses 0xc28] LCP 14: Echo-Req(125), Magic-Num=13065102 09:37:23.013261 0:d0:b7:92:c8:b5 0:90:1a:40:2b:21 8864 34: PPPoE [ses 0xc28] LCP 14: Echo-Rep(125), Magic-Num=d2e7883b 09:37:33.012590 0:90:1a:40:2b:21 0:d0:b7:92:c8:b5 8864 60: PPPoE [ses 0xc28] LCP 14: Echo-Req(126), Magic-Num=13065102 09:37:33.013421 0:d0:b7:92:c8:b5 0:90:1a:40:2b:21 8864 34: PPPoE [ses 0xc28] LCP 14: Echo-Rep(126), Magic-Num=d2e7883b 09:37:43.012568 0:90:1a:40:2b:21 0:d0:b7:92:c8:b5 8864 60: PPPoE [ses 0xc28] LCP 14: Echo-Req(127), Magic-Num=13065102 09:37:43.013375 0:d0:b7:92:c8:b5 0:90:1a:40:2b:21 8864 34: PPPoE [ses 0xc28] LCP 14: Echo-Rep(127), Magic-Num=d2e7883b 09:37:53.012305 0:90:1a:40:2b:21 0:d0:b7:92:c8:b5 8864 60: PPPoE [ses 0xc28] LCP 14: Echo-Req(128), Magic-Num=13065102 09:37:53.013142 0:d0:b7:92:c8:b5 0:90:1a:40:2b:21 8864 34: PPPoE [ses 0xc28] LCP 14: Echo-Rep(128), Magic-Num=d2e7883b 09:38:02.345354 0:d0:b7:92:c8:b5 0:90:1a:40:2b:21 8864 68: PPPoE [ses 0xc28] VJNC 48: 09:38:02.451844 0:90:1a:40:2b:21 0:d0:b7:92:c8:b5 8864 112: PPPoE [ses 0xc28] IP 92: 204.152.184.27.21 > 64.7.134.131.1034: P 287:337(50) ack 130 win 61440 (DF) [tos 0x10] (ttl 46, id 52676, len 90) 09:38:02.452855 0:d0:b7:92:c8:b5 0:90:1a:40:2b:21 8864 82: PPPoE [ses 0xc28] IP 62: 64.7.134.131.1035 > 204.152.184.27.23368: S [tcp sum ok] 2641833555:2641833555(0) win 57344 (DF) (ttl 64, id 1858, len 60) 09:38:02.545238 0:d0:b7:92:c8:b5 0:90:1a:40:2b:21 8864 29: PPPoE [ses 0xc28] VJC 9: 09:38:02.557007 0:90:1a:40:2b:21 0:d0:b7:92:c8:b5 8864 70: PPPoE [ses 0xc28] IP 50: 204.152.184.27.23368 > 64.7.134.131.1035: S [tcp sum ok] 424791459:424791459(0) ack 2641833556 win 61440 (ttl 46, id 52679, len 48) 09:38:02.557523 0:d0:b7:92:c8:b5 0:90:1a:40:2b:21 8864 62: PPPoE [ses 0xc28] VJNC 42: 09:38:02.557613 0:d0:b7:92:c8:b5 0:90:1a:40:2b:21 8864 51: PPPoE [ses 0xc28] VJC 31: 09:38:13.012033 0:90:1a:40:2b:21 0:d0:b7:92:c8:b5 8864 60: PPPoE [ses 0xc28] LCP 14: Echo-Req(129), Magic-Num=13065102 09:38:13.012886 0:d0:b7:92:c8:b5 0:90:1a:40:2b:21 8864 34: PPPoE [ses 0xc28] LCP 14: Echo-Rep(129), Magic-Num=d2e7883b 09:38:23.011511 0:90:1a:40:2b:21 0:d0:b7:92:c8:b5 8864 60: PPPoE [ses 0xc28] LCP 14: Echo-Req(130), Magic-Num=13065102 09:38:23.012353 0:d0:b7:92:c8:b5 0:90:1a:40:2b:21 8864 34: PPPoE [ses 0xc28] LCP 14: Echo-Rep(130), Magic-Num=d2e7883b 09:38:33.011496 0:90:1a:40:2b:21 0:d0:b7:92:c8:b5 8864 60: PPPoE [ses 0xc28] LCP 14: Echo-Req(131), Magic-Num=13065102 09:38:33.012351 0:d0:b7:92:c8:b5 0:90:1a:40:2b:21 8864 34: PPPoE [ses 0xc28] LCP 14: Echo-Rep(131), Magic-Num=d2e7883b 09:38:43.010745 0:90:1a:40:2b:21 0:d0:b7:92:c8:b5 8864 60: PPPoE [ses 0xc28] LCP 14: Echo-Req(132), Magic-Num=13065102 09:38:43.011566 0:d0:b7:92:c8:b5 0:90:1a:40:2b:21 8864 34: PPPoE [ses 0xc28] LCP 14: Echo-Rep(132), Magic-Num=d2e7883b 09:38:53.011224 0:90:1a:40:2b:21 0:d0:b7:92:c8:b5 8864 60: PPPoE [ses 0xc28] LCP 14: Echo-Req(133), Magic-Num=13065102 09:38:53.012056 0:d0:b7:92:c8:b5 0:90:1a:40:2b:21 8864 34: PPPoE [ses 0xc28] LCP 14: Echo-Rep(133), Magic-Num=d2e7883b 09:39:03.010955 0:90:1a:40:2b:21 0:d0:b7:92:c8:b5 8864 60: PPPoE [ses 0xc28] LCP 14: Echo-Req(134), Magic-Num=13065102 09:39:03.011775 0:d0:b7:92:c8:b5 0:90:1a:40:2b:21 8864 34: PPPoE [ses 0xc28] LCP 14: Echo-Rep(134), Magic-Num=d2e7883b 09:39:06.555878 0:d0:b7:92:c8:b5 0:90:1a:40:2b:21 8864 86: PPPoE [ses 0xc28] VJNC 66: 09:39:06.658709 0:90:1a:40:2b:21 0:d0:b7:92:c8:b5 8864 142: PPPoE [ses 0xc28] IP 122: 204.152.184.27.21 > 64.7.134.131.1034: P 337:417(80) ack 154 win 61440 (DF) [tos 0x10] (ttl 46, id 58021, len 120) 09:39:06.660516 0:d0:b7:92:c8:b5 0:90:1a:40:2b:21 8864 138: PPPoE [ses 0xc28] VJNC 118: 09:39:06.660971 0:d0:b7:92:c8:b5 0:90:1a:40:2b:21 8864 90: PPPoE [ses 0xc28] VJC 70: 09:39:06.676799 0:90:1a:40:2b:21 0:d0:b7:92:c8:b5 8864 1514: PPPoE [ses 0xc28] IP 1494: 204.152.184.27.23368 > 64.7.134.131.1035: . 1:1453(1452) ack 1 win 61440 (DF) [tos 0x10] (ttl 46, id 58022, len 1492) 09:39:06.688136 0:90:1a:40:2b:21 0:d0:b7:92:c8:b5 8864 1514: PPPoE [ses 0xc28] IP 1494: 204.152.184.27.23368 > 64.7.134.131.1035: . 1453:2905(1452) ack 1 win 61440 (DF) [tos 0x10] (ttl 46, id 58023, len 1492) 09:39:06.688616 0:d0:b7:92:c8:b5 0:90:1a:40:2b:21 8864 33: PPPoE [ses 0xc28] VJC 13: 09:39:06.692153 0:90:1a:40:2b:21 0:d0:b7:92:c8:b5 8864 74: PPPoE [ses 0xc28] IP 54: 199.212.134.18.2408 > 64.7.134.131.22: . [tcp sum ok] 96:96(0) ack 273 win 33088 (DF) [tos 0x10] (ttl 61, id 12670, len 52) 09:39:06.755770 0:d0:b7:92:c8:b5 0:90:1a:40:2b:21 8864 29: PPPoE [ses 0xc28] VJC 9: 09:39:15.733210 0:90:1a:40:2b:21 0:d0:b7:92:c8:b5 8864 1514: PPPoE [ses 0xc28] IP 1494: 204.152.184.27.23368 > 64.7.134.131.1035: . 1:1453(1452) ack 1 win 61440 (DF) [tos 0x10] (ttl 46, id 58608, len 1492) 09:39:15.733732 0:d0:b7:92:c8:b5 0:90:1a:40:2b:21 8864 30: PPPoE [ses 0xc28] VJC 10: 09:39:15.744778 0:90:1a:40:2b:21 0:d0:b7:92:c8:b5 8864 1514: PPPoE [ses 0xc28] IP 1494: 204.152.184.27.23368 > 64.7.134.131.1035: . 1453:2905(1452) ack 1 win 61440 (DF) [tos 0x10] (ttl 46, id 58609, len 1492) 09:39:15.745152 0:d0:b7:92:c8:b5 0:90:1a:40:2b:21 8864 62: PPPoE [ses 0xc28] VJNC 42: 09:39:15.856632 0:90:1a:40:2b:21 0:d0:b7:92:c8:b5 8864 1514: PPPoE [ses 0xc28] IP 1494: 204.152.184.27.23368 > 64.7.134.131.1035: . 2905:4357(1452) ack 1 win 61440 (DF) [tos 0x10] (ttl 46, id 58632, len 1492) 09:39:15.857456 0:d0:b7:92:c8:b5 0:90:1a:40:2b:21 8864 138: PPPoE [ses 0xc28] VJNC 118: 09:39:15.857909 0:d0:b7:92:c8:b5 0:90:1a:40:2b:21 8864 90: PPPoE [ses 0xc28] VJC 70: 09:39:15.868213 0:90:1a:40:2b:21 0:d0:b7:92:c8:b5 8864 1514: PPPoE [ses 0xc28] IP 1494: 204.152.184.27.23368 > 64.7.134.131.1035: . 4357:5809(1452) ack 1 win 61440 (DF) [tos 0x10] (ttl 46, id 58633, len 1492) 09:39:15.868705 0:d0:b7:92:c8:b5 0:90:1a:40:2b:21 8864 33: PPPoE [ses 0xc28] VJC 13: 09:39:15.879787 0:90:1a:40:2b:21 0:d0:b7:92:c8:b5 8864 1514: PPPoE [ses 0xc28] IP 1494: 204.152.184.27.23368 > 64.7.134.131.1035: . 5809:7261(1452) ack 1 win 61440 (DF) [tos 0x10] (ttl 46, id 58634, len 1492) 09:39:15.880247 0:d0:b7:92:c8:b5 0:90:1a:40:2b:21 8864 32: PPPoE [ses 0xc28] VJC 12: 09:39:15.888984 0:90:1a:40:2b:21 0:d0:b7:92:c8:b5 8864 74: PPPoE [ses 0xc28] IP 54: 199.212.134.18.2408 > 64.7.134.131.22: . [tcp sum ok] 96:96(0) ack 401 win 33088 (DF) [tos 0x10] (ttl 61, id 24424, len 52) 09:39:17.773236 0:90:1a:40:2b:21 0:d0:b7:92:c8:b5 8864 122: PPPoE [ses 0xc28] IP 102: 199.212.134.18.2408 > 64.7.134.131.22: P 96:144(48) ack 401 win 33120 (DF) [tos 0x10] (ttl 61, id 3434, len 100) 09:39:17.775152 0:d0:b7:92:c8:b5 0:90:1a:40:2b:21 8864 62: PPPoE [ses 0xc28] IP 42: 64.7.134.131.1035 > 204.152.184.27.23368: F [tcp sum ok] 1:1(0) ack 7261 win 58080 (DF) (ttl 64, id 1873, len 40) 09:39:17.775662 0:d0:b7:92:c8:b5 0:90:1a:40:2b:21 8864 298: PPPoE [ses 0xc28] VJNC 278: 09:39:17.886930 0:90:1a:40:2b:21 0:d0:b7:92:c8:b5 8864 1514: PPPoE [ses 0xc28] IP 1494: 204.152.184.27.23368 > 64.7.134.131.1035: . 7261:8713(1452) ack 2 win 61440 (DF) [tos 0x10] (ttl 46, id 58732, len 1492) 09:39:17.887399 0:d0:b7:92:c8:b5 0:90:1a:40:2b:21 8864 62: PPPoE [ses 0xc28] IP 42: 64.7.134.131.1035 > 204.152.184.27.23368: R [tcp sum ok] 2641833557:2641833557(0) win 0 (ttl 64, id 1875, len 40) 09:39:17.898508 0:90:1a:40:2b:21 0:d0:b7:92:c8:b5 8864 1514: PPPoE [ses 0xc28] IP 1494: 204.152.184.27.23368 > 64.7.134.131.1035: . 8713:10165(1452) ack 2 win 61440 (DF) [tos 0x10] (ttl 46, id 58733, len 1492) 09:39:17.898853 0:d0:b7:92:c8:b5 0:90:1a:40:2b:21 8864 62: PPPoE [ses 0xc28] IP 42: 64.7.134.131.1035 > 204.152.184.27.23368: R [tcp sum ok] 2641833557:2641833557(0) win 0 (ttl 64, id 1876, len 40) 09:39:17.909838 0:90:1a:40:2b:21 0:d0:b7:92:c8:b5 8864 1514: PPPoE [ses 0xc28] IP 1494: 204.152.184.27.23368 > 64.7.134.131.1035: . 10165:11617(1452) ack 2 win 61440 (DF) [tos 0x10] (ttl 46, id 58734, len 1492) 09:39:17.909922 0:90:1a:40:2b:21 0:d0:b7:92:c8:b5 8864 74: PPPoE [ses 0xc28] IP 54: 199.212.134.18.2408 > 64.7.134.131.22: . [tcp sum ok] 144:144(0) ack 625 win 33120 (DF) [tos 0x10] (ttl 61, id 21269, len 52) 09:39:17.910337 0:d0:b7:92:c8:b5 0:90:1a:40:2b:21 8864 62: PPPoE [ses 0xc28] IP 42: 64.7.134.131.1035 > 204.152.184.27.23368: R [tcp sum ok] 2641833557:2641833557(0) win 0 (ttl 64, id 1877, len 40) 09:39:31.974210 0:90:1a:40:2b:21 0:d0:b7:92:c8:b5 8864 82: PPPoE [ses 0xc28] IP 62: 202.41.239.22.45927 > 64.7.134.131.21: S [tcp sum ok] 1016522058:1016522058(0) win 5840 (DF) (ttl 48, id 61072, len 60) 09:39:31.974672 0:d0:b7:92:c8:b5 0:90:1a:40:2b:21 8864 62: PPPoE [ses 0xc28] IP 42: 64.7.134.131.21 > 202.41.239.22.45927: R [tcp sum ok] 0:0(0) ack 1016522059 win 0 (ttl 64, id 1878, len 40) 09:39:40.783294 0:90:1a:40:2b:21 0:d0:b7:92:c8:b5 8864 122: PPPoE [ses 0xc28] IP 102: 199.212.134.18.2411 > 64.7.134.131.22: P 0:48(48) ack 145 win 33120 (DF) [tos 0x10] (ttl 61, id 24638, len 100) 09:39:40.785739 0:d0:b7:92:c8:b5 0:90:1a:40:2b:21 8864 122: PPPoE [ses 0xc28] VJNC 102: 09:39:40.786123 0:d0:b7:92:c8:b5 0:90:1a:40:2b:21 8864 122: PPPoE [ses 0xc28] VJNC 102: 09:39:40.826119 0:90:1a:40:2b:21 0:d0:b7:92:c8:b5 8864 74: PPPoE [ses 0xc28] IP 54: 199.212.134.18.2411 > 64.7.134.131.22: . [tcp sum ok] 48:48(0) ack 241 win 33096 (DF) [tos 0x10] (ttl 61, id 16243, len 52) 09:39:41.124513 0:90:1a:40:2b:21 0:d0:b7:92:c8:b5 8864 122: PPPoE [ses 0xc28] IP 102: 199.212.134.18.2411 > 64.7.134.131.22: P 48:96(48) ack 241 win 33120 (DF) [tos 0x10] (ttl 61, id 32847, len 100) 09:39:41.125549 0:d0:b7:92:c8:b5 0:90:1a:40:2b:21 8864 122: PPPoE [ses 0xc28] VJNC 102: 09:39:41.189307 0:90:1a:40:2b:21 0:d0:b7:92:c8:b5 8864 122: PPPoE [ses 0xc28] IP 102: 199.212.134.18.2411 > 64.7.134.131.22: P 96:144(48) ack 289 win 33120 (DF) [tos 0x10] (ttl 61, id 18047, len 100) 09:39:41.190231 0:d0:b7:92:c8:b5 0:90:1a:40:2b:21 8864 122: PPPoE [ses 0xc28] VJNC 102: 09:39:41.305790 0:90:1a:40:2b:21 0:d0:b7:92:c8:b5 8864 74: PPPoE [ses 0xc28] IP 54: 199.212.134.18.2411 > 64.7.134.131.22: . [tcp sum ok] 144:144(0) ack 337 win 33120 (DF) [tos 0x10] (ttl 61, id 38178, len 52) 09:39:41.377028 0:90:1a:40:2b:21 0:d0:b7:92:c8:b5 8864 122: PPPoE [ses 0xc28] IP 102: 199.212.134.18.2411 > 64.7.134.131.22: P 144:192(48) ack 337 win 33120 (DF) [tos 0x10] (ttl 61, id 8828, len 100) 09:39:41.378887 0:d0:b7:92:c8:b5 0:90:1a:40:2b:21 8864 122: PPPoE [ses 0xc28] VJNC 102: 09:39:41.379214 0:d0:b7:92:c8:b5 0:90:1a:40:2b:21 8864 106: PPPoE [ses 0xc28] VJC 86: 09:39:41.412468 0:90:1a:40:2b:21 0:d0:b7:92:c8:b5 8864 74: PPPoE [ses 0xc28] IP 54: 199.212.134.18.2411 > 64.7.134.131.22: . [tcp sum ok] 192:192(0) ack 465 win 33080 (DF) [tos 0x10] (ttl 61, id 58428, len 52) 09:39:41.696812 0:90:1a:40:2b:21 0:d0:b7:92:c8:b5 8864 122: PPPoE [ses 0xc28] IP 102: 199.212.134.18.2411 > 64.7.134.131.22: P 192:240(48) ack 465 win 33120 (DF) [tos 0x10] (ttl 61, id 3333, len 100) 09:39:41.699428 0:d0:b7:92:c8:b5 0:90:1a:40:2b:21 8864 186: PPPoE [ses 0xc28] VJNC 166: 09:39:41.699778 0:d0:b7:92:c8:b5 0:90:1a:40:2b:21 8864 74: PPPoE [ses 0xc28] VJC 54: 09:39:41.729051 0:90:1a:40:2b:21 0:d0:b7:92:c8:b5 8864 74: PPPoE [ses 0xc28] IP 54: 199.212.134.18.2411 > 64.7.134.131.22: . [tcp sum ok] 240:240(0) ack 625 win 33096 (DF) [tos 0x10] (ttl 61, id 58488, len 52) --=====================_1109705762==_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="tun0.txt" 09:35:51.043460 AF 2 116: 64.7.134.131.22 > 199.212.134.18.2411: P 4206889706:4206889770(64) ack 2630293162 win 57600 (DF) [tos 0x10] (ttl 64, id 1837, len 116) 09:35:51.057041 AF 2 52: 199.212.134.18.2411 > 64.7.134.131.22: . [tcp sum ok] 1:1(0) ack 4294967216 win 33088 (DF) [tos 0x10] (ttl 61, id 1498, len 52) 09:35:51.075710 AF 2 52: 199.212.134.18.2411 > 64.7.134.131.22: . [tcp sum ok] 1:1(0) ack 64 win 33088 (DF) [tos 0x10] (ttl 61, id 14778, len 52) 09:35:54.035436 AF 2 100: 199.212.134.18.2408 > 64.7.134.131.22: P 3655225707:3655225755(48) ack 343315932 win 33120 (DF) [tos 0x10] (ttl 61, id 40418, len 100) 09:35:54.036127 AF 2 148: 64.7.134.131.22 > 199.212.134.18.2408: P 1:97(96) ack 48 win 57600 (DF) [tos 0x10] (ttl 64, id 1838, len 148) 09:35:54.150648 AF 2 52: 199.212.134.18.2408 > 64.7.134.131.22: . [tcp sum ok] 48:48(0) ack 97 win 33120 (DF) [tos 0x10] (ttl 61, id 31105, len 52) 09:35:54.466247 AF 2 100: 199.212.134.18.2408 > 64.7.134.131.22: P 48:96(48) ack 97 win 33120 (DF) [tos 0x10] (ttl 61, id 27799, len 100) 09:35:54.467640 AF 2 100: 64.7.134.131.22 > 199.212.134.18.2408: P 97:145(48) ack 96 win 57600 (DF) [tos 0x10] (ttl 64, id 1839, len 100) 09:35:54.473339 AF 2 57: 64.7.134.131.1080 > 199.212.134.11.53: [udp sum ok] 18299+ AAAA? ftp.isc.org. [|domain] (ttl 64, id 1840, len 57) 09:35:54.497855 AF 2 138: 199.212.134.11.53 > 64.7.134.131.1080: 18299 q: AAAA? ftp.isc.org. 1/1/0 ftp.isc.org. CNAME isrv4.isc.org. ns: isc.org. SOA[|domain] (ttl 62, id 44706, len 138) 09:35:54.498155 AF 2 57: 64.7.134.131.1081 > 199.212.134.11.53: [udp sum ok] 18300+ A? ftp.isc.org. [|domain] (ttl 64, id 1841, len 57) 09:35:54.522090 AF 2 291: 199.212.134.11.53 > 64.7.134.131.1081: 18300 q: A? ftp.isc.org. 2/5/5 ftp.isc.org. CNAME isrv4.isc.org., isrv4.isc.org. A[|domain] (ttl 62, id 44708, len 291) 09:35:54.522471 AF 2 60: 64.7.134.131.1034 > 204.152.184.27.21: S [tcp sum ok] 3360925822:3360925822(0) win 57344 (DF) (ttl 64, id 1842, len 60) 09:35:54.581278 AF 2 52: 199.212.134.18.2408 > 64.7.134.131.22: . [tcp sum ok] 96:96(0) ack 145 win 33120 (DF) [tos 0x10] (ttl 61, id 474, len 52) 09:35:54.621156 AF 2 48: 204.152.184.27.21 > 64.7.134.131.1034: S [tcp sum ok] 396459901:396459901(0) ack 3360925823 win 61440 (ttl 46, id 32254, len 48) 09:35:54.621223 AF 2 40: 64.7.134.131.1034 > 204.152.184.27.21: . [tcp sum ok] 1:1(0) ack 1 win 58080 (DF) (ttl 64, id 1843, len 40) 09:35:54.743199 AF 2 128: 204.152.184.27.21 > 64.7.134.131.1034: P 1:89(88) ack 1 win 61440 (DF) [tos 0x10] (ttl 46, id 32282, len 128) 09:35:54.744194 AF 2 56: 64.7.134.131.1034 > 204.152.184.27.21: P [tcp sum ok] 1:17(16) ack 89 win 58080 (DF) (ttl 64, id 1844, len 56) 09:35:55.744022 AF 2 56: 64.7.134.131.1034 > 204.152.184.27.21: P [tcp sum ok] 1:17(16) ack 89 win 58080 (DF) (ttl 64, id 1845, len 56) 09:35:55.843951 AF 2 108: 204.152.184.27.21 > 64.7.134.131.1034: P 89:157(68) ack 17 win 61440 (DF) [tos 0x10] (ttl 46, id 32453, len 108) 09:35:55.844850 AF 2 69: 64.7.134.131.1034 > 204.152.184.27.21: P [tcp sum ok] 17:46(29) ack 157 win 58080 (DF) (ttl 64, id 1846, len 69) 09:35:57.844038 AF 2 69: 64.7.134.131.1034 > 204.152.184.27.21: P [tcp sum ok] 17:46(29) ack 157 win 58080 (DF) (ttl 64, id 1847, len 69) 09:35:57.972569 AF 2 88: 204.152.184.27.21 > 64.7.134.131.1034: P [tcp sum ok] 157:205(48) ack 46 win 61440 (DF) [tos 0x10] (ttl 46, id 32665, len 88) 09:35:57.973136 AF 2 48: 64.7.134.131.1034 > 204.152.184.27.21: P [tcp sum ok] 46:54(8) ack 205 win 58080 (DF) (ttl 64, id 1848, len 48) 09:36:01.964076 AF 2 48: 64.7.134.131.1034 > 204.152.184.27.21: P [tcp sum ok] 46:54(8) ack 205 win 58080 (DF) (ttl 64, id 1849, len 48) 09:36:02.060501 AF 2 60: 204.152.184.27.21 > 64.7.134.131.1034: P [tcp sum ok] 205:225(20) ack 54 win 61440 [tos 0x10] (ttl 46, id 33043, len 60) 09:36:02.060884 AF 2 62: 64.7.134.131.1034 > 204.152.184.27.21: P [tcp sum ok] 54:76(22) ack 225 win 58080 (DF) (ttl 64, id 1850, len 62) 09:36:10.054172 AF 2 62: 64.7.134.131.1034 > 204.152.184.27.21: P [tcp sum ok] 54:76(22) ack 225 win 58080 (DF) (ttl 64, id 1851, len 62) 09:36:10.160969 AF 2 69: 204.152.184.27.21 > 64.7.134.131.1034: P [tcp sum ok] 225:254(29) ack 76 win 61440 (DF) [tos 0x10] (ttl 46, id 34610, len 69) 09:36:10.161372 AF 2 64: 64.7.134.131.1034 > 204.152.184.27.21: P [tcp sum ok] 76:100(24) ack 254 win 58080 (DF) (ttl 64, id 1852, len 64) 09:36:26.154296 AF 2 64: 64.7.134.131.1034 > 204.152.184.27.21: P [tcp sum ok] 76:100(24) ack 254 win 58080 (DF) (ttl 64, id 1853, len 64) 09:36:26.251342 AF 2 53: 204.152.184.27.21 > 64.7.134.131.1034: P [tcp sum ok] 254:267(13) ack 100 win 61440 [tos 0x10] (ttl 46, id 38967, len 53) 09:36:26.251621 AF 2 64: 64.7.134.131.1034 > 204.152.184.27.21: P [tcp sum ok] 100:124(24) ack 267 win 58080 (DF) (ttl 64, id 1854, len 64) 09:36:58.244571 AF 2 64: 64.7.134.131.1034 > 204.152.184.27.21: P [tcp sum ok] 100:124(24) ack 267 win 58080 (DF) (ttl 64, id 1855, len 64) 09:36:58.345399 AF 2 60: 204.152.184.27.21 > 64.7.134.131.1034: P [tcp sum ok] 267:287(20) ack 124 win 61440 [tos 0x10] (ttl 46, id 48964, len 60) 09:36:58.346134 AF 2 46: 64.7.134.131.1034 > 204.152.184.27.21: P [tcp sum ok] 124:130(6) ack 287 win 58080 (DF) (ttl 64, id 1856, len 46) 09:38:02.345105 AF 2 46: 64.7.134.131.1034 > 204.152.184.27.21: P [tcp sum ok] 124:130(6) ack 287 win 58080 (DF) (ttl 64, id 1857, len 46) 09:38:02.451999 AF 2 90: 204.152.184.27.21 > 64.7.134.131.1034: P [tcp sum ok] 287:337(50) ack 130 win 61440 (DF) [tos 0x10] (ttl 46, id 52676, len 90) 09:38:02.452629 AF 2 60: 64.7.134.131.1035 > 204.152.184.27.23368: S [tcp sum ok] 2641833555:2641833555(0) win 57344 (DF) (ttl 64, id 1858, len 60) 09:38:02.545076 AF 2 40: 64.7.134.131.1034 > 204.152.184.27.21: . [tcp sum ok] 130:130(0) ack 337 win 58080 (DF) (ttl 64, id 1859, len 40) 09:38:02.557134 AF 2 48: 204.152.184.27.23368 > 64.7.134.131.1035: S [tcp sum ok] 424791459:424791459(0) ack 2641833556 win 61440 (ttl 46, id 52679, len 48) 09:38:02.557208 AF 2 40: 64.7.134.131.1035 > 204.152.184.27.23368: . [tcp sum ok] 1:1(0) ack 1 win 58080 (DF) (ttl 64, id 1860, len 40) 09:38:02.557300 AF 2 64: 64.7.134.131.1034 > 204.152.184.27.21: P [tcp sum ok] 130:154(24) ack 337 win 58080 (DF) (ttl 64, id 1861, len 64) 09:39:06.555657 AF 2 64: 64.7.134.131.1034 > 204.152.184.27.21: P [tcp sum ok] 130:154(24) ack 337 win 58080 (DF) (ttl 64, id 1862, len 64) 09:39:06.658855 AF 2 120: 204.152.184.27.21 > 64.7.134.131.1034: P 337:417(80) ack 154 win 61440 (DF) [tos 0x10] (ttl 46, id 58021, len 120) 09:39:06.660247 AF 2 116: 64.7.134.131.22 > 199.212.134.18.2408: P 145:209(64) ack 96 win 57600 (DF) [tos 0x10] (ttl 64, id 1863, len 116) 09:39:06.660781 AF 2 116: 64.7.134.131.22 > 199.212.134.18.2408: P 209:273(64) ack 96 win 57600 (DF) [tos 0x10] (ttl 64, id 1864, len 116) 09:39:06.677011 AF 2 1492: 204.152.184.27.23368 > 64.7.134.131.1035: . 1:1453(1452) ack 1 win 61440 (DF) [tos 0x10] (ttl 46, id 58022, len 1492) 09:39:06.688308 AF 2 1492: 204.152.184.27.23368 > 64.7.134.131.1035: . 1453:2905(1452) ack 1 win 61440 (DF) [tos 0x10] (ttl 46, id 58023, len 1492) 09:39:06.688373 AF 2 40: 64.7.134.131.1035 > 204.152.184.27.23368: . [tcp sum ok] 1:1(0) ack 2905 win 56628 (DF) (ttl 64, id 1865, len 40) 09:39:06.692266 AF 2 52: 199.212.134.18.2408 > 64.7.134.131.22: . [tcp sum ok] 96:96(0) ack 273 win 33088 (DF) [tos 0x10] (ttl 61, id 12670, len 52) 09:39:06.755625 AF 2 40: 64.7.134.131.1034 > 204.152.184.27.21: . [tcp sum ok] 154:154(0) ack 417 win 58080 (DF) (ttl 64, id 1866, len 40) 09:39:15.733447 AF 2 1492: 204.152.184.27.23368 > 64.7.134.131.1035: . 1:1453(1452) ack 1 win 61440 (DF) [tos 0x10] (ttl 46, id 58608, len 1492) 09:39:15.733539 AF 2 40: 64.7.134.131.1035 > 204.152.184.27.23368: . [tcp sum ok] 1:1(0) ack 2905 win 58080 (DF) (ttl 64, id 1867, len 40) 09:39:15.744935 AF 2 1492: 204.152.184.27.23368 > 64.7.134.131.1035: . 1453:2905(1452) ack 1 win 61440 (DF) [tos 0x10] (ttl 46, id 58609, len 1492) 09:39:15.744992 AF 2 40: 64.7.134.131.1035 > 204.152.184.27.23368: . [tcp sum ok] 1:1(0) ack 2905 win 58080 (DF) (ttl 64, id 1868, len 40) 09:39:15.856797 AF 2 1492: 204.152.184.27.23368 > 64.7.134.131.1035: . 2905:4357(1452) ack 1 win 61440 (DF) [tos 0x10] (ttl 46, id 58632, len 1492) 09:39:15.857208 AF 2 116: 64.7.134.131.22 > 199.212.134.18.2408: P 273:337(64) ack 96 win 57600 (DF) [tos 0x10] (ttl 64, id 1869, len 116) 09:39:15.857719 AF 2 116: 64.7.134.131.22 > 199.212.134.18.2408: P 337:401(64) ack 96 win 57600 (DF) [tos 0x10] (ttl 64, id 1870, len 116) 09:39:15.868400 AF 2 1492: 204.152.184.27.23368 > 64.7.134.131.1035: . 4357:5809(1452) ack 1 win 61440 (DF) [tos 0x10] (ttl 46, id 58633, len 1492) 09:39:15.868463 AF 2 40: 64.7.134.131.1035 > 204.152.184.27.23368: . [tcp sum ok] 1:1(0) ack 5809 win 56628 (DF) (ttl 64, id 1871, len 40) 09:39:15.879948 AF 2 1492: 204.152.184.27.23368 > 64.7.134.131.1035: . 5809:7261(1452) ack 1 win 61440 (DF) [tos 0x10] (ttl 46, id 58634, len 1492) 09:39:15.880058 AF 2 40: 64.7.134.131.1035 > 204.152.184.27.23368: . [tcp sum ok] 1:1(0) ack 7261 win 58080 (DF) (ttl 64, id 1872, len 40) 09:39:15.889095 AF 2 52: 199.212.134.18.2408 > 64.7.134.131.22: . [tcp sum ok] 96:96(0) ack 401 win 33088 (DF) [tos 0x10] (ttl 61, id 24424, len 52) 09:39:17.773422 AF 2 100: 199.212.134.18.2408 > 64.7.134.131.22: P 96:144(48) ack 401 win 33120 (DF) [tos 0x10] (ttl 61, id 3434, len 100) 09:39:17.774826 AF 2 40: 64.7.134.131.1035 > 204.152.184.27.23368: F [tcp sum ok] 1:1(0) ack 7261 win 58080 (DF) (ttl 64, id 1873, len 40) 09:39:17.775460 AF 2 276: 64.7.134.131.22 > 199.212.134.18.2408: P 401:625(224) ack 144 win 57600 (DF) [tos 0x10] (ttl 64, id 1874, len 276) 09:39:17.887131 AF 2 1492: 204.152.184.27.23368 > 64.7.134.131.1035: . 7261:8713(1452) ack 2 win 61440 (DF) [tos 0x10] (ttl 46, id 58732, len 1492) 09:39:17.887224 AF 2 40: 64.7.134.131.1035 > 204.152.184.27.23368: R [tcp sum ok] 2641833557:2641833557(0) win 0 (ttl 64, id 1875, len 40) 09:39:17.898658 AF 2 1492: 204.152.184.27.23368 > 64.7.134.131.1035: . 8713:10165(1452) ack 2 win 61440 (DF) [tos 0x10] (ttl 46, id 58733, len 1492) 09:39:17.898704 AF 2 40: 64.7.134.131.1035 > 204.152.184.27.23368: R [tcp sum ok] 2641833557:2641833557(0) win 0 (ttl 64, id 1876, len 40) 09:39:17.910008 AF 2 1492: 204.152.184.27.23368 > 64.7.134.131.1035: . 10165:11617(1452) ack 2 win 61440 (DF) [tos 0x10] (ttl 46, id 58734, len 1492) 09:39:17.910049 AF 2 40: 64.7.134.131.1035 > 204.152.184.27.23368: R [tcp sum ok] 2641833557:2641833557(0) win 0 (ttl 64, id 1877, len 40) 09:39:17.910172 AF 2 52: 199.212.134.18.2408 > 64.7.134.131.22: . [tcp sum ok] 144:144(0) ack 625 win 33120 (DF) [tos 0x10] (ttl 61, id 21269, len 52) 09:39:31.974423 AF 2 60: 202.41.239.22.45927 > 64.7.134.131.21: S [tcp sum ok] 1016522058:1016522058(0) win 5840 (DF) (ttl 48, id 61072, len 60) 09:39:31.974497 AF 2 40: 64.7.134.131.21 > 202.41.239.22.45927: R [tcp sum ok] 0:0(0) ack 1016522059 win 0 (ttl 64, id 1878, len 40) 09:39:40.783492 AF 2 100: 199.212.134.18.2411 > 64.7.134.131.22: P 1:49(48) ack 64 win 33120 (DF) [tos 0x10] (ttl 61, id 24638, len 100) 09:39:40.785438 AF 2 100: 64.7.134.131.22 > 199.212.134.18.2411: P 64:112(48) ack 49 win 57600 (DF) [tos 0x10] (ttl 64, id 1879, len 100) 09:39:40.785946 AF 2 100: 64.7.134.131.22 > 199.212.134.18.2411: P 112:160(48) ack 49 win 57600 (DF) [tos 0x10] (ttl 64, id 1880, len 100) 09:39:40.826274 AF 2 52: 199.212.134.18.2411 > 64.7.134.131.22: . [tcp sum ok] 49:49(0) ack 160 win 33096 (DF) [tos 0x10] (ttl 61, id 16243, len 52) --=====================_1109705762==_-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 25 8:38:11 2002 Delivered-To: freebsd-net@freebsd.org Received: from obsidian.sentex.ca (obsidian.sentex.ca [64.7.128.101]) by hub.freebsd.org (Postfix) with ESMTP id F0BC937B400 for ; Tue, 25 Jun 2002 08:38:01 -0700 (PDT) Received: from simian.sentex.net (pyroxene.sentex.ca [199.212.134.18]) by obsidian.sentex.ca (8.12.4/8.12.4) with ESMTP id g5PFbue0012307; Tue, 25 Jun 2002 11:37:57 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <5.1.0.14.0.20020625112547.057eb870@marble.sentex.ca> X-Sender: mdtpop@marble.sentex.ca X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 25 Jun 2002 11:40:48 -0400 To: Andre Oppermann From: Mike Tancsa Subject: Re: SOLVED! Native PPPoE broken (4.6-STABLE), RP-PPPoE working?! Cc: Julian Elischer , freebsd-net@freebsd.org In-Reply-To: <3D183606.BBD1DE54@tix.ch> References: <2trfhu0tbekq67seicn4amdovp7564ji62@4ax.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: By Sentex Communications (obsidian/20020220) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In short, VJ-Header Compression! Why, I dont know. The exact same config works agains the SMSes by Redback. But not the Unisphere ERX Here is what I did to get it to all work. a) On my radius server, I had to get rid of Framed-Compression = Van-Jacobsen-TCP-IP b) On the FreeBSD box, I had to put disable vjcomp _Before_, on the Cisco terminating L2TP server we see bell-border#show int vi426 Virtual-Access426 is up, line protocol is up Hardware is Virtual Access interface Interface is unnumbered. Using address of Loopback0 (64.7.134.129) MTU 1492 bytes, BW 18868 Kbit, DLY 100000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation PPP, loopback not set Keepalive set (10 sec) DTR is pulsed for 5 seconds on reset LCP Open Open: IPCP Last input 01:11:57, output never, output hang never Last clearing of "show interface" counters 03:33:26 Queueing strategy: fifo Output queue 0/40, 0 drops; input queue 0/75, 0 drops 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 9265 packets input, 4481181 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 8720 packets output, 1141908 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 output buffer failures, 0 output buffers swapped out 0 carrier transitions bell-border#show int vi426 confi Virtual-Access426 is an L2TP link interface Building configuration... interface Virtual-Access426 configuration... mtu 1492 ip unnumbered Loopback0 ip tcp header-compression And _after_ bell-border#show int vi63 Virtual-Access63 is up, line protocol is up Hardware is Virtual Access interface Interface is unnumbered. Using address of Loopback0 (64.7.134.129) MTU 1492 bytes, BW 18868 Kbit, DLY 100000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation PPP, loopback not set Keepalive set (10 sec) DTR is pulsed for 5 seconds on reset LCP Open Open: IPCP Last input 00:00:09, output never, output hang never Last clearing of "show interface" counters 00:14:45 Queueing strategy: fifo Output queue 0/40, 0 drops; input queue 0/75, 0 drops 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 10 packets input, 217 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 8 packets output, 139 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 output buffer failures, 0 output buffers swapped out 0 carrier transitions bell-border#show int vi63 config Virtual-Access63 is an L2TP link interface Building configuration... interface Virtual-Access63 configuration... mtu 1492 ip unnumbered Loopback0 iscar# ifconfig tun0 tun0: flags=8051 mtu 1492 inet6 fe80::2d0:b7ff:fea6:4285%tun0 prefixlen 64 scopeid 0x8 inet 64.7.134.131 --> 64.7.134.129 netmask 0xffffff00 Opened by PID 55 iscar# fetch ftp://ftp.isc.org/isc/bind9/9.2.1/bind-9.2.1.tar.gz Receiving bind-9.2.1.tar.gz (5021044 bytes): 100% 5021044 bytes transferred in 39.9 seconds (122.76 kBps) iscar# To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 25 14:14:13 2002 Delivered-To: freebsd-net@freebsd.org Received: from soho1.binc.net (soho1.binc.net [64.73.16.3]) by hub.freebsd.org (Postfix) with SMTP id 48D1C37B417 for ; Tue, 25 Jun 2002 14:13:12 -0700 (PDT) Received: (qmail 10785 invoked from network); 25 Jun 2002 21:13:11 -0000 Received: from localhost (HELO the-rob.com) ([127.0.0.1]) (envelope-sender ) by localhost (qmail-ldap-1.03) with SMTP for ; 25 Jun 2002 21:13:11 -0000 Received: from 216.170.184.18 (SquirrelMail authenticated user rob@the-rob.com) by www.soho.berbee.com with HTTP; Tue, 25 Jun 2002 16:13:11 -0500 (CDT) Message-ID: <1329.216.170.184.18.1025039591.squirrel@www.soho.berbee.com> Date: Tue, 25 Jun 2002 16:13:11 -0500 (CDT) Subject: Re: Issues with pppoe & FBSD 4.6 From: To: Cc: X-Mailer: SquirrelMail (version 1.2.0 [cvs]) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Any progress on this? Just curious. My fbsd box has been down for the last 36 hours. Until yesterday it would be down for 8-10 hours then come up from 16-24. Yesterday it went down at ~8:30 am and has been down since. I left it try and grab IP information but it just "session closed" error (and created a shit load of logs). I copied my config files from my firewall and attempted to make one of my 2 other fbsd boxes my firewall and connect up to the pppoe server but they had the same thing (timeout...Generic "session closed" errors). So it's definatly a fbsd issue. Just wondering on the status...roomates are kinda getting ansy about getting the internet connection up and stable, after being up and down for about a week. rwz To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 26 10:49:21 2002 Delivered-To: freebsd-net@freebsd.org Received: from brainlink.com (mail.brainlink.com [66.228.0.129]) by hub.freebsd.org (Postfix) with ESMTP id 4EFDA37B400 for ; Wed, 26 Jun 2002 10:48:54 -0700 (PDT) Received: from [66.228.0.24] (account anthonyv HELO brainlink.com) by brainlink.com (CommuniGate Pro SMTP 3.5.3) with ESMTP id 14272903 for freebsd-net@freebsd.org; Wed, 26 Jun 2002 13:38:32 -0400 Message-ID: <3D19FE76.1030404@brainlink.com> Date: Wed, 26 Jun 2002 13:48:38 -0400 From: Anthony Volodkin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1a+) Gecko/20020626 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Forwarding UDP packets Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, Recently I've been faced with an odd problem. I setup a pptp link to my network from my friend's XP machine. While the link functions fine (both ends can ping each other, etc), there is one problem with it. I cannot get any broadcast packets through the link. I receive them on the tun0 interface, but no matter what I try i can't get them out of the fxp0 interface. I cannot get them to go the other way either. I know this is against standards, as they suggest routers should not forward broadcast packets, but I would still like to have this ability. Did anyone ever write a patch of some sort or maybe found a tool that does this type of thing? (many people suggested natd, and after playing with that i was able to redirect some bcast packets from tun0 to 1 host on my lan. I was not able to do that in the other direction, however.) I've found an old post on the hackers list by Jonathan Chen that included a patch to enable this kind of functionality. I applied it to my 4.6-RELEASE kernel and it didn't do anything but add a sysctl variable. Any help would be greatly appreciated. Here is that post: --------------------------------------------------- On FreeBSD -CURRENT and -STABLE, packets to broadcast addresses are not forwarded. For instance, if I have a FreeBSD router with interfaces 192.168.1.1 and 192.168.2.1, and I send packets from 192.168.1.2 to 192.168.2.255, the packets are dropped to the floor. IMO, this is wrong... but I haven't consulted all the RFC's so I'm not sure if some standard out there calls for it. In any case, the following patch creates a sysctl knob to turn on or off this feature (since it can be considered a security risk by some). I just want to ask around in case I turned out to be doing something incredibly evil. Comments? -Jon Index: in.h =================================================================== RCS file: /export/ncvs/src/sys/netinet/in.h,v retrieving revision 1.55 diff -u -r1.55 in.h --- in.h 2001/06/15 00:37:27 1.55 +++ in.h 2001/08/09 15:12:19 @@ -452,7 +452,8 @@ #define IPCTL_FASTFORWARDING 14 /* use fast IP forwarding code */ #define IPCTL_KEEPFAITH 15 /* FAITH IPv4->IPv6 translater ctl */ #define IPCTL_GIF_TTL 16 /* default TTL for gif encap packet */ -#define IPCTL_MAXID 17 +#define IPCTL_FORWARD_BROADCAST 18 /* forward broadcast packets */ +#define IPCTL_MAXID 18 #define IPCTL_NAMES { \ { 0, 0 }, \ Index: ip_input.c =================================================================== RCS file: /export/ncvs/src/sys/netinet/ip_input.c,v retrieving revision 1.174 diff -u -r1.174 ip_input.c --- ip_input.c 2001/06/23 17:17:58 1.174 +++ ip_input.c 2001/08/09 15:33:59 @@ -103,6 +103,10 @@ SYSCTL_INT(_net_inet_ip, IPCTL_FORWARDING, forwarding, CTLFLAG_RW, &ipforwarding, 0, "Enable IP forwarding between interfaces"); +int ipforward_broadcast = 0; +SYSCTL_INT(_net_inet_ip, IPCTL_FORWARD_BROADCAST, forward_broadcast, CTLFLAG_RW, + &ipforward_broadcast, 0, "Enable broadcast packets when forwarding IP packets"); + static int ipsendredirects = 1; /* XXX */ SYSCTL_INT(_net_inet_ip, IPCTL_SENDREDIRECTS, redirect, CTLFLAG_RW, &ipsendredirects, 0, "Enable sending IP redirects"); @@ -1684,7 +1688,8 @@ } error = ip_output(m, (struct mbuf *)0, &ipforward_rt, - IP_FORWARDING, 0); + IP_FORWARDING| + (ipforward_broadcast?IP_ALLOWBROADCAST:0), 0); if (error) ipstat.ips_cantforward++; else { -- Anthony Volodkin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 26 13:19:10 2002 Delivered-To: freebsd-net@freebsd.org Received: from brainlink.com (mail.brainlink.com [66.228.0.129]) by hub.freebsd.org (Postfix) with ESMTP id F2ECD37BE65 for ; Wed, 26 Jun 2002 13:09:26 -0700 (PDT) Received: from [66.228.0.24] (account anthonyv HELO brainlink.com) by brainlink.com (CommuniGate Pro SMTP 3.5.3) with ESMTP id 14275318; Wed, 26 Jun 2002 15:41:58 -0400 Message-ID: <3D1A1B64.402@brainlink.com> Date: Wed, 26 Jun 2002 15:52:04 -0400 From: Anthony Volodkin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1a+) Gecko/20020626 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Elischer Cc: freebsd-net@freebsd.org Subject: Re: Forwarding UDP packets References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I use poptop+the pppd that is included with 4.6-RELEASE. On the XP side, my friend just sets up a "Virtual Private Networking Connection" using the native XP client. Here are my /etc/ppp/options, if you wanted protocol info: lock debug auth proxyarp +chap +chapms +chapms-v2 and the relevant portion of ppp.conf: pptp: enable chap enable proxy set ifaddr 192.168.1.100 192.168.2.200-192.168.2.205 255.255.255.0 >what method of doing pptp are you using? > > >On Wed, 26 Jun 2002, Anthony Volodkin wrote: > > > >>Hi, >> >>Recently I've been faced with an odd problem. I setup a pptp link to my >>network from my friend's XP machine. While the link functions fine >>(both ends can ping each other, etc), there is one problem with it. I >>cannot get any broadcast packets through the link. I receive them on >>the tun0 interface, but no matter what I try i can't get them out of the >>fxp0 interface. I cannot get them to go the other way either. I know >>this is against standards, as they suggest routers should not forward >>broadcast packets, but I would still like to have this ability. >> >>Did anyone ever write a patch of some sort or maybe found a tool that >>does this type of thing? >>(many people suggested natd, and after playing with that i was able to >>redirect some bcast packets from tun0 to 1 host on my lan. I was not >>able to do that in the other direction, however.) >> >>I've found an old post on the hackers list by Jonathan Chen that >>included a patch to enable this kind of functionality. I applied it to >>my 4.6-RELEASE kernel and it didn't do anything but add a sysctl >>variable. Any help would be greatly appreciated. >> >>Here is that post: >> >>--------------------------------------------------- >> >>On FreeBSD -CURRENT and -STABLE, packets to broadcast addresses are not >>forwarded. For instance, if I have a FreeBSD router with interfaces >>192.168.1.1 and 192.168.2.1, and I send packets from 192.168.1.2 to >>192.168.2.255, the packets are dropped to the floor. IMO, this is wrong... >>but I haven't consulted all the RFC's so I'm not sure if some standard out >>there calls for it. In any case, the following patch creates a sysctl knob >>to turn on or off this feature (since it can be considered a security risk >>by some). I just want to ask around in case I turned out to be doing >>something incredibly evil. Comments? >> >>-Jon >> >>Index: in.h >>=================================================================== >>RCS file: /export/ncvs/src/sys/netinet/in.h,v >>retrieving revision 1.55 >>diff -u -r1.55 in.h >>--- in.h 2001/06/15 00:37:27 1.55 >>+++ in.h 2001/08/09 15:12:19 >>@@ -452,7 +452,8 @@ >> #define IPCTL_FASTFORWARDING 14 /* use fast IP forwarding code */ >> #define IPCTL_KEEPFAITH 15 /* FAITH IPv4->IPv6 translater ctl */ >> #define IPCTL_GIF_TTL 16 /* default TTL for gif encap packet */ >>-#define IPCTL_MAXID 17 >>+#define IPCTL_FORWARD_BROADCAST 18 /* forward broadcast packets */ >>+#define IPCTL_MAXID 18 >> >> #define IPCTL_NAMES { \ >> { 0, 0 }, \ >>Index: ip_input.c >>=================================================================== >>RCS file: /export/ncvs/src/sys/netinet/ip_input.c,v >>retrieving revision 1.174 >>diff -u -r1.174 ip_input.c >>--- ip_input.c 2001/06/23 17:17:58 1.174 >>+++ ip_input.c 2001/08/09 15:33:59 >>@@ -103,6 +103,10 @@ >> SYSCTL_INT(_net_inet_ip, IPCTL_FORWARDING, forwarding, CTLFLAG_RW, >> &ipforwarding, 0, "Enable IP forwarding between interfaces"); >> >>+int ipforward_broadcast = 0; >>+SYSCTL_INT(_net_inet_ip, IPCTL_FORWARD_BROADCAST, forward_broadcast, >>CTLFLAG_RW, >>+ &ipforward_broadcast, 0, "Enable broadcast packets when forwarding >>IP packets"); >>+ >> static int ipsendredirects = 1; /* XXX */ >> SYSCTL_INT(_net_inet_ip, IPCTL_SENDREDIRECTS, redirect, CTLFLAG_RW, >> &ipsendredirects, 0, "Enable sending IP redirects"); >>@@ -1684,7 +1688,8 @@ >> } >> >> error = ip_output(m, (struct mbuf *)0, &ipforward_rt, >>- IP_FORWARDING, 0); >>+ IP_FORWARDING| >>+ (ipforward_broadcast?IP_ALLOWBROADCAST:0), 0); >> if (error) >> ipstat.ips_cantforward++; >> else { >> >> >>-- >>Anthony Volodkin >> >> >>To Unsubscribe: send mail to majordomo@FreeBSD.org >>with "unsubscribe freebsd-net" in the body of the message >> >> >> > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 26 13:28:13 2002 Delivered-To: freebsd-net@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id AC5A037CA6D for ; Wed, 26 Jun 2002 13:14:48 -0700 (PDT) Received: from isi.edu (nnyovioroc2ho8li@hbo.isi.edu [128.9.160.75]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g5QKElr22651 for ; Wed, 26 Jun 2002 13:14:48 -0700 (PDT) Message-ID: <3D1A20B7.6030009@isi.edu> Date: Wed, 26 Jun 2002 13:14:47 -0700 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0.0) Gecko/20020618 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: /usr/lib/libtelnet.a missing on 4.6? Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090201020500090001040700" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a cryptographically signed message in MIME format. --------------ms090201020500090001040700 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, I'm trying to build the latest KAME SNAP, and the build fails, because /usr/lib/libtelnet.a is missing on a freshly installed 4.6-RELEASE system (installed from CD). None of our 4.6 systems has it, all of our 4.5 systems do. Is this a bug of the ISO image, or a deliberate change? Thanks, Lars -- Lars Eggert USC Information Sciences Institute --------------ms090201020500090001040700 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIrjCC ArUwggIeoAMCAQICAwWBRzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAxMDgyNDE2NDAwMFoXDTAyMDgyNDE2NDAwMFowVDEP MA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2VydDEc MBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEA0AvLBsD78nxcUHeHkaMgl3b4qYPnfgbf8Lh+HQP8RgGMRG/Yb+vTpkGezlwt9pkJxiD1 1uZDy4CNNJUu3gKxKSb+zRV70O+lkwwftuHoLHoH4xwo3LcQ2LGDpd+I95tUN4dfJ3TmeEcU SF50dC/SuUI4w8AlhXQ8IxrhgdayTpECAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIB BAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1Ud EwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAheZhn0pQA8zI7U2K1ZIAl11j0a1DKxnp3GtT vOUrGRB3WvYxidvdZ1kizhEsWeXU81TkNDH0DaRqtOEeu6Q2OhB+jeKEqY7IDAJE4/fI0e+d 6PnG1hd+vEvYmsKHkmzBhPc94XUOKNWO+qVNP2NGyNI3QIDy5wX4fdcOo1S34r4wggK1MIIC HqADAgECAgMFgUcwDQYJKoZIhvcNAQECBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYD VQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg UlNBIDIwMDAuOC4zMDAeFw0wMTA4MjQxNjQwMDBaFw0wMjA4MjQxNjQwMDBaMFQxDzANBgNV BAQTBkVnZ2VydDENMAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkq hkiG9w0BCQEWDWxhcnNlQGlzaS5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANAL ywbA+/J8XFB3h5GjIJd2+KmD534G3/C4fh0D/EYBjERv2G/r06ZBns5cLfaZCcYg9dbmQ8uA jTSVLt4CsSkm/s0Ve9DvpZMMH7bh6Cx6B+McKNy3ENixg6XfiPebVDeHXyd05nhHFEhedHQv 0rlCOMPAJYV0PCMa4YHWsk6RAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy dU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBAgUAA4GBAIXmYZ9KUAPMyO1NitWSAJddY9GtQysZ6dxrU7zlKxkQ d1r2MYnb3WdZIs4RLFnl1PNU5DQx9A2karThHrukNjoQfo3ihKmOyAwCROP3yNHvnej5xtYX frxL2JrCh5JswYT3PeF1DijVjvqlTT9jRsjSN0CA8ucF+H3XDqNUt+K+MIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYICpjCCAqICAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDBYFHMAkGBSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAyMDYyNjIwMTQ0N1owIwYJKoZIhvcNAQkEMRYEFFGKagTIZcxA TqtAxquNm6nB5Y3QMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0B CRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG A1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRl IFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMF gUcwDQYJKoZIhvcNAQEBBQAEgYBeIGvh5r3rwA/vwRbV2FKvMU86iI3e8scvSfixGrI3//iD jkWBjdSsCxQRLDpQybRaA1U3vXkESi4hko+wLY3tF88rfMQJRFCPG9Rk9gWH21FMHtGrUbAU ho++HVFZCIgxpk2Vi5NTLnCUt9dueE9KiGezeiflKzcPo6jKB5UGZwAAAAAAAA== --------------ms090201020500090001040700-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 26 13:36:24 2002 Delivered-To: freebsd-net@freebsd.org Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by hub.freebsd.org (Postfix) with ESMTP id C026337CCA0; Wed, 26 Jun 2002 13:30:13 -0700 (PDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Wed, 26 Jun 2002 16:30:11 -0400 Message-ID: <8C92E23A3E87FB479988285F9E22BE46FDE776@ftmail.lab.flarion.com> From: Matt Impett To: "'freebsd-net@freebsd.org'" Cc: "'freebsd-questions@freebsd.org'" Subject: source address based routing Date: Wed, 26 Jun 2002 16:30:10 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello, I was wondering if it is possible to do pure source address based routing under FreeBSD. What I really want to do is route packets from particular source addresses to tunnels (gif devices) regardless of what the packet's destination address is. thanks, matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 26 13:41:46 2002 Delivered-To: freebsd-net@freebsd.org Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by hub.freebsd.org (Postfix) with ESMTP id C026337CCA0; Wed, 26 Jun 2002 13:30:13 -0700 (PDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Wed, 26 Jun 2002 16:30:11 -0400 Message-ID: <8C92E23A3E87FB479988285F9E22BE46FDE776@ftmail.lab.flarion.com> From: Matt Impett To: "'freebsd-net@freebsd.org'" Cc: "'freebsd-questions@freebsd.org'" Subject: source address based routing Date: Wed, 26 Jun 2002 16:30:10 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello, I was wondering if it is possible to do pure source address based routing under FreeBSD. What I really want to do is route packets from particular source addresses to tunnels (gif devices) regardless of what the packet's destination address is. thanks, matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 26 16:21: 4 2002 Delivered-To: freebsd-net@freebsd.org Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by hub.freebsd.org (Postfix) with ESMTP id 1358E37B5AF; Wed, 26 Jun 2002 16:07:47 -0700 (PDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Wed, 26 Jun 2002 17:21:04 -0400 Message-ID: <8C92E23A3E87FB479988285F9E22BE46FDE778@ftmail.lab.flarion.com> From: Matt Impett To: 'Lars Eggert' , Matt Impett Cc: "'freebsd-net@freebsd.org'" , "'freebsd-questions@freebsd.org'" Subject: RE: source address based routing Date: Wed, 26 Jun 2002 17:21:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org inline.. > -----Original Message----- > From: Lars Eggert [mailto:larse@ISI.EDU] > Sent: Wednesday, June 26, 2002 5:10 PM > To: Matt Impett > Cc: 'freebsd-net@freebsd.org'; 'freebsd-questions@freebsd.org' > Subject: Re: source address based routing > > > Matt Impett wrote: > > I have looked at the firewall rather exetensively, but I > don't know that it > > can do what I want. > > Maybe you should describe what you want in a little more > detail then :-) gladly.. I am trying to implement reverse tunneling for mobile-IP. The basic idea is that packets must be reverse tunneled to different IP addresses depending on the source address of the packet. The reason the tunnel does not have an IP address associated with it is that I don't want to forward traffic down the tunnel for any other reason besides source addresses. As soon as I assign the tunnel interface an address, traffic sent to that address will be tunneled. > > > From what I can tell, the firewall fwd functionality allows > you to redirect > > a packet to a different next hop based on any of the > firewall matching rules > > (one of which is source address). > > > > What I want to do, however, is redirect the packet to a > tunnel (gif device) > > that has no next-hop associated with it. Is there any way > to do this?? > > How does it not have a next hop associated with it? Are you > leaving the > addresses unconfigured? Maybe you can still use ipfw like this: > > route add DUMMY_NEXT_HOP -interface GIF > ipfw add fwd DUMMY_NEXT_HOP all from SOURCE to any I have thought about doing this, but am a little concerned about assigning DUMMY_NEXT_HOP. As soon as I issue "route add DUMMY_NEXT_HOP -interface GIF", that DUMMY_NEXT_HOP address is now unusable by anyone else. Therefore, I guess it would have to be private, but then this would stop anyone from actually using this private address in the local domain. Plus, I don't know how many DUMMY_NEXT_HOPs to allocate, as I would need one for each tunnel I have set up, and the number of tunnels I set up is dependent on the number of mobile's that come into the system (which is somewhat of an unknown). What do you think?? matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 26 16:30:37 2002 Delivered-To: freebsd-net@freebsd.org Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by hub.freebsd.org (Postfix) with ESMTP id B9F5537BAA9; Wed, 26 Jun 2002 16:08:05 -0700 (PDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Wed, 26 Jun 2002 17:01:13 -0400 Message-ID: <8C92E23A3E87FB479988285F9E22BE46FDE777@ftmail.lab.flarion.com> From: Matt Impett To: 'Lars Eggert' , Matt Impett Cc: "'freebsd-net@freebsd.org'" , "'freebsd-questions@freebsd.org'" Subject: RE: source address based routing Date: Wed, 26 Jun 2002 17:01:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I have looked at the firewall rather exetensively, but I don't know that it can do what I want. From what I can tell, the firewall fwd functionality allows you to redirect a packet to a different next hop based on any of the firewall matching rules (one of which is source address). What I want to do, however, is redirect the packet to a tunnel (gif device) that has no next-hop associated with it. Is there any way to do this?? thanks, matt > -----Original Message----- > From: Lars Eggert [mailto:larse@ISI.EDU] > Sent: Wednesday, June 26, 2002 4:41 PM > To: Matt Impett > Cc: 'freebsd-net@freebsd.org'; 'freebsd-questions@freebsd.org' > Subject: Re: source address based routing > > > Matt Impett wrote: > > I was wondering if it is possible to do pure source address > based routing > > under FreeBSD. What I really want to do is route packets > from particular > > source addresses to tunnels (gif devices) regardless of > what the packet's > > destination address is. > > Firewall forwarding will do that, see ipfw (8), esp. the fwd action. > > Lars > -- > Lars Eggert USC Information > Sciences Institute > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 26 16:37:53 2002 Delivered-To: freebsd-net@freebsd.org Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by hub.freebsd.org (Postfix) with ESMTP id 0B57A37BABE; Wed, 26 Jun 2002 16:08:21 -0700 (PDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Wed, 26 Jun 2002 17:42:55 -0400 Message-ID: <8C92E23A3E87FB479988285F9E22BE46FDE779@ftmail.lab.flarion.com> From: Matt Impett To: 'Lars Eggert' , Matt Impett Cc: "'freebsd-net@freebsd.org'" , "'freebsd-questions@freebsd.org'" Subject: RE: source address based routing Date: Wed, 26 Jun 2002 17:42:48 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Ok.. Modifying the ipfw stuff is where I ended up after looking at this for a while. I have thought about adding something like the following: ipfw add fwd-intf GIF-DEVICE all from SOURCE to any The only problem I have seen with this (besides needing to modify the kernel and the user space ipfw application) was this: Once this rule is matched, the output routine of the GIF-DEVICE will be called and it will expect a rtentry structure to be passed. Unfortunately, I won't really have a correct rtentry structure as I am now forwarding to the device on a firewall rule instead of a routing table entry. However, from looking at the gif code, I don't think it really uses the rtentry structure anyway, so hopefully I won't break too much by passing a bogus one. Sound reasonable?? matt > -----Original Message----- > From: Lars Eggert [mailto:larse@ISI.EDU] > Sent: Wednesday, June 26, 2002 5:31 PM > To: Matt Impett > Cc: 'freebsd-net@freebsd.org'; 'freebsd-questions@freebsd.org' > Subject: Re: source address based routing > > > Matt Impett wrote: > > gladly.. I am trying to implement reverse tunneling for > mobile-IP. The > > basic idea is that packets must be reverse tunneled to different IP > > addresses depending on the source address of the packet. > The reason the > > tunnel does not have an IP address associated with it is > that I don't want > > to forward traffic down the tunnel for any other reason > besides source > > addresses. As soon as I assign the tunnel interface an > address, traffic > > sent to that address will be tunneled. > > Thanks, that was really helpful to get an idea of what your > scenario is! > > >> route add DUMMY_NEXT_HOP -interface GIF > >> ipfw add fwd DUMMY_NEXT_HOP all from SOURCE to any > > > > > > I have thought about doing this, but am a little concerned > about assigning > > DUMMY_NEXT_HOP. As soon as I issue "route add > DUMMY_NEXT_HOP -interface > > GIF", that DUMMY_NEXT_HOP address is now unusable by anyone else. > > Therefore, I guess it would have to be private, but then > this would stop > > anyone from actually using this private address in the local domain. > > Well, nobody should be using a private address in any domain that's > connected to the Internet, so you may be safe there. > > If not, then you could do either > > (1) modify ipfw to allow specification of a local interface (as > opposed to a gatway IP adress) in the fwd rule > or > (2) buy a large enough IP block so you can use your own > addresses for DUMMY_NEXT_HOP > > > Plus, > > I don't know how many DUMMY_NEXT_HOPs to allocate, as I > would need one for > > each tunnel I have set up, and the number of tunnels I set > up is dependent > > on the number of mobile's that come into the system (which > is somewhat of an > > unknown). > > This makes (2) look infeasible, but (1) may still be an option. > > Lars > -- > Lars Eggert USC Information > Sciences Institute > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 26 16:44:14 2002 Delivered-To: freebsd-net@freebsd.org Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by hub.freebsd.org (Postfix) with SMTP id A8E3837BAC9 for ; Wed, 26 Jun 2002 16:08:30 -0700 (PDT) Received: (qmail 2457 invoked from network); 26 Jun 2002 22:07:37 -0000 Received: from unknown (HELO pipeline.ch) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 26 Jun 2002 22:07:37 -0000 Message-ID: <3D1A3B11.2DDC266C@pipeline.ch> Date: Thu, 27 Jun 2002 00:07:13 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Matt Impett Cc: "'freebsd-net@freebsd.org'" , "'freebsd-questions@freebsd.org'" Subject: Re: source address based routing References: <8C92E23A3E87FB479988285F9E22BE46FDE776@ftmail.lab.flarion.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Matt Impett wrote: > > Hello, > > I was wondering if it is possible to do pure source address based routing > under FreeBSD. What I really want to do is route packets from particular > source addresses to tunnels (gif devices) regardless of what the packet's > destination address is. Not yet there. We're working on it and much more. It'll (hopefully) be in 5.0-RELEASE in November. For a workaround at the moment have a look at the "fwd" action in ipfw. -- Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 26 16:51:21 2002 Delivered-To: freebsd-net@freebsd.org Received: from tesla.foo.is (tesla.reverse-bias.org [217.151.166.96]) by hub.freebsd.org (Postfix) with ESMTP id 8C33637BF26; Wed, 26 Jun 2002 16:25:04 -0700 (PDT) Received: from there (eniac.foo.is [192.168.1.25]) by tesla.foo.is (Postfix) with SMTP id 3F6942731; Wed, 26 Jun 2002 22:18:24 +0000 (GMT) Content-Type: text/plain; charset="iso-8859-1" From: Baldur Gislason To: Matt Impett Subject: Re: source address based routing Date: Wed, 26 Jun 2002 22:16:42 +0000 X-Mailer: KMail [version 1.3.2] References: <8C92E23A3E87FB479988285F9E22BE46FDE776@ftmail.lab.flarion.com> In-Reply-To: <8C92E23A3E87FB479988285F9E22BE46FDE776@ftmail.lab.flarion.com> Cc: freebsd-net@freebsd.org, freebsd-questions@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20020626221824.3F6942731@tesla.foo.is> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org That's simple, FreeBSD can do policy based routing with ipfw. you need to compile a kernel with: options IPFIREWALL options IPFIREWALL_FORWARD myself I prefer to have these too but they're not absolutely necessary: options IPFIREWALL_VERBOSE options IPFIREWALL_VERBOSE_LIMIT=100 options IPFIREWALL_DEFAULT_TO_ACCEPT options IPDIVERT options DUMMYNET options BRIDGE Once we have a running kernel with the proper options, sysctl net.inet.ip.sourceroute=1 and use the ipfw fwd rules to set gateways based on policies. example: ipfw add fwd 192.168.1.1 ip from 172.20.0.0/24 to not 172.20.0.0/24 out makes 192.168.1.1 the next hop for any packet originating from 172.22.0.0/24 but destined outside 172.20.0.0/24 Baldur PS: man 8 ipfw and read http://www.freebsd.org/handbook and search http://www.google.com for further clues. On Wednesday 26 June 2002 20:30, you wrote: > Hello, > > I was wondering if it is possible to do pure source address based routing > under FreeBSD. What I really want to do is route packets from particular > source addresses to tunnels (gif devices) regardless of what the packet's > destination address is. > > thanks, > matt > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 26 16:57:23 2002 Delivered-To: freebsd-net@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id 73BD637BAC1; Wed, 26 Jun 2002 16:36:01 -0700 (PDT) Received: from isi.edu (lfr04ay4i1vhb5vs@hbo.isi.edu [128.9.160.75]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g5QLkxr20097; Wed, 26 Jun 2002 14:46:59 -0700 (PDT) Message-ID: <3D1A3653.4070601@isi.edu> Date: Wed, 26 Jun 2002 14:46:59 -0700 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0.0) Gecko/20020618 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: Matt Impett Cc: "'freebsd-net@freebsd.org'" , "'freebsd-questions@freebsd.org'" Subject: Re: source address based routing References: <8C92E23A3E87FB479988285F9E22BE46FDE779@ftmail.lab.flarion.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090407060306030407080900" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a cryptographically signed message in MIME format. --------------ms090407060306030407080900 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Matt Impett wrote: > Ok.. Modifying the ipfw stuff is where I ended up after looking at this for > a while. I have thought about adding something like the following: > > ipfw add fwd-intf GIF-DEVICE all from SOURCE to any > > The only problem I have seen with this (besides needing to modify the kernel > and the user space ipfw application) was this: Once this rule is matched, > the output routine of the GIF-DEVICE will be called and it will expect a > rtentry structure to be passed. Unfortunately, I won't really have a > correct rtentry structure as I am now forwarding to the device on a firewall > rule instead of a routing table entry. > > However, from looking at the gif code, I don't think it really uses the > rtentry structure anyway, so hopefully I won't break too much by passing a > bogus one. > > Sound reasonable?? Yup, but I'm really too familiar with the routing or ipfw parts of the network stack. Ping Luigi? Lars PS: Minor nit: I'd overload the "fwd" action instead of creating a new one. -- Lars Eggert USC Information Sciences Institute --------------ms090407060306030407080900 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIrjCC ArUwggIeoAMCAQICAwWBRzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAxMDgyNDE2NDAwMFoXDTAyMDgyNDE2NDAwMFowVDEP MA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2VydDEc MBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEA0AvLBsD78nxcUHeHkaMgl3b4qYPnfgbf8Lh+HQP8RgGMRG/Yb+vTpkGezlwt9pkJxiD1 1uZDy4CNNJUu3gKxKSb+zRV70O+lkwwftuHoLHoH4xwo3LcQ2LGDpd+I95tUN4dfJ3TmeEcU SF50dC/SuUI4w8AlhXQ8IxrhgdayTpECAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIB BAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1Ud EwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAheZhn0pQA8zI7U2K1ZIAl11j0a1DKxnp3GtT vOUrGRB3WvYxidvdZ1kizhEsWeXU81TkNDH0DaRqtOEeu6Q2OhB+jeKEqY7IDAJE4/fI0e+d 6PnG1hd+vEvYmsKHkmzBhPc94XUOKNWO+qVNP2NGyNI3QIDy5wX4fdcOo1S34r4wggK1MIIC HqADAgECAgMFgUcwDQYJKoZIhvcNAQECBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYD VQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg UlNBIDIwMDAuOC4zMDAeFw0wMTA4MjQxNjQwMDBaFw0wMjA4MjQxNjQwMDBaMFQxDzANBgNV BAQTBkVnZ2VydDENMAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkq hkiG9w0BCQEWDWxhcnNlQGlzaS5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANAL ywbA+/J8XFB3h5GjIJd2+KmD534G3/C4fh0D/EYBjERv2G/r06ZBns5cLfaZCcYg9dbmQ8uA jTSVLt4CsSkm/s0Ve9DvpZMMH7bh6Cx6B+McKNy3ENixg6XfiPebVDeHXyd05nhHFEhedHQv 0rlCOMPAJYV0PCMa4YHWsk6RAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy dU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBAgUAA4GBAIXmYZ9KUAPMyO1NitWSAJddY9GtQysZ6dxrU7zlKxkQ d1r2MYnb3WdZIs4RLFnl1PNU5DQx9A2karThHrukNjoQfo3ihKmOyAwCROP3yNHvnej5xtYX frxL2JrCh5JswYT3PeF1DijVjvqlTT9jRsjSN0CA8ucF+H3XDqNUt+K+MIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYICpjCCAqICAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDBYFHMAkGBSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAyMDYyNjIxNDY1OVowIwYJKoZIhvcNAQkEMRYEFFGZb2x106c7 6ZOdOUlandfJhzvzMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0B CRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG A1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRl IFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMF gUcwDQYJKoZIhvcNAQEBBQAEgYBSKAGDRolnDtP+zXbkxXCtt3yTszv1cA0YKL3nTK4rRqiD 3n46foKugPf+vz63ruVHjiNJaoDMHp/jvHHrLy5oz7x9bTQcrhBVNDaPhsORePDLw6xaGz6M 0Qhhna1TpmrxsB6Ynhwm1JLBgkLe5xRwEZkjGnIkgArkv9aQwvwJqAAAAAAAAA== --------------ms090407060306030407080900-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 26 17: 3:27 2002 Delivered-To: freebsd-net@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id C854D37C196; Wed, 26 Jun 2002 16:36:02 -0700 (PDT) Received: from isi.edu (bmzncck8qivp1z1v@hbo.isi.edu [128.9.160.75]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g5QKfMr09828; Wed, 26 Jun 2002 13:41:22 -0700 (PDT) Message-ID: <3D1A26F1.2010203@isi.edu> Date: Wed, 26 Jun 2002 13:41:21 -0700 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0.0) Gecko/20020618 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: Matt Impett Cc: "'freebsd-net@freebsd.org'" , "'freebsd-questions@freebsd.org'" Subject: Re: source address based routing References: <8C92E23A3E87FB479988285F9E22BE46FDE776@ftmail.lab.flarion.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050409000508010607060108" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a cryptographically signed message in MIME format. --------------ms050409000508010607060108 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Matt Impett wrote: > I was wondering if it is possible to do pure source address based routing > under FreeBSD. What I really want to do is route packets from particular > source addresses to tunnels (gif devices) regardless of what the packet's > destination address is. Firewall forwarding will do that, see ipfw (8), esp. the fwd action. Lars -- Lars Eggert USC Information Sciences Institute --------------ms050409000508010607060108 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIrjCC ArUwggIeoAMCAQICAwWBRzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAxMDgyNDE2NDAwMFoXDTAyMDgyNDE2NDAwMFowVDEP MA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2VydDEc MBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEA0AvLBsD78nxcUHeHkaMgl3b4qYPnfgbf8Lh+HQP8RgGMRG/Yb+vTpkGezlwt9pkJxiD1 1uZDy4CNNJUu3gKxKSb+zRV70O+lkwwftuHoLHoH4xwo3LcQ2LGDpd+I95tUN4dfJ3TmeEcU SF50dC/SuUI4w8AlhXQ8IxrhgdayTpECAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIB BAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1Ud EwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAheZhn0pQA8zI7U2K1ZIAl11j0a1DKxnp3GtT vOUrGRB3WvYxidvdZ1kizhEsWeXU81TkNDH0DaRqtOEeu6Q2OhB+jeKEqY7IDAJE4/fI0e+d 6PnG1hd+vEvYmsKHkmzBhPc94XUOKNWO+qVNP2NGyNI3QIDy5wX4fdcOo1S34r4wggK1MIIC HqADAgECAgMFgUcwDQYJKoZIhvcNAQECBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYD VQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg UlNBIDIwMDAuOC4zMDAeFw0wMTA4MjQxNjQwMDBaFw0wMjA4MjQxNjQwMDBaMFQxDzANBgNV BAQTBkVnZ2VydDENMAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkq hkiG9w0BCQEWDWxhcnNlQGlzaS5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANAL ywbA+/J8XFB3h5GjIJd2+KmD534G3/C4fh0D/EYBjERv2G/r06ZBns5cLfaZCcYg9dbmQ8uA jTSVLt4CsSkm/s0Ve9DvpZMMH7bh6Cx6B+McKNy3ENixg6XfiPebVDeHXyd05nhHFEhedHQv 0rlCOMPAJYV0PCMa4YHWsk6RAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy dU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBAgUAA4GBAIXmYZ9KUAPMyO1NitWSAJddY9GtQysZ6dxrU7zlKxkQ d1r2MYnb3WdZIs4RLFnl1PNU5DQx9A2karThHrukNjoQfo3ihKmOyAwCROP3yNHvnej5xtYX frxL2JrCh5JswYT3PeF1DijVjvqlTT9jRsjSN0CA8ucF+H3XDqNUt+K+MIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYICpjCCAqICAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDBYFHMAkGBSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAyMDYyNjIwNDEyMVowIwYJKoZIhvcNAQkEMRYEFKSWexpU/HDJ FZKzl5c4qW/wkeVLMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0B CRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG A1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRl IFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMF gUcwDQYJKoZIhvcNAQEBBQAEgYAXPEH++g8TxzREIEwh2OAJncNRXyYuoe59BcSnqbpxiPO2 QvY2QmfSEircQYFEAVTR3ZilkWfSfjawiCHa7MYaSaFTHOA73li+w3qiu3nxlDI64my1Uc3d nKrZiS6ZeEWVWFWKOyKMHwqbhMEuzN9OX0Y90v0/0llqiZfR86rUvgAAAAAAAA== --------------ms050409000508010607060108-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 26 17: 7:28 2002 Delivered-To: freebsd-net@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id 535F337C1B7; Wed, 26 Jun 2002 16:36:08 -0700 (PDT) Received: from isi.edu (95v4ojsb1si25g80@hbo.isi.edu [128.9.160.75]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g5QL9wr28885; Wed, 26 Jun 2002 14:09:58 -0700 (PDT) Message-ID: <3D1A2DA5.8070609@isi.edu> Date: Wed, 26 Jun 2002 14:09:57 -0700 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0.0) Gecko/20020618 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: Matt Impett Cc: "'freebsd-net@freebsd.org'" , "'freebsd-questions@freebsd.org'" Subject: Re: source address based routing References: <8C92E23A3E87FB479988285F9E22BE46FDE777@ftmail.lab.flarion.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010401040100010007060908" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a cryptographically signed message in MIME format. --------------ms010401040100010007060908 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Matt Impett wrote: > I have looked at the firewall rather exetensively, but I don't know that it > can do what I want. Maybe you should describe what you want in a little more detail then :-) > From what I can tell, the firewall fwd functionality allows you to redirect > a packet to a different next hop based on any of the firewall matching rules > (one of which is source address). > > What I want to do, however, is redirect the packet to a tunnel (gif device) > that has no next-hop associated with it. Is there any way to do this?? How does it not have a next hop associated with it? Are you leaving the addresses unconfigured? Maybe you can still use ipfw like this: route add DUMMY_NEXT_HOP -interface GIF ipfw add fwd DUMMY_NEXT_HOP all from SOURCE to any Lars -- Lars Eggert USC Information Sciences Institute --------------ms010401040100010007060908 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIrjCC ArUwggIeoAMCAQICAwWBRzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAxMDgyNDE2NDAwMFoXDTAyMDgyNDE2NDAwMFowVDEP MA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2VydDEc MBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEA0AvLBsD78nxcUHeHkaMgl3b4qYPnfgbf8Lh+HQP8RgGMRG/Yb+vTpkGezlwt9pkJxiD1 1uZDy4CNNJUu3gKxKSb+zRV70O+lkwwftuHoLHoH4xwo3LcQ2LGDpd+I95tUN4dfJ3TmeEcU SF50dC/SuUI4w8AlhXQ8IxrhgdayTpECAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIB BAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1Ud EwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAheZhn0pQA8zI7U2K1ZIAl11j0a1DKxnp3GtT vOUrGRB3WvYxidvdZ1kizhEsWeXU81TkNDH0DaRqtOEeu6Q2OhB+jeKEqY7IDAJE4/fI0e+d 6PnG1hd+vEvYmsKHkmzBhPc94XUOKNWO+qVNP2NGyNI3QIDy5wX4fdcOo1S34r4wggK1MIIC HqADAgECAgMFgUcwDQYJKoZIhvcNAQECBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYD VQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg UlNBIDIwMDAuOC4zMDAeFw0wMTA4MjQxNjQwMDBaFw0wMjA4MjQxNjQwMDBaMFQxDzANBgNV BAQTBkVnZ2VydDENMAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkq hkiG9w0BCQEWDWxhcnNlQGlzaS5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANAL ywbA+/J8XFB3h5GjIJd2+KmD534G3/C4fh0D/EYBjERv2G/r06ZBns5cLfaZCcYg9dbmQ8uA jTSVLt4CsSkm/s0Ve9DvpZMMH7bh6Cx6B+McKNy3ENixg6XfiPebVDeHXyd05nhHFEhedHQv 0rlCOMPAJYV0PCMa4YHWsk6RAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy dU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBAgUAA4GBAIXmYZ9KUAPMyO1NitWSAJddY9GtQysZ6dxrU7zlKxkQ d1r2MYnb3WdZIs4RLFnl1PNU5DQx9A2karThHrukNjoQfo3ihKmOyAwCROP3yNHvnej5xtYX frxL2JrCh5JswYT3PeF1DijVjvqlTT9jRsjSN0CA8ucF+H3XDqNUt+K+MIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYICpjCCAqICAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDBYFHMAkGBSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAyMDYyNjIxMDk1N1owIwYJKoZIhvcNAQkEMRYEFHh7mDGr8wOJ k+B1ugC/RPu6HSzuMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0B CRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG A1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRl IFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMF gUcwDQYJKoZIhvcNAQEBBQAEgYCFKOiTwjk4dNB52qoYjs1BBLglWyLaQV/Vo+rFW5a14LqZ MsFK9kVgJ6XIJEX9NbsVGBp1UuOBTD9uOYIpK/8fUjK9AU737QkIJh71OjoPP/od26w3PUuV i/L8CPyl4f0Hc+DP3AUnk6pUHs35+QXUPKqv1rsLaqUefB3LUA1oJwAAAAAAAA== --------------ms010401040100010007060908-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 26 17:11:48 2002 Delivered-To: freebsd-net@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id C635937C1B9; Wed, 26 Jun 2002 16:36:11 -0700 (PDT) Received: from isi.edu (2jdtd852kvokfblz@hbo.isi.edu [128.9.160.75]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g5QLV1r09593; Wed, 26 Jun 2002 14:31:01 -0700 (PDT) Message-ID: <3D1A3294.6010205@isi.edu> Date: Wed, 26 Jun 2002 14:31:00 -0700 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0.0) Gecko/20020618 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: Matt Impett Cc: "'freebsd-net@freebsd.org'" , "'freebsd-questions@freebsd.org'" Subject: Re: source address based routing References: <8C92E23A3E87FB479988285F9E22BE46FDE778@ftmail.lab.flarion.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050407020502030807060306" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a cryptographically signed message in MIME format. --------------ms050407020502030807060306 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Matt Impett wrote: > gladly.. I am trying to implement reverse tunneling for mobile-IP. The > basic idea is that packets must be reverse tunneled to different IP > addresses depending on the source address of the packet. The reason the > tunnel does not have an IP address associated with it is that I don't want > to forward traffic down the tunnel for any other reason besides source > addresses. As soon as I assign the tunnel interface an address, traffic > sent to that address will be tunneled. Thanks, that was really helpful to get an idea of what your scenario is! >> route add DUMMY_NEXT_HOP -interface GIF >> ipfw add fwd DUMMY_NEXT_HOP all from SOURCE to any > > > I have thought about doing this, but am a little concerned about assigning > DUMMY_NEXT_HOP. As soon as I issue "route add DUMMY_NEXT_HOP -interface > GIF", that DUMMY_NEXT_HOP address is now unusable by anyone else. > Therefore, I guess it would have to be private, but then this would stop > anyone from actually using this private address in the local domain. Well, nobody should be using a private address in any domain that's connected to the Internet, so you may be safe there. If not, then you could do either (1) modify ipfw to allow specification of a local interface (as opposed to a gatway IP adress) in the fwd rule or (2) buy a large enough IP block so you can use your own addresses for DUMMY_NEXT_HOP > Plus, > I don't know how many DUMMY_NEXT_HOPs to allocate, as I would need one for > each tunnel I have set up, and the number of tunnels I set up is dependent > on the number of mobile's that come into the system (which is somewhat of an > unknown). This makes (2) look infeasible, but (1) may still be an option. Lars -- Lars Eggert USC Information Sciences Institute --------------ms050407020502030807060306 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIrjCC ArUwggIeoAMCAQICAwWBRzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAxMDgyNDE2NDAwMFoXDTAyMDgyNDE2NDAwMFowVDEP MA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2VydDEc MBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEA0AvLBsD78nxcUHeHkaMgl3b4qYPnfgbf8Lh+HQP8RgGMRG/Yb+vTpkGezlwt9pkJxiD1 1uZDy4CNNJUu3gKxKSb+zRV70O+lkwwftuHoLHoH4xwo3LcQ2LGDpd+I95tUN4dfJ3TmeEcU SF50dC/SuUI4w8AlhXQ8IxrhgdayTpECAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIB BAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1Ud EwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAheZhn0pQA8zI7U2K1ZIAl11j0a1DKxnp3GtT vOUrGRB3WvYxidvdZ1kizhEsWeXU81TkNDH0DaRqtOEeu6Q2OhB+jeKEqY7IDAJE4/fI0e+d 6PnG1hd+vEvYmsKHkmzBhPc94XUOKNWO+qVNP2NGyNI3QIDy5wX4fdcOo1S34r4wggK1MIIC HqADAgECAgMFgUcwDQYJKoZIhvcNAQECBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYD VQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg UlNBIDIwMDAuOC4zMDAeFw0wMTA4MjQxNjQwMDBaFw0wMjA4MjQxNjQwMDBaMFQxDzANBgNV BAQTBkVnZ2VydDENMAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkq hkiG9w0BCQEWDWxhcnNlQGlzaS5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANAL ywbA+/J8XFB3h5GjIJd2+KmD534G3/C4fh0D/EYBjERv2G/r06ZBns5cLfaZCcYg9dbmQ8uA jTSVLt4CsSkm/s0Ve9DvpZMMH7bh6Cx6B+McKNy3ENixg6XfiPebVDeHXyd05nhHFEhedHQv 0rlCOMPAJYV0PCMa4YHWsk6RAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy dU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBAgUAA4GBAIXmYZ9KUAPMyO1NitWSAJddY9GtQysZ6dxrU7zlKxkQ d1r2MYnb3WdZIs4RLFnl1PNU5DQx9A2karThHrukNjoQfo3ihKmOyAwCROP3yNHvnej5xtYX frxL2JrCh5JswYT3PeF1DijVjvqlTT9jRsjSN0CA8ucF+H3XDqNUt+K+MIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYICpjCCAqICAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDBYFHMAkGBSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAyMDYyNjIxMzEwMFowIwYJKoZIhvcNAQkEMRYEFI51zCSzueYM yvOXWwgFE6/wBHbLMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0B CRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG A1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRl IFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMF gUcwDQYJKoZIhvcNAQEBBQAEgYAlh8rFEOPtjnNT/qx5tUH4ojdS6HtFesXfkOaCWCN6ZS8p nL5HacTedVfE+3S1A0YPn90ygkPzxYFh1uYQZvqL84b8G3ly9F/8FZHUJoR37EnJ+0EK8a8u J5R17Gs2nfZBMD3/4ZGYUt3TzbXOr0nu8P2S4aN2LQveSows/TA59gAAAAAAAA== --------------ms050407020502030807060306-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 26 17:53:21 2002 Delivered-To: freebsd-net@freebsd.org Received: from sccrmhc03.attbi.com (sccrmhc03.attbi.com [204.127.202.63]) by hub.freebsd.org (Postfix) with ESMTP id 98F9E37D55F; Wed, 26 Jun 2002 17:49:51 -0700 (PDT) Received: from InterJet.elischer.org ([12.232.206.8]) by sccrmhc03.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020626210014.JGPI903.sccrmhc03.attbi.com@InterJet.elischer.org>; Wed, 26 Jun 2002 21:00:14 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id NAA65030; Wed, 26 Jun 2002 13:47:47 -0700 (PDT) Date: Wed, 26 Jun 2002 13:47:46 -0700 (PDT) From: Julian Elischer To: Matt Impett Cc: "'freebsd-net@freebsd.org'" , "'freebsd-questions@freebsd.org'" Subject: Re: source address based routing In-Reply-To: <8C92E23A3E87FB479988285F9E22BE46FDE776@ftmail.lab.flarion.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This should almost be an FAQ... use ipfw and the FIREWALL_FORWARD option (ipfw fwd) to over-ride next hop routing decisions.. On Wed, 26 Jun 2002, Matt Impett wrote: > Hello, > > I was wondering if it is possible to do pure source address based routing > under FreeBSD. What I really want to do is route packets from particular > source addresses to tunnels (gif devices) regardless of what the packet's > destination address is. > > thanks, > matt > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 26 18:39: 1 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id BC48A37C1BB for ; Wed, 26 Jun 2002 18:30:09 -0700 (PDT) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020626204008.QZUP8262.rwcrmhc52.attbi.com@InterJet.elischer.org>; Wed, 26 Jun 2002 20:40:08 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id NAA64932; Wed, 26 Jun 2002 13:22:00 -0700 (PDT) Date: Wed, 26 Jun 2002 13:21:58 -0700 (PDT) From: Julian Elischer To: Anthony Volodkin Cc: freebsd-net@freebsd.org Subject: Re: Forwarding UDP packets In-Reply-To: <3D1A1B64.402@brainlink.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Try use mpd it does proxy arp and handles some broadcast features I believe. On Wed, 26 Jun 2002, Anthony Volodkin wrote: > I use poptop+the pppd that is included with 4.6-RELEASE. On the XP > side, my friend just sets up a "Virtual Private Networking Connection" > using the native XP client. > > Here are my /etc/ppp/options, if you wanted protocol info: > lock > debug > auth > proxyarp > +chap > +chapms > +chapms-v2 > > and the relevant portion of ppp.conf: > pptp: > enable chap > enable proxy > set ifaddr 192.168.1.100 192.168.2.200-192.168.2.205 255.255.255.0 > > >what method of doing pptp are you using? > > > > > >On Wed, 26 Jun 2002, Anthony Volodkin wrote: > > > > > > > >>Hi, > >> > >>Recently I've been faced with an odd problem. I setup a pptp link to my > >>network from my friend's XP machine. While the link functions fine > >>(both ends can ping each other, etc), there is one problem with it. I > >>cannot get any broadcast packets through the link. I receive them on > >>the tun0 interface, but no matter what I try i can't get them out of the > >>fxp0 interface. I cannot get them to go the other way either. I know > >>this is against standards, as they suggest routers should not forward > >>broadcast packets, but I would still like to have this ability. > >> > >>Did anyone ever write a patch of some sort or maybe found a tool that > >>does this type of thing? > >>(many people suggested natd, and after playing with that i was able to > >>redirect some bcast packets from tun0 to 1 host on my lan. I was not > >>able to do that in the other direction, however.) > >> > >>I've found an old post on the hackers list by Jonathan Chen that > >>included a patch to enable this kind of functionality. I applied it to > >>my 4.6-RELEASE kernel and it didn't do anything but add a sysctl > >>variable. Any help would be greatly appreciated. > >> > >>Here is that post: > >> > >>--------------------------------------------------- > >> > >>On FreeBSD -CURRENT and -STABLE, packets to broadcast addresses are not > >>forwarded. For instance, if I have a FreeBSD router with interfaces > >>192.168.1.1 and 192.168.2.1, and I send packets from 192.168.1.2 to > >>192.168.2.255, the packets are dropped to the floor. IMO, this is wrong... > >>but I haven't consulted all the RFC's so I'm not sure if some standard out > >>there calls for it. In any case, the following patch creates a sysctl knob > >>to turn on or off this feature (since it can be considered a security risk > >>by some). I just want to ask around in case I turned out to be doing > >>something incredibly evil. Comments? > >> > >>-Jon > >> > >>Index: in.h > >>=================================================================== > >>RCS file: /export/ncvs/src/sys/netinet/in.h,v > >>retrieving revision 1.55 > >>diff -u -r1.55 in.h > >>--- in.h 2001/06/15 00:37:27 1.55 > >>+++ in.h 2001/08/09 15:12:19 > >>@@ -452,7 +452,8 @@ > >> #define IPCTL_FASTFORWARDING 14 /* use fast IP forwarding code */ > >> #define IPCTL_KEEPFAITH 15 /* FAITH IPv4->IPv6 translater ctl */ > >> #define IPCTL_GIF_TTL 16 /* default TTL for gif encap packet */ > >>-#define IPCTL_MAXID 17 > >>+#define IPCTL_FORWARD_BROADCAST 18 /* forward broadcast packets */ > >>+#define IPCTL_MAXID 18 > >> > >> #define IPCTL_NAMES { \ > >> { 0, 0 }, \ > >>Index: ip_input.c > >>=================================================================== > >>RCS file: /export/ncvs/src/sys/netinet/ip_input.c,v > >>retrieving revision 1.174 > >>diff -u -r1.174 ip_input.c > >>--- ip_input.c 2001/06/23 17:17:58 1.174 > >>+++ ip_input.c 2001/08/09 15:33:59 > >>@@ -103,6 +103,10 @@ > >> SYSCTL_INT(_net_inet_ip, IPCTL_FORWARDING, forwarding, CTLFLAG_RW, > >> &ipforwarding, 0, "Enable IP forwarding between interfaces"); > >> > >>+int ipforward_broadcast = 0; > >>+SYSCTL_INT(_net_inet_ip, IPCTL_FORWARD_BROADCAST, forward_broadcast, > >>CTLFLAG_RW, > >>+ &ipforward_broadcast, 0, "Enable broadcast packets when forwarding > >>IP packets"); > >>+ > >> static int ipsendredirects = 1; /* XXX */ > >> SYSCTL_INT(_net_inet_ip, IPCTL_SENDREDIRECTS, redirect, CTLFLAG_RW, > >> &ipsendredirects, 0, "Enable sending IP redirects"); > >>@@ -1684,7 +1688,8 @@ > >> } > >> > >> error = ip_output(m, (struct mbuf *)0, &ipforward_rt, > >>- IP_FORWARDING, 0); > >>+ IP_FORWARDING| > >>+ (ipforward_broadcast?IP_ALLOWBROADCAST:0), 0); > >> if (error) > >> ipstat.ips_cantforward++; > >> else { > >> > >> > >>-- > >>Anthony Volodkin > >> > >> > >>To Unsubscribe: send mail to majordomo@FreeBSD.org > >>with "unsubscribe freebsd-net" in the body of the message > >> > >> > >> > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 26 18:48:50 2002 Delivered-To: freebsd-net@freebsd.org Received: from sccrmhc01.attbi.com (sccrmhc01.attbi.com [204.127.202.61]) by hub.freebsd.org (Postfix) with ESMTP id 3AF4137E4C1; Wed, 26 Jun 2002 18:40:15 -0700 (PDT) Received: from InterJet.elischer.org ([12.232.206.8]) by sccrmhc01.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020627014014.KVP29588.sccrmhc01.attbi.com@InterJet.elischer.org>; Thu, 27 Jun 2002 01:40:14 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id SAA66124; Wed, 26 Jun 2002 18:40:00 -0700 (PDT) Date: Wed, 26 Jun 2002 18:39:59 -0700 (PDT) From: Julian Elischer To: Lars Eggert Cc: Matt Impett , "'freebsd-net@freebsd.org'" , "'freebsd-questions@freebsd.org'" Subject: Re: source address based routing In-Reply-To: <3D1A3294.6010205@isi.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, 26 Jun 2002, Lars Eggert wrote: > Matt Impett wrote: > > gladly.. I am trying to implement reverse tunneling for mobile-IP. The > > basic idea is that packets must be reverse tunneled to different IP > > addresses depending on the source address of the packet. The reason the > > tunnel does not have an IP address associated with it is that I don't want > > to forward traffic down the tunnel for any other reason besides source > > addresses. As soon as I assign the tunnel interface an address, traffic > > sent to that address will be tunneled. Surely 10.200.x.x is unlikely to be used.. it gives you 64000 possible tunnels. What I am having trouble with is that the tunnel to use depends on the SOURCE? That seems a little unusual.. Obviously I'm missing something in the words "reverse tunnelling". > > Thanks, that was really helpful to get an idea of what your scenario is! > > >> route add DUMMY_NEXT_HOP -interface GIF > >> ipfw add fwd DUMMY_NEXT_HOP all from SOURCE to any > > > > > > I have thought about doing this, but am a little concerned about assigning > > DUMMY_NEXT_HOP. As soon as I issue "route add DUMMY_NEXT_HOP -interface > > GIF", that DUMMY_NEXT_HOP address is now unusable by anyone else. > > Therefore, I guess it would have to be private, but then this would stop > > anyone from actually using this private address in the local domain. ability to forward to an interface would be kind of cool.. > > Well, nobody should be using a private address in any domain that's > connected to the Internet, so you may be safe there. > > If not, then you could do either > > (1) modify ipfw to allow specification of a local interface (as > opposed to a gateway IP adress) in the fwd rule this would be cool but I'm not sure how feasible.. I have not looked at Luigi's new ipfw implementation yet. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 26 20:23:44 2002 Delivered-To: freebsd-net@freebsd.org Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by hub.freebsd.org (Postfix) with ESMTP id 6853337B414 for ; Wed, 26 Jun 2002 20:19:36 -0700 (PDT) Received: from house (cage.simianscience.com [64.7.134.1]) by smtp1.sentex.ca (8.12.3/8.12.3) with SMTP id g5R3DmPI074105 for ; Wed, 26 Jun 2002 23:13:49 -0400 (EDT) (envelope-from mike@sentex.net) From: Mike Tancsa To: freebsd-net@freebsd.org Subject: Re: SOLVED! Native PPPoE broken (4.6-STABLE), RP-PPPoE working?! Date: Wed, 26 Jun 2002 23:14:57 -0400 Message-ID: <4e0lhusn1nhnr8fdc591spcstfs8s8a532@4ax.com> References: <2trfhu0tbekq67seicn4amdovp7564ji62@4ax.com> <3D183606.BBD1DE54@tix.ch> <5.1.0.14.0.20020625112547.057eb870@marble.sentex.ca> In-Reply-To: <5.1.0.14.0.20020625112547.057eb870@marble.sentex.ca> X-Mailer: Forte Agent 1.8/32.548 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Just to close off this issue an feed it to the archives in case anyone = else runs into this issue, the telco found the article below in the vendor's knowledge database. =20 Again to summarize, if you use FreeBSD, PPPoE and your ISP or your ISP's telco uses an ERX as the PPPoE concentrator, make sure you disable and prevent VJ header compression as it will not work. Bell Canada has been slowly deploying these boxes so if you use Sympatico, or your ISP is in Quebec or Ontario, you will start to run into this issue as the telco = slow gets rid of their Redback SMSes and replaces them with Unisphere's ERX boxes. =20 The solution I found was to make sure that its also disabled and not offered in RADIUS either, so you might have to talk to your ISP if they have it configured, as we did. ---Mike *************************** Knowledge Database - Search Results Knowledge Asset ID#: 1773.00000=20 Subject: The ERX does not support IP header compression as described in = RFC 2507 and RFC 2508.=20 -------------------------------------------------------------------------= --- ---- =20 Type: SW Release: SW Version: =20 Problem Description: The ERX does not support and does not yet have plans to support IP header compression. For a full=20 description of IP header compression refer to RFC 2507 and RFC 2508. It basically says that multiple=20 packets to and from the same destinations can get their headers = compressed to save about 8 bytes per=20 packet.=20 This feature has been requested in case 10349=20 Workaround: =20 Solution: =20 **************************** On Tue, 25 Jun 2002 11:40:48 -0400, in sentex.lists.freebsd.net you = wrote: > >In short, VJ-Header Compression! Why, I dont know. The exact same = config=20 >works agains the SMSes by Redback. But not the Unisphere ERX > >Here is what I did to get it to all work. > >a) On my radius server, I had to get rid of > Framed-Compression =3D Van-Jacobsen-TCP-IP >b) On the FreeBSD box, I had to put > disable vjcomp > > >_Before_, on the Cisco terminating L2TP server we see > >bell-border#show int vi426 >Virtual-Access426 is up, line protocol is up > Hardware is Virtual Access interface > Interface is unnumbered. Using address of Loopback0 (64.7.134.129) > MTU 1492 bytes, BW 18868 Kbit, DLY 100000 usec, > reliability 255/255, txload 1/255, rxload 1/255 > Encapsulation PPP, loopback not set > Keepalive set (10 sec) > DTR is pulsed for 5 seconds on reset > LCP Open > Open: IPCP > Last input 01:11:57, output never, output hang never > Last clearing of "show interface" counters 03:33:26 > Queueing strategy: fifo > Output queue 0/40, 0 drops; input queue 0/75, 0 drops > 5 minute input rate 0 bits/sec, 0 packets/sec > 5 minute output rate 0 bits/sec, 0 packets/sec > 9265 packets input, 4481181 bytes, 0 no buffer > Received 0 broadcasts, 0 runts, 0 giants, 0 throttles > 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort > 8720 packets output, 1141908 bytes, 0 underruns > 0 output errors, 0 collisions, 0 interface resets > 0 output buffer failures, 0 output buffers swapped out > 0 carrier transitions >bell-border#show int vi426 confi >Virtual-Access426 is an L2TP link interface > >Building configuration... > >interface Virtual-Access426 configuration... >mtu 1492 >ip unnumbered Loopback0 >ip tcp header-compression > >And _after_ > >bell-border#show int vi63 >Virtual-Access63 is up, line protocol is up > Hardware is Virtual Access interface > Interface is unnumbered. Using address of Loopback0 (64.7.134.129) > MTU 1492 bytes, BW 18868 Kbit, DLY 100000 usec, > reliability 255/255, txload 1/255, rxload 1/255 > Encapsulation PPP, loopback not set > Keepalive set (10 sec) > DTR is pulsed for 5 seconds on reset > LCP Open > Open: IPCP > Last input 00:00:09, output never, output hang never > Last clearing of "show interface" counters 00:14:45 > Queueing strategy: fifo > Output queue 0/40, 0 drops; input queue 0/75, 0 drops > 5 minute input rate 0 bits/sec, 0 packets/sec > 5 minute output rate 0 bits/sec, 0 packets/sec > 10 packets input, 217 bytes, 0 no buffer > Received 0 broadcasts, 0 runts, 0 giants, 0 throttles > 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort > 8 packets output, 139 bytes, 0 underruns > 0 output errors, 0 collisions, 0 interface resets > 0 output buffer failures, 0 output buffers swapped out > 0 carrier transitions >bell-border#show int vi63 config >Virtual-Access63 is an L2TP link interface > >Building configuration... > >interface Virtual-Access63 configuration... >mtu 1492 >ip unnumbered Loopback0 > > >iscar# ifconfig tun0 >tun0: flags=3D8051 mtu 1492 > inet6 fe80::2d0:b7ff:fea6:4285%tun0 prefixlen 64 scopeid 0x8 > inet 64.7.134.131 --> 64.7.134.129 netmask 0xffffff00 > Opened by PID 55 >iscar# > >fetch ftp://ftp.isc.org/isc/bind9/9.2.1/bind-9.2.1.tar.gz >Receiving bind-9.2.1.tar.gz (5021044 bytes): 100% >5021044 bytes transferred in 39.9 seconds (122.76 kBps) >iscar# > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-net" in the body of the message Mike Tancsa (mdtancsa@sentex.net) =09 Sentex Communications Corp, =09 Waterloo, Ontario, Canada "Given enough time, 100 monkeys on 100 routers=20 could setup a national IP network." (KDW2) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 27 3:13:46 2002 Delivered-To: freebsd-net@freebsd.org Received: from utility.clubscholarship.com (utility.clubscholarship.com [198.78.70.175]) by hub.freebsd.org (Postfix) with ESMTP id 3D74237B405 for ; Thu, 27 Jun 2002 03:13:41 -0700 (PDT) Received: from localhost (root@localhost) by utility.clubscholarship.com (8.11.6/8.11.6) with ESMTP id g5RAA4T12932 for ; Thu, 27 Jun 2002 03:10:04 -0700 (PDT) (envelope-from root@utility.clubscholarship.com) Date: Thu, 27 Jun 2002 03:10:03 -0700 (PDT) From: Patrick Thomas To: Subject: tune down recvspace for this ? Message-ID: <20020627030821.M68572-100000@utility.clubscholarship.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org When I wake up in the morning I see this: Wed Jun 26 09:21:52 PDT 2002 99/10208/34816 mbufs in use (current/peak/max): 98 mbufs allocated to data 1 mbufs allocated to packet headers 94/8704/8704 mbuf clusters in use (current/peak/max) 19960 Kbytes allocated to network (76% of mb_map in use) 43143 requests for memory denied 1 requests for memory delayed 0 calls to protocol drain routines It looks benign at night, but as the morning rush kicks in, it ramps up to this. Would changing net.inet.tcp.recvspace down to 32768 (default is 65536) be a wise thing to do ? Or are there other better suggestions ? thanks, PT To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 27 3:35:18 2002 Delivered-To: freebsd-net@freebsd.org Received: from mailb.telia.se (mail.telia.se [131.115.15.109]) by hub.freebsd.org (Postfix) with ESMTP id 3286837B401 for ; Thu, 27 Jun 2002 03:35:06 -0700 (PDT) Received: from mailb.telia.se (localhost [127.0.0.1]) by mailb.telia.se (8.11.6/8.11.6) with ESMTP id g5RAZ3m04265 for ; Thu, 27 Jun 2002 12:35:03 +0200 (METDST) Received: from gripen.training.telia.se (gripen.training.telia.se [131.115.118.3]) by mailb.telia.se (8.11.6/8.11.6) with ESMTP id g5RAZ2w04247 for ; Thu, 27 Jun 2002 12:35:02 +0200 (METDST) Received: from nisse.netplex.se (dator52.training.telia.se [131.115.118.52]) by gripen.training.telia.se (8.11.1/8.11.1) with ESMTP id g5RAZ0Z67027 for ; Thu, 27 Jun 2002 12:35:01 +0200 (CEST) (envelope-from anders.hagman@netplex.se) Message-Id: <5.1.0.14.0.20020627122424.009f80d0@m1.480.telia.com> X-Sender: u48002568@m1.480.telia.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 27 Jun 2002 12:35:54 +0200 To: net@freebsd.org From: Anders Hagman Subject: Multi_af and ipv6 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hej >On Tue, May 14, 2002 at 04:50:24PM -0700, Lars Eggert wrote: > > Hi, > > > > could someone with more knowledge of the tun device please take a look > > at the code around line 387 in net/if_tun.c? It looks like tunoutput() > > drops all packets here that aren't of the AF_INET family - most notably, > > it drops IPv6 packets. > > > > We hacked around this with the simple fix below, but I'm not sure if > > there are any drawbacks... > > >[clip] > >Is there a specific reason why you are not using the "multi-af" mode? >IPv6 works just nicely with /usr/sbin/ppp (PPPoE), which uses if_tun in >"multi-af" mode. As a plain user using ppp and tun, how do I turn on multi_af mode? I want to use ipv6 on tty/ppp-lines on FreeBSD acting as a router for an ipv6 course. NetBSD has support for ipv6 on pppd. Is it coming for FreeBSD? Regards MVH /Anders Anders Hagman Netplex AB, 070 370 03 95 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 27 5: 9:44 2002 Delivered-To: freebsd-net@freebsd.org Received: from patrocles.silby.com (d130.as7.nwbl0.wi.voyager.net [169.207.130.68]) by hub.freebsd.org (Postfix) with ESMTP id 247E537B4D6 for ; Thu, 27 Jun 2002 05:09:29 -0700 (PDT) Received: from patrocles.silby.com (localhost [127.0.0.1]) by patrocles.silby.com (8.12.4/8.12.4) with ESMTP id g5RCBqcv067854; Thu, 27 Jun 2002 07:11:52 -0500 (CDT) (envelope-from silby@silby.com) Received: from localhost (silby@localhost) by patrocles.silby.com (8.12.4/8.12.4/Submit) with ESMTP id g5RCBmen067851; Thu, 27 Jun 2002 07:11:50 -0500 (CDT) X-Authentication-Warning: patrocles.silby.com: silby owned process doing -bs Date: Thu, 27 Jun 2002 07:11:48 -0500 (CDT) From: Mike Silbersack To: Patrick Thomas Cc: freebsd-net@freebsd.org Subject: Re: tune down recvspace for this ? In-Reply-To: <20020627030821.M68572-100000@utility.clubscholarship.com> Message-ID: <20020627071056.N67834-100000@patrocles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, 27 Jun 2002, Patrick Thomas wrote: > 99/10208/34816 mbufs in use (current/peak/max): > > Would changing net.inet.tcp.recvspace down to 32768 (default is 65536) be > a wise thing to do ? > > Or are there other better suggestions ? > > thanks, > > PT Actually, you usually use most of your mbuf (clusters) for sending, not receiving. Hence, sendspace is what you may wish to kick down in order to reduce usage. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 27 8:24: 7 2002 Delivered-To: freebsd-net@freebsd.org Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by hub.freebsd.org (Postfix) with ESMTP id 2C38B37B401; Thu, 27 Jun 2002 08:23:56 -0700 (PDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Thu, 27 Jun 2002 11:23:54 -0400 Message-ID: <8C92E23A3E87FB479988285F9E22BE46FDE77D@ftmail.lab.flarion.com> From: Matt Impett To: 'Julian Elischer' , Lars Eggert Cc: Matt Impett , "'freebsd-net@freebsd.org'" , "'freebsd-questions@freebsd.org'" Subject: RE: source address based routing Date: Thu, 27 Jun 2002 11:23:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org inline.. > -----Original Message----- > From: Julian Elischer [mailto:julian@elischer.org] > Sent: Wednesday, June 26, 2002 9:40 PM > To: Lars Eggert > Cc: Matt Impett; 'freebsd-net@freebsd.org'; > 'freebsd-questions@freebsd.org' > Subject: Re: source address based routing > > > On Wed, 26 Jun 2002, Lars Eggert wrote: > > > Matt Impett wrote: > > > gladly.. I am trying to implement reverse tunneling for mobile-IP. The > > > basic idea is that packets must be reverse tunneled to different IP > > > addresses depending on the source address of the packet. The reason the > > > tunnel does not have an IP address associated with it is that I don't want > > > to forward traffic down the tunnel for any other reason besides source > > > addresses. As soon as I assign the tunnel interface an address, traffic > > > sent to that address will be tunneled. > > Surely 10.200.x.x is unlikely to be used.. it gives you 64000 possible > tunnels. What I am having trouble with is that the tunnel to use depends > on the SOURCE? That seems a little unusual.. Obviously I'm missing > something in the words "reverse tunnelling". The company I work for (Flarion Technologies) is building an IP access box for mobile wireless networks that will plug into existing network infrastructure. I would be a little scared reserving a large piece of the private address space as I cannot be assured that the operator that owns the (private) network we will be plugging into is not using the same space. Doing so would require agreements with them about the use or reservation of the chunks of addressing space. It could be done, but I would rather avoid it. As for tunneling based on SOURCE, here is a brief explanation. We are running mobileIP to handle device mobility in our network. Basically, mobile nodes can have IP addresses which are not topologically correct at the access router they are connected to, but rather ARE topologically correct at some node (the Home Agent) back in the network. Downlink traffic (to the mobile node) is tunnelened from the Home Agent to the mobile's current point of attachment. Similarly, uplink traffic (from the mobile node), needs to be reverse tunneled back to the Home Agent, as the IP address the mobile will be sourcing traffic with is not topologically correct and will be dropped by any routers doing ingress filtering. So, our access box has to look for packets from particular source addresses and tunnel them back to that address's Home Agent. matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 27 8:25:12 2002 Delivered-To: freebsd-net@freebsd.org Received: from castle.jp.FreeBSD.org (castle.jp.FreeBSD.org [210.226.20.15]) by hub.freebsd.org (Postfix) with ESMTP id 785BA37B40A for ; Thu, 27 Jun 2002 08:25:04 -0700 (PDT) Received: from localhost (localhost [::1]) by castle.jp.FreeBSD.org (8.11.6+3.4W/8.11.3) with ESMTP/inet6 id g5RFOtn81584; Fri, 28 Jun 2002 00:24:55 +0900 (JST) (envelope-from matusita@jp.FreeBSD.org) Cc: net@FreeBSD.org In-Reply-To: <3D1A20B7.6030009@isi.edu> References: <3D1A20B7.6030009@isi.edu> X-User-Agent: Mew/1.94.2 XEmacs/21.5 (bamboo) X-FaceAnim: (-O_O-)(O_O- )(_O- )(O- )(- -)( -O)( -O_)( -O_O)(-O_O-) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Dispatcher: imput version 20000228(IM140) Lines: 9 From: Makoto Matsushita To: larse@ISI.EDU Subject: Re: /usr/lib/libtelnet.a missing on 4.6? Date: Fri, 28 Jun 2002 00:24:52 +0900 Message-Id: <20020628002452X.matusita@jp.FreeBSD.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org larse> Is this a bug of the ISO image, or a deliberate change? IIRC, not having libtelnet.a is intentional. 4-stable as of Apr/13/2002 or later doesn't have it. See src/lib/libtelnet/Makefile for details. -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 27 8:34:38 2002 Delivered-To: freebsd-net@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id 12D2D37B406 for ; Thu, 27 Jun 2002 08:34:33 -0700 (PDT) Received: from isi.edu (qmw2hn8fs5u6o35o@hbo.isi.edu [128.9.160.75]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g5RFYSr21879; Thu, 27 Jun 2002 08:34:29 -0700 (PDT) Message-ID: <3D1B3084.5000704@isi.edu> Date: Thu, 27 Jun 2002 08:34:28 -0700 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0.0) Gecko/20020618 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: Makoto Matsushita Cc: net@FreeBSD.org, itojun@iijlab.net Subject: Re: /usr/lib/libtelnet.a missing on 4.6? References: <3D1A20B7.6030009@isi.edu> <20020628002452X.matusita@jp.FreeBSD.org> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040906070201040302070009" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a cryptographically signed message in MIME format. --------------ms040906070201040302070009 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Makoto Matsushita wrote: > larse> Is this a bug of the ISO image, or a deliberate change? > > IIRC, not having libtelnet.a is intentional. 4-stable as of > Apr/13/2002 or later doesn't have it. See src/lib/libtelnet/Makefile > for details. Thanks, so it's a KAME issue. KAME should either update their tree to reflect the changes in STABLE, or can maybe completely remove it (as Itojun indicated on snap-users.) itojun@iijlab.net wrote: >>I'm seeing a weird problem when building the latest SNAP on FreeBSD-4.6: > > i don't think it necessary for us to ship usr.bin/telnet any longer. Thanks, Lars -- Lars Eggert USC Information Sciences Institute --------------ms040906070201040302070009 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIrjCC ArUwggIeoAMCAQICAwWBRzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAxMDgyNDE2NDAwMFoXDTAyMDgyNDE2NDAwMFowVDEP MA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2VydDEc MBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEA0AvLBsD78nxcUHeHkaMgl3b4qYPnfgbf8Lh+HQP8RgGMRG/Yb+vTpkGezlwt9pkJxiD1 1uZDy4CNNJUu3gKxKSb+zRV70O+lkwwftuHoLHoH4xwo3LcQ2LGDpd+I95tUN4dfJ3TmeEcU SF50dC/SuUI4w8AlhXQ8IxrhgdayTpECAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIB BAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1Ud EwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAheZhn0pQA8zI7U2K1ZIAl11j0a1DKxnp3GtT vOUrGRB3WvYxidvdZ1kizhEsWeXU81TkNDH0DaRqtOEeu6Q2OhB+jeKEqY7IDAJE4/fI0e+d 6PnG1hd+vEvYmsKHkmzBhPc94XUOKNWO+qVNP2NGyNI3QIDy5wX4fdcOo1S34r4wggK1MIIC HqADAgECAgMFgUcwDQYJKoZIhvcNAQECBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYD VQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg UlNBIDIwMDAuOC4zMDAeFw0wMTA4MjQxNjQwMDBaFw0wMjA4MjQxNjQwMDBaMFQxDzANBgNV BAQTBkVnZ2VydDENMAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkq hkiG9w0BCQEWDWxhcnNlQGlzaS5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANAL ywbA+/J8XFB3h5GjIJd2+KmD534G3/C4fh0D/EYBjERv2G/r06ZBns5cLfaZCcYg9dbmQ8uA jTSVLt4CsSkm/s0Ve9DvpZMMH7bh6Cx6B+McKNy3ENixg6XfiPebVDeHXyd05nhHFEhedHQv 0rlCOMPAJYV0PCMa4YHWsk6RAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy dU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBAgUAA4GBAIXmYZ9KUAPMyO1NitWSAJddY9GtQysZ6dxrU7zlKxkQ d1r2MYnb3WdZIs4RLFnl1PNU5DQx9A2karThHrukNjoQfo3ihKmOyAwCROP3yNHvnej5xtYX frxL2JrCh5JswYT3PeF1DijVjvqlTT9jRsjSN0CA8ucF+H3XDqNUt+K+MIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYICpjCCAqICAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDBYFHMAkGBSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAyMDYyNzE1MzQyOFowIwYJKoZIhvcNAQkEMRYEFB/RWggvikdr b0QtV2hc7m8GSJYKMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0B CRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG A1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRl IFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMF gUcwDQYJKoZIhvcNAQEBBQAEgYBW+lNGSWCGDQSqBPUd1hInNh60EOd4rbJ74KdPvkpwQWon vSh3jEMJ7LDyJ8Ol/jSDaOD/BXE2ZLixPbwSu2yhszodk6rWCJcnSdB4yUI8E2R7ElkqhTqh Dx7DfQpngEkplYBOlWwh5jdmKtBCWGqKsqYI+N5hSJPp9hUbR/ZLuAAAAAAAAA== --------------ms040906070201040302070009-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 27 8:57:34 2002 Delivered-To: freebsd-net@freebsd.org Received: from stewart.chicago.il.us (user166.64.47.24.dsli.com [64.47.24.166]) by hub.freebsd.org (Postfix) with ESMTP id 09A1337B405; Thu, 27 Jun 2002 08:56:56 -0700 (PDT) Received: from stewart.chicago.il.us (stewlap [10.1.1.5]) by stewart.chicago.il.us (8.11.1/8.11.1) with ESMTP id g5RFuWH06017; Thu, 27 Jun 2002 10:56:32 -0500 (CDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3D1B35B0.1945DAAC@stewart.chicago.il.us> Date: Thu, 27 Jun 2002 10:56:32 -0500 From: Randall Stewart X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2 i386) X-Accept-Language: en MIME-Version: 1.0 To: Matt Impett Cc: "'Julian Elischer'" , Lars Eggert , "'freebsd-net@freebsd.org'" , "'freebsd-questions@freebsd.org'" Subject: Re: source address based routing References: <8C92E23A3E87FB479988285F9E22BE46FDE77D@ftmail.lab.flarion.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Matt Impett wrote: > > inline.. > > > -----Original Message----- > > From: Julian Elischer [mailto:julian@elischer.org] > > Sent: Wednesday, June 26, 2002 9:40 PM > > To: Lars Eggert > > Cc: Matt Impett; 'freebsd-net@freebsd.org'; > > 'freebsd-questions@freebsd.org' > > Subject: Re: source address based routing > > > > > > On Wed, 26 Jun 2002, Lars Eggert wrote: > > > > > Matt Impett wrote: > > > > gladly.. I am trying to implement reverse tunneling for mobile-IP. > The > > > > basic idea is that packets must be reverse tunneled to different IP > > > > addresses depending on the source address of the packet. The reason > the > > > > tunnel does not have an IP address associated with it is that I don't > want > > > > to forward traffic down the tunnel for any other reason besides source > > > > addresses. As soon as I assign the tunnel interface an address, > traffic > > > > sent to that address will be tunneled. > > > > Surely 10.200.x.x is unlikely to be used.. it gives you 64000 possible > > tunnels. What I am having trouble with is that the tunnel to use depends > > on the SOURCE? That seems a little unusual.. Obviously I'm missing > > something in the words "reverse tunnelling". > > The company I work for (Flarion Technologies) is building an IP access box > for mobile wireless networks that will plug into existing network > infrastructure. I would be a little scared reserving a large piece of the > private address space as I cannot be assured that the operator that owns the > (private) network we will be plugging into is not using the same space. > Doing so would require agreements with them about the use or reservation of > the chunks of addressing space. It could be done, but I would rather avoid > it. > > As for tunneling based on SOURCE, here is a brief explanation. We are > running mobileIP to handle device mobility in our network. Basically, > mobile nodes can have IP addresses which are not topologically correct at > the access router they are connected to, but rather ARE topologically > correct at some node (the Home Agent) back in the network. Downlink traffic > (to the mobile node) is tunnelened from the Home Agent to the mobile's > current point of attachment. Similarly, uplink traffic (from the mobile > node), needs to be reverse tunneled back to the Home Agent, as the IP > address the mobile will be sourcing traffic with is not topologically > correct and will be dropped by any routers doing ingress filtering. So, our > access box has to look for packets from particular source addresses and > tunnel them back to that address's Home Agent. > > matt Matt: Curiosity drives me to ask the question... Where is the Foreign agent (FA)? In most mobile IP scenarios I have been familar with (granted a limited set.. and I have a tiny idea of how it should work that may be dated) the mobile has a FA. The FA is either co-located inside the mobile.. which in that case it would have the tunnel back to the home agent... OR the FA is a box somewhere in your network that picks up the packets from the wire and then encapsulates them and stuffs them back up the tunnel to the home agent... I think this is your "access box" if I read things correctly. In such a case the "access box" SHOULD have a valid address on the network and should have its tunnel going from it to the home agent. All the FA needs to do is grab the packets sourced from these mobiles. I would think the firewall should be able to redirect these to your code much like the nat something like ... add divert natd all from any to any via ... This will get your user space code all of the packets going by on this box. From there I would think you could write code that would look at the sources and put them into the right tunnels... Not sure if you could use the GIF tunnel itself... or just write the tunneling software yourself... probably there is a creative way to do this with one of th GIF tunnels... R -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 27 9: 7:27 2002 Delivered-To: freebsd-net@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id AFCA937B405 for ; Thu, 27 Jun 2002 09:07:22 -0700 (PDT) Received: by elvis.mu.org (Postfix, from userid 1192) id 8201DAE22C; Thu, 27 Jun 2002 09:07:22 -0700 (PDT) Date: Thu, 27 Jun 2002 09:07:22 -0700 From: Alfred Perlstein To: Mike Silbersack Cc: Patrick Thomas , freebsd-net@freebsd.org Subject: Re: tune down recvspace for this ? Message-ID: <20020627160722.GK18877@elvis.mu.org> References: <20020627030821.M68572-100000@utility.clubscholarship.com> <20020627071056.N67834-100000@patrocles.silby.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020627071056.N67834-100000@patrocles.silby.com> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org * Mike Silbersack [020627 05:10] wrote: > > On Thu, 27 Jun 2002, Patrick Thomas wrote: > > > 99/10208/34816 mbufs in use (current/peak/max): > > > > Would changing net.inet.tcp.recvspace down to 32768 (default is 65536) be > > a wise thing to do ? > > > > Or are there other better suggestions ? > > > > thanks, > > > > PT > > Actually, you usually use most of your mbuf (clusters) for sending, not > receiving. Hence, sendspace is what you may wish to kick down in order to > reduce usage. True, but it looks like he could raise nmbclusters in his config intead of throttling. -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 27 9:12: 9 2002 Delivered-To: freebsd-net@freebsd.org Received: from utility.clubscholarship.com (utility.clubscholarship.com [198.78.70.175]) by hub.freebsd.org (Postfix) with ESMTP id 14D4737B400 for ; Thu, 27 Jun 2002 09:12:01 -0700 (PDT) Received: from localhost (root@localhost) by utility.clubscholarship.com (8.11.6/8.11.6) with ESMTP id g5RG8Bu27085; Thu, 27 Jun 2002 09:08:11 -0700 (PDT) (envelope-from root@utility.clubscholarship.com) Date: Thu, 27 Jun 2002 09:08:11 -0700 (PDT) From: Patrick Thomas To: Alfred Perlstein Cc: Mike Silbersack , Subject: Re: tune down recvspace for this ? In-Reply-To: <20020627160722.GK18877@elvis.mu.org> Message-ID: <20020627090636.R68572-100000@utility.clubscholarship.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org two followups: 1) is the tcp.recvspace an immediate tunable, or to get best results should I set it in rc.local ? 2) when you say raise nmbclusters "in his config", may I assume you men my kernel config - mine is at the default - do you have a suggestion for the new setting ? thanks, PT On Thu, 27 Jun 2002, Alfred Perlstein wrote: > * Mike Silbersack [020627 05:10] wrote: > > > > On Thu, 27 Jun 2002, Patrick Thomas wrote: > > > > > 99/10208/34816 mbufs in use (current/peak/max): > > > > > > Would changing net.inet.tcp.recvspace down to 32768 (default is 65536) be > > > a wise thing to do ? > > > > > > Or are there other better suggestions ? > > > > > > thanks, > > > > > > PT > > > > Actually, you usually use most of your mbuf (clusters) for sending, not > > receiving. Hence, sendspace is what you may wish to kick down in order to > > reduce usage. > > True, but it looks like he could raise nmbclusters in his config intead > of throttling. > > -- > -Alfred Perlstein [alfred@freebsd.org] > 'Instead of asking why a piece of software is using "1970s technology," > start asking why software is ignoring 30 years of accumulated wisdom.' > Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 27 9:13:53 2002 Delivered-To: freebsd-net@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id 8233937B401 for ; Thu, 27 Jun 2002 09:13:50 -0700 (PDT) Received: by elvis.mu.org (Postfix, from userid 1192) id 643DEAE03F; Thu, 27 Jun 2002 09:13:50 -0700 (PDT) Date: Thu, 27 Jun 2002 09:13:50 -0700 From: Alfred Perlstein To: Patrick Thomas Cc: Mike Silbersack , freebsd-net@freebsd.org Subject: Re: tune down recvspace for this ? Message-ID: <20020627161350.GL18877@elvis.mu.org> References: <20020627160722.GK18877@elvis.mu.org> <20020627090636.R68572-100000@utility.clubscholarship.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020627090636.R68572-100000@utility.clubscholarship.com> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org * Patrick Thomas [020627 09:11] wrote: > > two followups: > > 1) is the tcp.recvspace an immediate tunable, or to get best results > should I set it in rc.local ? Why not look and find out? :) > 2) when you say raise nmbclusters "in his config", may I assume you men my > kernel config - mine is at the default - do you have a suggestion for the > new setting ? I usually wind up going 4x the default. Btw, you can also raise it via the bootloader (without requiring a recompile, just reboot) see the loader manpage. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 27 9:17:54 2002 Delivered-To: freebsd-net@freebsd.org Received: from garbo.lodgenet.com (garbo.lodgenet.com [204.124.122.252]) by hub.freebsd.org (Postfix) with ESMTP id 2869A37B400 for ; Thu, 27 Jun 2002 09:17:50 -0700 (PDT) Received: from hardy.lodgenet.com (hardy.lodgenet.com [10.0.104.235]) by garbo.lodgenet.com (8.11.4/8.11.4) with ESMTP id g5RGHnc13163 for ; Thu, 27 Jun 2002 11:17:49 -0500 (CDT) Received: from chaplin.lodgenet.com (not verified[10.0.104.215]) by hardy.lodgenet.com with MailMarshal (4,2,5,0) id ; Thu, 27 Jun 2002 11:17:48 -0500 Received: by chaplin.lodgenet.com with Internet Mail Service (5.5.2653.19) id ; Thu, 27 Jun 2002 11:13:15 -0500 Message-ID: <3EA88113DE92D211807300805FA7994209149EE8@chaplin.lodgenet.com> From: "McKenna, Lee" To: "'freebsd-net@freebsd.org'" Subject: bge problem under 4.6-stable Date: Thu, 27 Jun 2002 11:13:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I have two machines with new 3Com 3C996B-T adapters using the bge0 driver and I am having a problem with nfs. I can mount the server from the client, and I can cd into the mounted directory, but as soon as I do an 'ls' command, the client appears to hang. Strange loooking packets occasionally show up in tcpdump with what appears to be huge, invalid port numbers and the packets appear to be fragments?. I can ftp to/from the server just fine. I tried changing ETHER_ALIGN to 0, but same results. Tried media 100baseTX to force both cards to 100Mbps, same results. I removed the gigabit switch and used a crossover cable between the 2 machines, same results. I removed the bge0 cards and put in good ol' reliable fxp0 cards using same crossover cable and everything works fine. Is the bge driver a complete piece of crap, or am I holding the mouse wrong? :) Any recommendations for a more stable GigE card over copper? --Lee Lee McKenna Sr. Systems Engineer LodgeNet Entertainment Coporation 3900 West Innovation Street Sioux Falls, SD 57107 605-988-1320 lee.mckenna@lodgenet.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 27 9:46:29 2002 Delivered-To: freebsd-net@freebsd.org Received: from brainlink.com (mail.brainlink.com [66.228.0.129]) by hub.freebsd.org (Postfix) with ESMTP id 3771537B420 for ; Thu, 27 Jun 2002 09:44:31 -0700 (PDT) Received: from [24.189.7.159] (account anthonyv HELO brainlink.com) by brainlink.com (CommuniGate Pro SMTP 3.5.3) with ESMTP id 14294146 for freebsd-net@freebsd.org; Thu, 27 Jun 2002 12:34:05 -0400 Message-ID: <3D1B40D8.4080809@brainlink.com> Date: Thu, 27 Jun 2002 12:44:08 -0400 From: Anthony Volodkin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1a+) Gecko/20020626 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: Forwarding UDP packets References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org PopTop also uses proxy arp supposedly (i got that option enabled). I even read that that feature is supposed to allow broadcasts to function properly. It doesn't however. A friend suggested i try to bridge two interfaces (tun0 and fxp0). I first tried using briding implemented by 'options BRIDGE'. That failed to set the tun0 into promiscious mode and hence did not produce the desired effect. Then I tried using the /usr/share/examples/netgraph/ether.bridge script to bridge the two interfaces. That failed as well. Netgraph complained that 'tun0' does not exist, even though it was up and running. Any more clues on forwarding packets with destination 255.255.255.255 across interfaces are welcome. -Anthony Volodkin >Try use mpd >it does proxy arp and handles some broadcast features I believe. > > > >On Wed, 26 Jun 2002, Anthony Volodkin wrote: > > > >>I use poptop+the pppd that is included with 4.6-RELEASE. On the XP >>side, my friend just sets up a "Virtual Private Networking Connection" >>using the native XP client. >> >>Here are my /etc/ppp/options, if you wanted protocol info: >>lock >>debug >>auth >>proxyarp >>+chap >>+chapms >>+chapms-v2 >> >>and the relevant portion of ppp.conf: >>pptp: >> enable chap >> enable proxy >> set ifaddr 192.168.1.100 192.168.2.200-192.168.2.205 255.255.255.0 >> >> >> >>>what method of doing pptp are you using? >>> >>> >>>On Wed, 26 Jun 2002, Anthony Volodkin wrote: >>> >>> >>> >>> >>> >>>>Hi, >>>> >>>>Recently I've been faced with an odd problem. I setup a pptp link to my >>>>network from my friend's XP machine. While the link functions fine >>>>(both ends can ping each other, etc), there is one problem with it. I >>>>cannot get any broadcast packets through the link. I receive them on >>>>the tun0 interface, but no matter what I try i can't get them out of the >>>>fxp0 interface. I cannot get them to go the other way either. I know >>>>this is against standards, as they suggest routers should not forward >>>>broadcast packets, but I would still like to have this ability. >>>> >>>>Did anyone ever write a patch of some sort or maybe found a tool that >>>>does this type of thing? >>>>(many people suggested natd, and after playing with that i was able to >>>>redirect some bcast packets from tun0 to 1 host on my lan. I was not >>>>able to do that in the other direction, however.) >>>> >>>>I've found an old post on the hackers list by Jonathan Chen that >>>>included a patch to enable this kind of functionality. I applied it to >>>>my 4.6-RELEASE kernel and it didn't do anything but add a sysctl >>>>variable. Any help would be greatly appreciated. >>>> >>>>Here is that post: >>>> >>>>--------------------------------------------------- >>>> >>>>On FreeBSD -CURRENT and -STABLE, packets to broadcast addresses are not >>>>forwarded. For instance, if I have a FreeBSD router with interfaces >>>>192.168.1.1 and 192.168.2.1, and I send packets from 192.168.1.2 to >>>>192.168.2.255, the packets are dropped to the floor. IMO, this is wrong... >>>>but I haven't consulted all the RFC's so I'm not sure if some standard out >>>>there calls for it. In any case, the following patch creates a sysctl knob >>>>to turn on or off this feature (since it can be considered a security risk >>>>by some). I just want to ask around in case I turned out to be doing >>>>something incredibly evil. Comments? >>>> >>>>-Jon >>>> >>>>Index: in.h >>>>=================================================================== >>>>RCS file: /export/ncvs/src/sys/netinet/in.h,v >>>>retrieving revision 1.55 >>>>diff -u -r1.55 in.h >>>>--- in.h 2001/06/15 00:37:27 1.55 >>>>+++ in.h 2001/08/09 15:12:19 >>>>@@ -452,7 +452,8 @@ >>>> #define IPCTL_FASTFORWARDING 14 /* use fast IP forwarding code */ >>>> #define IPCTL_KEEPFAITH 15 /* FAITH IPv4->IPv6 translater ctl */ >>>> #define IPCTL_GIF_TTL 16 /* default TTL for gif encap packet */ >>>>-#define IPCTL_MAXID 17 >>>>+#define IPCTL_FORWARD_BROADCAST 18 /* forward broadcast packets */ >>>>+#define IPCTL_MAXID 18 >>>> >>>> #define IPCTL_NAMES { \ >>>> { 0, 0 }, \ >>>>Index: ip_input.c >>>>=================================================================== >>>>RCS file: /export/ncvs/src/sys/netinet/ip_input.c,v >>>>retrieving revision 1.174 >>>>diff -u -r1.174 ip_input.c >>>>--- ip_input.c 2001/06/23 17:17:58 1.174 >>>>+++ ip_input.c 2001/08/09 15:33:59 >>>>@@ -103,6 +103,10 @@ >>>> SYSCTL_INT(_net_inet_ip, IPCTL_FORWARDING, forwarding, CTLFLAG_RW, >>>> &ipforwarding, 0, "Enable IP forwarding between interfaces"); >>>> >>>>+int ipforward_broadcast = 0; >>>>+SYSCTL_INT(_net_inet_ip, IPCTL_FORWARD_BROADCAST, forward_broadcast, >>>>CTLFLAG_RW, >>>>+ &ipforward_broadcast, 0, "Enable broadcast packets when forwarding >>>>IP packets"); >>>>+ >>>> static int ipsendredirects = 1; /* XXX */ >>>> SYSCTL_INT(_net_inet_ip, IPCTL_SENDREDIRECTS, redirect, CTLFLAG_RW, >>>> &ipsendredirects, 0, "Enable sending IP redirects"); >>>>@@ -1684,7 +1688,8 @@ >>>> } >>>> >>>> error = ip_output(m, (struct mbuf *)0, &ipforward_rt, >>>>- IP_FORWARDING, 0); >>>>+ IP_FORWARDING| >>>>+ (ipforward_broadcast?IP_ALLOWBROADCAST:0), 0); >>>> if (error) >>>> ipstat.ips_cantforward++; >>>> else { >>>> >>>> >>>>-- >>>>Anthony Volodkin >>>> >>>> >>>>To Unsubscribe: send mail to majordomo@FreeBSD.org >>>>with "unsubscribe freebsd-net" in the body of the message >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> >> >> >> >> > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-net" in the body of the message > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 27 10:20:56 2002 Delivered-To: freebsd-net@freebsd.org Received: from rack.purplecat.net (rack.purplecat.net [208.133.44.46]) by hub.freebsd.org (Postfix) with ESMTP id ECE3A37B400 for ; Thu, 27 Jun 2002 10:20:29 -0700 (PDT) Received: (qmail 59061 invoked from network); 27 Jun 2002 17:20:40 -0000 Received: from unknown (HELO micron) (208.150.25.130) by rack.purplecat.net with SMTP; 27 Jun 2002 17:20:40 -0000 From: "Peter Brezny" To: Subject: limiting directed broadcasts with ipfw. Date: Thu, 27 Jun 2002 13:18:04 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Importance: Normal Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I did a quick search through the man page, but didn't come up with anything right off that looked like it could help mitigate smurf attacks similar to the cisco: no ip directed-broadcast feature. Is there a way? TIA Peter Brezny Skyrunner.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 27 10:38:53 2002 Delivered-To: freebsd-net@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id 28D7137B400 for ; Thu, 27 Jun 2002 10:38:41 -0700 (PDT) Received: from isi.edu (vfg6pvpzw7xv58kl@hbo.isi.edu [128.9.160.75]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g5RHcdr19748; Thu, 27 Jun 2002 10:38:39 -0700 (PDT) Message-ID: <3D1B4D9E.2010007@isi.edu> Date: Thu, 27 Jun 2002 10:38:38 -0700 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0.0) Gecko/20020618 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: Peter Brezny Cc: freebsd-net@freebsd.org Subject: Re: limiting directed broadcasts with ipfw. References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090803020504090809080108" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a cryptographically signed message in MIME format. --------------ms090803020504090809080108 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Peter Brezny wrote: > I did a quick search through the man page, but didn't come up with anything > right off that looked like it could help mitigate smurf attacks similar to > the cisco: > no ip directed-broadcast > > feature. > > Is there a way? I thought directed broadcasts where disabled by default to begin with (as required by RFC what-was-the-number-again, the one that updates that piece of RFC 1812). Have you *seen* your box forward directed broadcasts with a default configuration? Lars -- Lars Eggert USC Information Sciences Institute --------------ms090803020504090809080108 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIrjCC ArUwggIeoAMCAQICAwWBRzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAxMDgyNDE2NDAwMFoXDTAyMDgyNDE2NDAwMFowVDEP MA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2VydDEc MBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEA0AvLBsD78nxcUHeHkaMgl3b4qYPnfgbf8Lh+HQP8RgGMRG/Yb+vTpkGezlwt9pkJxiD1 1uZDy4CNNJUu3gKxKSb+zRV70O+lkwwftuHoLHoH4xwo3LcQ2LGDpd+I95tUN4dfJ3TmeEcU SF50dC/SuUI4w8AlhXQ8IxrhgdayTpECAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIB BAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1Ud EwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAheZhn0pQA8zI7U2K1ZIAl11j0a1DKxnp3GtT vOUrGRB3WvYxidvdZ1kizhEsWeXU81TkNDH0DaRqtOEeu6Q2OhB+jeKEqY7IDAJE4/fI0e+d 6PnG1hd+vEvYmsKHkmzBhPc94XUOKNWO+qVNP2NGyNI3QIDy5wX4fdcOo1S34r4wggK1MIIC HqADAgECAgMFgUcwDQYJKoZIhvcNAQECBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYD VQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg UlNBIDIwMDAuOC4zMDAeFw0wMTA4MjQxNjQwMDBaFw0wMjA4MjQxNjQwMDBaMFQxDzANBgNV BAQTBkVnZ2VydDENMAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkq hkiG9w0BCQEWDWxhcnNlQGlzaS5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANAL ywbA+/J8XFB3h5GjIJd2+KmD534G3/C4fh0D/EYBjERv2G/r06ZBns5cLfaZCcYg9dbmQ8uA jTSVLt4CsSkm/s0Ve9DvpZMMH7bh6Cx6B+McKNy3ENixg6XfiPebVDeHXyd05nhHFEhedHQv 0rlCOMPAJYV0PCMa4YHWsk6RAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy dU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBAgUAA4GBAIXmYZ9KUAPMyO1NitWSAJddY9GtQysZ6dxrU7zlKxkQ d1r2MYnb3WdZIs4RLFnl1PNU5DQx9A2karThHrukNjoQfo3ihKmOyAwCROP3yNHvnej5xtYX frxL2JrCh5JswYT3PeF1DijVjvqlTT9jRsjSN0CA8ucF+H3XDqNUt+K+MIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYICpjCCAqICAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDBYFHMAkGBSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAyMDYyNzE3MzgzOFowIwYJKoZIhvcNAQkEMRYEFMvqWx6D2E9b nRBWz6QitCc+vaXIMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0B CRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG A1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRl IFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMF gUcwDQYJKoZIhvcNAQEBBQAEgYDCpv4dHOe6b7LxiQ64Y9+3NXSqld/WAJseMFn8qFSGKOy8 ZYnfn9nRsUs3QrqhV63HD/MgL8jG3lZDMZf/BLNy20C/xXJM3odoZcWi6+U8FbcsN50+UDkv 4PJ1uOHEG3ua4KOj5UpyFH4OXIRzdImGLgouN/TzM3zz/IWQVSL1YwAAAAAAAA== --------------ms090803020504090809080108-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 27 11: 1:16 2002 Delivered-To: freebsd-net@freebsd.org Received: from tp.databus.com (p72-186.acedsl.com [66.114.72.186]) by hub.freebsd.org (Postfix) with ESMTP id 3E83937B41E for ; Thu, 27 Jun 2002 11:01:05 -0700 (PDT) Received: from databus.com (localhost.databus.com [127.0.0.1]) by tp.databus.com (8.12.4/8.12.3) with ESMTP id g5RI14QZ005674; Thu, 27 Jun 2002 14:01:04 -0400 (EDT) (envelope-from barney@databus.com) Received: (from barney@localhost) by databus.com (8.12.4/8.12.4/Submit) id g5RI14vI005673; Thu, 27 Jun 2002 14:01:04 -0400 (EDT) Date: Thu, 27 Jun 2002 14:01:04 -0400 From: Barney Wolff To: Peter Brezny Cc: freebsd-net@FreeBSD.ORG Subject: Re: limiting directed broadcasts with ipfw. Message-ID: <20020627140104.A5456@tp.databus.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from pbrezny@purplecat.net on Thu, Jun 27, 2002 at 01:18:04PM -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Nothing automatic or shorthand, but add nnnn deny ip from any to x.y.z.255 (or whatever your broadcast is) will work just fine. On Thu, Jun 27, 2002 at 01:18:04PM -0400, Peter Brezny wrote: > I did a quick search through the man page, but didn't come up with anything > right off that looked like it could help mitigate smurf attacks similar to > the cisco: > no ip directed-broadcast > > feature. > > Is there a way? > > TIA > > Peter Brezny > Skyrunner.net > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message -- Barney Wolff I never met a computer I didn't like. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 27 11: 7:31 2002 Delivered-To: freebsd-net@freebsd.org Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by hub.freebsd.org (Postfix) with ESMTP id 26FE737B48B; Thu, 27 Jun 2002 11:06:26 -0700 (PDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Thu, 27 Jun 2002 14:06:23 -0400 Message-ID: <8C92E23A3E87FB479988285F9E22BE46FDE788@ftmail.lab.flarion.com> From: Matt Impett To: 'Randall Stewart' , Matt Impett Cc: 'Julian Elischer' , Lars Eggert , "'freebsd-net@freebsd.org'" , "'freebsd-questions@freebsd.org'" Subject: RE: source address based routing Date: Thu, 27 Jun 2002 14:06:19 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Randall Stewart wrote: > Matt: > > Curiosity drives me to ask the question... > > Where is the Foreign agent (FA)? > > In most mobile IP scenarios I have been familar with (granted a > limited set.. and I have a tiny idea of how it should work > that may be dated) the mobile has a FA. The FA is either > co-located inside the mobile.. which in that case it would > have the tunnel back to the home agent... OR the FA is a > box somewhere in your network that picks up the packets > from the wire and then encapsulates them and stuffs them > back up the tunnel to the home agent... I think this is your > "access box" if I read things correctly. I didn't know how familiar people were with MIP, so I left out some details. You are correct though that our "access box" is also our FA. > In such a case the "access box" SHOULD have a valid address > on the network and should have its tunnel going from it > to the home agent. Yes. > > All the FA needs to do is grab the packets sourced from these > mobiles. I would think the firewall should be able to redirect > these to your code much like the nat something like > > ... add divert natd all from any to any via ... > > This will get your user space code all of the packets > going by on this box. From there I would think you could > write code that would look at the sources and put them into > the right tunnels... Not sure if you could use the GIF tunnel > itself... or just write the tunneling software yourself... probably > there is a creative way to do this with one of th GIF tunnels... You are absolutely correct that all the FA needs to do is grab packets sourced from the mobile and send them out a reverse tunnel. The problem is that routing in BSD is only destination based. I could do: ... add divert natd all from any to any via ... which would divert the mobiles packets up to user space. From here, though, how do I put them into the right tunnel??? Remember that I have no routing table entry which points to one of the tunnels, because routing table entries are destination based and I have no destination IP that I want to use the tunnel, only source addresses. I guess what my user space process could do would be just to take the IP packet that was diverted up to it and send it out a RAW IP socket to the HA address. This should work!! It is a little strange, in that I will not be using a kernel level tunnel device (ie. GIF devices). Also, all reverse tunneled packets (which could be all traffic from the mobile nodes) now has to take a trip up into user space. I would hate to see what this does to the throughput, but this should work. It would be nice if I could create two ng_ksockets, one bound to a divert port, and the other bound to inet/raw/ip, so that packets diverted to the divert port would get passed to the inet/raw/ip hook and go out the IP stack. Is this possible??? thanks, matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 27 11:21:58 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id 9F09937B414 for ; Thu, 27 Jun 2002 11:20:20 -0700 (PDT) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020627182019.MEAZ9178.rwcrmhc51.attbi.com@InterJet.elischer.org>; Thu, 27 Jun 2002 18:20:19 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA69839; Thu, 27 Jun 2002 11:06:28 -0700 (PDT) Date: Thu, 27 Jun 2002 11:06:28 -0700 (PDT) From: Julian Elischer To: Anthony Volodkin Cc: freebsd-net@freebsd.org Subject: Re: Forwarding UDP packets In-Reply-To: <3D1B40D8.4080809@brainlink.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, 27 Jun 2002, Anthony Volodkin wrote: > PopTop also uses proxy arp supposedly (i got that option enabled). I > even read that that feature is supposed to allow broadcasts to function > properly. It doesn't however. > > A friend suggested i try to bridge two interfaces (tun0 and fxp0). I > first tried using briding implemented by 'options BRIDGE'. That failed > to set the tun0 into promiscious mode and hence did not produce the > desired effect. Then I tried using the > /usr/share/examples/netgraph/ether.bridge script to bridge the two > interfaces. That failed as well. Netgraph complained that 'tun0' does > not exist, even though it was up and running. Any more clues on > forwarding packets with destination 255.255.255.255 across interfaces > are welcome. bridging only works with ethernets... tun0 is not an ethernet. please try mpd To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 27 11:23:57 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id B528B37B432; Thu, 27 Jun 2002 11:20:31 -0700 (PDT) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020627182030.MEFC9178.rwcrmhc51.attbi.com@InterJet.elischer.org>; Thu, 27 Jun 2002 18:20:30 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA69824; Thu, 27 Jun 2002 11:02:48 -0700 (PDT) Date: Thu, 27 Jun 2002 11:02:46 -0700 (PDT) From: Julian Elischer To: Matt Impett Cc: Lars Eggert , "'freebsd-net@freebsd.org'" , "'freebsd-questions@freebsd.org'" Subject: RE: source address based routing In-Reply-To: <8C92E23A3E87FB479988285F9E22BE46FDE77D@ftmail.lab.flarion.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org ahhhhhhh ok You need tje netgraph ipfw node or bpf node, attached to a netgraph ksocket node implementing the tunnel hmm the netgraph ipfw node is not yet checked in.. someone volunteered to update it, and in fact I guess now that luigi has rewritten ipfw, maybe the new one can b emade into a netgraph node easier. You may find that this works for a prototype, and that you then want to write a special purpose netgraph node to do just what you want.. anyhow, check out netgraph while you are about it.. it was designed for tunnelling and ancapsulation.. On Thu, 27 Jun 2002, Matt Impett wrote: > inline.. > > > -----Original Message----- > > From: Julian Elischer [mailto:julian@elischer.org] > > Sent: Wednesday, June 26, 2002 9:40 PM > > To: Lars Eggert > > Cc: Matt Impett; 'freebsd-net@freebsd.org'; > > 'freebsd-questions@freebsd.org' > > Subject: Re: source address based routing > > > > > > On Wed, 26 Jun 2002, Lars Eggert wrote: > > > > > Matt Impett wrote: > > > > gladly.. I am trying to implement reverse tunneling for mobile-IP. > The > > > > basic idea is that packets must be reverse tunneled to different IP > > > > addresses depending on the source address of the packet. The reason > the > > > > tunnel does not have an IP address associated with it is that I don't > want > > > > to forward traffic down the tunnel for any other reason besides source > > > > addresses. As soon as I assign the tunnel interface an address, > traffic > > > > sent to that address will be tunneled. > > > > Surely 10.200.x.x is unlikely to be used.. it gives you 64000 possible > > tunnels. What I am having trouble with is that the tunnel to use depends > > on the SOURCE? That seems a little unusual.. Obviously I'm missing > > something in the words "reverse tunnelling". > > The company I work for (Flarion Technologies) is building an IP access box > for mobile wireless networks that will plug into existing network > infrastructure. I would be a little scared reserving a large piece of the > private address space as I cannot be assured that the operator that owns the > (private) network we will be plugging into is not using the same space. > Doing so would require agreements with them about the use or reservation of > the chunks of addressing space. It could be done, but I would rather avoid > it. > > As for tunneling based on SOURCE, here is a brief explanation. We are > running mobileIP to handle device mobility in our network. Basically, > mobile nodes can have IP addresses which are not topologically correct at > the access router they are connected to, but rather ARE topologically > correct at some node (the Home Agent) back in the network. Downlink traffic > (to the mobile node) is tunnelened from the Home Agent to the mobile's > current point of attachment. Similarly, uplink traffic (from the mobile > node), needs to be reverse tunneled back to the Home Agent, as the IP > address the mobile will be sourcing traffic with is not topologically > correct and will be dropped by any routers doing ingress filtering. So, our > access box has to look for packets from particular source addresses and > tunnel them back to that address's Home Agent. > > matt > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 27 11:24: 0 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id D921137B43F; Thu, 27 Jun 2002 11:20:37 -0700 (PDT) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020627182037.MEHJ9178.rwcrmhc51.attbi.com@InterJet.elischer.org>; Thu, 27 Jun 2002 18:20:37 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA69866; Thu, 27 Jun 2002 11:11:03 -0700 (PDT) Date: Thu, 27 Jun 2002 11:11:02 -0700 (PDT) From: Julian Elischer To: Matt Impett Cc: "'Randall Stewart'" , Lars Eggert , "'freebsd-net@freebsd.org'" , "'freebsd-questions@freebsd.org'" Subject: RE: source address based routing In-Reply-To: <8C92E23A3E87FB479988285F9E22BE46FDE788@ftmail.lab.flarion.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, 27 Jun 2002, Matt Impett wrote: > It would be nice if I could create two ng_ksockets, one bound to a divert > port, and the other bound to inet/raw/ip, so that packets diverted to the > divert port would get passed to the inet/raw/ip hook and go out the IP > stack. Is this possible??? netgraph ksockets can do anything a userland socket can do.... I would even use a custom filtering node to do the tunnel selection. netgraph nodes are very easy to write.. > > thanks, > matt > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 27 12: 1:12 2002 Delivered-To: freebsd-net@freebsd.org Received: from overlord.e-gerbil.net (e-gerbil.net [64.186.142.66]) by hub.freebsd.org (Postfix) with ESMTP id 236D937B416 for ; Thu, 27 Jun 2002 12:00:39 -0700 (PDT) Received: by overlord.e-gerbil.net (Postfix, from userid 1000) id D5F4615E4B; Thu, 27 Jun 2002 15:00:32 -0400 (EDT) Date: Thu, 27 Jun 2002 15:00:32 -0400 From: Richard A Steenbergen To: Peter Brezny Cc: freebsd-net@freebsd.org Subject: Re: limiting directed broadcasts with ipfw. Message-ID: <20020627190032.GC99199@overlord.e-gerbil.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, Jun 27, 2002 at 01:18:04PM -0400, Peter Brezny wrote: > I did a quick search through the man page, but didn't come up with anything > right off that looked like it could help mitigate smurf attacks similar to > the cisco: > no ip directed-broadcast > > feature. > > Is there a way? sysctl net.inet.icmp.bmcastecho=0 has been the default since... well since smurf came out. :) -- Richard A Steenbergen http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 27 12:18: 4 2002 Delivered-To: freebsd-net@freebsd.org Received: from mail.toltecint.net (mail.toltecint.net [65.45.180.172]) by hub.freebsd.org (Postfix) with SMTP id 2677137B401 for ; Thu, 27 Jun 2002 12:17:48 -0700 (PDT) Received: (qmail 31638 invoked by uid 85); 27 Jun 2002 19:17:46 -0000 Received: from artslaptop.toltecint.net (HELO ARTSLAPTOP.toltec.biz) (192.168.135.20) by mail.toltecint.net with SMTP; 27 Jun 2002 19:17:44 -0000 Message-Id: <5.1.1.6.2.20020627122834.022c8f50@mail.toltecint.net> X-Sender: art@mail.toltecint.net X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Thu, 27 Jun 2002 13:17:52 -0600 To: freebsd-net@FreeBSD.ORG From: Arthur Peet Subject: bpf/netgraph interaction Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by AMaViS perl-11 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org G'day. Can anyone explain the relationship between BPF and netgraph sockets? I am trying to intercept packets destined for a process which is using BPF for read and write operations on an interface (and drop not-so-good packets). I can see all packets on the interface (using NgRecvData), however I am unable to drop the bad packets (by not calling my NgSendData function) as the process using BPF seems to be bypassing the netgraph functions. Thanks, -Art To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 27 14: 1:55 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id 416C737B400 for ; Thu, 27 Jun 2002 14:00:26 -0700 (PDT) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020627210024.PPOZ15755.rwcrmhc53.attbi.com@InterJet.elischer.org>; Thu, 27 Jun 2002 21:00:24 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id NAA70567; Thu, 27 Jun 2002 13:45:19 -0700 (PDT) Date: Thu, 27 Jun 2002 13:45:17 -0700 (PDT) From: Julian Elischer To: Arthur Peet Cc: freebsd-net@FreeBSD.ORG Subject: Re: bpf/netgraph interaction In-Reply-To: <5.1.1.6.2.20020627122834.022c8f50@mail.toltecint.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Use the Source Luke! ether_input(ifp, eh, m) struct ifnet *ifp; struct ether_header *eh; struct mbuf *m; { struct ether_header save_eh; /* Check for a BPF tap */ if (ifp->if_bpf != NULL) { struct m_hdr mh; /* This kludge is OK; BPF treats the "mbuf" as read-only */ mh.mh_next = m; mh.mh_data = (char *)eh; mh.mh_len = ETHER_HDR_LEN; bpf_mtap(ifp, (struct mbuf *)&mh); } ifp->if_ibytes += m->m_pkthdr.len + sizeof (*eh); /* Handle ng_ether(4) processing, if any */ if (ng_ether_input_p != NULL) { (*ng_ether_input_p)(ifp, &m, eh); if (m == NULL) return; } /* Check for bridging mode */ if (BDG_ACTIVE(ifp) ) { struct ifnet *bif; [...] as you see, bpf copies are taken before netgraph processing.. and non-netgraph bridging occurs after that. On Thu, 27 Jun 2002, Arthur Peet wrote: > G'day. > > Can anyone explain the relationship between BPF and netgraph sockets? I am > trying to intercept packets destined for a process which is using BPF for > read and write operations on an interface (and drop not-so-good > packets). I can see all packets on the interface (using NgRecvData), > however I am unable to drop the bad packets (by not calling my NgSendData > function) as the process using BPF seems to be bypassing the netgraph > functions. > > Thanks, > > -Art > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 27 14:54:24 2002 Delivered-To: freebsd-net@freebsd.org Received: from mail.toltecint.net (mail.toltecint.net [65.45.180.172]) by hub.freebsd.org (Postfix) with SMTP id DB75337B400 for ; Thu, 27 Jun 2002 14:54:17 -0700 (PDT) Received: (qmail 32789 invoked by uid 85); 27 Jun 2002 21:54:17 -0000 Received: from artslaptop.toltecint.net (HELO ARTSLAPTOP.toltec.biz) (192.168.135.20) by mail.toltecint.net with SMTP; 27 Jun 2002 21:54:14 -0000 Message-Id: <5.1.1.6.2.20020627152659.0228f128@mail.toltecint.net> X-Sender: art@mail.toltecint.net X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Thu, 27 Jun 2002 15:54:24 -0600 To: Julian Elischer From: Arthur Peet Subject: Re: bpf/netgraph interaction Cc: freebsd-net@FreeBSD.ORG In-Reply-To: References: <5.1.1.6.2.20020627122834.022c8f50@mail.toltecint.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by AMaViS perl-11 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >Use the Source Luke! Thanks, Obi! :) I REALLY appreciate your response. >as you see, bpf copies are taken before netgraph processing.. >and non-netgraph bridging occurs after that. It appears to me that if I switched the order in which the processing occurs and recompiled the kernel, the function would be absolutely broken. i.e I would never get to the BPF tap. Is this true? Are there any other taps I may access in order to accomplish this goal? On another note - my kernel - 4.4-Release did not have the following line between the two if statements: > ifp->if_ibytes += m->m_pkthdr.len + sizeof (*eh); Is it time for me to upgrade? Thanks again! -Art To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 27 15:21:28 2002 Delivered-To: freebsd-net@freebsd.org Received: from spmx.securepipe.com (spmx.securepipe.com [64.73.37.194]) by hub.freebsd.org (Postfix) with SMTP id 20C9637B401 for ; Thu, 27 Jun 2002 15:21:24 -0700 (PDT) Received: (qmail 4804 invoked from network); 27 Jun 2002 22:12:30 -0000 Received: from unknown (HELO alice.wi.securepipe.com) (64.73.37.245) by spmx.securepipe.com with SMTP; 27 Jun 2002 22:12:30 -0000 Received: (qmail 2076 invoked from network); 27 Jun 2002 22:21:17 -0000 Received: from unknown (HELO Homer.the-rob.com) (imapzietlow@216.170.184.30) by 0 with SMTP; 27 Jun 2002 22:21:17 -0000 Content-Type: text/plain; charset="us-ascii" From: Rob Zietlow To: mike@sentex.net Subject: Re: SOLVED! Native PPPoE broken (4.6-STABLE), RP-PPPoE working?! Date: Thu, 27 Jun 2002 17:21:13 -0500 User-Agent: KMail/1.4.1 Cc: net@freebsd.org, rob@the-rob.com MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200206271721.13301.zietlow@securepipe.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >Just to close off this issue an feed it to the archives in case anyone =3D >else >runs into this issue, the telco found the article below in the vendor's >knowledge database.=20 >Again to summarize, if you use FreeBSD, PPPoE and your ISP or your ISP's >telco uses an ERX as the PPPoE concentrator, make sure you disable and >prevent VJ header compression as it will not work. Bell Canada has been >slowly deploying these boxes so if you use Sympatico, or your ISP is in >Quebec or Ontario, you will start to run into this issue as the telco =3D >slow >gets rid of their Redback SMSes and replaces them with Unisphere's ERX >boxes.=20 > >The solution I found was to make sure that its also disabled and not >offered in RADIUS either, so you might have to talk to your ISP if they >have it configured, as we did. how exactly do you turn this off? Or even find out if it's enabled? A se= arch=20 on google mostly gives up ISDN cases of this kernel option. one article=20 mentions spppcontrol to turn this off, but when I attempt to use this opt= ion=20 I get the following PITA# spppcontrol tun0 spppcontrol: SIOCGIFGENERIC(SPPPIOGDEFS): Invalid argument I also attempted 'pppstats tun0' PITA# pppstats tun0 pppstats: invalid interface 'tun0' specified pppstats: couldn't get PPP statistics: Invalid argument PITA# pppstats -h pppstats: illegal option -- h Usage: pppstats [-a|-d] [-v|-r|-z] [-c count] [-w wait] [interface] Is there anything that I need to set in the /etc/ppp/ppp.conf or a sysctr= l? Rob=20 >=09---Mike --=20 ---------------------- Rob Zietlow Network Security Engineer=09 SecurePipe, Inc Madison, WI (608) 294-6940 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 27 16: 0:26 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id 9C92637B400 for ; Thu, 27 Jun 2002 16:00:18 -0700 (PDT) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020627230018.THNA15755.rwcrmhc53.attbi.com@InterJet.elischer.org>; Thu, 27 Jun 2002 23:00:18 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id PAA71098; Thu, 27 Jun 2002 15:50:17 -0700 (PDT) Date: Thu, 27 Jun 2002 15:50:16 -0700 (PDT) From: Julian Elischer To: Arthur Peet Cc: freebsd-net@FreeBSD.ORG Subject: Re: bpf/netgraph interaction In-Reply-To: <5.1.1.6.2.20020627152659.0228f128@mail.toltecint.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, 27 Jun 2002, Arthur Peet wrote: > > >Use the Source Luke! > > Thanks, Obi! :) I REALLY appreciate your response. > > >as you see, bpf copies are taken before netgraph processing.. > >and non-netgraph bridging occurs after that. > > It appears to me that if I switched the order in which the processing > occurs and recompiled the kernel, the function would be absolutely broken. > i.e I would never get to the BPF tap. Is this true? yes, and in this case, packets REinjected by netgraph never see the bridge code. because they are re-injected at a later stage of processing. > > Are there any other taps I may access in order to accomplish this goal? I forget the goal. sorry > > On another note - my kernel - 4.4-Release did not have the following line > between the two if statements: > > > ifp->if_ibytes += m->m_pkthdr.len + sizeof (*eh); > > Is it time for me to upgrade? > If you are working from sources, then it's usually worth tracking the altest version.. cvsup make world make kernel mergemaster reboot it's not that much work :-) (once you have the cvsup set up correctly) > Thanks again! > > -Art > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 27 16:12:29 2002 Delivered-To: freebsd-net@freebsd.org Received: from mail.toltecint.net (mail.toltecint.net [65.45.180.172]) by hub.freebsd.org (Postfix) with SMTP id 8DB5837B407 for ; Thu, 27 Jun 2002 16:12:25 -0700 (PDT) Received: (qmail 33741 invoked by uid 85); 27 Jun 2002 23:12:24 -0000 Received: from artslaptop.toltecint.net (HELO ARTSLAPTOP.toltec.biz) (192.168.135.20) by mail.toltecint.net with SMTP; 27 Jun 2002 23:12:22 -0000 Message-Id: <5.1.1.6.2.20020627170548.0220fb38@mail.toltecint.net> X-Sender: art@mail.toltecint.net X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Thu, 27 Jun 2002 17:12:32 -0600 To: Julian Elischer From: Arthur Peet Subject: Re: bpf/netgraph interaction Cc: freebsd-net@FreeBSD.ORG In-Reply-To: References: <5.1.1.6.2.20020627152659.0228f128@mail.toltecint.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by AMaViS perl-11 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org At 04:50 PM 6/27/2002, Julian Elischer wrote: > > Are there any other taps I may access in order to accomplish this goal? > >I forget the goal. sorry No problem - Hope you don't mind if I restate it. I am trying to strip/drop packets before they reach a server process which uses BPF for communicating with the network interface. I have briefly been looking into using an ipfw/divert socket, but I don't think that is going to work either. Thanks again! -Art To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 27 16:40:18 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id A03C537B400 for ; Thu, 27 Jun 2002 16:40:11 -0700 (PDT) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020627234011.VRXN9178.rwcrmhc51.attbi.com@InterJet.elischer.org>; Thu, 27 Jun 2002 23:40:11 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id QAA71273; Thu, 27 Jun 2002 16:20:54 -0700 (PDT) Date: Thu, 27 Jun 2002 16:20:52 -0700 (PDT) From: Julian Elischer To: Arthur Peet Cc: freebsd-net@FreeBSD.ORG Subject: Re: bpf/netgraph interaction In-Reply-To: <5.1.1.6.2.20020627170548.0220fb38@mail.toltecint.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Ipfw divers from within the IP stack by then it's too late. you could diver th epackets using netgraph and filter them and then pass them back into the eiface netgraph node to continue up. then you tell your application to listen to the "nge" interface.. unfortunatly another driver also produces 'nge' interfaces, but the chance you have htat card is quite small. [fxp0]<--->[ng_ether]<----->{filter}<--->ng_eiface<---->[IP stack] \ \---BPF On Thu, 27 Jun 2002, Arthur Peet wrote: > At 04:50 PM 6/27/2002, Julian Elischer wrote: > > > Are there any other taps I may access in order to accomplish this goal? > > > >I forget the goal. sorry > > > > No problem - Hope you don't mind if I restate it. > I am trying to strip/drop packets before they reach a server process which uses > BPF for communicating with the network interface. > I have briefly been looking into using an ipfw/divert socket, but I don't > think that is > going to work either. > > Thanks again! > -Art > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 27 20:48: 2 2002 Delivered-To: freebsd-net@freebsd.org Received: from cage.simianscience.com (cage.simianscience.com [64.7.134.1]) by hub.freebsd.org (Postfix) with ESMTP id 6844237B405 for ; Thu, 27 Jun 2002 20:47:55 -0700 (PDT) Received: from house.sentex.net (fcage [192.168.0.2]) by cage.simianscience.com (8.12.4/8.12.3) with ESMTP id g5S3kaur025042; Thu, 27 Jun 2002 23:46:37 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <5.1.0.14.0.20020627233341.074d7e30@192.168.0.12> X-Sender: mdtancsa@192.168.0.12 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 27 Jun 2002 23:47:47 -0400 To: Rob Zietlow From: Mike Tancsa Subject: Re: SOLVED! Native PPPoE broken (4.6-STABLE), RP-PPPoE working?! Cc: freebsd-net@freebsd.org In-Reply-To: <200206271721.13301.zietlow@securepipe.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: amavis-20020220 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org At 05:21 PM 6/27/2002 -0500, Rob Zietlow wrote: > >The solution I found was to make sure that its also disabled and not > >offered in RADIUS either, so you might have to talk to your ISP if they > >have it configured, as we did. > >how exactly do you turn this off? In my Radius config on the server, got rid of Framed-Compression = Van-Jacobsen-TCP-IP, in /etc/ppp/ppp.conf vjcomp (from the man pages) Default: Enabled and Accepted. This option determines if Van Jacobson header compression will be used. vjcomp disabled > Or even find out if it's enabled? Not sure on FreeBSD, but on my Cisco where all the PPPoE sessions are terminated as L2TP tunnels, I see bell-border#show int vi426 confi Virtual-Access426 is an L2TP link interface Building configuration... interface Virtual-Access426 configuration... mtu 1492 ip unnumbered Loopback0 ip tcp header-compression before and after bell-border#show int vi426 confi Virtual-Access426 is an L2TP link interface Building configuration... interface Virtual-Access426 configuration... mtu 1492 ip unnumbered Loopback0 In this case, I am not sure where the fault lies... In the Cisco, the ERX or FreeBSD, or PE. The ERX initiates the tunnel to the Cisco. At that point, I would have thought that they would properly negotiate capabilities... Not sure, but this did indeed solve the problem, and the ERX according to the article does not support VJ Header compressions. >PITA# spppcontrol tun0 >spppcontrol: SIOCGIFGENERIC(SPPPIOGDEFS): Invalid argument > >I also attempted 'pppstats tun0' > >PITA# pppstats tun0 >pppstats: invalid interface 'tun0' specified >pppstats: couldn't get PPP statistics: Invalid argument pppstats works for me cage# pppstats IN PACK VJCOMP VJUNC VJERR | OUT PACK VJCOMP VJUNC NON-VJ 0 0 0 0 0 | 0 0 0 0 0 cage# ---Mike -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 27 23: 3:53 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D908D37B400 for ; Thu, 27 Jun 2002 23:03:48 -0700 (PDT) Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C0BF43E09 for ; Thu, 27 Jun 2002 23:03:48 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g5S63m855052; Thu, 27 Jun 2002 23:03:48 -0700 (PDT) (envelope-from rizzo) Date: Thu, 27 Jun 2002 23:03:48 -0700 From: Luigi Rizzo To: net@freebsd.org Subject: interface stalling on tx ? Message-ID: <20020627230348.A54937@iguana.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, I have been hit by the following problem from time to time, and I was wondering if others have seen it. This has happened to me with the "em", "sis", "dc" and "fxp" cards, though it is not always easy to reproduce. But I have seen it enough times to believe that it is not card-specific. Basically, what it seems to happen is the following: If the driver has packets pending in its transmit queue (i.e. stored there by *_start()), and for some reason the link experiences some strange event (e.g. the device at the other end reboots), then packets pile up in the driver, the queue fills up, and the interface never resumes transmission until you do an ifconfig down/ ifconfig up (or some equivalent action is taken independently by the system). I thought that upon transmission the driver somehow registered a timeout to take care of these events, but maybe I am wrong ? Have other people seen this problem too ? cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 27 23:24:35 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DB1A537B401 for ; Thu, 27 Jun 2002 23:24:30 -0700 (PDT) Received: from smtp.noos.fr (lafontaine.noos.net [212.198.2.72]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE2D843E09 for ; Thu, 27 Jun 2002 23:24:29 -0700 (PDT) (envelope-from root@gits.dyndns.org) Received: (qmail 7497988 invoked by uid 0); 28 Jun 2002 06:24:28 -0000 Received: from unknown (HELO gits.gits.dyndns.org) ([212.198.229.153]) (envelope-sender ) by 212.198.2.72 (qmail-ldap-1.03) with SMTP for ; 28 Jun 2002 06:24:28 -0000 Received: from gits.gits.dyndns.org (t1jtj3bnphp7pg5n@localhost [127.0.0.1]) by gits.gits.dyndns.org (8.12.4/8.12.4) with ESMTP id g5S6ORtY042393 for ; Fri, 28 Jun 2002 08:24:27 +0200 (CEST) (envelope-from root@gits.dyndns.org) Received: (from root@localhost) by gits.gits.dyndns.org (8.12.4/8.12.4/Submit) id g5S6ORBn042392 for freebsd-net@FreeBSD.org; Fri, 28 Jun 2002 08:24:27 +0200 (CEST) (envelope-from root) Date: Fri, 28 Jun 2002 08:24:27 +0200 From: Cyrille Lefevre To: freebsd net Subject: arp_rtrequest: bad gateway value Message-ID: <20020628062427.GF35599@gits.dyndns.org> Mail-Followup-To: Cyrille Lefevre , freebsd net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.99i Organization: ACME X-Face: V|+c;4!|B?E%BE^{E6);aI.[< List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, since a few days, I get the following message, any idea ? Jun 28 07:00:01 gits /kernel: arp_rtrequest: bad gateway value # uname -a FreeBSD gits 4.6-STABLE FreeBSD 4.6-STABLE #15: Sun Jun 23 06:31:23 CEST 2002 root@gits:/disk2/freebsd/src/sys/compile/CUSTOM i386 # ifconfig -a # ifconfig -a ep0: flags=8843 mtu 1500 inet 212.198.229.153 netmask 0xffffff00 broadcast 212.198.229.255 inet 192.168.144.96 netmask 0xffffffff broadcast 192.168.144.96 inet 192.168.144.97 netmask 0xffffffff broadcast 192.168.144.97 ether 00:60:08:1a:9a:37 media: Ethernet 10baseT/UTP lo0: flags=8049 mtu 16384 inet 127.0.0.1 netmask 0xff000000 # netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 212.198.229.1 UGSc 4 51770 ep0 127.0.0.1 127.0.0.1 UH 3 9585 lo0 192.168.144.96 192.168.144.96 UH 0 0 ep0 => 192.168.144.96/32 link#1 UC 0 0 ep0 192.168.144.97 192.168.144.97 UH 0 0 ep0 => 192.168.144.97/32 link#1 UC 0 0 ep0 212.198.229 link#1 UC 2 0 ep0 212.198.229.1 08:00:3e:17:1c:a6 UHLW 2 0 ep0 1123 212.198.229.153 127.0.0.1 UGHS 0 0 lo0 212.198.229.255 ff:ff:ff:ff:ff:ff UHLWb 1 6 ep0 Cyrille. -- Cyrille Lefevre mailto:cyrille.lefevre@laposte.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jun 28 0:33: 1 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 904A637B401 for ; Fri, 28 Jun 2002 00:32:52 -0700 (PDT) Received: from patrocles.silby.com (d116.as7.nwbl0.wi.voyager.net [169.207.128.244]) by mx1.FreeBSD.org (Postfix) with ESMTP id B337943E06 for ; Fri, 28 Jun 2002 00:32:50 -0700 (PDT) (envelope-from silby@silby.com) Received: from patrocles.silby.com (localhost [127.0.0.1]) by patrocles.silby.com (8.12.4/8.12.4) with ESMTP id g5S7ZNcv071336; Fri, 28 Jun 2002 02:35:23 -0500 (CDT) (envelope-from silby@silby.com) Received: from localhost (silby@localhost) by patrocles.silby.com (8.12.4/8.12.4/Submit) with ESMTP id g5S7ZKYf071333; Fri, 28 Jun 2002 02:35:22 -0500 (CDT) X-Authentication-Warning: patrocles.silby.com: silby owned process doing -bs Date: Fri, 28 Jun 2002 02:35:20 -0500 (CDT) From: Mike Silbersack To: Luigi Rizzo Cc: net@freebsd.org Subject: Re: interface stalling on tx ? In-Reply-To: <20020627230348.A54937@iguana.icir.org> Message-ID: <20020628022611.K70821-100000@patrocles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, 27 Jun 2002, Luigi Rizzo wrote: > I thought that upon transmission the driver somehow registered a > timeout to take care of these events, but maybe I am wrong ? > > Have other people seen this problem too ? > > cheers > luigi The watchdog timer code in most of the drivers is rather conservative, and may not detect mid-transfer stalls. I'll use the dc driver as an example: In dc_start, if_timer = 5 is set. Then, in dc_txeof, if_timer = 0, disabling the watchdog timer. This means that after a _single_ frame is sent, any subsequent stall will not be recovered from by the watchdog. In the vr driver, we were having problems where such stalls could be caused by high load, and the ifconfig up / down process was getting annoying to users. I worked around this by setting if_timer = 5 every time vr_txeof was entered, only setting if_timer = 0 at the point when the _entire_ transmit buffer list was emptied. (See if_vr.c rev 1.49 to see how I did it in that driver.) You should be able to do something similar in all of the drivers, and I have indeed thought of doing so. Could you code up and test such a patch for whatever card you are using in your test environment to see if it is a successful workaround? Of course, in an ideal world all drivers would recover in a graceful fashion. However, taking advantage of the watchdog timer to reset stuck cards seems like an adequate workaround. So far, I can't see any downside to this approach. If the card never locks up, then the change is superfluous. When it does, the change is a lifesaver. Apologies if parts of this message sound like babbling; I should be sleeping at this moment in time. :) Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jun 28 0:40:24 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0EAB837B400 for ; Fri, 28 Jun 2002 00:40:11 -0700 (PDT) Received: from sccrmhc01.attbi.com (sccrmhc01.attbi.com [204.127.202.61]) by mx1.FreeBSD.org (Postfix) with ESMTP id 77C4743E09 for ; Fri, 28 Jun 2002 00:40:10 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by sccrmhc01.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020628074009.OAWA29588.sccrmhc01.attbi.com@InterJet.elischer.org>; Fri, 28 Jun 2002 07:40:09 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id AAA72972; Fri, 28 Jun 2002 00:23:15 -0700 (PDT) Date: Fri, 28 Jun 2002 00:23:14 -0700 (PDT) From: Julian Elischer To: Luigi Rizzo Cc: net@freebsd.org Subject: luigi, kernel module build broken by ipfw In-Reply-To: <20020627230348.A54937@iguana.icir.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org with freshly checked out sources, I can not build the modules... ===> ipfw cc -g -O -pipe -DIPFIREWALL -D_KERNEL -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wno-format -ansi -DKLD_MODULE -nostdinc -I- -I. -I@ -I@/dev -I@/../include -fno-common -g -mpreferred-stack-boundary=2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wno-format -ansi -c /usr/src/sys/netinet/ip_fw.c /usr/src/sys/netinet/ip_fw.c:216: warning: `union ip_fw_if' declared inside parameter list /usr/src/sys/netinet/ip_fw.c:216: warning: its scope is only this definition or declaration, which is probably not what you want /usr/src/sys/netinet/ip_fw.c: In function `tcpflg_match': /usr/src/sys/netinet/ip_fw.c:273: structure has no member named `fw_ipflg' /usr/src/sys/netinet/ip_fw.c:273: `IP_FW_IF_TCPEST' undeclared (first use in this function) /usr/src/sys/netinet/ip_fw.c:273: (Each undeclared identifier is reported only once /usr/src/sys/netinet/ip_fw.c:273: for each function it appears in.) [...] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jun 28 0:53:58 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8D03E37B401 for ; Fri, 28 Jun 2002 00:53:47 -0700 (PDT) Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id C0EF943E12 for ; Fri, 28 Jun 2002 00:53:25 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g5S7qrL55684; Fri, 28 Jun 2002 00:52:53 -0700 (PDT) (envelope-from rizzo) Date: Fri, 28 Jun 2002 00:52:53 -0700 From: Luigi Rizzo To: Mike Silbersack Cc: net@FreeBSD.ORG Subject: Re: interface stalling on tx ? Message-ID: <20020628005253.B55603@iguana.icir.org> References: <20020627230348.A54937@iguana.icir.org> <20020628022611.K70821-100000@patrocles.silby.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020628022611.K70821-100000@patrocles.silby.com>; from silby@silby.com on Fri, Jun 28, 2002 at 02:35:20AM -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, Jun 28, 2002 at 02:35:20AM -0500, Mike Silbersack wrote: ... > The watchdog timer code in most of the drivers is rather conservative, and > may not detect mid-transfer stalls. I'll use the dc driver as an example: > > In dc_start, if_timer = 5 is set. Then, in dc_txeof, if_timer = 0, > disabling the watchdog timer. This means that after a _single_ frame is > sent, any subsequent stall will not be recovered from by the watchdog. ok, i think this is exactly the problem, and "conservative" is an understatement, I would call that plain broken :) Your fix seems the correct way to handle the problem, I wonder if there is an easy way to put something like this in a generic procedure (such as ether_output_frame) that is called by all drivers instead of relying on the individual drivers to do the right thing each one in its own way... > In the vr driver, we were having problems where such stalls could be > caused by high load, and the ifconfig up / down process was getting > annoying to users. I worked around this by setting if_timer = 5 every > time vr_txeof was entered, only setting if_timer = 0 at the point when the > _entire_ transmit buffer list was emptied. > > (See if_vr.c rev 1.49 to see how I did it in that driver.) > > You should be able to do something similar in all of the drivers, and I > have indeed thought of doing so. Could you code up and test such a patch > for whatever card you are using in your test environment to see if it > is a successful workaround? yes i will try it tonight. thanks luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jun 28 0:54:10 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8115A37B405 for ; Fri, 28 Jun 2002 00:53:54 -0700 (PDT) Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 88B4143E0E for ; Fri, 28 Jun 2002 00:53:25 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g5S7lB955633; Fri, 28 Jun 2002 00:47:11 -0700 (PDT) (envelope-from rizzo) Date: Fri, 28 Jun 2002 00:47:11 -0700 From: Luigi Rizzo To: Julian Elischer Cc: net@FreeBSD.ORG Subject: Re: luigi, kernel module build broken by ipfw Message-ID: <20020628004710.A55603@iguana.icir.org> References: <20020627230348.A54937@iguana.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from julian@elischer.org on Fri, Jun 28, 2002 at 12:23:14AM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, Jun 28, 2002 at 12:23:14AM -0700, Julian Elischer wrote: oh, i forgot that... i cannot test it right now but the fix should be trivial in src/sys/modules/ipfw/Makefile, replace ip_fw.c with ip_fw2.c (and if it works, could you commit it ?) cheers luigi > > with freshly checked out sources, I can not build the modules... > > ===> ipfw > cc -g -O -pipe -DIPFIREWALL -D_KERNEL -Wall -Wredundant-decls > -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith > -Winline -Wcast-qual -Wno-format -ansi -DKLD_MODULE -nostdinc -I- > -I. -I@ -I@/dev -I@/../include -fno-common -g -mpreferred-stack-boundary=2 > -ffreestanding -Wall -Wredundant-decls -Wnested-externs > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline > -Wcast-qual -Wno-format -ansi -c /usr/src/sys/netinet/ip_fw.c > /usr/src/sys/netinet/ip_fw.c:216: warning: `union ip_fw_if' declared > inside parameter list > /usr/src/sys/netinet/ip_fw.c:216: warning: its scope is only this > definition or declaration, which is probably not what you want > /usr/src/sys/netinet/ip_fw.c: In function `tcpflg_match': > /usr/src/sys/netinet/ip_fw.c:273: structure has no member named `fw_ipflg' > /usr/src/sys/netinet/ip_fw.c:273: `IP_FW_IF_TCPEST' undeclared (first use > in this function) > /usr/src/sys/netinet/ip_fw.c:273: (Each undeclared identifier is reported > only once > /usr/src/sys/netinet/ip_fw.c:273: for each function it appears in.) > > [...] > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jun 28 1:20:21 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 58DA037B400 for ; Fri, 28 Jun 2002 01:20:13 -0700 (PDT) Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 050E343E09 for ; Fri, 28 Jun 2002 01:20:13 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020628082012.HRMP9178.rwcrmhc51.attbi.com@InterJet.elischer.org>; Fri, 28 Jun 2002 08:20:12 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id BAA73127; Fri, 28 Jun 2002 01:08:49 -0700 (PDT) Date: Fri, 28 Jun 2002 01:08:48 -0700 (PDT) From: Julian Elischer To: Luigi Rizzo Cc: net@FreeBSD.ORG Subject: Re: luigi, kernel module build broken by ipfw In-Reply-To: <20020628004710.A55603@iguana.icir.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org why can you not have teh .h file have defines for both with a #if separating them? I'll try it soon, teh world build broke too in libalias, but I have not got it in front of me at the moment.. it's scrolled off. ok theMakefile fix works.. I'll check it in.. On Fri, 28 Jun 2002, Luigi Rizzo wrote: > On Fri, Jun 28, 2002 at 12:23:14AM -0700, Julian Elischer wrote: > oh, i forgot that... > i cannot test it right now but the fix should be trivial > in src/sys/modules/ipfw/Makefile, replace ip_fw.c with ip_fw2.c > > (and if it works, could you commit it ?) > > cheers > luigi > > > > with freshly checked out sources, I can not build the modules... > > > > ===> ipfw > > cc -g -O -pipe -DIPFIREWALL -D_KERNEL -Wall -Wredundant-decls > > -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith > > -Winline -Wcast-qual -Wno-format -ansi -DKLD_MODULE -nostdinc -I- > > -I. -I@ -I@/dev -I@/../include -fno-common -g -mpreferred-stack-boundary=2 > > -ffreestanding -Wall -Wredundant-decls -Wnested-externs > > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline > > -Wcast-qual -Wno-format -ansi -c /usr/src/sys/netinet/ip_fw.c > > /usr/src/sys/netinet/ip_fw.c:216: warning: `union ip_fw_if' declared > > inside parameter list > > /usr/src/sys/netinet/ip_fw.c:216: warning: its scope is only this > > definition or declaration, which is probably not what you want > > /usr/src/sys/netinet/ip_fw.c: In function `tcpflg_match': > > /usr/src/sys/netinet/ip_fw.c:273: structure has no member named `fw_ipflg' > > /usr/src/sys/netinet/ip_fw.c:273: `IP_FW_IF_TCPEST' undeclared (first use > > in this function) > > /usr/src/sys/netinet/ip_fw.c:273: (Each undeclared identifier is reported > > only once > > /usr/src/sys/netinet/ip_fw.c:273: for each function it appears in.) > > > > [...] > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jun 28 1:20:38 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4D5EB37B405 for ; Fri, 28 Jun 2002 01:20:14 -0700 (PDT) Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id EA54B43E06 for ; Fri, 28 Jun 2002 01:20:13 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020628082013.HRMS9178.rwcrmhc51.attbi.com@InterJet.elischer.org>; Fri, 28 Jun 2002 08:20:13 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id BAA73157; Fri, 28 Jun 2002 01:15:14 -0700 (PDT) Date: Fri, 28 Jun 2002 01:15:13 -0700 (PDT) From: Julian Elischer To: Luigi Rizzo Cc: net@FreeBSD.ORG Subject: Re: luigi, kernel module build broken by ipfw In-Reply-To: <20020628004710.A55603@iguana.icir.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org also: cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wno-format -ansi -g -nostdinc -I- -I. -I../../.. -I../../../dev -I../../../contrib/dev/acpica -I../../../contrib/ipfilter -I../../../../include -D_KERNEL -include opt_global.h -fno-common -mpreferred-stack-boundary=2 -ffreestanding -Werror ../../../netinet/ip_fw2.c cc1: warnings being treated as errors ../../../netinet/ip_fw2.c: In function `ipfw_chk': ../../../netinet/ip_fw2.c:1781: warning: deprecated use of label at end of compound statement *** Error code 1 my quick answer is add a ";" on line 1780 but there is probably a beter way On Fri, 28 Jun 2002, Luigi Rizzo wrote: > On Fri, Jun 28, 2002 at 12:23:14AM -0700, Julian Elischer wrote: > oh, i forgot that... > i cannot test it right now but the fix should be trivial > in src/sys/modules/ipfw/Makefile, replace ip_fw.c with ip_fw2.c > > (and if it works, could you commit it ?) > > cheers > luigi > > > > with freshly checked out sources, I can not build the modules... > > > > ===> ipfw > > cc -g -O -pipe -DIPFIREWALL -D_KERNEL -Wall -Wredundant-decls > > -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith > > -Winline -Wcast-qual -Wno-format -ansi -DKLD_MODULE -nostdinc -I- > > -I. -I@ -I@/dev -I@/../include -fno-common -g -mpreferred-stack-boundary=2 > > -ffreestanding -Wall -Wredundant-decls -Wnested-externs > > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline > > -Wcast-qual -Wno-format -ansi -c /usr/src/sys/netinet/ip_fw.c > > /usr/src/sys/netinet/ip_fw.c:216: warning: `union ip_fw_if' declared > > inside parameter list > > /usr/src/sys/netinet/ip_fw.c:216: warning: its scope is only this > > definition or declaration, which is probably not what you want > > /usr/src/sys/netinet/ip_fw.c: In function `tcpflg_match': > > /usr/src/sys/netinet/ip_fw.c:273: structure has no member named `fw_ipflg' > > /usr/src/sys/netinet/ip_fw.c:273: `IP_FW_IF_TCPEST' undeclared (first use > > in this function) > > /usr/src/sys/netinet/ip_fw.c:273: (Each undeclared identifier is reported > > only once > > /usr/src/sys/netinet/ip_fw.c:273: for each function it appears in.) > > > > [...] > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jun 28 10:43:34 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6B00C37B40E for ; Fri, 28 Jun 2002 10:43:06 -0700 (PDT) Received: from patrocles.silby.com (d186.as9.nwbl0.wi.voyager.net [169.207.133.252]) by mx1.FreeBSD.org (Postfix) with ESMTP id CF81243E09 for ; Fri, 28 Jun 2002 10:42:55 -0700 (PDT) (envelope-from silby@silby.com) Received: from patrocles.silby.com (localhost [127.0.0.1]) by patrocles.silby.com (8.12.4/8.12.4) with ESMTP id g5SHjVcv073203; Fri, 28 Jun 2002 12:45:31 -0500 (CDT) (envelope-from silby@silby.com) Received: from localhost (silby@localhost) by patrocles.silby.com (8.12.4/8.12.4/Submit) with ESMTP id g5SHjUYA073200; Fri, 28 Jun 2002 12:45:31 -0500 (CDT) X-Authentication-Warning: patrocles.silby.com: silby owned process doing -bs Date: Fri, 28 Jun 2002 12:45:30 -0500 (CDT) From: Mike Silbersack To: Luigi Rizzo Cc: net@FreeBSD.ORG Subject: Junior Kernel hacker task? Re: interface stalling on tx ? In-Reply-To: <20020628005253.B55603@iguana.icir.org> Message-ID: <20020628124055.L72733-100000@patrocles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, 28 Jun 2002, Luigi Rizzo wrote: > ok, i think this is exactly the problem, and "conservative" is > an understatement, I would call that plain broken :) > > Your fix seems the correct way to handle the problem, > I wonder if there is an easy way to put something like > this in a generic procedure (such as ether_output_frame) > that is called by all drivers instead of relying on the > individual drivers to do the right thing each one in its > own way... I think that it would probably be easier to go and fix many of the network drivers than to abstract the watchdog timer more. If some junior kernel hacker wants a chance to write up some simple patches, this would be a good project. Of course, this also means that you must find someone with a network card for each driver you patch and have them ensure that the changes do not cause any problems. Then send the patches to me, and I'll get them committed. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jun 28 10:48:15 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5951F37B400 for ; Fri, 28 Jun 2002 10:48:11 -0700 (PDT) Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 129A443E0A for ; Fri, 28 Jun 2002 10:48:11 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g5SHm3160920; Fri, 28 Jun 2002 10:48:03 -0700 (PDT) (envelope-from rizzo) Date: Fri, 28 Jun 2002 10:48:03 -0700 From: Luigi Rizzo To: Mike Silbersack Cc: net@FreeBSD.ORG Subject: Re: Junior Kernel hacker task? Re: interface stalling on tx ? Message-ID: <20020628104803.B60755@iguana.icir.org> References: <20020628005253.B55603@iguana.icir.org> <20020628124055.L72733-100000@patrocles.silby.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020628124055.L72733-100000@patrocles.silby.com>; from silby@silby.com on Fri, Jun 28, 2002 at 12:45:30PM -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, Jun 28, 2002 at 12:45:30PM -0500, Mike Silbersack wrote: ... > I think that it would probably be easier to go and fix many of the network > drivers than to abstract the watchdog timer more. probably agreed. The changes to the individual drivers are not large, and a bit of auditing might be necessary because sometimes there are also race conditions involved in setting/clearing the timer. At this point i believe the "one card at a time" approach is the most productive one. A remark is that as time goes on, boxes become faster and faster, and they tend to trigger a lot of performance or timing bugs in the systems with which we have lived happily for ages. cheers luigi ----------------------------------+----------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone: (510) 666 2927 ----------------------------------+----------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jun 28 21:53:48 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D083F37B401 for ; Fri, 28 Jun 2002 21:53:43 -0700 (PDT) Received: from brainlink.com (mail.brainlink.com [66.228.0.129]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3810243E09 for ; Fri, 28 Jun 2002 21:53:43 -0700 (PDT) (envelope-from anthonyv@brainlink.com) Received: from [24.189.7.159] (account anthonyv HELO brainlink.com) by brainlink.com (CommuniGate Pro SMTP 3.5.3) with ESMTP id 14329573 for freebsd-net@freebsd.org; Sat, 29 Jun 2002 00:43:05 -0400 Message-ID: <3D1D3D4D.30202@brainlink.com> Date: Sat, 29 Jun 2002 00:53:33 -0400 From: Anthony Volodkin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1a) Gecko/20020612 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: ipfw/dummynet suggestion References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Check out ethfw - http://www.bsdshell.net/hut_ethfw.html It sort of works. Julian Elischer wrote: >there is a hack to allow MAC filtering somewhere. >Possibly connected with luigi's Bridging code. > > >thre is also an ipfw node for netgraph floating around somewhere. > > >On Fri, 28 Jun 2002, Ken Ebling wrote: > > > >>I know this isn't performed at the ip level, but I think a useful addition to ipfw would be to allow filtering by mac addresses. I think a lot of people would find it useful, and a lot of linux users I try and ``convert'' to FreeBSD say they require this feature too. >> >>Ken Ebling >> >> >> > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-hackers" in the body of the message > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jun 29 4:55:54 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 59BAA37B401 for ; Sat, 29 Jun 2002 04:55:27 -0700 (PDT) Received: from soho1.binc.net (soho1.binc.net [64.73.16.3]) by mx1.FreeBSD.org (Postfix) with SMTP id B74F543E39 for ; Sat, 29 Jun 2002 04:55:21 -0700 (PDT) (envelope-from rob@the-rob.com) Received: (qmail 5456 invoked from network); 29 Jun 2002 11:48:35 -0000 Received: from localhost (HELO the-rob.com) ([127.0.0.1]) (envelope-sender ) by localhost (qmail-ldap-1.03) with SMTP for ; 29 Jun 2002 11:48:35 -0000 Received: from 216.170.185.17 (SquirrelMail authenticated user rob@the-rob.com) by www.soho.berbee.com with HTTP; Sat, 29 Jun 2002 06:48:35 -0500 (CDT) Message-ID: <3285.216.170.185.17.1025351315.squirrel@www.soho.berbee.com> Date: Sat, 29 Jun 2002 06:48:35 -0500 (CDT) Subject: Re: SOLVED! PPPoE Broken (4.6-Stable) From: To: Cc: X-Mailer: SquirrelMail (version 1.2.0 [cvs]) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Thanks for the response Mike, but pppoe still seems to be broken. Disableing vjcomp didn't seem to work for me. I tried it with enable vjcomp disable vjcomp in my ppp.conf file. Didn't seem to help. I did get Brian Somer's fix to /usr/src/sys/netgraph/ng_pppoe.c This didn't seem to help either, though all the ^K^H and all the other mumbo jumbo that was in log files. Below I've inclued 1) current tcpdumps 2) logs from the tcpdump and 3) logs from the night before when I was connected. I still seem to be able to connect up for 24 hours then go down for 3-36 hours until I come back up. Hopefully these all help. 23:23:26.187588 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0xa5ee] LCP 20: Conf-Req(9), MRU=1492, Auth-Prot PAP, Magic-Num=a5f34be4 23:23:28.189353 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0xa5ee] LCP 20: Conf-Req(10), MRU=1492, Auth-Prot PAP, Magic-Num=a5f34be4 23:23:30.189645 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8863 60: PPPoE PADT [ses 0xa5ee] 23:23:42.967392 0:4:76:b8:26:7c Broadcast 8863 32: PPPoE PADI [Host-Uniq UTF8] 23:23:44.962604 0:4:76:b8:26:7c Broadcast 8863 32: PPPoE PADI [Host-Uniq UTF8] 23:23:44.988214 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8863 75: PPPoE PADO [Host- Uniq UTF8] [Service-Name] [AC-Name "miwi-6400-inet-nrp0"] [AC-Cookie UTF8] 23:23:44.988290 0:4:76:b8:26:7c 0:2:4b:a4:b7:87 8863 75: PPPoE PADR [Host- Uniq UTF8] [AC-Cookie UTF8] [AC-Name "miwi-6400-inet-nrp0"] 23:23:45.301353 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8863 75: PPPoE PADS [ses 0xa5ef] [Host-Uniq UTF8] [AC-Cookie UTF8] [AC-Name "miwi-6400-inet-nrp0"] 23:23:45.317586 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0xa5ef] LCP 20: Conf-Req(1), MRU=1492, Auth-Prot PAP, Magic-Num=a5f3d516 23:23:47.316406 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0xa5ef] LCP 20: Conf-Req(2), MRU=1492, Auth-Prot PAP, Magic-Num=a5f3d516 23:23:48.014436 0:4:76:b8:26:7c 0:2:4b:a4:b7:87 8863 38: PPPoE PADT [ses 0xa5ef] [Generic-Error "session closed"] 23:23:49.317691 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0xa5ef] LCP 20: Conf-Req(3), MRU=1492, Auth-Prot PAP, Magic-Num=a5f3d516 23:23:51.367007 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0xa5ef] LCP 20: Conf-Req(4), MRU=1492, Auth-Prot PAP, Magic-Num=a5f3d516 23:23:53.366558 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0xa5ef] LCP 20: Conf-Req(5), MRU=1492, Auth-Prot PAP, Magic-Num=a5f3d516 23:23:55.368324 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0xa5ef] LCP 20: Conf-Req(6), MRU=1492, Auth-Prot PAP, Magic-Num=a5f3d516 23:23:57.368611 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0xa5ef] LCP 20: Conf-Req(7), MRU=1492, Auth-Prot PAP, Magic-Num=a5f3d516 23:23:59.369153 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0xa5ef] LCP 20: Conf-Req(8), MRU=1492, Auth-Prot PAP, Magic-Num=a5f3d516 23:24:01.369940 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0xa5ef] LCP 20: Conf-Req(9), MRU=1492, Auth-Prot PAP, Magic-Num=a5f3d516 23:24:03.370716 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0xa5ef] LCP 20: Conf-Req(10), MRU=1492, Auth-Prot PAP, Magic-Num=a5f3d516 23:24:05.371753 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8863 60: PPPoE PADT [ses 0xa5ef] 23:24:18.037729 0:4:76:b8:26:7c Broadcast 8863 32: PPPoE PADI [Host-Uniq UTF8] 23:24:20.033133 0:4:76:b8:26:7c Broadcast 8863 32: PPPoE PADI [Host-Uniq UTF8] 23:24:20.056497 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8863 75: PPPoE PADO [Host- Uniq UTF8] [Service-Name] [AC-Name "miwi-6400-inet-nrp0"] [AC-Cookie UTF8] 23:24:20.056576 0:4:76:b8:26:7c 0:2:4b:a4:b7:87 8863 75: PPPoE PADR [Host- Uniq UTF8] [AC-Cookie UTF8] [AC-Name "miwi-6400-inet-nrp0"] 23:24:20.361739 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8863 75: PPPoE PADS [ses 0xa5f0] [Host-Uniq UTF8] [AC-Cookie UTF8] [AC-Name "miwi-6400-inet-nrp0"] 23:24:20.390555 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0xa5f0] LCP 20: Conf-Req(1), MRU=1492, Auth-Prot PAP, Magic-Num=a5f45e0b 23:24:22.390848 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0xa5f0] LCP 20: Conf-Req(2), MRU=1492, Auth-Prot PAP, Magic-Num=a5f45e0b 23:24:23.084963 0:4:76:b8:26:7c 0:2:4b:a4:b7:87 8863 38: PPPoE PADT [ses 0xa5f0] [Generic-Error "session closed"] 23:24:24.391389 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0xa5f0] LCP 20: Conf-Req(3), MRU=1492, Auth-Prot PAP, Magic-Num=a5f45e0b 23:24:26.392672 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0xa5f0] LCP 20: Conf-Req(4), MRU=1492, Auth-Prot PAP, Magic-Num=a5f45e0b 23:24:28.392963 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0xa5f0] LCP 20: Conf-Req(5), MRU=1492, Auth-Prot PAP, Magic-Num=a5f45e0b 23:24:30.393491 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0xa5f0] LCP 20: Conf-Req(6), MRU=1492, Auth-Prot PAP, Magic-Num=a5f45e0b 23:24:32.394777 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0xa5f0] LCP 20: Conf-Req(7), MRU=1492, Auth-Prot PAP, Magic-Num=a5f45e0b 23:24:34.395562 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0xa5f0] LCP 20: Conf-Req(8), MRU=1492, Auth-Prot PAP, Magic-Num=a5f45e0b 23:24:36.396095 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0xa5f0] LCP 20: Conf-Req(9), MRU=1492, Auth-Prot PAP, Magic-Num=a5f45e0b 23:24:38.396887 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0xa5f0] LCP 20: Conf-Req(10), MRU=1492, Auth-Prot PAP, Magic-Num=a5f45e0b 23:24:40.398156 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8863 60: PPPoE PADT [ses 0xa5f0] 23:24:53.108273 0:4:76:b8:26:7c Broadcast 8863 32: PPPoE PADI [Host-Uniq UTF8] 23:24:55.103662 0:4:76:b8:26:7c Broadcast 8863 32: PPPoE PADI [Host-Uniq UTF8] 23:24:55.127252 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8863 75: PPPoE PADO [Host- Uniq UTF8] [Service-Name] [AC-Name "miwi-6400-inet-nrp0"] [AC-Cookie UTF8] 23:24:55.127332 0:4:76:b8:26:7c 0:2:4b:a4:b7:87 8863 75: PPPoE PADR [Host- Uniq UTF8] [AC-Cookie UTF8] [AC-Name "miwi-6400-inet-nrp0"] 23:24:55.361542 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8863 75: PPPoE PADS [ses 0xa5f3] [Host-Uniq UTF8] [AC-Cookie UTF8] [AC-Name "miwi-6400-inet-nrp0"] 23:24:55.383459 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0xa5f3] LCP 20: Conf-Req(1), MRU=1492, Auth-Prot PAP, Magic-Num=a5f4e6b2 23:24:57.380550 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0xa5f3] LCP 20: Conf-Req(2), MRU=1492, Auth-Prot PAP, Magic-Num=a5f4e6b2 23:24:58.155467 0:4:76:b8:26:7c 0:2:4b:a4:b7:87 8863 38: PPPoE PADT [ses 0xa5f3] [Generic-Error "session closed"] 23:24:59.381338 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0xa5f3] LCP 20: Conf-Req(3), MRU=1492, Auth-Prot PAP, Magic-Num=a5f4e6b2 23:25:01.382373 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0xa5f3] LCP 20: Conf-Req(4), MRU=1492, Auth-Prot PAP, Magic-Num=a5f4e6b2 23:25:03.383152 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0xa5f3] LCP 20: Conf-Req(5), MRU=1492, Auth-Prot PAP, Magic-Num=a5f4e6b2 23:25:05.383933 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0xa5f3] LCP 20: Conf-Req(6), MRU=1492, Auth-Prot PAP, Magic-Num=a5f4e6b2 23:25:07.384467 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0xa5f3] LCP 20: Conf-Req(7), MRU=1492, Auth-Prot PAP, Magic-Num=a5f4e6b2 23:25:09.385751 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0xa5f3] LCP 20: Conf-Req(8), MRU=1492, Auth-Prot PAP, Magic-Num=a5f4e6b2 23:25:11.386574 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0xa5f3] LCP 20: Conf-Req(9), MRU=1492, Auth-Prot PAP, Magic-Num=a5f4e6b2 23:25:13.387060 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0xa5f3] LCP 20: Conf-Req(10), MRU=1492, Auth-Prot PAP, Magic-Num=a5f4e6b2 23:25:15.387851 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8863 60: PPPoE PADT [ses 0xa5f3] 23:25:28.178961 0:4:76:b8:26:7c Broadcast 8863 32: PPPoE PADI [Host-Uniq UTF8] 23:25:30.174192 0:4:76:b8:26:7c Broadcast 8863 32: PPPoE PADI [Host-Uniq UTF8] 23:25:30.200953 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8863 75: PPPoE PADO [Host- Uniq UTF8] [Service-Name] [AC-Name "miwi-6400-inet-nrp0"] [AC-Cookie UTF8] 23:25:30.201033 0:4:76:b8:26:7c 0:2:4b:a4:b7:87 8863 75: PPPoE PADR [Host- Uniq UTF8] [AC-Cookie UTF8] [AC-Name "miwi-6400-inet-nrp0"] 23:25:30.459655 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8863 75: PPPoE PADS [ses 0xa5f7] [Host-Uniq UTF8] [AC-Cookie UTF8] [AC-Name "miwi-6400-inet-nrp0"] 23:25:30.477971 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0xa5f7] LCP 20: Conf-Req(1), MRU=1492, Auth-Prot PAP, Magic-Num=a5f56fc6 23:25:32.476190 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0xa5f7] LCP 20: Conf-Req(2), MRU=1492, Auth-Prot PAP, Magic-Num=a5f56fc6 23:25:33.226076 0:4:76:b8:26:7c 0:2:4b:a4:b7:87 8863 38: PPPoE PADT [ses 0xa5f7] [Generic-Error "session closed"] 23:25:34.475739 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0xa5f7] LCP 20: Conf-Req(3), MRU=1492, Auth-Prot PAP, Magic-Num=a5f56fc6 23:25:36.476523 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0xa5f7] LCP 20: Conf-Req(4), MRU=1492, Auth-Prot PAP, Magic-Num=a5f56fc6 23:25:38.477061 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0xa5f7] LCP 20: Conf-Req(5), MRU=1492, Auth-Prot PAP, Magic-Num=a5f56fc6 23:25:40.479950 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0xa5f7] LCP 20: Conf-Req(6), MRU=1492, Auth-Prot PAP, Magic-Num=a5f56fc6 23:25:42.479124 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0xa5f7] LCP 20: Conf-Req(7), MRU=1492, Auth-Prot PAP, Magic-Num=a5f56fc6 23:25:44.480388 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0xa5f7] LCP 20: Conf-Req(8), MRU=1492, Auth-Prot PAP, Magic-Num=a5f56fc6 23:25:46.480447 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0xa5f7] LCP 20: Conf-Req(9), MRU=1492, Auth-Prot PAP, Magic-Num=a5f56fc6 23:25:48.514494 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0xa5f7] LCP 20: Conf-Req(10), MRU=1492, Auth-Prot PAP, Magic-Num=a5f56fc6 23:25:50.514538 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8863 60: PPPoE PADT [ses 0xa5f7] 23:26:03.249340 0:4:76:b8:26:7c Broadcast 8863 32: PPPoE PADI [Host-Uniq UTF8] 23:26:05.244722 0:4:76:b8:26:7c Broadcast 8863 32: PPPoE PADI [Host-Uniq UTF8] 23:26:05.269242 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8863 75: PPPoE PADO [Host- Uniq UTF8] [Service-Name] [AC-Name "miwi-6400-inet-nrp0"] [AC-Cookie UTF8] 23:26:05.269327 0:4:76:b8:26:7c 0:2:4b:a4:b7:87 8863 75: PPPoE PADR [Host- Uniq UTF8] [AC-Cookie UTF8] [AC-Name "miwi-6400-inet-nrp0"] 23:26:05.514386 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8863 75: PPPoE PADS [ses 0xa5fb] [Host-Uniq UTF8] [AC-Cookie UTF8] [AC-Name "miwi-6400-inet-nrp0"] 23:26:05.529923 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0xa5fb] LCP 20: Conf-Req(1), MRU=1492, Auth-Prot PAP, Magic-Num=a5f5f8af 23:26:07.529455 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0xa5fb] LCP 20: Conf-Req(2), MRU=1492, Auth-Prot PAP, Magic-Num=a5f5f8af 23:26:08.296562 0:4:76:b8:26:7c 0:2:4b:a4:b7:87 8863 38: PPPoE PADT [ses 0xa5fb] [Generic-Error "session closed"] 23:26:09.530235 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0xa5fb] LCP 20: Conf-Req(3), MRU=1492, Auth-Prot PAP, Magic-Num=a5f5f8af 23:26:11.532000 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0xa5fb] LCP 20: Conf-Req(4), MRU=1492, Auth-Prot PAP, Magic-Num=a5f5f8af 23:26:13.532046 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0xa5fb] LCP 20: Conf-Req(5), MRU=1492, Auth-Prot PAP, Magic-Num=a5f5f8af 23:26:15.532838 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0xa5fb] LCP 20: Conf-Req(6), MRU=1492, Auth-Prot PAP, Magic-Num=a5f5f8af 23:26:17.533612 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0xa5fb] LCP 20: Conf-Req(7), MRU=1492, Auth-Prot PAP, Magic-Num=a5f5f8af 23:26:19.534890 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0xa5fb] LCP 20: Conf-Req(8), MRU=1492, Auth-Prot PAP, Magic-Num=a5f5f8af 23:26:21.535432 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0xa5fb] LCP 20: Conf-Req(9), MRU=1492, Auth-Prot PAP, Magic-Num=a5f5f8af 23:26:23.536218 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0xa5fb] LCP 20: Conf-Req(10), MRU=1492, Auth-Prot PAP, Magic-Num=a5f5f8af 23:26:25.536999 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8863 60: PPPoE PADT [ses 0xa5fb] Jun 28 23:22:00 PITA ppp[72]: tun0: Phase: Received NGM_PPPOE_ACNAME (hook "miwi-6400-inet-n") Jun 28 23:22:01 PITA ppp[72]: tun0: Phase: Received NGM_PPPOE_<11> Jun 28 23:22:02 PITA ppp[72]: tun0: Phase: deflink: Disconnected! Jun 28 23:22:02 PITA ppp[72]: tun0: Phase: deflink: carrier -> hangup Jun 28 23:22:02 PITA ppp[72]: tun0: Phase: deflink: Connect time: 5 secs: 0 octets in, 0 octets out Jun 28 23:22:02 PITA ppp[72]: tun0: Phase: deflink: : 0 packets in, 0 packets out Jun 28 23:22:02 PITA ppp[72]: tun0: Phase: total 0 bytes/sec, peak 0 bytes/sec on Fri Jun 28 23:21:57 2002 Jun 28 23:22:02 PITA ppp[72]: tun0: Phase: deflink: hangup -> opening Jun 28 23:22:02 PITA ppp[72]: tun0: Phase: deflink: Enter pause (30) for redialing. Jun 28 23:22:32 PITA ppp[72]: tun0: Phase: deflink: Connected! Jun 28 23:22:32 PITA ppp[72]: tun0: Phase: deflink: opening -> dial Jun 28 23:22:32 PITA ppp[72]: tun0: Phase: deflink: dial -> carrier Jun 28 23:22:35 PITA ppp[72]: tun0: Phase: Received NGM_PPPOE_ACNAME (hook "miwi-6400-inet-n") Jun 28 23:22:36 PITA ppp[72]: tun0: Phase: Received NGM_PPPOE_<11> Jun 28 23:22:37 PITA ppp[72]: tun0: Phase: deflink: Disconnected! Jun 28 23:22:37 PITA ppp[72]: tun0: Phase: deflink: carrier -> hangup Jun 28 23:22:37 PITA ppp[72]: tun0: Phase: deflink: Connect time: 5 secs: 0 octets in, 0 octets out Jun 28 23:22:37 PITA ppp[72]: tun0: Phase: deflink: : 0 packets in, 0 packets out Jun 28 23:22:37 PITA ppp[72]: tun0: Phase: total 0 bytes/sec, peak 0 bytes/sec on Fri Jun 28 23:22:32 2002 Jun 28 23:22:37 PITA ppp[72]: tun0: Phase: deflink: hangup -> opening Jun 28 23:22:37 PITA ppp[72]: tun0: Phase: deflink: Enter pause (30) for redialing. Jun 28 23:23:07 PITA ppp[72]: tun0: Phase: deflink: Connected! Jun 28 23:23:07 PITA ppp[72]: tun0: Phase: deflink: opening -> dial Jun 28 23:23:07 PITA ppp[72]: tun0: Phase: deflink: dial -> carrier Jun 28 23:23:10 PITA ppp[72]: tun0: Phase: Received NGM_PPPOE_ACNAME (hook "miwi-6400-inet-n") Jun 28 23:23:11 PITA ppp[72]: tun0: Phase: Received NGM_PPPOE_<11> Jun 28 23:23:12 PITA ppp[72]: tun0: Phase: deflink: Disconnected! Jun 28 23:23:12 PITA ppp[72]: tun0: Phase: deflink: carrier -> hangup Jun 28 23:23:12 PITA ppp[72]: tun0: Phase: deflink: Connect time: 5 secs: 0 octets in, 0 octets out Jun 28 23:23:12 PITA ppp[72]: tun0: Phase: deflink: : 0 packets in, 0 packets out Jun 28 23:23:12 PITA ppp[72]: tun0: Phase: total 0 bytes/sec, peak 0 bytes/sec on Fri Jun 28 23:23:07 2002 Jun 28 23:23:12 PITA ppp[72]: tun0: Phase: deflink: hangup -> opening Jun 28 23:23:12 PITA ppp[72]: tun0: Phase: deflink: Enter pause (30) for redialing. Jun 28 23:23:42 PITA ppp[72]: tun0: Phase: deflink: Connected! Jun 28 23:23:42 PITA ppp[72]: tun0: Phase: deflink: opening -> dial Jun 28 23:23:42 PITA ppp[72]: tun0: Phase: deflink: dial -> carrier Jun 28 23:23:45 PITA ppp[72]: tun0: Phase: Received NGM_PPPOE_ACNAME (hook "miwi-6400-inet-n") Jun 28 23:23:47 PITA ppp[72]: tun0: Phase: Received NGM_PPPOE_<11> Jun 28 23:23:48 PITA ppp[72]: tun0: Phase: deflink: Disconnected! Jun 28 23:23:48 PITA ppp[72]: tun0: Phase: deflink: carrier -> hangup Jun 28 23:23:48 PITA ppp[72]: tun0: Phase: deflink: Connect time: 6 secs: 0 octets in, 0 octets out Jun 28 23:23:48 PITA ppp[72]: tun0: Phase: deflink: : 0 packets in, 0 packets out Jun 28 23:23:48 PITA ppp[72]: tun0: Phase: total 0 bytes/sec, peak 0 bytes/sec on Fri Jun 28 23:23:42 2002 Jun 28 23:23:48 PITA ppp[72]: tun0: Phase: deflink: hangup -> opening Jun 28 23:23:48 PITA ppp[72]: tun0: Phase: deflink: Enter pause (30) for redialing. Jun 28 23:24:18 PITA ppp[72]: tun0: Phase: deflink: Connected! Jun 28 23:24:18 PITA ppp[72]: tun0: Phase: deflink: opening -> dial Jun 28 23:24:18 PITA ppp[72]: tun0: Phase: deflink: dial -> carrier Jun 28 23:24:21 PITA ppp[72]: tun0: Phase: Received NGM_PPPOE_ACNAME (hook "miwi-6400-inet-n") Jun 28 23:24:22 PITA ppp[72]: tun0: Phase: Received NGM_PPPOE_<11> Jun 28 23:24:23 PITA ppp[72]: tun0: Phase: deflink: Disconnected! Jun 28 23:24:23 PITA ppp[72]: tun0: Phase: deflink: carrier -> hangup Jun 28 23:24:23 PITA ppp[72]: tun0: Phase: deflink: Connect time: 5 secs: 0 octets in, 0 octets out Jun 28 23:24:23 PITA ppp[72]: tun0: Phase: deflink: : 0 packets in, 0 packets out Jun 28 23:24:23 PITA ppp[72]: tun0: Phase: total 0 bytes/sec, peak 0 bytes/sec on Fri Jun 28 23:24:18 2002 Jun 28 23:24:23 PITA ppp[72]: tun0: Phase: deflink: hangup -> opening Jun 28 23:24:23 PITA ppp[72]: tun0: Phase: deflink: Enter pause (30) for redialing. Jun 28 23:24:53 PITA ppp[72]: tun0: Phase: deflink: Connected! Jun 28 23:24:53 PITA ppp[72]: tun0: Phase: deflink: opening -> dial Jun 28 23:24:53 PITA ppp[72]: tun0: Phase: deflink: dial -> carrier Jun 28 23:24:56 PITA ppp[72]: tun0: Phase: Received NGM_PPPOE_ACNAME (hook "miwi-6400-inet-n") Jun 28 23:24:57 PITA ppp[72]: tun0: Phase: Received NGM_PPPOE_<11> Jun 28 23:24:58 PITA ppp[72]: tun0: Phase: deflink: Disconnected! Jun 28 23:24:58 PITA ppp[72]: tun0: Phase: deflink: carrier -> hangup Jun 28 23:24:58 PITA ppp[72]: tun0: Phase: deflink: Connect time: 5 secs: 0 octets in, 0 octets out Jun 28 23:24:58 PITA ppp[72]: tun0: Phase: deflink: : 0 packets in, 0 packets out Jun 28 23:24:58 PITA ppp[72]: tun0: Phase: total 0 bytes/sec, peak 0 bytes/sec on Fri Jun 28 23:24:53 2002 Jun 28 23:24:58 PITA ppp[72]: tun0: Phase: deflink: hangup -> opening Jun 28 23:24:58 PITA ppp[72]: tun0: Phase: deflink: Enter pause (30) for redialing. Jun 28 23:25:28 PITA ppp[72]: tun0: Phase: deflink: Connected! Jun 28 23:25:28 PITA ppp[72]: tun0: Phase: deflink: opening -> dial Jun 28 23:25:28 PITA ppp[72]: tun0: Phase: deflink: dial -> carrier Jun 28 23:25:31 PITA ppp[72]: tun0: Phase: Received NGM_PPPOE_ACNAME (hook "miwi-6400-inet-n") Jun 28 23:25:32 PITA ppp[72]: tun0: Phase: Received NGM_PPPOE_<11> Jun 28 23:25:33 PITA ppp[72]: tun0: Phase: deflink: Disconnected! Jun 28 23:25:33 PITA ppp[72]: tun0: Phase: deflink: carrier -> hangup Jun 28 23:25:33 PITA ppp[72]: tun0: Phase: deflink: Connect time: 5 secs: 0 octets in, 0 octets out Jun 28 23:25:33 PITA ppp[72]: tun0: Phase: deflink: : 0 packets in, 0 packets out Jun 28 23:25:33 PITA ppp[72]: tun0: Phase: total 0 bytes/sec, peak 0 bytes/sec on Fri Jun 28 23:25:28 2002 Jun 28 23:25:33 PITA ppp[72]: tun0: Phase: deflink: hangup -> opening Jun 28 23:25:33 PITA ppp[72]: tun0: Phase: deflink: Enter pause (30) for redialing. Jun 28 23:26:03 PITA ppp[72]: tun0: Phase: deflink: Connected! Jun 28 23:26:03 PITA ppp[72]: tun0: Phase: deflink: opening -> dial Jun 28 23:26:03 PITA ppp[72]: tun0: Phase: deflink: dial -> carrier Jun 28 23:26:06 PITA ppp[72]: tun0: Phase: Received NGM_PPPOE_ACNAME (hook "miwi-6400-inet-n") Jun 28 23:26:07 PITA ppp[72]: tun0: Phase: Received NGM_PPPOE_<11> Jun 28 23:26:08 PITA ppp[72]: tun0: Phase: deflink: Disconnected! Jun 28 23:26:08 PITA ppp[72]: tun0: Phase: deflink: carrier -> hangup Jun 28 23:26:08 PITA ppp[72]: tun0: Phase: deflink: Connect time: 5 secs: 0 octets in, 0 octets out Jun 28 23:26:08 PITA ppp[72]: tun0: Phase: deflink: : 0 packets in, 0 packets out Jun 28 23:26:08 PITA ppp[72]: tun0: Phase: total 0 bytes/sec, peak 0 bytes/sec on Fri Jun 28 23:26:03 2002 Jun 28 23:26:08 PITA ppp[72]: tun0: Phase: deflink: hangup -> opening Jun 28 23:26:08 PITA ppp[72]: tun0: Phase: deflink: Enter pause (30) for redialing. Jun 28 23:26:38 PITA ppp[72]: tun0: Phase: deflink: Connected! Jun 28 23:26:38 PITA ppp[72]: tun0: Phase: deflink: opening -> dial Jun 28 23:26:38 PITA ppp[72]: tun0: Phase: deflink: dial -> carrier Jun 28 23:26:41 PITA ppp[72]: tun0: Phase: Received NGM_PPPOE_ACNAME (hook "miwi-6400-inet-n") Jun 28 23:22:00 PITA ppp[72]: tun0: Phase: Received NGM_PPPOE_ACNAME (hook "miwi-6400-inet-n") Jun 28 23:22:01 PITA ppp[72]: tun0: Phase: Received NGM_PPPOE_<11> Jun 28 23:22:02 PITA ppp[72]: tun0: Phase: deflink: Disconnected! Jun 28 23:22:02 PITA ppp[72]: tun0: Phase: deflink: carrier -> hangup Jun 28 23:22:02 PITA ppp[72]: tun0: Phase: deflink: Connect time: 5 secs: 0 octets in, 0 octets out Jun 28 23:22:02 PITA ppp[72]: tun0: Phase: deflink: : 0 packets in, 0 packets out Jun 28 23:22:02 PITA ppp[72]: tun0: Phase: total 0 bytes/sec, peak 0 bytes/sec on Fri Jun 28 23:21:57 2002 Jun 28 23:22:02 PITA ppp[72]: tun0: Phase: deflink: hangup -> opening Jun 28 23:22:02 PITA ppp[72]: tun0: Phase: deflink: Enter pause (30) for redialing. Jun 28 23:22:32 PITA ppp[72]: tun0: Phase: deflink: Connected! Jun 28 23:22:32 PITA ppp[72]: tun0: Phase: deflink: opening -> dial Jun 28 23:22:32 PITA ppp[72]: tun0: Phase: deflink: dial -> carrier Jun 28 23:22:35 PITA ppp[72]: tun0: Phase: Received NGM_PPPOE_ACNAME (hook "miwi-6400-inet-n") Jun 28 23:22:36 PITA ppp[72]: tun0: Phase: Received NGM_PPPOE_<11> Jun 28 23:22:37 PITA ppp[72]: tun0: Phase: deflink: Disconnected! Jun 28 23:22:37 PITA ppp[72]: tun0: Phase: deflink: carrier -> hangup Jun 28 23:22:37 PITA ppp[72]: tun0: Phase: deflink: Connect time: 5 secs: 0 octets in, 0 octets out Jun 28 23:22:37 PITA ppp[72]: tun0: Phase: deflink: : 0 packets in, 0 packets out Jun 28 23:22:37 PITA ppp[72]: tun0: Phase: total 0 bytes/sec, peak 0 bytes/sec on Fri Jun 28 23:22:32 2002 Jun 28 23:22:37 PITA ppp[72]: tun0: Phase: deflink: hangup -> opening Jun 28 23:22:37 PITA ppp[72]: tun0: Phase: deflink: Enter pause (30) for redialing. Jun 28 23:23:07 PITA ppp[72]: tun0: Phase: deflink: Connected! Jun 28 23:23:07 PITA ppp[72]: tun0: Phase: deflink: opening -> dial Jun 28 23:23:07 PITA ppp[72]: tun0: Phase: deflink: dial -> carrier Jun 28 23:23:10 PITA ppp[72]: tun0: Phase: Received NGM_PPPOE_ACNAME (hook "miwi-6400-inet-n") Jun 28 23:23:11 PITA ppp[72]: tun0: Phase: Received NGM_PPPOE_<11> Jun 28 23:23:12 PITA ppp[72]: tun0: Phase: deflink: Disconnected! Jun 28 23:23:12 PITA ppp[72]: tun0: Phase: deflink: carrier -> hangup Jun 28 23:23:12 PITA ppp[72]: tun0: Phase: deflink: Connect time: 5 secs: 0 octets in, 0 octets out Jun 28 23:23:12 PITA ppp[72]: tun0: Phase: deflink: : 0 packets in, 0 packets out Jun 28 23:23:12 PITA ppp[72]: tun0: Phase: total 0 bytes/sec, peak 0 bytes/sec on Fri Jun 28 23:23:07 2002 Jun 28 23:23:12 PITA ppp[72]: tun0: Phase: deflink: hangup -> opening Jun 28 23:23:12 PITA ppp[72]: tun0: Phase: deflink: Enter pause (30) for redialing. Jun 28 23:23:42 PITA ppp[72]: tun0: Phase: deflink: Connected! Jun 28 23:23:42 PITA ppp[72]: tun0: Phase: deflink: opening -> dial Jun 28 23:23:42 PITA ppp[72]: tun0: Phase: deflink: dial -> carrier Jun 28 23:23:45 PITA ppp[72]: tun0: Phase: Received NGM_PPPOE_ACNAME (hook "miwi-6400-inet-n") Jun 28 23:23:47 PITA ppp[72]: tun0: Phase: Received NGM_PPPOE_<11> Jun 28 23:23:48 PITA ppp[72]: tun0: Phase: deflink: Disconnected! Jun 28 23:23:48 PITA ppp[72]: tun0: Phase: deflink: carrier -> hangup Jun 28 23:23:48 PITA ppp[72]: tun0: Phase: deflink: Connect time: 6 secs: 0 octets in, 0 octets out Jun 28 23:23:48 PITA ppp[72]: tun0: Phase: deflink: : 0 packets in, 0 packets out Jun 28 23:23:48 PITA ppp[72]: tun0: Phase: total 0 bytes/sec, peak 0 bytes/sec on Fri Jun 28 23:23:42 2002 Jun 28 23:23:48 PITA ppp[72]: tun0: Phase: deflink: hangup -> opening Jun 28 23:23:48 PITA ppp[72]: tun0: Phase: deflink: Enter pause (30) for redialing. Jun 28 23:24:18 PITA ppp[72]: tun0: Phase: deflink: Connected! Jun 28 23:24:18 PITA ppp[72]: tun0: Phase: deflink: opening -> dial Jun 28 23:24:18 PITA ppp[72]: tun0: Phase: deflink: dial -> carrier Jun 28 23:24:21 PITA ppp[72]: tun0: Phase: Received NGM_PPPOE_ACNAME (hook "miwi-6400-inet-n") Jun 28 23:24:22 PITA ppp[72]: tun0: Phase: Received NGM_PPPOE_<11> Jun 28 23:24:23 PITA ppp[72]: tun0: Phase: deflink: Disconnected! Jun 28 23:24:23 PITA ppp[72]: tun0: Phase: deflink: carrier -> hangup Jun 28 23:24:23 PITA ppp[72]: tun0: Phase: deflink: Connect time: 5 secs: 0 octets in, 0 octets out Jun 28 23:24:23 PITA ppp[72]: tun0: Phase: deflink: : 0 packets in, 0 packets out Jun 28 23:24:23 PITA ppp[72]: tun0: Phase: total 0 bytes/sec, peak 0 bytes/sec on Fri Jun 28 23:24:18 2002 Jun 28 23:24:23 PITA ppp[72]: tun0: Phase: deflink: hangup -> opening Jun 28 23:24:23 PITA ppp[72]: tun0: Phase: deflink: Enter pause (30) for redialing. Jun 28 23:24:53 PITA ppp[72]: tun0: Phase: deflink: Connected! Jun 28 23:24:53 PITA ppp[72]: tun0: Phase: deflink: opening -> dial Jun 28 23:24:53 PITA ppp[72]: tun0: Phase: deflink: dial -> carrier Jun 28 23:24:56 PITA ppp[72]: tun0: Phase: Received NGM_PPPOE_ACNAME (hook "miwi-6400-inet-n") Jun 28 23:24:57 PITA ppp[72]: tun0: Phase: Received NGM_PPPOE_<11> Jun 28 23:24:58 PITA ppp[72]: tun0: Phase: deflink: Disconnected! Jun 28 23:24:58 PITA ppp[72]: tun0: Phase: deflink: carrier -> hangup Jun 28 23:24:58 PITA ppp[72]: tun0: Phase: deflink: Connect time: 5 secs: 0 octets in, 0 octets out Jun 28 23:24:58 PITA ppp[72]: tun0: Phase: deflink: : 0 packets in, 0 packets out Jun 28 23:24:58 PITA ppp[72]: tun0: Phase: total 0 bytes/sec, peak 0 bytes/sec on Fri Jun 28 23:24:53 2002 Jun 28 23:24:58 PITA ppp[72]: tun0: Phase: deflink: hangup -> opening Jun 28 23:24:58 PITA ppp[72]: tun0: Phase: deflink: Enter pause (30) for redialing. Jun 28 23:25:28 PITA ppp[72]: tun0: Phase: deflink: Connected! Jun 28 23:25:28 PITA ppp[72]: tun0: Phase: deflink: opening -> dial Jun 28 23:25:28 PITA ppp[72]: tun0: Phase: deflink: dial -> carrier Jun 28 23:25:31 PITA ppp[72]: tun0: Phase: Received NGM_PPPOE_ACNAME (hook "miwi-6400-inet-n") Jun 28 23:25:32 PITA ppp[72]: tun0: Phase: Received NGM_PPPOE_<11> Jun 28 23:25:33 PITA ppp[72]: tun0: Phase: deflink: Disconnected! Jun 28 23:25:33 PITA ppp[72]: tun0: Phase: deflink: carrier -> hangup Jun 28 23:25:33 PITA ppp[72]: tun0: Phase: deflink: Connect time: 5 secs: 0 octets in, 0 octets out Jun 28 23:25:33 PITA ppp[72]: tun0: Phase: deflink: : 0 packets in, 0 packets out Jun 28 23:25:33 PITA ppp[72]: tun0: Phase: total 0 bytes/sec, peak 0 bytes/sec on Fri Jun 28 23:25:28 2002 Jun 28 23:25:33 PITA ppp[72]: tun0: Phase: deflink: hangup -> opening Jun 28 23:25:33 PITA ppp[72]: tun0: Phase: deflink: Enter pause (30) for redialing. Jun 28 23:26:03 PITA ppp[72]: tun0: Phase: deflink: Connected! Jun 28 23:26:03 PITA ppp[72]: tun0: Phase: deflink: opening -> dial Jun 28 23:26:03 PITA ppp[72]: tun0: Phase: deflink: dial -> carrier Jun 28 23:26:06 PITA ppp[72]: tun0: Phase: Received NGM_PPPOE_ACNAME (hook "miwi-6400-inet-n") Jun 28 23:26:07 PITA ppp[72]: tun0: Phase: Received NGM_PPPOE_<11> Jun 28 23:26:08 PITA ppp[72]: tun0: Phase: deflink: Disconnected! Jun 28 23:26:08 PITA ppp[72]: tun0: Phase: deflink: carrier -> hangup Jun 28 23:26:08 PITA ppp[72]: tun0: Phase: deflink: Connect time: 5 secs: 0 octets in, 0 octets out Jun 28 23:26:08 PITA ppp[72]: tun0: Phase: deflink: : 0 packets in, 0 packets out Jun 28 23:26:08 PITA ppp[72]: tun0: Phase: total 0 bytes/sec, peak 0 bytes/sec on Fri Jun 28 23:26:03 2002 Jun 28 23:26:08 PITA ppp[72]: tun0: Phase: deflink: hangup -> opening Jun 28 23:26:08 PITA ppp[72]: tun0: Phase: deflink: Enter pause (30) for redialing. Jun 28 23:26:38 PITA ppp[72]: tun0: Phase: deflink: Connected! Jun 28 23:26:38 PITA ppp[72]: tun0: Phase: deflink: opening -> dial Jun 28 23:26:38 PITA ppp[72]: tun0: Phase: deflink: dial -> carrier Jun 28 23:26:41 PITA ppp[72]: tun0: Phase: Received NGM_PPPOE_ACNAME (hook "miwi-6400-inet-n") To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jun 29 5:34:33 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3B84637B400 for ; Sat, 29 Jun 2002 05:34:31 -0700 (PDT) Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id E48BF43E09 for ; Sat, 29 Jun 2002 05:34:30 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g5TCYUf70567; Sat, 29 Jun 2002 05:34:30 -0700 (PDT) (envelope-from rizzo) Date: Sat, 29 Jun 2002 05:34:30 -0700 From: Luigi Rizzo To: net@freebsd.org Subject: ipflow_has ? Message-ID: <20020629053430.A70505@iguana.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, looking at the code in ip_flow.c, i notice that the hash function ipflow_hash() uses both the source and destination address as parameters, and additionally, it never considers the lower two bits of the destination addres. The code is below, IPFLOW_HASHBITS is 6: unsigned hash = tos; int idx; for (idx = 0; idx < 32; idx += IPFLOW_HASHBITS) hash += (dst.s_addr >> (32 - idx)) + (src.s_addr >> idx); return hash & (IPFLOW_HASHSIZE-1); Of course it is just an optimization, but shouldn't routing decisions be based on the dst address only ? Just using the dst address would slightly simplify the function, and especially has the potential of collapsing a lot of information in the ipflow cache -- consider the case of a router box in front of a busy web server. Comments ? cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jun 29 14:53: 8 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 31A0537B400; Sat, 29 Jun 2002 14:53:04 -0700 (PDT) Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id DA9B143E06; Sat, 29 Jun 2002 14:53:03 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g5TLr3U75658; Sat, 29 Jun 2002 14:53:03 -0700 (PDT) (envelope-from rizzo) Date: Sat, 29 Jun 2002 14:53:03 -0700 From: Luigi Rizzo To: net@freebsd.org Subject: Should we keep a cache of mbuf+cluster ready for use ? Message-ID: <20020629145303.A75543@iguana.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, during some experiments i was doing recently, i noticed that there is a significant improvement in the forwarding speed (especially at very high speeds) if we keep a small pool of mbuf+cluster ready for use. This is because most network drivers do something like this MGETHDR(m_new, M_DONTWAIT, MT_DATA); if (m_new == NULL) return(ENOBUFS); MCLGET(m_new, M_DONTWAIT); if (!(m_new->m_flags & M_EXT)) { m_freem(m_new); return(ENOBUFS); } when replenishing the receive buffers, and both macros are quite long even if there are available blocks in the free lists. We can store buffers of this form when/if they are released with some code like this: if (my_pool_count < my_pool_max && m->m_next == NULL && (m->m_flags & M_EXT) && M_EXT_WRITABLE(m) ) { m->m_nextpkt = my_pool; m->m_data = ->m_ext.ext_buf; m->m_len = m->m_pkthdr.len = MCLBYTES; my_pool = m; my_pool_now++; } else { ... rest of m_freem() ... } and save a lot of overhead (we just need to reset m_data and m_len and m_pkthdr.len) when someone wants to allocate them. Is there interest in committing some code like this to mbuf.h and maybe uipc_mbuf*.c ? cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jun 29 15:46:18 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 86A1637B400 for ; Sat, 29 Jun 2002 15:46:16 -0700 (PDT) Received: from mta7.pltn13.pbi.net (mta7.pltn13.pbi.net [64.164.98.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4930F43E13 for ; Sat, 29 Jun 2002 15:46:16 -0700 (PDT) (envelope-from hsu@FreeBSD.org) Received: from FreeBSD.org ([63.193.112.125]) by mta7.pltn13.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GYH00JJBOL3HO@mta7.pltn13.pbi.net> for net@freebsd.org; Sat, 29 Jun 2002 15:46:16 -0700 (PDT) Date: Sat, 29 Jun 2002 15:46:31 -0700 From: Jeffrey Hsu Subject: Re: Should we keep a cache of mbuf+cluster ready for use ? In-reply-to: "Your message of Sat, 29 Jun 2002 14:53:03 PDT." <20020629145303.A75543@iguana.icir.org> To: Luigi Rizzo Cc: net@freebsd.org Message-id: <0GYH00JJCOL3HO@mta7.pltn13.pbi.net> MIME-version: 1.0 X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org So, what you want is something like a MGETHCL(m, how, type) MHCLFREE(m) interface which first looks in a combined freelist before the individual mbuf and cluster freelists. I think it's a good idea. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jun 29 16: 9: 1 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DE99637B400; Sat, 29 Jun 2002 16:08:55 -0700 (PDT) Received: from angelica.unixdaemons.com (angelica.unixdaemons.com [209.148.64.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9C06F43E1A; Sat, 29 Jun 2002 16:08:54 -0700 (PDT) (envelope-from bmilekic@angelica.unixdaemons.com) Received: from angelica.unixdaemons.com (bmilekic@localhost.unixdaemons.com [127.0.0.1]) by angelica.unixdaemons.com (8.12.4/8.12.1) with ESMTP id g5TN8j7g056291; Sat, 29 Jun 2002 19:08:45 -0400 (EDT) X-Authentication-Warning: angelica.unixdaemons.com: Host bmilekic@localhost.unixdaemons.com [127.0.0.1] claimed to be angelica.unixdaemons.com Received: (from bmilekic@localhost) by angelica.unixdaemons.com (8.12.4/8.12.1/Submit) id g5TN8iuO056285; Sat, 29 Jun 2002 19:08:44 -0400 (EDT) (envelope-from bmilekic) Date: Sat, 29 Jun 2002 19:08:44 -0400 From: Bosko Milekic To: Jeffrey Hsu Cc: Luigi Rizzo , net@FreeBSD.ORG Subject: Re: Should we keep a cache of mbuf+cluster ready for use ? Message-ID: <20020629190844.A54115@unixdaemons.com> References: <20020629145303.A75543@iguana.icir.org> <0GYH00JJCOL3HO@mta7.pltn13.pbi.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <0GYH00JJCOL3HO@mta7.pltn13.pbi.net>; from hsu@FreeBSD.ORG on Sat, Jun 29, 2002 at 03:46:31PM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sat, Jun 29, 2002 at 03:46:31PM -0700, Jeffrey Hsu wrote: > So, what you want is something like a > MGETHCL(m, how, type) > MHCLFREE(m) > interface which first looks in a combined freelist before the individual > mbuf and cluster freelists. I think it's a good idea. I would prefer to see an interface that just grabs both a cluster and an mbuf from their respective per-CPU caches (in -CURRENT) while only grabbing the lock once, if at all this is that important to you. [*] In -CURRENT right now, clusters and mbufs are allocated from different per-CPU cache lists but they _share_ per-CPU locks, therefore this is entirely do-able. Having yet another cache that holds linked cluster + mbufs would really complicate allocations. [*] Admittedly, Alfred was pushing for exactly this not long ago, but I just didn't feel like doing it because I felt that there are better things to worry about than a little unlock + relock, when we're just dropping and re-acquiring the exact same lock, I don't see it as too big of a deal. However, I'm really not sure as to how smart architectures like Intel are with bus-locked instructions and data cache use. If they're stupid about it (i.e., if they don't look at caches during a bus-locked cycle), then it could be worth it to avoid that extra unlock/relock between allocations. If they're fairly smart about it, it's really not worth it. Also, I should mention that in his original message, Luigi mentions that MGETHDR and MCLGET are rather long macros, but in -CURRENT they are functions so there is not really much added code cache pollution. Regards, -- Bosko Milekic bmilekic@unixdaemons.com bmilekic@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jun 29 16:11:26 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 12AB437B400; Sat, 29 Jun 2002 16:11:22 -0700 (PDT) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id BDA1C43E1F; Sat, 29 Jun 2002 16:11:20 -0700 (PDT) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 97FB4AE25A; Sat, 29 Jun 2002 16:11:20 -0700 (PDT) Date: Sat, 29 Jun 2002 16:11:20 -0700 From: Alfred Perlstein To: Bosko Milekic Cc: Jeffrey Hsu , Luigi Rizzo , net@FreeBSD.ORG Subject: Re: Should we keep a cache of mbuf+cluster ready for use ? Message-ID: <20020629231120.GO97638@elvis.mu.org> References: <20020629145303.A75543@iguana.icir.org> <0GYH00JJCOL3HO@mta7.pltn13.pbi.net> <20020629190844.A54115@unixdaemons.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020629190844.A54115@unixdaemons.com> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org * Bosko Milekic [020629 16:09] wrote: > > On Sat, Jun 29, 2002 at 03:46:31PM -0700, Jeffrey Hsu wrote: > > So, what you want is something like a > > MGETHCL(m, how, type) > > MHCLFREE(m) > > interface which first looks in a combined freelist before the individual > > mbuf and cluster freelists. I think it's a good idea. > > I would prefer to see an interface that just grabs both a cluster and > an mbuf from their respective per-CPU caches (in -CURRENT) while only > grabbing the lock once, if at all this is that important to you. [*] > > In -CURRENT right now, clusters and mbufs are allocated from > different per-CPU cache lists but they _share_ per-CPU > locks, therefore this is entirely do-able. Having yet another cache > that holds linked cluster + mbufs would really complicate allocations. > > [*] Admittedly, Alfred was pushing for exactly this not long ago, but > I just didn't feel like doing it because I felt that there are better > things to worry about than a little unlock + relock, when we're just > dropping and re-acquiring the exact same lock, I don't see it as too > big of a deal. However, I'm really not sure as to how smart > architectures like Intel are with bus-locked instructions and data > cache use. If they're stupid about it (i.e., if they don't look at > caches during a bus-locked cycle), then it could be worth it to avoid > that extra unlock/relock between allocations. If they're fairly smart > about it, it's really not worth it. > > Also, I should mention that in his original message, Luigi mentions > that MGETHDR and MCLGET are rather long macros, but in -CURRENT they > are functions so there is not really much added code cache pollution. Heh... :) If the pool is per-device-softc then it doesn't need locks and will be a lot more efficient than even grabbing from the per cpu pool. Also, (/me does a little dance) TOLD YOU SO ABOUT THE ALLOCATION CODE! hah! :) -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jun 29 16:29:44 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4C4E637B400; Sat, 29 Jun 2002 16:29:39 -0700 (PDT) Received: from angelica.unixdaemons.com (angelica.unixdaemons.com [209.148.64.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id 98EA143E0A; Sat, 29 Jun 2002 16:29:38 -0700 (PDT) (envelope-from bmilekic@angelica.unixdaemons.com) Received: from angelica.unixdaemons.com (bmilekic@localhost.unixdaemons.com [127.0.0.1]) by angelica.unixdaemons.com (8.12.4/8.12.1) with ESMTP id g5TNTT7g059369; Sat, 29 Jun 2002 19:29:29 -0400 (EDT) X-Authentication-Warning: angelica.unixdaemons.com: Host bmilekic@localhost.unixdaemons.com [127.0.0.1] claimed to be angelica.unixdaemons.com Received: (from bmilekic@localhost) by angelica.unixdaemons.com (8.12.4/8.12.1/Submit) id g5TNTTtW059368; Sat, 29 Jun 2002 19:29:29 -0400 (EDT) (envelope-from bmilekic) Date: Sat, 29 Jun 2002 19:29:29 -0400 From: Bosko Milekic To: Alfred Perlstein Cc: Jeffrey Hsu , Luigi Rizzo , net@FreeBSD.ORG Subject: Re: Should we keep a cache of mbuf+cluster ready for use ? Message-ID: <20020629192929.A58120@unixdaemons.com> References: <20020629145303.A75543@iguana.icir.org> <0GYH00JJCOL3HO@mta7.pltn13.pbi.net> <20020629190844.A54115@unixdaemons.com> <20020629231120.GO97638@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020629231120.GO97638@elvis.mu.org>; from bright@mu.org on Sat, Jun 29, 2002 at 04:11:20PM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sat, Jun 29, 2002 at 04:11:20PM -0700, Alfred Perlstein wrote: > If the pool is per-device-softc then it doesn't need locks and will > be a lot more efficient than even grabbing from the per cpu pool. We have an allocator that does per-CPU allocations, we don't need to add additional layers of caches on top of that. The only thing you would save would be avoiding having to lock and unlock a cache. Since the lock is a per-CPU lock (because the caches are per-CPU), the contention on it is very low unless, of course, you get pre-empted somewhere during the allocation and then migrate CPUs; but this is not that likely to happen, really (not right now, anyway). > Also, (/me does a little dance) TOLD YOU SO ABOUT THE ALLOCATION CODE! Huh? If you're referring to the grouped mbuf + cluster allocation interface, I haven't yet admitted that it is worth it. I specifically said that it depends on how the architecture deals with bus-locked instructions and cache use. In other words, it depends on how expensive a unlock+relock operation is when we're dealing with the same lock. If we're allowed to go to the cache during the bus-locked unlock+relock ops, then we should be getting cache hits so strictly speaking, them being there is not such a big deal. But again, I have no idea what happens with cache interactions during a bus-locked instruction. > hah! :) > > -- > -Alfred Perlstein [alfred@freebsd.org] > 'Instead of asking why a piece of software is using "1970s technology," > start asking why software is ignoring 30 years of accumulated wisdom.' > Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > -- Bosko Milekic bmilekic@unixdaemons.com bmilekic@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jun 29 17: 0:18 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8C9B537B400; Sat, 29 Jun 2002 17:00:13 -0700 (PDT) Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id E9E2E43E09; Sat, 29 Jun 2002 17:00:12 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020630000012.ONM9178.rwcrmhc51.attbi.com@InterJet.elischer.org>; Sun, 30 Jun 2002 00:00:12 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id QAA81918; Sat, 29 Jun 2002 16:42:51 -0700 (PDT) Date: Sat, 29 Jun 2002 16:42:49 -0700 (PDT) From: Julian Elischer To: Bosko Milekic Cc: Alfred Perlstein , Jeffrey Hsu , Luigi Rizzo , net@FreeBSD.ORG Subject: Re: Should we keep a cache of mbuf+cluster ready for use ? In-Reply-To: <20020629192929.A58120@unixdaemons.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I'd say yes. you could let uma hold them for you as it has support for 'constructors and destructors' for types you ask it to manage. it will call the constructor whenever it needs to create a new one and teh destructor when it gives that memeory back to the system. In between the two operations, the memory is type-stable, so you can have it allocate arbitrarily complicated objects. I'm allocating thread structures, which have KVM mapped kernel stacks hanging off them. So what UMA is handing me is not a simple mamory object but a structure, which owns a vm object and anothermamory range linked to it. (including the PCB). there is no reason uma cannot and you a mbuf wit a cluster already on it.. Julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jun 29 18:50: 9 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 49BB837B400 for ; Sat, 29 Jun 2002 18:50:06 -0700 (PDT) Received: from mta7.pltn13.pbi.net (mta7.pltn13.pbi.net [64.164.98.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B07343E09 for ; Sat, 29 Jun 2002 18:50:06 -0700 (PDT) (envelope-from hsu@FreeBSD.org) Received: from FreeBSD.org ([63.193.112.125]) by mta7.pltn13.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GYH00JFHX3HKD@mta7.pltn13.pbi.net> for net@freebsd.org; Sat, 29 Jun 2002 18:50:05 -0700 (PDT) Date: Sat, 29 Jun 2002 18:50:24 -0700 From: Jeffrey Hsu Subject: Re: Should we keep a cache of mbuf+cluster ready for use ? In-reply-to: "Your message of Sat, 29 Jun 2002 19:08:44 EDT." <20020629190844.A54115@unixdaemons.com> To: Bosko Milekic Cc: net@freebsd.org Message-id: <0GYH00JFIX3HKD@mta7.pltn13.pbi.net> MIME-version: 1.0 X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > > So, what you want is something like a > > MGETHCL(m, how, type) > > MHCLFREE(m) > > interface which first looks in a combined freelist before the individual > > mbuf and cluster freelists. I think it's a good idea. > > I would prefer to see an interface that just grabs both a cluster and > an mbuf from their respective per-CPU caches (in -CURRENT) while only > grabbing the lock once, if at all this is that important to you. [*] What would this interface look like? It seems to me having a grouped allocate and free interface allows for a variety of implementations: either the -stable sample implementation Luigi posted, a uma-based one in -current, or a modification of the -current mbuf allocator. The gains from each implementation may vary, but is no worse than doing the two allocations separately and returning them as a group. Jeffrey To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jun 29 20:19:36 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 40CCE37B400 for ; Sat, 29 Jun 2002 20:19:32 -0700 (PDT) Received: from prism.flugsvamp.com (66-191-112-47.mad.wi.charter.com [66.191.112.47]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4CD7A43E1D for ; Sat, 29 Jun 2002 20:19:31 -0700 (PDT) (envelope-from jlemon@flugsvamp.com) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.6/8.11.6) id g5U3JMg48882; Sat, 29 Jun 2002 22:19:22 -0500 (CDT) (envelope-from jlemon) Date: Sat, 29 Jun 2002 22:19:22 -0500 (CDT) From: Jonathan Lemon Message-Id: <200206300319.g5U3JMg48882@prism.flugsvamp.com> To: bmilekic@unixdaemons.com, net@freebsd.org Subject: Re: Should we keep a cache of mbuf+cluster ready for use ? X-Newsgroups: local.mail.freebsd-net In-Reply-To: References: Organization: Cc: Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In article you write: > >On Sat, Jun 29, 2002 at 03:46:31PM -0700, Jeffrey Hsu wrote: >> So, what you want is something like a >> MGETHCL(m, how, type) >> MHCLFREE(m) >> interface which first looks in a combined freelist before the individual >> mbuf and cluster freelists. I think it's a good idea. > > I would prefer to see an interface that just grabs both a cluster and > an mbuf from their respective per-CPU caches (in -CURRENT) while only > grabbing the lock once, if at all this is that important to you. [*] I'd agree with bosko. I don't think that a per-softc pool of mbuf+clusters is the way to go, this should be the function of the uma allocator. I'm agnostic as to whether a preconstructed mbuf+cluster pool is a useful construct or not. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jun 29 23: 9:33 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2821437B400; Sat, 29 Jun 2002 23:09:30 -0700 (PDT) Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id D25D843E09; Sat, 29 Jun 2002 23:09:29 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g5U69Rw78773; Sat, 29 Jun 2002 23:09:27 -0700 (PDT) (envelope-from rizzo) Date: Sat, 29 Jun 2002 23:09:27 -0700 From: Luigi Rizzo To: Bosko Milekic Cc: Jeffrey Hsu , net@FreeBSD.ORG Subject: Re: Should we keep a cache of mbuf+cluster ready for use ? Message-ID: <20020629230927.A78684@iguana.icir.org> References: <20020629145303.A75543@iguana.icir.org> <0GYH00JJCOL3HO@mta7.pltn13.pbi.net> <20020629190844.A54115@unixdaemons.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020629190844.A54115@unixdaemons.com>; from bmilekic@unixdaemons.com on Sat, Jun 29, 2002 at 07:08:44PM -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sat, Jun 29, 2002 at 07:08:44PM -0400, Bosko Milekic wrote: ... > I would prefer to see an interface that just grabs both a cluster and > an mbuf from their respective per-CPU caches (in -CURRENT) while only > grabbing the lock once, if at all this is that important to you. [*] I have to say i did the tests on a -stable uniprocessor box, so the locking costs are almost negligible there, and all the gain that i measured comes from not having to do the bookkeeping. On -current, I have no idea. But i wonder, which CPU gets to serve the interrupt handler (or equivalently, the polling loop) ? Is it picked up at random, or it is statically assigned to devices or irq lines or what ? Because the per-CPU allocation may or may not be a good idea depending on the above -- e.g. if the receiving and transmitting interrupt handler end up on different CPUs then the cache becomes totally useless (and i am not mentioning those clusters freed in the protocol stack because that still runs under Giant and it will take a while before it can be parallelised). cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jun 29 23:15:10 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2914D37B400 for ; Sat, 29 Jun 2002 23:15:02 -0700 (PDT) Received: from brainlink.com (mail.brainlink.com [66.228.0.129]) by mx1.FreeBSD.org (Postfix) with ESMTP id 59B5643E13 for ; Sat, 29 Jun 2002 23:15:01 -0700 (PDT) (envelope-from anthonyv@brainlink.com) Received: from [24.189.7.159] (account anthonyv HELO brainlink.com) by brainlink.com (CommuniGate Pro SMTP 3.5.3) with ESMTP id 14342367 for freebsd-net@freebsd.org; Sun, 30 Jun 2002 02:04:34 -0400 Message-ID: <3D1EA1E3.3010103@brainlink.com> Date: Sun, 30 Jun 2002 02:14:59 -0400 From: Anthony Volodkin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1a) Gecko/20020612 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: problems with mpd as a pptp server Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, Julian Elischer suggested that I use mpd to setup a pptp link instead of PoPtoP (thank you) I am now having problems with mpd. I configured it as a pptp server accoring to instructions, but it never responds to requests. Furthermore, I doubt it even listens for them, because it does not appear in the output of 'sockstat' as bound to a socket (like apache, and others do). How can I get it to bind to a port and listen? I did specify my external ip in the mpd.links file. On an unrelated note, if i start mpd and run 'show link', i get the following: [pptp1:pptp1] show link Link pptp1: Configuration MRU : 1500 bytes Ctrl char map : 0x000a0000 bytes Retry timeout : 2 seconds Max redial : 0 connect attempts Bandwidth : 64000 bits/sec Latency : 2000 usec Keep-alive : every 10 secs, timeout 60 Ident string : "" Link level options Name Self Peer ---------------------------------------- pap disable deny chap enable deny acfcomp enable accept protocomp enable accept magicnum enable passive disable check-magic enable no-orig-auth disable callback disable Traffic stats: Octets input : 0 Frames input : 0 Octets output : 0 Frames output : 0 Bad protocols : 0 Runts : 0 Dup fragments : 0 Drop fragments : 0 Device specific info: mpd: caught fatal signal segv mpd: fatal error, exiting [pptp0] IPCP: Down event [pptp0] IFACE: Close event [pptp1] IPCP: Down event [pptp1] IFACE: Close event mpd: process 870 terminated I am running -STABLE built from 062802 (I can post kernel config if you want). mpd 1.8. Here is my configuration: mpd.conf: default: load client0 load client1 client0: new -i ng0 pptp0 pptp0 set ipcp ranges 192.168.1.1/32 192.168.1.101/32 set iface disable on-demand set iface enable proxy-arp set iface idle 1800 set bundle enable multilink set link yes acfcomp protocomp set link no pap chap set link enable chap set link keep-alive 10 60 set ipcp yes vjcomp set ipcp dns 66.228.0.17 set bundle enable compression set ccp yes mppc set ccp yes mpp-e40 set ccp yes mpp-e128 set ccp yes mpp-stateless client1: new -i ng1 pptp1 pptp1 set ipcp ranges 192.168.1.1/32 192.168.1.102/32 set iface disable on-demand set iface enable proxy-arp set iface idle 1800 set bundle enable multilink set link yes acfcomp protocomp set link no pap chap set link enable chap set link keep-alive 10 60 set ipcp yes vjcomp set ipcp dns 66.228.0.17 set bundle enable compression set ccp yes mppc set ccp yes mpp-e40 set ccp yes mpp-e128 set ccp yes mpp-stateless --------------------- mpd.links: pptp: set link type pptp set pptp self 24.152.7.133 set pptp enable incoming set pptp disable originate -- Anthony Volodkin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jun 30 0: 1:19 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5484837B405 for ; Sun, 30 Jun 2002 00:00:34 -0700 (PDT) Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id E396E43E2F for ; Sun, 30 Jun 2002 00:00:33 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020630070033.HNJF9178.rwcrmhc51.attbi.com@InterJet.elischer.org>; Sun, 30 Jun 2002 07:00:33 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id XAA83610; Sat, 29 Jun 2002 23:49:18 -0700 (PDT) Date: Sat, 29 Jun 2002 23:49:16 -0700 (PDT) From: Julian Elischer To: Anthony Volodkin Cc: freebsd-net@freebsd.org Subject: Re: problems with mpd as a pptp server In-Reply-To: <3D1EA1E3.3010103@brainlink.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sun, 30 Jun 2002, Anthony Volodkin wrote: > Hi, > > Julian Elischer suggested that I use mpd to setup a pptp link instead of > PoPtoP (thank you) > I am now having problems with mpd. I configured it as a pptp server > accoring to instructions, but it never responds to requests. > Furthermore, I doubt it even listens for them, because it does not > appear in the output of 'sockstat' as bound to a socket (like apache, > and others do). How can I get it to bind to a port and listen? I did > specify my external ip in the mpd.links file. On an unrelated note, if i > start mpd and run 'show link', i get the following: mpd uses netgraph to do all it's protocoll work. the sockets therefore cannot be assigned to a process and don't show up in sockstat. in 4.x I think it loads all teh modules it needs but you should do a 'ngctl types' after running it to see that they are loaded properl. > > [pptp1:pptp1] show link > Link pptp1: > Configuration > MRU : 1500 bytes > Ctrl char map : 0x000a0000 bytes > Retry timeout : 2 seconds > Max redial : 0 connect attempts > Bandwidth : 64000 bits/sec > Latency : 2000 usec > Keep-alive : every 10 secs, timeout 60 > Ident string : "" > Link level options > Name Self Peer > ---------------------------------------- > pap disable deny > chap enable deny > acfcomp enable accept > protocomp enable accept > magicnum enable > passive disable > check-magic enable > no-orig-auth disable > callback disable > Traffic stats: > Octets input : 0 > Frames input : 0 > Octets output : 0 > Frames output : 0 > Bad protocols : 0 > Runts : 0 > Dup fragments : 0 > Drop fragments : 0 > Device specific info: > mpd: caught fatal signal segv > mpd: fatal error, exiting > [pptp0] IPCP: Down event > [pptp0] IFACE: Close event > [pptp1] IPCP: Down event > [pptp1] IFACE: Close event > mpd: process 870 terminated > > > I am running -STABLE built from 062802 (I can post kernel config if you > want). mpd 1.8. wow where did you find such an old mpd? (was it even released by archie at 1.8?) do you mean 3.8? here's my config file (altered IP addresses) ------- pptp_default: load pptp1 load pptp2 load pptp3 load pptp4 load pptp5 pptp_standard: set ipcp dns 132.232.78.2 set ipcp nbns 132.232.78.50 set iface disable on-demand set iface enable proxy-arp set iface idle 1800 set bundle disable multilink set link yes acfcomp protocomp set link no pap chap set link enable chap set link keep-alive 10 60 set ipcp yes vjcomp set bundle enable compression set ccp yes mppc set ccp yes mpp-e40 set ccp yes mpp-e128 set ccp yes mpp-stateless pptp1: new -i ng0 pptp1 pptp1 set ipcp ranges 132.232.78.1/32 132.232.78.4/32 load pptp_standard pptp2: new -i ng1 pptp2 pptp2 set ipcp ranges 132.232.78.1/32 132.232.78.5/32 load pptp_standard pptp3: new -i ng2 pptp3 pptp3 set ipcp ranges 132.232.78.1/32 132.232.78.6/32 load pptp_standard pptp4: new -i ng3 pptp4 pptp4 set ipcp ranges 132.232.78.1/32 132.232.78.7/32 load pptp_standard pptp5: new -i ng4 pptp5 pptp5 set ipcp ranges 132.232.78.1/32 132.232.78.8/32 load pptp_standard ------------ (132.232.78.x are 'internal' addresses) and mpd.links: ------ pptp1: set link type pptp set pptp self 132.218.234.250 set pptp enable incoming set pptp disable originate pptp2: set link type pptp set pptp self 132.218.234.250 set pptp enable incoming set pptp disable originate pptp3: set link type pptp set pptp self 132.218.234.250 set pptp enable incoming set pptp disable originate pptp4: set link type pptp set pptp self 132.218.234.250 set pptp enable incoming set pptp disable originate pptp5: set link type pptp set pptp self 132.218.234.250 set pptp enable incoming set pptp disable originate ------ 132.218.234.250 is the 'external routable address. > > Here is my configuration: > mpd.conf: > > default: > load client0 > load client1 > > client0: > new -i ng0 pptp0 pptp0 > set ipcp ranges 192.168.1.1/32 192.168.1.101/32 > set iface disable on-demand > set iface enable proxy-arp > set iface idle 1800 > set bundle enable multilink > set link yes acfcomp protocomp > set link no pap chap > set link enable chap > set link keep-alive 10 60 > set ipcp yes vjcomp > set ipcp dns 66.228.0.17 > set bundle enable compression > set ccp yes mppc > set ccp yes mpp-e40 > set ccp yes mpp-e128 > set ccp yes mpp-stateless > > client1: > new -i ng1 pptp1 pptp1 > set ipcp ranges 192.168.1.1/32 192.168.1.102/32 > set iface disable on-demand > set iface enable proxy-arp > set iface idle 1800 > set bundle enable multilink > set link yes acfcomp protocomp > set link no pap chap > set link enable chap > set link keep-alive 10 60 > set ipcp yes vjcomp > set ipcp dns 66.228.0.17 > set bundle enable compression > set ccp yes mppc > set ccp yes mpp-e40 > set ccp yes mpp-e128 > set ccp yes mpp-stateless > --------------------- > mpd.links: > > pptp: > set link type pptp > set pptp self 24.152.7.133 > set pptp enable incoming > set pptp disable originate > > > > -- > Anthony Volodkin > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message