From owner-freebsd-net Sun Dec 9 18:30:47 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail0.yrp.nttdocomo.co.jp (mail0.yrp.nttdocomo.co.jp [202.245.184.18]) by hub.freebsd.org (Postfix) with ESMTP id A73FE37B405 for ; Sun, 9 Dec 2001 18:30:44 -0800 (PST) Received: from mml.yrp.nttdocomo.co.jp (mml.yrp.nttdocomo.co.jp [172.21.48.50]) by mail0.yrp.nttdocomo.co.jp (8.9.0/YRPHUB0-8819980304) with ESMTP id LAA28424 for ; Mon, 10 Dec 2001 11:30:42 +0900 (JST) Received: from OSUGASYSWKS (osuga-syswks.mml-ad.yrp.nttdocomo.co.jp [172.21.51.242]) by mml.yrp.nttdocomo.co.jp (8.9.2/3.7W-mml-990617) with SMTP id LAA27400 for ; Mon, 10 Dec 2001 11:30:42 +0900 (JST) Message-ID: <02bc01c18122$a9d60050$f23315ac@mmlad.yrp.nttdocomo.co.jp> From: "Daikichi Osuga" To: Subject: What is TODO for SACK ? Date: Mon, 10 Dec 2001 11:30:41 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 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 hope SACK code comming into FreeBSD. What is TODO ? Can I help some work ? Our group is working to deploy useful TCP extensions for wireless networks. http://search.ietf.org/internet-drafts/draft-ietf-pilc-2.5g3g-05.txt We made Tom Henderson SACK code run on OPNET. (OPNET is commercial product network simulator. (www.opnet.com)) and fixed various bugs. so, I'm familiar with Tom Henderson SACK code. -- Daikichi Osuga Mobile Internet Laboratory NTT DoCoMo,Inc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Dec 9 19:19:59 2001 Delivered-To: freebsd-net@freebsd.org Received: from niwun.pair.com (niwun.pair.com [209.68.2.70]) by hub.freebsd.org (Postfix) with SMTP id 1ED8337B405 for ; Sun, 9 Dec 2001 19:19:56 -0800 (PST) Received: (qmail 73430 invoked by uid 3193); 10 Dec 2001 03:19:55 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 10 Dec 2001 03:19:55 -0000 Date: Sun, 9 Dec 2001 22:19:55 -0500 (EST) From: Mike Silbersack X-Sender: To: Daikichi Osuga Cc: Subject: Re: What is TODO for SACK ? In-Reply-To: <02bc01c18122$a9d60050$f23315ac@mmlad.yrp.nttdocomo.co.jp> 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, 10 Dec 2001, Daikichi Osuga wrote: > Hello > > I hope SACK code comming into FreeBSD. > What is TODO ? > Can I help some work ? > > Our group is working to deploy useful TCP extensions for wireless networks. > http://search.ietf.org/internet-drafts/draft-ietf-pilc-2.5g3g-05.txt > > We made Tom Henderson SACK code run on OPNET. > (OPNET is commercial product network simulator. (www.opnet.com)) > and fixed various bugs. > so, I'm familiar with Tom Henderson SACK code. > > -- > Daikichi Osuga > Mobile Internet Laboratory > NTT DoCoMo,Inc. There was a patch posted to -net a few months ago which imported the SACK support from OpenBSD. It needs a good looking over and testing, you should be able to find it if you look back through the archives. 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 Dec 10 3:15:31 2001 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 8FC8C37B419 for ; Mon, 10 Dec 2001 03:15:25 -0800 (PST) Received: (qmail 79601 invoked from network); 10 Dec 2001 11:15:13 -0000 Received: from unknown (HELO pipeline.ch) ([62.48.21.179]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 10 Dec 2001 11:15:13 -0000 Message-ID: <3C1498AD.E9B53A10@pipeline.ch> Date: Mon, 10 Dec 2001 12:12:45 +0100 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: net@freebsd.org, David Xu , Mike Barcroft , Leo Bicknell Subject: Re: mbuf / maxfiles / maxsockets / etc autoscaling patch References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Cool stuff and overdue for a loooong time! A few comments on the code: - IMHO it would be helpful to print the chosen values into the boot dmesg (maybe larger parts of it only with verbose). This aids explaining strange symtoms if someone adds/removes RAM and is not aware of autoscaling. "I took out 128MB of RAM and my webserver starts to fail..." Autoscaling enabled, setting values based on 64MB of usable RAM Autoscaling mproc=1024, mfiles=8192, msocket=4096, callout=9232, nmbcl=2048, nsfbuf=1024, tcphashsize=512 - I would suggest to append "MIN|MAX" to the variable instead of prepending it +#define TCBHASHPERMB 8 +#define TCBHASHAUTOMIN 512 +#define TCBHASHAUTOMAX 8192 - An update to the tuning man page describing this autoscaling is missing from this patch. -- Andre Mike Silbersack wrote: > > Here's the autoscaling patch I was mumbling about earlier this week. > With this patch applied, the necessity of tuning maxusers when one > upgrades to a machine with more ram should be removed in most cases. > (This patch is only to -current, the mbuf changes will make it not apply > cleanly to -stable patch if there is sufficient demand right now.) > > Here's a quick look at the size of various memory allocations with various > maxusers sizes and with the autoscaling patch: > > With maxusers: > > musers mproc mfiles msocket callout nmbcl nsfbuf tcp hash size > 32 532 1064 1064 1612 1024 1024 512 > 64 1044 2088 2088 3148 1536 1536 512 > 128 2068 4136 4136 6220 2560 2560 512 > 256 4116 8232 8232 12364 4608 4608 512 > > With autoscaling: > > MB ram mproc mfiles msocket callout nmbcl nsfbuf tcp hash size > 32 512 4096 2048 4624 1024 1024 512 > 64 1024 8192 4096 9232 2048 1024 512 > 128 2048 16384 8192 18448 4096 2048 1024 > 256 4096 32768 16384 36880 8192 4096 2048 > 384 6144 49152 24576 55312 12288 6144 3072 > 512 8192 65536 32767 73744 16384 8192 4096 > (Values above this start to flatten out due to #defined maximums) > > Note that in general calculations are of the following form: > > value = max(maxusers-derived value, autoscale-derived value); > value = loader tuned value if present > > As such, under no circumstances will people suddenly see a decrease in > various parameters when they upgrade to an autoscaling kernel; only > increases. > > I'm sure that there will be much commotion about what scaling factors are > correct. To make changes to these easy, I have grouped all the mins, > scaling factors, and maxes in param.h - tweaking them is quite simple. > > I included mins and maxes to make sure that autoscaling doesn't cause > problems by creating low values on small memory machines and also so that > it does not specify really high values on 2GB+ machines. The high case is > what worries me; I have not heard much about how well maxsockets / > nmbclusters > 32767 really works. If people running high volume systems > that actively use that many simultaneous sockets + clusters + files, I'd > be glad to bump up the maxes. > > Oh, there's one more kicker thrown in; I changed maxfilesperproc to equal > 9/10ths of maxfiles, and maxprocperuid to equal 9/10 maxproc; this'll help > to prevent a single process or user from forkbombing the system or running > it out of file handles with a default configuration. > > Please review. > > Thanks, > > Mike "Silby" Silbersack > > ------------------------------------------------------------------------ > Name: autoscale.patch > autoscale.patch Type: Plain Text (TEXT/PLAIN) > Encoding: BASE64 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Dec 10 3:55:46 2001 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 8209737B405 for ; Mon, 10 Dec 2001 03:55:38 -0800 (PST) Received: (qmail 84057 invoked from network); 10 Dec 2001 11:55:27 -0000 Received: from unknown (HELO pipeline.ch) ([62.48.21.179]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 10 Dec 2001 11:55:27 -0000 Message-ID: <3C14A21B.D0157030@pipeline.ch> Date: Mon, 10 Dec 2001 12:52:59 +0100 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 , net@freebsd.org, David Xu , Mike Barcroft , Leo Bicknell Subject: Re: mbuf / maxfiles / maxsockets / etc autoscaling patch References: <3C1498AD.E9B53A10@pipeline.ch> 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 Andre Oppermann wrote: > > Cool stuff and overdue for a loooong time! > > A few comments on the code: > > - IMHO it would be helpful to print the chosen values into the boot > dmesg (maybe larger parts of it only with verbose). This aids > explaining strange symtoms if someone adds/removes RAM and is not > aware of autoscaling. "I took out 128MB of RAM and my webserver > starts to fail..." > > Autoscaling enabled, setting values based on 64MB of usable RAM > Autoscaling mproc=1024, mfiles=8192, msocket=4096, callout=9232, > nmbcl=2048, nsfbuf=1024, tcphashsize=512 > > - I would suggest to append "MIN|MAX" to the variable instead of > prepending it > > +#define TCBHASHPERMB 8 > +#define TCBHASHAUTOMIN 512 > +#define TCBHASHAUTOMAX 8192 > > - An update to the tuning man page describing this autoscaling is > missing from this patch. - Only do autoscaling only if MAXUSERS=0 in kernel compile. Also change GENERIC to set MAXUSERS to null. (This is from Matt's patch) -- Andre > -- > Andre > > Mike Silbersack wrote: > > > > Here's the autoscaling patch I was mumbling about earlier this week. > > With this patch applied, the necessity of tuning maxusers when one > > upgrades to a machine with more ram should be removed in most cases. > > (This patch is only to -current, the mbuf changes will make it not apply > > cleanly to -stable patch if there is sufficient demand right now.) > > > > Here's a quick look at the size of various memory allocations with various > > maxusers sizes and with the autoscaling patch: > > > > With maxusers: > > > > musers mproc mfiles msocket callout nmbcl nsfbuf tcp hash size > > 32 532 1064 1064 1612 1024 1024 512 > > 64 1044 2088 2088 3148 1536 1536 512 > > 128 2068 4136 4136 6220 2560 2560 512 > > 256 4116 8232 8232 12364 4608 4608 512 > > > > With autoscaling: > > > > MB ram mproc mfiles msocket callout nmbcl nsfbuf tcp hash size > > 32 512 4096 2048 4624 1024 1024 512 > > 64 1024 8192 4096 9232 2048 1024 512 > > 128 2048 16384 8192 18448 4096 2048 1024 > > 256 4096 32768 16384 36880 8192 4096 2048 > > 384 6144 49152 24576 55312 12288 6144 3072 > > 512 8192 65536 32767 73744 16384 8192 4096 > > (Values above this start to flatten out due to #defined maximums) > > > > Note that in general calculations are of the following form: > > > > value = max(maxusers-derived value, autoscale-derived value); > > value = loader tuned value if present > > > > As such, under no circumstances will people suddenly see a decrease in > > various parameters when they upgrade to an autoscaling kernel; only > > increases. > > > > I'm sure that there will be much commotion about what scaling factors are > > correct. To make changes to these easy, I have grouped all the mins, > > scaling factors, and maxes in param.h - tweaking them is quite simple. > > > > I included mins and maxes to make sure that autoscaling doesn't cause > > problems by creating low values on small memory machines and also so that > > it does not specify really high values on 2GB+ machines. The high case is > > what worries me; I have not heard much about how well maxsockets / > > nmbclusters > 32767 really works. If people running high volume systems > > that actively use that many simultaneous sockets + clusters + files, I'd > > be glad to bump up the maxes. > > > > Oh, there's one more kicker thrown in; I changed maxfilesperproc to equal > > 9/10ths of maxfiles, and maxprocperuid to equal 9/10 maxproc; this'll help > > to prevent a single process or user from forkbombing the system or running > > it out of file handles with a default configuration. > > > > Please review. > > > > Thanks, > > > > Mike "Silby" Silbersack > > > > ------------------------------------------------------------------------ > > Name: autoscale.patch > > autoscale.patch Type: Plain Text (TEXT/PLAIN) > > Encoding: BASE64 > > 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 Mon Dec 10 4:58:45 2001 Delivered-To: freebsd-net@freebsd.org Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1]) by hub.freebsd.org (Postfix) with ESMTP id 5B87737B41B for ; Mon, 10 Dec 2001 04:58:40 -0800 (PST) Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1]) by yamato.ccrle.nec.de (8.11.6/8.10.1) with ESMTP id fBA98lq62259; Mon, 10 Dec 2001 10:08:47 +0100 (CET) Received: from elgar (elgar.heidelberg.ccrle.nec.de [192.168.102.180]) by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0) with ESMTP id 47B96C051; Mon, 10 Dec 2001 10:08:44 +0100 (CET) Date: Mon, 10 Dec 2001 10:08:43 +0100 From: Martin Stiemerling To: David Smithson , freebsd-net@FreeBSD.ORG Subject: Re: Gigabit for FreeBSD Message-ID: <13850000.1007975323@elgar> In-Reply-To: <4FB6DCB8FA515F49AAE50827A60D42CD862B0F@mail-01.foundation-i.com> References: <4FB6DCB8FA515F49AAE50827A60D42CD862B0F@mail-01.foundation-i.com > X-Mailer: Mulberry/2.1.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 D-LINK DGE500-SX works good! --On Freitag, Dezember 07, 2001 10:22:44 -0800 David Smithson wrote: > Hi all. Does anyone know of a good stable 1000baseTX gigabit network > adapter that works well with FreeBSD? I have this Netgear adapter that > seems to have problems. Help is -- of course -- appreciated. Thanks. > > 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 Mon Dec 10 6:15:40 2001 Delivered-To: freebsd-net@freebsd.org Received: from niwun.pair.com (niwun.pair.com [209.68.2.70]) by hub.freebsd.org (Postfix) with SMTP id 9B0F837B419 for ; Mon, 10 Dec 2001 06:15:37 -0800 (PST) Received: (qmail 32891 invoked by uid 3193); 10 Dec 2001 14:15:36 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 10 Dec 2001 14:15:36 -0000 Date: Mon, 10 Dec 2001 09:15:36 -0500 (EST) From: Mike Silbersack X-Sender: To: Andre Oppermann Cc: , David Xu , Mike Barcroft , Leo Bicknell Subject: Re: mbuf / maxfiles / maxsockets / etc autoscaling patch In-Reply-To: <3C14A21B.D0157030@pipeline.ch> 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, 10 Dec 2001, Andre Oppermann wrote: > - Only do autoscaling only if MAXUSERS=0 in kernel compile. Also > change GENERIC to set MAXUSERS to null. (This is from Matt's patch) > > -- > Andre Matt & I are working on merging the two approaches, once we've finished throwing numbers together we'll commit the merged patch. 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 Dec 10 7: 1:54 2001 Delivered-To: freebsd-net@freebsd.org Received: from luke.immure.com (luke.immure.com [207.8.42.74]) by hub.freebsd.org (Postfix) with ESMTP id D90C637B405 for ; Mon, 10 Dec 2001 07:01:49 -0800 (PST) Received: (from bob@localhost) by luke.immure.com (8.11.6/8.11.6) id fBAF0U113511; Mon, 10 Dec 2001 09:00:30 -0600 (CST) (envelope-from bob) Date: Mon, 10 Dec 2001 09:00:30 -0600 From: Bob Willcox To: Martin Stiemerling Cc: David Smithson , freebsd-net@FreeBSD.ORG Subject: Re: Gigabit for FreeBSD Message-ID: <20011210090030.A11879@luke.immure.com> Reply-To: Bob Willcox References: <4FB6DCB8FA515F49AAE50827A60D42CD862B0F@mail-01.foundation-i.com <4FB6DCB8FA515F49AAE50827A60D42CD862B0F@mail-01.foundation-i.com> <13850000.1007975323@elgar> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <13850000.1007975323@elgar>; from Martin.Stiemerling@ccrle.nec.de on Mon, Dec 10, 2001 at 10:08:43AM +0100 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 am running two FreeBSD (4.4-stable) systems here with the following GigE cards: Linksys EG1064 SMC 9462TX They both use the National Semiconductor chip and are supported by the nge driver. Both are in dual Athlon systems (Tyan S2460 MBs), connected to a Linksys EG0008 GigE switch, and are working well. I am experiencing three relatively small issues: 1. The SMC card seems to take a couple of tries to get the link up. I usually get several messages at boot time that the gigabit link is up from the driver, so it appears that it comes up put quickly drops one or more times before finally staying up (I have never seen it drop once the system is running). 2. The Linksys card appears to be about 25% slower than the SMC card. With netperf I get up to 85 MB/s with the SMC card and only 65 MB/s with the SMC. Note that the Linksys card is in the faster of the two systems (1.533 GHz CPUs vs. 1.2 GHz for the SMC card's CPUs). 3. If I statically link the driver in the kernel it disrupts my sound card. This doesn't happen if I dynamically load the driver. However, all of these are easily ignored or worked around in my environment. Bob On Mon, Dec 10, 2001 at 10:08:43AM +0100, Martin Stiemerling wrote: > D-LINK DGE500-SX works good! > > > --On Freitag, Dezember 07, 2001 10:22:44 -0800 David Smithson > wrote: > > > Hi all. Does anyone know of a good stable 1000baseTX gigabit network > > adapter that works well with FreeBSD? I have this Netgear adapter that > > seems to have problems. Help is -- of course -- appreciated. Thanks. > > > > 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 -- Bob Willcox Boucher's Observation: bob@vieo.com He who blows his own horn always plays the music Austin, TX several octaves higher than originally written. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Dec 10 9:30:46 2001 Delivered-To: freebsd-net@freebsd.org Received: from quack.kfu.com (quack.kfu.com [205.178.90.194]) by hub.freebsd.org (Postfix) with ESMTP id 9BCED37B416 for ; Mon, 10 Dec 2001 09:30:43 -0800 (PST) Received: from morpheus.kfu.com (morpheus.kfu.com [3ffe:1200:301b:1:2d0:b7ff:fe3f:bdd0]) by quack.kfu.com (8.11.6/8.11.6) with ESMTP id fBAHUWI41447 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Mon, 10 Dec 2001 09:30:38 -0800 (PST) (envelope-from nsayer@quack.kfu.com) Received: from quack.kfu.com (nospam@localhost [127.0.0.1]) by morpheus.kfu.com (8.11.6/8.11.6) with ESMTP id fBAHUWn68316 for ; Mon, 10 Dec 2001 09:30:32 -0800 (PST) (envelope-from nsayer@quack.kfu.com) Message-ID: <3C14F138.1020906@quack.kfu.com> Date: Mon, 10 Dec 2001 09:30:32 -0800 From: Nick Sayer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.6) Gecko/20011202 X-Accept-Language: en, en-US, en-GB MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: importing Kame's NATPT ? Content-Type: text/plain; charset=ISO-8859-15; 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 notice that kame has NATPT (a mechanism to let IPv6-only hosts interact with the IPv4 Internet) and that it has not been imported. I would like to see if it's possible to import just that bit of functionality as an independent unit (it gets us one step closer to killing IPv4). It appears to drop right in. The only real change in the existing code is an itty bitty chunk of stuff in ip_input() and ip6_input() that is #ifdef NATPT. Is anyone already doing this? Is there anyone I should coordinate this with? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Dec 10 10:17:20 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail-01.foundation-i.com (mail-01.foundation-i.com [206.111.21.14]) by hub.freebsd.org (Postfix) with ESMTP id 6060B37B416 for ; Mon, 10 Dec 2001 10:17:13 -0800 (PST) content-class: urn:content-classes:message Subject: RE: Gigabit for FreeBSD MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Mon, 10 Dec 2001 10:20:55 -0800 Message-ID: <4FB6DCB8FA515F49AAE50827A60D42CD862B1C@mail-01.foundation-i.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Gigabit for FreeBSD Thread-Index: AcGBjB4RI8DFUyoLRr6tgFUqrJlEZgAGsznQ From: "David Smithson" To: "Bob Willcox" 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 > I am experiencing three relatively small issues: >=20 > 1. The SMC card seems to take a couple of tries to get the link up. I > usually get several messages at boot time that the gigabit=20 > link is up > from the driver, so it appears that it comes up put=20 > quickly drops one > or more times before finally staying up (I have never seen it drop > once the system is running). >=20 I have a similar issue with the nge driver. Ocasionally I will get = repeated messages "gigabit link up" or something like that. It's not a = regular occurance though, and the link never actually comes up. I = wonder if there could be some conflict between the Netgear interface and = my Asante switch. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Dec 10 10:22: 2 2001 Delivered-To: freebsd-net@freebsd.org Received: from luke.immure.com (luke.immure.com [207.8.42.74]) by hub.freebsd.org (Postfix) with ESMTP id 6DA7637B417 for ; Mon, 10 Dec 2001 10:21:58 -0800 (PST) Received: (from bob@localhost) by luke.immure.com (8.11.6/8.11.6) id fBAILpm23516; Mon, 10 Dec 2001 12:21:51 -0600 (CST) (envelope-from bob) Date: Mon, 10 Dec 2001 12:21:51 -0600 From: Bob Willcox To: David Smithson Cc: freebsd-net@FreeBSD.ORG Subject: Re: Gigabit for FreeBSD Message-ID: <20011210122151.B20871@luke.immure.com> Reply-To: Bob Willcox References: <4FB6DCB8FA515F49AAE50827A60D42CD862B1C@mail-01.foundation-i.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4FB6DCB8FA515F49AAE50827A60D42CD862B1C@mail-01.foundation-i.com>; from david-s@foundation-i.com on Mon, Dec 10, 2001 at 10:20:55AM -0800 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, Dec 10, 2001 at 10:20:55AM -0800, David Smithson wrote: > > I am experiencing three relatively small issues: > > > > 1. The SMC card seems to take a couple of tries to get the link up. I > > usually get several messages at boot time that the gigabit > > link is up > > from the driver, so it appears that it comes up put > > quickly drops one > > or more times before finally staying up (I have never seen it drop > > once the system is running). > > > > I have a similar issue with the nge driver. Ocasionally I will get repeated messages "gigabit link up" or something like that. It's not a regular occurance though, and the link never actually comes up. I wonder if there could be some conflict between the Netgear interface and my Asante switch. Perhaps so. I get this (though the link usually does finally stay up) with both of the SMC cards that I have tried with my Linksys switch. On the other hand, my Linksys card always comes up on the first try with the Linksys switch. Unfortunately, it's also 25% slower than the SMC cards :-( Bob -- Bob Willcox Boucher's Observation: bob@vieo.com He who blows his own horn always plays the music Austin, TX several octaves higher than originally written. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Dec 10 16:40:13 2001 Delivered-To: freebsd-net@freebsd.org Received: from mta5-rme.xtra.co.nz (mta5-rme.xtra.co.nz [210.86.15.138]) by hub.freebsd.org (Postfix) with ESMTP id A2CFB37B417 for ; Mon, 10 Dec 2001 16:40:01 -0800 (PST) Received: from internet1.masaclaw.co.nz ([210.55.57.50]) by mta5-rme.xtra.co.nz with ESMTP id <20011211004000.BHKB21293.mta5-rme.xtra.co.nz@internet1.masaclaw.co.nz> for ; Tue, 11 Dec 2001 13:40:00 +1300 Message-Id: <5.1.0.14.2.20011211121120.0287ddb0@mail.masaclaw.co.nz> X-Sender: masaclaw@mail.masaclaw.co.nz X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 11 Dec 2001 13:33:53 +1300 To: freebsd-net@FreeBSD.ORG From: Tom Peck Subject: 1 IP - 1 Firewall - 2 Webservers 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 Hello We have ONE static IP with our ISP via a Cable Modem. Connected at our end of the Cable Modem is a FreeBSD Firewall / Internet Gateway for the rest of the internal Lan. On the Internal Network we have 2 Web / Mail servers which collect mail and serve HTTP requests recieved from the gateway box. INTERNET ---> GATEWAY_BOX ---> WEBSERVER_1 (www.domain1.com, bla@domain1.com) ---> WEBSERVER_2 (www.domain2.com, bla@domain2.com) ---> WORKSTATIONS We are currently using squid to forward on the HTTP requests to the web servers decided by domain requested, ie if someone goes to www.domain1.com/index.htm this request will be forwarded by Squid to the WEBSERVER_1. This has been working fine, until I decided to run some tests, and look through the apache logs on the WEBSERVER_1. ALL incoming Client IP's and Addresses are always that of the GATEWAY_BOX. This poses a problem for websites which have security on them for OUTSIDE addresses, as this security will no longer work.. Also, WebStats are going to be invalid as all requests are made from the Gateway IP. Does anybody have any solutions for this problem? Other software solutions which will fun on FreeBSD? Any help would be most appreciated - even just a "I wouldn't have a clue, e-mail this group" or something. Thanks All Tom Peck To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Dec 10 20:36:28 2001 Delivered-To: freebsd-net@freebsd.org Received: from emu.dhsnames.com (emu.dhsnames.com [63.175.98.31]) by hub.freebsd.org (Postfix) with SMTP id 7E98D37B41C for ; Mon, 10 Dec 2001 20:36:22 -0800 (PST) Received: (qmail 60697 invoked from network); 11 Dec 2001 04:34:05 -0000 Received: from aworklan001038.netvigator.com (HELO yusufg.portal2.com) (203.198.151.38) by box.dhsnames.com with SMTP; 11 Dec 2001 04:34:05 -0000 Received: (qmail 5960 invoked by uid 500); 11 Dec 2001 04:35:04 -0000 Date: Tue, 11 Dec 2001 12:35:04 +0800 From: Yusuf Goolamabbas To: freebsd-net@freebsd.org Subject: Is there a way to clear stats from netstat -i Message-ID: <20011211123504.A5909@outblaze.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.22.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 4.4-stable box netstat -i shows the number of packets and number of errors sent/received via the IPkt/Ierrs/Opkts/Oerrs fields. I would like to see if changing network cables and reset those fields shows reduction in the Ierrs/Oerrs field Is there a way to clear those flags netstat -sz doesn't seem to clear those flags and whilst netstat -iz doesn't barf on me even though the man page doesn't seem to indicate that this is a valid option Regards, Yusuf -- Yusuf Goolamabbas yusufg@outblaze.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Dec 10 21: 6:28 2001 Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id D0C8B37B417 for ; Mon, 10 Dec 2001 21:06:25 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.3/8.11.1) id fBB56Ps16331; Mon, 10 Dec 2001 21:06:25 -0800 (PST) (envelope-from rizzo) Date: Mon, 10 Dec 2001 21:06:25 -0800 From: Luigi Rizzo To: net@freebsd.org Subject: do we really need NETISR_foo == AF_foo ? Message-ID: <20011210210625.A16280@iguana.aciri.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.23i 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, for some reasons (device polling), i need to register a couple of netisr which are executed with highest and lowest priority among network soft interrupts. In other word, i would need #define NETISR_POLL 0 #define NETISR_POLLMORE 31 Now, the former is available, so no problem. The latter is already taken by NETISR_NETGRAPH, but I can still do something like what i need by modifying swi_net() (or the equivalent piece of assembly code in -stable; speaking of which, i wonder if we can replace it with a C function). However, I was wonder if it is really necessary that NETISR_foo has the same value as AF_foo, or it is possible to shift up values and fill holes to free the last bit ? cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Dec 10 21:20:23 2001 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 3A9DD37B417 for ; Mon, 10 Dec 2001 21:20:19 -0800 (PST) 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 <20011211052010.VFSE4213.rwcrmhc52.attbi.com@InterJet.elischer.org>; Tue, 11 Dec 2001 05:20:10 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id VAA02607; Mon, 10 Dec 2001 21:13:04 -0800 (PST) Date: Mon, 10 Dec 2001 21:13:03 -0800 (PST) From: Julian Elischer To: Tom Peck Cc: freebsd-net@FreeBSD.ORG Subject: Re: 1 IP - 1 Firewall - 2 Webservers In-Reply-To: <5.1.0.14.2.20011211121120.0287ddb0@mail.masaclaw.co.nz> 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 have a solution for exactlythis problem You need the patch I submitted for ipfw fwd of incoming packets about 3 weeks ago. it allows load sharing to an arbitrary number of webservers transparently I sent it to "net" and it had a subject of RFC: (something) the mail includes how to set it up.. it uses about 1% of cpu redirecting a 10Mb ethernet to 2 servers. (sorry to be vague but look it up in the archives with julian AND RFC AND ipfw in the net list.. On Tue, 11 Dec 2001, Tom Peck wrote: > Hello > > We have ONE static IP with our ISP via a Cable Modem. Connected at our end > of the Cable Modem is a FreeBSD Firewall / Internet Gateway for the rest of > the internal Lan. > > On the Internal Network we have 2 Web / Mail servers which collect mail and > serve HTTP requests recieved from the gateway box. > > INTERNET ---> GATEWAY_BOX ---> WEBSERVER_1 (www.domain1.com, bla@domain1.com) > ---> WEBSERVER_2 (www.domain2.com, bla@domain2.com) > ---> WORKSTATIONS > > > We are currently using squid to forward on the HTTP requests to the web > servers decided by domain requested, ie if someone goes to > www.domain1.com/index.htm this request will be forwarded by Squid to the > WEBSERVER_1. > > This has been working fine, until I decided to run some tests, and look > through the apache logs on the WEBSERVER_1. ALL incoming Client IP's and > Addresses are always that of the GATEWAY_BOX. This poses a problem for > websites which have security on them for OUTSIDE addresses, as this > security will no longer work.. Also, WebStats are going to be invalid as > all requests are made from the Gateway IP. > > Does anybody have any solutions for this problem? Other software solutions > which will fun on FreeBSD? Any help would be most appreciated - even just > a "I wouldn't have a clue, e-mail this group" or something. > > Thanks All > > Tom Peck > > > > 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 Mon Dec 10 21:32:48 2001 Delivered-To: freebsd-net@freebsd.org Received: from mta1-rme.xtra.co.nz (mta1-rme.xtra.co.nz [210.86.15.129]) by hub.freebsd.org (Postfix) with ESMTP id 8DB1437B417 for ; Mon, 10 Dec 2001 21:32:44 -0800 (PST) Received: from internet1.masaclaw.co.nz ([210.55.57.50]) by mta1-rme.xtra.co.nz with ESMTP id <20011211053241.RCBY28825.mta1-rme.xtra.co.nz@internet1.masaclaw.co.nz>; Tue, 11 Dec 2001 18:32:41 +1300 Message-Id: <5.1.0.14.2.20011211182526.02866228@mail.masaclaw.co.nz> X-Sender: masaclaw@mail.masaclaw.co.nz X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 11 Dec 2001 18:26:32 +1300 To: Julian Elischer , freebsd-net@FreeBSD.ORG From: Tom Peck Subject: Re: 1 IP - 1 Firewall - 2 Webservers In-Reply-To: References: <5.1.0.14.2.20011211121120.0287ddb0@mail.masaclaw.co.nz> 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 Thank-you for the reply Julian. I will get our network guru onto it and let you know the results. Tom At 21:13 10/12/2001 -0800, you wrote: >I have a solution for exactlythis problem >You need the patch I submitted for ipfw fwd of incoming packets >about 3 weeks ago. > >it allows load sharing to an arbitrary number of webservers transparently >I sent it to "net" and it had a subject of RFC: (something) > >the mail includes how to set it up.. >it uses about 1% of cpu redirecting a 10Mb ethernet to 2 servers. >(sorry to be vague but look it up in the archives with >julian AND RFC AND ipfw in the net list.. > > >On Tue, 11 Dec 2001, Tom Peck wrote: > > > Hello > > > > We have ONE static IP with our ISP via a Cable Modem. Connected at our > end > > of the Cable Modem is a FreeBSD Firewall / Internet Gateway for the > rest of > > the internal Lan. > > > > On the Internal Network we have 2 Web / Mail servers which collect mail > and > > serve HTTP requests recieved from the gateway box. > > > > INTERNET ---> GATEWAY_BOX ---> WEBSERVER_1 (www.domain1.com, > bla@domain1.com) > > ---> WEBSERVER_2 (www.domain2.com, > bla@domain2.com) > > ---> WORKSTATIONS > > > > > > We are currently using squid to forward on the HTTP requests to the web > > servers decided by domain requested, ie if someone goes to > > www.domain1.com/index.htm this request will be forwarded by Squid to the > > WEBSERVER_1. > > > > This has been working fine, until I decided to run some tests, and look > > through the apache logs on the WEBSERVER_1. ALL incoming Client IP's and > > Addresses are always that of the GATEWAY_BOX. This poses a problem for > > websites which have security on them for OUTSIDE addresses, as this > > security will no longer work.. Also, WebStats are going to be invalid as > > all requests are made from the Gateway IP. > > > > Does anybody have any solutions for this problem? Other software > solutions > > which will fun on FreeBSD? Any help would be most appreciated - even just > > a "I wouldn't have a clue, e-mail this group" or something. > > > > Thanks All > > > > Tom Peck > > > > > > > > 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 Mon Dec 10 21:57:57 2001 Delivered-To: freebsd-net@freebsd.org Received: from mailgate.rz.uni-karlsruhe.de (mailgate.rz.uni-karlsruhe.de [129.13.64.97]) by hub.freebsd.org (Postfix) with ESMTP id 2CFF037B420 for ; Mon, 10 Dec 2001 21:57:48 -0800 (PST) Received: from wn4-marvin.wn4.uni-karlsruhe.de (steele@wn4-marvin.wn4.uni-karlsruhe.de [172.20.12.211]) by mailgate.rz.uni-karlsruhe.de with smtp (Exim 3.16 #1) id 16Dfv6-0007YP-00; Tue, 11 Dec 2001 06:57:36 +0100 Received: by wn4-marvin.wn4.uni-karlsruhe.de (sSMTP sendmail emulation); Tue, 11 Dec 2001 06:57:47 +0100 Date: Tue, 11 Dec 2001 06:57:47 +0100 From: "Benedikt Schmidt" To: Julian Elischer Cc: Tom Peck , freebsd-net@FreeBSD.ORG Subject: Re: 1 IP - 1 Firewall - 2 Webservers Message-ID: <20011211055747.GA1486@wn4-marvin.wn4.uni-karlsruhe.de> References: <5.1.0.14.2.20011211121120.0287ddb0@mail.masaclaw.co.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.24i 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 wrote: > On Tue, 11 Dec 2001, Tom Peck wrote: > > We have ONE static IP with our ISP via a Cable Modem. Connected at our end > > of the Cable Modem is a FreeBSD Firewall / Internet Gateway for the rest of > > the internal Lan. > > > > On the Internal Network we have 2 Web / Mail servers which collect mail and > > serve HTTP requests recieved from the gateway box. > > > > INTERNET ---> GATEWAY_BOX ---> WEBSERVER_1 (www.domain1.com, bla@domain1.com) > > ---> WEBSERVER_2 (www.domain2.com, bla@domain2.com) > > ---> WORKSTATIONS > > > > > > We are currently using squid to forward on the HTTP requests to the web > > servers decided by domain requested, ie if someone goes to > > www.domain1.com/index.htm this request will be forwarded by Squid to the > > WEBSERVER_1. > > > > This has been working fine, until I decided to run some tests, and look > > through the apache logs on the WEBSERVER_1. ALL incoming Client IP's and > > Addresses are always that of the GATEWAY_BOX. This poses a problem for > > websites which have security on them for OUTSIDE addresses, as this > > security will no longer work.. Also, WebStats are going to be invalid as > > all requests are made from the Gateway IP. > > > > Does anybody have any solutions for this problem? Other software solutions > > which will fun on FreeBSD? Any help would be most appreciated - even just > > a "I wouldn't have a clue, e-mail this group" or something. > I have a solution for exactlythis problem > You need the patch I submitted for ipfw fwd of incoming packets > about 3 weeks ago. > > it allows load sharing to an arbitrary number of webservers transparently > I sent it to "net" and it had a subject of RFC: (something) > > the mail includes how to set it up.. > it uses about 1% of cpu redirecting a 10Mb ethernet to 2 servers. > (sorry to be vague but look it up in the archives with > julian AND RFC AND ipfw in the net list.. The new ipfw fwd functionality looks really nice. But it seems like Tom needs forwarding based on the name (www.domain1.com or www.domain2.com) in the HTTP GET Request. I don't think that can be handled in ipfw or ipf. One thing you could do is using both servers for both domains and use the load balancing described by Julian. This has the drawback that the servers are not separated but on the other hand you get redundancy for both servers. -- Benedikt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Dec 11 7:49:14 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail.unix.ru (mail.chs.ru [194.154.71.136]) by hub.freebsd.org (Postfix) with ESMTP id 4354B37B41B; Tue, 11 Dec 2001 07:49:10 -0800 (PST) Received: from [192.168.81.13] (helo=sam) by mail.unix.ru with esmtp (Exim 3.22) id 16Dp9O-0003bx-00 ; Tue, 11 Dec 2001 18:48:58 +0300 Date: Tue, 11 Dec 2001 18:51:44 +0300 From: Smirnov Konstantin X-Mailer: The Bat! (v1.46d) Personal Reply-To: Smirnov Konstantin Organization: RMP X-Priority: 3 (Normal) Message-ID: <305430238.20011211185144@rmp.ru> To: freebsd-net@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG Subject: Help! Server unexpectedly stops respond... Mime-Version: 1.0 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 Hi guys! We have a high-load webserver on FreeBSD 4.1.1 (~40 Apache connections at time with keep-alive switched off). Day after day we bump into following: server unexpectedly stops all data transfers. It responds on PING, and can open new sockets, but can't send or receive anything. 'top' reports (I grab 'top' output every 1 minute) don't look suspicious. Where can be problem? Best regards, Samius -------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Dec 11 8: 4:12 2001 Delivered-To: freebsd-net@freebsd.org Received: from bilbo.sgn.sca.se (bilbo.sgn.sca.se [193.221.47.92]) by hub.freebsd.org (Postfix) with ESMTP id 1982537B416 for ; Tue, 11 Dec 2001 08:04:09 -0800 (PST) Received: from narya.sgn.sca.se (root@narya.sgn.sca.se [10.192.24.4]) by bilbo.sgn.sca.se (8.11.6/8.11.6) with ESMTP id fBBG45O07218 for ; Tue, 11 Dec 2001 17:04:06 +0100 (CET) Received: from joed2000 ([172.24.60.7]) by narya.sgn.sca.se (8.11.6/8.11.6) with SMTP id fBBEA8304125; Tue, 11 Dec 2001 08:10:08 -0600 (CST) Reply-To: From: "Edstrom Johan" To: "Tom Peck" , Subject: RE: 1 IP - 1 Firewall - 2 Webservers Date: Tue, 11 Dec 2001 08:07:52 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <5.1.0.14.2.20011211121120.0287ddb0@mail.masaclaw.co.nz> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 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 Why just not use Apache virtual hosts? Or is it the cacheing you wish to do smarter? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Dec 11 8:27:32 2001 Delivered-To: freebsd-net@freebsd.org Received: from sonic.kks.net (sonic.kks.net [213.161.0.18]) by hub.freebsd.org (Postfix) with ESMTP id 7DDD737B405 for ; Tue, 11 Dec 2001 08:27:23 -0800 (PST) Received: from voyager.kksonline.com (5-51.ro.cable.kks.net [213.161.5.51]) by sonic.kks.net (Postfix) with ESMTP id C0A711E6 for ; Tue, 11 Dec 2001 17:27:30 +0100 (CET) Message-Id: <5.0.2.1.0.20011211172115.02d0edb8@sundance.kks.net> X-Sender: arozman@sundance.kks.net X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 11 Dec 2001 17:26:29 +0100 To: freebsd-net@freebsd.org From: Aleksander Rozman - Andy Subject: Adding new networking protocol (ax.25) In-Reply-To: <20011210210625.A16280@iguana.aciri.org> 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 Hi People ! I was planing some time now, to try to add ax25 (packet radio) protocols, so we could use packet radio with FreeBSD. Now I was wondering if any of you has seen any special documentation that could help me with that. I was told that TCP/IP Illustrated Volume 2, was great book for this purpose (I still haven't got my hands on it, but I am trying to get it), so I was wondering if anybody else has some info that could help me do that (tutorials, docs, books, links, anything...). I will be porting this from Linux, so any documentation for doing this will also be appreciated. I was searching net for this, but I haven't found much so far, everything I did get, I got by "accident"...so if any of you had some of such "accident" I would be grateful for any hints... Take care. Andy > ************************************************************************** * Aleksander Rozman - Andy * Fandoms: E2:EA, SAABer, Trekkie, Earthie * * andy@kksonline.com * Sentinel, BH 90210, True's Trooper, * * andy@atechnet.dhs.org * Heller's Angel, Questie, Legacy, PO5, * * Maribor, Slovenia (Europe) * Profiler, Buffy (Slayerete), Pretender * * ICQ-UIC: 4911125 ********************************************* * PGP key available * http://www.atechnet.dhs.org/~andy/ * ************************************************************************** To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Dec 11 9:26:23 2001 Delivered-To: freebsd-net@freebsd.org Received: from services.webwarrior.net (overlord-host99.dsl.visi.com [209.98.86.99]) by hub.freebsd.org (Postfix) with ESMTP id 875FE37BCFB; Tue, 11 Dec 2001 09:15:01 -0800 (PST) Received: from twincat.vladsempire.net (hutch-771.hutchtel.net [206.10.71.71]) by services.webwarrior.net (Postfix) with ESMTP id B8D7E204; Tue, 11 Dec 2001 11:14:09 -0600 (CST) Received: by twincat.vladsempire.net (Postfix, from userid 1001) id 44E2F3863; Tue, 11 Dec 2001 11:13:58 +0000 (GMT) Date: Tue, 11 Dec 2001 11:13:58 +0000 From: Josh Paetzel To: Smirnov Konstantin Cc: freebsd-net@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG Subject: Re: Help! Server unexpectedly stops respond... Message-ID: <20011211111358.E397@twincat.vladsempire.net> Mail-Followup-To: Smirnov Konstantin , freebsd-net@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG References: <305430238.20011211185144@rmp.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <305430238.20011211185144@rmp.ru>; from sam@rmp.ru on Tue, Dec 11, 2001 at 06:51:44PM +0300 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, Dec 11, 2001 at 06:51:44PM +0300, Smirnov Konstantin wrote: > Hi guys! > > We have a high-load webserver on FreeBSD 4.1.1 (~40 Apache connections at > time with keep-alive switched off). > Day after day we bump into following: server unexpectedly stops all > data transfers. It responds on PING, and can open new sockets, but > can't send or receive anything. > 'top' reports (I grab 'top' output every 1 minute) don't look suspicious. > Where can be problem? > > Best regards, > Samius > -------------------- This could be a lot of things, but without more info, it's hard to make any judgements at all. I will ask on question, though: What is MAXUSERS set to in your kernel? Josh To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Dec 11 9:27: 6 2001 Delivered-To: freebsd-net@freebsd.org Received: from wall.polstra.com (wall-gw.polstra.com [206.213.73.130]) by hub.freebsd.org (Postfix) with ESMTP id CB0FB37C12D for ; Tue, 11 Dec 2001 09:22:41 -0800 (PST) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.11.3/8.11.3) with ESMTP id fBBHMZ057168; Tue, 11 Dec 2001 09:22:35 -0800 (PST) (envelope-from jdp@wall.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.11.6/8.11.0) id fBBHMU706558; Tue, 11 Dec 2001 09:22:30 -0800 (PST) (envelope-from jdp) Date: Tue, 11 Dec 2001 09:22:30 -0800 (PST) Message-Id: <200112111722.fBBHMU706558@vashon.polstra.com> To: net@freebsd.org From: John Polstra Cc: rizzo@aciri.org Subject: Re: do we really need NETISR_foo == AF_foo ? In-Reply-To: <20011210210625.A16280@iguana.aciri.org> References: <20011210210625.A16280@iguana.aciri.org> Organization: Polstra & Co., Seattle, WA 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 <20011210210625.A16280@iguana.aciri.org>, Luigi Rizzo wrote: > However, I was wonder if it is really necessary that NETISR_foo has > the same value as AF_foo, or it is possible to shift up values and > fill holes to free the last bit ? I've never been able to find any reason at all why the NETISR and AF constants have to be the same. 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 Tue Dec 11 9:34: 3 2001 Delivered-To: freebsd-net@freebsd.org Received: from star.rila.bg (star.rila.bg [194.141.1.32]) by hub.freebsd.org (Postfix) with ESMTP id 8AA5F37B431 for ; Tue, 11 Dec 2001 09:31:50 -0800 (PST) Received: from star.rila.bg (vlady@localhost [127.0.0.1]) by star.rila.bg (8.11.4/8.11.4) with SMTP id fBBHVnc11225 for ; Tue, 11 Dec 2001 19:31:49 +0200 (EET) (envelope-from vladimirt@rila.bg) Date: Tue, 11 Dec 2001 19:31:48 +0200 From: "Vladimir Terziev" To: freebsd-net@freebsd.org Subject: Intel PRO/Wireless 5000 Lan PCI Message-Id: <20011211193148.47151415.vladimirt@rila.bg> X-Mailer: Sylpheed version 0.6.5 (GTK+ 1.2.7; i386-unknown-freebsd4.3) Mime-Version: 1.0 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 Hi all, I've searched the documentation, but couldn't find the answer of the following question. Does FreeBSD supports Intel PRO/Wireless 5000 Lan PCI adapter? regards, Vladimir To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Dec 11 10:17:26 2001 Delivered-To: freebsd-net@freebsd.org Received: from lart.thugsrus.net (geeb-0.dsl.speakeasy.net [216.254.33.22]) by hub.freebsd.org (Postfix) with ESMTP id 34ACB37B41B for ; Tue, 11 Dec 2001 10:17:22 -0800 (PST) Received: from slobberbunny.thugsrus.net (geeb-1.dsl.speakeasy.net [216.254.33.23]) by lart.thugsrus.net (Postfix) with ESMTP id 4187BF54D for ; Tue, 11 Dec 2001 13:17:21 -0500 (EST) Received: (from geeb@localhost) by slobberbunny.thugsrus.net (8.11.6/8.9.1) id fBBII5a01735 for freebsd-net@freebsd.org; Tue, 11 Dec 2001 13:18:05 -0500 (EST) Date: Tue, 11 Dec 2001 13:18:05 -0500 From: Mark A Gebert To: freebsd-net@freebsd.org Subject: Problems with mpd-netgraph and Stable Message-ID: <20011211131805.A1722@thugsrus.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i 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 trying to do pptp with mpd-netgraph and a stable kernel build from a day ago. Everytime I run it on my IBM T-20 laptop (with fxp interface), it negotiates the link and as it's ready to be used the laptop crashes: Dec 10 14:03:34 tigger /kernel: rupt mask = net tty bio cam Dec 10 14:03:34 tigger /kernel: trap number = 12 Dec 10 14:03:34 tigger /kernel: panic: page fault Dec 10 14:03:34 tigger /kernel: Uptime: 4h51m8s Dec 10 14:03:34 tigger /kernel: Dec 10 14:03:34 tigger /kernel: Dec 10 14:03:34 tigger /kernel: Fatal trap 12: page fault while in kernel mode Dec 10 14:03:34 tigger /kernel: fault virtual address = 0x30 Dec 10 14:03:34 tigger /kernel: fault code = supervisor read, page not present Dec 10 14:03:34 tigger /kernel: instruction pointer = 0x8:0xc0d48e3a Dec 10 14:03:34 tigger /kernel: stack pointer = 0x10:0xc02fea2c Dec 10 14:03:34 tigger /kernel: frame pointer = 0x10:0xc02fea34 Dec 10 14:03:34 tigger /kernel: code segment = base 0x0, limit 0xffff f, type 0x1b Dec 10 14:03:34 tigger /kernel: = DPL 0, pres 1, def32 1, gran 1 Dec 10 14:03:34 tigger /kernel: processor eflags = interrupt enabled, res ume, IOPL = 3 Dec 10 14:03:34 tigger /kernel: current process = Idle Dec 10 14:03:34 tigger /kernel: interrupt mask = net tty bio cam Dec 10 14:03:34 tigger /kernel: trap number = 12 Dec 10 14:03:34 tigger /kernel: panic: page fault Dec 10 14:03:34 tigger /kernel: Uptime: 4h51m8s Dec 10 14:03:34 tigger /kernel: Dec 10 14:03:34 tigger /kernel: Dec 10 14:03:34 tigger /kernel: Fatal trap 12: page fault while in kernel mode Dec 10 14:03:34 tigger /kernel: fault virtual address = 0x30 Dec 10 14:03:34 tigger /kernel: fault code = supervisor read, page not present Dec 10 14:03:34 tigger /kernel: instruction pointer = 0x8:0xc0d48e3a Dec 10 14:03:34 tigger /kernel: stack pointer = 0x10:0xc02fe77c Dec 10 14:03:34 tigger /kernel: frame pointer = 0x10:0xc02fe784 Dec 10 14:03:34 tigger /kernel: code segment = base 0x0, limit 0xffff f, type 0x1b I'm using the following mpd.conf: vpn: new -i ng0 vpn vpn set bundle no multilink set bundle authname geeb set bundle enable compression set bundle enable crypt-reqd set iface disable on-demand set iface idle 0 set iface route set ipcp ranges 0.0.0.0/0 /0 set ipcp accept vjcomp set link enable no-orig-auth set link keep-alive 10 75 set link max-redial 1 set link yes acfcomp protocomp set link no pap set link accept chap set ccp yes mppc set ccp yes mpp-e40 set ccp yes mpp-e128 set ccp yes mpp-stateless open Suggestions? --geeb -- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Dec 11 10:19:26 2001 Delivered-To: freebsd-net@freebsd.org Received: from charentes.fr.clara.net (charentes.fr.clara.net [212.43.194.76]) by hub.freebsd.org (Postfix) with ESMTP id 14CA737B416 for ; Tue, 11 Dec 2001 10:19:24 -0800 (PST) Received: from trotski.freesurf.fr (trotski.freesurf.fr [212.43.206.9]) by charentes.fr.clara.net (Postfix) with ESMTP id 2F8B959604 for ; Tue, 11 Dec 2001 19:19:23 +0100 (CET) Received: from gargantua.dyndns.org (du-204-198.nat.dialup.freesurf.fr [212.43.204.198]) by trotski.freesurf.fr (Postfix) with ESMTP id 050849B08 for ; Tue, 11 Dec 2001 19:19:20 +0100 (CET) Received: (from romain@localhost) by gargantua.dyndns.org (8.11.6/8.11.6) id fBBI80V52291 for net@freebsd.org; Tue, 11 Dec 2001 19:08:01 +0100 (CET) (envelope-from romain) Date: Tue, 11 Dec 2001 19:07:57 +0100 From: Romain Berrendonner To: net@freebsd.org Subject: SCTP Message-ID: <20011211190756.A52248@gargantua.dyndns.org> Reply-To: romain@cuivre.fr.eu.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi all, Does anybody know a SCTP (RFC XXXX) implementation in FreeBSD ? -- Romain Berrendonner romain@cuivre.fr.eu.org PGP Key fingerprint: 9416 A340 5934 388F FC44 34C2 AD80 555E 9CBE D8CB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Dec 11 10:26:53 2001 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 C814F37B405 for ; Tue, 11 Dec 2001 10:26:50 -0800 (PST) Received: from isi.edu (ras31.isi.edu [128.9.176.131]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id fBBIQlN00688; Tue, 11 Dec 2001 10:26:48 -0800 (PST) Message-ID: <3C164FE7.2010001@isi.edu> Date: Tue, 11 Dec 2001 10:26:47 -0800 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.6) Gecko/20011203 X-Accept-Language: en, de MIME-Version: 1.0 To: Mark A Gebert Cc: freebsd-net@freebsd.org Subject: Re: Problems with mpd-netgraph and Stable References: <20011211131805.A1722@thugsrus.org> 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 Mark A Gebert wrote: > I'm trying to do pptp with mpd-netgraph and a stable kernel build from a day > ago. Everytime I run it on my IBM T-20 laptop (with fxp interface), it > negotiates the link and as it's ready to be used the laptop crashes: I've seen mpd crashes with Cisco VPN servers that are stupid enough to advertise their own IP address to the client, causing an infinite encapsulation loop (tunneled packets forwarded over the tunnel). You could catch that with a sanity check inside mpd (don't accept the servers physical address for your own use during negotiation). I've not done this, we simply returned the Cisco box :-) Lars -- Lars Eggert Information Sciences Institute http://www.isi.edu/larse/ University of Southern California To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Dec 11 10:43: 3 2001 Delivered-To: freebsd-net@freebsd.org Received: from charentes.fr.clara.net (charentes.fr.clara.net [212.43.194.76]) by hub.freebsd.org (Postfix) with ESMTP id CF0AC37B417 for ; Tue, 11 Dec 2001 10:42:59 -0800 (PST) Received: from mail3.freesurf.fr (bastille.freesurf.fr [212.43.206.2]) by charentes.fr.clara.net (Postfix) with ESMTP id C2E15596D2 for ; Tue, 11 Dec 2001 19:42:58 +0100 (CET) Received: from trotski.freesurf.fr (trotski.freesurf.fr [212.43.206.9]) by mail3.freesurf.fr (Postfix) with ESMTP id 99D0719017 for ; Tue, 11 Dec 2001 19:42:58 +0100 (CET) Received: from gargantua.dyndns.org (du-201-129.nat.dialup.freesurf.fr [212.43.201.129]) by trotski.freesurf.fr (Postfix) with ESMTP id A0C329B08 for ; Tue, 11 Dec 2001 19:42:56 +0100 (CET) Received: (from romain@localhost) by gargantua.dyndns.org (8.11.6/8.11.6) id fBBIgrX55074 for net@FreeBSD.ORG; Tue, 11 Dec 2001 19:42:53 +0100 (CET) (envelope-from romain) Date: Tue, 11 Dec 2001 19:42:49 +0100 From: Romain Berrendonner To: net@FreeBSD.ORG Subject: Re: SCTP Message-ID: <20011211194248.A54901@gargantua.dyndns.org> Reply-To: romain@cuivre.fr.eu.org References: <20011211190756.A52248@gargantua.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011211190756.A52248@gargantua.dyndns.org>; from romain@gargantua.dyndns.org on Tue, Dec 11, 2001 at 07:07:57PM +0100 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 Le 2001-12-11 19:07 UTC+0100, Romain Berrendonner a ecrit: > Hi all, > > Does anybody know a SCTP (RFC XXXX) implementation in FreeBSD ? > Off course, I meant 8) RFC 2960 Stream Control Transmission Protocol. R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, V. Paxson. October 2000. (Format: TXT=297757 bytes) (Status: PROPOSED STANDARD) -- Romain Berrendonner romain@cuivre.fr.eu.org PGP Key fingerprint: 9416 A340 5934 388F FC44 34C2 AD80 555E 9CBE D8CB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Dec 11 11: 0:26 2001 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 1AB0437B41B for ; Tue, 11 Dec 2001 11:00:12 -0800 (PST) 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 <20011211190011.URQY24045.rwcrmhc53.attbi.com@InterJet.elischer.org>; Tue, 11 Dec 2001 19: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 KAA05665; Tue, 11 Dec 2001 10:57:23 -0800 (PST) Date: Tue, 11 Dec 2001 10:57:21 -0800 (PST) From: Julian Elischer To: Mark A Gebert Cc: freebsd-net@freebsd.org Subject: Re: Problems with mpd-netgraph and Stable In-Reply-To: <20011211131805.A1722@thugsrus.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 can you compile a debug kernel? (config -g MYKERNEL) and set dumps on (check rc.conf for the dumpon options) then we can get a propper backtrace.. (do you have the modules compiled in or are you loading them?) (prefer compiled in) On Tue, 11 Dec 2001, Mark A Gebert wrote: > I'm trying to do pptp with mpd-netgraph and a stable kernel build from a day > ago. Everytime I run it on my IBM T-20 laptop (with fxp interface), it > negotiates the link and as it's ready to be used the laptop crashes: > > Dec 10 14:03:34 tigger /kernel: rupt mask = net tty bio cam > Dec 10 14:03:34 tigger /kernel: trap number = 12 > Dec 10 14:03:34 tigger /kernel: panic: page fault > Dec 10 14:03:34 tigger /kernel: Uptime: 4h51m8s > Dec 10 14:03:34 tigger /kernel: > Dec 10 14:03:34 tigger /kernel: > Dec 10 14:03:34 tigger /kernel: Fatal trap 12: page fault while in kernel mode > Dec 10 14:03:34 tigger /kernel: fault virtual address = 0x30 > Dec 10 14:03:34 tigger /kernel: fault code = supervisor read, page > not present > Dec 10 14:03:34 tigger /kernel: instruction pointer = 0x8:0xc0d48e3a > Dec 10 14:03:34 tigger /kernel: stack pointer = 0x10:0xc02fea2c > Dec 10 14:03:34 tigger /kernel: frame pointer = 0x10:0xc02fea34 > Dec 10 14:03:34 tigger /kernel: code segment = base 0x0, limit 0xffff > f, type 0x1b > Dec 10 14:03:34 tigger /kernel: = DPL 0, pres 1, def32 1, gran 1 > Dec 10 14:03:34 tigger /kernel: processor eflags = interrupt enabled, res > ume, IOPL = 3 > Dec 10 14:03:34 tigger /kernel: current process = Idle > Dec 10 14:03:34 tigger /kernel: interrupt mask = net tty bio cam > Dec 10 14:03:34 tigger /kernel: trap number = 12 > Dec 10 14:03:34 tigger /kernel: panic: page fault > Dec 10 14:03:34 tigger /kernel: Uptime: 4h51m8s > Dec 10 14:03:34 tigger /kernel: > Dec 10 14:03:34 tigger /kernel: > Dec 10 14:03:34 tigger /kernel: Fatal trap 12: page fault while in kernel mode > Dec 10 14:03:34 tigger /kernel: fault virtual address = 0x30 > Dec 10 14:03:34 tigger /kernel: fault code = supervisor read, page > not present > Dec 10 14:03:34 tigger /kernel: instruction pointer = 0x8:0xc0d48e3a > Dec 10 14:03:34 tigger /kernel: stack pointer = 0x10:0xc02fe77c > Dec 10 14:03:34 tigger /kernel: frame pointer = 0x10:0xc02fe784 > Dec 10 14:03:34 tigger /kernel: code segment = base 0x0, limit 0xffff > f, type 0x1b > > > I'm using the following mpd.conf: > > vpn: > new -i ng0 vpn vpn > set bundle no multilink > set bundle authname geeb > set bundle enable compression > set bundle enable crypt-reqd > set iface disable on-demand > set iface idle 0 > set iface route > set ipcp ranges 0.0.0.0/0 /0 > set ipcp accept vjcomp > set link enable no-orig-auth > set link keep-alive 10 75 > set link max-redial 1 > set link yes acfcomp protocomp > set link no pap > set link accept chap > set ccp yes mppc > set ccp yes mpp-e40 > set ccp yes mpp-e128 > set ccp yes mpp-stateless > open > > Suggestions? > > --geeb > > -- > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Dec 11 12: 6:32 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail.unix.ru (mail.chs.ru [194.154.71.136]) by hub.freebsd.org (Postfix) with ESMTP id CB3AC37B417 for ; Tue, 11 Dec 2001 12:06:22 -0800 (PST) Received: from [192.168.81.13] (helo=sam) by mail.unix.ru with esmtp (Exim 3.22) id 16DtAD-0005O2-00 ; Tue, 11 Dec 2001 23:06:05 +0300 Date: Tue, 11 Dec 2001 23:08:50 +0300 From: Smirnov Konstantin X-Mailer: The Bat! (v1.46d) Personal Reply-To: Smirnov Konstantin Organization: RMP X-Priority: 3 (Normal) Message-ID: <553702363.20011211230850@rmp.ru> To: Josh Paetzel , freebsd-net@freebsd.org Subject: Re[2]: Help! Server unexpectedly stops respond... In-reply-To: <20011211111358.E397@twincat.vladsempire.net> References: <305430238.20011211185144@rmp.ru> <20011211111358.E397@twincat.vladsempire.net> Mime-Version: 1.0 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 Hello Josh, Tuesday, December 11, 2001, 2:13:58 PM, you wrote: JP> This could be a lot of things, but without more info, it's hard to JP> make any judgements at all. I will ask on question, though: What is JP> MAXUSERS set to in your kernel? Of course, I've should mention it in previous letter. Yes, I know that FreeBSD has a very low default MAXUSERS value (32, in 4.1.1.) So (3 months ago) I increased it to 256 ;). But it was not a reason Firstly I deduced that problems happen because of I've rebuilt kernel (1st of November). But when I built a "almost-generic" kernel (it means GENERIC config-file with 2 CPUs support and ipfw enabled), subject remains... Some backround: We use IBM NetFinity 3500 (without RAID-controller), 2xPIII 700, 512 Mb, 20GB SCSI (of which 1028MB is swap), Intel Pro 10/100B/100+ Ethernet OS: FreeBSD 4.1.1 ;) Installed services: Apache-1.3.20 with php-4.0.6, MySQL-3.23.45, BIND-9.1.3, Postfix, Qpopper-4.0, latest thttpd. 2 days ago I put into crontab a shell script that appends top+netstat shot to text file, so it's possible to see server status by the last minute before crash. But I saw nothing. Really nothing! Maybe, server can't fork any more, or something like that?? Maybe it would be more informative to post to you any config files? Thank you for help, John. Best regards, Samius -------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Dec 11 13:46:57 2001 Delivered-To: freebsd-net@freebsd.org Received: from mta1-rme.xtra.co.nz (mta1-rme.xtra.co.nz [210.86.15.129]) by hub.freebsd.org (Postfix) with ESMTP id CF2D637B417 for ; Tue, 11 Dec 2001 13:46:53 -0800 (PST) Received: from internet1.masaclaw.co.nz ([210.55.57.50]) by mta1-rme.xtra.co.nz with ESMTP id <20011211214651.CRAM28825.mta1-rme.xtra.co.nz@internet1.masaclaw.co.nz>; Wed, 12 Dec 2001 10:46:51 +1300 Message-Id: <5.1.0.14.2.20011212103711.00accef8@mail.masaclaw.co.nz> X-Sender: masaclaw@mail.masaclaw.co.nz X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 12 Dec 2001 10:39:46 +1300 To: , freebsd-net@FreeBSD.ORG From: Tom Peck Subject: RE: 1 IP - 1 Firewall - 2 Webservers In-Reply-To: References: <5.1.0.14.2.20011211121120.0287ddb0@mail.masaclaw.co.nz> 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 Hi John How would this work? The two web servers aren't accessible straight from the Internet - traffic goes via the gateway box. Or do you mean why have two web servers? Why not put both domains on the one server and then port forward? That would be nice, but the two different servers are running completely different environments.. Cheers Tom At 08:07 11/12/2001 -0800, you wrote: >Why just not use Apache virtual hosts? >Or is it the cacheing you wish to do smarter? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Dec 11 14:40:18 2001 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 AC71037B420 for ; Tue, 11 Dec 2001 14:40:07 -0800 (PST) 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 <20011211224007.VXCJ4213.rwcrmhc52.attbi.com@InterJet.elischer.org>; Tue, 11 Dec 2001 22:40: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 OAA06489; Tue, 11 Dec 2001 14:30:28 -0800 (PST) Date: Tue, 11 Dec 2001 14:30:27 -0800 (PST) From: Julian Elischer To: Tom Peck Cc: johan.edstrom@sca.com, freebsd-net@FreeBSD.ORG Subject: RE: 1 IP - 1 Firewall - 2 Webservers In-Reply-To: <5.1.0.14.2.20011212103711.00accef8@mail.masaclaw.co.nz> 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 Actually I misunderstood your original requirement that the load be split by domain. all you want to do is run apache or squid as a proxy on the forst machine with the proxy fetching the work from the two back-end machines. On Wed, 12 Dec 2001, Tom Peck wrote: > Hi John > > How would this work? The two web servers aren't accessible straight from > the Internet - traffic goes via the gateway box. > > Or do you mean why have two web servers? Why not put both domains on the > one server and then port forward? That would be nice, but the two > different servers are running completely different environments.. > > Cheers > > Tom > > > At 08:07 11/12/2001 -0800, you wrote: > >Why just not use Apache virtual hosts? > >Or is it the cacheing you wish to do smarter? > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Dec 11 14:54: 1 2001 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 CFE0A37B416 for ; Tue, 11 Dec 2001 14:53:57 -0800 (PST) Received: from isi.edu (ras32.isi.edu [128.9.176.132]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id fBBMrRN17209; Tue, 11 Dec 2001 14:53:27 -0800 (PST) Message-ID: <3C168E66.5080702@isi.edu> Date: Tue, 11 Dec 2001 14:53:26 -0800 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.6) Gecko/20011203 X-Accept-Language: en, de MIME-Version: 1.0 To: Tom Peck Cc: johan.edstrom@sca.com, freebsd-net@FreeBSD.ORG Subject: Re: 1 IP - 1 Firewall - 2 Webservers References: <5.1.0.14.2.20011211121120.0287ddb0@mail.masaclaw.co.nz> <5.1.0.14.2.20011212103711.00accef8@mail.masaclaw.co.nz> 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 Tom Peck wrote: > How would this work? The two web servers aren't accessible straight > from the Internet - traffic goes via the gateway box. I bet he forgot to mention that the gateway is also a NAT box. Since squid does app-level relaying, HTTP isn't affected. Lars -- Lars Eggert Information Sciences Institute http://www.isi.edu/larse/ University of Southern California To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Dec 11 15:41:56 2001 Delivered-To: freebsd-net@freebsd.org Received: from mta2-rme.xtra.co.nz (mta2-rme.xtra.co.nz [210.86.15.130]) by hub.freebsd.org (Postfix) with ESMTP id 8B77937B433 for ; Tue, 11 Dec 2001 15:41:47 -0800 (PST) Received: from internet1.masaclaw.co.nz ([210.55.57.50]) by mta2-rme.xtra.co.nz with ESMTP id <20011211234145.DAWN20016.mta2-rme.xtra.co.nz@internet1.masaclaw.co.nz>; Wed, 12 Dec 2001 12:41:45 +1300 Message-Id: <5.1.0.14.2.20011212123256.02871e50@mail.masaclaw.co.nz> X-Sender: masaclaw@mail.masaclaw.co.nz X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 12 Dec 2001 12:35:36 +1300 To: Julian Elischer , freebsd-net@FreeBSD.ORG From: Tom Peck Subject: RE: 1 IP - 1 Firewall - 2 Webservers In-Reply-To: References: <5.1.0.14.2.20011212103711.00accef8@mail.masaclaw.co.nz> 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 Hi Julian Yes, we currently have Squid serving this purpose - but as I stated in my first email, ALL incoming Client IP's and Addresses are always that of the GATEWAY_BOX - so for website security and logs, this isn't the best option.. I have yet to try Apache, but I have heard it acts in the same way - can someone clarify this? Thanks Tom At 14:30 11/12/2001 -0800, you wrote: >Actually I misunderstood your original requirement that the >load be split by domain. > >all you want to do is run apache or squid as a proxy >on the forst machine with the proxy fetching the work >from the two back-end machines. > > >On Wed, 12 Dec 2001, Tom Peck wrote: > > > Hi John > > > > How would this work? The two web servers aren't accessible straight from > > the Internet - traffic goes via the gateway box. > > > > Or do you mean why have two web servers? Why not put both domains on the > > one server and then port forward? That would be nice, but the two > > different servers are running completely different environments.. > > > > Cheers > > > > Tom > > > > > > At 08:07 11/12/2001 -0800, you wrote: > > >Why just not use Apache virtual hosts? > > >Or is it the cacheing you wish to do smarter? > > > > > > > > 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 Tue Dec 11 16:15: 7 2001 Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 6D43637B416; Tue, 11 Dec 2001 16:14:55 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.3/8.11.1) id fBC0Eto24132; Tue, 11 Dec 2001 16:14:55 -0800 (PST) (envelope-from rizzo) Date: Tue, 11 Dec 2001 16:14:55 -0800 From: Luigi Rizzo To: net@freebsd.org Subject: Polling code at http://info.iet.unipi.it/~luigi/polling/ Message-ID: <20011211161454.B23443@iguana.aciri.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.23i 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 [Bcc to committers and -stable as relevant there, but please keep the discussion on -net if any] I have put up a web page with the latest version of the device polling patches, both for -stable and -current, at http://info.iet.unipi.it/~luigi/polling/ so new versions will be available through there, together with additional documentation, code and references. Compared to the code recently pulled out from -stable, what you can find now at the above URL has the following improvements: * "scheduling" code which lets you control in a reasonably fine-grained way the sharing of CPU between kernel (polling) and userland. You can now do something like sysctl kern.polling.user_frac=40 to reserve 40% of the CPU time to userland processes (assuming there is enough work to do). Default value is 50. * a restructured polling loop which prevents livelock and unfairness even when the standard (no fastforwarding) path is used. Together with the kern.polling.enable variable, kern.polling.user_frac is the only tunable parameter that you need to care about, and the default value should be a reasonable one. It would be great if some of you committers would have the time to have a look at the -current version, or possibly even try it on Alpha boxes (I think overall there is only one or two lines of MD code), and send feedback. thanks luigi ----------------------------------+----------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . ACIRI/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 Tue Dec 11 18: 8: 0 2001 Delivered-To: freebsd-net@freebsd.org Received: from verifam.don.to (cj3096656-b.sagam1.kn.home.ne.jp [210.20.134.46]) by hub.freebsd.org (Postfix) with ESMTP id 6422537B405; Tue, 11 Dec 2001 18:07:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by verifam.don.to (8.11.3/3.7W) with ESMTP id fBC23fM19448; Wed, 12 Dec 2001 11:03:41 +0900 (JST) Date: Wed, 12 Dec 2001 11:06:36 +0900 (JST) Message-Id: <20011212.110636.65197733.sumikawa@ebina.hitachi.co.jp> To: nsayer@quack.kfu.com Cc: developers@FreeBSD.org, freebsd-net@FreeBSD.ORG, sumikawa@ebina.hitachi.co.jp Subject: Re: Should I merge KAME's NATPT? From: SUMIKAWA Munechika In-Reply-To: <3C16A5DF.8020005@kfu.com> References: <3C16A5DF.8020005@kfu.com> X-Mailer: xcite1.42> Mew version 3.0.50 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 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 Nick, > I asked a couple days ago on -net and heard nothing back, but I really > don't want to step on anyone's toes. > > I have successfully merged NATPT from KAME's latest snapshot. It was so > easy I am a bit surprised no one has done it already. It just drops > right in with a slight merge to ip_input.c, ip_proto.c and ip6_input.c, > all of > which is #ifdef NATPT protected. It works perfectly, so far as I can tell. > > I actually merged it into -stable, but I can't possibly imagine that it > wouldn't be just as easy to drop into -current. KAME NATPT is still under developing. It's unstable and cannot not translate all type of packets yet, for example it cannot handle IPv4 fragmented packet with DF bit now. Moreover there is possibility that its API might changes. We need to provide backward compatibility when the API is changed. I think -current merging need more couple of months. --- Munechika SUMIKAWA @ KAME Project / FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Dec 11 18:19:14 2001 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 770CE37B405 for ; Tue, 11 Dec 2001 18:19:09 -0800 (PST) Received: from gateway.posi.net ([12.236.90.177]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20011212021909.FHVA8889.rwcrmhc53.attbi.com@gateway.posi.net>; Wed, 12 Dec 2001 02:19:09 +0000 Received: from localhost (kbyanc@localhost) by gateway.posi.net (8.11.6/8.11.6) with ESMTP id fBC2J0830434; Tue, 11 Dec 2001 18:19:00 -0800 (PST) (envelope-from kbyanc@posi.net) X-Authentication-Warning: gateway.posi.net: kbyanc owned process doing -bs Date: Tue, 11 Dec 2001 18:18:59 -0800 (PST) From: Kelly Yancey To: Tom Peck Cc: Julian Elischer , freebsd-net@FreeBSD.ORG Subject: RE: 1 IP - 1 Firewall - 2 Webservers In-Reply-To: <5.1.0.14.2.20011212123256.02871e50@mail.masaclaw.co.nz> 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, 12 Dec 2001, Tom Peck wrote: > Hi Julian > > Yes, we currently have Squid serving this purpose - but as I stated in my > first email, ALL incoming Client IP's and Addresses are always that of the > GATEWAY_BOX - so for website security and logs, this isn't the best > option.. I have yet to try Apache, but I have heard it acts in the same > way - can someone clarify this? > > Thanks > > Tom > I have to apologize, I deleted the original post, but as I recall you have the actual forwarding working dandy. The only concern, which everyone has failed to address, is that you want the NAT'ed web servers to know the originating IP address for logging and IP-based security. Obviously, the reason you don't have this now is that the originating request is intercepted by squid on your gateway machine and then issueing a request to one of the internel web servers using it's "inside" IP address on the originator's behalf. You web server only ever sees the proxy's IP address. The question, then, is how to communicate the originaters IP address to the web server. I haven't answered previously because I'm no squid expert, but here is the solution that comes to my head: You could hack squid (assuming it doesn't have a knob to do it already) to include the originating IP address as a HTTP header in the proxied request. Then, modify your apps on the web server fetch the IP address from this header (i.e. via environment variable) as opposed to using the value the web server populates REMOTE_HOST with. However, the IP address in web server logs will still be that of the proxy unless you teach the web server to extract the IP from the new header. Of course, if you have the source to your web server (i.e. apache) then you could teach it to populate REMOTE_HOST with the IP address obtained from the squid-supplied header also and have it be transparent to your apps. All the said, you would have to take extra precautions in squid to not allow remote clients to supply the header themselves (i.e. to replace the header if it exists and add it if it doesn't), but this should be pretty straightforward. I hope that answers your question (assuming I am remembering it correctly :) ). Good luck! Kelly -- Kelly Yancey - kbyanc@{posi.net,FreeBSD.org} To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Dec 11 18:25: 2 2001 Delivered-To: freebsd-net@freebsd.org Received: from radius.ok-connect.com (radius.wavefire.com [139.142.95.252]) by hub.freebsd.org (Postfix) with SMTP id A904637B405 for ; Tue, 11 Dec 2001 18:24:58 -0800 (PST) Received: (qmail 14942 invoked from network); 12 Dec 2001 02:36:09 -0000 Received: from ccliii.caniserv.com (HELO dbitech) (139.142.95.253) by radius.wavefire.com with SMTP; 12 Dec 2001 02:36:09 -0000 Message-Id: <3.0.32.20011211182606.024ed180@mail.ok-connect.com> X-Sender: darcyb@mail.ok-connect.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 11 Dec 2001 18:26:07 -0800 To: Kelly Yancey , Tom Peck From: Darcy Buskermolen Subject: RE: 1 IP - 1 Firewall - 2 Webservers Cc: freebsd-net@FreeBSD.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 You can configure your cache server to send an X-header with the originateing IP, and then use that.. At 06:18 PM 12/11/01 -0800, Kelly Yancey wrote: >On Wed, 12 Dec 2001, Tom Peck wrote: > >> Hi Julian >> >> Yes, we currently have Squid serving this purpose - but as I stated in my >> first email, ALL incoming Client IP's and Addresses are always that of the >> GATEWAY_BOX - so for website security and logs, this isn't the best >> option.. I have yet to try Apache, but I have heard it acts in the same >> way - can someone clarify this? >> >> Thanks >> >> Tom >> > > I have to apologize, I deleted the original post, but as I recall you have >the actual forwarding working dandy. The only concern, which everyone has >failed to address, is that you want the NAT'ed web servers to know the >originating IP address for logging and IP-based security. Obviously, the >reason you don't have this now is that the originating request is intercepted >by squid on your gateway machine and then issueing a request to one of the >internel web servers using it's "inside" IP address on the originator's >behalf. You web server only ever sees the proxy's IP address. > The question, then, is how to communicate the originaters IP address to the >web server. I haven't answered previously because I'm no squid expert, but >here is the solution that comes to my head: > > You could hack squid (assuming it doesn't have a knob to do it already) to >include the originating IP address as a HTTP header in the proxied >request. Then, modify your apps on the web server fetch the IP address from >this header (i.e. via environment variable) as opposed to using the value the >web server populates REMOTE_HOST with. However, the IP address in web server >logs will still be that of the proxy unless you teach the web server to >extract the IP from the new header. > Of course, if you have the source to your web server (i.e. apache) then you >could teach it to populate REMOTE_HOST with the IP address obtained from the >squid-supplied header also and have it be transparent to your apps. > > All the said, you would have to take extra precautions in squid to not allow >remote clients to supply the header themselves (i.e. to replace the header if >it exists and add it if it doesn't), but this should be pretty >straightforward. > > I hope that answers your question (assuming I am remembering it correctly >:) ). Good luck! > > Kelly > >-- >Kelly Yancey - kbyanc@{posi.net,FreeBSD.org} > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-net" in the body of the message > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Dec 11 18:33:22 2001 Delivered-To: freebsd-net@freebsd.org Received: from mta3-rme.xtra.co.nz (mta3-rme.xtra.co.nz [210.86.15.131]) by hub.freebsd.org (Postfix) with ESMTP id 94FDD37B405 for ; Tue, 11 Dec 2001 18:33:13 -0800 (PST) Received: from internet1.masaclaw.co.nz ([210.55.57.50]) by mta3-rme.xtra.co.nz with ESMTP id <20011212023311.QMCF4439.mta3-rme.xtra.co.nz@internet1.masaclaw.co.nz>; Wed, 12 Dec 2001 15:33:11 +1300 Message-Id: <5.1.0.14.2.20011212151716.0289a4a8@mail.masaclaw.co.nz> X-Sender: masaclaw@mail.masaclaw.co.nz X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 12 Dec 2001 15:27:01 +1300 To: Kelly Yancey , freebsd-net@FreeBSD.ORG From: Tom Peck Subject: RE: 1 IP - 1 Firewall - 2 Webservers In-Reply-To: References: <5.1.0.14.2.20011212123256.02871e50@mail.masaclaw.co.nz> 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 Hi Kelly! At 18:18 11/12/2001 -0800, you wrote: > I have to apologize, I deleted the original post, but as I recall you have >the actual forwarding working dandy. The only concern, which everyone has >failed to address, is that you want the NAT'ed web servers to know the >originating IP address for logging and IP-based security. Obviously, the >reason you don't have this now is that the originating request is intercepted >by squid on your gateway machine and then issueing a request to one of the >internel web servers using it's "inside" IP address on the originator's >behalf. You web server only ever sees the proxy's IP address. YES! That's exactly the problem! Your memory is obviously far superior to most :-). > The question, then, is how to communicate the originaters IP address to the >web server. I haven't answered previously because I'm no squid expert, but >here is the solution that comes to my head: > > You could hack squid (assuming it doesn't have a knob to do it already) to >include the originating IP address as a HTTP header in the proxied >request. Then, modify your apps on the web server fetch the IP address from >this header (i.e. via environment variable) as opposed to using the value the >web server populates REMOTE_HOST with. However, the IP address in web server >logs will still be that of the proxy unless you teach the web server to >extract the IP from the new header. Ok, now we are getting over my head some what.. Installing from source is one thing, but modifying that source before installing is another - beyond what I am willing and capable to do... > Of course, if you have the source to your web server (i.e. apache) then you >could teach it to populate REMOTE_HOST with the IP address obtained from the >squid-supplied header also and have it be transparent to your apps. And if we don't :-( One of the servers has a pre-complied OS which cannot be altered in this way. Surely there must be a simpler way!! > All the said, you would have to take extra precautions in squid to not > allow >remote clients to supply the header themselves (i.e. to replace the header if >it exists and add it if it doesn't), but this should be pretty >straightforward. > > I hope that answers your question (assuming I am remembering it correctly >:) ). Good luck! Thanks for the time taken in responding to my problem. Unfortunately we are not prepared to go to these lengths to get the thing working how we would like it.. I'm quite surprised there isn't something available to make this feasible. Cheers Tom To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Dec 11 18:36:36 2001 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 4C8DA37B405 for ; Tue, 11 Dec 2001 18:36:32 -0800 (PST) Received: from attbi.com ([127.0.0.1]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20011212023632.MKP1691.rwcrmhc52.attbi.com@attbi.com>; Wed, 12 Dec 2001 02:36:32 +0000 Received: from gateway.posi.net (12-236-90-177.client.attbi.com[12.236.90.177]) by attbi.com (rwcrmhc52) with ESMTP id <200112120236310520013u1fe>; Wed, 12 Dec 2001 02:36:31 +0000 Received: from localhost (kbyanc@localhost) by gateway.posi.net (8.11.6/8.11.6) with ESMTP id fBC2aU130473; Tue, 11 Dec 2001 18:36:30 -0800 (PST) (envelope-from kbyanc@posi.net) X-Authentication-Warning: gateway.posi.net: kbyanc owned process doing -bs Date: Tue, 11 Dec 2001 18:36:30 -0800 (PST) From: Kelly Yancey To: Tom Peck Cc: Julian Elischer , freebsd-net@FreeBSD.ORG Subject: RE: 1 IP - 1 Firewall - 2 Webservers 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 A quick search of google revealed that there is an apache module for this specific purpose: http://web.systhug.com/mod_extract_forwarded/. So, if you are using apache, this appears to do everything you need on the web-server side. You might want to also look at the squid FAQ: http://www.squid-cache.org/Doc/FAQ/FAQ-4.html#ss4.17 Kelly -- Kelly Yancey - kbyanc@{posi.net,FreeBSD.org} On Tue, 11 Dec 2001, Kelly Yancey wrote: > On Wed, 12 Dec 2001, Tom Peck wrote: > > > Hi Julian > > > > Yes, we currently have Squid serving this purpose - but as I stated in my > > first email, ALL incoming Client IP's and Addresses are always that of the > > GATEWAY_BOX - so for website security and logs, this isn't the best > > option.. I have yet to try Apache, but I have heard it acts in the same > > way - can someone clarify this? > > > > Thanks > > > > Tom > > > > I have to apologize, I deleted the original post, but as I recall you have > the actual forwarding working dandy. The only concern, which everyone has > failed to address, is that you want the NAT'ed web servers to know the > originating IP address for logging and IP-based security. Obviously, the > reason you don't have this now is that the originating request is intercepted > by squid on your gateway machine and then issueing a request to one of the > internel web servers using it's "inside" IP address on the originator's > behalf. You web server only ever sees the proxy's IP address. > The question, then, is how to communicate the originaters IP address to the > web server. I haven't answered previously because I'm no squid expert, but > here is the solution that comes to my head: > > You could hack squid (assuming it doesn't have a knob to do it already) to > include the originating IP address as a HTTP header in the proxied > request. Then, modify your apps on the web server fetch the IP address from > this header (i.e. via environment variable) as opposed to using the value the > web server populates REMOTE_HOST with. However, the IP address in web server > logs will still be that of the proxy unless you teach the web server to > extract the IP from the new header. > Of course, if you have the source to your web server (i.e. apache) then you > could teach it to populate REMOTE_HOST with the IP address obtained from the > squid-supplied header also and have it be transparent to your apps. > > All the said, you would have to take extra precautions in squid to not allow > remote clients to supply the header themselves (i.e. to replace the header if > it exists and add it if it doesn't), but this should be pretty > straightforward. > > I hope that answers your question (assuming I am remembering it correctly > :) ). Good luck! > > Kelly > > -- > Kelly Yancey - kbyanc@{posi.net,FreeBSD.org} To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Dec 11 19: 4:38 2001 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 2411237B417 for ; Tue, 11 Dec 2001 19:04:31 -0800 (PST) Received: from attbi.com ([127.0.0.1]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20011212030431.BQAY2616.rwcrmhc53.attbi.com@attbi.com>; Wed, 12 Dec 2001 03:04:31 +0000 Received: from gateway.posi.net (12-236-90-177.client.attbi.com[12.236.90.177]) by attbi.com (rwcrmhc53) with ESMTP id <200112120304300530029e0fe>; Wed, 12 Dec 2001 03:04:30 +0000 Received: from localhost (kbyanc@localhost) by gateway.posi.net (8.11.6/8.11.6) with ESMTP id fBC34K030512; Tue, 11 Dec 2001 19:04:21 -0800 (PST) (envelope-from kbyanc@posi.net) X-Authentication-Warning: gateway.posi.net: kbyanc owned process doing -bs Date: Tue, 11 Dec 2001 19:04:20 -0800 (PST) From: Kelly Yancey To: Tom Peck Cc: freebsd-net@FreeBSD.ORG Subject: RE: 1 IP - 1 Firewall - 2 Webservers In-Reply-To: <5.1.0.14.2.20011212151716.0289a4a8@mail.masaclaw.co.nz> 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, 12 Dec 2001, Tom Peck wrote: > YES! That's exactly the problem! Your memory is obviously far superior to > most :-). > That's a scary proposition indeed! :) > > Of course, if you have the source to your web server (i.e. apache) then you > >could teach it to populate REMOTE_HOST with the IP address obtained from the > >squid-supplied header also and have it be transparent to your apps. > > And if we don't :-( One of the servers has a pre-complied OS which cannot > be altered in this way. Surely there must be a simpler way!! > Ack. Alright, see my previous post regarding squid, that part of the configuration should be simple. With squid supplying the information in the HTTP headers, the only matter left is getting the web server or web application to extract that information and to use that for the REMOTE_HOST IP. Perhaps you could share with us what web server you are using (again, I apologize if you included that in your original message). Also, do you just need a custom app to pick up the originating client's IP address or do you also need it to be logged or used in web server-supplied IP-based security? The former would be simple to solve that the app should just have to be modified to obtain the client's IP from the header. For logging, many web servers allow you to customize the log format to include the value associated with a given HTTP header (so you could log the X-Forwarded-For header). If you need it from web server-supplied IP-based security, you're probably out of luck. In this case, the web server would have to supply a knob to enable this behaviour. > Thanks for the time taken in responding to my problem. Unfortunately we > are not prepared to go to these lengths to get the thing working how we > would like it.. I'm quite surprised there isn't something available to > make this feasible. > There is the capability in the open-source tools :): squid supplies the information and apache, by means of the mod_extract_fordward module, can extract it so everything is transparent. The only issue at hand is whether your closed-source web server can be made to extract the information. :| Just to recap: The issue is that normally web servers obtain the client's IP address from the source IP of the HTTP connection. However, in your setup, the proxy receives the request (and therefor knows the client's IP), but it then reissues the request using it's inside IP to your NAT'ed web server. The web server only ever receives these proxied requests, therefor the web server always gets the same source IP on all of it's incoming HTTP connections: that of the proxy. Because of this, you need some way to communicate the client IP information from the proxy to the web server, and a way to configure the web server to switch from obtaining the IP from the HTTP connection and instead obtain it from the proxy-supplied data. The first half of the puzzle is solved; squid can pass the client IP via a HTTP header (X-Forwarded-For). All you need is a solution for the latter half of the puzzle. All that said, I don't suspect too many commerical web servers are going to supply such a knob due to the potential security issues. Forging a X-Forward-For header is far more trivial than forging the source address of a HTTP connection. In your scenario, I don't think it's an issue so long as you only honor the last IP in the X-Forwarded-For's IP address list (the one your trusted squid cache added). But commercial vendors don't necessarily have your scenario on their radar. :| Kelly -- Kelly Yancey - kbyanc@{posi.net,FreeBSD.org} To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Dec 11 19: 7:28 2001 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 9AC1837B417 for ; Tue, 11 Dec 2001 19:07:08 -0800 (PST) Received: (from root@localhost) by cage.simianscience.com (8.11.6/8.11.6) id fBC377m99521; Tue, 11 Dec 2001 22:07:07 -0500 (EST) (envelope-from mike@sentex.net) Received: from chimp.sentex.net (fcage [192.168.0.2]) by cage.simianscience.com (8.11.6/8.11.6av) with ESMTP id fBC374k99513; Tue, 11 Dec 2001 22:07:04 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <5.1.0.14.0.20011211220210.046d3a88@192.168.0.12> X-Sender: mdtancsa@192.168.0.12 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 11 Dec 2001 22:07:03 -0500 To: Luigi Rizzo From: Mike Tancsa Subject: Re: Polling code at http://info.iet.unipi.it/~luigi/polling/ Cc: net@freebsd.org In-Reply-To: <20011211161454.B23443@iguana.aciri.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by AMaViS perl-10 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, it looks like it patches OK, but when compiling, ruby3# make cc -c -x assembler-with-cpp -DLOCORE -O -pipe -march=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../../include -I../../contrib/ipfilter -D_KERNEL -include opt_global.h -elf -mpreferred-stack-boundary=2 ../../i386/i386/locore.s cc -c -O -pipe -march=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../../include -I../../contrib/ipfilter -D_KERNEL -include opt_global.h -elf -mpreferred-stack-boundary=2 device_if.c cc -c -O -pipe -march=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../../include -I../../contrib/ipfilter -D_KERNEL -include opt_global.h -elf -mpreferred-stack-boundary=2 bus_if.c cc -c -O -pipe -march=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../../include -I../../contrib/ipfilter -D_KERNEL -include opt_global.h -elf -mpreferred-stack-boundary=2 ../../dev/fxp/if_fxp.c ../../dev/fxp/if_fxp.c: In function `fxp_intr': ../../dev/fxp/if_fxp.c:1198: `IFF_POLLING' undeclared (first use in this function) ../../dev/fxp/if_fxp.c:1198: (Each undeclared identifier is reported only once ../../dev/fxp/if_fxp.c:1198: for each function it appears in.) ../../dev/fxp/if_fxp.c: In function `fxp_init': ../../dev/fxp/if_fxp.c:1754: `IFF_POLLING' undeclared (first use in this function) *** Error code 1 Stop in /usr/src/sys/compile/ruby. ruby3# This is after a config -r, make depend etc... I do have options HZ=1000 options DEVICE_POLLING in my kernel config The patch seems to apply OK. ruby3# patch -p < stable.011210c.diffs Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: sys/conf/options.i386 |=================================================================== |RCS file: /home/ncvs/src/sys/conf/options.i386,v |retrieving revision 1.132.2.10 |diff -u -r1.132.2.10 options.i386 |--- sys/conf/options.i386 8 Dec 2001 00:04:13 -0000 1.132.2.10 |+++ sys/conf/options.i386 11 Dec 2001 07:32:45 -0000 -------------------------- Patching file sys/conf/options.i386 using Plan A... Hunk #1 succeeded at 209 (offset 1 line). Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: sys/dev/fxp/if_fxp.c |=================================================================== |RCS file: /home/ncvs/src/sys/dev/fxp/if_fxp.c,v |retrieving revision 1.110.2.13 |diff -u -r1.110.2.13 if_fxp.c |--- sys/dev/fxp/if_fxp.c 8 Dec 2001 00:04:13 -0000 1.110.2.13 |+++ sys/dev/fxp/if_fxp.c 11 Dec 2001 07:32:46 -0000 -------------------------- Patching file sys/dev/fxp/if_fxp.c using Plan A... Hunk #1 succeeded at 170. Hunk #2 succeeded at 1150. Hunk #3 succeeded at 1192. Hunk #4 succeeded at 1227. Hunk #5 succeeded at 1282. Hunk #6 succeeded at 1746. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: sys/i386/i386/swtch.s |=================================================================== |RCS file: /home/ncvs/src/sys/i386/i386/swtch.s,v |retrieving revision 1.89.2.6 |diff -u -r1.89.2.6 swtch.s |--- sys/i386/i386/swtch.s 8 Dec 2001 00:04:14 -0000 1.89.2.6 |+++ sys/i386/i386/swtch.s 11 Dec 2001 07:32:48 -0000 -------------------------- Patching file sys/i386/i386/swtch.s using Plan A... Hunk #1 succeeded at 246. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: sys/i386/include/asnames.h |=================================================================== |RCS file: /home/ncvs/src/sys/i386/include/Attic/asnames.h,v |retrieving revision 1.44.2.5 |diff -u -r1.44.2.5 asnames.h |--- sys/i386/include/asnames.h 8 Dec 2001 00:04:14 -0000 1.44.2.5 |+++ sys/i386/include/asnames.h 11 Dec 2001 07:32:48 -0000 -------------------------- Patching file sys/i386/include/asnames.h using Plan A... Hunk #1 succeeded at 225. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: sys/kern/kern_clock.c |=================================================================== |RCS file: /home/ncvs/src/sys/kern/kern_clock.c,v |retrieving revision 1.105.2.6 |diff -u -r1.105.2.6 kern_clock.c |--- sys/kern/kern_clock.c 8 Dec 2001 00:04:14 -0000 1.105.2.6 |+++ sys/kern/kern_clock.c 11 Dec 2001 07:32:49 -0000 -------------------------- Patching file sys/kern/kern_clock.c using Plan A... Hunk #1 succeeded at 67. Hunk #2 succeeded at 202. Hunk #3 succeeded at 255. Hunk #4 succeeded at 1035. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: sys/net/netisr.h |=================================================================== |RCS file: /home/ncvs/src/sys/net/netisr.h,v |retrieving revision 1.21.2.3 |diff -u -r1.21.2.3 netisr.h |--- sys/net/netisr.h 4 Dec 2001 05:57:40 -0000 1.21.2.3 |+++ sys/net/netisr.h 11 Dec 2001 07:32:55 -0000 -------------------------- Patching file sys/net/netisr.h using Plan A... Hunk #1 succeeded at 61 (offset -1 lines). Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: sys/pci/if_dc.c |=================================================================== |RCS file: /home/ncvs/src/sys/pci/if_dc.c,v |retrieving revision 1.9.2.30 |diff -u -r1.9.2.30 if_dc.c |--- sys/pci/if_dc.c 11 Dec 2001 03:02:48 -0000 1.9.2.30 |+++ sys/pci/if_dc.c 11 Dec 2001 07:32:56 -0000 -------------------------- Patching file sys/pci/if_dc.c using Plan A... Hunk #1 succeeded at 2319. Hunk #2 succeeded at 2634. Hunk #3 succeeded at 2698. Hunk #4 succeeded at 3049. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: sys/pci/if_dcreg.h |=================================================================== |RCS file: /home/ncvs/src/sys/pci/if_dcreg.h,v |retrieving revision 1.4.2.13 |diff -u -r1.4.2.13 if_dcreg.h |--- sys/pci/if_dcreg.h 8 Dec 2001 00:04:15 -0000 1.4.2.13 |+++ sys/pci/if_dcreg.h 11 Dec 2001 07:32:56 -0000 -------------------------- Patching file sys/pci/if_dcreg.h using Plan A... Hunk #1 succeeded at 429. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: sys/pci/if_sis.c |=================================================================== |RCS file: /home/ncvs/src/sys/pci/if_sis.c,v |retrieving revision 1.13.4.14 |diff -u -r1.13.4.14 if_sis.c |--- sys/pci/if_sis.c 8 Dec 2001 00:04:15 -0000 1.13.4.14 |+++ sys/pci/if_sis.c 11 Dec 2001 07:32:56 -0000 -------------------------- Patching file sys/pci/if_sis.c using Plan A... Hunk #1 succeeded at 1100. Hunk #2 succeeded at 1274. Hunk #3 succeeded at 1330. Hunk #4 succeeded at 1615. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: sys/pci/if_sisreg.h |=================================================================== |RCS file: /home/ncvs/src/sys/pci/if_sisreg.h,v |retrieving revision 1.1.4.6 |diff -u -r1.1.4.6 if_sisreg.h |--- sys/pci/if_sisreg.h 8 Dec 2001 00:04:15 -0000 1.1.4.6 |+++ sys/pci/if_sisreg.h 11 Dec 2001 07:32:56 -0000 -------------------------- Patching file sys/pci/if_sisreg.h using Plan A... Hunk #1 succeeded at 402. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: sys/sys/systm.h |=================================================================== |RCS file: /home/ncvs/src/sys/sys/systm.h,v |retrieving revision 1.111.2.12 |diff -u -r1.111.2.12 systm.h |--- sys/sys/systm.h 8 Dec 2001 00:04:16 -0000 1.111.2.12 |+++ sys/sys/systm.h 11 Dec 2001 07:32:56 -0000 -------------------------- Patching file sys/sys/systm.h using Plan A... Hunk #1 succeeded at 88. done ruby3# At 04:14 PM 12/11/2001 -0800, Luigi Rizzo wrote: >[Bcc to committers and -stable as relevant there, but >please keep the discussion on -net if any] > >I have put up a web page with the latest version of the device >polling patches, both for -stable and -current, at > > http://info.iet.unipi.it/~luigi/polling/ > >so new versions will be available through there, together with >additional documentation, code and references. > >Compared to the code recently pulled out from -stable, what you >can find now at the above URL has the following improvements: > > * "scheduling" code which lets you control in a reasonably > fine-grained way the sharing of CPU between kernel (polling) > and userland. You can now do something like > > sysctl kern.polling.user_frac=40 > > to reserve 40% of the CPU time to userland processes > (assuming there is enough work to do). Default value is 50. > > * a restructured polling loop which prevents livelock and > unfairness even when the standard (no fastforwarding) path > is used. > >Together with the kern.polling.enable variable, kern.polling.user_frac >is the only tunable parameter that you need to care about, and the >default value should be a reasonable one. > >It would be great if some of you committers would have the time to >have a look at the -current version, or possibly even try it on >Alpha boxes (I think overall there is only one or two lines of MD >code), and send feedback. > > thanks > luigi >----------------------------------+----------------------------------------- > Luigi RIZZO, luigi@iet.unipi.it . ACIRI/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-stable" in the body of the message -------------------------------------------------------------------- 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 Dec 11 19:16:57 2001 Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 80AA237B41E for ; Tue, 11 Dec 2001 19:16:52 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.3/8.11.1) id fBC3Gob25400; Tue, 11 Dec 2001 19:16:50 -0800 (PST) (envelope-from rizzo) Date: Tue, 11 Dec 2001 19:16:50 -0800 From: Luigi Rizzo To: Mike Tancsa Cc: net@freebsd.org Subject: Re: Polling code at http://info.iet.unipi.it/~luigi/polling/ Message-ID: <20011211191650.I23443@iguana.aciri.org> References: <20011211161454.B23443@iguana.aciri.org> <5.1.0.14.0.20011211220210.046d3a88@192.168.0.12> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.1.0.14.0.20011211220210.046d3a88@192.168.0.12> User-Agent: Mutt/1.3.23i 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, Dec 11, 2001 at 10:07:03PM -0500, Mike Tancsa wrote: > > Hi, it looks like it patches OK, but when compiling, Whoops... missing one chunk for net/if.h, I have updated the web page and the patchfile, or you can just apply the following: cheers luigi Index: if.h =================================================================== RCS file: /home/xorpc/u2/freebsd/src/sys/net/if.h,v retrieving revision 1.58.2.4 diff -u -r1.58.2.4 if.h --- sys/net/if.h 2001/12/08 00:04:15 1.58.2.4 +++ sys/net/if.h 2001/12/04 05:57:40 @@ -130,6 +130,15 @@ #define IFF_LINK2 0x4000 /* per link layer defined bit */ #define IFF_ALTPHYS IFF_LINK2 /* use alternate physical connec tion */ #define IFF_MULTICAST 0x8000 /* supports multicast */ + +/* + * The following flag(s) ought to go in if_flags, but we cannot change + * struct ifnet because of binary compatibility, so we store them in + * if_ipending, which is not used so far. + * If possible, make sure the value is not conflicting with other + * IFF flags, so we have an easier time when we want to merge them. + */ +#define IFF_POLLING 0x10000 /* Interface is in polling mode. */ /* flags set internally only: */ #define IFF_CANTCHANGE \ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 12 1:31: 5 2001 Delivered-To: freebsd-net@freebsd.org Received: from proxy.omp.cz (wg-zl-omp.inext.cz [212.111.5.212]) by hub.freebsd.org (Postfix) with ESMTP id 9363437B417 for ; Wed, 12 Dec 2001 01:30:58 -0800 (PST) Received: from hornet ([192.168.1.111]) by proxy.omp.cz (8.9.3/8.9.3) with SMTP id KAA00492 for ; Wed, 12 Dec 2001 10:58:43 +0100 (CET) (envelope-from maan@omp.cz) Message-ID: <007901c182ef$fb013700$6f01a8c0@hornet> From: "maan" To: Subject: redirect_port Date: Wed, 12 Dec 2001 10:32:54 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0076_01C182F8.5BCC9900" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a multi-part message in MIME format. ------=_NextPart_000_0076_01C182F8.5BCC9900 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I need your help. I can redirect port 3389 for MS terminal server. I have FreeBsd 3.4. I read manual for natd and for NAT. =20 I do=20 natd -redirect_port tcp 192.168.1.20:3389 3389 -interface ep0=20 There is no error. But I cannot conection on 192.168.1.20 from outside. Can You Help me? Thanks. Antonin Majtner ------=_NextPart_000_0076_01C182F8.5BCC9900 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 I=20 need your help. I can redirect port 3389 for MS terminal = server.
 I have=20 FreeBsd 3.4.
 I read manual for natd and for NAT.
 
