From owner-freebsd-net Sun Jul 30 1:45:26 2000 Delivered-To: freebsd-net@freebsd.org Received: from garm.bart.nl (garm.bart.nl [194.158.170.13]) by hub.freebsd.org (Postfix) with ESMTP id C535A37B54E for ; Sun, 30 Jul 2000 01:45:21 -0700 (PDT) (envelope-from asmodai@wxs.nl) Received: from daemon.ninth-circle.org (daemon.ninth-circle.org [195.38.210.81]) by garm.bart.nl (8.10.1/8.10.1) with ESMTP id e6U8j5j79942 for ; Sun, 30 Jul 2000 10:45:08 +0200 (CEST) Received: (from asmodai@localhost) by daemon.ninth-circle.org (8.9.3/8.9.3) id KAA29599 for freebsd-net@freebsd.org; Sun, 30 Jul 2000 10:44:27 +0200 (CEST) (envelope-from asmodai) Date: Sun, 30 Jul 2000 10:44:27 +0200 From: Jeroen Ruigrok/Asmodai To: freebsd-net@freebsd.org Subject: Fwd: A new kernel extension to deal with IP option packets Message-ID: <20000730104427.A28035@daemon.ninth-circle.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i Organisation: Ninth-Circle Enterprises Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org For those interested. ----- Forwarded message from Ping Pan ----- From: Ping Pan To: e2e list , rsvp-test list CC: Henning Schulzrinne , Jon Crowcroft Subject: A new kernel extension to deal with IP option packets Date: Fri, 21 Jul 2000 14:44:53 -0400 X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en X-Apparently-From: PingPingPan@aol.com Precedence: bulk Hi, We have designed and developed a new socket protocol family to support IP option packets in BSD. It allows the users to intercept any IP option packet (source routing, router-alert...) from socket interface. So users can play fancy tricks with packets. This is mainly motivated by two reasons: 1. with all the potential benefits that IP option may provide, there is no clean way to intercept IP option packets from the kernel; 2. in case of RSVP and other incoming router-alert-driven applications, the BSD routers need to deal with the option packets in a more uniform way; (the current implementation is really intercepting packets base on the protocol types, rather than the IP option values.) A document describing this new feature and performance is available at http://www.cs.columbia.edu/~pingpan/papers/BLtm_ipopt.ps The source code for FreeBSD is at http://www.cs.columbia.edu/~pingpan/software_list.htm We also have coded a new command, ipodump(), to sniff option packets from the wire. ;-) I have tested it with ISI's RSVP, ping -R.... all worked. Thanks! -- Ping Pan and Henning Schulzrinne ----- End forwarded message ----- -- Jeroen Ruigrok vd Werven/Asmodai asmodai@[wxs.nl|bart.nl|freebsd.org] Documentation nutter/C-rated Coder BSD: Technical excellence at its best The BSD Programmer's Documentation Project Abandon hope, all ye who enter here... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jul 30 12:17:34 2000 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 70C7C37B6C6 for ; Sun, 30 Jul 2000 12:17:28 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id OAA02982; Sun, 30 Jul 2000 14:27:06 -0400 (EDT) (envelope-from wollman) Date: Sun, 30 Jul 2000 14:27:06 -0400 (EDT) From: Garrett Wollman Message-Id: <200007301827.OAA02982@khavrinen.lcs.mit.edu> To: Jeroen Ruigrok/Asmodai Cc: freebsd-net@FreeBSD.ORG Subject: Fwd: A new kernel extension to deal with IP option packets In-Reply-To: <20000730104427.A28035@daemon.ninth-circle.org> References: <20000730104427.A28035@daemon.ninth-circle.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > For those interested. We received a PR for it as well, which is still in my queue. I generally did not like what I read in the description (it sounds like a crock) so I haven't given it very high priority. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jul 30 12:21:33 2000 Delivered-To: freebsd-net@freebsd.org Received: from njord.bart.nl (njord.bart.nl [194.158.170.15]) by hub.freebsd.org (Postfix) with ESMTP id 2EEC037B6C1 for ; Sun, 30 Jul 2000 12:21:30 -0700 (PDT) (envelope-from asmodai@wxs.nl) Received: from daemon.ninth-circle.org (root@daemon.ninth-circle.org [195.38.210.81]) by njord.bart.nl (8.10.1/8.10.1) with ESMTP id e6UJLP487002; Sun, 30 Jul 2000 21:21:25 +0200 (CEST) Received: (from asmodai@localhost) by daemon.ninth-circle.org (8.9.3/8.9.3) id VAA31901; Sun, 30 Jul 2000 21:21:06 +0200 (CEST) (envelope-from asmodai) Date: Sun, 30 Jul 2000 21:21:06 +0200 From: Jeroen Ruigrok/Asmodai To: Garrett Wollman Cc: freebsd-net@FreeBSD.ORG Subject: Re: Fwd: A new kernel extension to deal with IP option packets Message-ID: <20000730212106.D28035@daemon.ninth-circle.org> References: <20000730104427.A28035@daemon.ninth-circle.org> <200007301827.OAA02982@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200007301827.OAA02982@khavrinen.lcs.mit.edu>; from wollman@khavrinen.lcs.mit.edu on Sun, Jul 30, 2000 at 02:27:06PM -0400 Organisation: Ninth-Circle Enterprises Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org -On [20000730 21:05], Garrett Wollman (wollman@khavrinen.lcs.mit.edu) wrote: >< said: > >> For those interested. > >We received a PR for it as well, which is still in my queue. I >generally did not like what I read in the description (it sounds like >a crock) so I haven't given it very high priority. I haven't had the chance yet really to look at it deeply, but if it is good it will be used, if it is not, it may serve as an education. -- Jeroen Ruigrok vd Werven/Asmodai asmodai@[wxs.nl|bart.nl|freebsd.org] Documentation nutter/C-rated Coder BSD: Technical excellence at its best The BSD Programmer's Documentation Project Abandon hope, all ye who enter here... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jul 30 16:57:16 2000 Delivered-To: freebsd-net@freebsd.org Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (Postfix) with ESMTP id 6DCC837B7EA for ; Sun, 30 Jul 2000 16:57:12 -0700 (PDT) (envelope-from louie@whizzo.transsys.com) Received: from whizzo.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.9.3/8.9.1) with ESMTP id TAA74234; Sun, 30 Jul 2000 19:57:10 -0400 (EDT) (envelope-from louie@whizzo.transsys.com) Message-Id: <200007302357.TAA74234@whizzo.transsys.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Jeroen Ruigrok/Asmodai Cc: Garrett Wollman , freebsd-net@FreeBSD.ORG X-Image-URL: http://www.transsys.com/louie/images/louie-mail.jpg From: "Louis A. Mamakos" Subject: Re: Fwd: A new kernel extension to deal with IP option packets References: <20000730104427.A28035@daemon.ninth-circle.org> <200007301827.OAA02982@khavrinen.lcs.mit.edu> <20000730212106.D28035@daemon.ninth-circle.org> In-reply-to: Your message of "Sun, 30 Jul 2000 21:21:06 +0200." <20000730212106.D28035@daemon.ninth-circle.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 30 Jul 2000 19:57:10 -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I saw this too, and I guess what I can't figure out is why socket options to extract IP options on a raw IP socket (or perhaps any datagram socket) are not sufficient. There are no "IP options packets"; the options are already associated with a packet bound to a socket. Or for packets transiting the host. Is this specifically to support an RSVP implementation when the FreeBSD platform is acting as a router? I'm also wondering why perhaps BPF isn't a mechanism which can be used, but perhaps that's much too low a level an interface. louie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jul 30 18:18:53 2000 Delivered-To: freebsd-net@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id 6CFA437B8C8; Sun, 30 Jul 2000 18:18:51 -0700 (PDT) (envelope-from kris@FreeBSD.org) Received: from localhost (kris@localhost) by freefall.freebsd.org (8.9.3/8.9.2) with ESMTP id SAA26643; Sun, 30 Jul 2000 18:18:51 -0700 (PDT) (envelope-from kris@FreeBSD.org) X-Authentication-Warning: freefall.freebsd.org: kris owned process doing -bs Date: Sun, 30 Jul 2000 18:18:51 -0700 (PDT) From: Kris Kennaway To: Jeroen Ruigrok/Asmodai Cc: freebsd-net@freebsd.org Subject: Re: Fwd: A new kernel extension to deal with IP option packets In-Reply-To: <20000730104427.A28035@daemon.ninth-circle.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 30 Jul 2000, Jeroen Ruigrok/Asmodai wrote: > We have designed and developed a new socket protocol family to support > IP option packets in BSD. It allows the users to intercept any IP option > packet (source routing, router-alert...) from socket interface. So users > can play fancy tricks with packets. Can't we do this already with ipfw and divert sockets? ipfw can already match IP packets containing options. Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jul 30 18:18:58 2000 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 0BEE137B8D8 for ; Sun, 30 Jul 2000 18:18:51 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id UAA03891; Sun, 30 Jul 2000 20:36:24 -0400 (EDT) (envelope-from wollman) Date: Sun, 30 Jul 2000 20:36:24 -0400 (EDT) From: Garrett Wollman Message-Id: <200007310036.UAA03891@khavrinen.lcs.mit.edu> To: "Louis A. Mamakos" Cc: freebsd-net@FreeBSD.ORG Subject: Re: Fwd: A new kernel extension to deal with IP option packets In-Reply-To: <200007302357.TAA74234@whizzo.transsys.com> References: <20000730104427.A28035@daemon.ninth-circle.org> <200007301827.OAA02982@khavrinen.lcs.mit.edu> <20000730212106.D28035@daemon.ninth-circle.org> <200007302357.TAA74234@whizzo.transsys.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > Is this specifically to support an RSVP implementation when the FreeBSD > platform is acting as a router? That's the impression I got from the second message. It certainly doesn't deserve a new protocol family. If anything, either the DIVERT (ick!) functionality, or a socket option on a raw IP socket would be more appropriate. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jul 30 18:25:31 2000 Delivered-To: freebsd-net@freebsd.org Received: from rly-ip02.mx.aol.com (rly-ip02.mx.aol.com [152.163.225.160]) by hub.freebsd.org (Postfix) with ESMTP id 37B8237B8D2 for ; Sun, 30 Jul 2000 18:25:29 -0700 (PDT) (envelope-from pingpan@cs.columbia.edu) Received: from tot-we.proxy.aol.com (tot-we.proxy.aol.com [205.188.195.1]) by rly-ip02.mx.aol.com (8.8.8/8.8.8/AOL-5.0.0) with ESMTP id VAA02191; Sun, 30 Jul 2000 21:25:02 -0400 (EDT) Received: from cs.columbia.edu (AC819AAD.ipt.aol.com [172.129.154.173]) by tot-we.proxy.aol.com (8.10.0/8.10.0) with ESMTP id e6V1P1B29099; Sun, 30 Jul 2000 21:25:01 -0400 (EDT) Message-ID: <3984D4D9.ECD596D3@cs.columbia.edu> Date: Sun, 30 Jul 2000 21:22:33 -0400 From: Ping Pan X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Garrett Wollman Cc: freebsd-net@freebsd.org Subject: Re: Fwd: A new kernel extension to deal with IP option packets References: <20000730104427.A28035@daemon.ninth-circle.org> <200007301827.OAA02982@khavrinen.lcs.mit.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Apparently-From: PingPingPan@aol.com Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Crock... ;-) Sorry about the PR. The reason why we wrote the report was to make sure that the work is useful and does not cost too much processing cycles.... The code itself was not big at all, and was quite easy to develop. Let me know if I can be any help. - Ping Pan Garrett Wollman wrote: > > < said: > > > For those interested. > > We received a PR for it as well, which is still in my queue. I > generally did not like what I read in the description (it sounds like > a crock) so I haven't given it very high priority. > > -GAWollman > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jul 30 18:32:38 2000 Delivered-To: freebsd-net@freebsd.org Received: from rly-ip02.mx.aol.com (rly-ip02.mx.aol.com [152.163.225.160]) by hub.freebsd.org (Postfix) with ESMTP id F035E37B8D2 for ; Sun, 30 Jul 2000 18:32:30 -0700 (PDT) (envelope-from pingpan@cs.columbia.edu) Received: from tot-we.proxy.aol.com (tot-we.proxy.aol.com [205.188.195.1]) by rly-ip02.mx.aol.com (8.8.8/8.8.8/AOL-5.0.0) with ESMTP id VAA09232; Sun, 30 Jul 2000 21:32:13 -0400 (EDT) Received: from cs.columbia.edu (AC819AAD.ipt.aol.com [172.129.154.173]) by tot-we.proxy.aol.com (8.10.0/8.10.0) with ESMTP id e6V1WAB03075; Sun, 30 Jul 2000 21:32:12 -0400 (EDT) Message-ID: <3984D687.8094E53A@cs.columbia.edu> Date: Sun, 30 Jul 2000 21:29:43 -0400 From: Ping Pan X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Louis A. Mamakos" Cc: Jeroen Ruigrok/Asmodai , Garrett Wollman , freebsd-net@freebsd.org Subject: Re: Fwd: A new kernel extension to deal with IP option packets References: <20000730104427.A28035@daemon.ninth-circle.org> <200007301827.OAA02982@khavrinen.lcs.mit.edu> <20000730212106.D28035@daemon.ninth-circle.org> <200007302357.TAA74234@whizzo.transsys.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Apparently-From: PingPingPan@aol.com Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "Louis A. Mamakos" wrote: > > I saw this too, and I guess what I can't figure out is why > socket options to extract IP options on a raw IP socket (or perhaps > any datagram socket) are not sufficient. There are no "IP options > packets"; the options are already associated with a packet bound to > a socket. Or for packets transiting the host. > > Is this specifically to support an RSVP implementation when the FreeBSD > platform is acting as a router? > Louis, If you take a look at the RSVP kernel support, it was doing protocol-type switching, and has nothing to do with the fact that the RSVP PATH messages are encapsulated in IP router-alert option. So using raw socket is not sufficient. Also if the IP option is for UDP and TCP packets, the current BSD cannot intercept the packets without knowing the port numbers. How can BSD routers pick up those packets? We had gone through all other possible mechanisms: raw socket, libpcap and divert. None really works, so we designed this socket family. The new socket family is to do IP option type switching. Please read the first section of the our report. The report is in http://www.cs.columbia.edu/~pingpan/paper_list.html > I'm also wondering why perhaps BPF isn't a mechanism which can be > used, but perhaps that's much too low a level an interface. > Yes. Parsing DLC headers at the application level is not so simple (and required to copy a lot of routines from tcpdump()). Given the user process is only interested in IP header, I don't see why I want to use libpcap. Also libpcap does not intercept the packets. It copes them only. Some router applications need to intercept the packets. > louie - Ping To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jul 30 18:38:56 2000 Delivered-To: freebsd-net@freebsd.org Received: from rly-ip02.mx.aol.com (rly-ip02.mx.aol.com [152.163.225.160]) by hub.freebsd.org (Postfix) with ESMTP id 4CD4A37B8D2 for ; Sun, 30 Jul 2000 18:38:52 -0700 (PDT) (envelope-from pingpan@cs.columbia.edu) Received: from tot-we.proxy.aol.com (tot-we.proxy.aol.com [205.188.195.1]) by rly-ip02.mx.aol.com (8.8.8/8.8.8/AOL-5.0.0) with ESMTP id VAA14306; Sun, 30 Jul 2000 21:38:28 -0400 (EDT) Received: from cs.columbia.edu (AC819AAD.ipt.aol.com [172.129.154.173]) by tot-we.proxy.aol.com (8.10.0/8.10.0) with ESMTP id e6V1cPB03291; Sun, 30 Jul 2000 21:38:27 -0400 (EDT) Message-ID: <3984D7FC.2C9970E7@cs.columbia.edu> Date: Sun, 30 Jul 2000 21:35:56 -0400 From: Ping Pan X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jeroen Ruigrok/Asmodai Cc: Garrett Wollman , freebsd-net@freebsd.org Subject: Re: Fwd: A new kernel extension to deal with IP option packets References: <20000730104427.A28035@daemon.ninth-circle.org> <200007301827.OAA02982@khavrinen.lcs.mit.edu> <20000730212106.D28035@daemon.ninth-circle.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Apparently-From: PingPingPan@aol.com Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Jeroen, Please let us know if it is not good enough. We have already used the new kernel extension to design and develop a new lightweight Internet reservation protocol, YESSIR, on FBSD. We can process up to 10,000 reservations-per-second on a 700MHz Pentium-III PC. I have not officially released that code because I have not figured out the AltQ/DiffServ interface and have bugs here and there. But that will be a nice application eventually, I hope. BTW, some people have written to me privately on using the new socket family for their prototyping projects. Thanks for showing the interest. - Ping Pan Jeroen Ruigrok/Asmodai wrote: > > -On [20000730 21:05], Garrett Wollman (wollman@khavrinen.lcs.mit.edu) wrote: > >< said: > > > >> For those interested. > > > >We received a PR for it as well, which is still in my queue. I > >generally did not like what I read in the description (it sounds like > >a crock) so I haven't given it very high priority. > > I haven't had the chance yet really to look at it deeply, but if it is > good it will be used, if it is not, it may serve as an education. > > -- > Jeroen Ruigrok vd Werven/Asmodai asmodai@[wxs.nl|bart.nl|freebsd.org] > Documentation nutter/C-rated Coder BSD: Technical excellence at its best > The BSD Programmer's Documentation Project > Abandon hope, all ye who enter here... > > 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 Sun Jul 30 18:48:18 2000 Delivered-To: freebsd-net@freebsd.org Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by hub.freebsd.org (Postfix) with SMTP id 3B33137B95F; Sun, 30 Jul 2000 18:48:07 -0700 (PDT) (envelope-from pingpan@research.bell-labs.com) Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by crufty; Sun Jul 30 21:47:18 EDT 2000 Received: from research.bell-labs.com (pingpan.lra.lucent.com [135.255.38.196]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id VAA15974; Sun, 30 Jul 2000 21:47:15 -0400 (EDT) Message-ID: <3984DA10.636ACA1A@research.bell-labs.com> Date: Sun, 30 Jul 2000 21:44:48 -0400 From: Ping Pan Organization: Bell Labs, Lucent X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Kris Kennaway Cc: Jeroen Ruigrok/Asmodai , freebsd-net@freebsd.org Subject: Re: Fwd: A new kernel extension to deal with IP option packets References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Kris Kennaway wrote: > > On Sun, 30 Jul 2000, Jeroen Ruigrok/Asmodai wrote: > > > We have designed and developed a new socket protocol family to support > > IP option packets in BSD. It allows the users to intercept any IP option > > packet (source routing, router-alert...) from socket interface. So users > > can play fancy tricks with packets. > > Can't we do this already with ipfw and divert sockets? ipfw can already > match IP packets containing options. > Yes, except that to have a security system, we need to put the IP option filters to be the *last* ones to check. That could be somewhat tricky during the filter configuration. Also since filter lookup (for divert) is quite extensive on several packet fields, I am not sure using the divert mechanism would give the best performance results. Regards, - Ping > Kris > > -- > In God we Trust -- all others must submit an X.509 certificate. > -- Charles Forsythe > > 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 Sun Jul 30 22:23:23 2000 Delivered-To: freebsd-net@freebsd.org Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by hub.freebsd.org (Postfix) with ESMTP id 3F05D37B60E for ; Sun, 30 Jul 2000 22:23:12 -0700 (PDT) (envelope-from itojun@itojun.org) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id OAA19656; Mon, 31 Jul 2000 14:23:07 +0900 (JST) To: Jeroen Ruigrok/Asmodai Cc: freebsd-net@freebsd.org In-reply-to: asmodai's message of Sun, 30 Jul 2000 10:44:27 +0200. <20000730104427.A28035@daemon.ninth-circle.org> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Fwd: A new kernel extension to deal with IP option packets From: itojun@iijlab.net Date: Mon, 31 Jul 2000 14:23:07 +0900 Message-ID: <19654.965020987@coconut.itojun.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >A document describing this new feature and performance is available at >http://www.cs.columbia.edu/~pingpan/papers/BLtm_ipopt.ps > >The source code for FreeBSD is at >http://www.cs.columbia.edu/~pingpan/software_list.htm > >We also have coded a new command, ipodump(), to sniff option packets >from the wire. ;-) I have tested it with ISI's RSVP, ping -R.... all >worked. you want to look at RFC2292, and draft-ietf-ipngwg-2292bis. RFC2292 specifies how you can manipulate IPv6 extension headers (header chains between IP and TCP/UDP header, has similar role to IPv4 options), using ancillary data stream. it gives you much higher flexibility and control, without additional address family (i think we shouldn't define address family for this). itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 31 0:33:34 2000 Delivered-To: freebsd-net@freebsd.org Received: from mgw1.MEIway.com (mgw1.meiway.com [212.73.210.75]) by hub.freebsd.org (Postfix) with ESMTP id 5913A37B642 for ; Mon, 31 Jul 2000 00:33:30 -0700 (PDT) (envelope-from lconrad@Go2France.com) Received: from mail.Go2France.com (ms1.meiway.com [212.73.210.73]) by mgw1.MEIway.com (Postfix Relay Hub) with ESMTP id 568786A901 for ; Mon, 31 Jul 2000 09:33:28 +0200 (CEST) Received: from sv.Go2France.com [212.73.210.79] by mail.Go2France.com with ESMTP (SMTPD32-6.03) id AC093FFE006A; Mon, 31 Jul 2000 09:34:33 +0200 Message-Id: <4.3.2.7.2.20000731090110.00d5c520@mail.Go2France.com> X-Sender: lconrad%Go2France.com@mail.Go2France.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 31 Jul 2000 09:31:00 +0200 To: freebsd-net@freebsd.org From: Len Conrad Subject: VPN Consortium Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org http://www.idg.net/go.cgi?id=289230 Just read this article, and was wondering if FreeBSD org or BSD/i were planning join the VPNC and to obtain a "VPNC Good Housekeeping Seal" for FreeBSD 4.1 + KAME? Can't hurt credibility, and FreeBSD needs all the good press it can get, esp since FreeBSD + KAME is running essentially a de facto standard used by VPNC to measure other products. Len http://BIND8NT.MEIway.com: ISC BIND 8.2.2 p5 installable binary for NT4 http://IMGate.MEIway.com: Build free, hi-perf, anti-spam mail gateways To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 31 1:39:35 2000 Delivered-To: freebsd-net@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id 0618937B8BF; Mon, 31 Jul 2000 01:39:29 -0700 (PDT) (envelope-from kris@FreeBSD.org) Received: from localhost (kris@localhost) by freefall.freebsd.org (8.9.3/8.9.2) with ESMTP id BAA79093; Mon, 31 Jul 2000 01:39:29 -0700 (PDT) (envelope-from kris@FreeBSD.org) X-Authentication-Warning: freefall.freebsd.org: kris owned process doing -bs Date: Mon, 31 Jul 2000 01:39:29 -0700 (PDT) From: Kris Kennaway To: current@freebsd.org Cc: net@freebsd.org Subject: Mozilla-M15+ipv6 package available Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org A few people have asked me for this, so I uploaded a package of the mozilla-M15+ipv6 port from KAME to http://www.freebsd.org/~kris/mozilla-M15.tgz (yes, I know M16 is out, but the port isn't yet updated). Install this package and you too can see the dancing kame at http://www.kame.net, the current hilight of the inet6! The patches aren't quite suitable for committing to the ports collection because they unconditionally enable support for IPv6 which may not work on 3.x machines, but if anyone is interested in looking at them then please let me know. Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 31 1:48:32 2000 Delivered-To: freebsd-net@freebsd.org Received: from garm.bart.nl (garm.bart.nl [194.158.170.13]) by hub.freebsd.org (Postfix) with ESMTP id 2D0AB37B56C for ; Mon, 31 Jul 2000 01:48:25 -0700 (PDT) (envelope-from asmodai@wxs.nl) Received: from daemon.ninth-circle.org (root@daemon.ninth-circle.org [195.38.210.81]) by garm.bart.nl (8.10.1/8.10.1) with ESMTP id e6V8mH622121; Mon, 31 Jul 2000 10:48:17 +0200 (CEST) Received: (from asmodai@localhost) by daemon.ninth-circle.org (8.9.3/8.9.3) id KAA34133; Mon, 31 Jul 2000 10:38:02 +0200 (CEST) (envelope-from asmodai) Date: Mon, 31 Jul 2000 10:38:02 +0200 From: Jeroen Ruigrok/Asmodai To: Ping Pan Cc: Garrett Wollman , freebsd-net@freebsd.org Subject: Re: Fwd: A new kernel extension to deal with IP option packets Message-ID: <20000731103802.C32129@daemon.ninth-circle.org> References: <20000730104427.A28035@daemon.ninth-circle.org> <200007301827.OAA02982@khavrinen.lcs.mit.edu> <20000730212106.D28035@daemon.ninth-circle.org> <3984D7FC.2C9970E7@cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <3984D7FC.2C9970E7@cs.columbia.edu>; from pingpan@cs.columbia.edu on Sun, Jul 30, 2000 at 09:35:56PM -0400 Organisation: Ninth-Circle Enterprises Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello Ping, -On [20000731 04:01], Ping Pan (pingpan@cs.columbia.edu) wrote: >Jeroen, > >Please let us know if it is not good enough. Hmm? I wasn't saying that. I was merely commenting on Garret's words that he wasn't particularly fond of it. My words were meant to say that if the idea and the code is good, it will get accepted, one way or the other. If they aren't, they may serve as education on how not to proceed. No matter what way you look at it, it will always be beneficial since we can learn from it. >We have already used the new kernel extension to design and develop a >new lightweight Internet reservation protocol, YESSIR, on FBSD. We can >process up to 10,000 reservations-per-second on a 700MHz Pentium-III >PC. I have not officially released that code because I have not figured >out the AltQ/DiffServ interface and have bugs here and there. But that >will be a nice application eventually, I hope. I will always be interested in looking at things like this, regardless of whether it gets integrated into FreeBSD or not. >BTW, some people have written to me privately on using the new socket >family for their prototyping projects. Which is good, but it doesn't give you an advantage over the acceptance. =) >Thanks for showing the interest. No problem, like I said, it will be useful no matter what. -- Jeroen Ruigrok vd Werven/Asmodai asmodai@[wxs.nl|bart.nl|freebsd.org] Documentation nutter/C-rated Coder BSD: Technical excellence at its best The BSD Programmer's Documentation Project Abandon hope, all ye who enter here... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 31 4:14: 5 2000 Delivered-To: freebsd-net@freebsd.org Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by hub.freebsd.org (Postfix) with SMTP id 7EE3637BC17 for ; Mon, 31 Jul 2000 04:14:02 -0700 (PDT) (envelope-from pingpan@research.bell-labs.com) Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by crufty; Mon Jul 31 07:12:53 EDT 2000 Received: from research.bell-labs.com (pingpan.lra.lucent.com [135.255.33.105]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id HAA28701; Mon, 31 Jul 2000 07:12:49 -0400 (EDT) Message-ID: <39855E9F.FA83B93@research.bell-labs.com> Date: Mon, 31 Jul 2000 07:10:23 -0400 From: Ping Pan Organization: Bell Labs, Lucent X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jeroen Ruigrok/Asmodai Cc: Ping Pan , Garrett Wollman , freebsd-net@freebsd.org Subject: Re: Fwd: A new kernel extension to deal with IP option packets References: <20000730104427.A28035@daemon.ninth-circle.org> <200007301827.OAA02982@khavrinen.lcs.mit.edu> <20000730212106.D28035@daemon.ninth-circle.org> <3984D7FC.2C9970E7@cs.columbia.edu> <20000731103802.C32129@daemon.ninth-circle.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, Since this is my first submission to FreeBSD, I don't know the proper procedure. Sorry if I have offend anyone on this list. I trust you guys will make the right decision one way or the other.... From my stand point of view, the new socket family just makes the life easier for some of the stuff I am working on. That's all. :-) Best regards to all, - Ping Jeroen Ruigrok/Asmodai wrote: > > Hello Ping, > > -On [20000731 04:01], Ping Pan (pingpan@cs.columbia.edu) wrote: > >Jeroen, > > > >Please let us know if it is not good enough. > > Hmm? I wasn't saying that. I was merely commenting on Garret's words > that he wasn't particularly fond of it. > > My words were meant to say that if the idea and the code is good, it > will get accepted, one way or the other. If they aren't, they may serve > as education on how not to proceed. > No matter what way you look at it, it will always be beneficial since we > can learn from it. > > >We have already used the new kernel extension to design and develop a > >new lightweight Internet reservation protocol, YESSIR, on FBSD. We can > >process up to 10,000 reservations-per-second on a 700MHz Pentium-III > >PC. I have not officially released that code because I have not figured > >out the AltQ/DiffServ interface and have bugs here and there. But that > >will be a nice application eventually, I hope. > > I will always be interested in looking at things like this, regardless > of whether it gets integrated into FreeBSD or not. > > >BTW, some people have written to me privately on using the new socket > >family for their prototyping projects. > > Which is good, but it doesn't give you an advantage over the acceptance. > =) > > >Thanks for showing the interest. > > No problem, like I said, it will be useful no matter what. > > -- > Jeroen Ruigrok vd Werven/Asmodai asmodai@[wxs.nl|bart.nl|freebsd.org] > Documentation nutter/C-rated Coder BSD: Technical excellence at its best > The BSD Programmer's Documentation Project > Abandon hope, all ye who enter here... > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 31 9: 7:27 2000 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 7664137B6BA for ; Mon, 31 Jul 2000 09:07:14 -0700 (PDT) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.9.3/1.13) id TAA81168; Mon, 31 Jul 2000 19:04:39 +0300 (EEST) Date: Mon, 31 Jul 2000 19:04:39 +0300 From: Ruslan Ermilov To: Stephen Montgomery-Smith , Gregory Bond Cc: net@FreeBSD.org Subject: Re: conf/20197: rc.firewall with firewall_type=simple doesn't work with natd Message-ID: <20000731190439.A75240@sunbay.com> Mail-Followup-To: Stephen Montgomery-Smith , Gregory Bond , net@FreeBSD.org References: <200007262240.PAA88875@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="6TrnltStXW4iwmi0" X-Mailer: Mutt 1.0i In-Reply-To: <200007262240.PAA88875@freefall.freebsd.org>; from stephen@math.missouri.edu on Wed, Jul 26, 2000 at 03:40:02PM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --6TrnltStXW4iwmi0 Content-Type: text/plain; charset=us-ascii On Wed, Jul 26, 2000 at 03:40:02PM -0700, Stephen Montgomery-Smith wrote: > > Or an even better way - sorry for all my follow ups. > [...] What do you guys think about the attached patch? -- 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 --6TrnltStXW4iwmi0 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p Index: rc.firewall =================================================================== RCS file: /home/ncvs/src/etc/rc.firewall,v retrieving revision 1.35 diff -u -p -r1.35 rc.firewall --- rc.firewall 2000/07/30 19:28:05 1.35 +++ rc.firewall 2000/07/31 16:02:55 @@ -67,18 +67,20 @@ esac ${fwcmd} -f flush ############ -# These rules are required for using natd. All packets are passed to +# This rule is required for using natd. All packets are passed to # natd before they encounter your remaining rules. The firewall rules # will then be run again on each packet after translation by natd, -# minus any divert rules (see natd(8)). +# starting at the rule number following the divert rule (see natd(8)). # -case ${natd_enable} in -[Yy][Ee][Ss]) - if [ -n "${natd_interface}" ]; then - ${fwcmd} add 50 divert natd all from any to any via ${natd_interface} - fi - ;; -esac +nat() { + case ${natd_enable} in + [Yy][Ee][Ss]) + if [ -n "${natd_interface}" ]; then + ${fwcmd} add divert natd all from any to any via ${natd_interface} + fi + ;; + esac +} ############ # If you just configured ipfw in the kernel as a tool to solve network @@ -101,6 +103,10 @@ ${fwcmd} add 200 deny all from any to 12 # case ${firewall_type} in [Oo][Pp][Ee][Nn]) + # Network Address Translation + nat + + # Allow everything ${fwcmd} add 65000 pass all from any to any ;; @@ -115,6 +121,9 @@ case ${firewall_type} in mask="255.255.255.0" ip="192.0.2.1" + # Network Address Translation + nat + # Allow any traffic to or from my own net. ${fwcmd} add pass all from ${ip} to ${net}:${mask} ${fwcmd} add pass all from ${net}:${mask} to ${ip} @@ -171,26 +180,35 @@ case ${firewall_type} in ${fwcmd} add deny all from ${onet}:${omask} to any in via ${iif} # Stop RFC1918 nets on the outside interface - ${fwcmd} add deny all from 10.0.0.0/8 to any via ${oif} ${fwcmd} add deny all from any to 10.0.0.0/8 via ${oif} - ${fwcmd} add deny all from 172.16.0.0/12 to any via ${oif} ${fwcmd} add deny all from any to 172.16.0.0/12 via ${oif} - ${fwcmd} add deny all from 192.168.0.0/16 to any via ${oif} ${fwcmd} add deny all from any to 192.168.0.0/16 via ${oif} # Stop draft-manning-dsua-03.txt (1 May 2000) nets (includes RESERVED-1, # DHCP auto-configuration, NET-TEST, MULTICAST (class D), and class E) # on the outside interface - ${fwcmd} add deny all from 0.0.0.0/8 to any via ${oif} ${fwcmd} add deny all from any to 0.0.0.0/8 via ${oif} - ${fwcmd} add deny all from 169.254.0.0/16 to any via ${oif} ${fwcmd} add deny all from any to 169.254.0.0/16 via ${oif} - ${fwcmd} add deny all from 192.0.2.0/24 to any via ${oif} ${fwcmd} add deny all from any to 192.0.2.0/24 via ${oif} - ${fwcmd} add deny all from 224.0.0.0/4 to any via ${oif} ${fwcmd} add deny all from any to 224.0.0.0/4 via ${oif} - ${fwcmd} add deny all from 240.0.0.0/4 to any via ${oif} ${fwcmd} add deny all from any to 240.0.0.0/4 via ${oif} + + # Network Address Translation + nat + + # Stop RFC1918 nets on the outside interface + ${fwcmd} add deny all from 10.0.0.0/8 to any via ${oif} + ${fwcmd} add deny all from 172.16.0.0/12 to any via ${oif} + ${fwcmd} add deny all from 192.168.0.0/16 to any via ${oif} + + # Stop draft-manning-dsua-03.txt (1 May 2000) nets (includes RESERVED-1, + # DHCP auto-configuration, NET-TEST, MULTICAST (class D), and class E) + # on the outside interface + ${fwcmd} add deny all from 0.0.0.0/8 to any via ${oif} + ${fwcmd} add deny all from 169.254.0.0/16 to any via ${oif} + ${fwcmd} add deny all from 192.0.2.0/24 to any via ${oif} + ${fwcmd} add deny all from 224.0.0.0/4 to any via ${oif} + ${fwcmd} add deny all from 240.0.0.0/4 to any via ${oif} # Allow TCP through if setup succeeded ${fwcmd} add pass tcp from any to any established --6TrnltStXW4iwmi0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 31 9:52:16 2000 Delivered-To: freebsd-net@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id 626D137BB91; Mon, 31 Jul 2000 09:52:11 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.9.3/8.9.1) id JAA75820; Mon, 31 Jul 2000 09:52:10 -0700 (PDT) (envelope-from obrien) Date: Mon, 31 Jul 2000 09:52:10 -0700 From: "David O'Brien" To: Kris Kennaway Cc: current@FreeBSD.org, net@FreeBSD.org Subject: Re: Mozilla-M15+ipv6 package available Message-ID: <20000731095210.A75780@dragon.nuxi.com> Reply-To: obrien@FreeBSD.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from kris@FreeBSD.org on Mon, Jul 31, 2000 at 01:39:29AM -0700 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Jul 31, 2000 at 01:39:29AM -0700, Kris Kennaway wrote: > A few people have asked me for this, so I uploaded a package of the > mozilla-M15+ipv6 port from KAME to ..snip.. > The patches aren't quite suitable for committing to the ports collection > because they unconditionally enable support for IPv6 which may not work on > 3.x machines, So what??? Mark it broken for 3.x. Ask Satoshi to repo-copy the mozilla port to mozilla-ipv6 and make this a real port. :-) -- -- David (obrien@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 Jul 31 10:43:23 2000 Delivered-To: freebsd-net@freebsd.org Received: from ns1.sunesi.net (ns1.sunesi.net [196.15.192.194]) by hub.freebsd.org (Postfix) with ESMTP id 5593C37BC09 for ; Mon, 31 Jul 2000 10:43:18 -0700 (PDT) (envelope-from nbm@sunesi.net) Received: from nbm by ns1.sunesi.net with local (Exim 3.03 #1) id 13JJaD-00019E-00; Mon, 31 Jul 2000 19:42:33 +0200 Date: Mon, 31 Jul 2000 19:42:33 +0200 From: Neil Blakey-Milner To: Ruslan Ermilov Cc: Stephen Montgomery-Smith , Gregory Bond , net@FreeBSD.org Subject: Re: conf/20197: rc.firewall with firewall_type=simple doesn't work with natd Message-ID: <20000731194233.A4370@mithrandr.moria.org> References: <200007262240.PAA88875@freefall.freebsd.org> <20000731190439.A75240@sunbay.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20000731190439.A75240@sunbay.com>; from ru@sunbay.com on Mon, Jul 31, 2000 at 07:04:39PM +0300 Organization: Sunesi Clinical Systems X-Operating-System: FreeBSD 3.3-RELEASE i386 X-URL: http://rucus.ru.ac.za/~nbm/ Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon 2000-07-31 (19:04), Ruslan Ermilov wrote: > What do you guys think about the attached patch? I had something reasonably similar that I was going to suggest for people who use custom rulesets and want natd_enable, but not for a divert line to be added automatically (I use it on my little NAT router). This means one less "customization" of rc scripts for me at least (: Neil -- Neil Blakey-Milner Sunesi Clinical Systems nbm@mithrandr.moria.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 31 12:47:36 2000 Delivered-To: freebsd-net@freebsd.org Received: from peace.mahoroba.org (peace.calm.imasy.or.jp [202.227.26.34]) by hub.freebsd.org (Postfix) with ESMTP id D4B4A37BBFB; Mon, 31 Jul 2000 12:47:21 -0700 (PDT) (envelope-from ume@mahoroba.org) Received: from localhost (IDENT:mMFAInxt4sobaOGJI6A0o2jLLJrUAWD3OcusDett762rh6l3DO1B7iCejo+lhgR+@localhost [::1]) (authenticated) by peace.mahoroba.org (8.11.0/3.7W-peace) with ESMTP id e6VJkph14993; Tue, 1 Aug 2000 04:46:51 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Tue, 01 Aug 2000 04:46:47 +0900 (JST) Message-Id: <20000801.044647.63121670.ume@mahoroba.org> To: kris@FreeBSD.org Cc: current@freebsd.org, net@freebsd.org Subject: Re: Mozilla-M15+ipv6 package available In-Reply-To: References: From: Hajimu UMEMOTO X-Mailer: Mew version 1.95b38 on Emacs 20.6 / Mule 4.0 =?iso-2022-jp?B?KBskQjJWMWMbKEIp?= X-PGP-Public-Key: http://www.imasy.org/~ume/publickey.asc X-PGP-Fingerprint: 6B 0C 53 FC 5D D0 37 91 05 D0 B3 EF 36 9B 6A BC X-URL: http://www.imasy.org/~ume/ X-OS: FreeBSD 5.0-CURRENT Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >>>>> On Mon, 31 Jul 2000 01:39:29 -0700 (PDT) >>>>> Kris Kennaway said: kris> A few people have asked me for this, so I uploaded a package of the kris> mozilla-M15+ipv6 port from KAME to kris> http://www.freebsd.org/~kris/mozilla-M15.tgz kris> (yes, I know M16 is out, but the port isn't yet updated). kris> Install this package and you too can see the dancing kame at kris> http://www.kame.net, the current hilight of the inet6! kris> The patches aren't quite suitable for committing to the ports collection kris> because they unconditionally enable support for IPv6 which may not work on kris> 3.x machines, but if anyone is interested in looking at them then please kris> let me know. And, IPv6 support of Mozilla is heavily depend on mapped address. So, IPv6 enabled Mozilla requires IPv6 awareness of kernel even if IPv4 only access. -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@bisd.hitachi.co.jp ume@FreeBSD.org http://www.imasy.org/~ume/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 1 0:21:18 2000 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 A21A237B994 for ; Tue, 1 Aug 2000 00:21:11 -0700 (PDT) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.9.3/1.13) id KAA01333; Tue, 1 Aug 2000 10:20:04 +0300 (EEST) Date: Tue, 1 Aug 2000 10:20:04 +0300 From: Ruslan Ermilov To: Neil Blakey-Milner Cc: Stephen Montgomery-Smith , Gregory Bond , net@FreeBSD.org Subject: Re: conf/20197: rc.firewall with firewall_type=simple doesn't work with natd Message-ID: <20000801102004.A753@sunbay.com> Mail-Followup-To: Neil Blakey-Milner , Stephen Montgomery-Smith , Gregory Bond , net@FreeBSD.org References: <200007262240.PAA88875@freefall.freebsd.org> <20000731190439.A75240@sunbay.com> <20000731194233.A4370@mithrandr.moria.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20000731194233.A4370@mithrandr.moria.org>; from nbm@mithrandr.moria.org on Mon, Jul 31, 2000 at 07:42:33PM +0200 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Jul 31, 2000 at 07:42:33PM +0200, Neil Blakey-Milner wrote: > On Mon 2000-07-31 (19:04), Ruslan Ermilov wrote: > > What do you guys think about the attached patch? > > I had something reasonably similar that I was going to suggest for > people who use custom rulesets and want natd_enable, but not for a > divert line to be added automatically (I use it on my little NAT > router). This means one less "customization" of rc scripts for me at > least (: > I am affraid I do not understand what do you mean here. Could you please explain it to me a bit more? The nat() function installs `divert' rule where appropriate only when both `natd_enable' and `natd_interface' are set in rc.conf. -- 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 Aug 1 1: 8:57 2000 Delivered-To: freebsd-net@freebsd.org Received: from ns1.sunesi.net (ns1.sunesi.net [196.15.192.194]) by hub.freebsd.org (Postfix) with ESMTP id 6CE2F37BE60 for ; Tue, 1 Aug 2000 01:08:51 -0700 (PDT) (envelope-from nbm@sunesi.net) Received: from nbm by ns1.sunesi.net with local (Exim 3.03 #1) id 13JX6D-0002xD-00; Tue, 01 Aug 2000 10:08:29 +0200 Date: Tue, 1 Aug 2000 10:08:29 +0200 From: Neil Blakey-Milner To: Stephen Montgomery-Smith , Gregory Bond , net@FreeBSD.org Subject: Re: conf/20197: rc.firewall with firewall_type=simple doesn't work with natd Message-ID: <20000801100829.A11304@mithrandr.moria.org> References: <200007262240.PAA88875@freefall.freebsd.org> <20000731190439.A75240@sunbay.com> <20000731194233.A4370@mithrandr.moria.org> <20000801102004.A753@sunbay.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20000801102004.A753@sunbay.com>; from ru@sunbay.com on Tue, Aug 01, 2000 at 10:20:04AM +0300 Organization: Sunesi Clinical Systems X-Operating-System: FreeBSD 3.3-RELEASE i386 X-URL: http://rucus.ru.ac.za/~nbm/ Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue 2000-08-01 (10:20), Ruslan Ermilov wrote: > > I had something reasonably similar that I was going to suggest for > > people who use custom rulesets and want natd_enable, but not for a > > divert line to be added automatically (I use it on my little NAT > > router). This means one less "customization" of rc scripts for me at > > least (: > > > I am affraid I do not understand what do you mean here. > Could you please explain it to me a bit more? > > The nat() function installs `divert' rule where appropriate only > when both `natd_enable' and `natd_interface' are set in rc.conf. Only if it is called - if you're using a custom firewall set, you don't call it. You may want your divert rule later in your firewall rules, for whatever reason - it may only apply on certain IPs, ports, or whatever. I've had to comment it out to prevent it from doing something I don't want. Neil -- Neil Blakey-Milner Sunesi Clinical Systems nbm@mithrandr.moria.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 1 1:32:40 2000 Delivered-To: freebsd-net@freebsd.org Received: from mta01.chello.no (mta01.chello.no [212.186.255.12]) by hub.freebsd.org (Postfix) with ESMTP id 2B5BC37B5E1 for ; Tue, 1 Aug 2000 01:32:32 -0700 (PDT) (envelope-from shaun@shamz.net) Received: from johnny.priv.shamz.net ([213.46.212.80]) by mta01.chello.no (InterMail vK.4.02.00.00 201-232-116 license 77df2db80a2bdce4d335ff4839618d42) with ESMTP id <20000801083300.FOVU27441.mta01@johnny.priv.shamz.net> for ; Tue, 1 Aug 2000 10:33:00 +0200 Received: from dakota.priv.shamz.net (dakota.priv.shamz.net [192.168.0.24]) by johnny.priv.shamz.net (8.9.3/8.9.3) with ESMTP id BAA18231 for ; Tue, 1 Aug 2000 01:17:13 +0200 (CEST) (envelope-from shaun@dakota.priv.shamz.net) Received: (from shaun@localhost) by dakota.priv.shamz.net (8.9.3/8.9.3) id BAA11044 for net@FreeBSD.ORG; Tue, 1 Aug 2000 01:17:09 +0200 (CEST) (envelope-from shaun) Date: Tue, 1 Aug 2000 01:17:09 +0200 From: Shaun Jurrens To: net@FreeBSD.ORG Subject: connections via natd dying in natd Message-ID: <20000801011709.B4159@dakota.priv.shamz.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi all, I have been struggling with this problem for a number of months, actually. I had it using 3-STABLE boxes and now with one 4-STABLE through the 3(.5)-STABLE natd gateway, the same problem occurs. The problem: connections via natd suddenly drop and similtaneously, I get errors on the console for the gateway box that natd has "failed to write the packet back (Permission denied)". This is almost exclusively with ssh connections (mostly because they are the most constant long time connections I have to notice this behavior) I have searched the lists and done the arp -s to set a permanent arp setting on all interfaces. I am also on a cable modem (chello). Even stranger, if I don't wait for the session to time out and kill the xterm, the connection stays up on the foreign host for _days_ (there are currently zombie sessions alive that are more than a week old). I do _not_ have the same behavior if I log to/from the gateway box to/from a foreign host. I find this more than a little disturbing. Well, down to the OS specifics: FreeBSD johnny 3.5-STABLE FreeBSD 3.5-STABLE #0: Sat Jun 24 23:35:28 CEST 2000 natd_flags="-f /etc/natd.conf" /etc/natd.conf log yes unregistered_only yes use_sockets yes dynamic yes interface xl0 some relevant sysctl's: net.inet.ip.fw.enable: 1 net.inet.ip.fw.one_pass: 1 net.inet.ip.fw.debug: 1 net.inet.ip.fw.verbose: 1 net.inet.ip.fw.verbose_limit: 100 net.inet.ip.fw.dyn_buckets: 256 net.inet.ip.fw.curr_dyn_buckets: 256 net.inet.ip.fw.dyn_count: 230 net.inet.ip.fw.dyn_max: 1000 net.inet.ip.fw.dyn_ack_lifetime: 1320 net.inet.ip.fw.dyn_syn_lifetime: 20 net.inet.ip.fw.dyn_fin_lifetime: 20 net.inet.ip.fw.dyn_rst_lifetime: 5 net.inet.ip.fw.dyn_short_lifetime: 5 net.inet.tcp.rfc1323: 1 net.inet.tcp.rfc1644: 0 net.inet.tcp.mssdflt: 512 net.inet.tcp.rttdflt: 3 net.inet.tcp.keepidle: 1200 net.inet.tcp.keepintvl: 150 net.inet.tcp.sendspace: 16384 net.inet.tcp.recvspace: 16384 net.inet.tcp.keepinit: 150 net.inet.tcp.log_in_vain: 1 net.inet.tcp.delayed_ack: 1 net.inet.tcp.restrict_rst: 1 net.inet.tcp.pcbcount: 23 net.inet.tcp.always_keepalive: 1 An additional and perhaps related problem is one with passive ftp. I should probably take an entire mail for it alone, but suffice it to say, active ftp works if I open the ports, but passive ftp causes the same failed packet errors. I know how passive ftp works and if I open ports from > 1024 to those (at least for fbsd ftpd's) on the server 49152-65535, I should be able to initiate a data channel. Well, I have had no success. The rule that I propose should work, looks like this: $fwcmd add 10202 allow tcp from ${intnet}:${intmask} 1025-65535 to any 49152-65535 setup keep-state (wrapped here with ) I've tried to tcpdump the connections, but it's a little difficult to watch so many things at the same time: natd aliases, two tcpdumps, and fw rules. I don't see anything hitting a rule either. The first problem is more aggrevating. The second one I have a awkward hack for. Guess I could use some suggestions from people more knowledgeable than I.... A final plea as long as I'm begging anyway: Could someone fix the mailing list search engine? If I can help with it let me know. I use it often, and it is a constant source of frustration, because it is so broken. I'd appreciate a CC as well, because I prefer to track the lists via web. Thanks in advance for any assistance. -- Yours truly, Shaun D. Jurrens shaun@shamz.net shamz@freenix.no IRCNET nick: shamz #chillout #unix #FreeBSD To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 1 3:37: 9 2000 Delivered-To: freebsd-net@freebsd.org Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by hub.freebsd.org (Postfix) with SMTP id 8028A37B6DA; Tue, 1 Aug 2000 03:36:32 -0700 (PDT) (envelope-from T.Pagtzis@cs.ucl.ac.uk) Received: from ppp-2-135.cvx4.telinco.net by bells.cs.ucl.ac.uk with Internet SMTP id ; Tue, 1 Aug 2000 11:36:15 +0100 Message-ID: <000801bffb9b$eab9a1c0$5c401080@cs.ucl.ac.uk> From: "T. Pagtzis" To: net Cc: mobile Subject: stuck with wavelan on desktop (isa bridge) Date: Tue, 1 Aug 2000 10:31:10 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_001A_01BFFBA3.9BE6D2E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is a multi-part message in MIME format. ------=_NextPart_000_001A_01BFFBA3.9BE6D2E0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_001B_01BFFBA3.9BE6D2E0" ------=_NextPart_001_001B_01BFFBA3.9BE6D2E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I have recently upgraded to 4.1 from 3.4 Experiences... I have been runninng on wd0s1x devices despite the fact that I = created the ad0 device set. When I changed it in my fstab file the = bootstrap did not like it...is it supposed to move over to ad0 device = set or would it stay with the old wd0 (non critical though since I can = boot ok with wd0) I have a problem with the wavelan device and getting it to work on a = desktop with the isa bridge (the laptop did fine) Basically I get pccardd to recognize the card but fail badly on irq and = io base. When I changed irq to something specific than ? (say 9,13,etc) = it kept complaining about io base. I do not know how to setup the io = base explicitly for the wavelan (or any pcmcia card), so I would = appreciate if someone could tell me what I have to touch on/configure. Here is my config scripts and dumpcis files so that you can see what I = did As I am stuck with the wavelan on the io base any help would be = appreciated... Thanks Theo ------=_NextPart_001_001B_01BFFBA3.9BE6D2E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
  I have recently upgraded to 4.1 from 3.4
 
