From owner-freebsd-net Sun Dec 16 1:26:44 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 5748C37B41A; Sun, 16 Dec 2001 01:26:40 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id E226781D03; Sun, 16 Dec 2001 03:26:39 -0600 (CST) Date: Sun, 16 Dec 2001 03:26:39 -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: <20011216032639.B82439@elvis.mu.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 * Alfred Perlstein [011215 15:10] wrote: > > 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. I'm about ready to commit this. The delta is at: http://www.mu.org/~bright/fifo.diff Any objections? -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Dec 16 12:26:38 2001 Delivered-To: freebsd-net@freebsd.org Received: from post.webmailer.de (natpost.webmailer.de [192.67.198.65]) by hub.freebsd.org (Postfix) with ESMTP id BD6E537B405 for ; Sun, 16 Dec 2001 12:26:32 -0800 (PST) Received: from master (pD9049163.dip.t-dialin.net [217.4.145.99]) by post.webmailer.de (8.9.3/8.8.7) with ESMTP id VAA22274 for ; Sun, 16 Dec 2001 21:26:31 +0100 (MET) From: "=?ISO-8859-1?Q?Boris_K=F6ster_?=" Organization: X-ITEC IT-Consulting http://www.x-itec.de To: freebsd-net@freebsd.org Date: Sun, 16 Dec 2001 21:26:30 +0100 MIME-Version: 1.0 Subject: nat / ipdivert problem - if possible please help Message-ID: <3C1D1186.26005.1F1D48@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 I have a problem. hope# uname -a FreeBSD hope.hope 4.4-STABLE FreeBSD 4.4-STABLE #2: Fri Dec 14 14:59:52 CE= T 2006 (???) I have a BSD laptop on 192.168.0.3 I have a BSD server 192.168.0.99 I have a win2k server at 192.168.0.1 I want to route telnet service on .99 to .3 that means if you telnet from .1 to .99 the laptop answers on 3 This feature requires ipfw/natd and I have made a kernel for this (IPFIREW= ALL, IPDIVERT) I don=B4t know how to continue, i tried this on the bsd server: /sbin/ipfw -f flush /sbin/ipfw add divert natd all from any to any via ed0 /sbin/ipfw add pass all from any to any natd -interface ed0 -redirect_port tcp 192.168.0.3:telnet 192.168.0.99:tel= net But without success. I am experimenting a lot of hours/days on this and I do not know how to co= ntinue, need help. -- 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 Sun Dec 16 19: 4:51 2001 Delivered-To: freebsd-net@freebsd.org Received: from harrier.prod.itd.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by hub.freebsd.org (Postfix) with ESMTP id 33A1537B41B for ; Sun, 16 Dec 2001 19:04:48 -0800 (PST) Received: from dialup-209.244.105.100.dial1.sanjose1.level3.net ([209.244.105.100] helo=blossom.cjclark.org) by harrier.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16Fo55-00043v-00; Sun, 16 Dec 2001 19:04:44 -0800 Received: (from cjc@localhost) by blossom.cjclark.org (8.11.6/8.11.3) id fBH34dh15793; Sun, 16 Dec 2001 19:04:39 -0800 (PST) (envelope-from cjc) Date: Sun, 16 Dec 2001 19:04:39 -0800 From: "Crist J . Clark" To: =?iso-8859-1?Q?Boris_K=F6ster_?= Cc: freebsd-net@FreeBSD.ORG Subject: Re: nat / ipdivert problem - if possible please help Message-ID: <20011216190439.B15624@blossom.cjclark.org> References: <3C1D1186.26005.1F1D48@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: <3C1D1186.26005.1F1D48@localhost>; from koester@x-itec.de on Sun, Dec 16, 2001 at 09:26:30PM +0100 X-URL: http://people.freebsd.org/~cjc/ Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sun, Dec 16, 2001 at 09:26:30PM +0100, Boris Köster wrote: > I have a problem. > > hope# uname -a > FreeBSD hope.hope 4.4-STABLE FreeBSD 4.4-STABLE #2: Fri Dec 14 14:59:52 CET > 2006 (???) > > I have a BSD laptop on 192.168.0.3 > > I have a BSD server 192.168.0.99 > > I have a win2k server at 192.168.0.1 > > I want to route telnet service on .99 to .3 > that means if you telnet from .1 to .99 the laptop answers on 3 > > This feature requires ipfw/natd and I have made a kernel for this (IPFIREWALL, > IPDIVERT) > > I don´t know how to continue, i tried this on the bsd server: > > /sbin/ipfw -f flush > /sbin/ipfw add divert natd all from any to any via ed0 > /sbin/ipfw add pass all from any to any > natd -interface ed0 -redirect_port tcp 192.168.0.3:telnet 192.168.0.99:telnet > > But without success. The problem I see is this, 1) The Win2k machine tries to initiate a connection to the BSD server, 192.168.0.1 -> 192.168.0.99 SYN 2) The BSD server rewrites the packet and sends its on its way, 192.168.0.1 -> 192.168.0.3 SYN 3) The BSD laptop gets the packet and sends back a response, 192.168.0.3 -> 192.168.0.1 SYN-ACK 4) The Win2k machine receives the packet, but since it hasn't tried to initiate a connection to 192.168.0.3, 192.168.0.1 -> 192.168.0.3 RST See the problem now? -- "It's always funny until someone gets hurt. Then it's hilarious." Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Dec 17 0:21:10 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 63DBD37B431 for ; Mon, 17 Dec 2001 00:20:52 -0800 (PST) Received: (qmail 20812 invoked by uid 3193); 17 Dec 2001 08:20:51 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 17 Dec 2001 08:20:51 -0000 Date: Mon, 17 Dec 2001 03:20:51 -0500 (EST) From: Mike Silbersack X-Sender: To: Thomas Zenker Cc: , Subject: Re: USB ethernet problem In-Reply-To: <20011217090920.A763@mezcal.tue.le> 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 (Moving over to -net, please remove -stable from any cc's) On Mon, 17 Dec 2001, Thomas Zenker wrote: > I allways wondered, why the initial slowstart window is set to one > (well some years I didn't look into the tcp code though). 9 years > ago I had to develope the firmware for a store&foreward radio > network, where I applied a lot of the ideas from the then net/2 tcp > stack. The rtt in such a network is really horrible and packetsizes > have to be taken in account. Anyway the optimal initial window there > was 2. With a window of two there much more probability to get a > connection going, because you send two packets in the beginning, > if the first is lost, the receiption of the second one gets the > first one resent long before the timeout. Otherway round, if the > second is lost... the third is on its way already. With a intital > window of 1 the only recovery is by timeout. The argument against > bigger than two was (at least in my case) not to defeat the intention > of the slowstart. Anyway, in tcp probably something between 2 and > 4 could be considered. > > Thomas RFC 2581 suggests that 4 is a good value (well, not exactly 4, they have a formula which comes out to about 4 in most cases.) I'm inclined to agree that something between 2-4 would be a good value for our non-local slowstart flightsize as well. Maybe after 4.5 is released we can go look into it. (It's too late to be changing stuff now.) 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 17 1:18:20 2001 Delivered-To: freebsd-net@freebsd.org Received: from smtp.www-service.de (smtp.www-service.de [212.77.161.16]) by hub.freebsd.org (Postfix) with SMTP id 3D5B037B419 for ; Mon, 17 Dec 2001 01:18:14 -0800 (PST) Received: (qmail 26446 invoked from network); 17 Dec 2001 09:18:02 -0000 Received: from pd90065db.dip.t-dialin.net (HELO fw.tue.le) (217.0.101.219) by smtp.www-service.de with SMTP; 17 Dec 2001 09:18:02 -0000 Received: from mezcal.tue.le (mezcal.tue.le [192.168.201.20]) by fw.tue.le (8.8.8/8.8.8) with ESMTP id KAA23066; Mon, 17 Dec 2001 10:17:49 +0100 (CET) (envelope-from thz@mezcal.tue.le) Received: (from thz@localhost) by mezcal.tue.le (8.11.6/8.11.6) id fBH9HmW01434; Mon, 17 Dec 2001 10:17:48 +0100 (CET) (envelope-from thz) Date: Mon, 17 Dec 2001 10:17:48 +0100 From: Thomas Zenker To: Mike Silbersack Cc: freebsd-net@freebsd.org Subject: Re: USB ethernet problem Message-ID: <20011217101748.A1395@mezcal.tue.le> Mail-Followup-To: Mike Silbersack , freebsd-net@freebsd.org References: <20011217090920.A763@mezcal.tue.le> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from silby@silby.com on Mon, Dec 17, 2001 at 03:20:51AM -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, Dec 17, 2001 at 03:20:51AM -0500, Mike Silbersack wrote: > > (Moving over to -net, please remove -stable from any cc's) > > On Mon, 17 Dec 2001, Thomas Zenker wrote: > > > I allways wondered, why the initial slowstart window is set to one > > (well some years I didn't look into the tcp code though). 9 years > > ago I had to develope the firmware for a store&foreward radio > > network, where I applied a lot of the ideas from the then net/2 tcp > > stack. The rtt in such a network is really horrible and packetsizes > > have to be taken in account. Anyway the optimal initial window there > > was 2. With a window of two there much more probability to get a > > connection going, because you send two packets in the beginning, > > if the first is lost, the receiption of the second one gets the > > first one resent long before the timeout. Otherway round, if the > > second is lost... the third is on its way already. With a intital > > window of 1 the only recovery is by timeout. The argument against > > bigger than two was (at least in my case) not to defeat the intention > > of the slowstart. Anyway, in tcp probably something between 2 and > > 4 could be considered. > > > > Thomas > > RFC 2581 suggests that 4 is a good value (well, not exactly 4, they have a > formula which comes out to about 4 in most cases.) I'm inclined to agree > that something between 2-4 would be a good value for our non-local > slowstart flightsize as well. Maybe after 4.5 is released we can go look > into it. (It's too late to be changing stuff now.) > > Mike "Silby" Silbersack ok. everybody can try this anyway: sysctl net.inet.tcp.slowstart_flightsize=2 -- Thomas Zenker c/o Lennartz electronic GmbH Bismarckstrasse 136, D-72072 Tuebingen, Germany Phone: +49-(0)7071-93550 Email: thz@lennartz-electronic.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Dec 17 5:10:29 2001 Delivered-To: freebsd-net@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 8891D37B41D; Mon, 17 Dec 2001 05:10:09 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id AAA31518; Tue, 18 Dec 2001 00:10:04 +1100 Date: Tue, 18 Dec 2001 00:09:42 +1100 (EST) From: Bruce Evans X-X-Sender: To: Alfred Perlstein Cc: , , , Subject: Re: fifo fix (Re: cvs commit: src/sys/fs/fifofs fifo_vnops.c) In-Reply-To: <20011215151025.A82439@elvis.mu.org> Message-ID: <20011217230720.N13599-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sat, 15 Dec 2001, Alfred Perlstein wrote: > 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 > ... > @@ -455,13 +451,23 @@ > } */ *ap; > { > struct file filetmp; > - int revents = 0; > + int s, revents = 0; New style bug: disordered declaration. (Old style bug: initialized in auto declaration.) > > if (ap->a_events & (POLLIN | POLLPRI | POLLRDNORM | POLLRDBAND)) { > + struct socket *so; > + int oflg; Style bugs: nested declarations. > + > 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); I'm not happy with frobbing the socket state. I suggest frobbing the events mask instead. Either use a flag to tell sopoll() to ignore SS_CANTRCVMORE, or use new events POLLIN_IGNORE_EOF and POLLRDNORM_IGNORE_EOF (convert the userland POLLIN/POLLRDNORM to these and change sopoll() to support them). > } > if (ap->a_events & (POLLOUT | POLLWRNORM | POLLWRBAND)) { > filetmp.f_data = (caddr_t)ap->a_vp->v_fifoinfo->fi_writesock; > Similar changes may be needed for kevent(). kevent() has a way to modify modify the usual watermark handling for reads, but doesn't have anything similar for EOFs, although it already has more complete EOF handling (filt_kqread() sets EV_EOF for EOFs, but sopoll() is missing support for POLLHUP). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Dec 17 5:35:37 2001 Delivered-To: freebsd-net@freebsd.org Received: from smtp.www-service.de (smtp.www-service.de [212.77.161.16]) by hub.freebsd.org (Postfix) with SMTP id A637F37B405 for ; Mon, 17 Dec 2001 05:35:31 -0800 (PST) Received: (qmail 15632 invoked from network); 17 Dec 2001 13:35:19 -0000 Received: from pd90065ae.dip.t-dialin.net (HELO fw.tue.le) (217.0.101.174) by smtp.www-service.de with SMTP; 17 Dec 2001 13:35:19 -0000 Received: from mezcal.tue.le (mezcal.tue.le [192.168.201.20]) by fw.tue.le (8.8.8/8.8.8) with ESMTP id OAA23574; Mon, 17 Dec 2001 14:35:04 +0100 (CET) (envelope-from thz@mezcal.tue.le) Received: (from thz@localhost) by mezcal.tue.le (8.11.6/8.11.6) id fBHDZ3V16618; Mon, 17 Dec 2001 14:35:03 +0100 (CET) (envelope-from thz) Date: Mon, 17 Dec 2001 14:35:03 +0100 From: Thomas Zenker To: Mike Silbersack Cc: freebsd-net@freebsd.org Subject: Re: USB ethernet problem Message-ID: <20011217143503.A16555@mezcal.tue.le> Mail-Followup-To: Mike Silbersack , freebsd-net@freebsd.org References: <20011217090920.A763@mezcal.tue.le> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from silby@silby.com on Mon, Dec 17, 2001 at 03:20:51AM -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, Dec 17, 2001 at 03:20:51AM -0500, Mike Silbersack wrote: .. deleted > > RFC 2581 suggests that 4 is a good value (well, not exactly 4, they have a > formula which comes out to about 4 in most cases.) I'm inclined to agree > that something between 2-4 would be a good value for our non-local > slowstart flightsize as well. Maybe after 4.5 is released we can go look > into it. (It's too late to be changing stuff now.) > > Mike "Silby" Silbersack just to remind ourselfs why this thread came up (i myself had nearly forgotten about it :-): for the instruments, we produce and which run FreeBSD embedded, I was doing an installation/upgrade package for our production here. The install is done via USB/ethernet adaptor. Because of the change to recvspace lately (now 65536) the USB/ethernet adaptor (or the switch, not sure) is overrun and resulting installation speed drops to unacceptible 10KB/s. It is not a problem for me, because I can manipulate per sysctl recvspace in my package. But it may become a problem for people which want to install FreeBSD 4.5 over USB/ethernet with the normal sysinstall (for example laptop users). AFAIK there is no knob if you boot from floppy. -- Thomas Zenker c/o Lennartz electronic GmbH Bismarckstrasse 136, D-72072 Tuebingen, Germany Phone: +49-(0)7071-93550 Email: thz@lennartz-electronic.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Dec 17 5:49:15 2001 Delivered-To: freebsd-net@freebsd.org Received: from icon.bg (icon.bg [62.176.80.58]) by hub.freebsd.org (Postfix) with ESMTP id 9E49237B405 for ; Mon, 17 Dec 2001 05:49:11 -0800 (PST) Received: (qmail 95354 invoked by uid 1000); 17 Dec 2001 13:49:08 -0000 Date: Mon, 17 Dec 2001 15:49:08 +0200 From: Victor Ivanov To: freebsd-net@freebsd.org Subject: RTM_DELETE not reported for AF_INET? Message-ID: <20011217134908.GA95331@icon.icon.bg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.23.2i 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 found something interesting, when opening a routing socket using sock = socket(AF_ROUTE, SOCK_RAW, AF_INET); no RTM_DELETE messages are reported, unless errno != 0. When opened using the last argument == 0 (AF_UNSPEC), it reports all operations. Is this a bug or a feature, and what's the reason for it? -- Players win and winners play Have a lucky day To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Dec 17 10:41:19 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 2DCE637BB21; Mon, 17 Dec 2001 10:31:05 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id 43D5C81D03; Mon, 17 Dec 2001 12:29:53 -0600 (CST) Date: Mon, 17 Dec 2001 12:29:53 -0600 From: Alfred Perlstein To: Bruce Evans Cc: wollman@FreeBSD.org, net@FreeBSD.org, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: fifo fix (Re: cvs commit: src/sys/fs/fifofs fifo_vnops.c) Message-ID: <20011217122953.G82439@elvis.mu.org> References: <20011215151025.A82439@elvis.mu.org> <20011217230720.N13599-100000@gamplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011217230720.N13599-100000@gamplex.bde.org>; from bde@zeta.org.au on Tue, Dec 18, 2001 at 12:09:42AM +1100 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 * Bruce Evans [011217 07:10] wrote: > On Sat, 15 Dec 2001, Alfred Perlstein wrote: > > > 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 > > ... > > @@ -455,13 +451,23 @@ > > } */ *ap; > > { > > struct file filetmp; > > - int revents = 0; > > + int s, revents = 0; > > New style bug: disordered declaration. (Old style bug: initialized in > auto declaration.) > > > > > if (ap->a_events & (POLLIN | POLLPRI | POLLRDNORM | POLLRDBAND)) { > > + struct socket *so; > > + int oflg; > > Style bugs: nested declarations. I'll take care of these two. > > + > > 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); > > I'm not happy with frobbing the socket state. I suggest frobbing the > events mask instead. Either use a flag to tell sopoll() to ignore > SS_CANTRCVMORE, or use new events POLLIN_IGNORE_EOF and > POLLRDNORM_IGNORE_EOF (convert the userland POLLIN/POLLRDNORM to these > and change sopoll() to support them). I'll consider that. There's actually a bug here, I need to make sure 'so' isn't NULL before I do this, sticking the frobbing under the 'if (filetmp.f_data)' should fix that. > > } > > if (ap->a_events & (POLLOUT | POLLWRNORM | POLLWRBAND)) { > > filetmp.f_data = (caddr_t)ap->a_vp->v_fifoinfo->fi_writesock; > > > > Similar changes may be needed for kevent(). kevent() has a way to modify > modify the usual watermark handling for reads, but doesn't have anything > similar for EOFs, although it already has more complete EOF handling > (filt_kqread() sets EV_EOF for EOFs, but sopoll() is missing support for > POLLHUP). I'll talk to jlemon about this. -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' http://www.morons.org/rants/gpl-harmful.php3 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Dec 17 18:39: 2 2001 Delivered-To: freebsd-net@freebsd.org Received: from hotmail.com (oe27.pav1.hotmail.com [64.4.30.84]) by hub.freebsd.org (Postfix) with ESMTP id 0F1FA37B405; Mon, 17 Dec 2001 18:38:58 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 17 Dec 2001 18:38:54 -0800 X-Originating-IP: [66.185.84.77] From: "jack xiao" To: , Subject: Fw: radiusclients questions Date: Mon, 17 Dec 2001 21:41:00 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00E5_01C18743.8494FE00" 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: 18 Dec 2001 02:38:54.0027 (UTC) FILETIME=[225511B0:01C1876D] 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_00E5_01C18743.8494FE00 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 DQpIaSwNCg0KTm93IEkgd2FudCB0byB1c2UgcmFkaXVzY2xpZW50ICggdmVyc2lvbiAwLjMuMSAp IHVuZGVyIEZyZWVCU0QgcG9ydHMgYW5kIHVzZSByYWRsb2dpbiB0byBzdWJzdGl0dXRlIG5vcm1h bCBsb2dpbiBmb3IgUFBQIGxvZ2luIHVzZXIuIEkgaGF2ZSBwb3J0ZWQgcmFkaXVzY2xpZW50IGFu ZCByYWRsb2dpbiB3b3JrcyB3ZWxsLCBidXQgSSBkb24ndCBrbm93IGhvdyB0byB1c2UgcmFkbG9n aW4gaW5zdGVhZCBvZiBsb2dpbi4gQW55IGlkZWFzIHdpbGwgYmUgYXBwcmVjaWF0ZWQuDQoNClRo YW5rcyENCg0KSmFjaw0KDQoNCg0KDQo= ------=_NextPart_000_00E5_01C18743.8494FE00 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_00E5_01C18743.8494FE00-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Dec 17 18:49: 8 2001 Delivered-To: freebsd-net@freebsd.org Received: from hotmail.com (oe64.pav1.hotmail.com [64.4.30.199]) by hub.freebsd.org (Postfix) with ESMTP id 5361337B422; Mon, 17 Dec 2001 18:49:00 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 17 Dec 2001 18:48:59 -0800 X-Originating-IP: [66.185.84.77] From: "jack xiao" To: , Subject: radiusclients questions Date: Mon, 17 Dec 2001 21:51:06 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0135_01C18744.EE5ECA40" 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: 18 Dec 2001 02:48:59.0445 (UTC) FILETIME=[8B308650:01C1876E] 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_0135_01C18744.EE5ECA40 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: base64 DQpIaSwNCiANCk5vdyBJIHdhbnQgdG8gdXNlIHJhZGl1c2NsaWVudCAoIHZlcnNpb24gMC4zLjEg KSB1bmRlciBGcmVlQlNEIHBvcnRzIGFuZCB1c2UgcmFkbG9naW4gdG8gc3Vic3RpdHV0ZSBub3Jt YWwgbG9naW4gZm9yIFBQUCBsb2dpbiB1c2VyLiBJIGhhdmUgcG9ydGVkIHJhZGl1c2NsaWVudCBh bmQgcmFkbG9naW4gd29ya3Mgd2VsbCwgYnV0IEkgZG9uJ3Qga25vdyBob3cgdG8gdXNlIHJhZGxv Z2luIGluc3RlYWQgb2YgbG9naW4uIEFueSBpZGVhcyB3aWxsIGJlIGFwcHJlY2lhdGVkLg0KIA0K VGhhbmtzIQ0KIA0KSmFjaw0KIA0K ------=_NextPart_000_0135_01C18744.EE5ECA40 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXdpbmRvd3MtMTI1MiI+DQo8TUVUQSBjb250ZW50PSJNU0hU TUwgNi4wMC4yNjAwLjAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+ DQo8Qk9EWT4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PC9GT05UPjxGT05UIGZhY2U9 QXJpYWwgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBz aXplPTI+SGksPEJSPiZuYnNwOzxCUj5Ob3cgSSB3YW50IHRvIHVzZSByYWRpdXNjbGllbnQgKCAN CnZlcnNpb24gMC4zLjEgKSB1bmRlciBGcmVlQlNEIHBvcnRzIGFuZCB1c2UgcmFkbG9naW4gdG8g c3Vic3RpdHV0ZSBub3JtYWwgbG9naW4gDQpmb3IgUFBQIGxvZ2luIHVzZXIuIEkgaGF2ZSBwb3J0 ZWQgcmFkaXVzY2xpZW50IGFuZCByYWRsb2dpbiB3b3JrcyB3ZWxsLCBidXQgSSANCmRvbid0IGtu b3cgaG93IHRvIHVzZSByYWRsb2dpbiBpbnN0ZWFkIG9mIGxvZ2luLiBBbnkgaWRlYXMgd2lsbCBi ZSANCmFwcHJlY2lhdGVkLjxCUj4mbmJzcDs8QlI+VGhhbmtzITxCUj4mbmJzcDs8QlI+SmFjazxC Uj48L0ZPTlQ+Jm5ic3A7PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_0135_01C18744.EE5ECA40-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Dec 17 20:43: 8 2001 Delivered-To: freebsd-net@freebsd.org Received: from hotmail.com (oe29.pav1.hotmail.com [64.4.30.86]) by hub.freebsd.org (Postfix) with ESMTP id 2C76737B419; Mon, 17 Dec 2001 20:43:02 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 17 Dec 2001 20:42:57 -0800 X-Originating-IP: [66.185.84.77] From: "jack xiao" To: , Subject: radius problem Date: Mon, 17 Dec 2001 23:45:03 -0500 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0013_01C18754.D937CD00" 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: 18 Dec 2001 04:42:57.0014 (UTC) FILETIME=[76B2C160:01C1877E] 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_0013_01C18754.D937CD00 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0014_01C18754.D937CD00" ------=_NextPart_001_0014_01C18754.D937CD00 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 DQo= ------=_NextPart_001_0014_01C18754.D937CD00 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC4yNjAwLjAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8Qk9E WSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPiZuYnNwOzwvRElWPjwvQk9EWT48L0hUTUw+DQo= ------=_NextPart_001_0014_01C18754.D937CD00-- ------=_NextPart_000_0013_01C18754.D937CD00 Content-Type: text/plain; name="radius problem.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="radius problem.txt" Hi, Now I want to use radiusclient ( version 0.3.1 ) under FreeBSD ports and use radlogin to substitute normal login for PPP login user. I have ported radiusclient and radlogin works well, but I don't know how to use radlogin instead of login. Any ideas will be appreciated. Thanks! Jack ------=_NextPart_000_0013_01C18754.D937CD00-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Dec 17 21:20:21 2001 Delivered-To: freebsd-net@freebsd.org Received: from web10102.mail.yahoo.com (web10102.mail.yahoo.com [216.136.130.52]) by hub.freebsd.org (Postfix) with SMTP id BB0FE37B405 for ; Mon, 17 Dec 2001 21:20:17 -0800 (PST) Message-ID: <20011218052017.16298.qmail@web10102.mail.yahoo.com> Received: from [194.225.40.6] by web10102.mail.yahoo.com via HTTP; Mon, 17 Dec 2001 21:20:17 PST Date: Mon, 17 Dec 2001 21:20:17 -0800 (PST) From: soheil hyeganeh Subject: i append the lib/libz/compress.c to sys/net/zlib.c and it takes an error To: 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 hi i want to use the compress(dst, dstsize, src, srcsize) and i append the lib/libz/compress.c to the sys/net/zlib.c and when i compile the kernel it takes an error for zlib.c a precompiling error for #ifndef _Z_UTIL_H line:45 and says that thereis no terminator for that i want to know why and how i can solve this problem thanx __________________________________________________ Do You Yahoo!? Check out Yahoo! Shopping and Yahoo! Auctions for all of your unique holiday gifts! Buy at http://shopping.yahoo.com or bid at http://auctions.yahoo.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 17 22:34:55 2001 Delivered-To: freebsd-net@freebsd.org Received: from citusc17.usc.edu (citusc17.usc.edu [128.125.38.177]) by hub.freebsd.org (Postfix) with ESMTP id A401037B426 for ; Mon, 17 Dec 2001 22:34:34 -0800 (PST) Received: (from kris@localhost) by citusc17.usc.edu (8.11.6/8.11.4) id fBI6YUO81122; Mon, 17 Dec 2001 22:34:30 -0800 (PST) (envelope-from kris) Date: Mon, 17 Dec 2001 22:34:30 -0800 From: Kris Kennaway To: soheil hyeganeh Cc: freebsd-net@FreeBSD.ORG Subject: Re: i append the lib/libz/compress.c to sys/net/zlib.c and it takes an error Message-ID: <20011217223430.A81108@citusc17.usc.edu> References: <20011218052017.16298.qmail@web10102.mail.yahoo.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="FL5UXtIhxfXey3p5" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011218052017.16298.qmail@web10102.mail.yahoo.com>; from soheil_has@yahoo.com on Mon, Dec 17, 2001 at 09:20:17PM -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 --FL5UXtIhxfXey3p5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Dec 17, 2001 at 09:20:17PM -0800, soheil hyeganeh wrote: > hi > i want to use the compress(dst, dstsize, src, srcsize) > and i append the lib/libz/compress.c to the > sys/net/zlib.c and when i compile the kernel > it takes an error for zlib.c > a precompiling error for #ifndef _Z_UTIL_H line:45 and > says that thereis no terminator for that=20 > i want to know why and how i can solve this problem Turn your changes into legitimate C code? Kris --FL5UXtIhxfXey3p5 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE8HuN1Wry0BWjoQKURAvuXAJwNhGGp6qz849o8mf/sEuTtTg/K8QCdEkC+ Xe/qJyGa/JFDSq2i8JMd+XU= =vd25 -----END PGP SIGNATURE----- --FL5UXtIhxfXey3p5-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Dec 18 1:15: 3 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 2BBC437B41B; Tue, 18 Dec 2001 01:14:49 -0800 (PST) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.6/8.11.2) id fBI9EQ135382; Tue, 18 Dec 2001 11:14:26 +0200 (EET) (envelope-from ru) Date: Tue, 18 Dec 2001 11:14:26 +0200 From: Ruslan Ermilov To: Boris Koster Cc: freebsd-questions@FreeBSD.ORG, freebsd-isp@freeBSD.FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: FreeBSD IPSEC mini-howto updated! Message-ID: <20011218111426.C30555@sunbay.com> References: <3C1B7FAE.31484.401E08@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C1B7FAE.31484.401E08@localhost> 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 Sat, Dec 15, 2001 at 04:51:58PM +0100, Boris K"oster wrote: > 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 > Now that you mention it. Why this document states that we need `gif' devices for IPSec to work? We're running VPN on IPSec without any gif(4) configured. The only ``magic'' used is to have routes on border nodes so that locally originated traffic has a proper source IP address. Thanks, -- 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 Tue Dec 18 2:14:30 2001 Delivered-To: freebsd-net@freebsd.org Received: from scribble.fsn.hu (scribble.fsn.hu [193.224.40.95]) by hub.freebsd.org (Postfix) with SMTP id 83BDE37B41D for ; Tue, 18 Dec 2001 02:14:27 -0800 (PST) Received: (qmail 4402 invoked by uid 1000); 18 Dec 2001 10:14:26 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 18 Dec 2001 10:14:26 -0000 Date: Tue, 18 Dec 2001 11:14:26 +0100 (CET) From: Attila Nagy To: net@freebsd.org Subject: FEC and VLAN trunking 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 Hello, I tried the FEC patch from http://people.freebsd.org/~wpaul/FEC/ on a 4-STABLE machine with two fxp cards connecting to a HP 4000M switch. The switch supports .1q tagging and FEC. I did the following: ifconfig fec0 up (the fec0 interface stands from fxp0 and fxp1) ifconfig vlan0 192.168.5.2 vlan 5 vlandev fec0 up Now I can't ping the machine 192.168.5.1 which is in the same VLAN (VLAN ID 5). If I do this without VLANs everything works correctly, so I can use fec0 as intended. tcpdump on fec0 (tcpdump -i fec0) shows that the machine gets the VLANs and tcpdump can identify each one with their ID. So on fec0 I get the correct traffic of several VLANs but I can not do anything besides that. If I ping 192.168.5.2 (the machine with FEC) from 192.168.5.1 I can see the ICMP echo requests coming in on the correct VLAN on fec0, but the machine does not respond to them. Is it possible to do VLAN trunking on a FEC interface? Thanks, -------------------------------------------------------------------------- Attila Nagy e-mail: Attila.Nagy@fsn.hu Budapest Polytechnic (BMF.HU) @work: +361 210 1415 (194) H-1084 Budapest, Tavaszmezo u. 15-17. cell.: +3630 306 6758 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Dec 18 4:48:27 2001 Delivered-To: freebsd-net@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 6FD5B37B41B; Tue, 18 Dec 2001 04:48:18 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id XAA28380; Tue, 18 Dec 2001 23:48:15 +1100 Date: Tue, 18 Dec 2001 23:49:31 +1100 (EST) From: Bruce Evans X-X-Sender: To: Alfred Perlstein Cc: , , , Subject: Re: fifo fix (Re: cvs commit: src/sys/fs/fifofs fifo_vnops.c) In-Reply-To: <20011217122953.G82439@elvis.mu.org> Message-ID: <20011218234521.F3927-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, 17 Dec 2001, Alfred Perlstein wrote: > * Bruce Evans [011217 07:10] wrote: > > > + > > > 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); > > > > I'm not happy with frobbing the socket state. I suggest frobbing the > > events mask instead. Either use a flag to tell sopoll() to ignore > > SS_CANTRCVMORE, or use new events POLLIN_IGNORE_EOF and > > POLLRDNORM_IGNORE_EOF (convert the userland POLLIN/POLLRDNORM to these > > and change sopoll() to support them). > > I'll consider that. > > There's actually a bug here, I need to make sure 'so' isn't NULL > before I do this, sticking the frobbing under the 'if (filetmp.f_data)' > should fix that. Putting it there is almost exactly right, except for the bogus casts back and forth. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Dec 18 5:18:32 2001 Delivered-To: freebsd-net@freebsd.org Received: from aragorn.ics.muni.cz (aragorn.ics.muni.cz [147.251.4.33]) by hub.freebsd.org (Postfix) with ESMTP id 947F237B41C; Tue, 18 Dec 2001 05:18:08 -0800 (PST) Received: from dior.ics.muni.cz (dior.ics.muni.cz [147.251.6.10]) by aragorn.ics.muni.cz (8.8.5/8.8.5) with ESMTP id OAA21064; Tue, 18 Dec 2001 14:18:07 +0100 (MET) Received: from kloboucek (root@localhost) (authenticated as hopet with LOGIN) by dior.ics.muni.cz (8.10.1/8.10.0.Beta12) with ESMTP id fBIDI6o23995; Tue, 18 Dec 2001 14:18:06 +0100 (MET) From: "Petr Holub" To: , , , Subject: tx driver Date: Tue, 18 Dec 2001 14:17:09 +0100 Message-ID: <003c01c187c6$4c323e00$d2e86cc2@kloboucek> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal 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 Hi all! I've encountered really awful behavior of my SMC card using tx driver in FreeBSD 4.3. On 100 Mbps network I get the throughput just about 200 kBps :-( Colleagues of mine running some PC based routers have very similar experiences with this driver (in both 4.3 and 4.4 Rel's) The same card running under the exactely same conditions in NetBSD is working pretty good (11 MBps) and in Windows 2000 (8 MBps). Also running other cards (like those with rl drivers) on the same network gives very reasonable results in FreeBSD (approx. 10.5 MBps) so I'm pretty convinced driver is to blame. Does anybody have some workaround for this? (If there is a need for me to send better diagnostics than it's no problem.) Best regards, Petr Holub ================================================================ Petr Holub CESNET z.s.p.o. Supercomputing Center Brno Zikova 2 Institute of Compt. Science 10200 Praha, CZ Masaryk University Czech Republic Botanicka 68a, 60200 Brno, CZ e-mail: Petr.Holub@cesnet.cz phone: +420-5-41512278 e-mail: hopet@ics.muni.cz To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Dec 18 7: 6:26 2001 Delivered-To: freebsd-net@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 4039D37B41F; Tue, 18 Dec 2001 07:06:02 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.6/8.11.5) with SMTP id fBIF5ui46714; Tue, 18 Dec 2001 10:05:56 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Tue, 18 Dec 2001 10:05:55 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org 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: <16162204675.20011214114735@rmp.ru> 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 Fri, 14 Dec 2001, Smirnov Konstantin wrote: > 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. And some of the things recommended are a bad idea, or already the default (and possibly both). :-) > ====================== 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 We need to make soft updates the default in -CURRENT; there was some disagreement on exactly the right mechanism, and what heuristic should be used to prevent application of SU to small root partitions. > Kernel modifications to make -- recompile and install the kernel afterwards: > MAXUSERS 512 This is no longer relevant: both -STABLE and -CURRENT will auto-tune the maxusers size by default based on available memory. For some environments, you may want to manually override to make the number bigger (or smaller). Many of the limits that used to be keyed to this are now tunable individually to much better effect, such as kern.maxfiles. tuning(7) is a much better guide right now due to being in sync with the system. > in /boot/load.conf > hw.ata.wc="1" In 4.4-RELEASE, the upcoming 4.5-RELEASE, and 4-STABLE in general, this is already the default. In 5.0, it is not the default, which is something we'll want to discuss more: we need to rely on safe drive behavior for background fsck. > kern.ipc.nmbclusters="60000" This is a patently bad idea on machines with <256Mb of memory, as each cluster represents about 2k of memory. In fact, tuning(7) specifically says not to do things like this: figure out how many you need. If you have a web server which maxes out at 1000 simultaneous connections, and each connection eats a 16K receive and 16K send buffer, you need approximate 32MB worth of network buffers to deal with it. A good rule of thumb is to multiply by 2, so 32MBx2 = 64MB/2K = 32768. So for this case you would want to set kern.ipc.nmbclusters to 32768. We recommend values between 1024 and 4096 for machines with moderates amount of memory, and between 4096 and 32768 for machines with greater amounts of memory. Under no circumstances should you specify an arbitrarily high value for this parameter, it could lead to a boot-time crash. The -m option to netstat(1) may be used to observe network cluster use. Older versions of FreeBSD do not have this tunable and require that the kernel config(8) option NMBCLUSTERS be set instead. > in /etc/fstab > > Add to options for all hard disk file systems ",async": This is a very bad idea, as it will dramatically increase the possibility of serious system failure in the event of a crash or unexpected power loss. Not only that, but SU probably makes this irrelevent. > In /etc/sysctl.conf > vfs.vmiodirenable=1 This is now the default. > kern.ipc.maxsockbuf=2097152 > kern.ipc.somaxconn=8192 > kern.ipc.maxsockets=16424 These may result in resource exhaustion, and should be carefully balanced based on your machine's capacity and the desired load. > kern.maxfiles=65536 This may be a bad idea. I'm not sure what the person is tuning for, but these are generally pretty bad tuning instructions. They must have a ton of memory, or this system wouldn't even boot. > kern.maxfilesperproc=32768 > net.inet.tcp.rfc1323=1 Already the default. > net.inet.tcp.delayed_ack=0 The bug that required this will be fixed in 4.5-RELEASE. > net.inet.tcp.sendspace=65535 This may be a reasonable change in some environments, but I'm beginning to suspect that if these limits were all reached, even a maxed out i386 box couldn't provide enough memory to support them. > net.inet.tcp.recvspace=65535 Already the default. > net.inet.udp.recvspace=65535 I'm not sure this is a performance optimization. In fact, this may pessimize behavior in most network environments :-). > net.inet.udp.maxdgram=57344 > net.local.stream.recvspace=65535 > net.local.stream.sendspace=65535 This may be useful in some environments, but also may not: what application do they have in mind? > What is your opinion? Is that parameters suitable for ALL systems? (I > think, no ;))) Maybe, somebody tried it yet? Many of these suggestions, if implemented, would result in substantial loss of system reliability and resilience to failure. In many cases, the default specified here would not even boot on most machines out there due to basic memory requirements. At least one fundamental concern is that some defaults here may pessimize performence for common applications: tuning of the system depends on the application, and as such choosing "big numbers" as a default is likely to hurt you far more than help. In 4.5-RELEASE, we've made an effort to substantially improve the default system tuning. About the only thing that hasn't been done for 4.5-RELEASE is to enable the softupdates on file systems by default: this is not something we should introduce prior to the release, due to its proximity. It's something that would be a reasonable default for 5.0-RELEASE. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Dec 18 9:15:50 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 53CA937B405; Tue, 18 Dec 2001 09:15:37 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id C47B481E0F; Tue, 18 Dec 2001 11:15:31 -0600 (CST) Date: Tue, 18 Dec 2001 11:15:31 -0600 From: Alfred Perlstein To: Bruce Evans Cc: wollman@FreeBSD.org, net@FreeBSD.org, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: fifo fix (Re: cvs commit: src/sys/fs/fifofs fifo_vnops.c) Message-ID: <20011218111531.A59831@elvis.mu.org> References: <20011215151025.A82439@elvis.mu.org> <20011217230720.N13599-100000@gamplex.bde.org> <20011217122953.G82439@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: <20011217122953.G82439@elvis.mu.org>; from alfred@FreeBSD.org on Mon, Dec 17, 2001 at 12:29:53PM -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 [011217 12:47] wrote: > * Bruce Evans [011217 07:10] wrote: > > > > + > > > 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); > > > > I'm not happy with frobbing the socket state. I suggest frobbing the > > events mask instead. Either use a flag to tell sopoll() to ignore > > SS_CANTRCVMORE, or use new events POLLIN_IGNORE_EOF and > > POLLRDNORM_IGNORE_EOF (convert the userland POLLIN/POLLRDNORM to these > > and change sopoll() to support them). Wait, please clarify, are you suggesting that POLLIN_IGNORE_EOF and POLLRDNORM_IGNORE_EOF must be used by userland applications? Or would it be an internal flag for the kernel so that here you'd see something like: filetmp.f_data = (caddr_t)ap->a_vp->v_fifoinfo->fi_readsock; if (filetmp.f_data) { if (ap->a_events & ~POLLIN) ap->a_events |= POLLIN_IGNORE_EOF; /* same for POLLRDNORM */ revents |= soo_poll(&filetmp, ap->a_events, ap->a_cred, ap->a_td); } Or that the userland will just OR in POLLIN_IGNORE_EOF before calling poll(2). I'm not sure if I like the latter way of fixing things. thanks, -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Dec 18 11:12:54 2001 Delivered-To: freebsd-net@freebsd.org Received: from ns1.cksoft.de (ns1.cksoft.de [62.111.66.1]) by hub.freebsd.org (Postfix) with ESMTP id 2AB8537B419; Tue, 18 Dec 2001 11:12:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by ns1.cksoft.de (Postfix) with ESMTP id 59D2314FA3; Tue, 18 Dec 2001 20:12:41 +0100 (CET) Received: by ns1.cksoft.de (Postfix, from userid 66) id 0D6A314FA2; Tue, 18 Dec 2001 20:12:39 +0100 (CET) Received: by hirvi.cksoft.de (Postfix, from userid 1000) id ABF481B653; Tue, 18 Dec 2001 22:09:31 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by hirvi.cksoft.de (Postfix) with ESMTP id AB0DA18E88; Tue, 18 Dec 2001 22:09:31 +0100 (CET) Date: Tue, 18 Dec 2001 22:09:31 +0100 (CET) From: Christian Kratzer To: Petr Holub Cc: , , , Subject: Re: tx driver In-Reply-To: <003c01c187c6$4c323e00$d2e86cc2@kloboucek> Message-ID: X-Spammer-Kill-Ratio: 75% MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS perl-11 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, On Tue, 18 Dec 2001, Petr Holub wrote: > Hi all! > > I've encountered really awful behavior of my SMC card using > tx driver in FreeBSD 4.3. On 100 Mbps network I get the throughput > just about 200 kBps :-( Colleagues of mine running some PC > based routers have very similar experiences with this driver > (in both 4.3 and 4.4 Rel's) The same card running under the > exactely same conditions in NetBSD is working pretty good > (11 MBps) and in Windows 2000 (8 MBps). Also running other cards > (like those with rl drivers) on the same network gives > very reasonable results in FreeBSD (approx. 10.5 MBps) so > I'm pretty convinced driver is to blame. Does anybody have > some workaround for this? the usual problem with this kind of performance with any driver is failed full/half duplex negotiation. Please try manually forcing your card to half or full duplex Add one of -mediaopt full-duplex or -mediaopt half-duplex depending on the setting of your switch to your ifconfig line in /etc/rc.conf This is the single most common cause of really low ethernet performance. I have had good experiences with the tx driver on 4.3 ond 4.4 releases. Greetings Christian -- CK Software GmbH Christian Kratzer, Schwarzwaldstr. 31, 71131 Jettingen Email: ck@cksoft.de Phone: +49 7452 889-135 Open Software Solutions, Network Security Fax: +49 7452 889-136 FreeBSD spoken here! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Dec 18 11:28:29 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 3831237B405 for ; Tue, 18 Dec 2001 11:28:23 -0800 (PST) Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.11.0/8.11.0) id fBIJM5s05089; Tue, 18 Dec 2001 11:22:05 -0800 Date: Tue, 18 Dec 2001 11:22:04 -0800 From: Brooks Davis To: Attila Nagy Cc: net@FreeBSD.ORG Subject: Re: FEC and VLAN trunking Message-ID: <20011218112204.A21166@Odin.AC.HMC.Edu> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="qDbXVdCdHGoSgWSk" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from bra@fsn.hu on Tue, Dec 18, 2001 at 11:14:26AM +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 --qDbXVdCdHGoSgWSk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Dec 18, 2001 at 11:14:26AM +0100, Attila Nagy wrote: > Hello, >=20 > I tried the FEC patch from http://people.freebsd.org/~wpaul/FEC/ on a > 4-STABLE machine with two fxp cards connecting to a HP 4000M switch. > The switch supports .1q tagging and FEC. >=20 > I did the following: >=20 > ifconfig fec0 up (the fec0 interface stands from fxp0 and fxp1) > ifconfig vlan0 192.168.5.2 vlan 5 vlandev fec0 up >=20 > Now I can't ping the machine 192.168.5.1 which is in the same VLAN (VLAN > ID 5). If I do this without VLANs everything works correctly, so I can use > fec0 as intended. >=20 > tcpdump on fec0 (tcpdump -i fec0) shows that the machine gets the VLANs > and tcpdump can identify each one with their ID. So on fec0 I get the > correct traffic of several VLANs but I can not do anything besides that. >=20 > If I ping 192.168.5.2 (the machine with FEC) from 192.168.5.1 I can see > the ICMP echo requests coming in on the correct VLAN on fec0, but the > machine does not respond to them. >=20 > Is it possible to do VLAN trunking on a FEC interface? I was expecting to find that it didn't work, but I downloaded the code and I can't see any reason why it shouldn't work at this point. I'm not 100% sure I read the code right but it looks like it should work (at least if your interface doesn't support hardware vlan decapsulation, which is the case with fxp). What happens if you put a bpf tap on vlan0? I'll put this on my todo list, but I'm not sure when I'll get to it. I will need this working at some point, but initialy I'll be able to work around it so I don't know when I'll get to it. -- 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 --qDbXVdCdHGoSgWSk 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 iD8DBQE8H5dcXY6L6fI4GtQRAkZ2AJ9kZ+imt3KSM/PcKf2FJTqUQCYUhgCfWgjO P31/xGis0PuXbrB5ssDwpuw= =VF// -----END PGP SIGNATURE----- --qDbXVdCdHGoSgWSk-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Dec 18 12: 3:39 2001 Delivered-To: freebsd-net@freebsd.org Received: from m3.bezeqint.net (m3.bezeqint.net [192.115.106.4]) by hub.freebsd.org (Postfix) with ESMTP id 4056637B417; Tue, 18 Dec 2001 12:03:32 -0800 (PST) Received: from bsd.net.il (bzq-148-20.pop.bezeqint.net [212.179.148.20]) by m3.bezeqint.net (Mirapoint) with ESMTP id ADO02059; Tue, 18 Dec 2001 22:03:27 +0200 (IST) Received: (from nimrodm@localhost) by bsd.net.il (8.11.6/8.11.6) id fBIK47j52006; Tue, 18 Dec 2001 22:04:07 +0200 (IST) (envelope-from nimrodm) From: Nimrod Mesika Date: Tue, 18 Dec 2001 22:04:06 +0200 To: freebsd-questions@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: FreeBSD IPSEC mini-howto updated! Message-ID: <20011218220406.A51872@localhost.bsd.net.il> Reply-To: nimrodm@email.com Mail-Followup-To: freebsd-questions@FreeBSD.ORG, freebsd-net@FreeBSD.ORG References: <3C1B7FAE.31484.401E08@localhost> <20011218111426.C30555@sunbay.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011218111426.C30555@sunbay.com>; from ru@FreeBSD.ORG on Tue, Dec 18, 2001 at 11:14:26AM +0200 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 18, 2001 at 11:14:26AM +0200, Ruslan Ermilov wrote: > > http://www.x-itec.de/projects/tuts/ipsec-howto.txt > > FreeBSD ipsec mini-howto > > > Now that you mention it. > > Why this document states that we need `gif' devices > for IPSec to work? We're running VPN on IPSec without > any gif(4) configured. The only ``magic'' used is to > have routes on border nodes so that locally originated > traffic has a proper source IP address. Just curious: Do you have any Windows 2000 machines on this VPN (working as gateways or standalone clients connecting using IPSec)? -- Nimrod. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 19 7:19:38 2001 Delivered-To: freebsd-net@freebsd.org Received: from comp.chem.msu.su (comp-xl.chem.msu.su [158.250.32.157]) by hub.freebsd.org (Postfix) with ESMTP id BC36737B416; Wed, 19 Dec 2001 07:19:31 -0800 (PST) Received: (from yar@localhost) by comp.chem.msu.su (8.11.1/8.11.1) id fBJFJTv21729; Wed, 19 Dec 2001 18:19:29 +0300 (MSK) (envelope-from yar) Date: Wed, 19 Dec 2001 18:19:29 +0300 From: Yar Tikhiy To: net@freebsd.org, hackers@freebsd.org Subject: Processing IP options reveals IPSTEALH router Message-ID: <20011219181929.A20425@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 Hi there, I ran into an absolutely clear, but year-old PR pointing out that a router in the IPSTEALTH mode will reveal itself when processing IP options: kern/23123. The fix proposed seems clean and right to me: don't do IP options at all when in the IPSTEALTH mode. Does anyone have objections? If no, I'll commit the fix. -- Yar To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 19 7:29:31 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 799C137B41B for ; Wed, 19 Dec 2001 07:29:26 -0800 (PST) Received: (qmail 39841 invoked by uid 3193); 19 Dec 2001 15:29:25 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 19 Dec 2001 15:29:25 -0000 Date: Wed, 19 Dec 2001 10:29:25 -0500 (EST) From: Mike Silbersack X-Sender: To: Yar Tikhiy Cc: , Subject: Re: Processing IP options reveals IPSTEALH router In-Reply-To: <20011219181929.A20425@comp.chem.msu.su> 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, 19 Dec 2001, Yar Tikhiy wrote: > Hi there, > > I ran into an absolutely clear, but year-old PR pointing out that > a router in the IPSTEALTH mode will reveal itself when processing > IP options: kern/23123. > > The fix proposed seems clean and right to me: don't do IP options > at all when in the IPSTEALTH mode. Does anyone have objections? > If no, I'll commit the fix. > > -- > Yar The fix looks good on the surface, but it probably should be tested before committing just to make sure. 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 Wed Dec 19 7:33:49 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 200F037B416; Wed, 19 Dec 2001 07:33:25 -0800 (PST) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.6/8.11.2) id fBJFXDd60549; Wed, 19 Dec 2001 17:33:13 +0200 (EET) (envelope-from ru) Date: Wed, 19 Dec 2001 17:33:13 +0200 From: Ruslan Ermilov To: Yar Tikhiy Cc: net@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: Processing IP options reveals IPSTEALH router Message-ID: <20011219173313.C54315@sunbay.com> References: <20011219181929.A20425@comp.chem.msu.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011219181929.A20425@comp.chem.msu.su> 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 Wed, Dec 19, 2001 at 06:19:29PM +0300, Yar Tikhiy wrote: > Hi there, > > I ran into an absolutely clear, but year-old PR pointing out that > a router in the IPSTEALTH mode will reveal itself when processing > IP options: kern/23123. > > The fix proposed seems clean and right to me: don't do IP options > at all when in the IPSTEALTH mode. Does anyone have objections? > If no, I'll commit the fix. > What if the packet is directed to us? I think we should still process options in this case, and the patch in the PR doesn't seem to do it. I was going to replace IPSTEALTH functionality with the net.inet.ip.decttl knob. Setting it to 0 would match the IPSTEALTH behavior, the default value will be 1. 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 Wed Dec 19 8:24: 1 2001 Delivered-To: freebsd-net@freebsd.org Received: from relay1.macomnet.ru (relay1.macomnet.ru [195.128.64.10]) by hub.freebsd.org (Postfix) with ESMTP id F404337B405; Wed, 19 Dec 2001 08:23:56 -0800 (PST) Received: from news1.macomnet.ru (maxim@news1.macomnet.ru [195.128.64.14]) by relay1.macomnet.ru (8.11.3/8.11.3) with ESMTP id fBJGNtY2684655; Wed, 19 Dec 2001 19:23:55 +0300 (MSK) Date: Wed, 19 Dec 2001 19:23:55 +0300 (MSK) From: Maxim Konovalov To: Yar Tikhiy Cc: net@FreeBSD.ORG, Subject: Re: Processing IP options reveals IPSTEALH router In-Reply-To: <20011219181929.A20425@comp.chem.msu.su> Message-ID: <20011219190533.W57795-100000@news1.macomnet.ru> 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 Hello Yar, On 18:19+0300, Dec 19, 2001, Yar Tikhiy wrote: > Hi there, > > I ran into an absolutely clear, but year-old PR pointing out that > a router in the IPSTEALTH mode will reveal itself when processing > IP options: kern/23123. > > The fix proposed seems clean and right to me: don't do IP options > at all when in the IPSTEALTH mode. Does anyone have objections? > If no, I'll commit the fix. > First of all we should decide what IPSTEALTH is for. Is it just a Ruslan's net.inet.ip.decttl or it should really stealth the fact of the routing? If the latter how do we behave in source routing case? -- Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer phone: +7 (095) 796-9079, mailto: maxim@macomnet.ru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 19 8:45: 2 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 9840F37B41A; Wed, 19 Dec 2001 08:44:48 -0800 (PST) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.6/8.11.2) id fBJGi5t70042; Wed, 19 Dec 2001 18:44:05 +0200 (EET) (envelope-from ru) Date: Wed, 19 Dec 2001 18:44:05 +0200 From: Ruslan Ermilov To: Maxim Konovalov Cc: Yar Tikhiy , net@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: Processing IP options reveals IPSTEALH router Message-ID: <20011219184405.A69668@sunbay.com> References: <20011219181929.A20425@comp.chem.msu.su> <20011219190533.W57795-100000@news1.macomnet.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011219190533.W57795-100000@news1.macomnet.ru> 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 Wed, Dec 19, 2001 at 07:23:55PM +0300, Maxim Konovalov wrote: > > Hello Yar, > > On 18:19+0300, Dec 19, 2001, Yar Tikhiy wrote: > > > Hi there, > > > > I ran into an absolutely clear, but year-old PR pointing out that > > a router in the IPSTEALTH mode will reveal itself when processing > > IP options: kern/23123. > > > > The fix proposed seems clean and right to me: don't do IP options > > at all when in the IPSTEALTH mode. Does anyone have objections? > > If no, I'll commit the fix. > > > > First of all we should decide what IPSTEALTH is for. Is it just a > Ruslan's net.inet.ip.decttl or it should really stealth the fact of > the routing? If the latter how do we behave in source routing case? > Do you have net.inet.ip.accept_sourceroute=1 on one of your publicly accessible routers? If so, could you please tell me its IP address? :-) 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 Wed Dec 19 8:49:28 2001 Delivered-To: freebsd-net@freebsd.org Received: from comp.chem.msu.su (comp-xl.chem.msu.su [158.250.32.157]) by hub.freebsd.org (Postfix) with ESMTP id A30D637B405; Wed, 19 Dec 2001 08:49:19 -0800 (PST) Received: (from yar@localhost) by comp.chem.msu.su (8.11.1/8.11.1) id fBJGn3l31461; Wed, 19 Dec 2001 19:49:03 +0300 (MSK) (envelope-from yar) Date: Wed, 19 Dec 2001 19:49:03 +0300 From: Yar Tikhiy To: Maxim Konovalov Cc: net@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: Processing IP options reveals IPSTEALH router Message-ID: <20011219194903.D21732@comp.chem.msu.su> References: <20011219181929.A20425@comp.chem.msu.su> <20011219190533.W57795-100000@news1.macomnet.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011219190533.W57795-100000@news1.macomnet.ru>; from maxim@macomnet.ru on Wed, Dec 19, 2001 at 07:23:55PM +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 Wed, Dec 19, 2001 at 07:23:55PM +0300, Maxim Konovalov wrote: > > > I ran into an absolutely clear, but year-old PR pointing out that > > a router in the IPSTEALTH mode will reveal itself when processing > > IP options: kern/23123. > > > > The fix proposed seems clean and right to me: don't do IP options > > at all when in the IPSTEALTH mode. Does anyone have objections? > > If no, I'll commit the fix. > > First of all we should decide what IPSTEALTH is for. Is it just a > Ruslan's net.inet.ip.decttl or it should really stealth the fact of > the routing? If the latter how do we behave in source routing case? Are there any reasons for a router not to decrement IP TTL besides trying to stay invisible to a third party? As for source routing, I believe a stealthy router should just drop such packets as though it were a host. Of course, source-routed packets destined for the router itself should be accepted. -- Yar To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 19 8:51: 4 2001 Delivered-To: freebsd-net@freebsd.org Received: from comp.chem.msu.su (comp-xl.chem.msu.su [158.250.32.157]) by hub.freebsd.org (Postfix) with ESMTP id 0078337B417; Wed, 19 Dec 2001 08:50:51 -0800 (PST) Received: (from yar@localhost) by comp.chem.msu.su (8.11.1/8.11.1) id fBJGomF32005; Wed, 19 Dec 2001 19:50:48 +0300 (MSK) (envelope-from yar) Date: Wed, 19 Dec 2001 19:50:48 +0300 From: Yar Tikhiy To: Ruslan Ermilov Cc: net@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: Processing IP options reveals IPSTEALH router Message-ID: <20011219195047.E21732@comp.chem.msu.su> References: <20011219181929.A20425@comp.chem.msu.su> <20011219173313.C54315@sunbay.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011219173313.C54315@sunbay.com>; from ru@FreeBSD.ORG on Wed, Dec 19, 2001 at 05:33:13PM +0200 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, Dec 19, 2001 at 05:33:13PM +0200, Ruslan Ermilov wrote: > On Wed, Dec 19, 2001 at 06:19:29PM +0300, Yar Tikhiy wrote: > > > > I ran into an absolutely clear, but year-old PR pointing out that > > a router in the IPSTEALTH mode will reveal itself when processing > > IP options: kern/23123. > > > > The fix proposed seems clean and right to me: don't do IP options > > at all when in the IPSTEALTH mode. Does anyone have objections? > > If no, I'll commit the fix. > > > What if the packet is directed to us? I think we should still > process options in this case, and the patch in the PR doesn't > seem to do it. Good point! Indeed, just ignoring IP options would let a third party to identify a FreeBSD host as a stealthy router. I think it's safe to move doing IP options to after identifying an IP packet as destined for this or another host. I'll make a patch and show it here. > > I was going to replace IPSTEALTH functionality with the > net.inet.ip.decttl knob. Setting it to 0 would match the > IPSTEALTH behavior, the default value will be 1. > In fact, IPSTEALTH does already have a sysctl knob: net.inet.ip.stealth, which is initially zero (i.e. don't be stealthy.) To my mind, the "stealth" name fits its purpose better since just leaving TTL untouched is insufficient for a router to achieve really stealthy behaviour. -- Yar To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 19 9:55: 6 2001 Delivered-To: freebsd-net@freebsd.org Received: from relay1.macomnet.ru (relay1.macomnet.ru [195.128.64.10]) by hub.freebsd.org (Postfix) with ESMTP id 91DFD37B41A; Wed, 19 Dec 2001 09:54:52 -0800 (PST) Received: from news1.macomnet.ru (maxim@news1.macomnet.ru [195.128.64.14]) by relay1.macomnet.ru (8.11.3/8.11.3) with ESMTP id fBJHsoY2860671; Wed, 19 Dec 2001 20:54:50 +0300 (MSK) Date: Wed, 19 Dec 2001 20:54:50 +0300 (MSK) From: Maxim Konovalov To: Yar Tikhiy Cc: net@FreeBSD.ORG, Subject: Re: Processing IP options reveals IPSTEALH router In-Reply-To: <20011219194903.D21732@comp.chem.msu.su> Message-ID: <20011219195659.G25693-100000@news1.macomnet.ru> 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 19:49+0300, Dec 19, 2001, Yar Tikhiy wrote: > On Wed, Dec 19, 2001 at 07:23:55PM +0300, Maxim Konovalov wrote: > > > > > I ran into an absolutely clear, but year-old PR pointing out that > > > a router in the IPSTEALTH mode will reveal itself when processing > > > IP options: kern/23123. > > > > > > The fix proposed seems clean and right to me: don't do IP options > > > at all when in the IPSTEALTH mode. Does anyone have objections? > > > If no, I'll commit the fix. > > > > First of all we should decide what IPSTEALTH is for. Is it just a > > Ruslan's net.inet.ip.decttl or it should really stealth the fact of > > the routing? If the latter how do we behave in source routing case? > > Are there any reasons for a router not to decrement IP TTL besides > trying to stay invisible to a third party? imho there are not. I've asked because ru's net.inet.ip.decttl means "do not decrement TTL" but not "hide the fact of the routing". > As for source routing, I believe a stealthy router should just drop > such packets as though it were a host. Of course, source-routed > packets destined for the router itself should be accepted. So there are three IPSTEALTH cases: 1/ the dst address is not ours, net.inet.ip.sourceroute=0, net.inet.ip.forwarding=1: process ip options by ip_dooptions(). 2/ the dst address is ours: process ip options by ip_dooptions(), 3/ in other cases do not process ip options. By the way, is it correct to forward the packet with incorrect ip options? Now we do not. -- Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer phone: +7 (095) 796-9079, mailto: maxim@macomnet.ru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 19 9:58: 6 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 7436E37B419; Wed, 19 Dec 2001 09:57:47 -0800 (PST) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.6/8.11.2) id fBJHvK880565; Wed, 19 Dec 2001 19:57:20 +0200 (EET) (envelope-from ru) Date: Wed, 19 Dec 2001 19:57:20 +0200 From: Ruslan Ermilov To: Maxim Konovalov Cc: Yar Tikhiy , net@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: Processing IP options reveals IPSTEALH router Message-ID: <20011219195720.B72222@sunbay.com> References: <20011219194903.D21732@comp.chem.msu.su> <20011219195659.G25693-100000@news1.macomnet.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011219195659.G25693-100000@news1.macomnet.ru> 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 Wed, Dec 19, 2001 at 08:54:50PM +0300, Maxim Konovalov wrote: > On 19:49+0300, Dec 19, 2001, Yar Tikhiy wrote: > > > On Wed, Dec 19, 2001 at 07:23:55PM +0300, Maxim Konovalov wrote: > > > > > > > I ran into an absolutely clear, but year-old PR pointing out that > > > > a router in the IPSTEALTH mode will reveal itself when processing > > > > IP options: kern/23123. > > > > > > > > The fix proposed seems clean and right to me: don't do IP options > > > > at all when in the IPSTEALTH mode. Does anyone have objections? > > > > If no, I'll commit the fix. > > > > > > First of all we should decide what IPSTEALTH is for. Is it just a > > > Ruslan's net.inet.ip.decttl or it should really stealth the fact of > > > the routing? If the latter how do we behave in source routing case? > > > > Are there any reasons for a router not to decrement IP TTL besides > > trying to stay invisible to a third party? > > imho there are not. I've asked because ru's net.inet.ip.decttl means > "do not decrement TTL" but not "hide the fact of the routing". > Nope, my net.inet.ip.decttl is the decrementor, it may be 1 (by default), 0 (to hide this router), or 2, 3, etc. 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 Wed Dec 19 10:21:54 2001 Delivered-To: freebsd-net@freebsd.org Received: from tao.org.uk (genius.tao.org.uk [212.135.162.51]) by hub.freebsd.org (Postfix) with ESMTP id 6F0C237B416; Wed, 19 Dec 2001 10:21:49 -0800 (PST) Received: by tao.org.uk (Postfix, from userid 100) id BE4A4F; Wed, 19 Dec 2001 18:21:39 +0000 (GMT) Date: Wed, 19 Dec 2001 18:21:39 +0000 From: Josef Karthauser To: ru@freebsd.org Cc: Yusuf Goolamabbas , freebsd-net@freebsd.org Subject: Re: Is there a way to clear stats from netstat -i Message-ID: <20011219182139.A9340@tao.org.uk> References: <20011211123504.A5909@outblaze.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="nFreZHaLTZJo0R7j" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011211123504.A5909@outblaze.com>; from yusufg@outblaze.com on Tue, Dec 11, 2001 at 12:35:04PM +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 --nFreZHaLTZJo0R7j Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Ruslan, You've been near this code recently. Do you have any suggestions for how this may work? Joe On Tue, Dec 11, 2001 at 12:35:04PM +0800, Yusuf Goolamabbas wrote: > 4.4-stable box >=20 > 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 >=20 > Is there a way to clear those flags >=20 > 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 >=20 > Regards, Yusuf > --=20 > Yusuf Goolamabbas > yusufg@outblaze.com >=20 >=20 > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message --nFreZHaLTZJo0R7j Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iEUEARECAAYFAjwg2rEACgkQXVIcjOaxUBaSUACY97S720emQzNGSMjg0SqhnzQB MQCdEdPqqBEI7Dbq2FXdGd3z6I+CeNs= =M3l4 -----END PGP SIGNATURE----- --nFreZHaLTZJo0R7j-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 19 11: 3:33 2001 Delivered-To: freebsd-net@freebsd.org Received: from hotmail.com (f196.pav2.hotmail.com [64.4.37.196]) by hub.freebsd.org (Postfix) with ESMTP id 27C1637B416 for ; Wed, 19 Dec 2001 11:03:31 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 19 Dec 2001 11:03:27 -0800 Received: from 209.167.77.135 by pv2fd.pav2.hotmail.msn.com with HTTP; Wed, 19 Dec 2001 19:03:26 GMT X-Originating-IP: [209.167.77.135] From: "Graham Dunn" To: freebsd-net@freebsd.org Subject: Bridging vlan0 with de0 Date: Wed, 19 Dec 2001 19:03:26 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 19 Dec 2001 19:03:27.0071 (UTC) FILETIME=[D705FEF0:01C188BF] 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 sent this to -questions, and the response was "no, you can't bridge a vlan interface." So I guess the question is now, how can I improve the design? The situation: Lan extension, vlan1 (10.5.0.0/16) and external IP block, vlan0 (x.x.x.x/27) arrive over a 802.1q interface (fxp0). I need to connect to two other subnets, 10.0.0.0/24 (our internal space), and our DMZ (x.x.x.x/27). At present, I have de0 and de1 as interfaces to our internal IP space (10.0.0.0/24) and the DMZ, respectively. However, this presents a problem (I think), in that I now have two interfaces onto the DMZ subnet: vlan0 and de1. (10.5.0.1) vlan1 |------| de0 (10.0.0.0/24) =======| |--------- vlan0 |______| (x.x.x.193) | | | de1 (x.x.x.194) Thanks, Graham _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 19 12: 0:19 2001 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id 6CA4D37B416 for ; Wed, 19 Dec 2001 12:00:15 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20011219200015.WBGH19716.rwcrmhc51.attbi.com@InterJet.elischer.org>; Wed, 19 Dec 2001 20:00:15 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA46600; Wed, 19 Dec 2001 11:50:04 -0800 (PST) Date: Wed, 19 Dec 2001 11:50:03 -0800 (PST) From: Julian Elischer To: Graham Dunn Cc: freebsd-net@freebsd.org Subject: Re: Bridging vlan0 with de0 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 I believe you can bridge a vlan interface if you use the new upcoming netgraph vlan node. It shuold be committed soon. (Vlans done the way it should have been done ;-) Julian On Wed, 19 Dec 2001, Graham Dunn wrote: > I sent this to -questions, and the response was "no, you can't bridge a vlan > interface." > > So I guess the question is now, how can I improve the design? > The situation: > > Lan extension, vlan1 (10.5.0.0/16) and external IP block, vlan0 > (x.x.x.x/27) arrive over a 802.1q interface (fxp0). I need to connect to > two other subnets, 10.0.0.0/24 (our internal space), and our DMZ > (x.x.x.x/27). > > At present, I have de0 and de1 as interfaces to our internal IP space > (10.0.0.0/24) and the DMZ, respectively. > > However, this presents a problem (I think), in that I now have two > interfaces onto the DMZ subnet: vlan0 and de1. > > (10.5.0.1) > vlan1 |------| de0 (10.0.0.0/24) > =======| |--------- > vlan0 |______| > (x.x.x.193) | > | > | de1 (x.x.x.194) > > Thanks, > > Graham > > _________________________________________________________________ > MSN Photos is the easiest way to share and print your photos: > http://photos.msn.com/support/worldwide.aspx > > > 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 19 13:32:54 2001 Delivered-To: freebsd-net@freebsd.org Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by hub.freebsd.org (Postfix) with ESMTP id AB4C037B419; Wed, 19 Dec 2001 13:32:48 -0800 (PST) Received: (from wkb@localhost) by freebie.xs4all.nl (8.11.6/8.11.6) id fBJLWgI04937; Wed, 19 Dec 2001 22:32:42 +0100 (CET) (envelope-from wkb) Date: Wed, 19 Dec 2001 22:32:42 +0100 From: Wilko Bulte To: Maxim Konovalov Cc: Yar Tikhiy , net@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: Processing IP options reveals IPSTEALH router Message-ID: <20011219223242.B4906@freebie.xs4all.nl> References: <20011219181929.A20425@comp.chem.msu.su> <20011219190533.W57795-100000@news1.macomnet.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011219190533.W57795-100000@news1.macomnet.ru>; from maxim@macomnet.ru on Wed, Dec 19, 2001 at 07:23:55PM +0300 X-OS: FreeBSD 4.4-STABLE X-PGP: finger wilko@freebsd.org Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, Dec 19, 2001 at 07:23:55PM +0300, Maxim Konovalov wrote: > > Hello Yar, > > On 18:19+0300, Dec 19, 2001, Yar Tikhiy wrote: > > > Hi there, > > > > I ran into an absolutely clear, but year-old PR pointing out that > > a router in the IPSTEALTH mode will reveal itself when processing > > IP options: kern/23123. > > > > The fix proposed seems clean and right to me: don't do IP options > > at all when in the IPSTEALTH mode. Does anyone have objections? > > If no, I'll commit the fix. > > > > First of all we should decide what IPSTEALTH is for. Is it just a > Ruslan's net.inet.ip.decttl or it should really stealth the fact of > the routing? If the latter how do we behave in source routing case? I would assume IPSTEALTH is thought to be for firewalls. Allowing source routing thru firewalls is a Bad Thing(TM) anyway, right? -- | / o / /_ _ email: wilko@FreeBSD.org |/|/ / / /( (_) Bulte Arnhem, The Netherlands To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 19 13:36: 7 2001 Delivered-To: freebsd-net@freebsd.org Received: from comp.chem.msu.su (comp-xl.chem.msu.su [158.250.32.157]) by hub.freebsd.org (Postfix) with ESMTP id 228AC37B419; Wed, 19 Dec 2001 13:35:59 -0800 (PST) Received: (from yar@localhost) by comp.chem.msu.su (8.11.1/8.11.1) id fBJLZuB62560; Thu, 20 Dec 2001 00:35:56 +0300 (MSK) (envelope-from yar) Date: Thu, 20 Dec 2001 00:35:55 +0300 From: Yar Tikhiy To: Maxim Konovalov Cc: net@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: IP options (was: Processing IP options reveals IPSTEALH router) Message-ID: <20011220003555.A52848@comp.chem.msu.su> References: <20011219194903.D21732@comp.chem.msu.su> <20011219195659.G25693-100000@news1.macomnet.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011219195659.G25693-100000@news1.macomnet.ru>; from maxim@macomnet.ru on Wed, Dec 19, 2001 at 08:54:50PM +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 Wed, Dec 19, 2001 at 08:54:50PM +0300, Maxim Konovalov wrote: > > By the way, is it correct to forward the packet with incorrect ip > options? Now we do not. No RFC seems to specify that particularly. However, RFC 1812 reads in general: (1) A router MUST verify the IP header, as described in section [5.2.2], before performing any actions based on the contents of the header. This allows the router to detect and discard bad packets before the expenditure of other resources. Meanwhile more IP option issues came to my attention... Neither RFC 791 nor RFC 1122 nor RFC 1812 specify the following: if a source-routed IP packet reachs the end of its route, but its destination address doesn't match a current host/router, whether the packet should be discarded, sent forth through usual routing or accepted as destined for this host? FreeBSD will route such a packet as usual. Then, a FreeBSD host (net.inet.ip.forwarding=0) will respond with Source Route Failed ICMPs to source-routed IP packets if source route processing is prohibited using net.inet.ip.sourceroute or net.inet.ip.accept_sourceroute. To my mind, it may be deduced from RFC 1122 that a host must stay silent in this case... -- Yar To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 19 13:50:49 2001 Delivered-To: freebsd-net@freebsd.org Received: from comp.chem.msu.su (comp-xl.chem.msu.su [158.250.32.157]) by hub.freebsd.org (Postfix) with ESMTP id 3854A37B419; Wed, 19 Dec 2001 13:50:44 -0800 (PST) Received: (from yar@localhost) by comp.chem.msu.su (8.11.1/8.11.1) id fBJLodv64337; Thu, 20 Dec 2001 00:50:39 +0300 (MSK) (envelope-from yar) Date: Thu, 20 Dec 2001 00:50:39 +0300 From: Yar Tikhiy To: Wilko Bulte Cc: Maxim Konovalov , net@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: Processing IP options reveals IPSTEALH router Message-ID: <20011220005038.B52848@comp.chem.msu.su> References: <20011219181929.A20425@comp.chem.msu.su> <20011219190533.W57795-100000@news1.macomnet.ru> <20011219223242.B4906@freebie.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011219223242.B4906@freebie.xs4all.nl>; from wkb@freebie.xs4all.nl on Wed, Dec 19, 2001 at 10:32:42PM +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 Wed, Dec 19, 2001 at 10:32:42PM +0100, Wilko Bulte wrote: > > > > First of all we should decide what IPSTEALTH is for. Is it just a > > Ruslan's net.inet.ip.decttl or it should really stealth the fact of > > the routing? If the latter how do we behave in source routing case? > > I would assume IPSTEALTH is thought to be for firewalls. Allowing > source routing thru firewalls is a Bad Thing(TM) anyway, right? Source routing itself is a Bad Thing, as is TELNET or rlogin. However, this isn't a reason strong enough to drop all such stuff from FreeBSD completely. That's why we're trying to consider every possible case. IMHO increasing the number of "FOO is incompatible with BAR" situations is no good. -- Yar To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 19 14:25: 0 2001 Delivered-To: freebsd-net@freebsd.org Received: from relay1.macomnet.ru (relay1.macomnet.ru [195.128.64.10]) by hub.freebsd.org (Postfix) with ESMTP id 6811737B417; Wed, 19 Dec 2001 14:24:54 -0800 (PST) Received: from news1.macomnet.ru (news1.macomnet.ru [195.128.64.14]) by relay1.macomnet.ru (8.11.3/8.11.3) with ESMTP id fBJMOrY3015098; Thu, 20 Dec 2001 01:24:53 +0300 (MSK) Date: Thu, 20 Dec 2001 01:24:48 +0300 (MSK) From: Maxim Konovalov To: Yar Tikhiy Cc: net@FreeBSD.ORG, Subject: Re: IP options (was: Processing IP options reveals IPSTEALH router) In-Reply-To: <20011220003555.A52848@comp.chem.msu.su> Message-ID: <20011220011255.G79558-100000@news1.macomnet.ru> 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 Morning, On 00:35+0300, Dec 20, 2001, Yar Tikhiy wrote: > On Wed, Dec 19, 2001 at 08:54:50PM +0300, Maxim Konovalov wrote: > > > > By the way, is it correct to forward the packet with incorrect ip > > options? Now we do not. > > No RFC seems to specify that particularly. However, RFC 1812 reads > in general: > > (1) A router MUST verify the IP header, as described in section > [5.2.2], before performing any actions based on the contents of > the header. This allows the router to detect and discard bad > packets before the expenditure of other resources. > > Meanwhile more IP option issues came to my attention... > > Neither RFC 791 nor RFC 1122 nor RFC 1812 specify the following: > if a source-routed IP packet reachs the end of its route, but its > destination address doesn't match a current host/router, whether > the packet should be discarded, sent forth through usual routing > or accepted as destined for this host? FreeBSD will route such a > packet as usual. Stevens, TCP Ill. vII, p.257 says: "If the destination address of the packet does not match one of the local addresses and the option is a strict source routing (IPOPT_SSRR), an ICMP source route failure error is sent. If a local address isn't listed in the route, the previous system sent the packet to the wrong host. This isn't an error for a loose source route (IPOPT_LSRR); it means IP must forward the packet toward the destionation." That is what ip_input does near the line 1193. > Then, a FreeBSD host (net.inet.ip.forwarding=0) will respond with > Source Route Failed ICMPs to source-routed IP packets if source > route processing is prohibited using net.inet.ip.sourceroute or > net.inet.ip.accept_sourceroute. To my mind, it may be deduced > from RFC 1122 that a host must stay silent in this case... -- Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer phone: +7 (095) 796-9079, mailto: maxim@macomnet.ru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 19 17:48:55 2001 Delivered-To: freebsd-net@freebsd.org Received: from parhelion.firedrake.org (parhelion.firedrake.org [212.135.138.219]) by hub.freebsd.org (Postfix) with ESMTP id CDB4A37B405; Wed, 19 Dec 2001 17:48:52 -0800 (PST) Received: from float by parhelion.firedrake.org with local (Exim 3.32 #1 (Debian)) id 16GsKJ-00054c-00; Thu, 20 Dec 2001 01:48:51 +0000 Date: Thu, 20 Dec 2001 01:48:51 +0000 To: Yar Tikhiy Cc: Wilko Bulte , Maxim Konovalov , net@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: Processing IP options reveals IPSTEALH router Message-ID: <20011220014851.A19346@parhelion.firedrake.org> Mail-Followup-To: Yar Tikhiy , Wilko Bulte , Maxim Konovalov , net@FreeBSD.ORG, hackers@FreeBSD.ORG References: <20011219181929.A20425@comp.chem.msu.su> <20011219190533.W57795-100000@news1.macomnet.ru> <20011219223242.B4906@freebie.xs4all.nl> <20011220005038.B52848@comp.chem.msu.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011220005038.B52848@comp.chem.msu.su> User-Agent: Mutt/1.3.23i From: void 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, Dec 20, 2001 at 12:50:39AM +0300, Yar Tikhiy wrote: > > Source routing itself is a Bad Thing, as is TELNET or rlogin. Telnet with Kerberos or other security options can be a fine thing. -- Ben "An art scene of delight I created this to be ..." -- Sun Ra To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 19 18: 9:49 2001 Delivered-To: freebsd-net@freebsd.org Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by hub.freebsd.org (Postfix) with ESMTP id B2C1237B417 for ; Wed, 19 Dec 2001 18:09:45 -0800 (PST) Received: from chimp.simianscience.com (cage.simianscience.com [64.7.134.1]) by smtp2.sentex.ca (8.11.6/8.11.6) with SMTP id fBK29g427329; Wed, 19 Dec 2001 21:09:42 -0500 (EST) (envelope-from mike@sentex.net) From: Mike Tancsa To: Julian Elischer Cc: freebsd-net@freebsd.org Subject: Re: Bridging vlan0 with de0 Date: Wed, 19 Dec 2001 21:09:42 -0500 Message-ID: <22i22u08iscdei27gkt2d3gg85pu56bb85@4ax.com> References: In-Reply-To: X-Mailer: Forte Agent 1.8/32.548 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, 19 Dec 2001 11:50:03 -0800 (PST), in sentex.lists.freebsd.net you wrote: >I believe you can bridge a vlan interface if you use the new upcoming >netgraph vlan node. It shuold be committed soon. (Vlans done the way it >should have been done ;-) What advantage does this method have ? ---Mike Mike Tancsa (mdtancsa@sentex.net) =09 Sentex Communications Corp, =09 Waterloo, Ontario, Canada "Given enough time, 100 monkeys on 100 routers=20 could setup a national IP network." (KDW2) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Dec 19 19:40:25 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 AE83837B41D for ; Wed, 19 Dec 2001 19:40:22 -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 <20011220034017.JZJN6450.rwcrmhc52.attbi.com@InterJet.elischer.org>; Thu, 20 Dec 2001 03:40:17 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id TAA48464; Wed, 19 Dec 2001 19:25:53 -0800 (PST) Date: Wed, 19 Dec 2001 19:25:52 -0800 (PST) From: Julian Elischer To: Mike Tancsa Cc: freebsd-net@freebsd.org Subject: Re: Bridging vlan0 with de0 In-Reply-To: <22i22u08iscdei27gkt2d3gg85pu56bb85@4ax.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, 19 Dec 2001, Mike Tancsa wrote: > On Wed, 19 Dec 2001 11:50:03 -0800 (PST), in sentex.lists.freebsd.net you > wrote: > > >I believe you can bridge a vlan interface if you use the new upcoming > >netgraph vlan node. It shuold be committed soon. (Vlans done the way it > >should have been done ;-) > > What advantage does this method have ? > you can tunnel the vlan over other other protocols etc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Dec 20 0:47:44 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 66B9237B405; Thu, 20 Dec 2001 00:47:35 -0800 (PST) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.6/8.11.2) id fBK8l8q77388; Thu, 20 Dec 2001 10:47:08 +0200 (EET) (envelope-from ru) Date: Thu, 20 Dec 2001 10:47:08 +0200 From: Ruslan Ermilov To: nimrodm@email.com Cc: freebsd-questions@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: FreeBSD IPSEC mini-howto updated! Message-ID: <20011220104708.D67452@sunbay.com> References: <3C1B7FAE.31484.401E08@localhost> <20011218111426.C30555@sunbay.com> <20011218220406.A51872@localhost.bsd.net.il> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011218220406.A51872@localhost.bsd.net.il> 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 18, 2001 at 10:04:06PM +0200, Nimrod Mesika wrote: > On Tue, Dec 18, 2001 at 11:14:26AM +0200, Ruslan Ermilov wrote: > > > http://www.x-itec.de/projects/tuts/ipsec-howto.txt > > > FreeBSD ipsec mini-howto > > > > > Now that you mention it. > > > > Why this document states that we need `gif' devices > > for IPSec to work? We're running VPN on IPSec without > > any gif(4) configured. The only ``magic'' used is to > > have routes on border nodes so that locally originated > > traffic has a proper source IP address. > > Just curious: > > Do you have any Windows 2000 machines on this VPN (working as > gateways or standalone clients connecting using IPSec)? > This VPN connects three networks, 192.168.0, 192.168.1, and 192.168.4, through the Internet, and it has a lot of Win2k machines. (Not sure what do you mean by "standalone clients connecting using IPSec.) These networks are connected by 3 FreeBSD boxes, running IPSec. 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 20 1:20:21 2001 Delivered-To: freebsd-net@freebsd.org Received: from scribble.fsn.hu (scribble.fsn.hu [193.224.40.95]) by hub.freebsd.org (Postfix) with SMTP id CF67F37B419 for ; Thu, 20 Dec 2001 01:20:15 -0800 (PST) Received: (qmail 19932 invoked by uid 1000); 20 Dec 2001 09:20:10 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 20 Dec 2001 09:20:10 -0000 Date: Thu, 20 Dec 2001 10:20:10 +0100 (CET) From: Attila Nagy To: Julian Elischer Cc: freebsd-net@freebsd.org Subject: Re: Bridging vlan0 with de0 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 Hello, > I believe you can bridge a vlan interface if you use the new upcoming > netgraph vlan node. It shuold be committed soon. (Vlans done the way > it should have been done ;-) Is it possible that this one will fix my FEC and VLAN problems? Is there a patch for -STABLE out there? I would be glad to test this :) -------------------------------------------------------------------------- Attila Nagy e-mail: Attila.Nagy@fsn.hu Budapest Polytechnic (BMF.HU) @work: +361 210 1415 (194) H-1084 Budapest, Tavaszmezo u. 15-17. cell.: +3630 306 6758 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Dec 20 1:40:11 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 2D61337B405 for ; Thu, 20 Dec 2001 01:40:08 -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 <20011220094007.WWKK20122.rwcrmhc53.attbi.com@InterJet.elischer.org>; Thu, 20 Dec 2001 09: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 BAA49777; Thu, 20 Dec 2001 01:23:53 -0800 (PST) Date: Thu, 20 Dec 2001 01:23:53 -0800 (PST) From: Julian Elischer To: Attila Nagy Cc: freebsd-net@freebsd.org Subject: Re: Bridging vlan0 with de0 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 it is being donated by a french fellow. He is just polishing it. I will try commit it in the next few days. On Thu, 20 Dec 2001, Attila Nagy wrote: > Hello, > > > I believe you can bridge a vlan interface if you use the new upcoming > > netgraph vlan node. It shuold be committed soon. (Vlans done the way > > it should have been done ;-) > Is it possible that this one will fix my FEC and VLAN problems? Is there a > patch for -STABLE out there? I would be glad to test this :) > > -------------------------------------------------------------------------- > Attila Nagy e-mail: Attila.Nagy@fsn.hu > Budapest Polytechnic (BMF.HU) @work: +361 210 1415 (194) > H-1084 Budapest, Tavaszmezo u. 15-17. cell.: +3630 306 6758 > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Dec 20 2:44:29 2001 Delivered-To: freebsd-net@freebsd.org Received: from scribble.fsn.hu (scribble.fsn.hu [193.224.40.95]) by hub.freebsd.org (Postfix) with SMTP id 4E8F337B41B for ; Thu, 20 Dec 2001 02:44:24 -0800 (PST) Received: (qmail 20600 invoked by uid 1000); 20 Dec 2001 10:44:23 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 20 Dec 2001 10:44:23 -0000 Date: Thu, 20 Dec 2001 11:44:23 +0100 (CET) From: Attila Nagy To: Julian Elischer Cc: freebsd-net@freebsd.org Subject: Re: Bridging vlan0 with de0 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 Hello, > it is being donated by a french fellow. He is just polishing it. I > will try commit it in the next few days. Great, thanks! -------------------------------------------------------------------------- Attila Nagy e-mail: Attila.Nagy@fsn.hu Budapest Polytechnic (BMF.HU) @work: +361 210 1415 (194) H-1084 Budapest, Tavaszmezo u. 15-17. cell.: +3630 306 6758 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Dec 20 3:18: 7 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 78F4D37B417 for ; Thu, 20 Dec 2001 03:18:00 -0800 (PST) Received: (qmail 89716 invoked from network); 20 Dec 2001 11:13:44 -0000 Received: from aworklan001038.netvigator.com (HELO yusufg.portal2.com) (203.198.151.38) by box.dhsnames.com with SMTP; 20 Dec 2001 11:13:44 -0000 Received: (qmail 3328 invoked by uid 500); 20 Dec 2001 11:15:45 -0000 Date: 20 Dec 2001 11:15:45 -0000 Message-ID: <20011220111545.3327.qmail@yusufg.portal2.com> From: Yusuf Goolamabbas To: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Cc: cez@pkl.net Subject: 4.4-stable kernel panic with dummynet/bridging. Same rules work fine with 4.3-RC 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, Similar to what Ceri describes in this message http://docs.freebsd.org/cgi/getmsg.cgi?fetch=508422+0+current/freebsd-stable I have observed a 4.4-stable box panicing whenever bridging is turned on. This was cvsup'ed today morning. I have other boxes cvsup'ed at the same time except that they don't have dummynet/bridging configured in them and they work pretty well I replaced the box with an another 4.3-RC box and the same rules enclosed here work just fine ${fwcmd} add 100 pass all from any to any via lo0 ${fwcmd} add 200 deny all from any to 127.0.0.0/8 ${fwcmd} add 300 deny ip from 127.0.0.0/8 to any # If you're using 'options BRIDGE', uncomment the following line to pass ARP ${fwcmd} add 400 pass udp from 0.0.0.0 2054 to 0.0.0.0 ${fwcmd} add 500 pass all from to any in via fxp0 ${fwcmd} add 800 pipe 1 ip from to any in via fxp1 ${fwcmd} pipe 1 config mask src-ip 0x000000ff bw 512Kbit/s queue 50 Basically, fxp1 is connected to a switch and every machine on that switch is rate limited to 512Kbit/s individually I had configured the box with DDB but didn't have serial console so I transcribed everything at the db> prompt Fatal trap 12: page fault while in kernel mode fault virtual address = 0xa4 fault code = superviser read, page not present instruction pointer = 0x8:0xc0199164 strack pointer = 0x10:0xc9889b5c frame pointer = 0x10:0xc9889bac code segment = base 0x0, limit 0xfff type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 55 (sh) interrupt mask = kernel: type 12 trap, code = 0 stopped at in_arpinput+0x158; movl 0xa4(%eax,%eax) db> t in_arpinput(c077cb00,0,c989cac,c020d625,c020d5df) at in_arpinput+0x158 arpintr(c020dfdf,0,c02800,0,c7640010,c0e700,0) at arpintr+0x112 swi_net_next(c028c26c,c764f000,3,0,c835c440) at swi_net_next trap_pfault(c9889d20,0,c764f000,0,806c591) at trap_pfault+0xbe trap(10,c9880010,c01d0010,c764f000,80be591_ at trap+0x31f calltrap() at calltrap+0x11 trap 0xc : eip - 0xc02172cf , esp - 0xc9889d60, ebp - 0xc9889d88 copyinstr(c9889e68,0,0,c9889f80,c9889f80) at copyinstr+0x37 exec_elf_imagact(c9889e68,c835c440,3,c9889f80,c9889e68) at exec_elf_imagact+0xba execve(c835c440,c9889f80,80be5d4,0,80be590) at execve+0x26c syscall2(2f,2f,2f,80be590,0) at syscall2+0x1a5 Xinit0x80_syscall() + Xint-x80_syscall+0x25 Hope this helps 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 Thu Dec 20 5:13:15 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 56B1C37B417 for ; Thu, 20 Dec 2001 05:12:48 -0800 (PST) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.6/8.11.2) id fBKDAcO18448; Thu, 20 Dec 2001 15:10:38 +0200 (EET) (envelope-from ru) Date: Thu, 20 Dec 2001 15:10:38 +0200 From: Ruslan Ermilov To: Josef Karthauser Cc: Yusuf Goolamabbas , freebsd-net@freebsd.org Subject: Re: Is there a way to clear stats from netstat -i Message-ID: <20011220151038.G6625@sunbay.com> References: <20011211123504.A5909@outblaze.com> <20011219182139.A9340@tao.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011219182139.A9340@tao.org.uk> 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 Wed, Dec 19, 2001 at 06:21:39PM +0000, Josef Karthauser wrote: > Hi Ruslan, > > You've been near this code recently. Do you have any suggestions for > how this may work? > This would require a new SIOCCIFDATA ioctl in group 'i'. > On Tue, Dec 11, 2001 at 12:35:04PM +0800, Yusuf Goolamabbas wrote: > > 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 -- 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 20 6:28:19 2001 Delivered-To: freebsd-net@freebsd.org Received: from ns2.robhughes.com (12-237-138-77.client.attbi.com [12.237.138.77]) by hub.freebsd.org (Postfix) with SMTP id 92A3737B416 for ; Thu, 20 Dec 2001 06:27:59 -0800 (PST) Received: (qmail 6396 invoked from network); 20 Dec 2001 14:27:58 -0000 Received: from hexch01.robhughes.com (192.168.1.3) by ns2.robhughes.com with SMTP; 20 Dec 2001 14:27:58 -0000 Subject: RE: 4.4-stable kernel panic with dummynet/bridging. Same rules work fine with 4.3-RC MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 20 Dec 2001 08:27:58 -0600 Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 X-MS-Has-Attach: Content-Class: urn:content-classes:message X-MS-TNEF-Correlator: Thread-Topic: 4.4-stable kernel panic with dummynet/bridging. Same rules work fine with 4.3-RC Thread-Index: AcGJSAtQ/suwCWlDR+SFGrTvBTGKXwAGe4vw From: "Robert D. Hughes" To: "Yusuf Goolamabbas" , , 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 Hmmmm.... I thought it was just me, and I hadn't had a chance yet to go digging. I just enabled OPTIONS =3D BRIDGE in the kernel and I was = getting spontaneous reboots, but they pointed to NATD blowing up. Essentially the same error though. Removing OPTIONS =3D BRIDGE seems to have stopped the reboots. This is on the 4.4-STABLE tree and has been going on for at least a couple of weeks. Rob -----Original Message----- From: Yusuf Goolamabbas [mailto:yusufg@outblaze.com] Sent: Thursday, December 20, 2001 5:16 AM To: freebsd-net@freebsd.org; freebsd-stable@freebsd.org Cc: cez@pkl.net Subject: 4.4-stable kernel panic with dummynet/bridging. Same rules work fine with 4.3-RC Hi, Similar to what Ceri describes in this message http://docs.freebsd.org/cgi/getmsg.cgi?fetch=3D508422+0+current/freebsd-s= t able I have observed a 4.4-stable box panicing whenever bridging is turned on. This was cvsup'ed today morning. I have other boxes cvsup'ed at the same time except that they don't have dummynet/bridging configured in them and they work pretty well I replaced the box with an another 4.3-RC box and the same rules enclosed here work just fine ${fwcmd} add 100 pass all from any to any via lo0 ${fwcmd} add 200 deny all from any to 127.0.0.0/8 ${fwcmd} add 300 deny ip from 127.0.0.0/8 to any # If you're using 'options BRIDGE', uncomment the following line to pass ARP ${fwcmd} add 400 pass udp from 0.0.0.0 2054 to 0.0.0.0 ${fwcmd} add 500 pass all from to any in via fxp0 ${fwcmd} add 800 pipe 1 ip from to any in via fxp1 ${fwcmd} pipe 1 config mask src-ip 0x000000ff bw 512Kbit/s queue 50=20 Basically, fxp1 is connected to a switch and every machine on that switch is rate limited to 512Kbit/s individually I had configured the box with DDB but didn't have serial console so I transcribed everything at the db> prompt Fatal trap 12: page fault while in kernel mode fault virtual address =3D 0xa4 fault code =3D superviser read, page not present instruction pointer =3D 0x8:0xc0199164 strack pointer =3D 0x10:0xc9889b5c frame pointer =3D 0x10:0xc9889bac code segment =3D base 0x0, limit 0xfff type 0x1b =3D DPL 0, pres 1, def32 1, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 55 (sh) interrupt mask =3D kernel: type 12 trap, code =3D 0 stopped at in_arpinput+0x158; movl 0xa4(%eax,%eax) db> t in_arpinput(c077cb00,0,c989cac,c020d625,c020d5df) at in_arpinput+0x158 arpintr(c020dfdf,0,c02800,0,c7640010,c0e700,0) at arpintr+0x112 swi_net_next(c028c26c,c764f000,3,0,c835c440) at swi_net_next trap_pfault(c9889d20,0,c764f000,0,806c591) at trap_pfault+0xbe trap(10,c9880010,c01d0010,c764f000,80be591_ at trap+0x31f calltrap() at calltrap+0x11 trap 0xc : eip - 0xc02172cf , esp - 0xc9889d60, ebp - 0xc9889d88 copyinstr(c9889e68,0,0,c9889f80,c9889f80) at copyinstr+0x37 exec_elf_imagact(c9889e68,c835c440,3,c9889f80,c9889e68) at exec_elf_imagact+0xba execve(c835c440,c9889f80,80be5d4,0,80be590) at execve+0x26c syscall2(2f,2f,2f,80be590,0) at syscall2+0x1a5 Xinit0x80_syscall() + Xint-x80_syscall+0x25 Hope this helps Regards, Yusuf --=20 Yusuf Goolamabbas yusufg@outblaze.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" 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 20 9:27:59 2001 Delivered-To: freebsd-net@freebsd.org Received: from cs.rice.edu (cs.rice.edu [128.42.1.30]) by hub.freebsd.org (Postfix) with ESMTP id 19E3337B417 for ; Thu, 20 Dec 2001 09:27:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by cs.rice.edu (Postfix) with ESMTP id 718C718E1 for ; Thu, 20 Dec 2001 11:27:50 -0600 (CST) Received: from nevada.cs.rice.edu (nevada.cs.rice.edu [128.42.1.164]) by cs.rice.edu (Postfix) with ESMTP id 5A6A41827 for ; Thu, 20 Dec 2001 11:27:47 -0600 (CST) Received: from localhost (hykim@localhost) by nevada.cs.rice.edu (8.9.3+Sun/8.9.0) with ESMTP id LAA05044 for ; Thu, 20 Dec 2001 11:27:32 -0600 (CST) X-Authentication-Warning: nevada.cs.rice.edu: hykim owned process doing -bs Date: Thu, 20 Dec 2001 11:27:32 -0600 (CST) From: Hyong-Youb Kim To: Subject: a newb question regarding TCP/IP hdrs Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS snapshot-20010714 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org From what I have learned (textbooks etc.), the size of TCP/IP headers do not change often. I wonder then how often they do change in a system running a webserver. Or is there a sysctl variable that reports such things? Thanks. John To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Dec 20 12:49: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 B51A137B416; Thu, 20 Dec 2001 12:49:10 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.3/8.11.1) id fBKKmxq09042; Thu, 20 Dec 2001 12:48:59 -0800 (PST) (envelope-from rizzo) Date: Thu, 20 Dec 2001 12:48:59 -0800 From: Luigi Rizzo To: Yusuf Goolamabbas Cc: freebsd-net@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG, cez@pkl.net Subject: Re: 4.4-stable kernel panic with dummynet/bridging. Same rules work fine with 4.3-RC Message-ID: <20011220124859.A8969@iguana.aciri.org> References: <20011220111545.3327.qmail@yusufg.portal2.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011220111545.3327.qmail@yusufg.portal2.com> 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 I wonder if this isn't related to some change in the handling of interface lists, routes or arp entries. I do not recall any recent change in the dummynet/bridge code that might cause this. On passing. the line ${fwcmd} add 400 pass udp from 0.0.0.0 2054 to 0.0.0.0 has not been supported for a long time. How repeatable is the problem ? It shouldn't be hard to track, it looks like a null pointer dereference. cheers luigi On Thu, Dec 20, 2001 at 11:15:45AM -0000, Yusuf Goolamabbas wrote: > Hi, Similar to what Ceri describes in this message > > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=508422+0+current/freebsd-stable > > I have observed a 4.4-stable box panicing whenever bridging is turned > on. This was cvsup'ed today morning. I have other boxes cvsup'ed at > the same time except that they don't have dummynet/bridging configured > in them and they work pretty well > > I replaced the box with an another 4.3-RC box and the same rules > enclosed here work just fine > > ${fwcmd} add 100 pass all from any to any via lo0 > ${fwcmd} add 200 deny all from any to 127.0.0.0/8 > ${fwcmd} add 300 deny ip from 127.0.0.0/8 to any > # If you're using 'options BRIDGE', uncomment the following line to pass ARP > ${fwcmd} add 400 pass udp from 0.0.0.0 2054 to 0.0.0.0 > ${fwcmd} add 500 pass all from to any in via fxp0 > ${fwcmd} add 800 pipe 1 ip from to any in via fxp1 > ${fwcmd} pipe 1 config mask src-ip 0x000000ff bw 512Kbit/s queue 50 > > Basically, fxp1 is connected to a switch and every machine on that > switch is rate limited to 512Kbit/s individually > > I had configured the box with DDB but didn't have serial console so I > transcribed everything at the db> prompt > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0xa4 > fault code = superviser read, page not present > instruction pointer = 0x8:0xc0199164 > strack pointer = 0x10:0xc9889b5c > frame pointer = 0x10:0xc9889bac > code segment = base 0x0, limit 0xfff type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 55 (sh) > interrupt mask = > kernel: type 12 trap, code = 0 > stopped at in_arpinput+0x158; movl 0xa4(%eax,%eax) > > db> t > in_arpinput(c077cb00,0,c989cac,c020d625,c020d5df) at in_arpinput+0x158 > arpintr(c020dfdf,0,c02800,0,c7640010,c0e700,0) at arpintr+0x112 > swi_net_next(c028c26c,c764f000,3,0,c835c440) at swi_net_next > trap_pfault(c9889d20,0,c764f000,0,806c591) at trap_pfault+0xbe > trap(10,c9880010,c01d0010,c764f000,80be591_ at trap+0x31f > calltrap() at calltrap+0x11 > trap 0xc : eip - 0xc02172cf , esp - 0xc9889d60, ebp - 0xc9889d88 > copyinstr(c9889e68,0,0,c9889f80,c9889f80) at copyinstr+0x37 > exec_elf_imagact(c9889e68,c835c440,3,c9889f80,c9889e68) at exec_elf_imagact+0xba > execve(c835c440,c9889f80,80be5d4,0,80be590) at execve+0x26c > syscall2(2f,2f,2f,80be590,0) at syscall2+0x1a5 > Xinit0x80_syscall() + Xint-x80_syscall+0x25 > > Hope this helps > > 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Dec 20 12:56:18 2001 Delivered-To: freebsd-net@freebsd.org Received: from ns1.nttmcl.com (ns1.nttmcl.com [216.69.68.197]) by hub.freebsd.org (Postfix) with ESMTP id A5D1237B41B for ; Thu, 20 Dec 2001 12:56:05 -0800 (PST) Received: from hsu (dhcp252.nttmcl.com [216.69.69.252]) by ns1.nttmcl.com (Postfix) with SMTP id 472AEDE541 for ; Thu, 20 Dec 2001 12:56:05 -0800 (PST) Reply-To: From: "Henry Su" To: Subject: socket call in the kernel Date: Thu, 20 Dec 2001 12:58:22 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal 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 am trying to modify ip_fw.c in the /usr/src/sys/netinet, I tried to add a socket call in the code, it can be compiled, but when it runs into the code, it just crashed. It gave me the "Fatal trap error 12", Memory address is wrong. Can any one tell me if socket call can be used in kernel level? If not, how can I accomplish socket communication in the kernel level? Thanks. ------------------------------------------------ Henry Su NTT Multimedia Communications Laboratories, Inc. 250 Cambridge Avenue Suite 300 Palo Alto, CA 94306, USA (PST:UTC -8H) Tel: +1 650 833 3652 Fax: +1 650 326 1878 http://www.nttmcl.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Dec 20 13: 0:17 2001 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id 512B637B405 for ; Thu, 20 Dec 2001 13:00:13 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20011220210012.ISKU19716.rwcrmhc51.attbi.com@InterJet.elischer.org>; Thu, 20 Dec 2001 21:00:12 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA52754; Thu, 20 Dec 2001 12:59:07 -0800 (PST) Date: Thu, 20 Dec 2001 12:59:07 -0800 (PST) From: Julian Elischer To: Henry Su Cc: freebsd-net@FreeBSD.ORG Subject: Re: socket call in the kernel 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 You cannot do a socket directly but you can indirectly tell me what you are trying to do and I can help.. On Thu, 20 Dec 2001, Henry Su wrote: > I am trying to modify ip_fw.c in the /usr/src/sys/netinet, I tried to add a > socket call in the code, it can be compiled, but when it runs into the code, > it just crashed. It gave me the "Fatal trap error 12", Memory address is > wrong. > > Can any one tell me if socket call can be used in kernel level? If not, how > can I accomplish socket communication in the kernel level? > > Thanks. > > ------------------------------------------------ > > Henry Su > > NTT Multimedia Communications Laboratories, Inc. > > 250 Cambridge Avenue Suite 300 > > Palo Alto, CA 94306, USA (PST:UTC -8H) > > Tel: +1 650 833 3652 > > Fax: +1 650 326 1878 > > http://www.nttmcl.com/ > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Dec 20 13:56: 9 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 D849F37B405 for ; Thu, 20 Dec 2001 13:56:05 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id 6529981E0B; Thu, 20 Dec 2001 15:56:00 -0600 (CST) Date: Thu, 20 Dec 2001 15:56:00 -0600 From: Alfred Perlstein To: Henry Su Cc: freebsd-net@FreeBSD.ORG Subject: Re: socket call in the kernel Message-ID: <20011220155600.J48837@elvis.mu.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from henrysu@nttmcl.com on Thu, Dec 20, 2001 at 12:58:22PM -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 * Henry Su [011220 14:56] wrote: > I am trying to modify ip_fw.c in the /usr/src/sys/netinet, I tried to add a > socket call in the code, it can be compiled, but when it runs into the code, > it just crashed. It gave me the "Fatal trap error 12", Memory address is > wrong. > > Can any one tell me if socket call can be used in kernel level? If not, how > can I accomplish socket communication in the kernel level? This is nowhere near enough information for anyone to be able to help you. Please be more specific, show us some example code. thanks, -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' http://www.morons.org/rants/gpl-harmful.php3 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Dec 20 13:59:21 2001 Delivered-To: freebsd-net@freebsd.org Received: from infiniteloop.ca (infiniteloop.ca [216.126.86.53]) by hub.freebsd.org (Postfix) with ESMTP id 0963737B417 for ; Thu, 20 Dec 2001 13:59:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by infiniteloop.ca (Postfix) with ESMTP id 8E7F81E4 for ; Thu, 20 Dec 2001 16:59:17 -0500 (EST) Received: from blake (CPE0050da7c7e5d.cpe.net.cable.rogers.com [24.101.32.246]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by infiniteloop.ca (Postfix) with ESMTP id CBAA913E for ; Thu, 20 Dec 2001 16:59:16 -0500 (EST) From: "Blake Crosby" To: Subject: mpd PPTP Proxy Arp Date: Thu, 20 Dec 2001 16:59:19 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-Virus-Scanned: by AMaViS snapshot-20010714 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 Hmm For some reason, I cannot seem to get the proxy arp portion of PPTP to work: [pptp] exec: /sbin/ifconfig ng0 10.1.1.79 10.1.1.80 netmask 0xffffffff -link0 [pptp] exec: /usr/sbin/arp -s 10.1.1.80 0:4f:49:9:bc:b9 pub manually running arp yields: arp -s 10.1.1.2 00:01:2e:00:1f:f2 pub cannot intuit interface index and type for 10.1.1.2 any idea what could be wrong? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Dec 20 14:59:45 2001 Delivered-To: freebsd-net@freebsd.org Received: from ns1.nttmcl.com (ns1.nttmcl.com [216.69.68.197]) by hub.freebsd.org (Postfix) with ESMTP id 21A6937B417 for ; Thu, 20 Dec 2001 14:59:37 -0800 (PST) Received: from hsu (dhcp252.nttmcl.com [216.69.69.252]) by ns1.nttmcl.com (Postfix) with SMTP id 014B7DE541; Thu, 20 Dec 2001 14:59:36 -0800 (PST) Reply-To: From: "Henry Su" To: "Julian Elischer" Cc: Subject: RE: socket call in the kernel Date: Thu, 20 Dec 2001 15:01:54 -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.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-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 Thanks, Julian and Alfred. I am trying to redirect the denied http request to a default web site. So my idea is in the "ip_fw_chk" function of ip_fw.c, add following code, when it will drop the packet. But as you pointed out in earlier email, socket can not be used in this case. Do u have any other solutions? Thanks a lot. * Finally, drop the packet. */ /* my code start debug */ /* find if it's a http packet */ dst_port_h = ntohs(dst_port); if(dst_port_h==80){ log(LOG_INFO,"src_port:%u src_ip:%d dst_port:%d dst_ip:%u", ntohs(src_port), src_ip.s_addr, nt ohs(dst_port), dst_ip.s_addr); /*s = 1;*/ s = socket(AF_INET, SOCK_STREAM, 0); if (s < 0) { log(LOG_INFO,"Redirect socket can not be created"); }else{ log(LOG_INFO,"Redirect socket is created"); /* bzero(&sa, sizeof sa); sa.sin_family = AF_INET; sa.sin_port = src_port; sa.sin_addr.s_addr = src_ip.s_addr; if (connect(s, (struct sockaddr *)&sa, sizeof sa) < 0) { log(LOG_INFO,"connect %d failed", src_ip.s_addr); close(s); }else{ log(LOG_INFO,"connect %d ok", src_ip.s_addr); close(s); } */ /* while ((bytes = read(s, buffer, BUFSIZ)) > 0) write(1, buffer, bytes); */ } } /* end debug */ return(IP_FW_PORT_DENY_FLAG); -----Original Message----- From: Julian Elischer [mailto:julian@elischer.org] Sent: Thursday, December 20, 2001 12:59 PM To: Henry Su Cc: freebsd-net@FreeBSD.ORG Subject: Re: socket call in the kernel You cannot do a socket directly but you can indirectly tell me what you are trying to do and I can help.. On Thu, 20 Dec 2001, Henry Su wrote: > I am trying to modify ip_fw.c in the /usr/src/sys/netinet, I tried to add a > socket call in the code, it can be compiled, but when it runs into the code, > it just crashed. It gave me the "Fatal trap error 12", Memory address is > wrong. > > Can any one tell me if socket call can be used in kernel level? If not, how > can I accomplish socket communication in the kernel level? > > Thanks. > > ------------------------------------------------ > > Henry Su > > NTT Multimedia Communications Laboratories, Inc. > > 250 Cambridge Avenue Suite 300 > > Palo Alto, CA 94306, USA (PST:UTC -8H) > > Tel: +1 650 833 3652 > > Fax: +1 650 326 1878 > > http://www.nttmcl.com/ > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Dec 20 15:20:32 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 3D7EE37B405 for ; Thu, 20 Dec 2001 15:20:08 -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 <20011220232007.KWDT6450.rwcrmhc52.attbi.com@InterJet.elischer.org>; Thu, 20 Dec 2001 23:20:07 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id PAA53598; Thu, 20 Dec 2001 15:11:12 -0800 (PST) Date: Thu, 20 Dec 2001 15:11:12 -0800 (PST) From: Julian Elischer To: Henry Su Cc: freebsd-net@FreeBSD.ORG Subject: RE: socket call in the kernel 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 programming in the kernel is not the same as outside the kernel. you can't use read(), open() write(), etc. in the same way, even if the functions exist.. (they have different args and require certain in kernel state.) socket can DEFINITLY not be used.. As I mentioned.. use a ipfw fwd rule instead of the deny rule.. On Thu, 20 Dec 2001, Henry Su wrote: > Thanks, Julian and Alfred. > > I am trying to redirect the denied http request to a default web site. So my > idea is in the "ip_fw_chk" function of ip_fw.c, add following code, when it > will drop the packet. But as you pointed out in earlier email, socket can > not be used in this case. Do u have any other solutions? Thanks a lot. > > > > * Finally, drop the packet. > */ > > > /* my code start debug */ > /* find if it's a http packet */ > dst_port_h = ntohs(dst_port); > if(dst_port_h==80){ > log(LOG_INFO,"src_port:%u src_ip:%d dst_port:%d dst_ip:%u", > ntohs(src_port), src_ip.s_addr, nt > ohs(dst_port), dst_ip.s_addr); > /*s = 1;*/ > s = socket(AF_INET, SOCK_STREAM, 0); > if (s < 0) { > log(LOG_INFO,"Redirect socket can not be created"); > }else{ > log(LOG_INFO,"Redirect socket is created"); > /* > bzero(&sa, sizeof sa); > sa.sin_family = AF_INET; > sa.sin_port = src_port; > sa.sin_addr.s_addr = src_ip.s_addr; > if (connect(s, (struct sockaddr *)&sa, sizeof sa) < > 0) { > log(LOG_INFO,"connect %d failed", > src_ip.s_addr); > close(s); > }else{ > log(LOG_INFO,"connect %d ok", > src_ip.s_addr); > close(s); > } > */ > /* > while ((bytes = read(s, buffer, BUFSIZ)) > 0) > write(1, buffer, bytes); > */ > } > } > /* end debug */ > return(IP_FW_PORT_DENY_FLAG); > > > -----Original Message----- > From: Julian Elischer [mailto:julian@elischer.org] > Sent: Thursday, December 20, 2001 12:59 PM > To: Henry Su > Cc: freebsd-net@FreeBSD.ORG > Subject: Re: socket call in the kernel > > > > > You cannot do a socket directly but you can indirectly > tell me what you are trying to do and I can help.. > > > > On Thu, 20 Dec 2001, Henry Su wrote: > > > I am trying to modify ip_fw.c in the /usr/src/sys/netinet, I tried to add > a > > socket call in the code, it can be compiled, but when it runs into the > code, > > it just crashed. It gave me the "Fatal trap error 12", Memory address is > > wrong. > > > > Can any one tell me if socket call can be used in kernel level? If not, > how > > can I accomplish socket communication in the kernel level? > > > > Thanks. > > > > ------------------------------------------------ > > > > Henry Su > > > > NTT Multimedia Communications Laboratories, Inc. > > > > 250 Cambridge Avenue Suite 300 > > > > Palo Alto, CA 94306, USA (PST:UTC -8H) > > > > Tel: +1 650 833 3652 > > > > Fax: +1 650 326 1878 > > > > http://www.nttmcl.com/ > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-net" in the body of the message > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Dec 20 15:20:42 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 CE10B37B416 for ; Thu, 20 Dec 2001 15:20:18 -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 <20011220232018.KWHG6450.rwcrmhc52.attbi.com@InterJet.elischer.org>; Thu, 20 Dec 2001 23:20:18 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id PAA53561; Thu, 20 Dec 2001 15:07:51 -0800 (PST) Date: Thu, 20 Dec 2001 15:07:50 -0800 (PST) From: Julian Elischer To: Henry Su Cc: freebsd-net@FreeBSD.ORG Subject: RE: socket call in the kernel 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 I have two answers: 1/ Use ipfw add NNN fwd localhost,8001 [deny criteria] to make the packet that is denied go to a default server listenning on port 8001 2/ there is an in-kernel webserver built using netgraph but it's not public, but you can definitly use the 'ksocket' node to open 'in kernel' sockets and pass the result to an arbitrary node. 1 can do what you want with no kernel programming.. check it out.. man ipfw On Thu, 20 Dec 2001, Henry Su wrote: > Thanks, Julian and Alfred. > > I am trying to redirect the denied http request to a default web site. So my > idea is in the "ip_fw_chk" function of ip_fw.c, add following code, when it > will drop the packet. But as you pointed out in earlier email, socket can > not be used in this case. Do u have any other solutions? Thanks a lot. > > > > * Finally, drop the packet. > */ > > > /* my code start debug */ > /* find if it's a http packet */ > dst_port_h = ntohs(dst_port); > if(dst_port_h==80){ > log(LOG_INFO,"src_port:%u src_ip:%d dst_port:%d dst_ip:%u", > ntohs(src_port), src_ip.s_addr, nt > ohs(dst_port), dst_ip.s_addr); > /*s = 1;*/ > s = socket(AF_INET, SOCK_STREAM, 0); > if (s < 0) { > log(LOG_INFO,"Redirect socket can not be created"); > }else{ > log(LOG_INFO,"Redirect socket is created"); > /* > bzero(&sa, sizeof sa); > sa.sin_family = AF_INET; > sa.sin_port = src_port; > sa.sin_addr.s_addr = src_ip.s_addr; > if (connect(s, (struct sockaddr *)&sa, sizeof sa) < > 0) { > log(LOG_INFO,"connect %d failed", > src_ip.s_addr); > close(s); > }else{ > log(LOG_INFO,"connect %d ok", > src_ip.s_addr); > close(s); > } > */ > /* > while ((bytes = read(s, buffer, BUFSIZ)) > 0) > write(1, buffer, bytes); > */ > } > } > /* end debug */ > return(IP_FW_PORT_DENY_FLAG); > > > -----Original Message----- > From: Julian Elischer [mailto:julian@elischer.org] > Sent: Thursday, December 20, 2001 12:59 PM > To: Henry Su > Cc: freebsd-net@FreeBSD.ORG > Subject: Re: socket call in the kernel > > > > > You cannot do a socket directly but you can indirectly > tell me what you are trying to do and I can help.. > > > > On Thu, 20 Dec 2001, Henry Su wrote: > > > I am trying to modify ip_fw.c in the /usr/src/sys/netinet, I tried to add > a > > socket call in the code, it can be compiled, but when it runs into the > code, > > it just crashed. It gave me the "Fatal trap error 12", Memory address is > > wrong. > > > > Can any one tell me if socket call can be used in kernel level? If not, > how > > can I accomplish socket communication in the kernel level? > > > > Thanks. > > > > ------------------------------------------------ > > > > Henry Su > > > > NTT Multimedia Communications Laboratories, Inc. > > > > 250 Cambridge Avenue Suite 300 > > > > Palo Alto, CA 94306, USA (PST:UTC -8H) > > > > Tel: +1 650 833 3652 > > > > Fax: +1 650 326 1878 > > > > http://www.nttmcl.com/ > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-net" in the body of the message > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Dec 20 16:39:41 2001 Delivered-To: freebsd-net@freebsd.org Received: from alicia.nttmcl.com (alicia.nttmcl.com [216.69.69.10]) by hub.freebsd.org (Postfix) with ESMTP id D79A637B416 for ; Thu, 20 Dec 2001 16:39:38 -0800 (PST) Received: from ntt27f48otgmw8 (dhcp246.nttmcl.com [216.69.69.246]) by alicia.nttmcl.com (8.10.1/8.10.1) with SMTP id fBL0dcv10972 for ; Thu, 20 Dec 2001 16:39:38 -0800 (PST) Reply-To: From: "Anuranjan" To: Subject: Memory mapped device Date: Thu, 20 Dec 2001 16:41:10 -0800 Message-ID: <015201c189b8$301b5550$f64545d8@ntt27f48otgmw8> 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 CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal 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 , I'm trying to write some driver code for a memory mapped device (PCI bus). struct xxx_softc *sc = device_get_softc(dev); struct resource *res; /* * Map control/status registers. */ command = pci_read_config(dev, PCIR_COMMAND, 4); command |= (PCIM_CMD_MEMEN | PCIM_CMD_BUSMASTEREN); pci_write_config(dev, PCIR_COMMAND, command, 4); command = pci_read_config(dev, PCIR_COMMAND, 4); if (!(command & PCIM_CMD_MEMEN)) { printf("xxx%d: failed to enable memory mapping!\n", unit); error = ENXIO; goto fail; } else printf("xxx%d: memory mapping enabled\n", unit); mem_rid = 0x10; res = bus_alloc_resource(dev, SYS_RES_MEMORY, &mem_rid, 0ul, ~0ul, size, RF_ACTIVE); I've been able to probe the device correctly, get the IRQ resource allocated correctly etc, I don't get any errors in this mapping enable and alloc code either. But when I try accessing the device I don't get the correct results (can't get to the eeprom, and can't access correct values from the register offsets. u_int32_t s = bus_space_read_4(sc->btag, sc->bhandle, REGISTER_OFFSET); The device is basically a Cardbus card attached to the freebsd 4.3 PCI bus through a Cardbus/PCI extender card. I don't know exactly why it couldn't be working here. Is it the problem with the mapping, or is it with the device, or with the freeBSD mechanism? I'm a newbie so please excuse me if I'm posting this at the wrong forum and let me know the right place to go to. Thanks in advance A To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Dec 20 19: 7:46 2001 Delivered-To: freebsd-net@freebsd.org Received: from ns2.robhughes.com (12-237-138-77.client.attbi.com [12.237.138.77]) by hub.freebsd.org (Postfix) with SMTP id B265837B419 for ; Thu, 20 Dec 2001 19:07:37 -0800 (PST) Received: (qmail 23558 invoked from network); 21 Dec 2001 03:07:36 -0000 Received: from hexch01.robhughes.com (192.168.1.3) by ns2.robhughes.com with SMTP; 21 Dec 2001 03:07:36 -0000 Subject: RE: 4.4-stable kernel panic with dummynet/bridging. Same rules work fine with 4.3-RC MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 20 Dec 2001 21:07:35 -0600 Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Content-Class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 4.4-stable kernel panic with dummynet/bridging. Same rules work fine with 4.3-RC Thread-Index: AcGJmB9b3eYlvdR3R5+W24Ah+x1PZwANEYiw From: "Robert D. Hughes" To: "Luigi Rizzo" , "Yusuf Goolamabbas" 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 Really? Its still part of the default rc.firewall that's being distributed and I haven't seen it mentioned anywhere the its been deprecated. -----Original Message----- From: Luigi Rizzo [mailto:rizzo@aciri.org] Sent: Thursday, December 20, 2001 2:49 PM To: Yusuf Goolamabbas Cc: freebsd-net@FreeBSD.ORG; freebsd-stable@FreeBSD.ORG; cez@pkl.net Subject: Re: 4.4-stable kernel panic with dummynet/bridging. Same rules work fine with 4.3-RC I wonder if this isn't related to some change in the handling of interface lists, routes or arp entries. I do not recall any recent change in the dummynet/bridge code that might cause this. On passing. the line ${fwcmd} add 400 pass udp from 0.0.0.0 2054 to 0.0.0.0 has not been supported for a long time. How repeatable is the problem ? It shouldn't be hard to track, it looks like a null pointer dereference. cheers luigi On Thu, Dec 20, 2001 at 11:15:45AM -0000, Yusuf Goolamabbas wrote: > Hi, Similar to what Ceri describes in this message >=20 > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=3D508422+0+current/freebsd-s= t able >=20 > I have observed a 4.4-stable box panicing whenever bridging is turned > on. This was cvsup'ed today morning. I have other boxes cvsup'ed at > the same time except that they don't have dummynet/bridging configured > in them and they work pretty well >=20 > I replaced the box with an another 4.3-RC box and the same rules > enclosed here work just fine >=20 > ${fwcmd} add 100 pass all from any to any via lo0 > ${fwcmd} add 200 deny all from any to 127.0.0.0/8 > ${fwcmd} add 300 deny ip from 127.0.0.0/8 to any > # If you're using 'options BRIDGE', uncomment the following line to pass ARP > ${fwcmd} add 400 pass udp from 0.0.0.0 2054 to 0.0.0.0 > ${fwcmd} add 500 pass all from to any in via fxp0 > ${fwcmd} add 800 pipe 1 ip from to any in via fxp1 > ${fwcmd} pipe 1 config mask src-ip 0x000000ff bw 512Kbit/s queue 50=20 >=20 > Basically, fxp1 is connected to a switch and every machine on that > switch is rate limited to 512Kbit/s individually >=20 > I had configured the box with DDB but didn't have serial console so I > transcribed everything at the db> prompt >=20 > Fatal trap 12: page fault while in kernel mode > fault virtual address =3D 0xa4 > fault code =3D superviser read, page not present > instruction pointer =3D 0x8:0xc0199164 > strack pointer =3D 0x10:0xc9889b5c > frame pointer =3D 0x10:0xc9889bac > code segment =3D base 0x0, limit 0xfff type 0x1b > =3D DPL 0, pres 1, def32 1, gran 1 > processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > current process =3D 55 (sh) > interrupt mask =3D > kernel: type 12 trap, code =3D 0 > stopped at in_arpinput+0x158; movl 0xa4(%eax,%eax) >=20 > db> t > in_arpinput(c077cb00,0,c989cac,c020d625,c020d5df) at in_arpinput+0x158 > arpintr(c020dfdf,0,c02800,0,c7640010,c0e700,0) at arpintr+0x112 > swi_net_next(c028c26c,c764f000,3,0,c835c440) at swi_net_next > trap_pfault(c9889d20,0,c764f000,0,806c591) at trap_pfault+0xbe > trap(10,c9880010,c01d0010,c764f000,80be591_ at trap+0x31f > calltrap() at calltrap+0x11 > trap 0xc : eip - 0xc02172cf , esp - 0xc9889d60, ebp - 0xc9889d88 > copyinstr(c9889e68,0,0,c9889f80,c9889f80) at copyinstr+0x37 > exec_elf_imagact(c9889e68,c835c440,3,c9889f80,c9889e68) at exec_elf_imagact+0xba > execve(c835c440,c9889f80,80be5d4,0,80be590) at execve+0x26c > syscall2(2f,2f,2f,80be590,0) at syscall2+0x1a5 > Xinit0x80_syscall() + Xint-x80_syscall+0x25 >=20 > Hope this helps >=20 > Regards, Yusuf >=20 > --=20 > Yusuf Goolamabbas > yusufg@outblaze.com >=20 > 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-stable" 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 20 20: 4:34 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 2CDAF37B41A for ; Thu, 20 Dec 2001 20:04:31 -0800 (PST) Received: (qmail 4352 invoked from network); 21 Dec 2001 04:00:11 -0000 Received: from aworklan001038.netvigator.com (HELO yusufg.portal2.com) (203.198.151.38) by box.dhsnames.com with SMTP; 21 Dec 2001 04:00:11 -0000 Received: (qmail 10488 invoked by uid 500); 21 Dec 2001 04:02:15 -0000 Date: Fri, 21 Dec 2001 12:02:15 +0800 From: Yusuf Goolamabbas To: Luigi Rizzo Cc: freebsd-net@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG, cez@pkl.net Subject: Re: 4.4-stable kernel panic with dummynet/bridging. Same rules work fine with 4.3-RC Message-ID: <20011221120215.A10482@outblaze.com> References: <20011220111545.3327.qmail@yusufg.portal2.com> <20011220124859.A8969@iguana.aciri.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011220124859.A8969@iguana.aciri.org> 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 > I wonder if this isn't related to some change in the handling of > interface lists, routes or arp entries. I do not recall any recent > change in the dummynet/bridge code that might cause this. > > On passing. the line ${fwcmd} add 400 pass udp from 0.0.0.0 2054 to 0.0.0.0 > has not been supported for a long time. Shouldn't it be taken out of /etc/rc.firewall and an appropiate note sent to Warner for insertion in UPDATING > > How repeatable is the problem ? It shouldn't be hard to track, it looks > like a null pointer dereference. 100% repeatable. The strange part is that the same rules including the ${fwcmd} add 400 pass udp from 0.0.0.0 2054 to 0.0.0.0 work perfectly with 4.3-RC Regards, yusuf To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Dec 20 23: 8:26 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 A363A37B416; Thu, 20 Dec 2001 23:08:21 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.3/8.11.1) id fBL78Ex12615; Thu, 20 Dec 2001 23:08:14 -0800 (PST) (envelope-from rizzo) Date: Thu, 20 Dec 2001 23:08:14 -0800 From: Luigi Rizzo To: Yusuf Goolamabbas Cc: freebsd-net@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG, cez@pkl.net Subject: Re: 4.4-stable kernel panic with dummynet/bridging. Same rules work fine with 4.3-RC Message-ID: <20011220230814.A11342@iguana.aciri.org> References: <20011220111545.3327.qmail@yusufg.portal2.com> <20011220124859.A8969@iguana.aciri.org> <20011221120215.A10482@outblaze.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011221120215.A10482@outblaze.com> 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 Fri, Dec 21, 2001 at 12:02:15PM +0800, Yusuf Goolamabbas wrote: > > > > How repeatable is the problem ? It shouldn't be hard to track, it looks > > like a null pointer dereference. > > 100% repeatable. The strange part is that the same rules including the > ${fwcmd} add 400 pass udp from 0.0.0.0 2054 to 0.0.0.0 work perfectly > with 4.3-RC the rule is just useless. do you have a sample case to trigger the problem so i can try and see what is going on ? 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 Thu Dec 20 23:26:12 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 CD51437B416 for ; Thu, 20 Dec 2001 23:26:08 -0800 (PST) Received: (qmail 7111 invoked from network); 21 Dec 2001 07:21:47 -0000 Received: from aworklan001038.netvigator.com (HELO yusufg.portal2.com) (203.198.151.38) by box.dhsnames.com with SMTP; 21 Dec 2001 07:21:47 -0000 Received: (qmail 11780 invoked by uid 500); 21 Dec 2001 07:23:54 -0000 Date: Fri, 21 Dec 2001 15:23:54 +0800 From: Yusuf Goolamabbas To: Luigi Rizzo Cc: freebsd-net@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG, cez@pkl.net Subject: Re: 4.4-stable kernel panic with dummynet/bridging. Same rules work fine with 4.3-RC Message-ID: <20011221152354.A11744@outblaze.com> References: <20011220111545.3327.qmail@yusufg.portal2.com> <20011220124859.A8969@iguana.aciri.org> <20011221120215.A10482@outblaze.com> <20011220230814.A11342@iguana.aciri.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011220230814.A11342@iguana.aciri.org> 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 On Thu, Dec 20, 2001 at 11:08:14PM -0800, Luigi Rizzo wrote: > On Fri, Dec 21, 2001 at 12:02:15PM +0800, Yusuf Goolamabbas wrote: > > > > > > How repeatable is the problem ? It shouldn't be hard to track, it looks > > > like a null pointer dereference. > > > > 100% repeatable. The strange part is that the same rules including the > > ${fwcmd} add 400 pass udp from 0.0.0.0 2054 to 0.0.0.0 work perfectly > > with 4.3-RC > > the rule is just useless. do you have a sample case to trigger the > problem so i can try and see what is going on ? > range and office are edited out This is what I have, the basic idea is that fxp1 is connected to a switch and I want each machine on the switch to be restricted to 512kb/s ${fwcmd} add 100 pass all from any to any via lo0 ${fwcmd} add 200 deny all from any to 127.0.0.0/8 ${fwcmd} add 300 deny ip from 127.0.0.0/8 to any # If you're using 'options BRIDGE', uncomment the following line to pass ARP ${fwcmd} add 400 pass udp from 0.0.0.0 2054 to 0.0.0.0 ${fwcmd} add 500 pass all from ${range} to any in via fxp0 ${fwcmd} add 800 pipe 1 ip from ${range} to not ${office} in via fxp1 ${fwcmd} pipe 1 config mask src-ip 0x000000ff bw 512Kbit/s queue 50 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Dec 21 1:45: 6 2001 Delivered-To: freebsd-net@freebsd.org Received: from web9303.mail.yahoo.com (web9303.mail.yahoo.com [216.136.129.52]) by hub.freebsd.org (Postfix) with SMTP id 8428537B419 for ; Fri, 21 Dec 2001 01:45:03 -0800 (PST) Message-ID: <20011221094502.18144.qmail@web9303.mail.yahoo.com> Received: from [212.174.195.226] by web9303.mail.yahoo.com via HTTP; Fri, 21 Dec 2001 01:45:02 PST Date: Fri, 21 Dec 2001 01:45:02 -0800 (PST) From: Omer Faruk Sen Subject: current state of delayed_ack To: freebsd-questions@freebsd.org 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 Hi; I have read (I don't know where) that delayed ack has a problem in freebsd-stable and suggested to turn it off. But I had a situation that I can't connect to www.suse.com:80 (for example) but after enabling it I can connect to that site. Normally with delayed_ack turned off I am receiving Push flag set packet from server but then server (www.suse.com:80 in my case) send me R. I have the same problem with login.icq.com. My question is: Is the delayed_ack is still buggy in -STABLE? __________________________________________________ Do You Yahoo!? Check out Yahoo! Shopping and Yahoo! Auctions for all of your unique holiday gifts! Buy at http://shopping.yahoo.com or bid at http://auctions.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Dec 21 2:59:27 2001 Delivered-To: freebsd-net@freebsd.org Received: from smtp.www-service.de (smtp.www-service.de [212.77.161.16]) by hub.freebsd.org (Postfix) with SMTP id 0559E37B41A for ; Fri, 21 Dec 2001 02:59:23 -0800 (PST) Received: (qmail 15272 invoked from network); 21 Dec 2001 10:59:09 -0000 Received: from pd95033b5.dip.t-dialin.net (HELO fw.tue.le) (217.80.51.181) by smtp.www-service.de with SMTP; 21 Dec 2001 10:59:09 -0000 Received: from mezcal.tue.le (mezcal.tue.le [192.168.201.20]) by fw.tue.le (8.8.8/8.8.8) with ESMTP id LAA09154; Fri, 21 Dec 2001 11:58:51 +0100 (CET) (envelope-from thz@mezcal.tue.le) Received: (from thz@localhost) by mezcal.tue.le (8.11.6/8.11.6) id fBLAwpw10249; Fri, 21 Dec 2001 11:58:51 +0100 (CET) (envelope-from thz) Date: Fri, 21 Dec 2001 11:58:51 +0100 From: Thomas Zenker To: Mike Silbersack Cc: freebsd-net@freebsd.org Subject: Re: USB ethernet problem Message-ID: <20011221115851.A10172@mezcal.tue.le> Mail-Followup-To: Mike Silbersack , freebsd-net@freebsd.org References: <20011217090920.A763@mezcal.tue.le> <20011217143503.A16555@mezcal.tue.le> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011217143503.A16555@mezcal.tue.le>; from thz@Lennartz-electronic.de on Mon, Dec 17, 2001 at 02:35:03PM +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 Mon, Dec 17, 2001 at 02:35:03PM +0100, Thomas Zenker wrote: > On Mon, Dec 17, 2001 at 03:20:51AM -0500, Mike Silbersack wrote: > .. deleted > > > > RFC 2581 suggests that 4 is a good value (well, not exactly 4, they have a > > formula which comes out to about 4 in most cases.) I'm inclined to agree > > that something between 2-4 would be a good value for our non-local > > slowstart flightsize as well. Maybe after 4.5 is released we can go look > > into it. (It's too late to be changing stuff now.) > > > > Mike "Silby" Silbersack > > just to remind ourselfs why this thread came up > (i myself had nearly forgotten about it :-): > > for the instruments, we produce and which run FreeBSD embedded, I > was doing an installation/upgrade package for our production here. > The install is done via USB/ethernet adaptor. Because of the change > to recvspace lately (now 65536) the USB/ethernet adaptor (or the > switch, not sure) is overrun and resulting installation speed drops > to unacceptible 10KB/s. It is not a problem for me, because I can > manipulate per sysctl recvspace in my package. But it may become a > problem for people which want to install FreeBSD 4.5 over USB/ethernet > with the normal sysinstall (for example laptop users). AFAIK there is > no knob if you boot from floppy. > to follow up myself :-( the situation changed, I have tried to install the new release now on the final embedded hardware. It is to mention, that this hardware is working with fbsd 4.3 from july without any problems in about 50 equipments. Upgrade from the previous fbsd 4.3 works flawlessly (4.3 kernel is running during this procedure), however after rebooting the 4.4 kernel, another upgrade run doesn't terminate: usb0: host controller process error usb0: host controller halted kue0: watchdog timeout kue0: watchdog timeout kue0: usb error on tx: TIMEOUT kue0: watchdog timeout kue0: watchdog timeout kue0: usb error on tx: TIMEOUT kue0: watchdog timeout and the machine hangs.... Tried to narrow the send/recv space without success. ttcp tests run without problems. Also tried the big read/write sizes, sysinstall uses. The difference in the run of sysinstall and ttcp is the heavy disk activity with sysinstall. There was no significant change in the USB driver since 2001-07-17. Might there be a run condition, interrupt problem or priority problem with the ata driver, which become visible now on the slower machine? May be I have to go back to fbsd 4.3 Thomas -- Thomas Zenker c/o Lennartz electronic GmbH Bismarckstrasse 136, D-72072 Tuebingen, Germany Phone: +49-(0)7071-93550 Email: thz@lennartz-electronic.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Dec 21 6:27:43 2001 Delivered-To: freebsd-net@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id AA98137B41B; Fri, 21 Dec 2001 06:27:34 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id BAA08565; Sat, 22 Dec 2001 01:27:29 +1100 Date: Sat, 22 Dec 2001 01:27:32 +1100 (EST) From: Bruce Evans X-X-Sender: To: Alfred Perlstein Cc: , , , Subject: Re: fifo fix (Re: cvs commit: src/sys/fs/fifofs fifo_vnops.c) In-Reply-To: <20011218111531.A59831@elvis.mu.org> Message-ID: <20011222011614.C4869-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, 18 Dec 2001, Alfred Perlstein wrote: > > * Bruce Evans [011217 07:10] wrote: > > > I'm not happy with frobbing the socket state. I suggest frobbing the > > > events mask instead. Either use a flag to tell sopoll() to ignore > > > SS_CANTRCVMORE, or use new events POLLIN_IGNORE_EOF and > > > POLLRDNORM_IGNORE_EOF (convert the userland POLLIN/POLLRDNORM to these > > > and change sopoll() to support them). > > Wait, please clarify, are you suggesting that POLLIN_IGNORE_EOF > and POLLRDNORM_IGNORE_EOF must be used by userland applications? > Or would it be an internal flag for the kernel so that here you'd > see something like: > > filetmp.f_data = (caddr_t)ap->a_vp->v_fifoinfo->fi_readsock; > if (filetmp.f_data) { > if (ap->a_events & ~POLLIN) > ap->a_events |= POLLIN_IGNORE_EOF; I think it should be more like: if (ap->a_events & POLLIN) ap->a_events = (ap->a_events & ~POLLIN) | POLLIN_IGNORE_EOF; We can't pass in flags that we don't really care about (POLLIN in this case) since they will cause side effects (selrecord()...). I might actually use a new variable instead of changing `ap'. > /* same for POLLRDNORM */ > revents |= soo_poll(&filetmp, ap->a_events, ap->a_cred, > ap->a_td); Add something like: if (revents & POLLIN_IGNORE_EOF) revents = (revents & ~POLLIN_IGNORE_EOF) | POLLIN; > } > > Or that the userland will just OR in POLLIN_IGNORE_EOF before calling > poll(2). > > I'm not sure if I like the latter way of fixing things. Userland might want to do this someday. I would just make it easy for it to do so. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Dec 21 7:36:43 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 0764637B405 for ; Fri, 21 Dec 2001 07:36:40 -0800 (PST) Received: from mira-sjc5-2.cisco.com (mira-sjc5-2.cisco.com [171.71.163.16]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id fBLFaQx19663; Fri, 21 Dec 2001 07:36:26 -0800 (PST) Received: from stewart.chicago.il.us (ssh-sj1.cisco.com [171.68.225.134]) by mira-sjc5-2.cisco.com (Mirapoint) with ESMTP id AAP04744; Fri, 21 Dec 2001 07:36:24 -0800 (PST) Message-ID: <3C2356F9.5A160A5@stewart.chicago.il.us> Date: Fri, 21 Dec 2001 09:36:25 -0600 From: Randall Stewart X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: net@FreeBSD.ORG Cc: Marco Molteni , romain@cuivre.fr.eu.org Subject: Re: SCTP References: <20011211190756.A52248@gargantua.dyndns.org> <20011211194248.A54901@gargantua.dyndns.org> <20011212134941.A4544@cobweb.example.org> 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: Sorry for the delay in responding my head is deep into getting this thing out the door :> Yes, we are very very close... currently I am looking at some final testing of a few features and then we have a decision to make... your input would be nice ... 1) We have the UDP model mostly completed (draft-ietf-tsvwg-sctpsocket-02.txt) and have just begun the work on the TCP model (note I say mostly because we do have a few minor tweaks to do before we can be 100% there). 2) We are thinking we will need about an additional month or two to get the TCP model in as well. This leaves us with a choice. Release the code we have now after integrating to the current KAME release (we are working with a kame snap right now). Then in a month or two release a update that includes the TCP model. Or hold off and wait for a couple of months and release it all at once. Your opinions would be most welcome on how you'all would like to see it.. By the way, if anyone wants a private release let me know and I can send it to you.. Regards R Marco Molteni wrote: > > 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 -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Dec 21 7:42:32 2001 Delivered-To: freebsd-net@freebsd.org Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by hub.freebsd.org (Postfix) with ESMTP id 9B90637B405 for ; Fri, 21 Dec 2001 07:42:30 -0800 (PST) Received: from mira-sjc5-2.cisco.com (mira-sjc5-2.cisco.com [171.71.163.16]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id fBLFgUY19019 for ; Fri, 21 Dec 2001 07:42:30 -0800 (PST) Received: from stewart.chicago.il.us (ssh-sj1.cisco.com [171.68.225.134]) by mira-sjc5-2.cisco.com (Mirapoint) with ESMTP id AAP04834; Fri, 21 Dec 2001 07:42:29 -0800 (PST) Message-ID: <3C235866.B063CC7B@stewart.chicago.il.us> Date: Fri, 21 Dec 2001 09:42:30 -0600 From: Randall Stewart X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: net@freebsd.org Subject: m_reclaim and a protocol drain 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 have a question. I have been working to test the new sctp_drain function I am adding and have had a very difficult time getting the drain function to be called by the mbuf system... Now here is what I most observe from some of the test cases I am building: A) All inbound packets get a cluster down in the driver routine. B) There is a much smaller limit to clusters C) The cluster allocation routine will NOT call reclaim() et.al. D) Of course since the lower drivers are allocating M_DONTWAIT even if they did I would not get the routine called. Now this brings to light a weakness in my mind on the reclaim system. 1) One of the primary things I thought the drain() functions help with is to ward off DOS attacks. 2) If drivers all use clusters only and clusters can never call a drain() function, does this not leave both TCP and SCTP weak against an attack on the cluster side of the MBUF system? 3) I can see if we are out of mbufs eventually something sending down will do a mget(..) with a M_WAIT which can spawn the drains should we not have something like this for a cluster allocation?? If we don't it seems to me the utility of the drain() fucnction is very very limited.. Regards R -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Dec 21 10:35:44 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 C54CC37B436 for ; Fri, 21 Dec 2001 10:35:37 -0800 (PST) Received: (qmail 58053 invoked by uid 3193); 21 Dec 2001 18:35:36 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 21 Dec 2001 18:35:36 -0000 Date: Fri, 21 Dec 2001 13:35:36 -0500 (EST) From: Mike Silbersack X-Sender: To: Thomas Zenker Cc: Subject: Re: USB ethernet problem In-Reply-To: <20011221115851.A10172@mezcal.tue.le> 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 Fri, 21 Dec 2001, Thomas Zenker wrote: > to follow up myself :-( > > the situation changed, I have tried to install the new release now > on the final embedded hardware. It is to mention, that this hardware > is working with fbsd 4.3 from july without any problems in about > 50 equipments. Upgrade from the previous fbsd 4.3 works flawlessly > (4.3 kernel is running during this procedure), however after rebooting > the 4.4 kernel, another upgrade run doesn't terminate: > > kue0: usb error on tx: TIMEOUT > kue0: watchdog timeout > > The difference in the run of sysinstall and ttcp is the heavy disk > activity with sysinstall. > > There was no significant change in the USB driver since 2001-07-17. > > Might there be a run condition, interrupt problem or priority problem > with the ata driver, which become visible now on the slower machine? > > May be I have to go back to fbsd 4.3 Hmm. I agree, it doesn't like like much of anything usb-related changed between 4.3 and now. If we examine the ata driver, one big thing changed between 4.3 and 4.4: Write caching was re-enabled. This caused a big change in disk throughput for some people, perhaps it's affecting you. Try turning it off (see the ata manpage for details) and see if that changes your results. Also, is your USB adapter sharing interrupts with anything else? Are interrupts being allocated the same way on 4.3 and 4.4? Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Dec 21 10:41:43 2001 Delivered-To: freebsd-net@freebsd.org Received: from technokratis.com (modemcable099.144-201-24.mtl.mc.videotron.ca [24.201.144.99]) by hub.freebsd.org (Postfix) with ESMTP id 33FE337B419 for ; Fri, 21 Dec 2001 10:41:34 -0800 (PST) Received: (from bmilekic@localhost) by technokratis.com (8.11.4/8.11.3) id fBLIh7w69266; Fri, 21 Dec 2001 13:43:07 -0500 (EST) (envelope-from bmilekic) Date: Fri, 21 Dec 2001 13:43:07 -0500 From: Bosko Milekic To: Randall Stewart Cc: net@FreeBSD.ORG Subject: Re: m_reclaim and a protocol drain Message-ID: <20011221134307.A69233@technokratis.com> References: <3C235866.B063CC7B@stewart.chicago.il.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C235866.B063CC7B@stewart.chicago.il.us>; from randall@stewart.chicago.il.us on Fri, Dec 21, 2001 at 09:42:30AM -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 On Fri, Dec 21, 2001 at 09:42:30AM -0600, Randall Stewart wrote: > Hi all: > > I have a question. I have been working to test the new > sctp_drain function I am adding and have had a very difficult > time getting the drain function to be called by the mbuf system... > > Now here is what I most observe from some of the test cases > I am building: > > A) All inbound packets get a cluster down in the driver routine. > B) There is a much smaller limit to clusters > C) The cluster allocation routine will NOT call reclaim() et.al. This has changed in -CURRENT and it should be easy to change -STABLE to do the same. -CURRENT now drains the protocols in the cluster starvation case too. > D) Of course since the lower drivers are allocating M_DONTWAIT > even if they did I would not get the routine called. > > Now this brings to light a weakness in my mind on the reclaim > system. > > 1) One of the primary things I thought the drain() functions > help with is to ward off DOS attacks. Well, no, not really. They're just there to `help' out in any starvation case, really. > 2) If drivers all use clusters only and clusters can never > call a drain() function, does this not leave both TCP and > SCTP weak against an attack on the cluster side of the MBUF > system? Well, firstly, all clusters are accompanied by mbufs. Secondly, as mentionned above, -CURRENT drains in both cases. > 3) I can see if we are out of mbufs eventually something sending > down will do a mget(..) with a M_WAIT which can spawn the drains > should we not have something like this for a cluster allocation?? There's no way we can have M_DONTWAIT allocations possibly drain the protocols. It would be way too much time for an M_DONTWAIT allocation, especially in light of where we may be going with this in the future (i.e. processing some packets from interrupt context - perhaps). What I think you should do in your code is make the calls with M_TRYWAIT (what you call M_WAIT) wherever they are possible and only call with M_DONTWAIT where it's really not possible to wait. The M_TRYWAIT flag does not imply "run slower than M_DONTWAIT," it just means "try harder even if it takes a little longer, since we are able to block." > If we don't it seems to me the utility of the drain() fucnction is > very very limited.. > > Regards > > R > > -- > Randall R. Stewart > randall@stewart.chicago.il.us 815-342-5222 (cell phone) -- Bosko Milekic bmilekic@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Dec 21 10:44:22 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 50F1937B417; Fri, 21 Dec 2001 10:44:17 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id E85CE81E0F; Fri, 21 Dec 2001 12:44:16 -0600 (CST) Date: Fri, 21 Dec 2001 12:44:16 -0600 From: Alfred Perlstein To: Bruce Evans Cc: wollman@FreeBSD.org, net@FreeBSD.org, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: fifo fix (Re: cvs commit: src/sys/fs/fifofs fifo_vnops.c) Message-ID: <20011221124416.T48837@elvis.mu.org> References: <20011218111531.A59831@elvis.mu.org> <20011222011614.C4869-100000@gamplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011222011614.C4869-100000@gamplex.bde.org>; from bde@zeta.org.au on Sat, Dec 22, 2001 at 01:27:32AM +1100 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 * Bruce Evans [011221 08:27] wrote: > > I think it should be more like: > > if (ap->a_events & POLLIN) > ap->a_events = (ap->a_events & ~POLLIN) | POLLIN_IGNORE_EOF; > > We can't pass in flags that we don't really care about (POLLIN in > this case) since they will cause side effects (selrecord()...). > > I might actually use a new variable instead of changing `ap'. Ok, I'll get this working on my way up to Tahoe. :) Thanks for the advice. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Dec 21 11: 7:40 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 B238637B405 for ; Fri, 21 Dec 2001 11:07:31 -0800 (PST) Received: from trotski.freesurf.fr (trotski.freesurf.fr [212.43.206.9]) by charentes.fr.clara.net (Postfix) with ESMTP id 20B1259F34; Fri, 21 Dec 2001 20:06:59 +0100 (CET) Received: from gargantua.dyndns.org (du-198-12.nat.dialup.freesurf.fr [212.43.198.12]) by trotski.freesurf.fr (Postfix) with ESMTP id A48769B06; Fri, 21 Dec 2001 20:06:57 +0100 (CET) Received: (from romain@localhost) by gargantua.dyndns.org (8.11.6/8.11.6) id fBLJ5xh02673; Fri, 21 Dec 2001 20:05:59 +0100 (CET) (envelope-from romain) Date: Fri, 21 Dec 2001 20:05:58 +0100 From: Romain Berrendonner To: Randall Stewart Cc: net@FreeBSD.ORG, Marco Molteni Subject: Re: SCTP Message-ID: <20011221200557.A2459@gargantua.dyndns.org> Reply-To: romain@cuivre.fr.eu.org References: <20011211190756.A52248@gargantua.dyndns.org> <20011211194248.A54901@gargantua.dyndns.org> <20011212134941.A4544@cobweb.example.org> <3C2356F9.5A160A5@stewart.chicago.il.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C2356F9.5A160A5@stewart.chicago.il.us>; from randall@stewart.chicago.il.us on Fri, Dec 21, 2001 at 09:36:25AM -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 Le 2001-12-21 09:36 UTC-0600, Randall Stewart a ecrit: > > Yes, we are very very close... currently I am looking at > some final testing of a few features and then we have > a decision to make... your input would be nice ... > I hope I'll have some more time to take a look at this while on vacation. Is there any testbed somewhere on the internet ? > 1) We have the UDP model mostly completed > (draft-ietf-tsvwg-sctpsocket-02.txt) and > have just begun the work on the TCP model (note I say mostly because > we > do have a few minor tweaks to do before we can be 100% there). > > 2) We are thinking we will need about an additional month or two to get > the TCP model in as well. I believed that SCTP was a protocol on its own, aside TCP an UDP. Do you mean you are implementing the semantics of SCTP over UDP or TCP ? Anyway, I also have to look at the I-D. Regards, -romain -- 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 Fri Dec 21 13: 8:17 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 58BDC37B416 for ; Fri, 21 Dec 2001 13:08:10 -0800 (PST) Received: from mira-sjc5-2.cisco.com (mira-sjc5-2.cisco.com [171.71.163.16]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id fBLL81109221; Fri, 21 Dec 2001 13:08:01 -0800 (PST) Received: from stewart.chicago.il.us (ssh-sj1.cisco.com [171.68.225.134]) by mira-sjc5-2.cisco.com (Mirapoint) with ESMTP id AAP14412; Fri, 21 Dec 2001 13:07:54 -0800 (PST) Message-ID: <3C23A4A6.9EC2D921@stewart.chicago.il.us> Date: Fri, 21 Dec 2001 15:07:50 -0600 From: Randall Stewart X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Jim Fleming Cc: net@FreeBSD.ORG, Marco Molteni , romain@cuivre.fr.eu.org Subject: Re: SCTP References: <20011211190756.A52248@gargantua.dyndns.org> <20011211194248.A54901@gargantua.dyndns.org> <20011212134941.A4544@cobweb.example.org> <3C2356F9.5A160A5@stewart.chicago.il.us> <010801c18a39$7eb75e80$1000a8c0@Unir.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Jim: Comments below :> Jim Fleming wrote: > > Thanks for the reply. Here are a couple of comments. > > We can only fit ICMP, UDP and TCP in IPv4++ > Does SCTP run inside UDP ? > http://www.dot-biz.com/IPv4/Tutorial/ > http://www.RepliGate.net > No, SCTP is IP protocol number 132 (if I remember right). It is a multi-streaming protocol that gets rid of the TCP H-O-L blocking issue. For more details you can check out the following: RFC2960 or Stream Control Transmission Protocol (SCTP) a reference guide Publisher addison/wesley > Also, the Unir Project and Virtual Personal Computer (VPC) > uses a concept called Wide-Pipes. It runs in TCP. Those > are 16-bit wide pipes where each byte has a stream number. > It was the cover story in Dr. Dobb's Journal, #88, February 1984 > for those that reference prior art. > > The Netfilter Project: Packet Mangling for Linux 2.4 > http://netfilter.samba.org > http://www.IPv8.info > IPv16....One Better !! > > Jim Fleming > http://www.ddj.com/articles/search/search.cgi?q=fleming > Oct93: The C+@ Programming Language > > ----- Original Message ----- > From: "Randall Stewart" > To: > Cc: "Marco Molteni" ; > Sent: Friday, December 21, 2001 9:36 AM > Subject: Re: SCTP > > > Hi all: > > > > Sorry for the delay in responding my head is deep into > > getting this thing out the door :> > > > > Yes, we are very very close... currently I am looking at > > some final testing of a few features and then we have > > a decision to make... your input would be nice ... > > > > 1) We have the UDP model mostly completed > > (draft-ietf-tsvwg-sctpsocket-02.txt) and > > have just begun the work on the TCP model (note I say mostly because > > we > > do have a few minor tweaks to do before we can be 100% there). > > > > 2) We are thinking we will need about an additional month or two to get > > the TCP model in as well. > > > > > > This leaves us with a choice. Release the code we have now after > > integrating to the current KAME release (we are working with a > > kame snap right now). Then in a month or two release a update > > that includes the TCP model. Or hold off and wait for a couple > > of months and release it all at once. > > > > Your opinions would be most welcome on how you'all would like > > to see it.. > > > > By the way, if anyone wants a private release let me know and > > I can send it to you.. > > > > > > Regards > > > > R > > > > Marco Molteni wrote: > > > > > > 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 > > > > -- > > Randall R. Stewart > > randall@stewart.chicago.il.us 815-342-5222 (cell phone) > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-net" in the body of the message > > -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Dec 21 13:12:47 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 B488737B405 for ; Fri, 21 Dec 2001 13:12:41 -0800 (PST) Received: from mira-sjc5-2.cisco.com (mira-sjc5-2.cisco.com [171.71.163.16]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id fBLLCZx04783; Fri, 21 Dec 2001 13:12:39 -0800 (PST) Received: from stewart.chicago.il.us (ssh-sj1.cisco.com [171.68.225.134]) by mira-sjc5-2.cisco.com (Mirapoint) with ESMTP id AAP14504; Fri, 21 Dec 2001 13:12:33 -0800 (PST) Message-ID: <3C23A5C2.CB4A5C0B@stewart.chicago.il.us> Date: Fri, 21 Dec 2001 15:12:34 -0600 From: Randall Stewart X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: romain@cuivre.fr.eu.org Cc: net@FreeBSD.ORG, Marco Molteni Subject: Re: SCTP References: <20011211190756.A52248@gargantua.dyndns.org> <20011211194248.A54901@gargantua.dyndns.org> <20011212134941.A4544@cobweb.example.org> <3C2356F9.5A160A5@stewart.chicago.il.us> <20011221200557.A2459@gargantua.dyndns.org> 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 Romain Berrendonner wrote: > > Le 2001-12-21 09:36 UTC-0600, Randall Stewart a ecrit: > > > > Yes, we are very very close... currently I am looking at > > some final testing of a few features and then we have > > a decision to make... your input would be nice ... > > > > I hope I'll have some more time to take a look at this while > on vacation. Is there any testbed somewhere on the internet ? > I believe you can test (with pre-arrangment) with some folks at the University of Essen. We also are trying to get together a 4th bake-off at Connect-a-thon as well as a fifth in June at the U-of-Essen in Germany. I can also (if you have an implementation) test with you as long as you can talk IPv6. > > 1) We have the UDP model mostly completed > > (draft-ietf-tsvwg-sctpsocket-02.txt) and > > have just begun the work on the TCP model (note I say mostly because > > we > > do have a few minor tweaks to do before we can be 100% there). > > > > 2) We are thinking we will need about an additional month or two to get > > the TCP model in as well. > > I believed that SCTP was a protocol on its own, aside TCP an UDP. > Do you mean you are implementing the semantics of SCTP over UDP or TCP ? > Anyway, I also have to look at the I-D. The I-D allows either a TCP or UDP flavor interface. We started with implementing the UDP flavor but will support both interfaces when we are finished.. R > > Regards, -romain > -- > 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 -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Dec 22 11:14:53 2001 Delivered-To: freebsd-net@freebsd.org Received: from comp.chem.msu.su (comp-ext.chem.msu.su [158.250.32.157]) by hub.freebsd.org (Postfix) with ESMTP id 405CB37B41A; Sat, 22 Dec 2001 11:14:14 -0800 (PST) Received: (from yar@localhost) by comp.chem.msu.su (8.11.1/8.11.1) id fBLGCLQ30942; Fri, 21 Dec 2001 19:12:21 +0300 (MSK) (envelope-from yar) Date: Fri, 21 Dec 2001 19:12:21 +0300 From: Yar Tikhiy To: Maxim Konovalov Cc: net@FreeBSD.org, hackers@FreeBSD.org Subject: Re: IP options (was: Processing IP options reveals IPSTEALH router) Message-ID: <20011221191221.C25868@comp.chem.msu.su> References: <20011220003555.A52848@comp.chem.msu.su> <20011220011255.G79558-100000@news1.macomnet.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011220011255.G79558-100000@news1.macomnet.ru>; from maxim@macomnet.ru on Thu, Dec 20, 2001 at 01:24:48AM +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 Thu, Dec 20, 2001 at 01:24:48AM +0300, Maxim Konovalov wrote: > > > Neither RFC 791 nor RFC 1122 nor RFC 1812 specify the following: > > if a source-routed IP packet reachs the end of its route, but its > > destination address doesn't match a current host/router, whether > > the packet should be discarded, sent forth through usual routing > > or accepted as destined for this host? FreeBSD will route such a > > packet as usual. > > Stevens, TCP Ill. vII, p.257 says: > > "If the destination address of the packet does not match one of the > local addresses and the option is a strict source routing > (IPOPT_SSRR), an ICMP source route failure error is sent. If a local > address isn't listed in the route, the previous system sent the packet > to the wrong host. This isn't an error for a loose source route > (IPOPT_LSRR); it means IP must forward the packet toward the > destionation." > > That is what ip_input does near the line 1193. Oops, it appeared that I misunderstood the way the source route record worked. FreeBSD does it right, except for a host (ipforwarding=0) replying with error ICMP on some source route attempts. What about the following small change? --- /usr/src/sys/netinet.orig/ip_input.c Fri Dec 7 00:54:48 2001 +++ netinet/ip_input.c Fri Dec 21 19:08:56 2001 @@ -1212,13 +1212,13 @@ ia = (struct in_ifaddr *) ifa_ifwithaddr((struct sockaddr *)&ipaddr); if (ia == 0) { + if (!ip_dosourceroute) + goto nosourcerouting; if (opt == IPOPT_SSRR) { type = ICMP_UNREACH; code = ICMP_UNREACH_SRCFAIL; goto bad; } - if (!ip_dosourceroute) - goto nosourcerouting; /* * Loose routing, and not at next destination * yet; nothing to do except forward. @@ -1231,18 +1231,19 @@ * End of source route. Should be for us. */ if (!ip_acceptsourceroute) - goto nosourcerouting; + goto logandsendicmp; save_rte(cp, ip->ip_src); break; } if (!ip_dosourceroute) { +nosourcerouting: if (ipforwarding) { char buf[16]; /* aaa.bbb.ccc.ddd\0 */ /* * Acting as a router, so generate ICMP */ -nosourcerouting: +logandsendicmp: strcpy(buf, inet_ntoa(ip->ip_dst)); log(LOG_WARNING, "attempted source route from %s to %s\n", -- Yar To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Dec 22 11:15:15 2001 Delivered-To: freebsd-net@freebsd.org Received: from comp.chem.msu.su (comp-ext.chem.msu.su [158.250.32.157]) by hub.freebsd.org (Postfix) with ESMTP id 5529F37B41E; Sat, 22 Dec 2001 11:14:22 -0800 (PST) Received: (from yar@localhost) by comp.chem.msu.su (8.11.1/8.11.1) id fBLFpJR28804; Fri, 21 Dec 2001 18:51:19 +0300 (MSK) (envelope-from yar) Date: Fri, 21 Dec 2001 18:51:18 +0300 From: Yar Tikhiy To: Maxim Konovalov Cc: net@FreeBSD.org, hackers@FreeBSD.org Subject: Re: Processing IP options reveals IPSTEALH router Message-ID: <20011221185118.B25868@comp.chem.msu.su> References: <20011219194903.D21732@comp.chem.msu.su> <20011219195659.G25693-100000@news1.macomnet.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011219195659.G25693-100000@news1.macomnet.ru>; from maxim@macomnet.ru on Wed, Dec 19, 2001 at 08:54:50PM +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 Wed, Dec 19, 2001 at 08:54:50PM +0300, Maxim Konovalov wrote: > On 19:49+0300, Dec 19, 2001, Yar Tikhiy wrote: > > > As for source routing, I believe a stealthy router should just drop > > such packets as though it were a host. Of course, source-routed > > packets destined for the router itself should be accepted. > > So there are three IPSTEALTH cases: > > 1/ the dst address is not ours, net.inet.ip.sourceroute=0, > net.inet.ip.forwarding=1: process ip options by ip_dooptions(). > > 2/ the dst address is ours: process ip options by ip_dooptions(), > > 3/ in other cases do not process ip options. I made a patch that adds the "stealthy IP options feature". Honestly, now I'm afraid it's "much ado about nothing", given how clumsy solution is needed for such a small problem. Even the way of ignoring IP options completely when doing IPSTEALTH looks way better... -- Yar P.S. Here's the patch: --- ip_input.c.orig Fri Dec 7 00:54:48 2001 +++ ip_input.c Fri Dec 21 17:59:22 2001 @@ -211,7 +211,7 @@ struct sockaddr_in *ip_fw_fwd_addr; static void save_rte __P((u_char *, struct in_addr)); -static int ip_dooptions __P((struct mbuf *)); +static int ip_dooptions __P((struct mbuf *, int)); static void ip_forward __P((struct mbuf *, int)); static void ip_freef __P((struct ipqhead *, struct ipq *)); #ifdef IPDIVERT @@ -499,7 +499,7 @@ * to be sent and the original packet to be freed). */ ip_nhops = 0; /* for source routed packets */ - if (hlen > sizeof (struct ip) && ip_dooptions(m)) { + if (hlen > sizeof (struct ip) && ip_dooptions(m, 0)) { #ifdef IPFIREWALL_FORWARD ip_fw_fwd_addr = NULL; #endif @@ -657,6 +657,19 @@ return; ours: +#ifdef IPSTEALTH + /* + * IPSTEALTH: Process non-routing options only + * if the packet is destined for us. + */ + if (ipstealth && hlen > sizeof (struct ip) && ip_dooptions(m, 1)) { +#ifdef IPFIREWALL_FORWARD + ip_fw_fwd_addr = NULL; +#endif + return; + } +#endif /* IPSTEALTH */ + /* Count the packet in the ip address stats */ if (ia != NULL) { ia->ia_ifa.if_ipackets++; @@ -1150,12 +1163,18 @@ * Do option processing on a datagram, * possibly discarding it if bad options are encountered, * or forwarding it if source-routed. + * The pass argument is used when operating in the IPSTEALTH + * mode to tell what options to process: + * [LS]SRR (pass 0) or the others (pass 1). + * The reason for as many as two passes is that non-routing options + * must not be processed if the packet isn't for us when doing IPSTEALH. * Returns 1 if packet has been forwarded/freed, * 0 if the packet should be processed further. */ static int -ip_dooptions(m) +ip_dooptions(m, pass) struct mbuf *m; + int pass; { register struct ip *ip = mtod(m, struct ip *); register u_char *cp; @@ -1200,6 +1219,10 @@ */ case IPOPT_LSRR: case IPOPT_SSRR: +#ifdef IPSTEALTH + if (ipstealth && pass > 0) + break; +#endif if (optlen < IPOPT_OFFSET + sizeof(*cp)) { code = &cp[IPOPT_OLEN] - (u_char *)ip; goto bad; @@ -1235,7 +1258,10 @@ save_rte(cp, ip->ip_src); break; } - +#ifdef IPSTEALTH + if (ipstealth) + goto dropit; +#endif if (!ip_dosourceroute) { if (ipforwarding) { char buf[16]; /* aaa.bbb.ccc.ddd\0 */ @@ -1254,6 +1280,9 @@ /* * Not acting as a router, so silently drop. */ +#ifdef IPSTEALTH +dropit: +#endif ipstat.ips_cantforward++; m_freem(m); return (1); @@ -1289,6 +1318,10 @@ break; case IPOPT_RR: +#ifdef IPSTEALTH + if (ipstealth && pass == 0) + break; +#endif if (optlen < IPOPT_OFFSET + sizeof(*cp)) { code = &cp[IPOPT_OFFSET] - (u_char *)ip; goto bad; @@ -1322,6 +1355,10 @@ break; case IPOPT_TS: +#ifdef IPSTEALTH + if (ipstealth && pass == 0) + break; +#endif code = cp - (u_char *)ip; if (optlen < 4 || optlen > 40) { code = &cp[IPOPT_OLEN] - (u_char *)ip; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Dec 22 13: 3:34 2001 Delivered-To: freebsd-net@freebsd.org Received: from relay1.macomnet.ru (relay1.macomnet.ru [195.128.64.10]) by hub.freebsd.org (Postfix) with ESMTP id 30EDF37B416; Sat, 22 Dec 2001 13:03:22 -0800 (PST) Received: from news1.macomnet.ru (maxim@news1.macomnet.ru [195.128.64.14]) by relay1.macomnet.ru (8.11.3/8.11.3) with ESMTP id fBML3KY3182064; Sun, 23 Dec 2001 00:03:20 +0300 (MSK) Date: Sun, 23 Dec 2001 00:03:20 +0300 (MSK) From: Maxim Konovalov To: Yar Tikhiy Cc: net@FreeBSD.ORG, Subject: Re: IP options (was: Processing IP options reveals IPSTEALH router) In-Reply-To: <20011221191221.C25868@comp.chem.msu.su> Message-ID: <20011222235149.S26298-100000@news1.macomnet.ru> 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 Hi, Yar, On 19:12+0300, Dec 21, 2001, Yar Tikhiy wrote: > On Thu, Dec 20, 2001 at 01:24:48AM +0300, Maxim Konovalov wrote: > > > > > Neither RFC 791 nor RFC 1122 nor RFC 1812 specify the following: > > > if a source-routed IP packet reachs the end of its route, but its > > > destination address doesn't match a current host/router, whether > > > the packet should be discarded, sent forth through usual routing > > > or accepted as destined for this host? FreeBSD will route such a > > > packet as usual. > > > > Stevens, TCP Ill. vII, p.257 says: > > > > "If the destination address of the packet does not match one of the > > local addresses and the option is a strict source routing > > (IPOPT_SSRR), an ICMP source route failure error is sent. If a local > > address isn't listed in the route, the previous system sent the packet > > to the wrong host. This isn't an error for a loose source route > > (IPOPT_LSRR); it means IP must forward the packet toward the > > destionation." > > > > That is what ip_input does near the line 1193. > > Oops, it appeared that I misunderstood the way the source route > record worked. FreeBSD does it right, except for a host (ipforwarding=0) > replying with error ICMP on some source route attempts. > What about the following small change? > > --- /usr/src/sys/netinet.orig/ip_input.c Fri Dec 7 00:54:48 2001 > +++ netinet/ip_input.c Fri Dec 21 19:08:56 2001 > @@ -1212,13 +1212,13 @@ > ia = (struct in_ifaddr *) > ifa_ifwithaddr((struct sockaddr *)&ipaddr); > if (ia == 0) { > + if (!ip_dosourceroute) > + goto nosourcerouting; Nice catch. > if (opt == IPOPT_SSRR) { > type = ICMP_UNREACH; > code = ICMP_UNREACH_SRCFAIL; > goto bad; > } > - if (!ip_dosourceroute) > - goto nosourcerouting; > /* > * Loose routing, and not at next destination > * yet; nothing to do except forward. > @@ -1231,18 +1231,19 @@ > * End of source route. Should be for us. > */ > if (!ip_acceptsourceroute) > - goto nosourcerouting; > + goto logandsendicmp; > save_rte(cp, ip->ip_src); > break; > } > > if (!ip_dosourceroute) { > +nosourcerouting: I do not agree here. As far as I understand when we recieve a SSRR packet and there are no our addresses in the source routing addresses list we have to send ICPM_UNREACH to the sender regardless of net.inet.ip.forwarding. > if (ipforwarding) { > char buf[16]; /* aaa.bbb.ccc.ddd\0 */ > /* > * Acting as a router, so generate ICMP > */ > -nosourcerouting: > +logandsendicmp: > strcpy(buf, inet_ntoa(ip->ip_dst)); > log(LOG_WARNING, > "attempted source route from %s to %s\n", > > Btw, there are many compares like cnt < IPOPT_OLEN + sizeof(*cp) in ip_doiptions(). IMHO more strict to compare agains IPOPT_MIN because multibyte ip options length cannot be less then four bytes. Am I wrong? -- Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer phone: +7 (095) 796-9079, mailto: maxim@macomnet.ru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Dec 22 15:29:22 2001 Delivered-To: freebsd-net@freebsd.org Received: from relay1.macomnet.ru (relay1.macomnet.ru [195.128.64.10]) by hub.freebsd.org (Postfix) with ESMTP id F2F4237B416; Sat, 22 Dec 2001 15:29:15 -0800 (PST) Received: from news1.macomnet.ru (maxim@news1.macomnet.ru [195.128.64.14]) by relay1.macomnet.ru (8.11.3/8.11.3) with ESMTP id fBMNTEY3193743; Sun, 23 Dec 2001 02:29:14 +0300 (MSK) Date: Sun, 23 Dec 2001 02:29:14 +0300 (MSK) From: Maxim Konovalov To: Yar Tikhiy Cc: net@FreeBSD.ORG, Subject: Re: Processing IP options reveals IPSTEALH router In-Reply-To: <20011221185118.B25868@comp.chem.msu.su> Message-ID: <20011223022614.U18529-100000@news1.macomnet.ru> 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 Hello, On 18:51+0300, Dec 21, 2001, Yar Tikhiy wrote: > On Wed, Dec 19, 2001 at 08:54:50PM +0300, Maxim Konovalov wrote: > > On 19:49+0300, Dec 19, 2001, Yar Tikhiy wrote: > > > > > As for source routing, I believe a stealthy router should just drop > > > such packets as though it were a host. Of course, source-routed > > > packets destined for the router itself should be accepted. > > > > So there are three IPSTEALTH cases: > > > > 1/ the dst address is not ours, net.inet.ip.sourceroute=0, > > net.inet.ip.forwarding=1: process ip options by ip_dooptions(). > > > > 2/ the dst address is ours: process ip options by ip_dooptions(), > > > > 3/ in other cases do not process ip options. > > I made a patch that adds the "stealthy IP options feature". > Honestly, now I'm afraid it's "much ado about nothing", given how > clumsy solution is needed for such a small problem. Even the way > of ignoring IP options completely when doing IPSTEALTH looks way > better... IMHO it is not a good idea to forward a packet with possible incorrect ip options. The patch looks OK for me. -- Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer phone: +7 (095) 796-9079, mailto: maxim@macomnet.ru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message