= I=20 do 
natd -redirect_port tcp 192.168.1.20:3389 3389 -interface=20 ep0 
There is no error.
 But I cannot conection on = 192.168.1.20=20 from  outside.
 Can You Help me?
Thanks.
Antonin = Majtner
------=_NextPart_000_0076_01C182F8.5BCC9900-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 12 4:49:50 2001 Delivered-To: freebsd-net@freebsd.org Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by hub.freebsd.org (Postfix) with ESMTP id 854AC37B50B for ; Wed, 12 Dec 2001 04:49:43 -0800 (PST) Received: from europe.cisco.com (europe.cisco.com [144.254.52.73]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id fBCCng615131 for ; Wed, 12 Dec 2001 04:49:42 -0800 (PST) Received: from cobweb.example.org (dhcp-nic-val-26-134.cisco.com [64.103.26.134]) by europe.cisco.com (8.8.8+Sun/8.8.8) with SMTP id NAA18563 for ; Wed, 12 Dec 2001 13:49:41 +0100 (MET) Received: (qmail 7036 invoked by uid 1000); 12 Dec 2001 12:49:41 -0000 Date: Wed, 12 Dec 2001 13:49:41 +0100 From: Marco Molteni To: romain@cuivre.fr.eu.org Cc: net@FreeBSD.ORG Subject: Re: SCTP Message-ID: <20011212134941.A4544@cobweb.example.org> References: <20011211190756.A52248@gargantua.dyndns.org> <20011211194248.A54901@gargantua.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011211194248.A54901@gargantua.dyndns.org>; from romain@gargantua.dyndns.org on Tue, Dec 11, 2001 at 07:42:49PM +0100 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 2001-12-11, Romain Berrendonner wrote: > Le 2001-12-11 19:07 UTC+0100, Romain Berrendonner a ecrit: > > Hi all, > > > > Does anybody know a SCTP (RFC XXXX) implementation in FreeBSD ? > > > Off course, I meant 8) > > RFC 2960 Stream Control Transmission Protocol. R. Stewart, Q. Xie, K. > Morneault, C. Sharp, H. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, > L. Zhang, V. Paxson. October 2000. (Format: TXT=297757 bytes) > (Status: PROPOSED STANDARD) There is the SCTP reference implementation by Stewart and Xie http://www.sctp.org/ I think Randall Stewart (Hi Randall) is on -net too and may chime in. marco To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 12 9:50:14 2001 Delivered-To: freebsd-net@freebsd.org Received: from bungo.sgn.sca.se (bungo.sgn.sca.se [193.221.76.5]) by hub.freebsd.org (Postfix) with ESMTP id 447D337B42F for ; Wed, 12 Dec 2001 09:49:57 -0800 (PST) Received: from narya.sgn.sca.se (root@narya.sgn.sca.se [10.192.24.4]) by bungo.sgn.sca.se (8.11.6/8.11.6) with ESMTP id fBCHp1Q16440 for ; Wed, 12 Dec 2001 12:51:01 -0500 (EST) Received: from joed2000 ([172.24.60.7]) by narya.sgn.sca.se (8.11.6/8.11.6) with SMTP id fBCEFjB33811; Wed, 12 Dec 2001 08:15:45 -0600 (CST) Reply-To: From: "Edstrom Johan" To: "Lars Eggert" , "Tom Peck" Cc: Subject: RE: 1 IP - 1 Firewall - 2 Webservers Date: Wed, 12 Dec 2001 08:13:28 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3C168E66.5080702@isi.edu> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 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 perhaps should have read all of the mail..... Well - Squid got X-Forwarded for, And that't easy to configure Apache to look into, I believe that the newer IIS server if that's used also are quite good at that type of access. If I remember correctly doing a reverse proxy under Apache would (with the proxy-pass-reverse) produce pretty much the same result. But another thing comes to mind, squid do produce quite nice logs as well? /JE Unix is like a wigwam - no gates, no windows, apache inside ################################## Johan Edstrom, SCA IT Services johan.edstrom@sca.com Tel : +1 920 727 8821 Fax : +1 920 727 8810 Cell : +1 920 205 6472 ################################## > -----Original Message----- > From: owner-freebsd-net@FreeBSD.ORG > [mailto:owner-freebsd-net@FreeBSD.ORG]On Behalf Of Lars Eggert > Sent: Tuesday, December 11, 2001 2:53 PM > To: Tom Peck > Cc: johan.edstrom@sca.com; freebsd-net@FreeBSD.ORG > Subject: Re: 1 IP - 1 Firewall - 2 Webservers > > > Tom Peck wrote: > > > How would this work? The two web servers aren't accessible straight > > from the Internet - traffic goes via the gateway box. > > I bet he forgot to mention that the gateway is also a NAT box. Since > squid does app-level relaying, HTTP isn't affected. > > Lars > -- > Lars Eggert Information Sciences Institute > http://www.isi.edu/larse/ University of Southern California > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 12 12:16:23 2001 Delivered-To: freebsd-net@freebsd.org Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by hub.freebsd.org (Postfix) with ESMTP id 642E737B419 for ; Wed, 12 Dec 2001 12:16:19 -0800 (PST) Received: from stannous-ultra.cisco.com (stannous-ultra.cisco.com [64.102.40.156]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id fBCKGFo04279; Wed, 12 Dec 2001 12:16:16 -0800 (PST) Received: (stannous@localhost) by stannous-ultra.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA29150; Wed, 12 Dec 2001 15:15:58 -0500 (EST) Date: Wed, 12 Dec 2001 15:15:58 -0500 From: Sam Tannous To: Brooks Davis Cc: freebsd-net@FreeBSD.ORG Subject: Re: ti driver, vlan and tcpdump Message-ID: <20011212151557.J28904@cisco.com> References: <20011115132222.B17252@Odin.AC.HMC.Edu> <01111515412101.00586@shaggy.doo.com> <20011115134207.A26868@Odin.AC.HMC.Edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <20011115134207.A26868@Odin.AC.HMC.Edu>; from brooks@one-eyed-alien.net on Thu, Nov 15, 2001 at 01:42:07PM -0800 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, Nov 15, 2001 at 01:42:07PM -0800, Brooks Davis wrote: > On Thu, Nov 15, 2001 at 03:41:21PM -0600, Shaun Marko wrote: > > Could you also get the desired result by using a kernel without > > VLAN support? > > The original poster said he didn't want to configure VLAN interfaces > > anyway. > For the moment, on stable hosts, that will work. Driver vlan support is > no longer optional in current and that change will be MFC'd just as soon > as I get it tested. The right answer is probably to modify the > VLAN_INPUT_TAG macro to do the bpf stuff. > is there a way to turn off driver VLAN support? (I don't object to having it on by default. I just want to be able to turn it off so I can see *all* the vlan traffic with tcpdump/libpcap (even if I have VLAN turned on in my kernel)). Thanks, Sam To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 12 12:26:31 2001 Delivered-To: freebsd-net@freebsd.org Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by hub.freebsd.org (Postfix) with ESMTP id F1F3D37B405 for ; Wed, 12 Dec 2001 12:26:25 -0800 (PST) Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.11.0/8.11.0) id fBCKQNW03223; Wed, 12 Dec 2001 12:26:23 -0800 Date: Wed, 12 Dec 2001 12:26:23 -0800 From: Brooks Davis To: Sam Tannous Cc: freebsd-net@FreeBSD.ORG Subject: Re: ti driver, vlan and tcpdump Message-ID: <20011212122620.A2030@Odin.AC.HMC.Edu> References: <20011115132222.B17252@Odin.AC.HMC.Edu> <01111515412101.00586@shaggy.doo.com> <20011115134207.A26868@Odin.AC.HMC.Edu> <20011212151557.J28904@cisco.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="HlL+5n6rz5pIUxbD" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011212151557.J28904@cisco.com>; from stannous@cisco.com on Wed, Dec 12, 2001 at 03:15:58PM -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 --HlL+5n6rz5pIUxbD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 12, 2001 at 03:15:58PM -0500, Sam Tannous wrote: > On Thu, Nov 15, 2001 at 01:42:07PM -0800, Brooks Davis wrote: > > On Thu, Nov 15, 2001 at 03:41:21PM -0600, Shaun Marko wrote: > > > Could you also get the desired result by using a kernel without=20 > > > VLAN support? > > > The original poster said he didn't want to configure VLAN interfaces= =20 > > > anyway. > > For the moment, on stable hosts, that will work. Driver vlan support is > > no longer optional in current and that change will be MFC'd just as soon > > as I get it tested. The right answer is probably to modify the > > VLAN_INPUT_TAG macro to do the bpf stuff. > >=20 >=20 > is there a way to turn off driver VLAN support? >=20 > (I don't object to having it on by default. =20 > I just want to be able to turn it off > so I can see *all* the vlan traffic with tcpdump/libpcap > (even if I have VLAN turned on in my kernel)). In current there's an interface capability configuration system that is used to enable and disable things like hardware checksum support. I intend to look at adding a bit to control hardware VLAN decoding. Unfortunatly it won't be possiable to MFC this without a rule change because it would break all binary network drivers. We do plan to modify vlan_input_tag to fake up a vlan header and pass the packet to bfp so you will be able to tap hardware decoded vlan frames. I'm not sure it this will be enabled by default or not. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --HlL+5n6rz5pIUxbD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8F71sXY6L6fI4GtQRAjZ4AKC2K+rR4I2e0txf7u08WQ7Nfaq4ZQCfQBet tzCHOUWvKlZqZ6N/TLVAuL8= =BN+H -----END PGP SIGNATURE----- --HlL+5n6rz5pIUxbD-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 12 13:31:32 2001 Delivered-To: freebsd-net@freebsd.org Received: from mta4-rme.xtra.co.nz (mta4-rme.xtra.co.nz [210.86.15.132]) by hub.freebsd.org (Postfix) with ESMTP id BE13637B405 for ; Wed, 12 Dec 2001 13:31:16 -0800 (PST) Received: from internet1.paradise.net.nz ([210.55.57.50]) by mta4-rme.xtra.co.nz with ESMTP id <20011212213114.SRTG24850.mta4-rme.xtra.co.nz@internet1.paradise.net.nz> for ; Thu, 13 Dec 2001 10:31:14 +1300 Message-Id: <5.1.0.14.2.20011213102454.0280ee78@pop3.paradise.net.nz> X-Sender: tompeck@pop3.paradise.net.nz X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 13 Dec 2001 10:25:04 +1300 To: freebsd-net@FreeBSD.ORG From: Tom Subject: RE: 1 IP - 1 Firewall - 2 Webservers 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 19:04 11/12/2001 -0800, you wrote: >On Wed, 12 Dec 2001, Tom Peck wrote: > > > YES! That's exactly the problem! Your memory is obviously far superior to > > most :-). > > > > That's a scary proposition indeed! :) > > > > Of course, if you have the source to your web server (i.e. apache) > then you > > >could teach it to populate REMOTE_HOST with the IP address obtained > from the > > >squid-supplied header also and have it be transparent to your apps. > > > > And if we don't :-( One of the servers has a pre-complied OS which cannot > > be altered in this way. Surely there must be a simpler way!! > > > > Ack. Alright, see my previous post regarding squid, that part of the >configuration should be simple. With squid supplying the information in the >HTTP headers, the only matter left is getting the web server or web >application to extract that information and to use that for the REMOTE_HOST >IP. Perhaps you could share with us what web server you are using (again, I >apologize if you included that in your original message). > Also, do you just need a custom app to pick up the originating client's IP >address or do you also need it to be logged or used in web server-supplied >IP-based security? The former would be simple to solve that the app should >just have to be modified to obtain the client's IP from the header. For >logging, many web servers allow you to customize the log format to include the >value associated with a given HTTP header (so you could log the >X-Forwarded-For header). If you need it from web server-supplied IP-based >security, you're probably out of luck. In this case, the web server would have >to supply a knob to enable this behaviour. > > > Thanks for the time taken in responding to my problem. Unfortunately we > > are not prepared to go to these lengths to get the thing working how we > > would like it.. I'm quite surprised there isn't something available to > > make this feasible. > > > > There is the capability in the open-source tools :): squid supplies the >information and apache, by means of the mod_extract_fordward module, can >extract it so everything is transparent. The only issue at hand is whether >your closed-source web server can be made to extract the information. :| Well, ok, I lied - it's not exactly closed source. One of the machines is a freeBSD 4.4 webserver, which would not be a problem, and the other is an SME / e-smith 5.0 server - which is basically a linux server in a box - but without all the necessary tools to do source installs etc. I've been reluctant to have to muck around with the server too much as it works perfectly as it is. Would it be possible to apply the Mod without having to re-compile and re-install apache? > Just to recap: > The issue is that normally web servers obtain the client's IP address from >the source IP of the HTTP connection. However, in your setup, the proxy >receives the request (and therefor knows the client's IP), but it then >reissues the request using it's inside IP to your NAT'ed web server. The web >server only ever receives these proxied requests, therefor the web server >always gets the same source IP on all of it's incoming HTTP connections: that >of the proxy. Yes, you have the gift of explaining things too :-) > Because of this, you need some way to communicate the client IP information >from the proxy to the web server, and a way to configure the web server to >switch from obtaining the IP from the HTTP connection and instead obtain it >from the proxy-supplied data. The first half of the puzzle is solved; squid >can pass the client IP via a HTTP header (X-Forwarded-For). All you need is a >solution for the latter half of the puzzle. Yep it looks that way. My network dude has already setup Squid for this purpose, so we ARE halfway there! > All that said, I don't suspect too many commerical web servers are going to >supply such a knob due to the potential security issues. Forging a >X-Forward-For header is far more trivial than forging the source address of a >HTTP connection. In your scenario, I don't think it's an issue so long as you >only honor the last IP in the X-Forwarded-For's IP address list (the one your >trusted squid cache added). But commercial vendors don't necessarily have your >scenario on their radar. :| Well, running Apache I'm sure it can be done - but this depends on the methods which have to be taken to have it up and running. I have posted a message on the e-smith forum about adding mods to an already installed Apache server - but they are pretty slow at responding to things over there - so someone here can probably shed some light for me :-) Again Kelly, thanks for the time spent - I really do love the open-source community and their willingness to help. Tom To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 12 13:31:38 2001 Delivered-To: freebsd-net@freebsd.org Received: from mta2-rme.xtra.co.nz (mta2-rme.xtra.co.nz [210.86.15.130]) by hub.freebsd.org (Postfix) with ESMTP id DF88937B416 for ; Wed, 12 Dec 2001 13:31:27 -0800 (PST) Received: from internet1.masaclaw.co.nz ([210.55.57.50]) by mta2-rme.xtra.co.nz with ESMTP id <20011212213125.UYZI20016.mta2-rme.xtra.co.nz@internet1.masaclaw.co.nz> for ; Thu, 13 Dec 2001 10:31:25 +1300 Message-Id: <5.1.0.14.2.20011213102507.02807928@mail.masaclaw.co.nz> X-Sender: masaclaw@mail.masaclaw.co.nz X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 13 Dec 2001 10:25:15 +1300 To: freebsd-net@FreeBSD.ORG From: Tom Peck Subject: RE: 1 IP - 1 Firewall - 2 Webservers 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 Hi Johan At 08:13 12/12/2001 -0800, you wrote: >I perhaps should have read all of the mail..... > >Well - Squid got X-Forwarded for, >And that't easy to configure Apache to look into, I believe that the >newer IIS server if that's used also are quite good at that type of >access. > >If I remember correctly doing a reverse proxy under Apache would >(with the proxy-pass-reverse) produce pretty much the same result. > >But another thing comes to mind, squid do produce quite nice logs >as well? It would, but I would prefer to save the gateways recourses (log files can become quite large..) and to have each web server looking after it's own logs - so basically once the gateway box has been configured, it should never need to be touched again. Tom >/JE > > >Unix is like a wigwam - no gates, no windows, apache inside > >################################## > Johan Edstrom, SCA IT Services > johan.edstrom@sca.com > Tel : +1 920 727 8821 > Fax : +1 920 727 8810 > Cell : +1 920 205 6472 >################################## > > > -----Original Message----- > > From: owner-freebsd-net@FreeBSD.ORG > > [mailto:owner-freebsd-net@FreeBSD.ORG]On Behalf Of Lars Eggert > > Sent: Tuesday, December 11, 2001 2:53 PM > > To: Tom Peck > > Cc: johan.edstrom@sca.com; freebsd-net@FreeBSD.ORG > > Subject: Re: 1 IP - 1 Firewall - 2 Webservers > > > > > > Tom Peck wrote: > > > > > How would this work? The two web servers aren't accessible straight > > > from the Internet - traffic goes via the gateway box. > > > > I bet he forgot to mention that the gateway is also a NAT box. Since > > squid does app-level relaying, HTTP isn't affected. > > > > Lars > > -- > > Lars Eggert Information Sciences Institute > > http://www.isi.edu/larse/ University of Southern California > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-net" in the body of the message > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 12 14:22: 6 2001 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 8801437B417 for ; Wed, 12 Dec 2001 14:22:04 -0800 (PST) Received: from gateway.posi.net ([12.236.90.177]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20011212222203.INFN403.rwcrmhc52.attbi.com@gateway.posi.net>; Wed, 12 Dec 2001 22:22:03 +0000 Received: from localhost (kbyanc@localhost) by gateway.posi.net (8.11.6/8.11.6) with ESMTP id fBCMM2k00734; Wed, 12 Dec 2001 14:22:02 -0800 (PST) (envelope-from kbyanc@posi.net) X-Authentication-Warning: gateway.posi.net: kbyanc owned process doing -bs Date: Wed, 12 Dec 2001 14:22:01 -0800 (PST) From: Kelly Yancey To: Tom Cc: freebsd-net@FreeBSD.ORG Subject: RE: 1 IP - 1 Firewall - 2 Webservers In-Reply-To: <5.1.0.14.2.20011213102454.0280ee78@pop3.paradise.net.nz> 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, 13 Dec 2001, Tom wrote: > Well, running Apache I'm sure it can be done - but this depends on the > methods which have to be taken to have it up and running. I have posted a > message on the e-smith forum about adding mods to an already installed > Apache server - but they are pretty slow at responding to things over there > - so someone here can probably shed some light for me :-) > > Tom > Ah, well that is good news. I'm not familiar with e-smith, but from the looks of their site it supports installing binary apache modules via RPM. They have a pretty good list of contributed RPMs on their site (under "modules" on the right of e-smith.org), but unfortunately it does not include mod_extract_forwarded. If you know the glibc, kernel version, and whatever other linux variables you may be able to just snag a binary RPM for mod_extract_forwarded off the net (rpmfind.net, for example). This will be made easier if the OS is a stock distribution (i.e. RedHat). Anyway, I'm definately getting out of my area of expertise, so I can't be of any more help, but it sounds like you understand the issues and well on the way of getting things settled. Good luck, Kelly -- Kelly Yancey - kbyanc@{posi.net,FreeBSD.org} To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 12 14:35: 0 2001 Delivered-To: freebsd-net@freebsd.org Received: from mta4-rme.xtra.co.nz (mta4-rme.xtra.co.nz [210.86.15.132]) by hub.freebsd.org (Postfix) with ESMTP id 56CEF37B405 for ; Wed, 12 Dec 2001 14:34:57 -0800 (PST) Received: from internet1.masaclaw.co.nz ([210.55.57.50]) by mta4-rme.xtra.co.nz with ESMTP id <20011212223455.UAIW24850.mta4-rme.xtra.co.nz@internet1.masaclaw.co.nz> for ; Thu, 13 Dec 2001 11:34:55 +1300 Message-Id: <5.1.0.14.2.20011213112828.02867c40@mail.masaclaw.co.nz> X-Sender: masaclaw@mail.masaclaw.co.nz X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 13 Dec 2001 11:28:46 +1300 To: freebsd-net@FreeBSD.ORG From: Tom Peck Subject: RE: 1 IP - 1 Firewall - 2 Webservers 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 > Ah, well that is good news. I'm not familiar with e-smith, but from the >looks of their site it supports installing binary apache modules via RPM. They >have a pretty good list of contributed RPMs on their site (under "modules" on >the right of e-smith.org), but unfortunately it does not include >mod_extract_forwarded. If you know the glibc, kernel version, and whatever >other linux variables you may be able to just snag a binary RPM for >mod_extract_forwarded off the net (rpmfind.net, for example). This will be >made easier if the OS is a stock distribution (i.e. RedHat). Anyway, I'm >definately getting out of my area of expertise, so I can't be of any more >help, but it sounds like you understand the issues and well on the way of >getting things settled. Good luck, Yes, it uses the RedHat base - so this shouldn't be a problem. Thanks for the help, I _should_ be able to manage it from here. Tom To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 12 15:42:26 2001 Delivered-To: freebsd-net@freebsd.org Received: from zeus.anet-chi.com (zeus.anet-chi.com [207.7.4.6]) by hub.freebsd.org (Postfix) with ESMTP id B070537B417 for ; Wed, 12 Dec 2001 15:41:52 -0800 (PST) Received: from IPv16 (as1b-243.chi.il.dial.anet.com [198.92.157.243]) by zeus.anet-chi.com (8.9.3/spamfix) with SMTP id RAA22167 for ; Wed, 12 Dec 2001 17:42:06 -0600 (CST) Message-ID: <014e01c18368$825c2980$1000a8c0@Unir.com> From: "Jim Fleming" To: Subject: Fw: RIFRAF Routing Changes for FreeBSD Date: Wed, 12 Dec 2001 17:55:41 -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 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 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 RIFRAF Routing RIFRAF (Remote Identification Field Random Action Filter) Routing is part of a phased approach to evolving from 32-bit IPv4 Internet Addressing to larger address spaces. The RIFRAF feature in an IP stack, allows for remote access control of the left-most 8-bits of the normally 16-bit IPv4 Identification Field. The feature is part of the IPv8 PeaceKeeper/GateKeeper series. The feature allows a PeaceKeeper for a /16 prefix to remotely set StarGate values in a marking engine via simple ICMP+ extensions via the TOS field. The 4-bit StarGate values are rotated through an 8-bit field which is used in a 50/50 coin-toss marking process as packets are processed with the /16 prefix. Source and Destination StarGate marking is distinct, and all 65,536 /16 prefixes have two choices for the source addresses and two choices for destination addresses. The random marking can be prevented by loading both StarGate values to be the same. The GateKeeper can be restored to legacy Identification Field marking by the PeaceKeeper. Packets marked via RIFRAF can be further routed or queued based on the marks which effectively add 4 bits to the 32-bit IPv4 legacy addresses. All of the packets pass transparently through legacy IPv4 equipment with no change. For legacy equipment not prepared to handle the markings, it appears as the left 8-bits of the Identification Field. For each of the 256 marking values, an independent counter is maintained for the right-most 8-bits of the Identification Field. There is no API required or other user-level tools. Most modern "ping" programs can be used to set the bits. RIFRAF can exist silently inside of the stack and be totally controlled remotely via existing connection(s) to the IPv4 private Intranets or the IPv4 Global Public Internet. Spoofing of the PeaceKeeper is possible and the real PeaceKeeper will receive the return reply, at which point the PeaceKeeper can restore the desired values. When RIFRAF is used in conjunction with other routing devices and on an IPv16 network, these problems can be minimized. RIFRAF is mostly intended for use in extending the addressing of leaf-nodes, which generally are protected behind fire-walls and NAT devices, but can also be used on the IPv4 Global Public Internet to increase the addressing used by edge devices on /16 networks. > This may help... > http://www.dot-biz.com/IPv4/Tutorial/ > http://www.RepliGate.net > > The Netfilter Project: Packet Mangling for Linux 2.4 > http://netfilter.samba.org > > Jim Fleming > http://www.IPv8.info > IPv16....One Better !! > > ----- Original Message ----- > From: "Charlie Root" > To: > Sent: Wednesday, December 12, 2001 4:45 AM > > > > diff -c -r /unir/sys/netinet/ip.h netinet/ip.h > > *** /unir/sys/netinet/ip.h Wed Dec 22 19:13:20 1999 > > --- netinet/ip.h Tue Dec 11 13:59:38 2001 > > *************** > > *** 43,48 **** > > --- 43,53 ---- > > */ > > #define IPVERSION 4 > > > > + #define IPXX_V4 4 > > + #define IPXX_V5 5 > > + #define IPXX_V7 7 > > + #define IPXX_V8 8 > > + > > /* > > * Structure of an internet header, naked of options. > > */ > > *************** > > *** 61,73 **** > > #endif /* not _IP_VHL */ > > u_char ip_tos; /* type of service */ > > u_short ip_len; /* total length */ > > ! u_short ip_id; /* identification */ > > u_short ip_off; /* fragment offset field */ > > #define IP_RF 0x8000 /* reserved fragment flag */ > > #define IP_DF 0x4000 /* dont fragment flag */ > > #define IP_MF 0x2000 /* more fragments flag */ > > #define IP_OFFMASK 0x1fff /* mask for fragmenting bits */ > > u_char ip_ttl; /* time to live */ > > u_char ip_p; /* protocol */ > > u_short ip_sum; /* checksum */ > > struct in_addr ip_src,ip_dst; /* source and dest address */ > > --- 66,89 ---- > > #endif /* not _IP_VHL */ > > u_char ip_tos; /* type of service */ > > u_short ip_len; /* total length */ > > ! #define IPXX_UNIRVERSE_DEFAULT 0 /* Default IPv8 UnirVerse Value */ > > ! u_char ip_gate; /* UnirVerse/StarGate */ > > ! u_char ip_id; /* identification */ > > u_short ip_off; /* fragment offset field */ > > + #define IPXX_FLAG 0x8000 /* IPvXX flag */ > > #define IP_RF 0x8000 /* reserved fragment flag */ > > #define IP_DF 0x4000 /* dont fragment flag */ > > #define IP_MF 0x2000 /* more fragments flag */ > > #define IP_OFFMASK 0x1fff /* mask for fragmenting bits */ > > u_char ip_ttl; /* time to live */ > > + #define IPXX_GALAXY 033 /* IPv8 Galaxy Value for 3:219 .INFO */ > > + #define IPXX_P_MASK 0x3F > > + #define IPXX_ICMP_VAL 1 > > + #define IPXX_ICMP_FLAG 0x40 > > + #define IPXX_TCP_VAL 6 > > + #define IPXX_TCP_FLAG 0x80 > > + #define IPXX_UDP_VAL 16 > > + #define IPXX_UDP_FLAG 0xC0 > > u_char ip_p; /* protocol */ > > u_short ip_sum; /* checksum */ > > struct in_addr ip_src,ip_dst; /* source and dest address */ > > diff -c -r /unir/sys/netinet/ip_icmp.c netinet/ip_icmp.c > > *** /unir/sys/netinet/ip_icmp.c Tue Jul 3 11:01:46 2001 > > --- netinet/ip_icmp.c Tue Dec 11 14:00:00 2001 > > *************** > > *** 121,132 **** > > #endif > > > > static void icmp_reflect __P((struct mbuf *)); > > ! static void icmp_send __P((struct mbuf *, struct mbuf *)); > > static int ip_next_mtu __P((int, int)); > > > > extern struct protosw inetsw[]; > > > > /* > > * Generate an error packet of type error > > * in response to bad packet ip. > > */ > > --- 121,396 ---- > > #endif > > > > static void icmp_reflect __P((struct mbuf *)); > > ! static void icmp_send __P((struct mbuf *, struct mbuf *, int)); > > static int ip_next_mtu __P((int, int)); > > > > extern struct protosw inetsw[]; > > > > /* > > + * Table used to reverse the 4-bit source and destination values > > + * in the 8-bit TOS field. > > + */ > > + > > + unsigned char reverse_nibbles[256] = { > > + /*00*/ 0x00, > > + /*01*/ 0x10, > > + /*02*/ 0x20, > > + /*03*/ 0x30, > > + /*04*/ 0x40, > > + /*05*/ 0x50, > > + /*06*/ 0x60, > > + /*07*/ 0x70, > > + /*08*/ 0x80, > > + /*09*/ 0x90, > > + /*0a*/ 0xa0, > > + /*0b*/ 0xb0, > > + /*0c*/ 0xc0, > > + /*0d*/ 0xd0, > > + /*0e*/ 0xe0, > > + /*0f*/ 0xf0, > > + /*10*/ 0x01, > > + /*11*/ 0x11, > > + /*12*/ 0x21, > > + /*13*/ 0x31, > > + /*14*/ 0x41, > > + /*15*/ 0x51, > > + /*16*/ 0x61, > > + /*17*/ 0x71, > > + /*18*/ 0x81, > > + /*19*/ 0x91, > > + /*1a*/ 0xa1, > > + /*1b*/ 0xb1, > > + /*1c*/ 0xc1, > > + /*1d*/ 0xd1, > > + /*1e*/ 0xe1, > > + /*1f*/ 0xf1, > > + /*20*/ 0x02, > > + /*21*/ 0x12, > > + /*22*/ 0x22, > > + /*23*/ 0x32, > > + /*24*/ 0x42, > > + /*25*/ 0x52, > > + /*26*/ 0x62, > > + /*27*/ 0x72, > > + /*28*/ 0x82, > > + /*29*/ 0x92, > > + /*2a*/ 0xa2, > > + /*2b*/ 0xb2, > > + /*2c*/ 0xc2, > > + /*2d*/ 0xd2, > > + /*2e*/ 0xe2, > > + /*2f*/ 0xf2, > > + /*30*/ 0x03, > > + /*31*/ 0x13, > > + /*32*/ 0x23, > > + /*33*/ 0x33, > > + /*34*/ 0x43, > > + /*35*/ 0x53, > > + /*36*/ 0x63, > > + /*37*/ 0x73, > > + /*38*/ 0x83, > > + /*39*/ 0x93, > > + /*3a*/ 0xa3, > > + /*3b*/ 0xb3, > > + /*3c*/ 0xc3, > > + /*3d*/ 0xd3, > > + /*3e*/ 0xe3, > > + /*3f*/ 0xf3, > > + /*40*/ 0x04, > > + /*41*/ 0x14, > > + /*42*/ 0x24, > > + /*43*/ 0x34, > > + /*44*/ 0x44, > > + /*45*/ 0x54, > > + /*46*/ 0x64, > > + /*47*/ 0x74, > > + /*48*/ 0x84, > > + /*49*/ 0x94, > > + /*4a*/ 0xa4, > > + /*4b*/ 0xb4, > > + /*4c*/ 0xc4, > > + /*4d*/ 0xd4, > > + /*4e*/ 0xe4, > > + /*4f*/ 0xf4, > > + /*50*/ 0x05, > > + /*51*/ 0x15, > > + /*52*/ 0x25, > > + /*53*/ 0x35, > > + /*54*/ 0x45, > > + /*55*/ 0x55, > > + /*56*/ 0x65, > > + /*57*/ 0x75, > > + /*58*/ 0x85, > > + /*59*/ 0x95, > > + /*5a*/ 0xa5, > > + /*5b*/ 0xb5, > > + /*5c*/ 0xc5, > > + /*5d*/ 0xd5, > > + /*5e*/ 0xe5, > > + /*5f*/ 0xf5, > > + /*60*/ 0x06, > > + /*61*/ 0x16, > > + /*62*/ 0x26, > > + /*63*/ 0x36, > > + /*64*/ 0x46, > > + /*65*/ 0x56, > > + /*66*/ 0x66, > > + /*67*/ 0x76, > > + /*68*/ 0x86, > > + /*69*/ 0x96, > > + /*6a*/ 0xa6, > > + /*6b*/ 0xb6, > > + /*6c*/ 0xc6, > > + /*6d*/ 0xd6, > > + /*6e*/ 0xe6, > > + /*6f*/ 0xf6, > > + /*70*/ 0x07, > > + /*71*/ 0x17, > > + /*72*/ 0x27, > > + /*73*/ 0x37, > > + /*74*/ 0x47, > > + /*75*/ 0x57, > > + /*76*/ 0x67, > > + /*77*/ 0x77, > > + /*78*/ 0x87, > > + /*79*/ 0x97, > > + /*7a*/ 0xa7, > > + /*7b*/ 0xb7, > > + /*7c*/ 0xc7, > > + /*7d*/ 0xd7, > > + /*7e*/ 0xe7, > > + /*7f*/ 0xf7, > > + /*80*/ 0x08, > > + /*81*/ 0x18, > > + /*82*/ 0x28, > > + /*83*/ 0x38, > > + /*84*/ 0x48, > > + /*85*/ 0x58, > > + /*86*/ 0x68, > > + /*87*/ 0x78, > > + /*88*/ 0x88, > > + /*89*/ 0x98, > > + /*8a*/ 0xa8, > > + /*8b*/ 0xb8, > > + /*8c*/ 0xc8, > > + /*8d*/ 0xd8, > > + /*8e*/ 0xe8, > > + /*8f*/ 0xf8, > > + /*90*/ 0x09, > > + /*91*/ 0x19, > > + /*92*/ 0x29, > > + /*93*/ 0x39, > > + /*94*/ 0x49, > > + /*95*/ 0x59, > > + /*96*/ 0x69, > > + /*97*/ 0x79, > > + /*98*/ 0x89, > > + /*99*/ 0x99, > > + /*9a*/ 0xa9, > > + /*9b*/ 0xb9, > > + /*9c*/ 0xc9, > > + /*9d*/ 0xd9, > > + /*9e*/ 0xe9, > > + /*9f*/ 0xf9, > > + /*a0*/ 0x0a, > > + /*a1*/ 0x1a, > > + /*a2*/ 0x2a, > > + /*a3*/ 0x3a, > > + /*a4*/ 0x4a, > > + /*a5*/ 0x5a, > > + /*a6*/ 0x6a, > > + /*a7*/ 0x7a, > > + /*a8*/ 0x8a, > > + /*a9*/ 0x9a, > > + /*aa*/ 0xaa, > > + /*ab*/ 0xba, > > + /*ac*/ 0xca, > > + /*ad*/ 0xda, > > + /*ae*/ 0xea, > > + /*af*/ 0xfa, > > + /*b0*/ 0x0b, > > + /*b1*/ 0x1b, > > + /*b2*/ 0x2b, > > + /*b3*/ 0x3b, > > + /*b4*/ 0x4b, > > + /*b5*/ 0x5b, > > + /*b6*/ 0x6b, > > + /*b7*/ 0x7b, > > + /*b8*/ 0x8b, > > + /*b9*/ 0x9b, > > + /*ba*/ 0xab, > > + /*bb*/ 0xbb, > > + /*bc*/ 0xcb, > > + /*bd*/ 0xdb, > > + /*be*/ 0xeb, > > + /*bf*/ 0xfb, > > + /*c0*/ 0x0c, > > + /*c1*/ 0x1c, > > + /*c2*/ 0x2c, > > + /*c3*/ 0x3c, > > + /*c4*/ 0x4c, > > + /*c5*/ 0x5c, > > + /*c6*/ 0x6c, > > + /*c7*/ 0x7c, > > + /*c8*/ 0x8c, > > + /*c9*/ 0x9c, > > + /*ca*/ 0xac, > > + /*cb*/ 0xbc, > > + /*cc*/ 0xcc, > > + /*cd*/ 0xdc, > > + /*ce*/ 0xec, > > + /*cf*/ 0xfc, > > + /*d0*/ 0x0d, > > + /*d1*/ 0x1d, > > + /*d2*/ 0x2d, > > + /*d3*/ 0x3d, > > + /*d4*/ 0x4d, > > + /*d5*/ 0x5d, > > + /*d6*/ 0x6d, > > + /*d7*/ 0x7d, > > + /*d8*/ 0x8d, > > + /*d9*/ 0x9d, > > + /*da*/ 0xad, > > + /*db*/ 0xbd, > > + /*dc*/ 0xcd, > > + /*dd*/ 0xdd, > > + /*de*/ 0xed, > > + /*df*/ 0xfd, > > + /*e0*/ 0x0e, > > + /*e1*/ 0x1e, > > + /*e2*/ 0x2e, > > + /*e3*/ 0x3e, > > + /*e4*/ 0x4e, > > + /*e5*/ 0x5e, > > + /*e6*/ 0x6e, > > + /*e7*/ 0x7e, > > + /*e8*/ 0x8e, > > + /*e9*/ 0x9e, > > + /*ea*/ 0xae, > > + /*eb*/ 0xbe, > > + /*ec*/ 0xce, > > + /*ed*/ 0xde, > > + /*ee*/ 0xee, > > + /*ef*/ 0xfe, > > + /*f0*/ 0x0f, > > + /*f1*/ 0x1f, > > + /*f2*/ 0x2f, > > + /*f3*/ 0x3f, > > + /*f4*/ 0x4f, > > + /*f5*/ 0x5f, > > + /*f6*/ 0x6f, > > + /*f7*/ 0x7f, > > + /*f8*/ 0x8f, > > + /*f9*/ 0x9f, > > + /*fa*/ 0xaf, > > + /*fb*/ 0xbf, > > + /*fc*/ 0xcf, > > + /*fd*/ 0xdf, > > + /*fe*/ 0xef, > > + /*ff*/ 0xff > > + }; > > + > > + /* > > * Generate an error packet of type error > > * in response to bad packet ip. > > */ > > *************** > > *** 226,232 **** > > nip->ip_len = m->m_len; > > nip->ip_vhl = IP_VHL_BORING; > > nip->ip_p = IPPROTO_ICMP; > > ! nip->ip_tos = 0; > > icmp_reflect(m); > > > > freeit: > > --- 490,496 ---- > > nip->ip_len = m->m_len; > > nip->ip_vhl = IP_VHL_BORING; > > nip->ip_p = IPPROTO_ICMP; > > ! nip->ip_tos = 0x44; /* Network Management Flow */ > > icmp_reflect(m); > > > > freeit: > > *************** > > *** 610,615 **** > > --- 874,880 ---- > > struct in_addr t; > > struct mbuf *opts = 0; > > int optlen = (IP_VHL_HL(ip->ip_vhl) << 2) - sizeof(struct ip); > > + int flags = 0; > > > > if (!in_canforward(ip->ip_src) && > > ((ntohl(ip->ip_src.s_addr) & IN_CLASSA_NET) != > > *************** > > *** 617,622 **** > > --- 882,895 ---- > > m_freem(m); /* Bad return address */ > > goto done; /* Ip_output() will check for broadcast */ > > } > > + /* Handle IPv8 TOS and UnirVerse fields */ > > + if(((ip->ip_tos&0xF0)!=0) && ((ip->ip_tos&0x0F)!=0)){ > > + ip->ip_tos = reverse_nibbles[ip->ip_tos]; > > + if(ip->ip_gate != IPXX_UNIRVERSE_DEFAULT){ > > + ip->ip_gate = reverse_nibbles[ip->ip_gate]; > > + flags |= IP_UNIRVERSE_SET; > > + } > > + } > > t = ip->ip_dst; > > ip->ip_dst = ip->ip_src; > > /* > > *************** > > *** 719,725 **** > > (unsigned)(m->m_len - sizeof(struct ip))); > > } > > m->m_flags &= ~(M_BCAST|M_MCAST); > > ! icmp_send(m, opts); > > done: > > if (opts) > > (void)m_free(opts); > > --- 992,998 ---- > > (unsigned)(m->m_len - sizeof(struct ip))); > > } > > m->m_flags &= ~(M_BCAST|M_MCAST); > > ! icmp_send(m,opts,flags); > > done: > > if (opts) > > (void)m_free(opts); > > *************** > > *** 730,738 **** > > * after supplying a checksum. > > */ > > static void > > ! icmp_send(m, opts) > > register struct mbuf *m; > > struct mbuf *opts; > > { > > register struct ip *ip = mtod(m, struct ip *); > > register int hlen; > > --- 1003,1012 ---- > > * after supplying a checksum. > > */ > > static void > > ! icmp_send(m,opts,flags) > > register struct mbuf *m; > > struct mbuf *opts; > > + int flags; > > { > > register struct ip *ip = mtod(m, struct ip *); > > register int hlen; > > *************** > > *** 757,763 **** > > } > > #endif > > bzero(&ro, sizeof ro); > > ! (void) ip_output(m, opts, &ro, 0, NULL); > > if (ro.ro_rt) > > RTFREE(ro.ro_rt); > > } > > --- 1031,1037 ---- > > } > > #endif > > bzero(&ro, sizeof ro); > > ! (void) ip_output(m, opts, &ro, flags, NULL); > > if (ro.ro_rt) > > RTFREE(ro.ro_rt); > > } > > diff -c -r /unir/sys/netinet/ip_input.c netinet/ip_input.c > > *** /unir/sys/netinet/ip_input.c Wed Aug 29 21:41:37 2001 > > --- netinet/ip_input.c Wed Dec 12 09:57:20 2001 > > *************** > > *** 258,266 **** > > maxnipq = nmbclusters / 4; > > ip_maxfragpackets = nmbclusters / 4; > > > > - #ifndef RANDOM_IP_ID > > ip_id = time_second & 0xffff; > > ! #endif > > ipintrq.ifq_maxlen = ipqmaxlen; > > > > register_netisr(NETISR_IP, ipintr); > > --- 258,275 ---- > > maxnipq = nmbclusters / 4; > > ip_maxfragpackets = nmbclusters / 4; > > > > ip_id = time_second & 0xffff; > > ! /* initialize all the StarGate id counters */ > > ! for(i=0; i<256; i++){ > > ! ip_id_[i] = time_second & 0xffff; > > ! } > > ! for(i=0; i<65536; i++){ > > ! src_gate[i] = 0x00; > > ! dst_gate[i] = 0x00; > > ! } > > ! galaxy_in=0; > > ! galaxy_out=0; > > ! > > ipintrq.ifq_maxlen = ipqmaxlen; > > > > register_netisr(NETISR_IP, ipintr); > > *************** > > *** 269,274 **** > > --- 278,285 ---- > > static struct sockaddr_in ipaddr = { sizeof(ipaddr), AF_INET }; > > static struct route ipforward_rt; > > > > + extern unsigned char reverse_nibbles[]; > > + > > /* > > * Ip input routine. Checksum and byte swap header. If fragmented > > * try to reassemble. Process options. Pass to next level. > > *************** > > *** 287,292 **** > > --- 298,305 ---- > > u_int32_t divert_info = 0; /* packet divert/tee info */ > > #endif > > struct ip_fw_chain *rule = NULL; > > + u_int32_t src_addr; > > + u_int32_t dst_addr; > > > > #ifdef IPDIVERT > > /* Get and reset firewall cookie */ > > *************** > > *** 346,351 **** > > --- 359,365 ---- > > ip = mtod(m, struct ip *); > > } > > > > + > > /* 127/8 must not appear on wire - RFC1122 */ > > if ((ntohl(ip->ip_dst.s_addr) >> IN_CLASSA_NSHIFT) == IN_LOOPBACKNET || > > (ntohl(ip->ip_src.s_addr) >> IN_CLASSA_NSHIFT) == IN_LOOPBACKNET) { > > *************** > > *** 402,407 **** > > --- 416,483 ---- > > if (ipsec_gethist(m, NULL)) > > goto pass; > > #endif > > + > > + /* Process IPvXX ICMP++ packets that are special QoS codes */ > > + if((ip->ip_p==IPPROTO_ICMP) && (((ip->ip_tos&0xF0)==0)||((ip->ip_tos&0x0F)==0))){ > > + src_addr = ntohl(ip->ip_src.s_addr); > > + dst_addr = ntohl(ip->ip_dst.s_addr); > > + /* QoS(4)=Network Management */ > > + switch(ip->ip_tos){ > > + case 0x04: > > + /* Check for Galaxy PeaceKeeper */ > > + /* PPPPPPPP.PPPPPPPP.GGG00000.XXXX0000 */ > > + if((src_addr&0x1F0F)==0){ > > + dst_gate[src_addr>>16] >>= 4; > > + dst_gate[src_addr>>16] |= src_addr&0xF0; > > + /* Check for possible new Galaxy setting */ > > + if(((src_addr&0x0E00)!=0)&&((src_addr&0xFFFF0000)==(dst_addr&0xFFFF0000))){ > > + galaxy_out=(src_addr&0x0E00)>>8; > > + log(LOG_WARNING,"Outbound Galactic Routing set to %d\n",galaxy_out); > > + } > > + else{ > > + galaxy_out=0; > > + } > > + } > > + break; > > + case 0x40: > > + /* Check for Galaxy PeaceKeeper */ > > + /* PPPPPPPP.PPPPPPPP.GGG00000.XXXX0000 */ > > + if((src_addr&0x1F0F)==0){ > > + src_gate[src_addr>>16] >>= 4; > > + src_gate[src_addr>>16] |= src_addr&0xF0; > > + /* Check for possible new Galaxy setting */ > > + if(((src_addr&0x0E00)!=0)&&((src_addr&0xFFFF0000)==(dst_addr&0xFFFF0000))){ > > + galaxy_in=(src_addr&0x0E00)>>8; > > + log(LOG_WARNING,"Inbound Galactic Routing set to %d\n",galaxy_in); > > + } > > + else{ > > + galaxy_in=0; > > + } > > + } > > + break; > > + default: > > + log(LOG_WARNING,"Unknown ICMP+ QoS Code from %s\n", > > + inet_ntoa(ip->ip_src)); > > + } > > + } > > + /* Process IPvXX-style Packets */ > > + if((ip->ip_off&0x8000)!=0){ > > + /* Process non-Galaxy 0 Packets */ > > + if(((ip->ip_p&0xC0) != 0)&& > > + ((ip->ip_p&0x07) != galaxy_in)){ > > + printf("Dropped packet not from our galaxy\n"); > > + ipstat.ips_badaddr++; > > + goto bad; > > + } > > + else{ > > + /* Packet is Galaxy 0, are we ? */ > > + if(galaxy_in != 0){ > > + printf("Dropped packet not from our galaxy\n"); > > + ipstat.ips_badaddr++; > > + goto bad; > > + } > > + } > > + } > > > > /* > > * IpHack's section. > > diff -c -r /unir/sys/netinet/ip_mroute.c netinet/ip_mroute.c > > *** /unir/sys/netinet/ip_mroute.c Thu Jul 19 06:37:26 2001 > > --- netinet/ip_mroute.c Tue Dec 11 14:00:20 2001 > > *************** > > *** 1581,1590 **** > > */ > > ip_copy = mtod(mb_copy, struct ip *); > > *ip_copy = multicast_encap_iphdr; > > #ifdef RANDOM_IP_ID > > ip_copy->ip_id = ip_randomid(); > > #else > > ! ip_copy->ip_id = htons(ip_id++); > > #endif > > ip_copy->ip_len += len; > > ip_copy->ip_src = vifp->v_lcl_addr; > > --- 1581,1597 ---- > > */ > > ip_copy = mtod(mb_copy, struct ip *); > > *ip_copy = multicast_encap_iphdr; > > + ip_copy->ip_gate=0; > > #ifdef RANDOM_IP_ID > > ip_copy->ip_id = ip_randomid(); > > #else > > ! if(ip_copy->ip_tos != 0){ > > ! ip_copy->ip_id = ip_id_[ip_copy->ip_gate]++; > > ! } > > ! else{ > > ! ip_copy->ip_id = ip_id++; > > ! ip_copy->ip_gate = ip_id>>8; > > ! } > > #endif > > ip_copy->ip_len += len; > > ip_copy->ip_src = vifp->v_lcl_addr; > > diff -c -r /unir/sys/netinet/ip_output.c netinet/ip_output.c > > *** /unir/sys/netinet/ip_output.c Thu Jul 19 06:37:26 2001 > > --- netinet/ip_output.c Wed Dec 12 10:28:11 2001 > > *************** > > *** 52,57 **** > > --- 52,58 ---- > > #include > > #include > > #include > > + #include > > > > #include > > #include > > *************** > > *** 88,101 **** > > #include > > #endif > > > > ! #ifdef IPFIREWALL_FORWARD_DEBUG > > ! #define print_ip(a) printf("%ld.%ld.%ld.%ld",(ntohl(a.s_addr)>>24)&0xFF,\ > > (ntohl(a.s_addr)>>16)&0xFF,\ > > (ntohl(a.s_addr)>>8)&0xFF,\ > > (ntohl(a.s_addr))&0xFF); > > - #endif > > > > u_short ip_id; > > > > static struct mbuf *ip_insertoptions __P((struct mbuf *, struct mbuf *, int *)); > > static struct ifnet *ip_multicast_if __P((struct in_addr *, int *)); > > --- 89,105 ---- > > #include > > #endif > > > > ! #define print_ip(a) printf("%ld.%ld.%ld.%ld ",(ntohl(a.s_addr)>>24)&0xFF,\ > > (ntohl(a.s_addr)>>16)&0xFF,\ > > (ntohl(a.s_addr)>>8)&0xFF,\ > > (ntohl(a.s_addr))&0xFF); > > > > u_short ip_id; > > + u_char ip_id_[256]; > > + u_char src_gate[65536]; > > + u_char dst_gate[65536]; > > + u_char galaxy_out; > > + u_char galaxy_in; > > > > static struct mbuf *ip_insertoptions __P((struct mbuf *, struct mbuf *, int *)); > > static struct ifnet *ip_multicast_if __P((struct in_addr *, int *)); > > *************** > > *** 127,132 **** > > --- 131,137 ---- > > int flags; > > struct ip_moptions *imo; > > { > > + struct timeval random_time; > > struct ip *ip, *mhip; > > struct ifnet *ifp; > > struct mbuf *m = m0; > > *************** > > *** 207,219 **** > > /* > > * Fill in IP header. > > */ > > if ((flags & (IP_FORWARDING|IP_RAWOUTPUT)) == 0) { > > ip->ip_vhl = IP_MAKE_VHL(IPVERSION, hlen >> 2); > > ip->ip_off &= IP_DF; > > #ifdef RANDOM_IP_ID > > ip->ip_id = ip_randomid(); > > #else > > ! ip->ip_id = htons(ip_id++); > > #endif > > ipstat.ips_localout++; > > } else { > > --- 212,252 ---- > > /* > > * Fill in IP header. > > */ > > + > > + /* Set UnirVerse on QoS-agile Packets */ > > + if(ip->ip_tos != 0){ > > + /* Allow reflectors and forwarders to prevent setting */ > > + if((flags & IP_UNIRVERSE_SET) == 0){ > > + getmicrotime(&random_time); > > + if(random_time.tv_usec&0x01){ > > + ip->ip_gate = > > + ((src_gate[(ntohl(ip->ip_src.s_addr)>>16)&0xFFFF])&0xF0) | > > + (((dst_gate[(ntohl(ip->ip_dst.s_addr)>>16)&0xFFFF])>>4)&0x0F); > > + } > > + else{ > > + ip->ip_gate = > > + (((src_gate[(ntohl(ip->ip_src.s_addr)>>16)&0xFFFF])<<4)&0xF0) | > > + ((dst_gate[(ntohl(ip->ip_dst.s_addr)>>16)&0xFFFF])&0x0F); > > + } > > + } > > + } > > + else{ > > + ip->ip_gate = IPXX_UNIRVERSE_DEFAULT; > > + } > > + /* Set id based on UnirVerse */ > > if ((flags & (IP_FORWARDING|IP_RAWOUTPUT)) == 0) { > > ip->ip_vhl = IP_MAKE_VHL(IPVERSION, hlen >> 2); > > ip->ip_off &= IP_DF; > > #ifdef RANDOM_IP_ID > > ip->ip_id = ip_randomid(); > > #else > > ! if(ip->ip_tos != 0){ > > ! ip->ip_id = ip_id_[ip->ip_gate]++; > > ! } > > ! else{ > > ! ip->ip_id = ip_id++; > > ! ip->ip_gate = ip_id>>8; > > ! } > > #endif > > ipstat.ips_localout++; > > } else { > > *************** > > *** 431,436 **** > > --- 464,470 ---- > > } > > > > sendit: > > + > > #ifdef IPSEC > > /* get SP for this packet */ > > if (so == NULL) > > diff -c -r /unir/sys/netinet/ip_var.h netinet/ip_var.h > > *** /unir/sys/netinet/ip_var.h Thu Jul 19 06:37:26 2001 > > --- netinet/ip_var.h Tue Dec 11 14:00:41 2001 > > *************** > > *** 133,138 **** > > --- 133,140 ---- > > /* flags passed to ip_output as last parameter */ > > #define IP_FORWARDING 0x1 /* most of ip header exists */ > > #define IP_RAWOUTPUT 0x2 /* raw ip header exists */ > > + #define IP_UNIRVERSE_SET 0x4 /* UnirVerse set in header */ > > + > > #define IP_ROUTETOIF SO_DONTROUTE /* bypass routing tables */ > > #define IP_ALLOWBROADCAST SO_BROADCAST /* can send broadcast packets */ > > > > *************** > > *** 142,150 **** > > struct sockopt; > > > > extern struct ipstat ipstat; > > ! #ifndef RANDOM_IP_ID > > ! extern u_short ip_id; /* ip packet ctr, for ids */ > > ! #endif > > extern int ip_defttl; /* default IP ttl */ > > extern int ipforwarding; /* ip forwarding */ > > extern u_char ip_protox[]; > > --- 144,157 ---- > > struct sockopt; > > > > extern struct ipstat ipstat; > > ! > > ! extern u_short ip_id; /* ip packet ctr, for ids */ > > ! extern u_char ip_id_[]; /* id counters for each StarGate */ > > ! extern u_char src_gate[]; > > ! extern u_char dst_gate[]; > > ! extern u_char galaxy_in; > > ! extern u_char galaxy_out; > > ! > > extern int ip_defttl; /* default IP ttl */ > > extern int ipforwarding; /* ip forwarding */ > > extern u_char ip_protox[]; > > diff -c -r /unir/sys/netinet/raw_ip.c netinet/raw_ip.c > > *** /unir/sys/netinet/raw_ip.c Sun Jul 29 19:32:40 2001 > > --- netinet/raw_ip.c Tue Dec 11 14:01:10 2001 > > *************** > > *** 239,249 **** > > m_freem(m); > > return EINVAL; > > } > > - if (ip->ip_id == 0) > > #ifdef RANDOM_IP_ID > > ip->ip_id = ip_randomid(); > > #else > > ! ip->ip_id = htons(ip_id++); > > #endif > > /* XXX prevent ip_output from overwriting header fields */ > > flags |= IP_RAWOUTPUT; > > --- 239,259 ---- > > m_freem(m); > > return EINVAL; > > } > > #ifdef RANDOM_IP_ID > > + if (ip->ip_id == 0){ > > ip->ip_id = ip_randomid(); > > + } > > #else > > ! if (ip->ip_id == 0){ > > ! if(ip->ip_tos != 0){ > > ! ip->ip_id = ip_id_[ip->ip_gate]++; > > ! ip->ip_gate = IPXX_UNIRVERSE_DEFAULT; > > ! } > > ! else{ > > ! ip->ip_id = ip_id++; > > ! ip->ip_gate = ip_id>>8; > > ! } > > ! } > > #endif > > /* XXX prevent ip_output from overwriting header fields */ > > flags |= IP_RAWOUTPUT; > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 12 16:16: 3 2001 Delivered-To: freebsd-net@freebsd.org Received: from sbserv0.intra.selectbourse.net (ATuileries-103-2-1-140.abo.wanadoo.fr [193.252.55.140]) by hub.freebsd.org (Postfix) with ESMTP id 0564937B41F for ; Wed, 12 Dec 2001 16:15:43 -0800 (PST) Received: from there (spetit.intra.selectbourse.net [172.16.2.7]) by sbserv0.intra.selectbourse.net (Postfix) with SMTP id A996DBA85; Thu, 13 Dec 2001 00:14:10 +0100 (CET) Content-Type: text/plain; charset="iso-8859-1" From: Sebastien Petit To: Sam Tannous , rizzo@aciri.org Subject: Re: Ethernet Firewall for FreeBSD-4.4 Date: Thu, 13 Dec 2001 01:13:00 +0100 X-Mailer: KMail [version 1.3.1] References: <20011203211222.DA4386ACF@vega.bsdshell.net> <20011212173538.N28904@cisco.com> In-Reply-To: <20011212173538.N28904@cisco.com> Cc: net@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20011212231410.A996DBA85@sbserv0.intra.selectbourse.net> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wednesday 12 December 2001 23:35, Sam Tannous wrote: > I've download the ethfw patches (v1.2) and they work fine > on my 4.4 system. One other good reason to add ethfw > to the existing ipfw code (and this is purely subjective) > is that it would look more like ipfw: > > 00100 27 1144 allow ip from any to any > > looks nicer then > > [ 50] REJ VLAN ANY -> ANY < in/out all > > > (I really miss having the little counters too.) > accounting and another features are for the next release of ethfw. > On a more practical level, the configs, code, > man pages, logs, etc....would all be in one place. > They really belong together...perhaps change the name to > simply "fw" ;-) my point of view is the same as Luiggi and yours. So Luiggi is very busy for the moment due to the polling code vs interrupts but he says that we can do this job current January probably. An unified interface is the best solution and I hope this can be done, this comment is perhaps applicable to ip6fw too. > > (I do a lot of work in protocol emulation/testing > that uses divert and dummynet. I would be spending > way too much money on test gear if I didn't have these) Yes, you're right. On Mon, Dec 03, 2001 at 10:06:35PM +0100, Sebastien Petit wrote: > On Monday 03 December 2001 21:28, Luigi Rizzo wrote: > > Sebastien, > > this is a personal point of view, and I know that people think > > differently, but I believe it would be a lot more interesting if > > you would design ethfw as an add-on for ipfw as opposed to a separate > > thing. Not only it would remove some replication from the code (all > > [sg]etsockopt, basically), but would also make its adoption easier > > to people who already use ipfw.  In fact, a very preliminary > > incarnation of ethernet matching was already in ipfw some time ago. > > > > I am a strong supporter of a unified interface for > > firewall functions. >  > Luigi, Regards, Sebastien. -- The HUT Project http://www.bsdshell.net/ spe@bsdfr.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 12 16:20:15 2001 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 7FC0737B417 for ; Wed, 12 Dec 2001 16:20:11 -0800 (PST) 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 <20011213002011.MLTY10701.rwcrmhc53.attbi.com@InterJet.elischer.org>; Thu, 13 Dec 2001 00:20: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 QAA12178; Wed, 12 Dec 2001 16:05:44 -0800 (PST) Date: Wed, 12 Dec 2001 16:05:43 -0800 (PST) From: Julian Elischer To: Aleksander Rozman - Andy Cc: freebsd-net@freebsd.org Subject: Re: Adding new networking protocol (ax.25) In-Reply-To: <5.0.2.1.0.20011211172115.02d0edb8@sundance.kks.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 a couple of comments.. understand mbufs vs Linux pkbufs. there are several "added" protocols. see what netgraph does to add itself as a protocol the socket part of doing so is in ng_socket.c and the bottom end is in ng_base.c where it adds a handler to the netisr structures. look however at how ip or appletalk actually get teh packets from there, rather than how netgraph does, which is non standard. ( you have to add yourself to structures at both the top and bottom of the kernel.) divert sockets also add themself as a IP subprotocol. (the top part) On Tue, 11 Dec 2001, Aleksander Rozman - Andy wrote: > > Hi People ! > > I was planing some time now, to try to add ax25 (packet radio) protocols, > so we could use packet radio with FreeBSD. Now I was wondering if any of > you has seen any special documentation that could help me with that. I was > told that TCP/IP Illustrated Volume 2, was great book for this purpose (I > still haven't got my hands on it, but I am trying to get it), so I was > wondering if anybody else has some info that could help me do that > (tutorials, docs, books, links, anything...). I will be porting this from > Linux, so any documentation for doing this will also be appreciated. I was > searching net for this, but I haven't found much so far, everything I did > get, I got by "accident"...so if any of you had some of such "accident" I > would be grateful for any hints... > > Take care. > Andy > > > > > ************************************************************************** > * Aleksander Rozman - Andy * Fandoms: E2:EA, SAABer, Trekkie, Earthie * > * andy@kksonline.com * Sentinel, BH 90210, True's Trooper, * > * andy@atechnet.dhs.org * Heller's Angel, Questie, Legacy, PO5, * > * Maribor, Slovenia (Europe) * Profiler, Buffy (Slayerete), Pretender * > * ICQ-UIC: 4911125 ********************************************* > * PGP key available * http://www.atechnet.dhs.org/~andy/ * > ************************************************************************** > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 12 21:30: 8 2001 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id 8F6BF37B405 for ; Wed, 12 Dec 2001 21:30:03 -0800 (PST) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id VAA99330; Wed, 12 Dec 2001 21:22:25 -0800 (PST) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id fBD5MOD19095; Wed, 12 Dec 2001 21:22:24 -0800 (PST) (envelope-from archie) From: Archie Cobbs Message-Id: <200112130522.fBD5MOD19095@arch20m.dellroad.org> Subject: Re: Problems with mpd-netgraph and Stable In-Reply-To: <3C164FE7.2010001@isi.edu> "from Lars Eggert at Dec 11, 2001 10:26:47 am" To: Lars Eggert Date: Wed, 12 Dec 2001 21:22:24 -0800 (PST) Cc: Mark A Gebert , freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Lars Eggert writes: > > I'm trying to do pptp with mpd-netgraph and a stable kernel build from a > > day ago. Everytime I run it on my IBM T-20 laptop (with fxp interface), > > it negotiates the link and as it's ready to be used the laptop crashes: > > I've seen mpd crashes with Cisco VPN servers that are stupid enough to > advertise their own IP address to the client, causing an infinite > encapsulation loop (tunneled packets forwarded over the tunnel). > > You could catch that with a sanity check inside mpd (don't accept the > servers physical address for your own use during negotiation). I've not > done this, we simply returned the Cisco box :-) Mark, Please give the patch below a try. It should cause IPCP negotiation to fail, instead of succeeding and then crashing the kernel. FYI in theory we could support the peer's "inside the tunnel" IP address being the same as the "outside the tunnel" IP address but it would require some really ugly kernel hacks. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com Index: ipcp.c =================================================================== RCS file: /home/cvs/archie/mpd/src/ipcp.c,v retrieving revision 1.2 diff -u -r1.2 ipcp.c --- ipcp.c 2001/04/12 17:03:31 1.2 +++ ipcp.c 2001/12/13 05:21:21 @@ -19,6 +19,7 @@ #include "custom.h" #include "msg.h" #include "ngfunc.h" +#include "pptp.h" #include #include @@ -607,7 +608,7 @@ switch (mode) { case MODE_REQ: if (!IpAddrInRange(&ipcp->conf.peer_allow, *ip) || !ip->s_addr) { - if (ipcp->peer_addr.s_addr == 0) +nak_ip: if (ipcp->peer_addr.s_addr == 0) Log(LG_IPCP, (" %s", "no IP address available for peer!")); if (Enabled(&ipcp->conf.options, IPCP_CONF_PRETENDIP)) { Log(LG_IPCP, (" pretending that %s is OK, will ignore", @@ -620,6 +621,17 @@ Log(LG_IPCP, (" NAKing with %s", inet_ntoa(*ip))); FsmNak(fp, opt); break; + } + if (bund->links[0]->phys->type == &gPptpPhysType) { + struct in_addr pip; + + lnk = bund->links[0]; + pip = PptpGetPeerIp(); + if (ip->s_addr == pip.s_addr) { + Log(LG_IPCP, + (" Same as PPTP IP; would cause routing loop")); + goto nak_ip; + } } Log(LG_IPCP, (" %s is OK", inet_ntoa(*ip))); ipcp->peer_addr = *ip; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Dec 13 6:17:27 2001 Delivered-To: freebsd-net@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 9017B37B41A; Thu, 13 Dec 2001 06:17:15 -0800 (PST) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.6/8.11.2) id fBDEGpw27653; Thu, 13 Dec 2001 16:16:51 +0200 (EET) (envelope-from ru) Date: Thu, 13 Dec 2001 16:16:51 +0200 From: Ruslan Ermilov To: qingli@speakeasy.net Cc: net@FreeBSD.org Subject: Re: route add - ?? Message-ID: <20011213161651.E19995@sunbay.com> References: <200112122351.fBCNpFq30812@spidey.speakeasy.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200112122351.fBCNpFq30812@spidey.speakeasy.net> User-Agent: Mutt/1.3.23i 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 [Redirected to -net] On Wed, Dec 12, 2001 at 03:51:15PM -0800, qingli@speakeasy.net wrote: > > netstat -r > ============ > Destination Gateway Flags Refs Use Netif Expire > default gateway-38 UGSc 59 0 ep0 > localhost localhost UH 1 713 lo0 > 147.11.38/24 link#6 UC 1 0 ep0 > gateway-38 0:0:c:7:ac:26 UHLW 58 0 ep0 575 > > Now I do > ======== > route add -net 192.103.54.0 64.81.55.1 > > an entry of > ============ > 192.103.54 dsl081-055-001.sfo UGSc 0 2 ep0 > > is inserted. > > Why was I allowed to add such a route. The gateway > 64.81.55.1 is not even reachable. > It is actually reachable through the default route. You can verify this by: ``route get 64.81.55.1''. The other question is why FreeBSD allows the use of indirect gateways. Well, I've offered in the past to disable this feature, but some other -net geeks like this "policy routing" feature of BSD. Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Dec 13 10:19:18 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail-01.foundation-i.com (mail-01.foundation-i.com [206.111.21.14]) by hub.freebsd.org (Postfix) with ESMTP id 1EE6D37B41B for ; Thu, 13 Dec 2001 10:19:14 -0800 (PST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Gigabit troubles X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Thu, 13 Dec 2001 10:22:59 -0800 Message-ID: <4FB6DCB8FA515F49AAE50827A60D42CD8C473F@mail-01.foundation-i.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Gigabit troubles Thread-Index: AcGEAzGrd/Cu/06uT7G2uWISI/Ibrg== From: "David Smithson" To: Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi all. I thought I'd share this with you quickly. I finally found a = solution to my gigabit connectivity problems. I have a Netgear GA-622T = connected to an Asante FriendlyNet switch. When I would bring the = interface to and UP state, the port would shutdown on the switch. I = tried everything I could think of. Finally I called Asante -- which is = what I should have done in the first place. And Engineer named Al told = me that my cable was too short (4-5 ft.). I said wtf?! What do you = mean too short? Then he explained why it matters. I'm not an = electrical engineer, so I won't even attempt to explain it here. Sure = enough, I made a longer (10 ft.) cable and for **** sake, it worked! = This may not be news to some of you, but I'm used to 100 megabit = ethernet networks where cables are sometimes too long (attenuation is = high), but never too short. -- David To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Dec 13 11:37: 2 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail.chem.msu.ru (mail.chem.msu.ru [195.208.208.19]) by hub.freebsd.org (Postfix) with ESMTP id 97F0337B405; Thu, 13 Dec 2001 11:36:56 -0800 (PST) Received: from comp.chem.msu.su ([158.250.32.97]) by mail.chem.msu.ru with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id YH35GH9N; Thu, 13 Dec 2001 22:36:33 +0300 Received: (from yar@localhost) by comp.chem.msu.su (8.11.1/8.11.1) id fBDJapJ07366; Thu, 13 Dec 2001 22:36:51 +0300 (MSK) (envelope-from yar) Date: Thu, 13 Dec 2001 22:36:51 +0300 From: Yar Tikhiy To: hackers@freebsd.org, net@freebsd.org Subject: Solution for an IPFIREWALL_FORWARD panic? Message-ID: <20011213223651.A2089@comp.chem.msu.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i 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 everybody, A kernel panic has been observed in both branches under the following conditions: o ipfw is configured with a "fwd" rule for outgoing packets that will match some RIP datagrams o GateD is started with RIP enabled and consequently sends a broadcast UDP datagram that matches the "fwd" rule The panic happens there (the source file is sys/netinet/ip_output.c; quoted as to rev. 1.99.2.21): 740 if (ro_fwd->ro_rt->rt_flags & RTF_HOST) 741 isbroadcast = 742 (ro_fwd->ro_rt->rt_flags & RTF_BROADCAST); 743 else 744 isbroadcast = in_broadcast(dst->sin_addr, ifp); 745 RTFREE(ro->ro_rt); ^^^^^^^^^^^^^^^^^^^^^^^ 746 ro->ro_rt = ro_fwd->ro_rt; 747 dst = (struct sockaddr_in *)&ro_fwd->ro_dst; ro->ro_rt is NULL, which causes the panic. As far as I understand the ip_output() code, ro->ro_rt being NULL at that point is actually all right, so to solve the problem, the code just must be changed as follows: < RTFREE(ro->ro_rt); -- > if (ro->ro_rt) > RTFREE(ro->ro_rt); Am I right? Or ro->ro_rt should not be NULL there at all and the actual bug hides somewhere else? -- Yar To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Dec 13 11:58:49 2001 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 1FB5B37B405; Thu, 13 Dec 2001 11:58:41 -0800 (PST) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) id fBDJwef85203; Thu, 13 Dec 2001 14:58:40 -0500 (EST) (envelope-from wollman) Date: Thu, 13 Dec 2001 14:58:40 -0500 (EST) From: Garrett Wollman Message-Id: <200112131958.fBDJwef85203@khavrinen.lcs.mit.edu> To: bmah@FreeBSD.ORG Cc: net@FreeBSD.ORG Subject: Re: -current vs. -stable network performance In-Reply-To: <200112131913.fBDJD8d38312@bmah.dyndns.org> References: <20011212224206.D35108@iguana.aciri.org> <200112131839.fBDId7v70103@apollo.backplane.com> <200112131913.fBDJD8d38312@bmah.dyndns.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 < said: > 5-CURRENT (11/19): 9244 pps, 35.6 Mbps > 4-STABLE (late November): 21827 pps, 84 Mbps Doesn't seem right to me. wollman@cheyenne-mountain(6)$ ttcp -t -s -v -f m -b 131072 -u mintaka ttcp-t: buflen=8192, nbuf=2048, align=16384/0, port=5001, sockbufsize=131072 udp -> mintaka ttcp-t: socket ttcp-t: sndbuf ttcp-t: 16777216 bytes in 1.32 real seconds = 97.26 Mbit/sec +++ ttcp-t: 16777216 bytes in 0.10 CPU seconds = 1276.04 Mbit/cpu sec ttcp-t: 2094 I/O calls, msec/call = 0.64, calls/sec = 1591.09 ttcp-t: 0.0user 0.1sys 0:01real 7% 12i+184d 622maxrss 0+2pf 40+174csw ttcp-t: buffer address 0x8054000 These are 4-stable 1-GHz Pentium IIIs doing UDP on a switched 100-Mbit/s network with GA620Ts. For TCP, it's a little bit worse: wollman@cheyenne-mountain(7)$ ttcp -t -s -v -f m -b 131072 mintaka ttcp-t: buflen=8192, nbuf=2048, align=16384/0, port=5001, sockbufsize=131072 tcp -> mintaka ttcp-t: socket ttcp-t: sndbuf ttcp-t: connect ttcp-t: 16777216 bytes in 1.55 real seconds = 82.46 Mbit/sec +++ ttcp-t: 16777216 bytes in 0.11 CPU seconds = 1212.30 Mbit/cpu sec ttcp-t: 2048 I/O calls, msec/call = 0.78, calls/sec = 1319.33 ttcp-t: 0.0user 0.1sys 0:01real 6% 19i+294d 246maxrss 0+2pf 7033+35csw ttcp-t: buffer address 0x8054000 Results are actually a little bit better on my six-months-ago-current desktop (an 800-MHz Pentium III with i82559). These machines are all under some level of network load, so the results for a clean system should be even better. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Dec 13 12:36:20 2001 Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 7086637B405; Thu, 13 Dec 2001 12:36:15 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.3/8.11.1) id fBDKa9m41623; Thu, 13 Dec 2001 12:36:09 -0800 (PST) (envelope-from rizzo) Date: Thu, 13 Dec 2001 12:36:09 -0800 From: Luigi Rizzo To: Garrett Wollman Cc: bmah@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: -current vs. -stable network performance Message-ID: <20011213123608.B41389@iguana.aciri.org> References: <20011212224206.D35108@iguana.aciri.org> <200112131839.fBDId7v70103@apollo.backplane.com> <200112131913.fBDJD8d38312@bmah.dyndns.org> <200112131958.fBDJwef85203@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200112131958.fBDJwef85203@khavrinen.lcs.mit.edu> User-Agent: Mutt/1.3.23i 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 As i said in my original message, I can pump out and receive almost at full speed using CURRENT, but I can only forward 2/3 of the packets that STABLE does (~80Kpps vs 125Kpps). The TTCP test is not really significant, as 1.5K packet means that you are only dealing with less than 10,000 pps, we are talking one order of magnitude higher here... cheers luigi On Thu, Dec 13, 2001 at 02:58:40PM -0500, Garrett Wollman wrote: > < said: > > > 5-CURRENT (11/19): 9244 pps, 35.6 Mbps > > 4-STABLE (late November): 21827 pps, 84 Mbps > > Doesn't seem right to me. > > wollman@cheyenne-mountain(6)$ ttcp -t -s -v -f m -b 131072 -u mintaka > ttcp-t: buflen=8192, nbuf=2048, align=16384/0, port=5001, sockbufsize=131072 udp -> mintaka > ttcp-t: socket > ttcp-t: sndbuf > ttcp-t: 16777216 bytes in 1.32 real seconds = 97.26 Mbit/sec +++ > ttcp-t: 16777216 bytes in 0.10 CPU seconds = 1276.04 Mbit/cpu sec > ttcp-t: 2094 I/O calls, msec/call = 0.64, calls/sec = 1591.09 > ttcp-t: 0.0user 0.1sys 0:01real 7% 12i+184d 622maxrss 0+2pf 40+174csw > ttcp-t: buffer address 0x8054000 > > These are 4-stable 1-GHz Pentium IIIs doing UDP on a switched > 100-Mbit/s network with GA620Ts. For TCP, it's a little bit worse: > > wollman@cheyenne-mountain(7)$ ttcp -t -s -v -f m -b 131072 mintaka > ttcp-t: buflen=8192, nbuf=2048, align=16384/0, port=5001, sockbufsize=131072 tcp -> mintaka > ttcp-t: socket > ttcp-t: sndbuf > ttcp-t: connect > ttcp-t: 16777216 bytes in 1.55 real seconds = 82.46 Mbit/sec +++ > ttcp-t: 16777216 bytes in 0.11 CPU seconds = 1212.30 Mbit/cpu sec > ttcp-t: 2048 I/O calls, msec/call = 0.78, calls/sec = 1319.33 > ttcp-t: 0.0user 0.1sys 0:01real 6% 19i+294d 246maxrss 0+2pf 7033+35csw > ttcp-t: buffer address 0x8054000 > > Results are actually a little bit better on my six-months-ago-current > desktop (an 800-MHz Pentium III with i82559). These machines are all > under some level of network load, so the results for a clean system > should be even better. > > -GAWollman > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Dec 13 14:39: 9 2001 Delivered-To: freebsd-net@freebsd.org Received: from apollo.sitaranetworks.com (apollo.sitaranetworks.com [199.103.141.105]) by hub.freebsd.org (Postfix) with ESMTP id 330E437B419 for ; Thu, 13 Dec 2001 14:39:01 -0800 (PST) Received: from rios.sitaranetworks.com (rios.sitaranetworks.com [199.103.141.78]) by apollo.sitaranetworks.com (8.10.2+Sun/8.9.3) with ESMTP id fBDMchY04847; Thu, 13 Dec 2001 17:38:43 -0500 (EST) Received: by RIOS with Internet Mail Service (5.5.2653.19) id ; Thu, 13 Dec 2001 17:38:37 -0500 Message-ID: <31269226357BD211979E00A0C9866DABE41345@RIOS> From: Charles Richmond To: "'Martin.Stiemerling@ccrle.nec.de'" , "'david-s@foundation-i.com'" , "'freebsd-net@FreeBSD.ORG'" Subject: Re: Gigabit for FreeBSD Date: Thu, 13 Dec 2001 17:38:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain 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 am curious about your problems with the netgear card. We use netgear cards at Sitara and have solved a number of driver and firmware issues. If I know the specific problems then I might be able to make some suggestions. Charles ----Original Message----- >From: "Martin Stiemerling" >To: "David Smithson" ;"freebsd-net@FreeBSD.ORG" >Cc: >Bcc: >Subj: Re: Gigabit for FreeBSD >Type: IPM.Note >Sent: Monday, December 10, 2001 7:59 AM > >D-LINK DGE500-SX works good! > > >--On Freitag, Dezember 07, 2001 10:22:44 -0800 David Smithson > wrote: > >> Hi all. Does anyone know of a good stable 1000baseTX gigabit network >> adapter that works well with FreeBSD? I have this Netgear adapter that >> seems to have problems. Help is -- of course -- appreciated. Thanks. >> >> 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 Dec 13 14:53:10 2001 Delivered-To: freebsd-net@freebsd.org Received: from web.cs.ndsu.nodak.edu (web.cs.ndsu.NoDak.edu [134.129.125.7]) by hub.freebsd.org (Postfix) with ESMTP id 3024937B417 for ; Thu, 13 Dec 2001 14:53:08 -0800 (PST) Received: (from tinguely@localhost) by web.cs.ndsu.nodak.edu (8.11.4/8.11.4) id fBDMr7S42070 for freebsd-net@freebsd.org; Thu, 13 Dec 2001 16:53:07 -0600 (CST) (envelope-from tinguely) Date: Thu, 13 Dec 2001 16:53:07 -0600 (CST) From: mark tinguely Message-Id: <200112132253.fBDMr7S42070@web.cs.ndsu.nodak.edu> To: freebsd-net@freebsd.org Subject: TCP snd_recover 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 am playing with RFC 3042 and notice some strange dupacks count sequences. One place I see a problem is with snd_recover and newreno: if (tcp_do_newreno && SEQ_LT(th->th_ack, tp->snd_recover)) { if th->th_ack > 0x7fffffff and snd_recover has not been initialized, the problem results in a ACK loop that continues until a rexmt timer expires, and a side effect of timer, the snd_recover is finally set. from looking things over, this could happen from wrapping sequences also since we do not check if snd_una <= snd_recover <= snd_max, but less likely. I have not caught this in a trace yet. --mark tinguely. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Dec 13 15:11:49 2001 Delivered-To: freebsd-net@freebsd.org Received: from fepC.post.tele.dk (fepC.post.tele.dk [195.41.46.147]) by hub.freebsd.org (Postfix) with ESMTP id D865837B416 for ; Thu, 13 Dec 2001 15:11:46 -0800 (PST) Received: from arnold.neland.dk ([62.243.77.140]) by fepC.post.tele.dk (InterMail vM.4.01.03.23 201-229-121-123-20010418) with ESMTP id <20011213231145.NLOL11568.fepC.post.tele.dk@arnold.neland.dk>; Fri, 14 Dec 2001 00:11:45 +0100 Received: from gina ([192.168.5.109]) by arnold.neland.dk (8.11.6/8.11.6) with SMTP id fBDNDCQ68643; Fri, 14 Dec 2001 00:13:13 +0100 (CET) (envelope-from leifn@neland.dk) Message-ID: <00be01c1842b$683be360$6d05a8c0@neland.dk> From: "Leif Neland" To: , "Tom" References: <5.1.0.14.2.20011213102454.0280ee78@pop3.paradise.net.nz> Subject: Re: 1 IP - 1 Firewall - 2 Webservers Date: Fri, 14 Dec 2001 00:10:48 +0100 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I've got a different solution: Use squid for logging and acl. The squid access.log contains the client adress and the requested url, just like the apache log. And squid can also grant and deny requests based on ip and url. You can also make access to certain urls passwordguarded from the outside and passwordless from the inside. The only thing which could be difficult is to have password guarded access from certain outside addresses and passwordless from other outside addresses. But that doesn't happen often, I believe. Leif To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Dec 13 15:19:20 2001 Delivered-To: freebsd-net@freebsd.org Received: from fepA.post.tele.dk (fepA.post.tele.dk [195.41.46.143]) by hub.freebsd.org (Postfix) with ESMTP id 4972237B419 for ; Thu, 13 Dec 2001 15:19:10 -0800 (PST) Received: from arnold.neland.dk ([62.243.77.140]) by fepA.post.tele.dk (InterMail vM.4.01.03.23 201-229-121-123-20010418) with ESMTP id <20011213231908.TLXA23247.fepA.post.tele.dk@arnold.neland.dk>; Fri, 14 Dec 2001 00:19:08 +0100 Received: from gina ([192.168.5.109]) by arnold.neland.dk (8.11.6/8.11.6) with SMTP id fBDNKaQ69552; Fri, 14 Dec 2001 00:20:36 +0100 (CET) (envelope-from leifn@neland.dk) Message-ID: <010a01c1842c$70c0de40$6d05a8c0@neland.dk> From: "Leif Neland" To: , "Tom Peck" References: <5.1.0.14.2.20011213102507.02807928@mail.masaclaw.co.nz> Subject: Re: 1 IP - 1 Firewall - 2 Webservers Date: Fri, 14 Dec 2001 00:18:13 +0100 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > > At 08:13 12/12/2001 -0800, you wrote: > >I perhaps should have read all of the mail..... Well, so should I have... Anyways: > >But another thing comes to mind, squid do produce quite nice logs > >as well? > > > It would, but I would prefer to save the gateways recourses (log files can > become quite large..) and to have each web server looking after it's own > logs - so basically once the gateway box has been configured, it should > never need to be touched again. You could, after rotating the logs in squid, move the log to the webserver, and split it in individual domains, and then transfer the parts to the responsible server. Leif To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Dec 13 17:21:10 2001 Delivered-To: freebsd-net@freebsd.org Received: from ns2.webvolution.net (ns2.webvolution.net [64.173.23.218]) by hub.freebsd.org (Postfix) with ESMTP id 3C66937B419 for ; Thu, 13 Dec 2001 17:21:05 -0800 (PST) Received: (from jpedras@localhost) by ns2.webvolution.net (8.11.6/8.11.6) id fBE1Hoi16393 for freebsd-net@freebsd.org; Thu, 13 Dec 2001 17:17:50 -0800 (PST) (envelope-from jpedras@webvolution.net) X-Authentication-Warning: ns2.webvolution.net: jpedras set sender to jpedras@webvolution.net using -f Date: Thu, 13 Dec 2001 17:17:50 -0800 From: Joao Pedras To: freebsd-net@freebsd.org Subject: net.inet.ip.fw.one_pass Message-ID: <20011213171750.H16010@webvolution.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Organization: Webvolution Networks Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi all. After some attempts with net.inet.ip.fw.one_pass in a recent 4.4-stable, it seems not be working, in my case. I need ipfw to continue do read the rules after a pipe. As stated in the manual this won't happen if net.inet.ip.fw.one_pass is set. I set net.inet.ip.fw.one_pass to 0 but the one_pass behaviour seems to continue. What can be wrong ? Please answer directly to me as I am not subscribing this lists. Thank you for your help. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Dec 13 18:39:45 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail.realtek.com.tw (ms1.realtek.com.tw [203.69.112.3]) by hub.freebsd.org (Postfix) with ESMTP id 497FC37B405 for ; Thu, 13 Dec 2001 18:39:39 -0800 (PST) Received: from RTCN3848 ([172.20.35.162]) by mail.realtek.com.tw (Lotus Domino Release 5.0.8) with SMTP id 2001121410393336:4660 ; Fri, 14 Dec 2001 10:39:33 +0800 Message-ID: <007401c18449$59728140$a22314ac@RTCN3848> From: "¼B¾JÂ×" To: Subject: ALG modules using divert socket on FreeBSD?? Date: Fri, 14 Dec 2001 10:45:10 +0800 MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-MIMETrack: Itemize by SMTP Server on ms1/Realtek(Release 5.0.8 |June 18, 2001) at 12/14/2001 10:39:33 AM, Serialize by Router on ms1/Realtek(Release 5.0.8 |June 18, 2001) at 12/14/2001 10:39:36 AM, Serialize complete at 12/14/2001 10:39:36 AM Content-Type: multipart/alternative; boundary="----=_NextPart_000_0071_01C1848C.6781EB20" 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_0071_01C1848C.6781EB20 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="big5" Dear friends, Are there any ALG (Application Layer Gateway) modules written by = FreeBSD/Linux's divert socket interface? I found only natd.c used divert = socket. As for ALGs for those protocols which embed connection socket = pair information in control channels (eg. FTP, RealAudio, Quake I,...), = it seems most of them are written with protocol stack callback function = interface. I think ALGs written by divert socket should be quite portable = between operating systems with divert socket capability, that is why I = am looking for such kind of support. Thanks. Regards, David ------=_NextPart_000_0071_01C1848C.6781EB20 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="big5"
Dear friends,
    Are there any ALG (Application = Layer=20 Gateway) modules written by FreeBSD/Linux's divert socket = interface?=20 I found only natd.c used divert socket. As for ALGs for those = protocols=20 which embed connection socket pair information in control channels (eg. = FTP,=20 RealAudio, Quake I,...), it seems most of them are written with protocol = stack=20 callback function interface.
    I think ALGs written by = divert socket=20 should be quite portable between operating systems with divert = socket=20 capability, that is why I am looking for such kind of = support.
 