Experiences...
 
   I have been runninng on wd0s1x devices despite the = fact that I=20 created the ad0 device set. When I changed it in my fstab file the = bootstrap did=20 not like it...is it supposed to move over to ad0 device set or would it = stay=20 with the old wd0 (non critical though since I can boot ok = with=20 wd0)
 
I have a problem with the wavelan device and getting it to work on = a=20 desktop with the isa bridge (the laptop did fine)
 
Basically I get pccardd to recognize the card but fail badly on irq = and io=20 base. When I changed irq to something specific than ? (say 9,13,etc) it = kept=20 complaining about io base. I do not know how to setup the io base = explicitly for=20 the wavelan (or any pcmcia card), so I would appreciate if someone could = tell me=20 what I have to touch on/configure.
 
Here is my config scripts and dumpcis files so that you can see = what I=20 did
 
As I am stuck with the wavelan on the io base any help would be=20 appreciated...
 
 
Thanks
 
Theo
 
 
------=_NextPart_001_001B_01BFFBA3.9BE6D2E0-- ------=_NextPart_000_001A_01BFFBA3.9BE6D2E0 Content-Type: application/octet-stream; name="cis" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="cis" Configuration data for card in slot 0=0A= Tuple #1, code =3D 0x1 (Common memory descriptor), length =3D 3=0A= 000: 00 00 ff=0A= Common memory device information:=0A= Device number 1, type No device, WPS =3D OFF=0A= Speed =3D No speed, Memory block size =3D 512b, 1 units=0A= Tuple #2, code =3D 0x17 (Attribute memory descriptor), length =3D 4=0A= 000: 67 5a 08 ff=0A= Attribute memory device information:=0A= Device number 1, type SRAM, WPS =3D OFF=0A= Speed =3D 5.0 x 100 ns, Memory block size =3D reserved, 32 units=0A= Device number 2, type No device, WPS =3D OFF=0A= Speed =3D No speed, Memory block size =3D 512b, 1 units=0A= Tuple #3, code =3D 0x1d (Other conditions for attribute memory), length = =3D 5=0A= 000: 01 67 5a 08 ff=0A= (MWAIT)=0A= Tuple #4, code =3D 0x15 (Version 1 info), length =3D 80=0A= 000: 05 00 4c 75 63 65 6e 74 20 54 65 63 68 6e 6f 6c=0A= 010: 6f 67 69 65 73 00 57 61 76 65 4c 41 4e 2f 49 45=0A= 020: 45 45 00 56 65 72 73 69 6f 6e 20 30 31 2e 30 31=0A= 030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00=0A= 040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff=0A= Version =3D 5.0, Manuf =3D [Lucent Technologies], card vers =3D = [WaveLAN/IEEE]=0A= Addit. info =3D [Version 01.01],[]=0A= Tuple #5, code =3D 0x20 (Manufacturer ID), length =3D 4=0A= 000: 56 01 02 00=0A= PCMCIA ID =3D 0x156, OEM ID =3D 0x2=0A= Tuple #6, code =3D 0x21 (Functional ID), length =3D 2=0A= 000: 06 00=0A= Network/LAN adapter=0A= Tuple #7, code =3D 0x22 (Functional EXT), length =3D 2=0A= 000: 01 07=0A= Network technology: Wireless=0A= Tuple #8, code =3D 0x22 (Functional EXT), length =3D 5=0A= 000: 02 40 42 0f 00=0A= Network speed: 1 Mb/sec=0A= Tuple #9, code =3D 0x22 (Functional EXT), length =3D 5=0A= 000: 02 80 84 1e 00=0A= Network speed: 2 Mb/sec=0A= Tuple #10, code =3D 0x22 (Functional EXT), length =3D 5=0A= 000: 02 60 ec 53 00=0A= Network speed: 5 Mb/sec=0A= Tuple #11, code =3D 0x22 (Functional EXT), length =3D 5=0A= 000: 02 c0 d8 a7 00=0A= Network speed: 11 Mb/sec=0A= Tuple #12, code =3D 0x22 (Functional EXT), length =3D 2=0A= 000: 03 07=0A= Network media: 2.4 GHz=0A= Tuple #13, code =3D 0x22 (Functional EXT), length =3D 8=0A= 000: 04 06 00 60 1d 1e 6c 4b=0A= Network node ID: 00 60 1d 1e 6c 4b=0A= Tuple #14, code =3D 0x22 (Functional EXT), length =3D 2=0A= 000: 05 01=0A= Network connector: closed connector standard=0A= Tuple #15, code =3D 0x1a (Configuration map), length =3D 7=0A= 000: 03 01 e0 03 00 00 01=0A= Reg len =3D 4, config register addr =3D 0x3e0, last config =3D 0x1=0A= Registers: X------- =0A= Tuple #16, code =3D 0x1b (Configuration entry), length =3D 15=0A= 000: c1 01 19 76 c5 4b d5 19 36 36 05 46 7f ff ff=0A= Config index =3D 0x1(default)=0A= Interface byte =3D 0x1 (I/O)=0A= Vcc pwr:=0A= Minimum operating supply voltage: 4 x 1V, ext =3D 0x4b=0A= Maximum operating supply voltage: 5 x 1V, ext =3D 0x19=0A= Max current average over 1 second: 3 x 100mA=0A= Max current average over 10 ms: 3 x 100mA=0A= Power down supply current: 1 x 10mA=0A= Card decodes 6 address lines, limited 8/16 Bit I/O=0A= IRQ modes: Level, Pulse=0A= IRQs: NMI IOCK BERR VEND 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15=0A= Tuple #17, code =3D 0xff (Terminator), length =3D 0=0A= 2 slots found=0A= ------=_NextPart_000_001A_01BFFBA3.9BE6D2E0 Content-Type: application/octet-stream; name="Custom" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Custom" #=0A= # GENERIC -- Generic kernel configuration file for FreeBSD/i386=0A= #=0A= # For more information on this file, please read the handbook section on=0A= # Kernel Configuration Files:=0A= #=0A= # http://www.FreeBSD.org/handbook/kernelconfig-config.html=0A= #=0A= # The handbook is also available locally in /usr/share/doc/handbook=0A= # if you've installed the doc distribution, otherwise always see the=0A= # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the=0A= # latest information.=0A= #=0A= # An exhaustive list of options and more detailed explanations of the=0A= # device lines is also present in the ./LINT configuration file. If you = are=0A= # in doubt as to the purpose or necessity of a line, check first in LINT.=0A= #=0A= # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.246.2.8 2000/07/20 02:51:02 = msmith Exp $=0A= =0A= machine i386=0A= cpu I586_CPU=0A= cpu I686_CPU=0A= ident GENERIC=0A= maxusers 32=0A= =0A= #makeoptions DEBUG=3D-g #Build kernel with gdb(1) debug symbols=0A= makeoptions KERNEL=3D41S=0A= =0A= options MATH_EMULATE #Support for x87 emulation=0A= options INET #InterNETworking=0A= options INET6 #IPv6 communications protocols=0A= options FFS #Berkeley Fast Filesystem=0A= options FFS_ROOT #FFS usable as root device [keep this!]=0A= options SOFTUPDATES #Enable FFS soft updates support=0A= options MFS #Memory Filesystem=0A= options MD_ROOT #MD is a potential root device=0A= options NFS #Network Filesystem=0A= options NFS_ROOT #NFS usable as root device, NFS required=0A= options MSDOSFS #MSDOS Filesystem=0A= options CD9660 #ISO 9660 Filesystem=0A= options CD9660_ROOT #CD-ROM usable as root, CD9660 required=0A= options PROCFS #Process filesystem=0A= options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!]=0A= options UCONSOLE #Allow users to grab the console=0A= options USERCONFIG #boot -c editor=0A= options VISUAL_USERCONFIG #visual boot -c editor=0A= options KTRACE #ktrace(1) support=0A= options SYSVSHM #SYSV-style shared memory=0A= options SYSVMSG #SYSV-style message queues=0A= options SYSVSEM #SYSV-style semaphores=0A= options P1003_1B #Posix P1003_1B real-time extensions=0A= options _KPOSIX_PRIORITY_SCHEDULING=0A= options ICMP_BANDLIM #Rate limit bad replies=0A= options KBD_INSTALL_CDEV # install a CDEV entry in /dev=0A= options CPU_FASTER_5X86_FPU=0A= options HZ=3D1000=0A= =0A= device isa=0A= device pci=0A= =0A= # Floppy drives=0A= device fdc0 at isa? port IO_FD1 irq 6 drq 2=0A= device fd0 at fdc0 drive 0=0A= =0A= # ATA and ATAPI devices=0A= device ata0 at isa? port IO_WD1 irq 14=0A= device ata1 at isa? port IO_WD2 irq 15=0A= device ata=0A= device atadisk # ATA disk drives=0A= device atapicd # ATAPI CDROM drives=0A= device atapifd # ATAPI floppy drives=0A= options ATA_STATIC_ID #Static device numbering=0A= #options ATA_ENABLE_ATAPI_DMA #Enable DMA on ATAPI devices=0A= =0A= # atkbdc0 controls both the keyboard and the PS/2 mouse=0A= device atkbdc0 at isa? port IO_KBD=0A= device atkbd0 at atkbdc? irq 1 flags 0x1=0A= device psm0 at atkbdc? irq 12=0A= =0A= device vga0 at isa?=0A= =0A= # splash screen/screen saver=0A= pseudo-device splash=0A= =0A= # syscons is the default console driver, resembling an SCO console=0A= device sc0 at isa? flags 0x100=0A= =0A= # Floating point support - do not disable.=0A= device npx0 at nexus? port IO_NPX irq 13=0A= =0A= # Power management support (see LINT for more options)=0A= device apm0 at nexus? disable flags 0x20 # Advanced Power Management=0A= =0A= # PCCARD (PCMCIA) support=0A= device card=0A= #device pcic0 at isa? irq 10 port 0x3e0 iomem 0xd0000=0A= #device pcic1 at isa? irq 11 port 0x3e2 iomem 0xd4000 disable=0A= device pcic0 at isa? irq 11 port 0x3e2 iomem 0xd0000 =0A= #device pcic0 at isa? irq 11 port 0x3e3=0A= options PCIC_RESUME_RESET=0A= =0A= # Serial (COM) ports=0A= device sio0 at isa? port IO_COM1 flags 0x10 irq 4=0A= device sio1 at isa? port IO_COM2 irq 3=0A= =0A= device pcm=0A= device pca0 at isa? port IO_TIMER1=0A= device bktr=0A= =0A= # PCI Ethernet NICs.=0A= device de # DEC/Intel DC21x4x (``Tulip'')=0A= device fxp # Intel EtherExpress PRO/100B (82557, 82558)=0A= =0A= device wi=0A= device an=0A= #device wi0 at isa? port? net irq?=0A= #device an0 at isa? port? net irq?=0A= =0A= =0A= # Pseudo devices - the number indicates how many units to allocated.=0A= pseudo-device loop # Network loopback=0A= pseudo-device ether # Ethernet support=0A= pseudo-device tun # Packet tunnel.=0A= pseudo-device pty # Pseudo-ttys (telnet etc)=0A= pseudo-device md # Memory "disks"=0A= pseudo-device gif 4 # IPv6 and IPv4 tunneling=0A= pseudo-device faith 1 # IPv6-to-IPv4 relaying (translation)=0A= pseudo-device stf 1 #6to4 IPv6 over IPv4 = encapsulation=0A= pseudo-device bpf #Berkeley packet filter=0A= ------=_NextPart_000_001A_01BFFBA3.9BE6D2E0 Content-Type: application/octet-stream; name="pccard.conf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="pccard.conf" # Default PCCARD configuration file=0A= #=0A= # Removing all IRQ conflicts from this file can't be done because of some=0A= # IRQ-selfish PC-cards. So if you want to use some of these cards in=0A= # your machine, you will be forced to modify their IRQ parameters from=0A= # the following list.=0A= #=0A= # IRQ =3D=3D 0 means "allocate free IRQ from IRQ pool"=0A= # IRQ =3D=3D 16 means "do not use IRQ (e.g. PIO mode)"=0A= #=0A= # $FreeBSD: src/etc/defaults/pccard.conf,v 1.98.2.3 2000/07/19 12:58:12 = sanpei Exp $=0A= #=0A= # Send new entries for this file to imp@freebsd.org. He's volunteered=0A= # to act as coordinator for this file.=0A= #=0A= =0A= # Generally available IO ports=0A= io 0x240-0x360=0A= # Generally available IRQs (Built-in sound-card owners remove 5)=0A= irq 3 5 10 11 15=0A= # Available memory slots=0A= memory 0xd4000 96k=0A= =0A= # Include user configration file=0A= # This allow you to override or add configurations.=0A= include /etc/pccard.conf=0A= =0A= #=0A= # PLEASE KEEP THIS FILE IN ORDER=0A= #=0A= # In order is defined as follows. We sort first by driver type (an, ed, = etc)=0A= # and then by CIS strings. Do not commit to this file entries out of=0A= # order.=0A= #=0A= =0A= =0A= ########## wi ##########=0A= =0A= # Cabletron RoamAbout, WaveLAN/IEEE clone=0A= card "Cabletron" "RoamAbout 802.11 DS"=0A= config 0x1 "wi" ?=0A= insert /etc/pccard_ether $device=0A= remove /sbin/ifconfig $device delete=0A= =0A= # Lucent WaveLAN/IEEE=0A= card "Lucent Technologies" "WaveLAN/IEEE"=0A= config 0x1 "wi" 9 =0A= insert /etc/pccard_ether $device=0A= remove /sbin/ifconfig $device delete=0A= =0A= # NCR WaveLAN/IEEE=0A= card "NCR" "WaveLAN/IEEE"=0A= config 0x1 "wi" ?=0A= # config auto "wi" ?=0A= insert /etc/pccard_ether $device=0A= remove /sbin/ifconfig $device delete=0A= =0A= # Melco Airconnect=0A= card "MELCO" "WLI-PCM-L11"=0A= config 0x1 "wi" ?=0A= insert /etc/pccard_ether $device=0A= remove /sbin/ifconfig $device delete=0A= =0A= # PLANEX GeoWave/GW-NS110=0A= card "PLANEX" "GeoWave/GW-NS110"=0A= config 0x1 "wi" ?=0A= insert /etc/pccard_ether $device=0A= remove /sbin/ifconfig $device delete=0A= =0A= ########## xe ##########=0A= =0A= # Accton EN2226/Fast EtherCard (16-bit verison)=0A= card "Accton" "Fast EtherCard-16"=0A= config default "xe" ?=0A= insert /etc/pccard_ether $device=0A= remove /sbin/ifconfig $device delete=0A= =0A= # Compaq Netelligent 10/100 PC Card=0A= card "Compaq" "Netelligent 10/100 PC Card"=0A= config 0x1 "xe" ?=0A= insert /etc/pccard_ether $device=0A= remove sbin/ifconfig $device delete=0A= =0A= # Intel EtherExpress PRO/100 Mobile Adapter (16-bit verison)=0A= card "Intel" "EtherExpress(TM) PRO/100 PC Card Mobile Adapter16"=0A= config 0x1 "xe" ?=0A= insert /etc/pccard_ether $device=0A= remove /sbin/ifconfig $device delete=0A= =0A= # XXX NOT SURE SUPPORTED=0A= # Toshiba 10/100 Ethernet PC Card IPC5008A=0A= #card "Toshiba" "10/100 Ethernet PC Card"=0A= # config auto "xe" ?=0A= ## cardio 0x300 0x10=0A= # iosize 16=0A= # insert /etc/pccard_ether $device=0A= # remove /sbin/ifconfig $device delete=0A= =0A= # Xircom Realport card + modem=0A= card "Xircom" "16-bit Ethernet + Modem 56"=0A= config 0x27 "xe" 9=0A= insert /etc/pccard_ether $device=0A= remove /etc/pccard_ether $device delete=0A= =0A= # Xircom CreditCard Ethernet 10/100=0A= card "Xircom" "CreditCard 10/100"=0A= config 0x1 "xe" ?=0A= insert /etc/pccard_ether $device=0A= remove /etc/pccard_ether $device delete=0A= =0A= # Xircom CreditCard 10Base-T "CreditCard Ethernet Adaptor IIps" = (PS-CE2-10)=0A= card "Xircom" "CreditCard 10Base-T"=0A= config auto "xe" ?=0A= insert /etc/pccard_ether $device=0A= remove /sbin/ifconfig $device delete=0A= =0A= # Xircom CreditCard Ethernet 10/100 + modem (Ethernet part)=0A= card "Xircom" "CreditCard Ethernet 10/100 + Modem 56"=0A= config 0x27 "xe" ?=0A= insert /etc/pccard_ether $device=0A= remove /sbin/ifconfig $device delete=0A= =0A= # -------------------------------------------------------------------=0A= # =0A= # "Wildcard" entries=0A= # =0A= # -------------------------------------------------------------------=0A= =0A= # GENERIC PCMCIA modem=0A= generic serial=0A= config auto "sio" ?=0A= reset 10000 # for unstable cards=0A= logstr "GENERIC PCMCIA modem"=0A= =0A= # GENERIC Flash ATA / ATA HDD=0A= generic fixed_disk=0A= config auto "ata" ?=0A= logstr "GENERIC Flash ATA / ATA HDD"=0A= ------=_NextPart_000_001A_01BFFBA3.9BE6D2E0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 1 10: 0:21 2000 Delivered-To: freebsd-net@freebsd.org Received: from mail.rdc1.il.home.com (ha1.rdc1.il.home.com [24.2.1.66]) by hub.freebsd.org (Postfix) with ESMTP id 2F19437BF9C for ; Tue, 1 Aug 2000 10:00:17 -0700 (PDT) (envelope-from stephen@math.missouri.edu) Received: from math.missouri.edu ([24.12.197.197]) by mail.rdc1.il.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20000801170014.EEFP21928.mail.rdc1.il.home.com@math.missouri.edu>; Tue, 1 Aug 2000 10:00:14 -0700 Message-ID: <39870232.F1E1C38C@math.missouri.edu> Date: Tue, 01 Aug 2000 12:00:34 -0500 From: Stephen Montgomery-Smith X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Ruslan Ermilov Cc: Gregory Bond , net@FreeBSD.org Subject: Re: conf/20197: rc.firewall with firewall_type=simple doesn't work with natd References: <200007262240.PAA88875@freefall.freebsd.org> <20000731190439.A75240@sunbay.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I think that rc.firewall should serve two purposes: 1) In as much as possible, it should work right out of the box. 2) It should teach the newbie to firewalls - by looking at the code he/she should learn about firewalls (that's how I learned - a week ago I was a newbie - and actually still am). I think Ruslan Ermilov's suggested patch succeeds admirably in both these respects. The change of position of the natd command is clear, and should alert the reader that there is a reason for it. Perhaps the only change I would make is to keep a comment explaining briefly why the natd is positioned where it is. But I can understand if others feel it unnecessary. -- Stephen Montgomery-Smith stephen@math.missouri.edu http://www.math.missouri.edu/~stephen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 1 13:34: 6 2000 Delivered-To: freebsd-net@freebsd.org Received: from fep02-svc.mail.telepac.pt (fep02-svc.mail.telepac.pt [194.65.5.201]) by hub.freebsd.org (Postfix) with ESMTP id 8FF6B37B69C for ; Tue, 1 Aug 2000 13:34:03 -0700 (PDT) (envelope-from jfsasilva@mail.telepac.pt) Received: from mop35705 ([194.65.241.4]) by fep02-svc.mail.telepac.pt (InterMail vM.4.01.02.27 201-229-119-110) with SMTP id <20000801203811.KLEG12634.fep02-svc.mail.telepac.pt@mop35705> for ; Tue, 1 Aug 2000 21:38:11 +0100 Message-ID: <002101bffbf7$338aede0$04f141c2@mop35705.telepac.pt> From: "Jorge Sa' Silva" To: Subject: unsuscribe Date: Tue, 1 Aug 2000 21:29:32 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001E_01BFFBFF.94B84600" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is a multi-part message in MIME format. ------=_NextPart_000_001E_01BFFBFF.94B84600 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable unsuscribe ------=_NextPart_000_001E_01BFFBFF.94B84600 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
unsuscribe
------=_NextPart_000_001E_01BFFBFF.94B84600-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 1 13:51:57 2000 Delivered-To: freebsd-net@freebsd.org Received: from sn1oexchr01.nextvenue.com (sn1oexchr01.nextvenue.com [63.209.169.9]) by hub.freebsd.org (Postfix) with SMTP id 6DFD937BD80 for ; Tue, 1 Aug 2000 13:51:49 -0700 (PDT) (envelope-from nevans@nextvenue.com) Received: FROM sn1exchmbx.nextvenue.com BY sn1oexchr01.nextvenue.com ; Tue Aug 01 16:49:56 2000 -0400 Received: by sn1exchmbx.nextvenue.com with Internet Mail Service (5.5.2650.21) id ; Tue, 1 Aug 2000 16:47:16 -0400 Message-ID: <712384017032D411AD7B0001023D799B33B188@sn1exchmbx.nextvenue.com> From: Nick Evans To: "'freebsd-net@freebsd.org'" , "'freebsd-hackers@freebsd.org'" , "'freebsd-isp@freebsd.org'" Subject: Teaming Network Interfaces Date: Tue, 1 Aug 2000 16:47:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFFBF9.AD4B87A0" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFFBF9.AD4B87A0 Content-Type: text/plain; charset="iso-8859-1" Does anyone know of a project or other plans to implement teaming of network interfaces in FreeBSD? Something that will allow two or more NICs share the "same" IP Address, MAC address, etc. for network fault tolerance purposes? I found nothing in the archives and it's pretty disconcerting that no one is spending any time on fault tolerance for a network operating system. thx nick ------------------------------------------ nick.evans network.engineering NextVenue, Inc. phone: (212) 909.2988 pager: (888) 642.5541 ------_=_NextPart_001_01BFFBF9.AD4B87A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Teaming Network Interfaces

Does anyone know of a project or other plans to = implement teaming of network interfaces in FreeBSD? Something that will = allow two or more NICs share the "same" IP Address, MAC = address, etc. for network fault tolerance purposes? I found nothing in = the archives and it's pretty disconcerting that no one is spending any = time on fault tolerance for a network operating system.

thx
nick

------------------------------------------
nick.evans
network.engineering
NextVenue, Inc.
phone: (212) 909.2988
pager: (888) 642.5541

------_=_NextPart_001_01BFFBF9.AD4B87A0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 1 14:38:50 2000 Delivered-To: freebsd-net@freebsd.org Received: from zoe2.qserve.net (zoe2.qserve.net [207.250.219.4]) by hub.freebsd.org (Postfix) with ESMTP id 3CA0037BE2C for ; Tue, 1 Aug 2000 14:38:47 -0700 (PDT) (envelope-from rch@qserve.net) Received: from acidic.qserve.net (acidic.qserve.net [207.250.219.40]) by zoe2.qserve.net (8.10.1/8.10.1) with ESMTP id e71LckD26602 for ; Tue, 1 Aug 2000 16:38:47 -0500 (EST) Message-Id: <4.3.1.2.20000801163822.01db7e00@qserve.net> X-Sender: rch@qserve.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Tue, 01 Aug 2000 16:39:55 -0500 To: freebsd-net@FreeBSD.ORG From: Robert Hough Subject: OT: Bandwidth Limiting Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Anyone have some advice on bandwidth limiting hardware and/or software? Any switched out there capable of doing something like this? -- Robert Hough (rch@qserve.net) Qserve Internet, Inc. http://www.qserve.net/ Ph: (317)802-3036 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 1 14:43:12 2000 Delivered-To: freebsd-net@freebsd.org Received: from bubba.whistle.com (bubba.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id 08BBC37BE60 for ; Tue, 1 Aug 2000 14:43:10 -0700 (PDT) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.3) id OAA65460; Tue, 1 Aug 2000 14:43:01 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200008012143.OAA65460@bubba.whistle.com> Subject: Re: OT: Bandwidth Limiting In-Reply-To: <4.3.1.2.20000801163822.01db7e00@qserve.net> from Robert Hough at "Aug 1, 2000 04:39:55 pm" To: Robert Hough Date: Tue, 1 Aug 2000 14:43:01 -0700 (PDT) Cc: freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL68 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Robert Hough writes: > Anyone have some advice on bandwidth limiting hardware and/or software? > Any switched out there capable of doing something like this? Check out dummynet(4). -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 1 19: 0: 7 2000 Delivered-To: freebsd-net@freebsd.org Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by hub.freebsd.org (Postfix) with SMTP id 2883837B5E5 for ; Tue, 1 Aug 2000 19:00:03 -0700 (PDT) (envelope-from pingpan@research.bell-labs.com) Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by crufty; Tue Aug 1 21:59:01 EDT 2000 Received: from research.bell-labs.com (pingpan.lra.lucent.com [135.255.37.60]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id VAA15865; Tue, 1 Aug 2000 21:58:58 -0400 (EDT) Message-ID: <39877FCD.AC968B74@research.bell-labs.com> Date: Tue, 01 Aug 2000 21:56:29 -0400 From: Ping Pan Organization: Bell Labs, Lucent X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: itojun@iijlab.net Cc: freebsd-net@freebsd.org Subject: Re: Fwd: A new kernel extension to deal with IP option packets References: <19654.965020987@coconut.itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org itojun@iijlab.net wrote: > > > you want to look at RFC2292, and draft-ietf-ipngwg-2292bis. > RFC2292 specifies how you can manipulate IPv6 extension headers > (header chains between IP and TCP/UDP header, has similar role to > IPv4 options), using ancillary data stream. it gives you much higher > flexibility and control, without additional address family > (i think we shouldn't define address family for this). > > itojun > Hello, Itojun, I could not find you in IETF. So here is my response: after reading through some of the FrreBSD kernel code on IPv6 and the RFC, it has the same problem as in IPv4. That is, the user needs to open a raw socket first with a protocol family and a protocol type. Only then you may use setsockopt() to receive the option that you want. This mechanism is pretty much the same as in IPv4. The problem that we are trying to solve is to intercept the IP packets *only* base on their IP option types. The protocol type is irrelevant here. I don't see this is solved in IPv6 RFC and drafts. WRT the need of a new socket family, please recommend a better method to solve the problem. Thanks! - Ping Pan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 1 20:29:35 2000 Delivered-To: freebsd-net@freebsd.org Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by hub.freebsd.org (Postfix) with ESMTP id A907137BF6A for ; Tue, 1 Aug 2000 20:29:26 -0700 (PDT) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from localhost (shuttle.sixyards.wide.toshiba.co.jp [3ffe:501:100f:0:200:f8ff:fe01:61cf]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id MAA24745; Wed, 2 Aug 2000 12:14:35 +0900 (JST) Date: Wed, 02 Aug 2000 12:24:47 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: pingpan@research.bell-labs.com Cc: freebsd-net@FreeBSD.ORG Subject: Re: Fwd: A new kernel extension to deal with IP option packets In-Reply-To: In your message of "Tue, 01 Aug 2000 21:56:29 -0400" <39877FCD.AC968B74@research.bell-labs.com> References: <19654.965020987@coconut.itojun.org> <39877FCD.AC968B74@research.bell-labs.com> User-Agent: Wanderlust/2.3.0 (Roam) Emacs/20.6 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 31 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >>>>> On Tue, 01 Aug 2000 21:56:29 -0400, >>>>> Ping Pan said: >> you want to look at RFC2292, and draft-ietf-ipngwg-2292bis. >> RFC2292 specifies how you can manipulate IPv6 extension headers >> (header chains between IP and TCP/UDP header, has similar role to >> IPv4 options), using ancillary data stream. it gives you much higher >> flexibility and control, without additional address family >> (i think we shouldn't define address family for this). > I could not find you in IETF. So here is my response: after reading > through some of the FrreBSD kernel code on IPv6 and the RFC, it has the > same > problem as in IPv4. That is, the user needs to open a raw socket first > with a protocol family and a protocol type. Only then you may use > setsockopt() to receive the option that you want. This mechanism is > pretty much the same as in IPv4. No. You can get IPv6 extension headers of packets via RFC2292 (or 2292bis), regardless of the transport layer protocols. However, > The problem that we are trying to solve is to intercept the IP packets > *only* base on their IP option types. The protocol type is irrelevant > here. I don't see this is solved in IPv6 RFC and drafts. I'm not sure if 2292 (or 22292bis) can be used to satisfy this goal. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 1 20:54:53 2000 Delivered-To: freebsd-net@freebsd.org Received: from hotmail.com (f79.law10.hotmail.com [64.4.15.79]) by hub.freebsd.org (Postfix) with SMTP id CD38237BF9B for ; Tue, 1 Aug 2000 20:54:50 -0700 (PDT) (envelope-from dispensa@hotmail.com) Received: (qmail 36203 invoked by uid 0); 2 Aug 2000 03:53:19 -0000 Message-ID: <20000802035319.36202.qmail@hotmail.com> Received: from 209.242.124.252 by www.hotmail.com with HTTP; Tue, 01 Aug 2000 20:53:19 PDT X-Originating-IP: [209.242.124.252] From: "Steve Dispensa" To: freebsd-net@freebsd.org Subject: libpcap, BPF, and 100% CPU Date: Tue, 01 Aug 2000 22:53:19 CDT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I'm not sure if this is the right forum for this, but... I'm working on a packet-capture program for some protocol analysis of a proprietary UDP-based protocol. I'm using libpcap on FreeBSD 4.0-release. It's thread-based, with a thread for capturing and a thread for reporting. I'm compiling it with 'cc -pthread -lpcap -g -o sniff sniff.c' - which should link it against the right libraries for thread support. The problem is that it nails the processor at 100% (I've tested the same bpf program with tcpdump, and it idles at 0%). Then, after some time (1-3 minutes), the box either reboots (!) or the program just dumps core. Occasionally I get "segmentation fault"; other times I get "bus error". Now, I'm pretty sure I'm doing something wrong here - I've run pcap programs before on other platforms without 100% CPU usage - but the box rebooting itself sounds like a bad (hardware) sign. Any ideas? --Steve ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 1 22:41: 7 2000 Delivered-To: freebsd-net@freebsd.org Received: from boruta.demo.pl (boruta.demo.pl [212.244.219.19]) by hub.freebsd.org (Postfix) with ESMTP id 3C80737BFFB for ; Tue, 1 Aug 2000 22:41:04 -0700 (PDT) (envelope-from maliniak@demo.pl) Received: from shaker (shaker.demo.pl [212.244.219.37]) by boruta.demo.pl (8.10.2/8.10.2) with SMTP id e725f0n06996 for ; Wed, 2 Aug 2000 07:41:01 +0200 (CEST) Message-ID: <009401bffc44$8218eaf0$25dbf4d4@demo.pl> From: "Grzegorz Malinka" To: References: <20000802035319.36202.qmail@hotmail.com> Subject: Date: Wed, 2 Aug 2000 07:42:54 +0200 Organization: ISP @ Demo-Net MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2417.2000 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org unsubscribe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 1 23: 5:52 2000 Delivered-To: freebsd-net@freebsd.org Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by hub.freebsd.org (Postfix) with SMTP id CDEFC37B720; Tue, 1 Aug 2000 23:05:43 -0700 (PDT) (envelope-from T.Pagtzis@cs.ucl.ac.uk) Received: from ppp-1-58.cvx4.telinco.net by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 2 Aug 2000 07:05:39 +0100 Message-ID: <000001bffc3f$487612a0$5c401080@cs.ucl.ac.uk> From: "T. Pagtzis" To: net Cc: mobile Subject: Wavelan working now in desktop and isa bridge.. Date: Tue, 1 Aug 2000 11:13:21 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001A_01BFFBA9.80EFB0A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is a multi-part message in MIME format. ------=_NextPart_000_001A_01BFFBA9.80EFB0A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, I have found out the cause of the problem with regard to wavelan being = recognized by the desktop..The base io as specified in pccard.conf is = probably low..I have changed 0x240 with 0x280 and works fine...people = may want to update their pccard.conf so that they do not run into this = problem.. Cheers Theo ------=_NextPart_000_001A_01BFFBA9.80EFB0A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all,
 
  I have found out the cause of the problem with regard to = wavelan=20 being recognized by the desktop..The base io as specified in pccard.conf = is=20 probably low..I have changed 0x240 with 0x280 and works fine...people = may want=20 to update their pccard.conf so that they do not run into this = problem..
 