Thanks.
 
Regards,
David
------=_NextPart_000_0071_01C1848C.6781EB20-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Dec 14 0:47:44 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail.unix.ru (mail.chs.ru [194.154.71.136]) by hub.freebsd.org (Postfix) with ESMTP id 0EEFA37B405; Fri, 14 Dec 2001 00:47:35 -0800 (PST) Received: from [192.168.81.13] (helo=sam) by mail.unix.ru with esmtp (Exim 3.22) id 16Eo08-0006Cy-00 ; Fri, 14 Dec 2001 11:47:28 +0300 Date: Fri, 14 Dec 2001 11:47:35 +0300 From: Smirnov Konstantin X-Mailer: The Bat! (v1.46d) Personal Reply-To: Smirnov Konstantin Organization: RMP X-Priority: 3 (Normal) Message-ID: <16162204675.20011214114735@rmp.ru> To: freebsd-net@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG Subject: Tuning up FreeBSD - http://www.samag.com/documents/s=1147/sam0108q/ Mime-Version: 1.0 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 Hello all! Look what I've found in http://www.samag.com/documents/s=1147/sam0108q/ This is recomendation on tuning FreeBSD for higher perfomance when it's used as the net server. ====================== cut ======================== FreeBSD Tuning Tips The following FreeBSD OS tuning tips were suggested to us by readers of our article. In single-user mode: tunefs -n enable / tunefs -n enable /usr tunefs -n enable /var Kernel modifications to make -- recompile and install the kernel afterwards: MAXUSERS 512 in /boot/load.conf hw.ata.wc="1" kern.ipc.nmbclusters="60000" in /etc/fstab Add to options for all hard disk file systems ",async": In /etc/sysctl.conf vfs.vmiodirenable=1 kern.ipc.maxsockbuf=2097152 kern.ipc.somaxconn=8192 kern.ipc.maxsockets=16424 kern.maxfiles=65536 kern.maxfilesperproc=32768 net.inet.tcp.rfc1323=1 net.inet.tcp.delayed_ack=0 net.inet.tcp.sendspace=65535 net.inet.tcp.recvspace=65535 net.inet.udp.recvspace=65535 net.inet.udp.maxdgram=57344 net.local.stream.recvspace=65535 net.local.stream.sendspace=65535 ====================== cut ======================== What is your opinion? Is that parameters suitable for ALL systems? (I think, no ;))) Maybe, somebody tried it yet? Thanks, Best regards, Samius -------------------- ...We the world... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Dec 14 5:46:24 2001 Delivered-To: freebsd-net@freebsd.org Received: from web.cs.ndsu.nodak.edu (web.cs.ndsu.NoDak.edu [134.129.125.7]) by hub.freebsd.org (Postfix) with ESMTP id E624437B417 for ; Fri, 14 Dec 2001 05:46:18 -0800 (PST) Received: (from tinguely@localhost) by web.cs.ndsu.nodak.edu (8.11.4/8.11.4) id fBEDkHN45695 for freebsd-net@freebsd.org; Fri, 14 Dec 2001 07:46:17 -0600 (CST) (envelope-from tinguely) Date: Fri, 14 Dec 2001 07:46:17 -0600 (CST) From: mark tinguely Message-Id: <200112141346.fBEDkHN45695@web.cs.ndsu.nodak.edu> To: freebsd-net@freebsd.org Subject: Re: TCP snd_recover Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Sorry, I lost my negatives this morning ... we can NOT do much about stale snd_recover, and would NOT happen very easilly, NOR often. initialization for the snd_recover TCPS_SYN_SENT and TCPS_SYN_RECEIVED is a simple solution that can handle the simple case, and much more likely case. --mark To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Dec 14 8:25:33 2001 Delivered-To: freebsd-net@freebsd.org Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by hub.freebsd.org (Postfix) with ESMTP id 1365D37B419; Fri, 14 Dec 2001 08:25:03 -0800 (PST) Received: from ptavv.es.net (localhost [127.0.0.1]) by ptavv.es.net (8.10.1/8.10.1) with ESMTP id fBEGOsd19051; Fri, 14 Dec 2001 08:24:56 -0800 (PST) Message-Id: <200112141624.fBEGOsd19051@ptavv.es.net> To: Smirnov Konstantin Cc: freebsd-net@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG Subject: Re: Tuning up FreeBSD - http://www.samag.com/documents/s=1147/sam0108q/ In-reply-to: Your message of "Fri, 14 Dec 2001 11:47:35 +0300." <16162204675.20011214114735@rmp.ru> Date: Fri, 14 Dec 2001 08:24:54 -0800 From: "Kevin Oberman" 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 > Date: Fri, 14 Dec 2001 11:47:35 +0300 > From: Smirnov Konstantin > Sender: owner-freebsd-net@FreeBSD.ORG > > Hello all! > > Look what I've found in > http://www.samag.com/documents/s=1147/sam0108q/ > This is recomendation on tuning FreeBSD for higher perfomance when > it's used as the net server. > > ====================== cut ======================== > FreeBSD Tuning Tips > > The following FreeBSD OS tuning tips were suggested to us by readers of our article. > > In single-user mode: > > tunefs -n enable / > tunefs -n enable /usr > tunefs -n enable /var > > Kernel modifications to make -- recompile and install the kernel afterwards: > MAXUSERS 512 > > in /boot/load.conf > hw.ata.wc="1" > kern.ipc.nmbclusters="60000" > in /etc/fstab > > Add to options for all hard disk file systems ",async": > > In /etc/sysctl.conf > vfs.vmiodirenable=1 > kern.ipc.maxsockbuf=2097152 > kern.ipc.somaxconn=8192 > kern.ipc.maxsockets=16424 > kern.maxfiles=65536 > kern.maxfilesperproc=32768 > net.inet.tcp.rfc1323=1 > net.inet.tcp.delayed_ack=0 > net.inet.tcp.sendspace=65535 > net.inet.tcp.recvspace=65535 > net.inet.udp.recvspace=65535 > net.inet.udp.maxdgram=57344 > net.local.stream.recvspace=65535 > net.local.stream.sendspace=65535 > ====================== cut ======================== > > What is your opinion? Is that parameters suitable for ALL systems? (I > think, no ;))) Maybe, somebody tried it yet? If it was a good idea on all systems, there would be no tuning to do. The values you suggest are generally a good thing for a fairly fast link. Several of the values you suggest are default and others, like the expansion of send and recvspace are a good idea as long as you are on a fairly fast line to the world. On a slow line, this sort of thing can deteriorate performance. One thing I would certainly add is the expansion of mss to 1460 if you are Ethernet connected. You suggestions also require substantially more memory than the defaults, so it is not a good idea for a system with only limited memory. (Of course, with current memory prices, most systems have no problems in this area!) There are two items I must take issue with. 1. I would not enable soft updates to /. If you use the default partition size for /, it will tend to break the system if you update it. And soft updates on / are seldom a significant improvement since writes to / are fairly limited. 2. If you use soft updates, why are you suggesting that the file systems run async? In combination write cache on the disks, you are really asking for a disaster and the whole idea of soft updates is to allow safe asynchronous disk writes most of the time without risk to file system integrity. Running any system that needs reliability with this combination (write cache on, soft updates, and async) is a true recipe for disaster. R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Dec 14 9: 5:52 2001 Delivered-To: freebsd-net@freebsd.org Received: from prima-exc01.cidadei.com.br (a200042033005.rev.prima.com.ar [200.42.33.5]) by hub.freebsd.org (Postfix) with ESMTP id 0F61737B417; Fri, 14 Dec 2001 09:05:47 -0800 (PST) Received: by prima-exc01.cidadei.com.br with Internet Mail Service (5.5.2653.19) id ; Fri, 14 Dec 2001 14:57:42 -0300 Message-ID: <9CF6FAED416EA043A968ED643E13719502C6C45A@prima-exc01.cidadei.com.br> From: Daniel Abad To: freebsd-net@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG Subject: no memory for rx list Date: Fri, 14 Dec 2001 14:57:42 -0300 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 What should I do to fix it? Dec 13 17:17:53 server /kernel: xl0: no memory for rx list -- packet dropped! Dec 13 17:17:53 server last message repeated 4 times Dec 13 17:17:53 server /kernel: xl1: no memory for rx list -- packet dropped! Dec 13 17:17:53 server /kernel: xl0: no memory for rx list -- packet dropped! Dec 13 17:17:53 server last message repeated 3 times Dec 13 17:17:53 server /kernel: xl1: no memory for rx list -- packet dropped! Dec 13 17:17:53 server /kernel: xl0: no memory for rx list -- packet dropped! Dec 13 17:17:53 server2 last message repeated 23 times Tks. Dan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Dec 14 14:33:24 2001 Delivered-To: freebsd-net@freebsd.org Received: from sr3.terra.com.br (sr3.terra.com.br [200.176.3.18]) by hub.freebsd.org (Postfix) with ESMTP id 9EE0037B405; Fri, 14 Dec 2001 14:33:20 -0800 (PST) Received: from srv16-sao.terra.com.br (srv16-sao.terra.com.br [200.176.3.39]) by sr3.terra.com.br (Postfix) with ESMTP id CD93315AAF7; Fri, 14 Dec 2001 20:33:10 -0200 (GMT+2) Received: from rodrigo (dl-rip-C8B1EDEA.mii.terra.com.br [200.177.237.234]) by srv16-sao.terra.com.br (Postfix) with ESMTP id AF4EA2BB37; Fri, 14 Dec 2001 20:33:08 -0200 (GMT+2) Message-ID: <008d01c184ef$52c6e060$eaedb1c8@rodrigo> From: =?iso-8859-1?Q?Jo=E3o_Silvestre?= To: Cc: Subject: HELP!!! Date: Fri, 14 Dec 2001 20:33:12 -0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi All, I need to receive GRE packets from CISCO... I have patched the kernel with the gre.c (from squid) and add OPTIONS GRE too. The tcpdump shows that CISCO is sending GRE packets to FreeBSD, but the FreeBSD isn't decapsulating packets. I need to redirect these packets to proxy... What's is wrong in my system? Thanks! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Dec 15 7:52: 7 2001 Delivered-To: freebsd-net@freebsd.org Received: from post.webmailer.de (natwar.webmailer.de [192.67.198.70]) by hub.freebsd.org (Postfix) with ESMTP id 133A937B419; Sat, 15 Dec 2001 07:52:03 -0800 (PST) Received: from master (pD9049121.dip.t-dialin.net [217.4.145.33]) by post.webmailer.de (8.9.3/8.8.7) with ESMTP id QAA00092; Sat, 15 Dec 2001 16:47:41 +0100 (MET) From: "=?ISO-8859-1?Q?Boris_K=F6ster_?=" Organization: X-ITEC IT-Consulting http://www.x-itec.de To: freebsd-questions@FreeBSD.ORG, freebsd-isp@freeBSD.FreeBSD.ORG, freebsd-net@FreeBSD.ORG Date: Sat, 15 Dec 2001 16:51:58 +0100 MIME-Version: 1.0 Subject: FreeBSD IPSEC mini-howto updated! Message-ID: <3C1B7FAE.31484.401E08@localhost> X-mailer: Pegasus Mail for Windows (v4.01) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: Quoted-printable Content-description: Mail message body 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 New in 12/2001: * complete rewrite of this howto * all scripts redesigned * all scripts updated to BSD 4.4 * racoon configuration updated * NEW: interoperability with PGP NET * NEW: more examples, more infos for newbies * NEW: used 192... adresses for easier reading * NEW: ipfw settings / example http://www.x-itec.de/projects/tuts/ipsec-howto.txt FreeBSD ipsec mini-howto -- Boris K=F6ster [C / C++ / PHP / FreeBSD / Security / Consulting] Maintainer of IPSEC Mini-HowTo | QSP | and more. HTTP://www.x-itec.de * koester@x-itec.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Dec 15 10:39:42 2001 Delivered-To: freebsd-net@freebsd.org Received: from hotmail.com (oe18.pav1.hotmail.com [64.4.30.122]) by hub.freebsd.org (Postfix) with ESMTP id 704A137B41A for ; Sat, 15 Dec 2001 10:39:35 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 15 Dec 2001 10:39:35 -0800 X-Originating-IP: [66.185.84.77] From: "jack xiao" To: , Subject: radiusclients questions Date: Sat, 15 Dec 2001 13:41:40 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003B_01C1856E.39BBF2C0" 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: 15 Dec 2001 18:39:35.0142 (UTC) FILETIME=[D7DFF860:01C18597] 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_003B_01C1856E.39BBF2C0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 DQpIaSwNCg0KTm93IEkgd2FudCB0byB1c2UgcmFkaXVzY2xpZW50ICggdmVyc2lvbiAwLjMuMSAp IHVuZGVyIEZyZWVCU0QgcG9ydHMgYW5kIHVzZSByYWRsb2dpbiB0byBzdWJzdGl0dXRlIG5vcm1h bCBsb2dpbiBmb3IgUFBQIGxvZ2luIHVzZXIuIEkgaGF2ZSBwb3J0ZWQgcmFkaXVzY2xpZW50IGFu ZCByYWRsb2dpbiB3b3JrcyB3ZWxsLCBidXQgSSBkb24ndCBrbm93IGhvdyB0byB1c2UgcmFkbG9n aW4gaW5zdGVhZCBvZiBsb2dpbi4gQW55IGlkZWFzIHdpbGwgYmUgYXBwcmVjaWF0ZWQuDQoNClRo YW5rcyENCg0KSmFjaw0KDQoNCg0KDQo= ------=_NextPart_000_003B_01C1856E.39BBF2C0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC4yNjAwLjAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8Qk9E WSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjwvRk9OVD4m bmJzcDs8L0RJVj4NCjxESVYgc3R5bGU9IkZPTlQ6IDEwcHQgYXJpYWwiPjxGT05UIGZhY2U9QXJp YWwgc2l6ZT0yPkhpLDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+ PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5Ob3cgSSB3 YW50IHRvIHVzZSByYWRpdXNjbGllbnQgKCB2ZXJzaW9uIDAuMy4xIA0KKSZuYnNwO3VuZGVyIEZy ZWVCU0QgcG9ydHMgYW5kJm5ic3A7dXNlIHJhZGxvZ2luIHRvIHN1YnN0aXR1dGUgbm9ybWFsIGxv Z2luIA0KZm9yJm5ic3A7UFBQIGxvZ2luIHVzZXIuJm5ic3A7SSBoYXZlIHBvcnRlZCByYWRpdXNj bGllbnQgYW5kIHJhZGxvZ2luJm5ic3A7d29ya3MgDQp3ZWxsLCBidXQgSSBkb24ndCBrbm93IGhv dyB0byB1c2UgcmFkbG9naW4gaW5zdGVhZCBvZiBsb2dpbi4mbmJzcDtBbnkgaWRlYXMgd2lsbCAN CmJlIGFwcHJlY2lhdGVkLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXpl PTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5UaGFu a3MhPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48L0ZPTlQ+Jm5i c3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPkphY2s8L0ZPTlQ+PC9ESVY+ DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+ PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBm YWNlPUFyaWFsIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJp YWwgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_003B_01C1856E.39BBF2C0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Dec 15 13:10:46 2001 Delivered-To: freebsd-net@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id 8790937B416; Sat, 15 Dec 2001 13:10:31 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id 07E9081D03; Sat, 15 Dec 2001 15:10:25 -0600 (CST) Date: Sat, 15 Dec 2001 15:10:25 -0600 From: Alfred Perlstein To: Bruce Evans Cc: wollman@freebsd.org, net@freebsd.org, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: fifo fix (Re: cvs commit: src/sys/fs/fifofs fifo_vnops.c) Message-ID: <20011215151025.A82439@elvis.mu.org> References: <20011212125324.R92148@elvis.mu.org> <20011213224148.M469-100000@gamplex.bde.org> <20011213120830.E79896@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: <20011213120830.E79896@elvis.mu.org>; from alfred@FreeBSD.org on Thu, Dec 13, 2001 at 12:08:30PM -0600 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 * Alfred Perlstein [011213 12:08] wrote: > * Bruce Evans [011213 05:56] wrote: > > > > >From POSIX.1-200x-draft7 (this has not changed since at least the 1990 > > version): > > > > ! 36609 When attempting to read from an empty pipe or FIFO: > > ! > > ! 36610 * If no process has the pipe open for writing, read( ) shall return 0 to indicate end-of-file. > > > > The changes make read() block instead, at least for the non-O_NONBLOCK case. > > I'm not sure of the effect of the change in the O_NONBLOCK case, but it > > seems likely that -1/EAGAIN is returned instead of 0/no-error. > > Ok, I can fix this. (I hope :) ) Can people take a look at this fix? It seems to dtrt, but I need feedback here. It basically backs out my last two revisions and changes the hacks the poll call to seemingly do the right thing. Index: fifo_vnops.c =================================================================== RCS file: /home/ncvs/src/sys/fs/fifofs/fifo_vnops.c,v retrieving revision 1.57 diff -u -r1.57 fifo_vnops.c --- fifo_vnops.c 12 Dec 2001 09:35:33 -0000 1.57 +++ fifo_vnops.c 15 Dec 2001 21:25:30 -0000 @@ -199,6 +199,7 @@ } fip->fi_readers = fip->fi_writers = 0; wso->so_snd.sb_lowat = PIPE_BUF; + rso->so_state |= SS_CANTRCVMORE; } if (ap->a_mode & FREAD) { fip->fi_readers++; @@ -283,11 +284,6 @@ VOP_UNLOCK(ap->a_vp, 0, td); error = soreceive(rso, (struct sockaddr **)0, uio, (struct mbuf **)0, (struct mbuf **)0, (int *)0); - /* - * Clear EOF indication after first such return. - */ - if (uio->uio_resid == startresid) - rso->so_state &= ~SS_CANTRCVMORE; vn_lock(ap->a_vp, LK_EXCLUSIVE | LK_RETRY, td); if (ap->a_ioflag & IO_NDELAY) rso->so_state &= ~SS_NBIO; @@ -455,13 +451,23 @@ } */ *ap; { struct file filetmp; - int revents = 0; + int s, revents = 0; if (ap->a_events & (POLLIN | POLLPRI | POLLRDNORM | POLLRDBAND)) { + struct socket *so; + int oflg; + filetmp.f_data = (caddr_t)ap->a_vp->v_fifoinfo->fi_readsock; + so = (struct socket *)filetmp.f_data; + s = splnet(); + oflg = so->so_state & SS_CANTRCVMORE; + if (ap->a_vp->v_fifoinfo->fi_writers == 0) + so->so_state &= ~SS_CANTRCVMORE; if (filetmp.f_data) revents |= soo_poll(&filetmp, ap->a_events, ap->a_cred, ap->a_td); + so->so_state |= oflg; + splx(s); } if (ap->a_events & (POLLOUT | POLLWRNORM | POLLWRBAND)) { filetmp.f_data = (caddr_t)ap->a_vp->v_fifoinfo->fi_writesock; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message