Cheers
 
Theo
------=_NextPart_000_001A_01BFFBA9.80EFB0A0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 1 23: 8: 4 2000 Delivered-To: freebsd-net@freebsd.org Received: from hotmail.com (f55.law10.hotmail.com [64.4.15.55]) by hub.freebsd.org (Postfix) with SMTP id 72B2437BB55 for ; Tue, 1 Aug 2000 23:08:02 -0700 (PDT) (envelope-from dispensa@hotmail.com) Received: (qmail 38734 invoked by uid 0); 2 Aug 2000 06:07:04 -0000 Message-ID: <20000802060704.38733.qmail@hotmail.com> Received: from 209.242.124.252 by www.hotmail.com with HTTP; Tue, 01 Aug 2000 23:07:04 PDT X-Originating-IP: [209.242.124.252] From: "Steve Dispensa" To: freebsd-net@freebsd.org Subject: Followup: pthreads + bpf Date: Wed, 02 Aug 2000 01:07:04 CDT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org After some additional tinkering, it seems like the combination of bpf and pthreads causes the cpu to go to 100%. I can compile tcpdump normally and it idles at 0% cpu, but if I add the -pthread switch to gcc and relink, it's a 100% cpu situation again. Just guessing here, it seems like when the interface is in promiscuous mode and ioctl'd by bpf calls, read() is returning on no packet rather than blocking as it should, which is causing a busy-loop. Am I off track here? Any advice? TIA. --Steve ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Aug 2 1:25:58 2000 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 DBCD537C0BD for ; Wed, 2 Aug 2000 01:25:45 -0700 (PDT) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.9.3/1.13) id LAA40548; Wed, 2 Aug 2000 11:24:58 +0300 (EEST) Date: Wed, 2 Aug 2000 11:24:58 +0300 From: Ruslan Ermilov To: Archie Cobbs Cc: Charles Mott , Erik Salander , net@FreeBSD.ORG, Julian Elischer , Brian Somers , Eivind Eklund Subject: Re: Improved PPTP support for libalias(3) Message-ID: <20000802112458.B38876@sunbay.com> Mail-Followup-To: Archie Cobbs , Charles Mott , Erik Salander , net@FreeBSD.ORG, Julian Elischer , Brian Somers , Eivind Eklund References: <200007281735.KAA25478@bubba.whistle.com> <200007281941.MAA26153@bubba.whistle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200007281941.MAA26153@bubba.whistle.com>; from archie@whistle.com on Fri, Jul 28, 2000 at 12:41:34PM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Jul 28, 2000 at 12:41:34PM -0700, Archie Cobbs wrote: > Archie Cobbs writes: > > > Is this a limitation of a specific server implementation, or > > > a limitation of the PPTP standard? > > > > It's simply a limitation in our address translation module for PPTP. > > There's nothing implied wrong with the standard itself or the server > > implementation. > > > > This limitation could be eliminated with more coding, but it's > > somewhat ugly (you have to make two TCP streams appear as one). > > Sorry, I may have misinterpreted your question... > > It is inherent in the PPTP standard that there be at most ONE > PPTP TCP control connection between any two IP addresses. > > If you think about it for a second you can see why: when a machine > receives a GRE packet, it identifies the call using the pair > . That means that there can be at most ONE entity > living at sourceIP doling out CallID's for calls to the local > machine/IP address.. otherwise CallID's would not be guaranteed > to be unique. > This is all right, except libalias(3) is supposed to intercept outgoing PPTP call requests messages and alias CallID to be unique, see AliasHandlePptpOut(). -- 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 Aug 2 3:54:31 2000 Delivered-To: freebsd-net@freebsd.org Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by hub.freebsd.org (Postfix) with ESMTP id 026F137B50D for ; Wed, 2 Aug 2000 03:54:29 -0700 (PDT) (envelope-from itojun@itojun.org) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id TAA20537; Wed, 2 Aug 2000 19:54:23 +0900 (JST) To: Ping Pan Cc: freebsd-net@freebsd.org In-reply-to: pingpan's message of Tue, 01 Aug 2000 21:56:29 -0400. <39877FCD.AC968B74@research.bell-labs.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Fwd: A new kernel extension to deal with IP option packets From: itojun@iijlab.net Date: Wed, 02 Aug 2000 19:54:23 +0900 Message-ID: <20535.965213663@coconut.itojun.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Hello, Itojun, > >I could not find you in IETF. So here is my response: after reading >through some of the FrreBSD kernel code on IPv6 and the RFC, it has the >same >problem as in IPv4. That is, the user needs to open a raw socket first >with a protocol family and a protocol type. Only then you may use >setsockopt() to receive the option that you want. This mechanism is >pretty much the same as in IPv4. > >The problem that we are trying to solve is to intercept the IP packets >*only* base on their IP option types. The protocol type is irrelevant >here. I don't see this is solved in IPv6 RFC and drafts. you mean router alert option? you may want to look at ip6_input(). there's some code in it. router alert option is standardized enough, and i don't think you need additional AF for it. itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Aug 2 9:25:18 2000 Delivered-To: freebsd-net@freebsd.org Received: from bubba.whistle.com (bubba.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id 6FDDD37B5A6; Wed, 2 Aug 2000 09:25:15 -0700 (PDT) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.3) id JAA81509; Wed, 2 Aug 2000 09:25:13 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200008021625.JAA81509@bubba.whistle.com> Subject: Re: Improved PPTP support for libalias(3) In-Reply-To: <20000802112458.B38876@sunbay.com> from Ruslan Ermilov at "Aug 2, 2000 11:24:58 am" To: Ruslan Ermilov Date: Wed, 2 Aug 2000 09:25:13 -0700 (PDT) Cc: Archie Cobbs , Charles Mott , Erik Salander , net@FreeBSD.ORG, Julian Elischer , Brian Somers , Eivind Eklund X-Mailer: ELM [version 2.4ME+ PL68 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Ruslan Ermilov writes: > > > > Is this a limitation of a specific server implementation, or > > > > a limitation of the PPTP standard? > > > > > > It's simply a limitation in our address translation module for PPTP. > > > There's nothing implied wrong with the standard itself or the server > > > implementation. > > > > > > This limitation could be eliminated with more coding, but it's > > > somewhat ugly (you have to make two TCP streams appear as one). > > > > Sorry, I may have misinterpreted your question... > > > > It is inherent in the PPTP standard that there be at most ONE > > PPTP TCP control connection between any two IP addresses. > > > > If you think about it for a second you can see why: when a machine > > receives a GRE packet, it identifies the call using the pair > > . That means that there can be at most ONE entity > > living at sourceIP doling out CallID's for calls to the local > > machine/IP address.. otherwise CallID's would not be guaranteed > > to be unique. > > This is all right, except libalias(3) is supposed to intercept > outgoing PPTP call requests messages and alias CallID to be unique, > see AliasHandlePptpOut(). Sorry, I don't understand your point... libalias already does this fine, that's not the problem. The problem is that two internal clients connecting to the same external server at the same time will result in two TCP connections to the same server seeming to come from the same IP address, which violates the protocol. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Aug 2 9:51:20 2000 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 651BD37B971 for ; Wed, 2 Aug 2000 09:51:15 -0700 (PDT) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.9.3/1.13) id TAA37378; Wed, 2 Aug 2000 19:49:01 +0300 (EEST) Date: Wed, 2 Aug 2000 19:49:01 +0300 From: Ruslan Ermilov To: Archie Cobbs Cc: Charles Mott , Erik Salander , net@FreeBSD.ORG, Julian Elischer , Brian Somers , Eivind Eklund Subject: Re: Improved PPTP support for libalias(3) Message-ID: <20000802194901.D36141@sunbay.com> Mail-Followup-To: Archie Cobbs , Charles Mott , Erik Salander , net@FreeBSD.ORG, Julian Elischer , Brian Somers , Eivind Eklund References: <20000802112458.B38876@sunbay.com> <200008021625.JAA81509@bubba.whistle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200008021625.JAA81509@bubba.whistle.com>; from archie@whistle.com on Wed, Aug 02, 2000 at 09:25:13AM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Aug 02, 2000 at 09:25:13AM -0700, Archie Cobbs wrote: > Ruslan Ermilov writes: > > > > > Is this a limitation of a specific server implementation, or > > > > > a limitation of the PPTP standard? > > > > > > > > It's simply a limitation in our address translation module for PPTP. > > > > There's nothing implied wrong with the standard itself or the server > > > > implementation. > > > > > > > > This limitation could be eliminated with more coding, but it's > > > > somewhat ugly (you have to make two TCP streams appear as one). > > > > > > Sorry, I may have misinterpreted your question... > > > > > > It is inherent in the PPTP standard that there be at most ONE > > > PPTP TCP control connection between any two IP addresses. > > > > > > If you think about it for a second you can see why: when a machine > > > receives a GRE packet, it identifies the call using the pair > > > . That means that there can be at most ONE entity > > > living at sourceIP doling out CallID's for calls to the local > > > machine/IP address.. otherwise CallID's would not be guaranteed > > > to be unique. > > > > This is all right, except libalias(3) is supposed to intercept > > outgoing PPTP call requests messages and alias CallID to be unique, > > see AliasHandlePptpOut(). > > Sorry, I don't understand your point... libalias already does this fine, > that's not the problem. > > The problem is that two internal clients connecting to the same > external server at the same time will result in two TCP connections > to the same server seeming to come from the same IP address, which > violates the protocol. > Sorry, I misinterpreted your explanation. But I still do not understand why there is such a limitation in PPTP, can you see any sense here? -- 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 Aug 2 9:52:51 2000 Delivered-To: freebsd-net@freebsd.org Received: from bubba.whistle.com (bubba.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id 8E64137B971; Wed, 2 Aug 2000 09:52:47 -0700 (PDT) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.3) id JAA81974; Wed, 2 Aug 2000 09:52:46 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200008021652.JAA81974@bubba.whistle.com> Subject: Re: Improved PPTP support for libalias(3) In-Reply-To: <20000802194901.D36141@sunbay.com> from Ruslan Ermilov at "Aug 2, 2000 07:49:01 pm" To: Ruslan Ermilov Date: Wed, 2 Aug 2000 09:52:46 -0700 (PDT) Cc: Archie Cobbs , Charles Mott , Erik Salander , net@FreeBSD.ORG, Julian Elischer , Brian Somers , Eivind Eklund X-Mailer: ELM [version 2.4ME+ PL68 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Ruslan Ermilov writes: > > > > > > Is this a limitation of a specific server implementation, or > > > > > > a limitation of the PPTP standard? > > > > > > > > > > It's simply a limitation in our address translation module for PPTP. > > > > > There's nothing implied wrong with the standard itself or the server > > > > > implementation. > > > > > > > > > > This limitation could be eliminated with more coding, but it's > > > > > somewhat ugly (you have to make two TCP streams appear as one). > > > > > > > > Sorry, I may have misinterpreted your question... > > > > > > > > It is inherent in the PPTP standard that there be at most ONE > > > > PPTP TCP control connection between any two IP addresses. > > > > > > > > If you think about it for a second you can see why: when a machine > > > > receives a GRE packet, it identifies the call using the pair > > > > . That means that there can be at most ONE entity > > > > living at sourceIP doling out CallID's for calls to the local > > > > machine/IP address.. otherwise CallID's would not be guaranteed > > > > to be unique. ^^^^^^^^^^^^^^^^^ this is why ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > This is all right, except libalias(3) is supposed to intercept > > > outgoing PPTP call requests messages and alias CallID to be unique, > > > see AliasHandlePptpOut(). > > > > Sorry, I don't understand your point... libalias already does this fine, > > that's not the problem. > > > > The problem is that two internal clients connecting to the same > > external server at the same time will result in two TCP connections > > to the same server seeming to come from the same IP address, which > > violates the protocol. > > Sorry, I misinterpreted your explanation. But I still do not understand > why there is such a limitation in PPTP, can you see any sense here? Because there can be only one "controlling authority" for each IP address.. see above. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Aug 2 10:37: 8 2000 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 7A8C137B6B8; Wed, 2 Aug 2000 10:37:00 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org (InterJet.elischer.org [192.168.1.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id KAA79596; Wed, 2 Aug 2000 10:36:56 -0700 (PDT) Date: Wed, 2 Aug 2000 10:36:55 -0700 (PDT) From: Julian Elischer To: Archie Cobbs Cc: Ruslan Ermilov , Charles Mott , Erik Salander , net@FreeBSD.ORG, Brian Somers , Eivind Eklund Subject: Re: Improved PPTP support for libalias(3) In-Reply-To: <200008021625.JAA81509@bubba.whistle.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 2 Aug 2000, Archie Cobbs wrote: > > Sorry, I don't understand your point... libalias already does this fine, > that's not the problem. > > The problem is that two internal clients connecting to the same > external server at the same time will result in two TCP connections > to the same server seeming to come from the same IP address, which > violates the protocol. you could do this using the ipfw 'forward' keyword, to redirect the streams from the clients to a proxy subprocess in the natd process, which would aggregate as needed onto a separate tcp stream it runs itself. I'm a little confused though. PPTP isn't running over TCP.. or are you indicating that the TCP sreams under GRE are 'fiddled' by natd? > -Archie > > ___________________________________________________________________________ > Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Aug 2 10:41:17 2000 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id AFCFD37BD00; Wed, 2 Aug 2000 10:41:12 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org (InterJet.elischer.org [192.168.1.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id KAA79609; Wed, 2 Aug 2000 10:41:10 -0700 (PDT) Date: Wed, 2 Aug 2000 10:41:09 -0700 (PDT) From: Julian Elischer To: Archie Cobbs Cc: Ruslan Ermilov , Charles Mott , Erik Salander , net@FreeBSD.ORG, Brian Somers , Eivind Eklund Subject: Re: Improved PPTP support for libalias(3) In-Reply-To: <200008021652.JAA81974@bubba.whistle.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 2 Aug 2000, Archie Cobbs wrote: > > > > > If you think about it for a second you can see why: when a machine > > > > > receives a GRE packet, it identifies the call using the pair > > > > > . That means that there can be at most ONE entity > > > > > living at sourceIP doling out CallID's for calls to the local > > > > > machine/IP address.. otherwise CallID's would not be guaranteed > > > > > to be unique. > > ^^^^^^^^^^^^^^^^^ this is why ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > > This is all right, except libalias(3) is supposed to intercept > > > > outgoing PPTP call requests messages and alias CallID to be unique, > > > > see AliasHandlePptpOut(). > > Because there can be only one "controlling authority" for each > IP address.. see above. but surely, the CALLID is unique in the instance of NATD, which is a 1:1 relationship with the SourceIP that teh server sees, so there is only ever one CALLID/SRCIP pair per session and they are unique. even with multiple clients behind the nat curtain. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Aug 2 11:14:23 2000 Delivered-To: freebsd-net@freebsd.org Received: from mrout1.yahoo.com (mrout1.yahoo.com [208.48.125.95]) by hub.freebsd.org (Postfix) with ESMTP id 4C5C237BDEC for ; Wed, 2 Aug 2000 11:14:19 -0700 (PDT) (envelope-from jayanth@yahoo-inc.com) Received: from milk.yahoo.com (milk.yahoo.com [206.251.16.37]) by mrout1.yahoo.com (8.10.0/8.10.0/y.out) with ESMTP id e72IEC750436 for ; Wed, 2 Aug 2000 11:14:16 -0700 (PDT) Received: (from jayanth@localhost) by milk.yahoo.com (8.8.8/8.6.12) id LAA01215 for freebsd-net@FreeBSD.ORG; Wed, 2 Aug 2000 11:14:12 -0700 (PDT) Date: Wed, 2 Aug 2000 11:14:12 -0700 From: jayanth To: freebsd-net@FreeBSD.ORG Subject: Max data queued for UDP Message-ID: <20000802111412.A29943@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1us Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org while running some tests for udp with very small packets(25 bytes) I found that the total amount of data that can be queued at the socket buffer(just queued, not read) is very limited, close to around 4k - 5k bytes. One of the issues is that the driver uses a cluster for every data packet, however small the data packet is. There is a per socket limit on the total amount of network memory that can be used for a socket (sb->sb_mbmax), which is typically 256k. There is also a variable that keeps count of the total n/w network memory actually used by the socket (sb->mb_cnt). The mb_cnt variable is incremented by a cluster + sizeof(mbuf) for every incoming packet. So for very small udp packets the total no. of packets that can be queued is sb_mbmax / (cluster + mbuf) = 256K / (2048 + 256) = 113 packets. At this point, the sbspace() macro declares that there is no space in the socket buffer, in terms of n/w memory. (sbmax - sb_mbcnt becomes -ve) TCP already has an sbcompress() and I have code that does the same for UDP. The code basically compresses the data from the cluster into the mbuf and frees the cluster, if the data fits in one mbuf. I am a little hesitant to do it in the driver code or the ether_input() code as it might do a copy for every protocol including tcp. feedback, please... jayanth To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Aug 2 11:27:17 2000 Delivered-To: freebsd-net@freebsd.org Received: from bubba.whistle.com (bubba.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id 229BB37BD96; Wed, 2 Aug 2000 11:27:13 -0700 (PDT) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.3) id LAA98525; Wed, 2 Aug 2000 11:26:38 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200008021826.LAA98525@bubba.whistle.com> Subject: Re: Improved PPTP support for libalias(3) In-Reply-To: from Julian Elischer at "Aug 2, 2000 10:36:55 am" To: Julian Elischer Date: Wed, 2 Aug 2000 11:26:38 -0700 (PDT) Cc: Archie Cobbs , Ruslan Ermilov , Charles Mott , Erik Salander , net@FreeBSD.ORG, Brian Somers , Eivind Eklund X-Mailer: ELM [version 2.4ME+ PL68 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Julian Elischer writes: > > Sorry, I don't understand your point... libalias already does this fine, > > that's not the problem. > > > > The problem is that two internal clients connecting to the same > > external server at the same time will result in two TCP connections > > to the same server seeming to come from the same IP address, which > > violates the protocol. > > you could do this using the ipfw 'forward' keyword, > to redirect the streams from the clients to a proxy subprocess > in the natd process, which would aggregate as needed onto a separate > tcp stream it runs itself. > > I'm a little confused though. PPTP isn't running over > TCP.. or are you indicating that the TCP sreams under GRE > are 'fiddled' by natd? PPTP includes two components: a TCP control stream and a GRE transport layer. A control stream corresponds one-to-one with a remote peer IP address. Once a control stream is established, you may then establish one or more actual calls. Each of these calls gets a unique Call ID (unique to the control stream). The whole thing is predicated on there only being ONE control stream for each pair of servers. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Aug 2 12:50:35 2000 Delivered-To: freebsd-net@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 0B76E37C1C3 for ; Wed, 2 Aug 2000 12:50:25 -0700 (PDT) (envelope-from xavier@cs.duke.edu) Received: from mackerel.cs.duke.edu (mackerel.cs.duke.edu [152.3.140.156]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id PAA26456 for ; Wed, 2 Aug 2000 15:50:24 -0400 (EDT) Received: from localhost (xavier@localhost) by mackerel.cs.duke.edu (8.8.5/8.6.9) with ESMTP id PAA29964 for ; Wed, 2 Aug 2000 15:50:23 -0400 (EDT) X-Authentication-Warning: mackerel.cs.duke.edu: xavier owned process doing -bs Date: Wed, 2 Aug 2000 15:50:23 -0400 (EDT) From: Clinton Xavier Berni To: freebsd-net@FreeBSD.org Subject: confused about th_ack Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, I'm confused about the values for th_ack and th_seq in the tcp header. First let me provide some background. I'm working at the ip layer, not tcp. Therefore in order to obtain tcp header information I use the mtod() and mpullup() routines. If I have a tcp header and source or dest. port is 80 then I print out the following packet header information: ip_src - the source ip ip_dst - the destination ip src_port - the source port dst_port - the destination port th_ack - the ack sequence number th_seq - the sequence id ip_id - the ip fragment id ip_off - the offset of the fragment I downloaded a large text file using http. Many of the packets exhibit the same value for th_ack and th_seq (100s of packets). Is there something wrong or are there really that many duplicated packets sent and dropped? Maybe I'm misinterpreting the meaning of th_ack and th_seq? Here is an example of the packet output: SYN packet: ip_src 949027736, ip_dst 93062040, src_port 2241, dst_port 80, th_ack 0, th_seq 31122, ip_id 50254, ip_off 64 SYN packet: ip_src 93062040, ip_dst 949027736, src_port 80, dst_port 2241, th_ack 31122, th_seq 44343, ip_id 48929, ip_off 64 packet: ip_src 949027736, ip_dst 93062040, src_port 2241, dst_port 80, th_ack 44343, th_seq 31122, ip_id 50256, ip_off 64 packet: ip_src 949027736, ip_dst 93062040, src_port 2241, dst_port 80, th_ack 44343, th_seq 31122, ip_id 50261, ip_off 64 packet: ip_src 93062040, ip_dst 949027736, src_port 80, dst_port 2241, th_ack 31122, th_seq 44343, ip_id 49185, ip_off 64 packet: ip_src 93062040, ip_dst 949027736, src_port 80, dst_port 2241, th_ack 31122, th_seq 44343, ip_id 49441, ip_off 64 packet: ip_src 93062040, ip_dst 949027736, src_port 80, dst_port 2241, th_ack 31122, th_seq 44343, ip_id 49697, ip_off 64 packet: ip_src 949027736, ip_dst 93062040, src_port 2241, dst_port 80, th_ack 44343, th_seq 31122, ip_id 50355, ip_off 64 ... It goes on like this (~120 packets) with ip_id being the only field that changes. Any help or explanation would be appreciated. thanks, Xavier To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Aug 2 13:41: 9 2000 Delivered-To: freebsd-net@freebsd.org Received: from css-1.cs.iastate.edu (css-1.cs.iastate.edu [129.186.3.24]) by hub.freebsd.org (Postfix) with ESMTP id 2E6DD37BD3E for ; Wed, 2 Aug 2000 13:40:59 -0700 (PDT) (envelope-from ghelmer@cs.iastate.edu) Received: from popeye.cs.iastate.edu (ghelmer@popeye.cs.iastate.edu [129.186.3.4]) by css-1.cs.iastate.edu (8.9.0/8.9.0) with ESMTP id PAA26521; Wed, 2 Aug 2000 15:40:59 -0500 (CDT) Received: from localhost (ghelmer@localhost) by popeye.cs.iastate.edu (8.9.0/8.9.0) with ESMTP id PAA15978; Wed, 2 Aug 2000 15:40:55 -0500 (CDT) X-Authentication-Warning: popeye.cs.iastate.edu: ghelmer owned process doing -bs Date: Wed, 2 Aug 2000 15:40:55 -0500 (CDT) From: Guy Helmer To: Clinton Xavier Berni Cc: freebsd-net@FreeBSD.ORG Subject: Re: confused about th_ack In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 2 Aug 2000, Clinton Xavier Berni wrote: > I'm confused about the values for th_ack and th_seq in the tcp header. > > First let me provide some background. I'm working at the ip layer, not > tcp. Therefore in order to obtain tcp header information I use the mtod() > and mpullup() routines. If I have a tcp header and source or dest. port is > 80 then I print out the following packet header information: > ... > ip_id - the ip fragment id > ip_off - the offset of the fragment The fragment offset must be 0 for you to decode a TCP header in the packet. Each of your decodes shows an ip_off of 64... I'd suggest using "tcpdump tcp and port 80" to grab & decode the same packets you are decoding in the kernel. Compare the tcpdump results with your own code to discover whether your code is working properly. th_seq and th_ack are most likely increasing as one would expect... Hope this helps, Guy Guy Helmer, Ph.D. Candidate, Iowa State University Dept. of Computer Science Research Assistant, Dept. of Computer Science --- ghelmer@cs.iastate.edu http://www.cs.iastate.edu/~ghelmer To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Aug 2 17: 1:32 2000 Delivered-To: freebsd-net@freebsd.org Received: from bubba.whistle.com (bubba.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id 7409A37B874 for ; Wed, 2 Aug 2000 17:01:23 -0700 (PDT) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.3) id RAA28226; Wed, 2 Aug 2000 17:01:16 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200008030001.RAA28226@bubba.whistle.com> Subject: Re: Max data queued for UDP In-Reply-To: <20000802111412.A29943@yahoo-inc.com> from jayanth at "Aug 2, 2000 11:14:12 am" To: jayanth Date: Wed, 2 Aug 2000 17:01:16 -0700 (PDT) Cc: freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL68 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org jayanth writes: > while running some tests for udp with very small packets(25 bytes) > I found that the total amount of data that can be queued > at the socket buffer(just queued, not read) is very limited, > close to around 4k - 5k bytes. > One of the issues is that the driver uses a cluster for > every data packet, however small the data packet is. > There is a per socket limit on the total amount of network > memory that can be used for a socket (sb->sb_mbmax), which > is typically 256k. There is also a variable that keeps > count of the total n/w network memory actually used > by the socket (sb->mb_cnt). The mb_cnt variable is > incremented by a cluster + sizeof(mbuf) for every > incoming packet. So for very small udp packets the total > no. of packets that can be queued is > sb_mbmax / (cluster + mbuf) = 256K / (2048 + 256) = 113 packets. > At this point, the sbspace() macro declares that there is > no space in the socket buffer, in terms of n/w memory. > (sbmax - sb_mbcnt becomes -ve) > > TCP already has an sbcompress() and I have code that does > the same for UDP. The code basically compresses the > data from the cluster into the mbuf and frees the > cluster, if the data fits in one mbuf. > > I am a little hesitant to do it in the driver code or > the ether_input() code as it might do a copy for > every protocol including tcp. > > feedback, please... IMHO, it makes sense to do it for UDP and raw sockets, but not generically. When you say "the driver uses a cluster for every data packet, however small the data packet is" are you referring to a specific Ethernet driver? If so then that driver is lame. It should at least have two possibilities: (a) normal mbuf, and (b) cluster. It's very easy and fast to make that minimal decision. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Aug 2 19: 9:59 2000 Delivered-To: freebsd-net@freebsd.org Received: from inet-smtp3.oracle.com (inet-smtp3.oracle.com [205.227.43.23]) by hub.freebsd.org (Postfix) with ESMTP id 423A537B540 for ; Wed, 2 Aug 2000 19:09:57 -0700 (PDT) (envelope-from Loganathan.Ramasamy@oracle.com) Received: from gmgw02.us.oracle.com (gmgw02.us.oracle.com [130.35.60.93]) by inet-smtp3.oracle.com (8.9.3/8.9.3) with ESMTP id TAA02084 for ; Wed, 2 Aug 2000 19:10:07 -0700 (PDT) Received: from oracle.com (loramasa-pc.us.oracle.com [144.25.191.87]) by gmgw02.us.oracle.com (8.8.8+Sun/8.8.8) with ESMTP id TAA09930 for ; Wed, 2 Aug 2000 19:09:15 -0700 (PDT) Message-ID: <3988D054.67921194@oracle.com> Date: Wed, 02 Aug 2000 18:52:20 -0700 From: Loganathan Ramasamy X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: why SO_REUSEADDR option ? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In the Richard stevens "Unix Network Programming" , it is mentioned that one of the scenarios in which SO_REUSEADDR used is "To bind the same port number with different IP aliases of the host system to different endpoints" I didn't quite get the reason why SO_REUSEADDR has to be used in this scenario. If i don't use why will i get the error "address already in use" , since Source IP address in a 5 tuple connection is going to be different for different endpoints. ie why bind(IP1,P1) and bind (IP2,P1) should give error if i don't use SO_REUSEADDR ?? So can somebody explain it . Thanks loganathan.R To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Aug 2 20:54:31 2000 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 0D32837B6EA for ; Wed, 2 Aug 2000 20:54:24 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id XAA21343; Wed, 2 Aug 2000 23:54:06 -0400 (EDT) (envelope-from wollman) Date: Wed, 2 Aug 2000 23:54:06 -0400 (EDT) From: Garrett Wollman Message-Id: <200008030354.XAA21343@khavrinen.lcs.mit.edu> To: jayanth Cc: freebsd-net@FreeBSD.ORG Subject: Max data queued for UDP In-Reply-To: <20000802111412.A29943@yahoo-inc.com> References: <20000802111412.A29943@yahoo-inc.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > So for very small udp packets the total > no. of packets that can be queued is > sb_mbmax / (cluster + mbuf) = 256K / (2048 + 256) = 113 packets. This is a well-known feature of the BSD stack. The purpose is to limit the amount of wired-down kernel memory an unprivileged (or even remote) user can cause to be a allocated. A cluster is always allocated by most drivers because those drivers are trying to optimize for speed, and this interferes destructively with the flow-control policy in the socket buffer layer. Any allocation or compression policy of this kind will have a ``sour spot'' where packet sizes tip over into the next-size bucket. Finer-grained allocation is a bad idea, since it would require copying many packets -- and that in turn opens up DoS opportunities. There are a few things which would help: 1) Push the socket buffering down into the protocol. This would allow protocols to override the socket buffer flow-control policy with one actually appropriate to the protocol. (Van Jacobson has been flaming about this for a decade or more.) For PR_ATOMIC protocols, a flow-control policy which I think has merit is to use a RED queue, and allow the user to specify the x1 and x2 values. For TCP, the right flow-control policy is to use TCP's flow-control. 2) In m_pullup(), automatically copy the entire packet out of the cluster if it would fit, and free the cluster. This will cost some, but I think it's a win because the IP stack will call m_pullup almost immediately upon receiving a packet, we're already committed to doing a copy, and the current implementation of m_pullup will then allocate an extra mbuf. (This would bite for multicast routing, however. The way to fix that is to keep m_pullup out of the multicast routing code path.) 3) There was a third thing, but it's escaping me at this late hour. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 3 6: 8: 5 2000 Delivered-To: freebsd-net@freebsd.org Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184]) by hub.freebsd.org (Postfix) with ESMTP id EEF6B37B80A for ; Thu, 3 Aug 2000 06:07:42 -0700 (PDT) (envelope-from luigi@info.iet.unipi.it) Received: (from luigi@localhost) by info.iet.unipi.it (8.9.3/8.9.3) id PAA22493; Thu, 3 Aug 2000 15:05:35 +0200 (CEST) (envelope-from luigi) From: Luigi Rizzo Message-Id: <200008031305.PAA22493@info.iet.unipi.it> Subject: Re: Max data queued for UDP In-Reply-To: <200008030001.RAA28226@bubba.whistle.com> from Archie Cobbs at "Aug 2, 2000 05:01:16 pm" To: Archie Cobbs Date: Thu, 3 Aug 2000 15:05:35 +0200 (CEST) Cc: jayanth , freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > One of the issues is that the driver uses a cluster for > > every data packet, however small the data packet is. ... > When you say "the driver uses a cluster for every data packet, > however small the data packet is" are you referring to a specific > Ethernet driver? If so then that driver is lame. It should at > least have two possibilities: (a) normal mbuf, and (b) cluster. > It's very easy and fast to make that minimal decision. not so fast. Some NICs (especially fast ones) DMA directly into memory, and so the obvious choice is to put clusters in the receive ring buffer. The NIC normally cannot be instructed to use either of them. What you can do (maybe) is to decide to copy back small packets into the mbuf and free the cluster, as someone else suggested. cheers luigi -----------------------------------+------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) Mobile +39-347-0373137 -----------------------------------+------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 3 12: 3:32 2000 Delivered-To: freebsd-net@freebsd.org Received: from bubba.whistle.com (bubba.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id 0F23337B528 for ; Thu, 3 Aug 2000 12:03:29 -0700 (PDT) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.3) id MAA42267; Thu, 3 Aug 2000 12:02:40 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200008031902.MAA42267@bubba.whistle.com> Subject: Re: Max data queued for UDP In-Reply-To: <200008030354.XAA21343@khavrinen.lcs.mit.edu> from Garrett Wollman at "Aug 2, 2000 11:54:06 pm" To: Garrett Wollman Date: Thu, 3 Aug 2000 12:02:40 -0700 (PDT) Cc: jayanth , freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL68 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Garrett Wollman writes: > 2) In m_pullup(), automatically copy the entire packet out of the > cluster if it would fit, and free the cluster. This will cost some, > but I think it's a win because the IP stack will call m_pullup almost > immediately upon receiving a packet, we're already committed to doing > a copy, and the current implementation of m_pullup will then allocate > an extra mbuf. (This would bite for multicast routing, however. The > way to fix that is to keep m_pullup out of the multicast routing code > path.) That sounds like a cool idea.. What is special about multicast that would be particularly problematic? -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 3 12: 9:48 2000 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 3A91D37B43C for ; Thu, 3 Aug 2000 12:09:46 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id PAA24064; Thu, 3 Aug 2000 15:09:40 -0400 (EDT) (envelope-from wollman) Date: Thu, 3 Aug 2000 15:09:40 -0400 (EDT) From: Garrett Wollman Message-Id: <200008031909.PAA24064@khavrinen.lcs.mit.edu> To: Archie Cobbs Cc: freebsd-net@FreeBSD.ORG Subject: Re: Max data queued for UDP In-Reply-To: <200008031902.MAA42267@bubba.whistle.com> References: <200008030354.XAA21343@khavrinen.lcs.mit.edu> <200008031902.MAA42267@bubba.whistle.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > What is special about multicast that would be particularly problematic? Because you are potentially making many (manual) copies of multicast packets which were previously copied-by-reference. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 3 12:17:21 2000 Delivered-To: freebsd-net@freebsd.org Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184]) by hub.freebsd.org (Postfix) with ESMTP id D0CDD37B43C for ; Thu, 3 Aug 2000 12:17:17 -0700 (PDT) (envelope-from luigi@info.iet.unipi.it) Received: (from luigi@localhost) by info.iet.unipi.it (8.9.3/8.9.3) id VAA23823; Thu, 3 Aug 2000 21:17:39 +0200 (CEST) (envelope-from luigi) From: Luigi Rizzo Message-Id: <200008031917.VAA23823@info.iet.unipi.it> Subject: Re: Max data queued for UDP In-Reply-To: <200008031909.PAA24064@khavrinen.lcs.mit.edu> from Garrett Wollman at "Aug 3, 2000 03:09:40 pm" To: Garrett Wollman Date: Thu, 3 Aug 2000 21:17:39 +0200 (CEST) Cc: Archie Cobbs , freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > What is special about multicast that would be particularly problematic? > > Because you are potentially making many (manual) copies of multicast > packets which were previously copied-by-reference. > the mbuf is still initialized/copied manually, and i think there is already some m_pullup() anyways in the code path to bring up the ip header at least. If the packet fits into one mbuf, copying 20 bytes or 108 makes very little difference compared with other costs, right ? cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 3 12:26:35 2000 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 7D9DB37B43C for ; Thu, 3 Aug 2000 12:26:31 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id PAA24151; Thu, 3 Aug 2000 15:26:19 -0400 (EDT) (envelope-from wollman) Date: Thu, 3 Aug 2000 15:26:19 -0400 (EDT) From: Garrett Wollman Message-Id: <200008031926.PAA24151@khavrinen.lcs.mit.edu> To: Luigi Rizzo Cc: freebsd-net@FreeBSD.ORG Subject: Re: Max data queued for UDP In-Reply-To: <200008031917.VAA23823@info.iet.unipi.it> References: <200008031909.PAA24064@khavrinen.lcs.mit.edu> <200008031917.VAA23823@info.iet.unipi.it> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > the mbuf is still initialized/copied manually, and i think there is > already some m_pullup() anyways in the code path to bring up the > ip header at least. Bug. > If the packet fits into one mbuf, > copying 20 bytes or 108 makes very little difference compared with > other costs, right ? It may get to the point of significance given 256-byte mbufs. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 3 13:37:33 2000 Delivered-To: freebsd-net@freebsd.org Received: from mrout2.yahoo.com (mrout2.yahoo.com [208.48.125.152]) by hub.freebsd.org (Postfix) with ESMTP id 010C837B7E0 for ; Thu, 3 Aug 2000 13:37:24 -0700 (PDT) (envelope-from jayanth@yahoo-inc.com) Received: from milk.yahoo.com (milk.yahoo.com [206.251.16.37]) by mrout2.yahoo.com (8.10.0/8.10.0/y.out) with ESMTP id e73Kaes78647; Thu, 3 Aug 2000 13:36:40 -0700 (PDT) Received: (from jayanth@localhost) by milk.yahoo.com (8.8.8/8.6.12) id NAA25762; Thu, 3 Aug 2000 13:36:40 -0700 (PDT) Date: Thu, 3 Aug 2000 13:36:40 -0700 From: jayanth To: Garrett Wollman Cc: freebsd-net@FreeBSD.ORG Subject: Re: Max data queued for UDP Message-ID: <20000803133640.B23963@yahoo-inc.com> References: <20000802111412.A29943@yahoo-inc.com> <200008030354.XAA21343@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1us In-Reply-To: <200008030354.XAA21343@khavrinen.lcs.mit.edu>; from wollman@khavrinen.lcs.mit.edu on Wed, Aug 02, 2000 at 11:54:06PM -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Garrett Wollman (wollman@khavrinen.lcs.mit.edu) wrote: > < said: > > > So for very small udp packets the total > > no. of packets that can be queued is > > sb_mbmax / (cluster + mbuf) = 256K / (2048 + 256) = 113 packets. > > This is a well-known feature of the BSD stack. The purpose is to > limit the amount of wired-down kernel memory an unprivileged (or even > remote) user can cause to be a allocated. A cluster is always > allocated by most drivers because those drivers are trying to optimize > for speed, and this interferes destructively with the flow-control > policy in the socket buffer layer. > > Any allocation or compression policy of this kind will have a ``sour > spot'' where packet sizes tip over into the next-size bucket. > Finer-grained allocation is a bad idea, since it would require copying > many packets -- and that in turn opens up DoS opportunities. > > There are a few things which would help: > > 1) Push the socket buffering down into the protocol. This would allow > protocols to override the socket buffer flow-control policy with one > actually appropriate to the protocol. (Van Jacobson has been flaming > about this for a decade or more.) For PR_ATOMIC protocols, a > flow-control policy which I think has merit is to use a RED queue, and > allow the user to specify the x1 and x2 values. For TCP, the right > flow-control policy is to use TCP's flow-control. > > 2) In m_pullup(), automatically copy the entire packet out of the > cluster if it would fit, and free the cluster. This will cost some, > but I think it's a win because the IP stack will call m_pullup almost > immediately upon receiving a packet, we're already committed to doing > a copy, and the current implementation of m_pullup will then allocate > an extra mbuf. (This would bite for multicast routing, however. The > way to fix that is to keep m_pullup out of the multicast routing code > path.) In the m_pullup() case, for two consecutive tcp packets with data that fits into one mbuf , will the second packet will be copied twice , once during m_pullup() and once during sbcompress() ? jayanth ~ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 3 20:15:27 2000 Delivered-To: freebsd-net@freebsd.org Received: from smtp.whitebarn.com (Spin.WhiteBarn.Com [216.0.13.113]) by hub.freebsd.org (Postfix) with ESMTP id 5826B37B8F5 for ; Thu, 3 Aug 2000 20:15:23 -0700 (PDT) (envelope-from Bob@WhiteBarn.Com) Received: from WhiteBarn.Com (Relent.Bob.WhiteBarn.Com [216.0.13.50]) by smtp.whitebarn.com (8.9.3/8.9.3) with ESMTP id WAA98186; Thu, 3 Aug 2000 22:15:21 -0500 (CDT) (envelope-from Bob@WhiteBarn.Com) Message-ID: <398A3549.902A31F5@WhiteBarn.Com> Date: Thu, 03 Aug 2000 22:15:21 -0500 From: Bob Van Valzah X-Mailer: Mozilla 4.72 [en] (X11; I; FreeBSD 4.0-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-net@FreeBSD.ORG Subject: VLAN MTU? 1500? 1504? Why? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I'm about to try setting up VLANs on FreeBSD. I haven't yet found any mention of VLANs in the FreeBSD documentation. The web pages I've read on the subject seem to indicate that there's some dissension in deciding how hosts with VLAN interfaces should handle the extra 4 bytes required for the VLAN header. One camp seems to be saying that the NIC's idea of MTU for the physical interface should be raised to 1504 to allow room for this header so that the VLAN interfaces can maintain the usual 1500-byte MTU. Another camp seems to feel that the 1500-byte MTU of the physical interface is sacred and suggests that the VLAN interfaces should have an MTU of 1496. What're the pros and cons of each approach? Is there a consensus as to which would be a better default? Thanks, Bob To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 3 21:34:13 2000 Delivered-To: freebsd-net@freebsd.org Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (Postfix) with ESMTP id 9C9A437B6AE for ; Thu, 3 Aug 2000 21:34:06 -0700 (PDT) (envelope-from louie@whizzo.transsys.com) Received: from whizzo.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.9.3/8.9.1) with ESMTP id AAA41523; Fri, 4 Aug 2000 00:34:04 -0400 (EDT) (envelope-from louie@whizzo.transsys.com) Message-Id: <200008040434.AAA41523@whizzo.transsys.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Bob Van Valzah Cc: freebsd-net@FreeBSD.ORG X-Image-URL: http://www.transsys.com/louie/images/louie-mail.jpg From: "Louis A. Mamakos" Subject: Re: VLAN MTU? 1500? 1504? Why? References: <398A3549.902A31F5@WhiteBarn.Com> In-reply-to: Your message of "Thu, 03 Aug 2000 22:15:21 CDT." <398A3549.902A31F5@WhiteBarn.Com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 04 Aug 2000 00:34:04 -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org You've got the wrong alternatives considered. The two to choose between are: 1. The IPv4 MTU for packets on an Ethernet are always 1500 bytes. To this, the ethernet driver adds various link-layer headers (source and destination MAC addresses, Ethernet Type/802.3 length) as well as trailers (Ethernet CRC). For some ethernet links which use VLAN trunking, there are additional fields in the link layer headers which are added to support VLANs and 802.1p priority. Ethernet interfaces which choose to participate in explicit VLAN tagging need to be able to add and remove this header, which may result in maximal length frames a few byte longer than previously. 2. The IPv4 MTU for packets is decreased because the hardware you have can't accomodate the addition of VLAN tagging when you want to use explicit tagging of frames, and the IP payload is "large." I would argue that if your Ethernet hardware can't send and receive frames with the "normal" sized payload AND the addition of VLAN tags, then you have no business using it on explicitly tagged VLAN ethernet segments. E.g., alternative 1 is correct. It's important to distinguish between the payload length that the link layer (e.g., ethernet) offers to transport for the higher level protocol (IPv4 in this discussion) with the constraints that the physical layer protocol has. Ethernet MTUs have never been 1500 bytes; that's the IP MTU of IP packets carried inside of Ethernet frames. The length of the Ethernet frame was sacred until someone wanted to do VLAN tagging (which has to be consented to by the parties) and they allowed the packets to grow larger to accomodate this. This makes sense when you consider that the primary application of explicit VLAN tags is on a VLAN trunk between Ethernet switches. The end system using the ethernet switches should not have to care (or even be aware) that the link between a couple of switches is just a plain ethernet, or a VLAN trunk carrying multiple distinct broadcast domains, one per VLAN. louie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 4 0:23:58 2000 Delivered-To: freebsd-net@freebsd.org Received: from pr.infosec.ru (pr.infosec.ru [194.135.141.98]) by hub.freebsd.org (Postfix) with ESMTP id C66D737B771 for ; Fri, 4 Aug 2000 00:23:53 -0700 (PDT) (envelope-from blaze@infosec.ru) Received: from xen.infosec.ru (WS_BLAZE [200.0.0.51]) by pr.infosec.ru with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id P0TVHCFF; Fri, 4 Aug 2000 11:11:53 +0400 Date: Fri, 4 Aug 2000 11:13:39 +0400 (MSD) From: Andrey Sverdlichenko To: freebsd-net@freebsd.org Subject: netgraph ethernet module Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello. Are there any plans to develop ethernet encapsulation module for netgraph, something that can be inserted between ng_iface and ng_ether? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 4 5:40:31 2000 Delivered-To: freebsd-net@freebsd.org Received: from smtp.whitebarn.com (Spin.WhiteBarn.Com [216.0.13.113]) by hub.freebsd.org (Postfix) with ESMTP id 9545437BAA0 for ; Fri, 4 Aug 2000 05:40:28 -0700 (PDT) (envelope-from Bob@WhiteBarn.Com) Received: from WhiteBarn.Com (Relent.Bob.WhiteBarn.Com [216.0.13.50]) by smtp.whitebarn.com (8.9.3/8.9.3) with ESMTP id HAA00797; Fri, 4 Aug 2000 07:39:56 -0500 (CDT) (envelope-from Bob@WhiteBarn.Com) Message-ID: <398AB99C.9D5938B9@WhiteBarn.Com> Date: Fri, 04 Aug 2000 07:39:56 -0500 From: Bob Van Valzah X-Mailer: Mozilla 4.72 [en] (X11; I; FreeBSD 4.0-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Louis A. Mamakos" Cc: freebsd-net@FreeBSD.ORG Subject: Re: VLAN MTU? 1500? 1504? Why? References: <398A3549.902A31F5@WhiteBarn.Com> <200008040434.AAA41523@whizzo.transsys.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Louie, Thanks for your comments and for framing the question more clearly. Let's assume we do want to do 1500-byte frames on the virtual interfaces and go on to an ugly aspect of implementing it. Longer frames seem to require that the physical interface "know" that 1504-byte frames should be allowed when the VLAN or 802.1p driver is above it but prohibited otherwise. Conversely, the VLAN driver should "ask" before assuming that the physical interface can handle the larger frames so that it can fail the open in those cases where the driver can't handle them? Is there any existing mechanism for "negotiation" of MTU between the physical layer and virtual layer? If not, should there be? I suppose we could crank the MTU of all physical interfaces up to whatever they can really handle instead of artificially limiting them to 1500 bytes, but that sounds icky. In short, it seem kind of gross to have to hack the source code of the physical driver when you intend to use it with a virtual driver above it. Is it worth making an elegant solution to this or should we just let the few who need longer frames continue futzing the source of the physical drivers? Thanks, Bob "Louis A. Mamakos" wrote: > You've got the wrong alternatives considered. > > The two to choose between are: > > 1. The IPv4 MTU for packets on an Ethernet are always 1500 bytes. To > this, the ethernet driver adds various link-layer headers (source > and destination MAC addresses, Ethernet Type/802.3 length) as well as > trailers (Ethernet CRC). > > For some ethernet links which use VLAN trunking, there are additional > fields in the link layer headers which are added to support VLANs and > 802.1p priority. Ethernet interfaces which choose to participate in > explicit VLAN tagging need to be able to add and remove this header, > which may result in maximal length frames a few byte longer than > previously. > > 2. The IPv4 MTU for packets is decreased because the hardware you > have can't accomodate the addition of VLAN tagging when you want to > use explicit tagging of frames, and the IP payload is "large." > > I would argue that if your Ethernet hardware can't send and receive > frames with the "normal" sized payload AND the addition of VLAN tags, > then you have no business using it on explicitly tagged VLAN ethernet > segments. E.g., alternative 1 is correct. > > It's important to distinguish between the payload length that the > link layer (e.g., ethernet) offers to transport for the higher level > protocol (IPv4 in this discussion) with the constraints that the > physical layer protocol has. Ethernet MTUs have never been 1500 > bytes; that's the IP MTU of IP packets carried inside of Ethernet > frames. The length of the Ethernet frame was sacred until someone > wanted to do VLAN tagging (which has to be consented to by the > parties) and they allowed the packets to grow larger to accomodate > this. > > This makes sense when you consider that the primary application of > explicit VLAN tags is on a VLAN trunk between Ethernet switches. The > end system using the ethernet switches should not have to care (or > even be aware) that the link between a couple of switches is just > a plain ethernet, or a VLAN trunk carrying multiple distinct > broadcast domains, one per VLAN. > > louie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 4 6:42:30 2000 Delivered-To: freebsd-net@freebsd.org Received: from ozias.inrs-telecom.uquebec.ca (ozias.inrs-telecom.uquebec.ca [192.26.211.164]) by hub.freebsd.org (Postfix) with ESMTP id 1C73337BB40 for ; Fri, 4 Aug 2000 06:42:25 -0700 (PDT) (envelope-from aljtarik@cholla.inrs-telecom.uquebec.ca) Received: from cholla.INRS-Telecom.UQuebec.CA (cholla [192.26.211.110]) by ozias.inrs-telecom.uquebec.ca (8.9.1/8.9.1) with ESMTP id JAA22301; Fri, 4 Aug 2000 09:42:20 -0400 (EDT) Received: from cholla by cholla.INRS-Telecom.UQuebec.CA (8.9.3+Sun/SMI-SVR4) id JAA05141; Fri, 4 Aug 2000 09:42:10 -0400 (EDT) Message-Id: <200008041342.JAA05141@cholla.INRS-Telecom.UQuebec.CA> Date: Fri, 4 Aug 2000 09:42:10 -0400 (EDT) From: Tarik Alj Reply-To: Tarik Alj Subject: Re: VLAN MTU? 1500? 1504? Why? To: Bob@WhiteBarn.Com, louie@TransSys.COM Cc: freebsd-net@FreeBSD.ORG MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: oRK/G9/pCxNJ25qMCuu7Zg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4u sparc Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > >Louie, Thanks for your comments and for framing the question more >clearly. > >Let's assume we do want to do 1500-byte frames on the virtual interfaces >and go on to an ugly aspect of implementing it. > >Longer frames seem to require that the physical interface "know" that >1504-byte frames should be allowed when the VLAN or 802.1p driver is >above it but prohibited otherwise. Conversely, the VLAN driver should >"ask" before assuming that the physical interface can handle the larger >frames so that it can fail the open in those cases where the driver can't >handle them? > >Is there any existing mechanism for "negotiation" of MTU between the >physical layer and virtual layer? If not, should there be? I suppose we >could crank the MTU of all physical interfaces up to whatever they can >really handle instead of artificially limiting them to 1500 bytes, but >that sounds icky. > >In short, it seem kind of gross to have to hack the source code of the >physical driver when you intend to use it with a virtual driver above it. >Is it worth making an elegant solution to this or should we just let the >few who need longer frames continue futzing the source of the physical >drivers? > Well the actual solution isn't very elegant, is it? But there doesn't seem to be a simple way to fix this. A _new_ MTU will require the existing drivers to be modified anyways, but as things go more and more NICs should support 802.1Q tagging. In my opinion VLANs are most useful (and were designed, I believe) for bridging segments (that includes trunking), thus 802.1Q tagging should be done by the bridge module. If you follow IEEE (a document that goes by the name P802.3ac/D3.1, "Frame Extensions for VLAN Tagging on 802.3 Networks) it is the Ethernet frame that gets bigger, not the IP packet that gets smaller. (my 2c :). Tarik. > Thanks, > > Bob > >"Louis A. Mamakos" wrote: > >> You've got the wrong alternatives considered. >> >> The two to choose between are: >> >> 1. The IPv4 MTU for packets on an Ethernet are always 1500 bytes. To >> this, the ethernet driver adds various link-layer headers (source >> and destination MAC addresses, Ethernet Type/802.3 length) as well as >> trailers (Ethernet CRC). >> >> For some ethernet links which use VLAN trunking, there are additional >> fields in the link layer headers which are added to support VLANs and >> 802.1p priority. Ethernet interfaces which choose to participate in >> explicit VLAN tagging need to be able to add and remove this header, >> which may result in maximal length frames a few byte longer than >> previously. >> >> 2. The IPv4 MTU for packets is decreased because the hardware you >> have can't accomodate the addition of VLAN tagging when you want to >> use explicit tagging of frames, and the IP payload is "large." >> >> I would argue that if your Ethernet hardware can't send and receive >> frames with the "normal" sized payload AND the addition of VLAN tags, >> then you have no business using it on explicitly tagged VLAN ethernet >> segments. E.g., alternative 1 is correct. >> >> It's important to distinguish between the payload length that the >> link layer (e.g., ethernet) offers to transport for the higher level >> protocol (IPv4 in this discussion) with the constraints that the >> physical layer protocol has. Ethernet MTUs have never been 1500 >> bytes; that's the IP MTU of IP packets carried inside of Ethernet >> frames. The length of the Ethernet frame was sacred until someone >> wanted to do VLAN tagging (which has to be consented to by the >> parties) and they allowed the packets to grow larger to accomodate >> this. >> >> This makes sense when you consider that the primary application of >> explicit VLAN tags is on a VLAN trunk between Ethernet switches. The >> end system using the ethernet switches should not have to care (or >> even be aware) that the link between a couple of switches is just >> a plain ethernet, or a VLAN trunk carrying multiple distinct >> broadcast domains, one per VLAN. >> >> louie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 4 7:46:53 2000 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 5314437BB61 for ; Fri, 4 Aug 2000 07:46:49 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id KAA27928; Fri, 4 Aug 2000 10:46:38 -0400 (EDT) (envelope-from wollman) Date: Fri, 4 Aug 2000 10:46:38 -0400 (EDT) From: Garrett Wollman Message-Id: <200008041446.KAA27928@khavrinen.lcs.mit.edu> To: Bob Van Valzah Cc: freebsd-net@FreeBSD.ORG Subject: Re: VLAN MTU? 1500? 1504? Why? In-Reply-To: <398AB99C.9D5938B9@WhiteBarn.Com> References: <398A3549.902A31F5@WhiteBarn.Com> <200008040434.AAA41523@whizzo.transsys.com> <398AB99C.9D5938B9@WhiteBarn.Com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > Is there any existing mechanism for "negotiation" of MTU between the > physical layer and virtual layer? Yes. In FreeBSD's implementation, the network interface driver indicates its ability to handle 802.1p-enacapsulated frames (as used in 802.1Q) by advertising a header length of 18 rather than the standard (no encapsulation) 14 octets. (The current implementation does not, however, have a mechanism for rejecting 1518-byte *unencapsulated* packets, as should officially be done. I don't think this is a serious problem.) -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 4 10:18:24 2000 Delivered-To: freebsd-net@freebsd.org Received: from bubba.whistle.com (bubba.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id 3BB6F37BA5E for ; Fri, 4 Aug 2000 10:18:21 -0700 (PDT) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.3) id KAA09439 for freebsd-net@freebsd.org; Fri, 4 Aug 2000 10:18:20 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200008041718.KAA09439@bubba.whistle.com> Subject: Re: cvs commit: src/sys/netinet tcp_output.c In-Reply-To: <200008032323.QAA56279@freefall.freebsd.org> from Archie Cobbs at "Aug 3, 2000 04:23:37 pm" To: freebsd-net@freebsd.org Date: Fri, 4 Aug 2000 10:18:20 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL68 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Archie Cobbs writes: > Modified files: > sys/netinet tcp_output.c > Log: > Improve performance in the case where ip_output() returns an error. > When this happens, we know for sure that the packet data was not > received by the peer. Therefore, back out any advancing of the > transmit sequence number so that we send the same data the next > time we transmit a packet, avoiding a guaranteed missed packet and > its resulting TCP transmit slowdown. > > In most systems ip_output() probably never returns an error, and > so this problem is never seen. However, it is more likely to occur > with device drivers having short output queues (causing ENOBUFS to > be returned when they are full), not to mention low memory situations. > > Moreover, because of this problem writers of slow devices were > required to make an unfortunate choice between (a) having a relatively > short output queue (with low latency but low TCP bandwidth because > of this problem) or (b) a long output queue (with high latency and > high TCP bandwidth). In my particular application (ISDN) it took > an output queue equal to ~5 seconds of transmission to avoid ENOBUFS. > A more reasonable output queue of 0.5 seconds resulted in only about > 50% TCP throughput. With this patch full throughput was restored in > the latter case. I wonder if this has anything to do with why the default interface max transmit queue is IFQ_MAXLEN == 50. Seems like a rather high number to me. I wonder how they came up with this number. Note that if_ppp.c uses this value.. seems kindof inappropriate for a (potentially) slow PPP link. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 4 11:15:42 2000 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 45DD637BAD9 for ; Fri, 4 Aug 2000 11:15:38 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id OAA33020; Fri, 4 Aug 2000 14:15:32 -0400 (EDT) (envelope-from wollman) Date: Fri, 4 Aug 2000 14:15:32 -0400 (EDT) From: Garrett Wollman Message-Id: <200008041815.OAA33020@khavrinen.lcs.mit.edu> To: Archie Cobbs Cc: freebsd-net@FreeBSD.ORG Subject: Re: cvs commit: src/sys/netinet tcp_output.c In-Reply-To: <200008041718.KAA09439@bubba.whistle.com> References: <200008032323.QAA56279@freefall.freebsd.org> <200008041718.KAA09439@bubba.whistle.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > I wonder if this has anything to do with why the default > interface max transmit queue is IFQ_MAXLEN == 50. Seems > like a rather high number to me. I wonder how they came > up with this number. The default used to be 100. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 4 12:44:40 2000 Delivered-To: freebsd-net@freebsd.org Received: from bubba.whistle.com (bubba.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id 52C5337B887 for ; Fri, 4 Aug 2000 12:44:38 -0700 (PDT) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.3) id MAA10454; Fri, 4 Aug 2000 12:44:04 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200008041944.MAA10454@bubba.whistle.com> Subject: Re: cvs commit: src/sys/netinet tcp_output.c In-Reply-To: <200008041815.OAA33020@khavrinen.lcs.mit.edu> from Garrett Wollman at "Aug 4, 2000 02:15:32 pm" To: Garrett Wollman Date: Fri, 4 Aug 2000 12:44:04 -0700 (PDT) Cc: freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL68 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Garrett Wollman writes: > > I wonder if this has anything to do with why the default > > interface max transmit queue is IFQ_MAXLEN == 50. Seems > > like a rather high number to me. I wonder how they came > > up with this number. > > The default used to be 100. Yikes. It seems like a more sensible approach would be to: (a) Measure queue length by counting bytes instead of packets (b) Define the max queue length in terms of time (IFQ_MAXDELAY?) instead of bytes, e.g.: ifp->if_maxq = ifp->if_baudrate * IFQ_MAXDELAY "50 packets" can mean wildy different things to a 14.4 modem vs. a 100baseT Ethernet. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 4 12:50:31 2000 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 7C9F237BB8A for ; Fri, 4 Aug 2000 12:50:27 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id PAA33292; Fri, 4 Aug 2000 15:50:23 -0400 (EDT) (envelope-from wollman) Date: Fri, 4 Aug 2000 15:50:23 -0400 (EDT) From: Garrett Wollman Message-Id: <200008041950.PAA33292@khavrinen.lcs.mit.edu> To: Archie Cobbs Cc: freebsd-net@FreeBSD.ORG Subject: Re: cvs commit: src/sys/netinet tcp_output.c In-Reply-To: <200008041944.MAA10454@bubba.whistle.com> References: <200008041815.OAA33020@khavrinen.lcs.mit.edu> <200008041944.MAA10454@bubba.whistle.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > Yikes. It seems like a more sensible approach would be to: No, what would be more sensible would be to replace drop-tail with RED. Been there, done that. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 4 12:55: 3 2000 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 9269637B6C6 for ; Fri, 4 Aug 2000 12:54:59 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id PAA33315; Fri, 4 Aug 2000 15:54:55 -0400 (EDT) (envelope-from wollman) Date: Fri, 4 Aug 2000 15:54:55 -0400 (EDT) From: Garrett Wollman Message-Id: <200008041954.PAA33315@khavrinen.lcs.mit.edu> To: Archie Cobbs Cc: freebsd-net@FreeBSD.ORG Subject: Re: cvs commit: src/sys/netinet tcp_output.c In-Reply-To: <200008041950.PAA33292@khavrinen.lcs.mit.edu> References: <200008041815.OAA33020@khavrinen.lcs.mit.edu> <200008041944.MAA10454@bubba.whistle.com> <200008041950.PAA33292@khavrinen.lcs.mit.edu> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > No, what would be more sensible would be to replace drop-tail with > RED. Been there, done that. Oh, and I forgot to mention -- I'm fairly certain that your recent change breaks this. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 4 12:59:50 2000 Delivered-To: freebsd-net@freebsd.org Received: from bubba.whistle.com (bubba.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id E8C1E37B702 for ; Fri, 4 Aug 2000 12:59:47 -0700 (PDT) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.3) id MAA10571; Fri, 4 Aug 2000 12:59:15 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200008041959.MAA10571@bubba.whistle.com> Subject: Re: cvs commit: src/sys/netinet tcp_output.c In-Reply-To: <200008041954.PAA33315@khavrinen.lcs.mit.edu> from Garrett Wollman at "Aug 4, 2000 03:54:55 pm" To: Garrett Wollman Date: Fri, 4 Aug 2000 12:59:14 -0700 (PDT) Cc: freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL68 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Garrett Wollman writes: > > No, what would be more sensible would be to replace drop-tail with > > RED. Been there, done that. > > Oh, and I forgot to mention -- I'm fairly certain that your recent > change breaks this. Hmm.. Can you explain what "RED" is and how the change breaks it? Thanks, -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 4 13:14:37 2000 Delivered-To: freebsd-net@freebsd.org Received: from ozias.inrs-telecom.uquebec.ca (ozias.inrs-telecom.uquebec.ca [192.26.211.164]) by hub.freebsd.org (Postfix) with ESMTP id 7450937BBA1 for ; Fri, 4 Aug 2000 13:14:33 -0700 (PDT) (envelope-from aljtarik@cholla.inrs-telecom.uquebec.ca) Received: from cholla.INRS-Telecom.UQuebec.CA (cholla [192.26.211.110]) by ozias.inrs-telecom.uquebec.ca (8.9.1/8.9.1) with ESMTP id QAA27437; Fri, 4 Aug 2000 16:14:31 -0400 (EDT) Received: from cholla by cholla.INRS-Telecom.UQuebec.CA (8.9.3+Sun/SMI-SVR4) id QAA05452; Fri, 4 Aug 2000 16:14:31 -0400 (EDT) Message-Id: <200008042014.QAA05452@cholla.INRS-Telecom.UQuebec.CA> Date: Fri, 4 Aug 2000 16:14:31 -0400 (EDT) From: Tarik Alj Reply-To: Tarik Alj Subject: Re: cvs commit: src/sys/netinet tcp_output.c To: archie@whistle.com Cc: freebsd-net@FreeBSD.ORG MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: be1tsF4yfPy74emM1+FQVw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4u sparc Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > >Hmm.. Can you explain what "RED" is and how the change breaks it? RED stands for Random Early Detection, you can find more info about it (at least a bunch of pointers) from: [http://www.aciri.org/floyd/red.html]. > >Thanks, >-Archie Regards, Tarik To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 4 14: 8:14 2000 Delivered-To: freebsd-net@freebsd.org Received: from bmah-freebsd-0.cisco.com (bmah-freebsd-0.cisco.com [171.70.84.42]) by hub.freebsd.org (Postfix) with ESMTP id E224537B75B for ; Fri, 4 Aug 2000 14:08:05 -0700 (PDT) (envelope-from bmah@cisco.com) Received: (from bmah@localhost) by bmah-freebsd-0.cisco.com (8.11.0/8.11.0) id e74L7Tu13995; Fri, 4 Aug 2000 14:07:29 -0700 (PDT) (envelope-from bmah) Message-Id: <200008042107.e74L7Tu13995@bmah-freebsd-0.cisco.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Tarik Alj Cc: archie@whistle.com, freebsd-net@FreeBSD.ORG Subject: Re: cvs commit: src/sys/netinet tcp_output.c In-Reply-To: <200008042014.QAA05452@cholla.INRS-Telecom.UQuebec.CA> References: <200008042014.QAA05452@cholla.INRS-Telecom.UQuebec.CA> Comments: In-reply-to Tarik Alj message dated "Fri, 04 Aug 2000 16:14:31 -0400." From: bmah@cisco.com (Bruce A. Mah) Reply-To: bmah@cisco.com X-Face: g~c`.{#4q0"(V*b#g[i~rXgm*w;:nMfz%_RZLma)UgGN&=j`5vXoU^@n5v4:OO)c["!w)nD/!!~e4Sj7LiT'6*wZ83454H""lb{CC%T37O!!'S$S&D}sem7I[A 2V%N&+ X-Image-Url: http://www.employees.org/~bmah/Images/bmah-cisco-small.gif X-Url: http://www.employees.org/~bmah/ Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_2103521206P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Fri, 04 Aug 2000 14:07:29 -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --==_Exmh_2103521206P Content-Type: text/plain; charset=us-ascii If memory serves me right, Tarik Alj wrote: > > > > > >Hmm.. Can you explain what "RED" is and how the change breaks it? > > RED stands for Random Early Detection, you can find more info about it (at le > ast > a bunch of pointers) from: [http://www.aciri.org/floyd/red.html]. To answer the other half of the question, I think the problem is that if the queue is full, the committed patch calls to drop the latest outbound packet. That's the definition of "drop tail". A RED queue would drop a random packet from the full queue. The idea, in a really handwavy way, is that flows with many packets enqueued are more susceptable to having something dropped. If you can get those flows to back off (e.g. TCP congestion control), that'll hopefully have the most effect of alleviating the congestion in the queue. Garrett is probably right in a purist sense, but if no one's going to have RED in the stack (e.g. ALTQ) it seems this patch fixes at least *something*. Bruce. PS. Hi Archie! --==_Exmh_2103521206P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use MessageID: elU4ojSwEQblVPaewQ6LsY8kNLlDkOhT iQA/AwUBOYswkdjKMXFboFLDEQJwwgCfY16VqxdQt35OLMG62kPt4XISFb4An2wM 0xfuxIfYOS6lYml3KlYbOJji =/3rr -----END PGP SIGNATURE----- --==_Exmh_2103521206P-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 4 14:32: 1 2000 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 69EDF37B96E for ; Fri, 4 Aug 2000 14:31:51 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id RAA33779; Fri, 4 Aug 2000 17:31:44 -0400 (EDT) (envelope-from wollman) Date: Fri, 4 Aug 2000 17:31:44 -0400 (EDT) From: Garrett Wollman Message-Id: <200008042131.RAA33779@khavrinen.lcs.mit.edu> To: bmah@cisco.com Cc: freebsd-net@FreeBSD.ORG Subject: Re: cvs commit: src/sys/netinet tcp_output.c In-Reply-To: <200008042107.e74L7Tu13995@bmah-freebsd-0.cisco.com> References: <200008042014.QAA05452@cholla.INRS-Telecom.UQuebec.CA> <200008042107.e74L7Tu13995@bmah-freebsd-0.cisco.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < A RED queue would drop a random packet from the full queue. Actually, no. A RED queue would drop a packet as it is enqueued, at random intervals which depend on the current length of the queue. Many people get this wrong when the idea is first explained to them; I know I did. Read the paper for a full explanation of how this works.[1] > If you can get those flows to back off (e.g. TCP congestion > control), Specifically, I think the problem with Archie's patch is that it might result in TCP not backing off at all. RED doesn't deal well with unresponsive flows. -GAWollman [1] In essence, when the average length x [2] exceeds threshold th_min, start dropping packets at probability proportional to (x - th_min). When x exceeds threshold th_max, drop all packets. There are good mathematical tricks to make this very efficient for packets which are not dropped.[3] [2] As computed using a low-pass filter (exponential weighted moving average). [3] Here is some code I wrote a long time ago, written along the lines suggested in the paper. Some of it is probably wrong, since I never finished testing it: static inline int if_enq_drop(struct ifqueue *ifq, struct mbuf *m) { int marked; u_int newlen, new_avglen; if (ifq->ifq_instlen) { newlen = ifq->ifq_instlen + 1; new_avglen = ifq->ifq_avg + ((newlen << (RED_AVG_SCALE - RED_W_Q_SHIFT)) - (ifq->ifq_avg >> RED_W_Q_SHIFT)); } else { newlen = 1; new_avglen = if_red_unidle(ifq); } if (new_avglen < RED_MIN_TH_SCALED) { ifq->ifq_red_count = -1; marked = 0; } else { marked = if_red_domark(new_avglen, ifq); } if (marked) { ifq->ifq_drops++; /* XXX DEBUG */ printf("%p: marked a packet, instlen %u, avglen %u\n", (void *)ifq, ifq->ifq_instlen, ifq->ifq_avg); /* XXX END DEBUG */ return 0; } m->m_nextpkt = 0; if (ifq->ifq_tail == 0) ifq->ifq_head = m; else ifq->ifq_tail->m_nextpkt = m; ifq->ifq_tail = m; ifq->ifq_instlen = newlen; if (newlen > ifq->ifq_max_instlen) ifq->ifq_max_instlen = newlen; ifq->ifq_avg = new_avglen; return 1; } /* * We are called knowing that avglen is already over the threshold. * NB: the calculations involving R_OVER_PB are a bit suspect. XXX * should test. */ int if_red_domark(avglen, ifq) u_int avglen; struct ifqueue *ifq; { u_int mark_prob; int mark_shift; int marked = 0; if (avglen < RED_MAX_TH_SCALED) { ifq->ifq_red_count++; mark_prob = (ifq->ifq_avg >> RED_PROB_C_1_SHIFT) - RED_PROB_C_2_SCALED; /* * We want to quickly approximate R/p_b, where * R is a fixed-point between 0 and 1 with scale shift * RED_RANDOM_SCALE, and p_b is a fixed-point between * 0 and 1 with scale shift RED_AVG_SCALE. * fls() gives us the highest-order bit set (numbered * 1(LSB) to 32(MSB)) or zero if no bits are set. This * -log2(p_b), but for the scale factor. We avoid using * a zero value directly to make things less complicated. */ if (mark_prob == 0) mark_prob = 1; /* smallest representable */ mark_shift = fls(mark_prob) - 1; /* * Now, mark_shift is in the range [0..RED_AVG_SCALE]; * log2(p_b) would be in the range [-RED_AVG_SCALE..0], * which is to say, it is mark_shift - RED_AVG_SCALE. * Still with me? C shifts only work in one direction, * so what we really need is -log2(p_b), which is thus * RED_AVG_SCALE - mark_shift. But, at the same time, * we also need to unscale R, so we subtract RED_RANDOM_SCALE * from that shift factor (to avoid overflow). That can * sometimes turn the sign negative, so we have to be able * to do two-way shifts anyway. */ mark_shift = RED_AVG_SCALE - mark_shift - RED_RANDOM_SCALE; #define R_OVER_PB(R) (int)(mark_shift > 0 ? \ (R) << mark_shift : (R) >> -mark_shift) if (ifq->ifq_red_count > 0 && ifq->ifq_red_count >= R_OVER_PB(ifq->ifq_random)) { marked = 1; ifq->ifq_red_count = 0; } if (ifq->ifq_red_count == 0) ifq->ifq_random = random() & RED_RANDOM_MASK; } else { marked = 1; ifq->ifq_red_count = -1; } return marked; } -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 4 15: 3:42 2000 Delivered-To: freebsd-net@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 90C7937BA64; Fri, 4 Aug 2000 15:03:30 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id QAA54409; Fri, 4 Aug 2000 16:00:44 -0600 (MDT) (envelope-from ken) Date: Fri, 4 Aug 2000 16:00:44 -0600 From: "Kenneth D. Merry" To: net@FreeBSD.ORG Subject: new zero copy sockets and NFS snapshot Message-ID: <20000804160044.A54375@panzer.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [ -arch and -current BCC'ed for wider coverage, please direct followups to -net and/or me ] I have put a new copy of the zero copy sockets and NFS patches, against -current as of early August 3rd, 2000, here: http://people.FreeBSD.ORG/~ken/zero_copy/ Feedback would be very welcome, we haven't gotten much response on this yet. Besides being generated against a newer version of -current, the following things have changed in the new patches posted above: - Support has been merged in from -current for Alteon and Netgear 1000baseT boards. Initial tests with Alteon boards indicate that their performance is identical to the 1000baseSX model. - The zero copy send support code has been renamed and moved to a new file, src/sys/kern/uipc_cow.c. - Drew Gallatin has made some performance enhancements in the ti(4) driver that decrease receive-side CPU utilization and increase performance somewhat. (CPU utilization changes are hard to quantify, but are probably in the 10-20% range. TCP performance on my test Pentium II 350's increased from about 746Mbps to about 763Mbps, as measured by netperf.) - Drew Gallatin submitted a fix to the IP fragmenting code to make sure that outgoing fragments are 8-byte aligned. - Incorporated Bill Paul's fixes to Alteon's 12.4.11 firmware that hopefully include most of the true bugfixes to their 12.4.13 firmware. Alteon's 12.4.13 firmware, when used with 1000BaseT boards, doesn't seem to autonegotiate anything other than 1000BaseT, and also doesn't like to be forced to a speed other than 1000Mbps. Alteon hasn't yet responded to queries about the problems with version 12.4.13 of their firmware, so we're using version 12.4.11 with some selected fixes from 12.4.13. This seems to properly negotiate at all supported speeds and duplex settings with 1000baseT boards. - Header splitting is now restricted to Tigon 2 boards only. We only have source for firmware for the Tigon 2, thus the reason header splitting is only supported for those chips. - Drew Gallatin's NFS read header splitting code is now included in the firmware. This can dramatically improve NFS read performance. - There is a new references section in the FAQ that includes pointers to some relevant papers and proposals. For those of you who missed the previous messages about this code (that went out to -net, -arch and -current), here's a quick list of what is included in the code: - Two sets of zero copy send code, written by Drew Gallatin and Robert Picco . - Zero copy receive code, written by Drew Gallatin. - Zero copy NFS code, written by Drew Gallatin. - Header splitting firmware for Alteon's Tigon II boards (written by me), based on version 12.4.11 of their firmware. This is used in combination with the zero copy receive code to guarantee that the payload of TCP or UDP packet is placed into a page-aligned buffer. - Alteon firmware debugging ioctls and supporting routines for the Tigon driver (also written by me). This will help anyone who is doing firmware development under FreeBSD for the Tigon boards. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 4 15:17: 0 2000 Delivered-To: freebsd-net@freebsd.org Received: from bmah-freebsd-0.cisco.com (bmah-freebsd-0.cisco.com [171.70.84.42]) by hub.freebsd.org (Postfix) with ESMTP id 3FAC737BA04 for ; Fri, 4 Aug 2000 15:16:55 -0700 (PDT) (envelope-from bmah@cisco.com) Received: (from bmah@localhost) by bmah-freebsd-0.cisco.com (8.11.0/8.11.0) id e74MGMk14703; Fri, 4 Aug 2000 15:16:22 -0700 (PDT) (envelope-from bmah) Message-Id: <200008042216.e74MGMk14703@bmah-freebsd-0.cisco.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Garrett Wollman Cc: bmah@cisco.com, freebsd-net@FreeBSD.ORG Subject: Re: cvs commit: src/sys/netinet tcp_output.c In-Reply-To: <200008042131.RAA33779@khavrinen.lcs.mit.edu> References: <200008042014.QAA05452@cholla.INRS-Telecom.UQuebec.CA> <200008042107.e74L7Tu13995@bmah-freebsd-0.cisco.com> <200008042131.RAA33779@khavrinen.lcs.mit.edu> Comments: In-reply-to Garrett Wollman message dated "Fri, 04 Aug 2000 17:31:44 -0400." From: bmah@cisco.com (Bruce A. Mah) Reply-To: bmah@cisco.com X-Face: g~c`.{#4q0"(V*b#g[i~rXgm*w;:nMfz%_RZLma)UgGN&=j`5vXoU^@n5v4:OO)c["!w)nD/!!~e4Sj7LiT'6*wZ83454H""lb{CC%T37O!!'S$S&D}sem7I[A 2V%N&+ X-Image-Url: http://www.employees.org/~bmah/Images/bmah-cisco-small.gif X-Url: http://www.employees.org/~bmah/ Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_-2095522332P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Fri, 04 Aug 2000 15:16:22 -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --==_Exmh_-2095522332P Content-Type: text/plain; charset=us-ascii If memory serves me right, Garrett Wollman wrote: > < > > A RED queue would drop a random packet from the full queue. > > Actually, no. A RED queue would drop a packet as it is enqueued, at > random intervals which depend on the current length of the queue. > Many people get this wrong when the idea is first explained to them; I > know I did. Read the paper for a full explanation of how this works.[1] Mea culpa, thanks for the correction. It's been too long since I read the paper. If it makes you feel any better, I have *nothing* to do whatsoever with the RED implementation in any Cisco product. :-p > > If you can get those flows to back off (e.g. TCP congestion > > control), > > Specifically, I think the problem with Archie's patch is that it might > result in TCP not backing off at all. I think I see your concern but I am not sure whether or not this is true. Given that I started off my previous email with a totally false statement, I'm not sure if I should venture out on a limb again, but: From the commit log, the error case Archie is concerned with is if ip_output returns with ENOBUFS. If this is true, then after Archie's patch gets executed, the code below the out: label will call tcp_quench(), which closes the congestion window down to one segment. The fact that the patch already reset tp->snd_nxt doesn't change that. > RED doesn't deal well with > unresponsive flows. Agreed. Bruce. --==_Exmh_-2095522332P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use MessageID: HuZKOCkYKe88R65elv+ql4bPbwEyn4xc iQA/AwUBOYtAttjKMXFboFLDEQJlkwCfTiMVV4cCrBWxlUDLG+vtRwHq1yoAoJAb wbp/u8hqqDGPdcSbe8NpXDhQ =d0l+ -----END PGP SIGNATURE----- --==_Exmh_-2095522332P-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 4 16: 1:19 2000 Delivered-To: freebsd-net@freebsd.org Received: from bubba.whistle.com (bubba.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id B993337BB7E for ; Fri, 4 Aug 2000 16:01:08 -0700 (PDT) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.3) id QAA22438; Fri, 4 Aug 2000 16:00:59 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200008042300.QAA22438@bubba.whistle.com> Subject: Re: netgraph ethernet module In-Reply-To: from Andrey Sverdlichenko at "Aug 4, 2000 11:13:39 am" To: Andrey Sverdlichenko Date: Fri, 4 Aug 2000 16:00:59 -0700 (PDT) Cc: freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL68 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Andrey Sverdlichenko writes: > Are there any plans to develop ethernet encapsulation module for netgraph, > something that can be inserted between ng_iface and ng_ether? Not a bad idea.. But really this should be separate module(s) for each protocol type. E.g.: +-----------+ | ng_iface | +-----------+ / | \ IPX / | IP \ AppleTalk ... _____/ | \_________________ ... | +----------------+ | ng_ip_ethernet | +--------------+ +----------------+ +----------------+ | ng_ipx_ether | | ARP | IP | ng_atalk_ether | +--------------+ | | + (EtherTalk) | | | | +----------------+ ARP (0x0800) | | IP (0x0800) | | | IPX (0x8137) +---------------+ AppleTalk (0x809B) ... ---------| ng_ether_mux |--------------- ... +---------------+ | | +-----------+ | ng_ether | +-----------+ -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Aug 5 8:28:21 2000 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 8B3D737B9BF for ; Sat, 5 Aug 2000 08:28:14 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id LAA39081; Sat, 5 Aug 2000 11:28:09 -0400 (EDT) (envelope-from wollman) Date: Sat, 5 Aug 2000 11:28:09 -0400 (EDT) From: Garrett Wollman Message-Id: <200008051528.LAA39081@khavrinen.lcs.mit.edu> To: bmah@cisco.com Cc: freebsd-net@FreeBSD.ORG Subject: Re: cvs commit: src/sys/netinet tcp_output.c In-Reply-To: <200008042216.e74MGMk14703@bmah-freebsd-0.cisco.com> References: <200008042014.QAA05452@cholla.INRS-Telecom.UQuebec.CA> <200008042107.e74L7Tu13995@bmah-freebsd-0.cisco.com> <200008042131.RAA33779@khavrinen.lcs.mit.edu> <200008042216.e74MGMk14703@bmah-freebsd-0.cisco.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < From the commit log, the error case Archie is concerned with is if > ip_output returns with ENOBUFS. If this is true, then after Archie's > patch gets executed, the code below the out: label will call > tcp_quench(), which closes the congestion window down to one > segment. OK, I missed that. Everything should be OK then. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Aug 5 10: 4:37 2000 Delivered-To: freebsd-net@freebsd.org Received: from smtp.whitebarn.com (Spin.WhiteBarn.Com [216.0.13.113]) by hub.freebsd.org (Postfix) with ESMTP id 3CC6037BA30 for ; Sat, 5 Aug 2000 10:04:33 -0700 (PDT) (envelope-from Bob@WhiteBarn.Com) Received: from WhiteBarn.Com (Relent.Bob.WhiteBarn.Com [216.0.13.50]) by smtp.whitebarn.com (8.9.3/8.9.3) with ESMTP id MAA15885; Sat, 5 Aug 2000 12:04:31 -0500 (CDT) (envelope-from Bob@WhiteBarn.Com) Message-ID: <398C491E.D7ED5E9F@WhiteBarn.Com> Date: Sat, 05 Aug 2000 12:04:30 -0500 From: Bob Van Valzah X-Mailer: Mozilla 4.72 [en] (X11; I; FreeBSD 4.0-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-net@FreeBSD.ORG Subject: VLAN Config Advice Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I'm having trouble getting VLANs to work on a 4.1-RELEASE system and would appreciate any advice from those who have it running. (If I'm able to get a decent understanding of the issues involved, I may even tackle writing a section for the Handbook on VLANs.) Here's the setup. The physical device is fxp0. I have not applied any patches to the physical driver for larger MTUs. If I don't ifconfig fxp0 and try to go straight to an ifconfig of vlan0, the kernel panics. (I haven't looked at why yet, but probably could if somebody thought it'd help.) Interestingly, it also seems to panic if I ifconfig vlan1 before I configure vlan0. If I do ifconfig fxp0 first and then ifconfig vlan0 on top of it, I get a booted system. However, arp issues lots of warning messages about packets arriving on fxp0 when they should be on vlan0 and I can't ping the box. If you have advice or even just have running VLANs on a fairly stock 4.x system, I'd love to see a snippet of your rc.conf or the hardwired ifconfig commands you may be using. Thanks, Bob To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Aug 5 12:43:42 2000 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 2FFD237B713 for ; Sat, 5 Aug 2000 12:43:39 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id PAA01396; Sat, 5 Aug 2000 15:43:36 -0400 (EDT) (envelope-from wollman) Date: Sat, 5 Aug 2000 15:43:36 -0400 (EDT) From: Garrett Wollman Message-Id: <200008051943.PAA01396@khavrinen.lcs.mit.edu> To: jayanth Cc: freebsd-net@FreeBSD.ORG Subject: Re: Max data queued for UDP In-Reply-To: <20000803133640.B23963@yahoo-inc.com> References: <20000802111412.A29943@yahoo-inc.com> <200008030354.XAA21343@khavrinen.lcs.mit.edu> <20000803133640.B23963@yahoo-inc.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > In the m_pullup() case, for two consecutive tcp packets > with data that fits into one mbuf , will the second packet will be > copied twice , once during m_pullup() and once during sbcompress() ? Yes, but you lose either way. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Aug 5 21:53:20 2000 Delivered-To: freebsd-net@freebsd.org Received: from smtp13.bellglobal.com (smtp13.bellglobal.com [204.101.251.52]) by hub.freebsd.org (Postfix) with ESMTP id 9CF9437BB04 for ; Sat, 5 Aug 2000 21:53:16 -0700 (PDT) (envelope-from james@ehlo.com) Received: from smtp.ehlo.com (HSE-Toronto-ppp175855.sympatico.ca [64.229.72.238]) by smtp13.bellglobal.com (8.8.5/8.8.5) with ESMTP id AAA16126; Sun, 6 Aug 2000 00:57:37 -0400 (EDT) Received: from james by smtp.ehlo.com with local (Exim 3.15 #1) id 13LIQA-00027h-00; Sun, 06 Aug 2000 00:52:22 -0400 Date: Sun, 6 Aug 2000 00:52:22 -0400 From: James FitzGibbon To: Bob Van Valzah Cc: freebsd-net@freebsd.org Subject: Re: VLAN Config Advice Message-ID: <20000806005221.A8147@ehlo.com> References: <398C491E.D7ED5E9F@WhiteBarn.Com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <398C491E.D7ED5E9F@WhiteBarn.Com>; from Bob@WhiteBarn.Com on Sat, Aug 05, 2000 at 12:04:30PM -0500 Organization: EHLO Solutions Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Bob Van Valzah (Bob@WhiteBarn.Com) [000805 13:04]: > I'm having trouble getting VLANs to work on a 4.1-RELEASE system and > would appreciate any advice from those who have it running. (If I'm able > to get a decent understanding of the issues involved, I may even tackle > writing a section for the Handbook on VLANs.) I'll lay out one working VLAN config on 4.x for you: 172.20.32.0/20 VLAN ID 2 172.16.8.0/22 VLAN ID 3 Physical: one CAT5 cable running from fxp1 to a port on an HP Procurve 4000M. On the HP, the port is set to have both VLAN2 and VLAN3 set up as 'tagged'. On some other switch or router, you may have to set things up differently. I'm familiar with Cisco's way of configuring the other end, but won't go into it unless you say that you're using Cisco (it's a long answer). Logical: fxp1: flags=8843 mtu 1500 inet 169.254.1.1 netmask 0xffffffff broadcast 169.254.1.1 ether 00:d0:b7:65:bf:f5 media: autoselect (100baseTX ) status: active supported media: autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP vlan0: flags=8843 mtu 1496 inet 172.16.8.101 netmask 0xfffffc00 broadcast 172.16.11.255 ether 00:d0:b7:65:bf:f5 vlan: 3 parent interface: fxp1 vlan1: flags=8843 mtu 1496 inet 172.20.32.101 netmask 0xfffff000 broadcast 172.20.47.255 ether 00:d0:b7:65:bf:f5 vlan: 2 parent interface: fxp1 I get this configuration on boot this way: 1. I have 'pseudo-device vlan 2' in my kernel 2. My rc.conf looks like this: network_interfaces="fxp1 vlan0 vlan1" ifconfig_fxp1="inet 169.254.1.1 netmask 255.255.255.255" ifconfig_vlan0="inet 172.16.8.101 netmask 255.255.252.0" ifconfig_vlan1="172.20.32.101 netmask 255.255.240.0" I do the VLAN association by way of an /etc/start_if.vlan0 script, which reads like this: ifconfig vlan0 vlan 3 vlandev fxp1 Since the start_if scripts run before the ifconfig magic from rc.conf, the tag ids are set up prior to any real addresses being assigned to the vlan interfaces. The use of 169.254.1.1 is borrowed from the range that M$ uses to default configure DHCP interfaces. I believe that there is an RFC or IETF draft that suggests that this range be used for similar applications. Upon reboot, everything works fine. -- j. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Aug 5 22:43:14 2000 Delivered-To: freebsd-net@freebsd.org Received: from smtp.whitebarn.com (Spin.WhiteBarn.Com [216.0.13.113]) by hub.freebsd.org (Postfix) with ESMTP id BE6A737B91F for ; Sat, 5 Aug 2000 22:43:10 -0700 (PDT) (envelope-from Bob@WhiteBarn.Com) Received: from WhiteBarn.Com (BarnStorm.WhiteBarn.Com [216.0.13.81]) by smtp.whitebarn.com (8.9.3/8.9.3) with ESMTP id AAA19661; Sun, 6 Aug 2000 00:43:09 -0500 (CDT) (envelope-from Bob@WhiteBarn.Com) Message-ID: <398CFAEC.9F11947F@WhiteBarn.Com> Date: Sun, 06 Aug 2000 00:43:09 -0500 From: Bob Van Valzah Organization: WhiteBarn Web Works X-Mailer: Mozilla 4.61 [en] (X11; I; FreeBSD 3.3-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: James FitzGibbon Cc: freebsd-net@freebsd.org Subject: Re: VLAN Config Advice References: <398C491E.D7ED5E9F@WhiteBarn.Com> <20000806005221.A8147@ehlo.com> Content-Type: multipart/alternative; boundary="------------D062EAAAD81FE9052BC91E13" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --------------D062EAAAD81FE9052BC91E13 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit James, Thanks for the advice. I'll give your start_if.vlan0 script a try. In the mean time . . . James FitzGibbon wrote: > Physical: one CAT5 cable running from fxp1 to a port on an HP Procurve > 4000M. On the HP, the port is set to have both VLAN2 and VLAN3 set up as > 'tagged'. On some other switch or router, you may have to set things up > differently. I'm familiar with Cisco's way of configuring the other end, > but won't go into it unless you say that you're using Cisco (it's a long > answer). > I should've said I'm on a Cisco 2924XL. I'm using this config for the port interface FastEthernet0/13 switchport trunk encapsulation dot1q switchport mode trunk Is that reasonable? If not, I'm prepared for any answer (no matter how long :-) Thanks, Bob --------------D062EAAAD81FE9052BC91E13 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit James, Thanks for the advice. I'll give your start_if.vlan0 script a try. In the mean
time . . .

James FitzGibbon wrote: 

 Physical: one CAT5 cable running from fxp1 to a port on an HP Procurve 
  4000M.  On the HP, the port is set to have both VLAN2 and VLAN3 set up as 
  'tagged'.  On some other switch or router, you may have to set things up 
  differently.  I'm familiar with Cisco's way of configuring the other end, 
  but won't go into it unless you say that you're using Cisco (it's a long 
  answer).


I should've said I'm on a Cisco 2924XL. I'm using this config for the port

      interface FastEthernet0/13
       switchport trunk encapsulation dot1q
       switchport mode trunk

Is that reasonable? If not, I'm prepared for any answer (no matter how long :-)

    Thanks,

    Bob --------------D062EAAAD81FE9052BC91E13-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message