From owner-freebsd-net Sun Sep 3 4:34:38 2000 Delivered-To: freebsd-net@freebsd.org Received: from scientia.demon.co.uk (scientia.demon.co.uk [212.228.14.13]) by hub.freebsd.org (Postfix) with ESMTP id 76F2637B423 for ; Sun, 3 Sep 2000 04:34:32 -0700 (PDT) Received: from strontium.scientia.demon.co.uk ([192.168.91.36] ident=root) by scientia.demon.co.uk with esmtp (Exim 3.16 #1) id 13VXta-000D3g-00; Sun, 03 Sep 2000 12:25:06 +0100 Received: (from ben@localhost) by strontium.scientia.demon.co.uk (8.9.3/8.9.3) id MAA83933; Sun, 3 Sep 2000 12:25:06 +0100 (BST) (envelope-from ben) Date: Sun, 3 Sep 2000 12:25:06 +0100 From: Ben Smithurst To: MrBoboo Cc: freebsd net Subject: Re: kernel thing Message-ID: <20000903122506.U72445@strontium.scientia.demon.co.uk> References: <001f01c0156e$1da7dca0$71aa1518@mesqt1.tx.home.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <001f01c0156e$1da7dca0$71aa1518@mesqt1.tx.home.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org MrBoboo wrote: > is there a way to view the settings or configuration for the curent > kernel that is running instead of making a kernel from scratch, i just > want to change some lines in my current one, is there a way to do > that??? basically do a CP of the current to a new file name perhaps > MYKERNEL, then edit MYKERNEL and then you know the rest Have you ever built your own kernel before? If you've never built a kernel before, your kernel will be based on the GENERIC kernel configuration file in /sys/i386/conf. -- Ben Smithurst / ben@FreeBSD.org / PGP: 0x99392F7D To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Sep 3 10:11: 9 2000 Delivered-To: freebsd-net@freebsd.org Received: from avocet.prod.itd.earthlink.net (avocet.prod.itd.earthlink.net [207.217.121.50]) by hub.freebsd.org (Postfix) with ESMTP id 7FAAC37B422 for ; Sun, 3 Sep 2000 10:11:06 -0700 (PDT) Received: from nukemhigh (hybrid-024-221-117-152.phoenix.speedchoice.com [24.221.117.152]) by avocet.prod.itd.earthlink.net (8.9.3-EL_1_3/8.9.3) with SMTP id KAA08750 for ; Sun, 3 Sep 2000 10:11:05 -0700 (PDT) Message-Id: <200009031711.KAA08750@avocet.prod.itd.earthlink.net> X-Sender: egravel@mail.earthlink.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Sun, 03 Sep 2000 10:16:55 -0700 To: freebsd-net@FreeBSD.ORG From: Emmanuel Gravel Subject: Re: Increasing network performance In-Reply-To: References: <200009030438.VAA24762@avocet.prod.itd.earthlink.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org From uname -a: 4.1-RC #0: Mon Jul 17 Cable from hub to FreeBSD is a few feet long (2 or 3). Other cables are longer. For dealing with collisions, I've also seen it just go through collisions as if they were nothing, but that's mostly the exception when transfering a lot of stuff. The hub is a Linksys 5 port 10 Mb/s only. Had a 3Com but it didn't have enough ports. Cable from hub to FreeBSD may need changing though, but the connection is always alive... At 09:58 AM 9/3/00 -0700, Bernie Doehner wrote: >What version of FreeBSD are you running? How long is the cable plugged >into your 3c509's? I am wondering if either the cable or the hub is bad, >or the cable is so short, you aren't properly dealing with collisions. > >Bernie > >On Sat, 2 Sep 2000, Emmanuel Gravel wrote: > >> I have a few machines in network. I'm using FreeBSD as my NAT/firewall. >> The NIC's in the FreeBSD box are 3c509B's. It's a P90 with 32 MB of >> RAM, and at least double of swap. Not running any caching/proxy servers, >> unless you consider NAT as a proxy. >> >> When exchanging files between my FreeBSD box and others on the >> network, and no Internet traffic, at maximum I've seen ~ 250 KB/s >> (not quite 2 Mb/s) transfer rates. When I get Internet traffic, the transfer >> rate goes way down if I also try to transfer files, and I get strange >> behaviour from the network. Traffic happens in bursts, which seem >> usually (but not always) disrupted by collisions, and usually there's >> a fairly long pause (a few seconds) before traffic starts again. I would >> think part of it has to do with the system being dual-homed, with two >> 509's, but I'm sure there has to be something to do to improve performance >> somehow. Does anyone know where I should look to get my box to >> react a little more sanely? If there's anything else you want to know >> just ask :) >> >> Thanks! >> >> >> To Unsubscribe: send mail to majordomo@FreeBSD.org >> with "unsubscribe freebsd-net" in the body of the message >> > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Sep 3 11:45:23 2000 Delivered-To: freebsd-net@freebsd.org Received: from thelab.hub.org (CDR27-115.accesscable.net [24.138.27.115]) by hub.freebsd.org (Postfix) with ESMTP id BDCE437B626 for ; Sun, 3 Sep 2000 11:45:20 -0700 (PDT) Received: from localhost (scrappy@localhost) by thelab.hub.org (8.9.3/8.9.3) with ESMTP id PAA09354; Sun, 3 Sep 2000 15:44:57 -0300 (ADT) (envelope-from scrappy@hub.org) X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs Date: Sun, 3 Sep 2000 15:44:57 -0300 (ADT) From: The Hermit Hacker To: Emmanuel Gravel Cc: freebsd-net@FreeBSD.ORG Subject: Re: Increasing network performance In-Reply-To: <200009030607.XAA17067@avocet.prod.itd.earthlink.net> 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 Sat, 2 Sep 2000, Emmanuel Gravel wrote: > Ah! I knew there were driver issues, but didn't think it would be that bad. > Which NIC's would best suit my needs (decent performance, dual homed, > P90 CPU, and not too expensive)? I won't touch anything by the Intel EtherExpress Pro's ... > > Thanks! > > At 01:58 AM 9/3/00 -0400, Matthew N. Dodd wrote: > >On Sat, 2 Sep 2000, Emmanuel Gravel wrote: > >> Does anyone know where I should look to get my box to react a little > >> more sanely? If there's anything else you want to know just ask :) > > > >3c509s are a wee bit CPU hungry. The driver still has a few issues that > >make the cards a poor choice for performance under FreeBSD. > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Sep 3 12:26:53 2000 Delivered-To: freebsd-net@freebsd.org Received: from addr2.addr.com (addr.com [209.249.147.252]) by hub.freebsd.org (Postfix) with ESMTP id 2D11B37B424 for ; Sun, 3 Sep 2000 12:26:51 -0700 (PDT) Received: from WINNT01 (drnet.fais.net [208.249.141.31]) by addr2.addr.com (8.9.3/8.9.1) with SMTP id MAA91994; Sun, 3 Sep 2000 12:31:20 -0700 (PDT) (envelope-from jwpauler@jwpages.com) From: "Justin W. Pauler" To: , "Emmanuel Gravel" Subject: Re: Increasing network performance Date: Sun, 3 Sep 2000 14:26:38 -0500 Message-ID: <01c015dc$e13db540$0250400a@WINNT01> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org If you are looking for a general NIC that is good quality and has good speed, maybe just try a generic NE2000 NIC. I have two NE2000's in my machine: Pentium 66mhz 20MB RAM FreeBSD 4.0-RELEASE They took a little bit of tweaking in the kernel, to get the interrupt/io port right, but after I did they run very smoothly. I have one NIC connected to all the printers in my house and one NIC connected to all the machines. I get excellent speeds across both sides and haven't had a hiccup yet. These two btw are the following: ed0 at port 0x300-0x31f iomem 0xd8000 irq 3 on isa0 ed0: address 00:40:05:14:c7:2c, type NE2000 (16 bit) They are both just a simple 16 bit card, but I get excellent transfer rates. Justin W. Pauler -----Original Message----- From: Emmanuel Gravel To: freebsd-net@FreeBSD.ORG Date: Sunday, September 03, 2000 7:30 PM Subject: Re: Increasing network performance >Ah! I knew there were driver issues, but didn't think it would be that bad. >Which NIC's would best suit my needs (decent performance, dual homed, >P90 CPU, and not too expensive)? > >Thanks! > >At 01:58 AM 9/3/00 -0400, Matthew N. Dodd wrote: >>On Sat, 2 Sep 2000, Emmanuel Gravel wrote: >>> Does anyone know where I should look to get my box to react a little >>> more sanely? If there's anything else you want to know just ask :) >> >>3c509s are a wee bit CPU hungry. The driver still has a few issues that >>make the cards a poor choice for performance under FreeBSD. > > > >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 Sep 3 12:28:14 2000 Delivered-To: freebsd-net@freebsd.org Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by hub.freebsd.org (Postfix) with ESMTP id 16A1D37B42C for ; Sun, 3 Sep 2000 12:28:12 -0700 (PDT) Received: from ptavv.es.net (localhost [127.0.0.1]) by ptavv.es.net (8.10.1/8.10.1) with ESMTP id e83JSBU07183; Sun, 3 Sep 2000 12:28:11 -0700 (PDT) Message-Id: <200009031928.e83JSBU07183@ptavv.es.net> To: Emmanuel Gravel Cc: freebsd-net@FreeBSD.ORG Subject: Re: Increasing network performance In-reply-to: Your message of "Sat, 02 Sep 2000 21:44:17 PDT." <200009030438.VAA24762@avocet.prod.itd.earthlink.net> Date: Sun, 03 Sep 2000 12:28:11 -0700 From: "Kevin Oberman" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Emmanual, This performance is WAY below what you should be seeing. The card may not be the best choice, but it is not terrible, either. > When exchanging files between my FreeBSD box and others on the > network, and no Internet traffic, at maximum I've seen ~ 250 KB/s > (not quite 2 Mb/s) transfer rates. When I get Internet traffic, the transfer > rate goes way down if I also try to transfer files, and I get strange > behaviour from the network. Traffic happens in bursts, which seem > usually (but not always) disrupted by collisions, and usually there's > a fairly long pause (a few seconds) before traffic starts again. I would > think part of it has to do with the system being dual-homed, with two > 509's, but I'm sure there has to be something to do to improve performance > somehow. Does anyone know where I should look to get my box to > react a little more sanely? If there's anything else you want to know > just ask :) Collisions are seldom an issue. People get excited by the blinking light, but the cost of a collision is very low. 'netstat -i' will report both collisions and errors. Only errors should cause a significant hit on performance. (They require the CPU to get involved and are very expensive!) Collisions are a simple Ethernet flow control mechanism and re-transmission of the colliding packets is handled by the controllers with no CPU involvement other than bumping the collision counter. Are you sure that all of the Ethernet cards are running half-duplex? The symptoms you report are commonly seen when you have a full-duplex interface talking to a half-duplex unit, or, worse yet, to a hub. R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Sep 3 12:35:56 2000 Delivered-To: freebsd-net@freebsd.org Received: from mail.palnet.com (mail.palnet.com [192.116.19.220]) by hub.freebsd.org (Postfix) with ESMTP id 4BD4D37B423 for ; Sun, 3 Sep 2000 12:35:51 -0700 (PDT) Received: from plapla (mustafa.palnet.com [192.116.17.10]) by mail.palnet.com (8.9.3/8.9.3) with SMTP id VAA53324; Sun, 3 Sep 2000 21:38:20 +0200 (IST) Message-ID: <004501c015e5$3c2dc320$0a1174c0@palnet.com> From: "Mustafa N. Deeb" To: "Justin W. Pauler" , , "Emmanuel Gravel" References: <01c015dc$e13db540$0250400a@WINNT01> Subject: Re: Increasing network performance Date: Sun, 3 Sep 2000 22:26:25 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 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 what maximum traffic can you get in your house !!! ----- Original Message ----- From: Justin W. Pauler To: ; Emmanuel Gravel Sent: Sunday, September 03, 2000 9:26 PM Subject: Re: Increasing network performance > If you are looking for a general NIC that is good quality and has good > speed, maybe just try a generic NE2000 NIC. I have two NE2000's in my > machine: > > Pentium 66mhz > 20MB RAM > FreeBSD 4.0-RELEASE > > They took a little bit of tweaking in the kernel, to get the interrupt/io > port right, but after I did they run very smoothly. I have one NIC connected > to all the printers in my house and one NIC connected to all the machines. I > get excellent speeds across both sides and haven't had a hiccup yet. > > These two btw are the following: > > ed0 at port 0x300-0x31f iomem 0xd8000 irq 3 on isa0 > ed0: address 00:40:05:14:c7:2c, type NE2000 (16 bit) > > They are both just a simple 16 bit card, but I get excellent transfer rates. > > Justin W. Pauler > > -----Original Message----- > From: Emmanuel Gravel > To: freebsd-net@FreeBSD.ORG > Date: Sunday, September 03, 2000 7:30 PM > Subject: Re: Increasing network performance > > > >Ah! I knew there were driver issues, but didn't think it would be that bad. > >Which NIC's would best suit my needs (decent performance, dual homed, > >P90 CPU, and not too expensive)? > > > >Thanks! > > > >At 01:58 AM 9/3/00 -0400, Matthew N. Dodd wrote: > >>On Sat, 2 Sep 2000, Emmanuel Gravel wrote: > >>> Does anyone know where I should look to get my box to react a little > >>> more sanely? If there's anything else you want to know just ask :) > >> > >>3c509s are a wee bit CPU hungry. The driver still has a few issues that > >>make the cards a poor choice for performance under FreeBSD. > > > > > > > >To Unsubscribe: send mail to majordomo@FreeBSD.org > >with "unsubscribe freebsd-net" in the body of the message > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Sep 3 13:50:29 2000 Delivered-To: freebsd-net@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 467C437B422 for ; Sun, 3 Sep 2000 13:50:23 -0700 (PDT) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e83KoLg23271; Sun, 3 Sep 2000 13:50:21 -0700 (PDT) Date: Sun, 3 Sep 2000 13:50:21 -0700 From: Alfred Perlstein To: Emmanuel Gravel Cc: freebsd-net@FreeBSD.ORG Subject: Re: Increasing network performance Message-ID: <20000903135021.B18862@fw.wintelcom.net> References: <200009030438.VAA24762@avocet.prod.itd.earthlink.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <200009030438.VAA24762@avocet.prod.itd.earthlink.net>; from egravel@earthlink.net on Sat, Sep 02, 2000 at 09:44:17PM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Emmanuel Gravel [000902 21:38] wrote: > I have a few machines in network. I'm using FreeBSD as my NAT/firewall. > The NIC's in the FreeBSD box are 3c509B's. It's a P90 with 32 MB of > RAM, and at least double of swap. Not running any caching/proxy servers, > unless you consider NAT as a proxy. > > When exchanging files between my FreeBSD box and others on the > network, and no Internet traffic, at maximum I've seen ~ 250 KB/s > (not quite 2 Mb/s) transfer rates. When I get Internet traffic, the transfer > rate goes way down if I also try to transfer files, and I get strange > behaviour from the network. Traffic happens in bursts, which seem > usually (but not always) disrupted by collisions, and usually there's > a fairly long pause (a few seconds) before traffic starts again. I would > think part of it has to do with the system being dual-homed, with two > 509's, but I'm sure there has to be something to do to improve performance > somehow. Does anyone know where I should look to get my box to > react a little more sanely? If there's anything else you want to know > just ask :) > This sounds an awful lot like your cards aren't negotiating full/half duplex properly, check the manpage for ifconfig and make sure that if you have a hub that it's set to half on all your computers and if it's a switch it should be full-duplex. best of luck, -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Sep 3 13:52:27 2000 Delivered-To: freebsd-net@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 6E1BD37B422; Sun, 3 Sep 2000 13:52:25 -0700 (PDT) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e83KqPJ23301; Sun, 3 Sep 2000 13:52:25 -0700 (PDT) Date: Sun, 3 Sep 2000 13:52:25 -0700 From: Alfred Perlstein To: Ben Smithurst Cc: MrBoboo , freebsd net Subject: Re: kernel thing Message-ID: <20000903135225.C18862@fw.wintelcom.net> References: <001f01c0156e$1da7dca0$71aa1518@mesqt1.tx.home.com> <20000903122506.U72445@strontium.scientia.demon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <20000903122506.U72445@strontium.scientia.demon.co.uk>; from ben@FreeBSD.ORG on Sun, Sep 03, 2000 at 12:25:06PM +0100 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Ben Smithurst [000903 04:34] wrote: > MrBoboo wrote: > > > is there a way to view the settings or configuration for the curent > > kernel that is running instead of making a kernel from scratch, i just > > want to change some lines in my current one, is there a way to do > > that??? basically do a CP of the current to a new file name perhaps > > MYKERNEL, then edit MYKERNEL and then you know the rest > > Have you ever built your own kernel before? If you've never built > a kernel before, your kernel will be based on the GENERIC kernel > configuration file in /sys/i386/conf. If you check the LINT kernel you'll see an option: # This allows you to actually store this configuration file into # the kernel binary itself, where it may be later read by saying: # strings -n 3 /kernel | sed -n 's/^___//p' > MYKERNEL # options INCLUDE_CONFIG_FILE # Include this file in kernel that ought to help. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Sep 3 14:54:37 2000 Delivered-To: freebsd-net@freebsd.org Received: from mail.bezeqint.net (mail-a.bezeqint.net [192.115.106.23]) by hub.freebsd.org (Postfix) with ESMTP id E2D6E37B423 for ; Sun, 3 Sep 2000 14:54:34 -0700 (PDT) Received: from bsd.net.il (bzq-169-111.bezeqint.net) by mail.bezeqint.net (Sun Internet Mail Server sims.3.5.2000.03.23.18.03.p10) with ESMTP id <0G0B00972ZFTTH@mail.bezeqint.net> for freebsd-net@FreeBSD.ORG; Mon, 4 Sep 2000 00:52:42 +0300 (GMT) Received: (from nimrodm@localhost) by bsd.net.il (8.11.0/8.9.3) id e83LnEi00461 for freebsd-net@FreeBSD.ORG; Sun, 03 Sep 2000 23:49:14 +0200 (IST envelope-from nimrodm) Date: Sun, 03 Sep 2000 23:49:13 +0200 From: Nimrod Mesika Subject: Re: Increasing network performance In-reply-to: <20000903135021.B18862@fw.wintelcom.net>; from bright@wintelcom.net on Sun, Sep 03, 2000 at 01:50:21PM -0700 To: freebsd-net@FreeBSD.ORG Reply-To: nimrodm@email.com Message-id: <20000903234913.A394@localhost.bsd.net.il> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline Mail-Followup-To: freebsd-net@FreeBSD.ORG User-Agent: Mutt/1.2i References: <200009030438.VAA24762@avocet.prod.itd.earthlink.net> <20000903135021.B18862@fw.wintelcom.net> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, Sep 03, 2000 at 01:50:21PM -0700, Alfred Perlstein wrote: > This sounds an awful lot like your cards aren't negotiating full/half > duplex properly, check the manpage for ifconfig and make sure that if > you have a hub that it's set to half on all your computers and if > it's a switch it should be full-duplex. Talking about performance - what type of performance can I expect to see when two machines are connected using 100Mbps full-duplex switch (assuming all are full-duplex of course)? We're talking Celeron-300 machines here, if that matters and Windows gets about 20Mbps (but of course, this may be due to small receive window - I'm not sure). -- Nimrod. http://www.geocities.com/rodd_27 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Sep 3 19:50:49 2000 Delivered-To: freebsd-net@freebsd.org Received: from inetfw.sonycsl.co.jp (inetfw.SonyCSL.CO.JP [203.137.129.4]) by hub.freebsd.org (Postfix) with ESMTP id 4535C37B424 for ; Sun, 3 Sep 2000 19:50:45 -0700 (PDT) Received: from hotaka.csl.sony.co.jp (hotaka.csl.sony.co.jp [43.27.98.57]) by inetfw.sonycsl.co.jp (8.9.3+3.2W/3.7Ws3/inetfw/2000050701/smtpfeed 1.07) with ESMTP id LAA79020; Mon, 4 Sep 2000 11:50:35 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by hotaka.csl.sony.co.jp (8.9.3+3.2W/3.7Ws3/hotaka/2000061722) with ESMTP id LAA28787; Mon, 4 Sep 2000 11:50:35 +0900 (JST) To: altq@csl.sony.co.jp, akorud@polynet.lviv.ua Cc: freebsd-net@freebsd.org Subject: Re: [altq 565] Running ALTQ In-Reply-To: <122572553.20000902143543@polynet.lviv.ua> References: <122572553.20000902143543@polynet.lviv.ua> X-Mailer: Mew version 1.94.2 on Emacs 20.6 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000904115035K.kjc@csl.sony.co.jp> Date: Mon, 04 Sep 2000 11:50:35 +0900 From: Kenjiro Cho X-Dispatcher: imput version 20000228(IM140) Lines: 20 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Andriy Korud wrote: > I've successfully compiled KAME cvsup, everything is working fine, but > when I try to run altqd with the following cfg file (very simple, just > for test): [snip] > Please note the error. Apparently, the error occurred when altqd tried to install an IPv6 default filter. I guess your kernel doesn't have INET6. If this is the case, you can ignore the error message. > And there is no limit - interface is working on full speed. I need the output of altqstat. -Kenjiro To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Sep 3 21:43:35 2000 Delivered-To: freebsd-net@freebsd.org Received: from po4.wam.umd.edu (po4.wam.umd.edu [128.8.10.166]) by hub.freebsd.org (Postfix) with ESMTP id 5B56037B423 for ; Sun, 3 Sep 2000 21:43:33 -0700 (PDT) Received: from locust.wam.umd.edu (adsl-138-88-45-28.bellatlantic.net [138.88.45.28]) by po4.wam.umd.edu (8.9.3/8.9.3) with ESMTP id AAA08283 for ; Mon, 4 Sep 2000 00:43:32 -0400 (EDT) Message-Id: <4.3.2.7.0.20000904004006.00b60c88@pop.wam.umd.edu> X-Sender: bmbintz@pop.wam.umd.edu X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 04 Sep 2000 00:40:35 -0400 To: freebsd-net@freebsd.org From: Brian Bintz Subject: subscribe 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 subscribe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Sep 4 3:16: 1 2000 Delivered-To: freebsd-net@freebsd.org Received: from genius.systems.pavilion.net (genius.systems.pavilion.net [212.74.1.100]) by hub.freebsd.org (Postfix) with ESMTP id E192537B423 for ; Mon, 4 Sep 2000 03:15:59 -0700 (PDT) Received: by genius.systems.pavilion.net (Postfix, from userid 100) id 6ADA19B26; Mon, 4 Sep 2000 11:16:15 +0100 (BST) Date: Mon, 4 Sep 2000 11:16:15 +0100 From: Josef Karthauser To: The Hermit Hacker Cc: Emmanuel Gravel , freebsd-net@FreeBSD.org Subject: Re: Increasing network performance Message-ID: <20000904111614.A370@pavilion.net> References: <200009030607.XAA17067@avocet.prod.itd.earthlink.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from scrappy@hub.org on Sun, Sep 03, 2000 at 03:44:57PM -0300 X-NCC-RegID: uk.pavilion Organisation: Pavilion Internet plc, Lees House, 21-23 Dyke Road, Brighton, England Phone: +44-845-333-5000 Fax: +44-845-333-5001 Mobile: +44-403-596893 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, Sep 03, 2000 at 03:44:57PM -0300, The Hermit Hacker wrote: > On Sat, 2 Sep 2000, Emmanuel Gravel wrote: > > > Ah! I knew there were driver issues, but didn't think it would be that bad. > > Which NIC's would best suit my needs (decent performance, dual homed, > > P90 CPU, and not too expensive)? > > I won't touch anything by the Intel EtherExpress Pro's ... Hopefully you mean "but" not "by" :) We only use these cards also. Joe -- Josef Karthauser FreeBSD: How many times have you booted today? Technical Manager Viagra for your server (http://www.uk.freebsd.org) Pavilion Internet plc. [joe@pavilion.net, joe@uk.freebsd.org, joe@tao.org.uk] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Sep 4 8:23:30 2000 Delivered-To: freebsd-net@freebsd.org Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78]) by hub.freebsd.org (Postfix) with ESMTP id C730C37B424 for ; Mon, 4 Sep 2000 08:23:22 -0700 (PDT) Received: from staub.net (dsl-pstaub.pacifier.net [216.65.144.154] (may be forged)) (authenticated) by eclipse.pacifier.com (8.10.1/8.10.1) with ESMTP id e84FN5812071 for ; Mon, 4 Sep 2000 08:23:05 -0700 (PDT) Message-ID: <39B3BEA0.B3726565@staub.net> Date: Mon, 04 Sep 2000 08:24:16 -0700 From: Phil Staub X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.14-5.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: DSLl and ssh questions 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 running a FreeBSD 4.1-RELEASE system (Pentium-166) connected through a PicoBSD 3.4 firewall (AMD 486DX4-100). The 4.1 system is a dual homed host, serving as a gateway to a mixture of Windoze and other FreeBSD boxes. It has an NE2000 clone on the local network side and an Intel Pro 10/100B/100+ on the firewall side. The firewall machine has a RealTek 8139 on the inside and a NE2000 clone on the DSL side. The DSL modem is a Cisco 675 in bridging mode. The firewall ruleset currently has 18 rules, and is providing NAT translation for the inside network. I recently switched from cable modem to DSL (got tired of @Home's outages and other limitations), and started seeing relatively frequent long pauses (sometimes 15 seconds or more) during an interactive ssh session with a remote host. I'll type a few characters and all will be well, then the next few will not be echoed for a long time. Nothing is lost, it just takes a very long time to echo the characters and respond. Also, if I'm editing a file on the remote machine, screen updates sometimes pause for similar periods. Oddly enough, if I try the same thing over an insecure connection (e.g., via telnet), I still occasionally get delays, but they are very short compared to what I'm seeing with an ssh connection. Also, pinging an outside host from inside for an extended time results in between 10% and 15% dropped packets. Going the other way (pinging the machine behind my firewall/NAT machine) gives similar results. Trying to understand what may be happening, I captured an scp session with tcpdump into a file and then started printing out what I captured with different options, and I also looked at the overall session statistics with tcptrace. Two things stand out: 1. tcpdump reports a *lot* of truncated incoming packets. When a packet is received truncated, it is almost immediately received again. Often, this retransmitted packet is still truncated, but has fewer bytes missing, until eventually the entire packet is received. 2. The tcptrace -l report is consistent with item 1: out of 993351 bytes sent in 695 packets, 562 packets containing 812437 bytes were retransmitted packets. The connection in the other direction is not nearly as bad (though since this was a file copy from the remote machine to the local one, there was not nearly as much traffic this way): out of 483 bytes sent in 10 packets, 1 packet containing 1 byte was retransmitted. Also, tcptrace reports 561 hardware duplicates on the down link and none on the uplink. Clearly something is *very* wrong. I'm a bit suspicious of the RealTek NIC in the firewall, but I was noticing similar problems when I was initially setting up the DSL without the firewall machine in the line (though I wasn't set up to take the tcpdump/tcptrace measurements at that point). Three questions: 1) Is this *really* typical DSL behavior, 2) if not, where do I go next to track this down, and 3) if the RealTek NIC is suspect, would a 3com 3C905C-TX-M that came with the DSL modem installation package be a reasonable alternative? I've already been on the phone with USWest (the DSL provider, though I'm not using them as an ISP), and they told me how to change the signal level on the wire to reduce the error counts at the DSL modem level to a pretty acceptable number (well under 1%). But I have to think there is something else going on here. I'd appreciate any insight that anyone can offer to shed some light and help me figure out who I should talk to to get this straightened out. Thanks, Phil -- Phil Staub, KE7HC phils@staub.net Unix: because reboots are for hardware upgrades To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Sep 4 11:42:37 2000 Delivered-To: freebsd-net@freebsd.org Received: from guard.polynet.lviv.ua (Guard.PolyNet.Lviv.UA [209.58.62.194]) by hub.freebsd.org (Postfix) with SMTP id 4EAD237B423 for ; Mon, 4 Sep 2000 11:42:17 -0700 (PDT) Received: (qmail 58942 invoked from network); 4 Sep 2000 18:42:07 -0000 Received: from unknown (HELO postoffice.polynet.lviv.ua) (unknown) by unknown with SMTP; 4 Sep 2000 18:42:07 -0000 Received: (qmail 32874 invoked from network); 4 Sep 2000 18:42:07 -0000 Received: (ofmipd unknown); 4 Sep 2000 18:41:45 -0000 Date: 4 Sep 2000 21:42:14 +0300 Message-ID: <128848740.20000904214214@polynet.lviv.ua> From: "Andriy Korud" Reply-To: "Andriy Korud" To: altq@csl.sony.co.jp Cc: freebsd-net@freebsd.org X-Mailer: The Bat! (v1.44) X-Priority: 3 (Normal) Subject: Re[2]: [altq 565] Running ALTQ In-reply-To: <20000904115035K.kjc@csl.sony.co.jp> References: <122572553.20000902143543@polynet.lviv.ua> <20000904115035K.kjc@csl.sony.co.jp> 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 Hello Kenjiro, Monday, September 04, 2000, 5:50:35 AM, you wrote: Kenjiro> Apparently, the error occurred when altqd tried to install an IPv6 Kenjiro> default filter. Kenjiro> I guess your kernel doesn't have INET6. If this is the case, you can Kenjiro> ignore the error message. Yes, my kernel doesn't have INET6. >> And there is no limit - interface is working on full speed. Kenjiro> I need the output of altqstat. Sorry, it was my bug - I tried to GET files by ftp (incoming traffic). When trying to PUT files (outgoing traffic) - everything is going fine. And few more questions: 1. What does ALTQ_NOPCC option mean? Will disabling it (using processor counters) improve limit resolution? 2. When CDRN or HFSC are typically used? I saw something about that CDRN can limit incoming traffic, is it true? Maybe some references in Internet? -- Best regards, Andriy mailto:akorud@polynet.lviv.ua To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Sep 4 18:50:33 2000 Delivered-To: freebsd-net@freebsd.org Received: from falla.videotron.net (falla.videotron.net [205.151.222.106]) by hub.freebsd.org (Postfix) with ESMTP id 1503C37B424 for ; Mon, 4 Sep 2000 18:50:25 -0700 (PDT) Received: from modemcable136.203-201-24.mtl.mc.videotron.net ([24.201.203.136]) by falla.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0G0E00E3M4X16O@falla.videotron.net> for freebsd-net@FreeBSD.ORG; Mon, 4 Sep 2000 21:46:13 -0400 (EDT) Date: Mon, 04 Sep 2000 21:49:33 -0400 (EDT) From: Bosko Milekic Subject: Re: Proposal to clarify mbuf handling rules In-reply-to: X-Sender: bmilekic@jehovah.technokratis.com To: David Malone Cc: freebsd-net@FreeBSD.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 I wrote: > Okay, I will post *something* by this upcoming Monday (long weekend > here!). > > Later, > > Bosko Milekic > bmilekic@technokratis.com Well, I almost have a presentable diff (I was a little sidetracked this weekend). I noticed a little problem in m_pulldown(), though. If we have a reference count of exactly 1, we're okay because that count will never increase throughout our use of sharedcluster (after we set it). The reason is that in order to increase the reference count, we need to have posession of another mbuf referring to the same ext buf as well, and since the count is exactly 1, we know that won't happen until we let go of our mbuf. So if we set sharedcluster to 0, we're deffinately sure that it's writable. However, we may end up with a ref count greater than 1, and set sharedcluster to 1, which means that it's not writable - but throughout our use of sharedcluster, the ref count may drop to 1 and we may become writable. This will only happen during a free of an mbuf referring to the same ext buf, which may or may not happen from within an interrupt. Thus, there is no practical way to block it from happening. But it's not too big of a deal; it would have been more damaging if the behavior was inverse. Comments, anyone? (I'll give you guys an initial patch soon, so that you can apply it, and make whatever modifications you need to). Cheers, Bosko Milekic bmilekic@technokratis.com On-Line TODO: http://www.technokratis.com/~bmilekic/index.html To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Sep 4 20:17:40 2000 Delivered-To: freebsd-net@freebsd.org Received: from falla.videotron.net (falla.videotron.net [205.151.222.106]) by hub.freebsd.org (Postfix) with ESMTP id 3803337B423 for ; Mon, 4 Sep 2000 20:17:34 -0700 (PDT) Received: from modemcable136.203-201-24.mtl.mc.videotron.net ([24.201.203.136]) by falla.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0G0E001X192X4S@falla.videotron.net> for freebsd-net@FreeBSD.ORG; Mon, 4 Sep 2000 23:16:09 -0400 (EDT) Date: Mon, 04 Sep 2000 23:19:29 -0400 (EDT) From: Bosko Milekic Subject: Re: Proposal to clarify mbuf handling rules In-reply-to: X-Sender: bmilekic@jehovah.technokratis.com To: David Malone Cc: freebsd-net@FreeBSD.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 Mon, 4 Sep 2000, I wrote: > Well, I almost have a presentable diff (I was a little sidetracked > this weekend). Here's a preliminary patch; it builds, but I haven't gotten around to testing it yet (my monitor is still at the repair shop, so I'm doing everything remotely). It still lacks things and needs some work... http://www.technokratis.com/code/mbuf/mbuf_rdonly.patch Cheers, Bosko Milekic bmilekic@technokratis.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Sep 4 21:12:55 2000 Delivered-To: freebsd-net@freebsd.org Received: from sentry.granch.com (sentry.granch.com [212.109.197.135]) by hub.freebsd.org (Postfix) with ESMTP id 8004B37B422 for ; Mon, 4 Sep 2000 21:12:48 -0700 (PDT) Received: (from shelton@localhost) by sentry.granch.com (8.9.3/8.9.3) id LAA14701; Tue, 5 Sep 2000 11:12:41 +0700 (NOVST) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <39B3BEA0.B3726565@staub.net> Date: Tue, 05 Sep 2000 11:12:41 +0700 (NOVST) Reply-To: "Rashid N. Achilov" Organization: Granch Ltd. From: "Rashid N. Achilov" To: Phil Staub Subject: RE: DSLl and ssh questions Cc: freebsd-net@FreeBSD.ORG Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 04-Sep-00 Phil Staub wrote: > I'm running a FreeBSD 4.1-RELEASE system (Pentium-166) connected > through a PicoBSD 3.4 firewall (AMD 486DX4-100). > > The firewall machine has a RealTek 8139 on the inside and a NE2000 > clone on the DSL side. The DSL modem is a Cisco 675 in bridging Is a 100Mb speed inside (in the RealTek)? Recently I had had some kind of strange problems. I had two FreeBSD boxes(3.5-STABLE each), connected by crossover patchcord at 100Mb. Each box had RealTek-based NIC (SMC1211TX). Second had some more NIC's (RealTek 8029, NE2000 ISA...). When I tried to download big file (about 15Mb) from first to my box throuch second, download had constantly broken at 10Mb and traffic had stopped . This stange bug can be solved by strange way - when I started trafshow (traffic monitor), interface go to promiscuous mode and traffic resumed :-))) Solve for me: replace this bug-field to Intel EhterExpress Pro 100+. Problem disappeared and never has been occured since change. PS: I suggest to read the comments to rl0 driver in file if_rl0.c in kernel source directory. If driver author himself regarded to his "child" so, what can I tell more...:-) -- With Best Regards. Rashid N. Achilov (RNA1-RIPE), Brainbench ID: 28514 Granch Ltd. lead engineer, e-mail: achilov@granch.ru tel/fax (383-2) 24-2363 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Sep 4 21:36:18 2000 Delivered-To: freebsd-net@freebsd.org Received: from inetfw.sonycsl.co.jp (inetfw.SonyCSL.CO.JP [203.137.129.4]) by hub.freebsd.org (Postfix) with ESMTP id 7594B37B424 for ; Mon, 4 Sep 2000 21:36:16 -0700 (PDT) Received: from hotaka.csl.sony.co.jp (hotaka.csl.sony.co.jp [43.27.98.57]) by inetfw.sonycsl.co.jp (8.9.3+3.2W/3.7Ws3/inetfw/2000050701/smtpfeed 1.07) with ESMTP id NAA04659; Tue, 5 Sep 2000 13:36:13 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by hotaka.csl.sony.co.jp (8.9.3+3.2W/3.7Ws3/hotaka/2000061722) with ESMTP id NAA97353; Tue, 5 Sep 2000 13:36:13 +0900 (JST) To: altq@csl.sony.co.jp, akorud@polynet.lviv.ua Cc: freebsd-net@freebsd.org Subject: Re: [altq 575] Re[2]: [altq 565] Running ALTQ In-Reply-To: <128848740.20000904214214@polynet.lviv.ua> References: <122572553.20000902143543@polynet.lviv.ua> <20000904115035K.kjc@csl.sony.co.jp> <128848740.20000904214214@polynet.lviv.ua> X-Mailer: Mew version 1.94.2 on Emacs 20.6 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000905133613H.kjc@csl.sony.co.jp> Date: Tue, 05 Sep 2000 13:36:13 +0900 From: Kenjiro Cho X-Dispatcher: imput version 20000228(IM140) Lines: 23 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Andriy Korud wrote: > And few more questions: > 1. What does ALTQ_NOPCC option mean? Will disabling it (using > processor counters) improve limit resolution? It requires only one machine cycle to read a processor cycle couner (timestamp counter for pentium), which is much cheaper than using microtime(). However, it doesn't affect the kernel timer resolution. > 2. When CDRN or HFSC are typically used? I saw something about that > CDRN can limit incoming traffic, is it true? Maybe some references in > Internet? CDNR (traffic conditioners) is a set of mechanisms to meter, mark, or drop incoming traffic. A good starting point would be RFC2475 (An Architecture for Differentiated Services). HFSC (hierachical fair service curve) is a queueing discipline from CMU. http://www.cs.cmu.edu/~hzhang/HFSC/main.html -Kenjiro To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Sep 4 22:42:39 2000 Delivered-To: freebsd-net@freebsd.org Received: from rina.r.dl.itc.u-tokyo.ac.jp (rina.r.dl.itc.u-tokyo.ac.jp [133.11.199.247]) by hub.freebsd.org (Postfix) with ESMTP id 64E7E37B422; Mon, 4 Sep 2000 22:42:32 -0700 (PDT) Received: from rina.r.dl.itc.u-tokyo.ac.jp (tanimura@localhost [127.0.0.1]) by rina.r.dl.itc.u-tokyo.ac.jp (8.9.3+3.2W/3.7W-rina.r-0.1-11.01.2000) with ESMTP/IPv4 id OAA52773; Tue, 5 Sep 2000 14:42:11 +0900 (JST) Date: Tue, 05 Sep 2000 14:42:10 +0900 Message-ID: <14772.34738.630468.85559N@rina> From: Seigo Tanimura To: current@freebsd.org, net@freebsd.org Subject: the ifp to a removed pcmcia ethernet card is left in struct ip_moptions and struct ifmultiaddr Cc: Seigo Tanimura User-Agent: Wanderlust/1.0.3 (Notorious) SEMI/1.13.4 (Terai) FLIM/1.12.7 (=?ISO-8859-4?Q?Y=FEzaki?=) MULE XEmacs/21.1 (patch 9) (Canyonlands) (i386--freebsd) Organization: Digital Library Research Division, Information Techinology Centre, The University of Tokyo MIME-Version: 1.0 (generated by SEMI 1.13.4 - "Terai") Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I have been suffering from this problem for almost 2 months. When I remove a pcmcia ethernet card from my laptop PC, routed(8) announces updated routing information by multicast, leading to a kernel panic. The stack trace looks like this: IdlePTD 4136960 initial pcb at 352840 panicstr: page fault panic messages: --- Syntax error: Unterminated quoted string --- #0 boot (howto=256) at ../../kern/kern_shutdown.c:310 310 dumppcb.pcb_cr3 = rcr3(); (kgdb) bt #0 boot (howto=256) at ../../kern/kern_shutdown.c:310 #1 0xc018f3e1 in panic (fmt=0xc02faf4f "page fault") at ../../kern/kern_shutdown.c:560 #2 0xc02b5043 in trap_fatal (frame=0xcb9b0d7c, eva=213493) at ../../i386/i386/trap.c:951 #3 0xc02b4ce5 in trap_pfault (frame=0xcb9b0d7c, usermode=0, eva=213493) at ../../i386/i386/trap.c:844 #4 0xc02b4877 in trap (frame={tf_fs = 16, tf_es = -969998320, tf_ds = 16, tf_edi = -1058687232, tf_esi = -1058687744, tf_ebp = -879030772, tf_isp = -879030872, tf_ebx = -1058661888, tf_edx = -1067786268, tf_ecx = 213485, tf_eax = -1058661888, tf_trapno = 12, tf_err = 0, tf_eip = -1071746146, tf_cs = 8, tf_eflags = 66054, tf_esp = -1067786496, tf_ss = -879030720}) at ../../i386/i386/trap.c:443 #5 0xc01e739e in ip_output (m0=0xc05adf00, opt=0x0, ro=0xcb424dc8, flags=32, imo=0xc0e5b700) at ../../netinet/ip_output.c:326 #6 0xc01e8e26 in rip_output (m=0xc05adf00, so=0xcae549c0, dst=33554656) at ../../netinet/raw_ip.c:234 #7 0xc01e9627 in rip_send (so=0xcae549c0, flags=0, m=0xc05adf00, nam=0xc0da7950, control=0x0, p=0xc62f9f60) at ../../netinet/raw_ip.c:566 #8 0xc01b281f in sosend (so=0xcae549c0, addr=0xc0da7950, uio=0xcb9b0ed4, top=0xc05adf00, control=0x0, flags=0, p=0xc62f9f60) at ../../kern/uipc_socket.c:614 #9 0xc01b63be in sendit (p=0xc62f9f60, s=5, mp=0xcb9b0f14, flags=0) at ../../kern/uipc_syscalls.c:519 #10 0xc01b7998 in sendto (p=0xc62f9f60, uap=0xcb9b0f80) at ../../kern/uipc_syscalls.c:571 #11 0xc02b51ba in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 0, tf_esi = 134727225, tf_ebp = -1077937408, tf_isp = -879030316, tf_ebx = 134844928, tf_edx = 2, tf_ecx = -1, tf_eax = 133, tf_trapno = 7, tf_err = 2, tf_eip = 134573992, tf_cs = 31, tf_eflags = 659, tf_esp = -1077937484, tf_ss = 47}) at ../../i386/i386/trap.c:1150 #12 0xc02a8875 in Xint0x80_syscall () #13 0x8051b10 in ?? () #14 0x8050ff4 in ?? () #15 0x804c212 in ?? () #16 0x804813f in ?? () In ip_output(), imo->imo_multicast_ifp points to the removed interface, which is passed to IN_LOOKUP_MULTI() to cause a panic. This problem also occurs when we attempt to delete a multicast address from a removed interface. if_delmulti() derefers an ifp to the removed interface, ending up with a panic. The problem does not occur for unicast. http://people.FreeBSD.org/~tanimura/patches/mcastif.diff.gz is a workround patch. The idea is to track all of the active ifps, confirm an ifp to be active prior to dereferencing it, and free orphaned ifmultiaddrs attached to a removed ifp. It would be much more elegant if we could clean up the multicast information related to a removed interface, though. -- Seigo Tanimura To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Sep 4 23: 8:37 2000 Delivered-To: freebsd-net@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id 2527837B422; Mon, 4 Sep 2000 23:08:34 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 13WBzS-0000FR-00; Tue, 05 Sep 2000 00:13:50 -0600 Message-ID: <39B48F1E.4C193F79@softweyr.com> Date: Tue, 05 Sep 2000 00:13:50 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; FreeBSD 4.1-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: Seigo Tanimura Cc: current@freebsd.org, net@freebsd.org Subject: Re: the ifp to a removed pcmcia ethernet card is left in struct ip_moptions and struct ifmultiaddr References: <14772.34738.630468.85559N@rina> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Seigo Tanimura wrote: > > I have been suffering from this problem for almost 2 months. When I > remove a pcmcia ethernet card from my laptop PC, routed(8) announces > updated routing information by multicast, leading to a kernel > panic. Ejecting an interface configured up will do that. ifconfig the interface `down' and then `delete' before ejecting it. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Sep 4 23:10:19 2000 Delivered-To: freebsd-net@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 9536D37B424; Mon, 4 Sep 2000 23:10:15 -0700 (PDT) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id AAA24820; Tue, 5 Sep 2000 00:10:13 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id AAA58464; Tue, 5 Sep 2000 00:09:33 -0600 (MDT) Message-Id: <200009050609.AAA58464@harmony.village.org> To: Wes Peters Subject: Re: the ifp to a removed pcmcia ethernet card is left in struct ip_moptions and struct ifmultiaddr Cc: Seigo Tanimura , current@FreeBSD.ORG, net@FreeBSD.ORG In-reply-to: Your message of "Tue, 05 Sep 2000 00:13:50 MDT." <39B48F1E.4C193F79@softweyr.com> References: <39B48F1E.4C193F79@softweyr.com> <14772.34738.630468.85559N@rina> Date: Tue, 05 Sep 2000 00:09:33 -0600 From: Warner Losh Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <39B48F1E.4C193F79@softweyr.com> Wes Peters writes: : Ejecting an interface configured up will do that. ifconfig the interface : `down' and then `delete' before ejecting it. At best this is an unsatisfactory workaround. if_detach should cause the right thing to happen. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Sep 5 7:34:43 2000 Delivered-To: freebsd-net@freebsd.org Received: from gidora.zeta.org.au (gidora.zeta.org.au [203.26.10.25]) by hub.freebsd.org (Postfix) with SMTP id 0B0CA37B422 for ; Tue, 5 Sep 2000 07:34:40 -0700 (PDT) Received: (qmail 10120 invoked from network); 5 Sep 2000 14:34:36 -0000 Received: from unknown (HELO bde.zeta.org.au) (203.2.228.102) by gidora.zeta.org.au with SMTP; 5 Sep 2000 14:34:36 -0000 Date: Wed, 6 Sep 2000 01:34:32 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Kenjiro Cho Cc: altq@csl.sony.co.jp, akorud@polynet.lviv.ua, freebsd-net@FreeBSD.ORG Subject: Re: [altq 575] Re[2]: [altq 565] Running ALTQ In-Reply-To: <20000905133613H.kjc@csl.sony.co.jp> 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 Tue, 5 Sep 2000, Kenjiro Cho wrote: > Andriy Korud wrote: > > And few more questions: > > 1. What does ALTQ_NOPCC option mean? Will disabling it (using > > processor counters) improve limit resolution? > > It requires only one machine cycle to read a processor cycle couner > (timestamp counter for pentium), which is much cheaper than using > microtime(). However, it doesn't affect the kernel timer resolution. It takes more than one cycle, at least in a loop. I just retried the following: main() { __asm(" movl $100000000,%ecx .align 4,0x90 1: rdtsc decl %ecx nop jne 1b "); } and it took 30 cycles on a Celeron and 12 cycles on a P5 (32 and 14 cycles, respectively, including 2 cycles of loop overhead). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Sep 5 8:30:51 2000 Delivered-To: freebsd-net@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id CC16D37B423; Tue, 5 Sep 2000 08:30:44 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 13WKnt-00006R-00; Tue, 05 Sep 2000 09:38:30 -0600 Message-ID: <39B51375.4DE4C6FA@softweyr.com> Date: Tue, 05 Sep 2000 09:38:29 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; FreeBSD 4.1-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: Warner Losh Cc: Seigo Tanimura , current@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: the ifp to a removed pcmcia ethernet card is left in struct ip_moptions and struct ifmultiaddr References: <39B48F1E.4C193F79@softweyr.com> <14772.34738.630468.85559N@rina> <200009050609.AAA58464@harmony.village.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Warner Losh wrote: > > In message <39B48F1E.4C193F79@softweyr.com> Wes Peters writes: > : Ejecting an interface configured up will do that. ifconfig the interface > : `down' and then `delete' before ejecting it. > > At best this is an unsatisfactory workaround. if_detach should cause > the right thing to happen. Right, but as we've discussed before, that may not be possible with PCCard and CardBus, or anything else short of CPCI. In the meantime, this is the state the code is in now, and if someone wants it to be better, we await their patches. As always. ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Sep 5 8:36:10 2000 Delivered-To: freebsd-net@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 3008D37B423; Tue, 5 Sep 2000 08:36:03 -0700 (PDT) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id JAA26432; Tue, 5 Sep 2000 09:35:54 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id JAA60822; Tue, 5 Sep 2000 09:35:13 -0600 (MDT) Message-Id: <200009051535.JAA60822@harmony.village.org> To: Wes Peters Subject: Re: the ifp to a removed pcmcia ethernet card is left in struct ip_moptions and struct ifmultiaddr Cc: Seigo Tanimura , current@FreeBSD.ORG, net@FreeBSD.ORG In-reply-to: Your message of "Tue, 05 Sep 2000 09:38:29 MDT." <39B51375.4DE4C6FA@softweyr.com> References: <39B51375.4DE4C6FA@softweyr.com> <39B48F1E.4C193F79@softweyr.com> <14772.34738.630468.85559N@rina> <200009050609.AAA58464@harmony.village.org> Date: Tue, 05 Sep 2000 09:35:12 -0600 From: Warner Losh Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <39B51375.4DE4C6FA@softweyr.com> Wes Peters writes: : state the code is in now, and if someone wants it to be better, we await : their patches. As always. ;^) Tanimura-san did contribute patches. This problem isn't a race at the eject, but rather the network layer incompletely cleaning up after a device has gone away. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Sep 5 11:40:29 2000 Delivered-To: freebsd-net@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 5114237B422; Tue, 5 Sep 2000 11:40:24 -0700 (PDT) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id OAA03025; Tue, 5 Sep 2000 14:38:54 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Tue, 5 Sep 2000 14:38:54 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Warner Losh Cc: Wes Peters , Seigo Tanimura , current@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: the ifp to a removed pcmcia ethernet card is left in struct ip_moptions and struct ifmultiaddr In-Reply-To: <200009050609.AAA58464@harmony.village.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 Tue, 5 Sep 2000, Warner Losh wrote: > In message <39B48F1E.4C193F79@softweyr.com> Wes Peters writes: > : Ejecting an interface configured up will do that. ifconfig the interface > : `down' and then `delete' before ejecting it. > > At best this is an unsatisfactory workaround. if_detach should cause > the right thing to happen. This is all made harder by the fact that struct mbuf has a struct ifnet pointer in it, so if for any reason there is an outstanding mbuf originating from that interface, it is possible that the struct ifnet * will be dereferenced. For example, if it hits an ipfw rule that dummynets it, then hits an interface-based rule. This has been raised as an issue before, and is a good reason to ifconfig down the interface, and wait a second or two before ejecting. You could imagine code-based solutions, including scanning mbufs (?) for pointers that are undesirable, refcounting the struct ifnet so it isn't freed until all mbufs are free'd, etc. Whatever the case, you want to make sure that locking in the line of fire is avoided (i.e., attempting to lock struct ifnet during packet handling in the interrupt). Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Sep 5 11:44:28 2000 Delivered-To: freebsd-net@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id B10EF37B424; Tue, 5 Sep 2000 11:44:21 -0700 (PDT) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id MAA27368; Tue, 5 Sep 2000 12:44:17 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id MAA62492; Tue, 5 Sep 2000 12:43:35 -0600 (MDT) Message-Id: <200009051843.MAA62492@harmony.village.org> To: Robert Watson Subject: Re: the ifp to a removed pcmcia ethernet card is left in struct ip_moptions and struct ifmultiaddr Cc: Wes Peters , Seigo Tanimura , current@FreeBSD.ORG, net@FreeBSD.ORG In-reply-to: Your message of "Tue, 05 Sep 2000 14:38:54 EDT." References: Date: Tue, 05 Sep 2000 12:43:35 -0600 From: Warner Losh Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message Robert Watson writes: : This is all made harder by the fact that struct mbuf has a struct ifnet : pointer in it, so if for any reason there is an outstanding mbuf : originating from that interface, it is possible that the struct ifnet * : will be dereferenced. For example, if it hits an ipfw rule that dummynets : it, then hits an interface-based rule. Yes. That's true. There's a race. : This has been raised as an issue before, and is a good reason to ifconfig : down the interface, and wait a second or two before ejecting. You could : imagine code-based solutions, including scanning mbufs (?) for pointers : that are undesirable, refcounting the struct ifnet so it isn't freed until : all mbufs are free'd, etc. Whatever the case, you want to make sure that : locking in the line of fire is avoided (i.e., attempting to lock struct : ifnet during packet handling in the interrupt). No body waits :-(. This is made worse by pccard's detaching the device when a suspend happens via acpi or apm. NetBSD has done some interesting things in this area with reference counting and such that I'd love to bring in as soon as I get newcard done. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Sep 5 11:50: 1 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 7361137B423; Tue, 5 Sep 2000 11:49:55 -0700 (PDT) Received: (from luigi@localhost) by info.iet.unipi.it (8.9.3/8.9.3) id UAA20917; Tue, 5 Sep 2000 20:51:43 +0200 (CEST) (envelope-from luigi) From: Luigi Rizzo Message-Id: <200009051851.UAA20917@info.iet.unipi.it> Subject: Re: the ifp to a removed pcmcia ethernet card is left in struct ip_moptions and struct ifmultiaddr In-Reply-To: from Robert Watson at "Sep 5, 2000 02:38:54 pm" To: Robert Watson Date: Tue, 5 Sep 2000 20:51:43 +0200 (CEST) Cc: Warner Losh , Wes Peters , Seigo Tanimura , current@FreeBSD.ORG, 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 > This is all made harder by the fact that struct mbuf has a struct ifnet > pointer in it, so if for any reason there is an outstanding mbuf ... > This has been raised as an issue before, and is a good reason to ifconfig > down the interface, and wait a second or two before ejecting. You could and still, the wait is not errorproof as delays can be larger than a second or two. I suppose the correct way to do things when you delete an interface is to to keep the struct ifnet around (in some list) for further reuse when the card is reinserted. One could argue that dummynet with its delayed scheduling of packets is screwing up things, but i would argue that having pointers to volatile objects without reference counts is not such a great design, and SMP might give the same kind of problems. cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Sep 5 14:16:39 2000 Delivered-To: freebsd-net@freebsd.org Received: from verdi.nethelp.no (verdi.nethelp.no [158.36.41.162]) by hub.freebsd.org (Postfix) with SMTP id 7C33137B423 for ; Tue, 5 Sep 2000 14:16:36 -0700 (PDT) Received: (qmail 24034 invoked by uid 1001); 5 Sep 2000 21:16:34 +0000 (GMT) To: nimrodm@email.com, nimrodm@bezeqint.net Cc: freebsd-net@FreeBSD.ORG Subject: Re: Increasing network performance From: sthaug@nethelp.no In-Reply-To: Your message of "Sun, 03 Sep 2000 23:49:13 +0200" References: <20000903234913.A394@localhost.bsd.net.il> X-Mailer: Mew version 1.05+ on Emacs 19.34.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Tue, 05 Sep 2000 23:16:34 +0200 Message-ID: <24032.968188594@verdi.nethelp.no> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Talking about performance - what type of performance can I expect to > see when two machines are connected using 100Mbps full-duplex > switch (assuming all are full-duplex of course)? > > We're talking Celeron-300 machines here, if that matters and Windows > gets about 20Mbps (but of course, this may be due to small receive > window - I'm not sure). Celeron 300 should have no problem saturating 100 Mbps Ethernet using reasonable Ethernet cards (fxp or de) - in fact you can do it with a P-166 or better (measured this myself with FreeBSD more than 3 years ago). Steinar Haug, Nethelp consulting, sthaug@nethelp.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Sep 5 17:53:16 2000 Delivered-To: freebsd-net@freebsd.org Received: from defiant.quansoo.com (adsl-216-158-26-30.cust.oldcity.dca.net [216.158.26.30]) by hub.freebsd.org (Postfix) with ESMTP id D497637B424 for ; Tue, 5 Sep 2000 17:53:13 -0700 (PDT) Received: from localhost (cgriffiths@localhost) by defiant.quansoo.com (8.11.0/8.11.0) with ESMTP id e860r3900891 for ; Tue, 5 Sep 2000 20:53:04 -0400 (EDT) (envelope-from cgriffiths@quansoo.com) X-Authentication-Warning: defiant.quansoo.com: cgriffiths owned process doing -bs Date: Tue, 5 Sep 2000 20:53:03 -0400 (EDT) From: "Christopher T. Griffiths" To: net@freebsd.org Subject: mpd-netgraph and vpn issues 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 In my continued attempts to connect my win2k client to a mpd-netgraph server I have gotten this far: My local lan behind my firewall in the dmz has internet routed address. The mpd server is sitting in the dmz. I need to be able to add vpn users to some block of address in the dmz so that they can access systems past my firewall. I am also getting the following error when I connect: [pptp] no interface to proxy arp on for 192.168.1.2 Do I need to change the 192.168.* address to my public dmz address to get the systems to proxy arp? My attempts to do so have caused my server system to hop off the local network and only talk to the vpn client. Not a good scenario. The compression/encryption stuff is working great and I am sure it is something so stupid in order to get network connectivity working. If I add the following line I am able to ping back and forth between the client and server machine but not out into the dmz: set iface route 192.168.1.0/24 any help would be greatly appreciated. Thanks Chris config: pptp: new -i ng0 pptp pptp set iface disable on-demand set iface enable proxy-arp set iface idle 1800 set bundle disable multilink set link yes acfcomp protocomp set link no pap chap set link enable chap set link keep-alive 10 60 set ipcp yes vjcomp set ipcp ranges 192.168.1.1/32 192.168.1.2/32 set ipcp dns 12.40.126.75 set bundle enable compression set ccp yes mppc set ccp yes mpp-e40 set ccp yes mpp-e128 set bundle enable crypt-reqd set ccp yes mpp-stateless --- Christopher T. Griffiths Quansoo Group Inc. cgriffiths@quansoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Sep 5 20:35:21 2000 Delivered-To: freebsd-net@freebsd.org Received: from ebola.biohz.net (ebola.biohz.net [206.80.1.35]) by hub.freebsd.org (Postfix) with ESMTP id 2AF8C37B423 for ; Tue, 5 Sep 2000 20:35:15 -0700 (PDT) Received: from rabies (localhost [127.0.0.1]) by ebola.biohz.net (Postfix) with SMTP id 066DF3A338; Tue, 5 Sep 2000 20:35:09 -0700 (PDT) Message-ID: <002801c017b3$76ab5a60$0302010a@biohz.net> From: "Renaud Waldura" To: "Christopher T. Griffiths" Cc: References: Subject: Re: mpd-netgraph and vpn issues Date: Tue, 5 Sep 2000 20:35:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.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 Maybe add: # the PPTP interface address set pptp self YOUR_ADDR to mpd.links? From what I'm guessing, YOUR_ADDR above is probably 192.168.1.1. I do not see why your setup would require you to use a route, although I can be mistaken. > The compression/encryption stuff is working great and I am sure it is Now tell me, how did you get the compression/encryption to work? I was under the impression that compression+encryption required code not present in the FreeBSD distribution, and hence was not available. Do Windows clients connect with the "Require data encryption" setting (on by default)? Thanks, --Renaud ----- Original Message ----- From: Christopher T. Griffiths To: Sent: Tuesday, September 05, 2000 5:53 PM Subject: mpd-netgraph and vpn issues > In my continued attempts to connect my win2k client to a mpd-netgraph > server I have gotten this far: > > My local lan behind my firewall in the dmz has internet routed address. > The mpd server is sitting in the dmz. > > I need to be able to add vpn users to some block of address in the dmz > so that they can access systems past my firewall. > > I am also getting the following error when I connect: > > [pptp] no interface to proxy arp on for 192.168.1.2 > > Do I need to change the 192.168.* address to my public dmz address to get > the systems to proxy arp? > > My attempts to do so have caused my server system to hop off the local > network and only talk to the vpn client. Not a good scenario. > > The compression/encryption stuff is working great and I am sure it is > something so stupid in order to get network connectivity working. > > If I add the following line I am able to ping back and forth between the > client and server machine but not out into the dmz: > > set iface route 192.168.1.0/24 > > any help would be greatly appreciated. > > Thanks > > Chris > > > config: > pptp: > new -i ng0 pptp pptp > set iface disable on-demand > set iface enable proxy-arp > set iface idle 1800 > set bundle disable multilink > set link yes acfcomp protocomp > set link no pap chap > set link enable chap > set link keep-alive 10 60 > set ipcp yes vjcomp > set ipcp ranges 192.168.1.1/32 192.168.1.2/32 > set ipcp dns 12.40.126.75 > set bundle enable compression > set ccp yes mppc > set ccp yes mpp-e40 > set ccp yes mpp-e128 > set bundle enable crypt-reqd > set ccp yes mpp-stateless > > > --- > Christopher T. Griffiths > Quansoo Group Inc. > cgriffiths@quansoo.com > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Sep 5 21:21:31 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 BF78B37B423; Tue, 5 Sep 2000 21:21:19 -0700 (PDT) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id WAA97128; Tue, 5 Sep 2000 22:21:19 -0600 (MDT) (envelope-from ken) Date: Tue, 5 Sep 2000 22:21:19 -0600 From: "Kenneth D. Merry" To: net@FreeBSD.ORG Subject: new zero copy sockets and NFS snapshot Message-ID: <20000905222119.A97109@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 September 5th, 2000, here: http://people.FreeBSD.ORG/~ken/zero_copy/ Questions, comments and feedback are welcome. Besides being generated against a newer version of -current, the following things have changed in the new patches posted above: - Merged in the new mbuf reference counting code from -current. - Fixed a bug in writev(2) and sendmsg(2) handling noticed by Alan Cox. We weren't incrementing the iov pointer in the uio structure, like uiomove() does. - Fixed another bug in the zero copy code, noticed by Alan Cox. Move the initialization of the cow_send in sosend() (in uipc_socket.c) into the inner while loop. 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. The Alteon header splitting and debugging code was written for Pluto Technologies (www.plutotech.com), which has kindly agreed to let me release the code. 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 Tue Sep 5 23:34:41 2000 Delivered-To: freebsd-net@freebsd.org Received: from urban.iinet.net.au (urban.iinet.net.au [203.59.24.231]) by hub.freebsd.org (Postfix) with ESMTP id 9C8D437B423; Tue, 5 Sep 2000 23:34:33 -0700 (PDT) Received: from muzak.iinet.net.au (muzak.iinet.net.au [203.59.24.237]) by urban.iinet.net.au (8.8.7/8.8.7) with ESMTP id OAA25398; Wed, 6 Sep 2000 14:34:13 +0800 Received: from jules.elischer.org (reggae-20-221.nv.iinet.net.au [203.59.85.221]) by muzak.iinet.net.au (8.8.5/8.8.5) with SMTP id OAA00331; Wed, 6 Sep 2000 14:34:07 +0800 Message-ID: <39B5E55A.167EB0E7@elischer.org> Date: Tue, 05 Sep 2000 23:34:02 -0700 From: Julian Elischer X-Mailer: Mozilla 3.04Gold (X11; I; FreeBSD 5.0-CURRENT i386) MIME-Version: 1.0 To: Warner Losh Cc: Robert Watson , Wes Peters , Seigo Tanimura , current@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: the ifp to a removed pcmcia ethernet card is left in struct ip_moptions and struct ifmultiaddr References: <200009051843.MAA62492@harmony.village.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Warner Losh wrote: > > NetBSD has done some interesting things in this area with reference > counting and such that I'd love to bring in as soon as I get newcard > done. A few years ago I did some work on rationalising the reference counting in the kernel WRT network routes and ifps. Some of it was actually checked in on a branch, however it should probably be done from scratch since so much has changed. the basic things I did were: ALL references to ifps were counted (mbufs too, though that was never checked in) References to ifnets in many structures were changed to be references to ifaddrs attached to the ifnets instead. Ifaddrs and ifnet structs had a 'VALID' flag added to them. Whenever a new pointer to an ifnet/ifaddr was followed, the VALID flag was checked. if the VALID flag was not set then the operation was aborted and the reference being followed was dropped. (on reaching 0 the target was freed). If you freed an interface, then the structures would hang around as long as they had refering pointers outstanding. This could possibly lead to a leak, but that would by definition also be a leak of mbufs or routes. The ifaddrs also had references to the ifps. However on boing made invalid, they dropped those references immediatly. so theoretically, since many structs pointed to ifaddrs instead of ifnets, it would be quite possible for the ifnet structs to be freed long before an ifaddr that was once attached to it. (this was safe because the VALID flag was not set in the ifaddr, so nothing would follow the pointer. (which was NULLED out anyhow). I had a set of small methods to do these dereferences and stuff, but the hardest part was deciding in the CALLING routines (e.g. ipoutput) what to do when you discovered that the ifnet you were going to access came back as INVALID). Note that this didn't totally close the window for disaster as it is possible that an interface might be disabled between the time that you followed the ifp and the time that you used the pointer. it took it down to millisecconds however as opposed to seconds. I think it would be possible using sufficiently paranoid coding to completely close the window, but the question is raised "how much time do you want to waste in normal operation being paranoid?" With SMP the windows widen again, so we need to think a lot about this. Maybe all Interface removals are not done directly but handled in a serialised manner by some kernel thread? This feeds into what I believe should be done in the general case of device removal, which is the creation of a devd kernel thread, that responds to requests from drivers to instatiate and deinstanciate system linkages. having this done by the drivers themselves raises so many complications WRT locking and such that I think it would be a win overall. The drivers would supply code to be run by the devd, using methods supplied by the devd. -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ presently in: Perth v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Sep 6 0:51:22 2000 Delivered-To: freebsd-net@freebsd.org Received: from inetfw.sonycsl.co.jp (inetfw.SonyCSL.CO.JP [203.137.129.4]) by hub.freebsd.org (Postfix) with ESMTP id 8EFFF37B43E for ; Wed, 6 Sep 2000 00:51:19 -0700 (PDT) Received: from hotaka.csl.sony.co.jp (hotaka.csl.sony.co.jp [43.27.98.57]) by inetfw.sonycsl.co.jp (8.9.3+3.2W/3.7Ws3/inetfw/2000050701/smtpfeed 1.07) with ESMTP id QAA30787; Wed, 6 Sep 2000 16:51:12 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by hotaka.csl.sony.co.jp (8.9.3+3.2W/3.7Ws3/hotaka/2000061722) with ESMTP id QAA72547; Wed, 6 Sep 2000 16:51:12 +0900 (JST) To: bde@zeta.org.au Cc: freebsd-net@FreeBSD.ORG Subject: rdtsc overhead (was Re: Running ALTQ) In-Reply-To: References: <20000905133613H.kjc@csl.sony.co.jp> X-Mailer: Mew version 1.94.2 on Emacs 20.6 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000906165112Y.kjc@csl.sony.co.jp> Date: Wed, 06 Sep 2000 16:51:12 +0900 From: Kenjiro Cho X-Dispatcher: imput version 20000228(IM140) Lines: 34 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Bruce Evans wrote: > > It requires only one machine cycle to read a processor cycle couner > > (timestamp counter for pentium), which is much cheaper than using > > microtime(). However, it doesn't affect the kernel timer resolution. > > It takes more than one cycle, at least in a loop. I just retried the > following: > > main() > { > __asm(" > movl $100000000,%ecx > .align 4,0x90 > 1: > rdtsc > decl %ecx > nop > jne 1b > "); > } > > and it took 30 cycles on a Celeron and 12 cycles on a P5 (32 and 14 > cycles, respectively, including 2 cycles of loop overhead). Hmmm, I've confirmed the result. If another rdtsc is inserted in the loop, it almost doubles the execution time, which suggests the loop overhead is negligible. But 30 cycles sound a bit too long. As I understand it, rdtsc is not a serializing instruction. Is it more than latching the counter plus reading the 64bit value into 2 32bit registers? -Kenjiro To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Sep 6 5:15:38 2000 Delivered-To: freebsd-net@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id A711037B424 for ; Wed, 6 Sep 2000 05:15:34 -0700 (PDT) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.8.7/8.8.7) with ESMTP id XAA08161; Wed, 6 Sep 2000 23:15:24 +1100 Date: Wed, 6 Sep 2000 23:15:21 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Kenjiro Cho Cc: freebsd-net@FreeBSD.ORG Subject: Re: rdtsc overhead (was Re: Running ALTQ) In-Reply-To: <20000906165112Y.kjc@csl.sony.co.jp> 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, 6 Sep 2000, Kenjiro Cho wrote: > > Bruce Evans wrote: > > main() > > { > > __asm(" > > movl $100000000,%ecx > > .align 4,0x90 > > 1: > > rdtsc > > decl %ecx > > nop > > jne 1b > > "); > > } > > > > and it took 30 cycles on a Celeron and 12 cycles on a P5 (32 and 14 > > cycles, respectively, including 2 cycles of loop overhead). > > Hmmm, I've confirmed the result. If another rdtsc is inserted in the > loop, it almost doubles the execution time, which suggests the loop > overhead is negligible. > > But 30 cycles sound a bit too long. As I understand it, rdtsc is not > a serializing instruction. Is it more than latching the counter plus > reading the 64bit value into 2 32bit registers? I don't know exactly what it does. Apperently the latch operation is slow. 12 cycles was on a P5/133 and 30 cycles was on a Celeron 366 overclocked to 522. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Sep 6 6:29:30 2000 Delivered-To: freebsd-net@freebsd.org Received: from relay1.ntu-kpi.kiev.ua (www.ntu-kpi.kiev.ua [212.111.192.161]) by hub.freebsd.org (Postfix) with ESMTP id 73A8E37B424 for ; Wed, 6 Sep 2000 06:29:26 -0700 (PDT) Received: by relay1.ntu-kpi.kiev.ua (Postfix, from userid 1122) id 0F0572FA47; Wed, 6 Sep 2000 16:29:17 +0300 (EEST) From: Yaroslav Halchinsky To: freebsd-net@freebsd.org Subject: Re: mpd-netgraph and vpn issues In-Reply-To: <002801c017b3$76ab5a60$0302010a@biohz.net> User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (FreeBSD/3.4-STABLE (i386)) Message-Id: <20000906132917.0F0572FA47@relay1.ntu-kpi.kiev.ua> Date: Wed, 6 Sep 2000 16:29:17 +0300 (EEST) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Renaud Waldura wrote: >> The compression/encryption stuff is working great and I am sure it is > Now tell me, how did you get the compression/encryption to work? > I was under the impression that compression+encryption required code not > present in the FreeBSD distribution, and hence was not available. Do Windows > clients connect with the "Require data encryption" setting (on by default)? Not sure about compression, but encryption support works well. -- Regards, Yaroslav Halchinsky To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Sep 6 11:53: 6 2000 Delivered-To: freebsd-net@freebsd.org Received: from ebola.biohz.net (ebola.biohz.net [206.80.1.35]) by hub.freebsd.org (Postfix) with ESMTP id 8444B37B423 for ; Wed, 6 Sep 2000 11:53:03 -0700 (PDT) Received: from rabies (localhost [127.0.0.1]) by ebola.biohz.net (Postfix) with SMTP id 127793A46E for ; Wed, 6 Sep 2000 11:53:03 -0700 (PDT) Message-ID: <00ad01c01833$af605a60$0302010a@biohz.net> From: "Renaud Waldura" To: References: <20000906132917.0F0572FA47@relay1.ntu-kpi.kiev.ua> Subject: Re: mpd-netgraph and vpn issues Date: Wed, 6 Sep 2000 11:53:02 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.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 My mistake. I misread the manpage: COMPILATION The kernel options NETGRAPH_MPPC_COMPRESSION and NETGRAPH_MPPC_ENCRYPTION are supplied to selectively compile in either or both capabilities. At least one of these must be defined, or else this node type is useless. The MPPC protocol requires proprietary compression code available from Hi/Fn (formerly STAC). These files must be obtained elsewhere and added to the kernel sources before this node type will compile with the NETGRAPH_MPPC_COMPRESSION option. NETGRAPH_MPPC_ENCRYPTION defaults to 1. NETGRAPH_MPPC_COMPRESSION defaults to 0; it uses proprietary code. So the bottom line is, encryption works OK but there is no compression yet. Has anyone compared the performance of this implementation vs. a native Windows PPTP server with compression enabled? --Renaud ----- Original Message ----- From: Yaroslav Halchinsky To: Sent: Wednesday, September 06, 2000 6:29 AM Subject: Re: mpd-netgraph and vpn issues > Renaud Waldura wrote: > > > Now tell me, how did you get the compression/encryption to work? > > > I was under the impression that compression+encryption required code not > > present in the FreeBSD distribution, and hence was not available. Do Windows > > clients connect with the "Require data encryption" setting (on by default)? > > Not sure about compression, but encryption support works well. > > -- > Regards, > Yaroslav Halchinsky To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Sep 6 14:19:30 2000 Delivered-To: freebsd-net@freebsd.org Received: from relay2.wertep.com (relay2.wertep.com [194.44.90.130]) by hub.freebsd.org (Postfix) with ESMTP id 3A16E37B422; Wed, 6 Sep 2000 14:19:16 -0700 (PDT) Received: from She.wertep.com (she-tun-proxy [192.168.252.2]) by relay2.wertep.com (8.9.3/8.9.3) with ESMTP id AAA97554; Thu, 7 Sep 2000 00:19:05 +0300 (EEST) (envelope-from petro@She.wertep.com) Received: from localhost (petro@localhost) by She.wertep.com (8.9.3/8.9.3) with ESMTP id AAA00528; Thu, 7 Sep 2000 00:19:04 +0300 (EEST) (envelope-from petro@She.wertep.com) Date: Thu, 7 Sep 2000 00:19:00 +0300 (EEST) From: petro To: freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Problem!! 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 have the following problem my local network (192.168.x.x) is connected to server, and use squid on the next server to run Explorer, Nescape. I can run Inetner Explorer and Netscape but when I try to run ping any.hos I receive only it's number arequested timed out . My ipfw is working good, also named works good(I receive IP address of machines) but I can't understand where is problem Thank you very much To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Sep 6 14:37:17 2000 Delivered-To: freebsd-net@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 53E6237B423; Wed, 6 Sep 2000 14:37:14 -0700 (PDT) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e86Lafu23535; Wed, 6 Sep 2000 14:36:41 -0700 (PDT) Date: Wed, 6 Sep 2000 14:36:41 -0700 From: Alfred Perlstein To: petro Cc: freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: Problem!! Message-ID: <20000906143641.P18862@fw.wintelcom.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: ; from petro@She.wertep.com on Thu, Sep 07, 2000 at 12:19:00AM +0300 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * petro [000906 14:19] wrote: > Hi! > I have the following problem my local network (192.168.x.x) is connected > to server, and use squid on the next server to run Explorer, Nescape. I > can run Inetner Explorer and Netscape but when I try to run ping > any.hos I receive only it's number arequested timed out . My ipfw is > working good, also named works good(I receive IP address of machines) but > I can't understand where is problem > Thank you very much Unless you're using NAT then your packets are going out onto the internet as 192.168.x.x and the internet has no clue how to get these packets back to you. Solution, install NATd. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Sep 7 2:20:17 2000 Delivered-To: freebsd-net@freebsd.org Received: from bilbo.w-link.net (bilbo.w-link.net [206.98.114.20]) by hub.freebsd.org (Postfix) with ESMTP id 19E0A37B42C for ; Thu, 7 Sep 2000 02:20:12 -0700 (PDT) Received: from mail.w-link.net ([209.236.216.224]) by bilbo.w-link.net (8.9.3/8.9.3) with SMTP id CAA15375 for ; Thu, 7 Sep 2000 02:20:37 -0700 (PDT) X-Server: Advanced Direct Remailer (www.elcomsoft.com) Message-ID: <001101c018ab$67c6a600$e0d8ecd1@camano> From: "BluzMan" To: Subject: NIC Bonding Date: Thu, 7 Sep 2000 02:10:00 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I have been scouring the FBSD docs and related web pages trying to find out if FBSD 4.1 supports any form of NIC bonding, whereby one can take multiple network cards and assign them a single IP for increased bandwidth. I am working on a project where I would like to take two fast ethernet NICs and tie them to a Cisco switch for a 200 mbps connection. I have gotten the ifconfig vlan switch to properly connect a single NIC to a single switched port, but the ifconfig vlan switch appears to be limited to supporting a sole network card. I would greatly appreciate any input or experience on this matter. Respectfully, Drew B. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Sep 7 9:30:36 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 B56DF37B424 for ; Thu, 7 Sep 2000 09:30:33 -0700 (PDT) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id MAA30115; Thu, 7 Sep 2000 12:30:29 -0400 (EDT) (envelope-from wollman) Date: Thu, 7 Sep 2000 12:30:29 -0400 (EDT) From: Garrett Wollman Message-Id: <200009071630.MAA30115@khavrinen.lcs.mit.edu> To: Ruslan Ermilov Cc: net@FreeBSD.org Subject: Re: cvs commit: src/sys/netinet ip_divert.c ip_icmp.c ip_input.c ip_mroute.c ip_output.c raw_ip.c udp_usrreq.c In-Reply-To: <20000907092610.A46475@sunbay.com> References: <200009011233.FAA69145@freefall.freebsd.org> <200009061845.OAA20964@khavrinen.lcs.mit.edu> <20000907092610.A46475@sunbay.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > The same does NetBSD, but I feel more logical is to have all these fields > in host byte order right after ip_input() processing. Why? There is no earthly reason for ip_id to *ever* be swapped. -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 Sep 7 15:28:22 2000 Delivered-To: freebsd-net@freebsd.org Received: from valis.worldgate.ca (valis.worldgate.ca [198.161.84.2]) by hub.freebsd.org (Postfix) with ESMTP id 72CB237B423 for ; Thu, 7 Sep 2000 15:28:19 -0700 (PDT) Received: from worldgate.com (diskless4.worldgate.ca [198.161.84.132]) by valis.worldgate.ca (8.9.3/8.9.3) with ESMTP id QAA31633 for ; Thu, 7 Sep 2000 16:28:13 -0600 (MDT) (envelope-from skafte@worldgate.com) Message-ID: <39B8167D.1B834E8C@worldgate.com> Date: Thu, 07 Sep 2000 16:28:13 -0600 From: Greg Skafte Organization: WorldGate Inc X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.0.36 i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Strange behaviour?? Content-Type: multipart/mixed; boundary="------------A222471AC47031B3956011EE" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is a multi-part message in MIME format. --------------A222471AC47031B3956011EE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit on a RELENG_4 box supped yesterday, I did the following ifconfig fxp1 delete ifconfig fxp1 down now if I do a netstat -rn there are still residual routes to fxp1 host routes broadcast routes network routes should this be the case? after all if I'm going to the extreme of a ifconfig delete would it not be safe to assume that any hosts that were learned by that interface would no longer be reachable through that interface? I'm not saying the behaviour is correct or incorrect, just not what I expected. -- Email: skafte@worldgate.ca Voice: +780 413 1910 Fax: +780 421 4929 #575 Sun Life Place * 10123 99 Street * Edmonton, AB * Canada * T5J 3H1 -- -- When things can't get any worse, they simplify themselves by getting a whole lot worse then complicated. A complete and utter disaster is the simplest thing in the world; it's preventing one that's complex. (Janet Morris) --------------A222471AC47031B3956011EE Content-Type: text/x-vcard; charset=us-ascii; name="skafte.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Greg Skafte Content-Disposition: attachment; filename="skafte.vcf" begin:vcard n:Skafte;Greg tel;pager:+1 (780) 491 4791 tel;cell:+1 (780) 718 1570 tel;fax:+1 (780) 421 4929 tel;work:+1 (780) 413 1910 x-mozilla-html:FALSE org:;Network Operations adr:;;#575 10123 99 Street;Edmonton;Alberta;T5J 3H1;Canada version:2.1 email;internet:Skafte@worldgate.ca title:Operations Manager x-mozilla-cpt:;29088 fn:Greg Skafte end:vcard --------------A222471AC47031B3956011EE-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Sep 8 4:18:30 2000 Delivered-To: freebsd-net@freebsd.org Received: from mail2.netcologne.de (mail2.netcologne.de [194.8.194.103]) by hub.freebsd.org (Postfix) with ESMTP id D5E0D37B424; Fri, 8 Sep 2000 04:18:23 -0700 (PDT) Received: from bagabeedaboo.security.at12.de (dial-213-168-73-75.netcologne.de [213.168.73.75]) by mail2.netcologne.de (8.9.3/8.9.3) with ESMTP id NAA22516; Fri, 8 Sep 2000 13:18:21 +0200 (MET DST) Received: from localhost (localhost.security.at12.de [127.0.0.1]) by bagabeedaboo.security.at12.de (8.11.0/8.11.0) with ESMTP id e88BIDe02678; Fri, 8 Sep 2000 13:18:13 +0200 (CEST) (envelope-from pherman@frenchfries.net) Date: Fri, 8 Sep 2000 13:18:13 +0200 (CEST) From: Paul Herman To: Ramses Smeyers Cc: freebsd-net@FreeBSD.ORG Subject: Re: useripacct 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 [ ...brought over to freebsd-net... ] On Fri, 8 Sep 2000, Ramses Smeyers wrote: > > ipfw(8) in FreeBSD can count packets/bytes based on uid and gid (based > > on local socket credentials.) > > are we then talking about a rule for every user?, and can this system be > used as disk quota, so with hard and soft quota (like > useripacct) does. The aim of the useripacct patch is to give a user 200MB > traffic for one month, and let their traffic block after those 200MB are > used. To implement this in freebsd, do I have to place a rule for every > user, this is like not scalable, and is their a daemon available to > control the IP flow and block users if it has to be done ? ipfw doesn't implement quotas, but yes you would have to have a separate rule for each uid/gid -- agreed, not so efficient for ipfw to do. BTW, this topic has been brushed by the freebsd-net crowd before, so you might want to arm yourself :) and browse the freebsd-net mail archive first (try keywords like "ipfw", "quota", ...) http://www.freebsd.org/search/search.html Other than that, I can imagine an optional external daemon similar to natd(8) which enforces network quotas via a "divert" ipfw rule. Whether or not network quotas are a good thing(tm) is a whole other question all together... :) -Paul. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Sep 8 4:25:32 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 C1D6C37B424 for ; Fri, 8 Sep 2000 04:25:26 -0700 (PDT) Received: (from luigi@localhost) by info.iet.unipi.it (8.9.3/8.9.3) id NAA33256; Fri, 8 Sep 2000 13:26:13 +0200 (CEST) (envelope-from luigi) From: Luigi Rizzo Message-Id: <200009081126.NAA33256@info.iet.unipi.it> Subject: Re: useripacct In-Reply-To: from Paul Herman at "Sep 8, 2000 01:18:13 pm" To: Paul Herman Date: Fri, 8 Sep 2000 13:26:13 +0200 (CEST) Cc: Ramses Smeyers , 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 > ipfw doesn't implement quotas, but yes you would have to have a > separate rule for each uid/gid -- agreed, not so efficient for ipfw to > do. Not really. There are several pieces now in ipfw/dummynet which can generate rules and pipes from a template, (see the keep-state rules and the "mask" specifier in dummynet pipes), so the implementation of per-uid quotas would be efficient and rather trivial (basically a small modification to dynamic pipes where you just check the quota). > Other than that, I can imagine an optional external daemon similar to > natd(8) which enforces network quotas via a "divert" ipfw rule. killing performance in the meantime... cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Sep 8 5:15:27 2000 Delivered-To: freebsd-net@freebsd.org Received: from hidrogenio.widesoft.com.br (hidrogenio.widesoft.com.br [200.246.206.1]) by hub.freebsd.org (Postfix) with ESMTP id 3F5D337B423 for ; Fri, 8 Sep 2000 05:15:24 -0700 (PDT) Received: from widesoft.com.br (coruscant.widesoft.com.br [200.246.206.12]) by hidrogenio.widesoft.com.br (Postfix) with ESMTP id 28B0591A6F for ; Fri, 8 Sep 2000 09:15:13 -0300 (EST) Message-ID: <39B8B0D2.B74602D0@widesoft.com.br> Date: Fri, 08 Sep 2000 06:26:42 -0300 From: Alexandre Roberto Zia X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.2.16 i686) X-Accept-Language: en MIME-Version: 1.0 Cc: freebsd-net@FreeBSD.ORG Subject: syslog - is a bug? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org An user try to update my DNS, but my version of named don't permit this, but my syslogd becomes crazy, incapable to permit a reload of my named. Anyone here know what happened? -- _____________________________________________________ Alexandre Roberto Zia zia@gullo.com.br Administrador de Rede Widesoft Sistemas Ltda. Limeira SP Brasil +55 19 451 6300 ICQ# 13404662 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Sep 8 6:11:58 2000 Delivered-To: freebsd-net@freebsd.org Received: from walhalla.sin.khk.be (ns.sin.khk.be [194.7.78.21]) by hub.freebsd.org (Postfix) with ESMTP id 473F437B422 for ; Fri, 8 Sep 2000 06:11:56 -0700 (PDT) Received: from localhost (fatman@localhost) by walhalla.sin.khk.be (8.9.3/8.9.1) with ESMTP id PAA07883; Fri, 8 Sep 2000 15:11:53 +0200 X-Authentication-Warning: walhalla.sin.khk.be: fatman owned process doing -bs Date: Fri, 8 Sep 2000 15:11:53 +0200 (CEST) From: Ramses Smeyers X-Sender: fatman@walhalla.sin.khk.be To: Paul Herman Cc: freebsd-net@FreeBSD.ORG Subject: Re: useripacct 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 Hi, > Other than that, I can imagine an optional external daemon similar to > natd(8) which enforces network quotas via a "divert" ipfw rule. > Whether or not network quotas are a good thing(tm) is a whole other > question all together... :) first off all, I will certainly look up this stuff in the archives. Then second, it is a good things. Large shell servers, (we are speaking in the size of workspot and co), have to deal with 40k local users which are generating huge amounts of traffic. 'Some' of those users are not your average users ;), they generate a large amount of traffic and spoil the fun of the entire group. For those 100 users, you have to imply rules on all your users. So yes, this features does have a future and I would like to see this in the FreeBSD system, if you people don't like it, I just do it ;), ys, Ramses Smeyers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Sep 8 7:23:10 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 18D1E37B423 for ; Fri, 8 Sep 2000 07:22:48 -0700 (PDT) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.9.3/1.13) id RAA27502; Fri, 8 Sep 2000 17:21:45 +0300 (EEST) Date: Fri, 8 Sep 2000 17:21:45 +0300 From: Ruslan Ermilov To: Garrett Wollman Cc: net@FreeBSD.org Subject: Re: cvs commit: src/sys/netinet ip_divert.c ip_icmp.c ip_input.c ip_mroute.c ip_output.c raw_ip.c udp_usrreq.c Message-ID: <20000908172145.A27354@sunbay.com> Mail-Followup-To: Garrett Wollman , net@FreeBSD.org References: <200009011233.FAA69145@freefall.freebsd.org> <200009061845.OAA20964@khavrinen.lcs.mit.edu> <20000907092610.A46475@sunbay.com> <200009071630.MAA30115@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="OXfL5xGRrasGEqWY" X-Mailer: Mutt 1.0i In-Reply-To: <200009071630.MAA30115@khavrinen.lcs.mit.edu>; from wollman@khavrinen.lcs.mit.edu on Thu, Sep 07, 2000 at 12:30:29PM -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --OXfL5xGRrasGEqWY Content-Type: text/plain; charset=us-ascii On Thu, Sep 07, 2000 at 12:30:29PM -0400, Garrett Wollman wrote: > < said: > > > The same does NetBSD, but I feel more logical is to have all these fields > > in host byte order right after ip_input() processing. > > Why? There is no earthly reason for ip_id to *ever* be swapped. > Ok, here is the patch that completely eliminates `ip_id' swapping, bringing us in sync with BSD/OS and NetBSD. It reverts part of my previously committed `icmp error generation fixes' 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 --OXfL5xGRrasGEqWY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="patch-5.0-CURRENT" Index: man4/ip.4 =================================================================== RCS file: /home/ncvs/src/share/man/man4/ip.4,v retrieving revision 1.16 diff -u -p -r1.16 ip.4 --- man4/ip.4 2000/09/01 13:06:57 1.16 +++ man4/ip.4 2000/09/08 14:17:14 @@ -32,7 +32,7 @@ .\" @(#)ip.4 8.2 (Berkeley) 11/30/93 .\" $FreeBSD: src/share/man/man4/ip.4,v 1.16 2000/09/01 13:06:57 sheldonh Exp $ .\" -.Dd September 1, 2000 +.Dd November 30, 1993 .Dt IP 4 .Os BSD 4.2 .Sh NAME @@ -368,10 +368,6 @@ ip->ip_off = offset; If the header source address is set to .Dv INADDR_ANY, the kernel will choose an appropriate address. -.Pp -The header identification field -.Dq Li ip_id -is expected in host byte order. .Sh DIAGNOSTICS A socket operation may fail with one of the following errors returned: .Bl -tag -width [EADDRNOTAVAIL] @@ -420,11 +416,3 @@ The .Nm protocol appeared in .Bx 4.2 . -.Pp -If the -.Dv IP_HDRINCL -option is in use, -.Fx 4.2 -and above expect the -.Dq Li ip_id -field in host byte order. Index: net/bridge.c =================================================================== RCS file: /home/ncvs/src/sys/net/bridge.c,v retrieving revision 1.23 diff -u -p -r1.23 bridge.c --- net/bridge.c 2000/07/29 02:00:12 1.23 +++ net/bridge.c 2000/09/08 14:17:14 @@ -718,7 +718,6 @@ bdg_forward(struct mbuf **m0, struct eth */ ip = mtod(m, struct ip *); NTOHS(ip->ip_len); - NTOHS(ip->ip_id); NTOHS(ip->ip_off); /* @@ -744,7 +743,6 @@ bdg_forward(struct mbuf **m0, struct eth * Then, if canfree==1, also restore *m0. */ HTONS(ip->ip_len); - HTONS(ip->ip_id); HTONS(ip->ip_off); if (canfree) /* m was a reference to *m0, so update *m0 */ *m0 = m ; Index: netinet/ip_auth.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_auth.c,v retrieving revision 1.18 diff -u -p -r1.18 ip_auth.c --- netinet/ip_auth.c 2000/08/01 17:14:38 1.18 +++ netinet/ip_auth.c 2000/09/08 14:17:14 @@ -250,7 +250,7 @@ ip_t *ip; bo = ip->ip_len; ip->ip_len = htons(bo); -# if !SOLARIS && !defined(__NetBSD__) +# if !SOLARIS && !defined(__NetBSD__) && !defined(__FreeBSD__) /* 4.4BSD converts this ip_input.c, but I don't in solaris.c */ bo = ip->ip_id; ip->ip_id = htons(bo); Index: netinet/ip_divert.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_divert.c,v retrieving revision 1.46 diff -u -p -r1.46 ip_divert.c --- netinet/ip_divert.c 2000/09/01 12:33:03 1.46 +++ netinet/ip_divert.c 2000/09/08 14:17:14 @@ -293,7 +293,6 @@ div_output(so, m, addr, control) /* Convert fields to host order for ip_output() */ NTOHS(ip->ip_len); - NTOHS(ip->ip_id); NTOHS(ip->ip_off); /* Send packet to output processing */ Index: netinet/ip_fil.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_fil.c,v retrieving revision 1.21 diff -u -p -r1.21 ip_fil.c --- netinet/ip_fil.c 2000/08/13 04:31:05 1.21 +++ netinet/ip_fil.c 2000/09/08 14:17:14 @@ -1369,7 +1369,9 @@ frdest_t *fdp; i = 1; # endif # ifndef sparc +# ifndef __FreeBSD__ ip->ip_id = htons(ip->ip_id); +# endif ip->ip_len = htons(ip->ip_len); ip->ip_off = htons(ip->ip_off); # endif Index: netinet/ip_icmp.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_icmp.c,v retrieving revision 1.44 diff -u -p -r1.44 ip_icmp.c --- netinet/ip_icmp.c 2000/09/01 12:33:03 1.44 +++ netinet/ip_icmp.c 2000/09/08 14:17:14 @@ -196,7 +196,6 @@ icmp_error(n, type, code, dest, destifp) * Convert fields to network representation. */ HTONS(nip->ip_len); - HTONS(nip->ip_id); HTONS(nip->ip_off); /* Index: netinet/ip_input.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_input.c,v retrieving revision 1.139 diff -u -p -r1.139 ip_input.c --- netinet/ip_input.c 2000/09/01 12:33:03 1.139 +++ netinet/ip_input.c 2000/09/08 14:17:15 @@ -346,7 +346,6 @@ ip_input(struct mbuf *m) ipstat.ips_badlen++; goto bad; } - NTOHS(ip->ip_id); NTOHS(ip->ip_off); /* @@ -692,10 +691,8 @@ found: ip->ip_len += hlen; HTONS(ip->ip_len); HTONS(ip->ip_off); - HTONS(ip->ip_id); ip->ip_sum = 0; ip->ip_sum = in_cksum_hdr(ip); - NTOHS(ip->ip_id); NTOHS(ip->ip_off); NTOHS(ip->ip_len); ip->ip_len -= hlen; @@ -725,7 +722,6 @@ found: ip->ip_len += hlen; HTONS(ip->ip_len); HTONS(ip->ip_off); - HTONS(ip->ip_id); /* Deliver packet to divert input routine */ ip_divert_cookie = divert_cookie; Index: netinet/ip_mroute.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_mroute.c,v retrieving revision 1.58 diff -u -p -r1.58 ip_mroute.c --- netinet/ip_mroute.c 2000/09/01 12:33:03 1.58 +++ netinet/ip_mroute.c 2000/09/08 14:17:16 @@ -1581,7 +1581,7 @@ encap_send(ip, vifp, m) */ ip_copy = mtod(mb_copy, struct ip *); *ip_copy = multicast_encap_iphdr; - ip_copy->ip_id = ip_id++; + ip_copy->ip_id = htons(ip_id++); ip_copy->ip_len += len; ip_copy->ip_src = vifp->v_lcl_addr; ip_copy->ip_dst = vifp->v_rmt_addr; @@ -1592,7 +1592,6 @@ encap_send(ip, vifp, m) ip = (struct ip *)((caddr_t)ip_copy + sizeof(multicast_encap_iphdr)); --ip->ip_ttl; HTONS(ip->ip_len); - HTONS(ip->ip_id); HTONS(ip->ip_off); ip->ip_sum = 0; mb_copy->m_data += sizeof(multicast_encap_iphdr); Index: netinet/ip_output.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_output.c,v retrieving revision 1.110 diff -u -p -r1.110 ip_output.c --- netinet/ip_output.c 2000/09/01 12:33:03 1.110 +++ netinet/ip_output.c 2000/09/08 14:17:16 @@ -211,7 +211,7 @@ ip_output(m0, opt, ro, flags, imo) if ((flags & (IP_FORWARDING|IP_RAWOUTPUT)) == 0) { ip->ip_vhl = IP_MAKE_VHL(IPVERSION, hlen >> 2); ip->ip_off &= IP_DF; - ip->ip_id = ip_id++; + ip->ip_id = htons(ip_id++); ipstat.ips_localout++; } else { hlen = IP_VHL_HL(ip->ip_vhl) << 2; @@ -520,7 +520,6 @@ sendit: /* Restore packet header fields to original values */ HTONS(ip->ip_len); - HTONS(ip->ip_id); HTONS(ip->ip_off); /* Deliver packet to divert input routine */ @@ -595,7 +594,6 @@ sendit: m->m_pkthdr.csum_flags |= CSUM_IP_CHECKED | CSUM_IP_VALID; HTONS(ip->ip_len); - HTONS(ip->ip_id); HTONS(ip->ip_off); ip_input(m); goto done; @@ -715,7 +713,6 @@ pass: } HTONS(ip->ip_len); - HTONS(ip->ip_id); HTONS(ip->ip_off); error = ipsec4_output(&state, sp, flags); @@ -776,7 +773,6 @@ pass: /* make it flipped, again. */ NTOHS(ip->ip_len); - NTOHS(ip->ip_id); NTOHS(ip->ip_off); skip_ipsec: #endif /*IPSEC*/ @@ -796,7 +792,6 @@ skip_ipsec: if ((u_short)ip->ip_len <= ifp->if_mtu || ifp->if_hwassist & CSUM_FRAGMENT) { HTONS(ip->ip_len); - HTONS(ip->ip_id); HTONS(ip->ip_off); ip->ip_sum = 0; if (sw_csum & CSUM_DELAY_IP) { @@ -892,7 +887,6 @@ skip_ipsec: m->m_pkthdr.len = mhlen + len; m->m_pkthdr.rcvif = (struct ifnet *)0; m->m_pkthdr.csum_flags = m0->m_pkthdr.csum_flags; - HTONS(mhip->ip_id); HTONS(mhip->ip_off); mhip->ip_sum = 0; if (sw_csum & CSUM_DELAY_IP) { @@ -921,7 +915,6 @@ skip_ipsec: m_adj(m, hlen + firstlen - (u_short)ip->ip_len); m->m_pkthdr.len = hlen + firstlen; ip->ip_len = htons((u_short)m->m_pkthdr.len); - HTONS(ip->ip_id); ip->ip_off |= IP_MF; HTONS(ip->ip_off); ip->ip_sum = 0; @@ -1864,7 +1857,6 @@ ip_mloopback(ifp, m, dst, hlen) */ ip = mtod(copym, struct ip *); HTONS(ip->ip_len); - HTONS(ip->ip_id); HTONS(ip->ip_off); ip->ip_sum = 0; if (ip->ip_vhl == IP_VHL_BORING) { Index: netinet/raw_ip.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/raw_ip.c,v retrieving revision 1.68 diff -u -p -r1.68 raw_ip.c --- netinet/raw_ip.c 2000/09/01 12:33:03 1.68 +++ netinet/raw_ip.c 2000/09/08 14:17:16 @@ -221,7 +221,7 @@ rip_output(m, so, dst) return EINVAL; } if (ip->ip_id == 0) - ip->ip_id = ip_id++; + ip->ip_id = htons(ip_id++); /* XXX prevent ip_output from overwriting header fields */ flags |= IP_RAWOUTPUT; ipstat.ips_rawout++; Index: netinet6/ah_input.c =================================================================== RCS file: /home/ncvs/src/sys/netinet6/ah_input.c,v retrieving revision 1.4 diff -u -p -r1.4 ah_input.c --- netinet6/ah_input.c 2000/08/16 09:56:45 1.4 +++ netinet6/ah_input.c 2000/09/08 14:17:16 @@ -291,7 +291,6 @@ ah4_input(m, va_alist) * convert them back to network endian. VERY stupid. */ ip->ip_len = htons(ip->ip_len + hlen); - ip->ip_id = htons(ip->ip_id); ip->ip_off = htons(ip->ip_off); #endif if (ah4_calccksum(m, (caddr_t)cksum, siz1, algo, sav)) { @@ -305,7 +304,6 @@ ah4_input(m, va_alist) * flip them back. */ ip->ip_len = ntohs(ip->ip_len) - hlen; - ip->ip_id = ntohs(ip->ip_id); ip->ip_off = ntohs(ip->ip_off); #endif } --OXfL5xGRrasGEqWY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="patch-4.1-STABLE" Index: net/bridge.c =================================================================== RCS file: /home/ncvs/src/sys/net/bridge.c,v retrieving revision 1.16.2.4 diff -u -p -r1.16.2.4 bridge.c --- net/bridge.c 2000/08/03 00:09:34 1.16.2.4 +++ net/bridge.c 2000/09/08 14:18:14 @@ -713,7 +713,6 @@ bdg_forward(struct mbuf **m0, struct eth */ ip = mtod(m, struct ip *); NTOHS(ip->ip_len); - NTOHS(ip->ip_id); NTOHS(ip->ip_off); /* @@ -739,7 +738,6 @@ bdg_forward(struct mbuf **m0, struct eth * Then, if canfree==1, also restore *m0. */ HTONS(ip->ip_len); - HTONS(ip->ip_id); HTONS(ip->ip_off); if (canfree) /* m was a reference to *m0, so update *m0 */ *m0 = m ; Index: netinet/ip_auth.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_auth.c,v retrieving revision 1.14.2.3 diff -u -p -r1.14.2.3 ip_auth.c --- netinet/ip_auth.c 2000/08/04 17:52:23 1.14.2.3 +++ netinet/ip_auth.c 2000/09/08 14:18:14 @@ -250,7 +250,7 @@ ip_t *ip; bo = ip->ip_len; ip->ip_len = htons(bo); -# if !SOLARIS && !defined(__NetBSD__) +# if !SOLARIS && !defined(__NetBSD__) && !defined(__FreeBSD__) /* 4.4BSD converts this ip_input.c, but I don't in solaris.c */ bo = ip->ip_id; ip->ip_id = htons(bo); Index: netinet/ip_fil.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_fil.c,v retrieving revision 1.14.2.2 diff -u -p -r1.14.2.2 ip_fil.c --- netinet/ip_fil.c 2000/07/19 23:27:55 1.14.2.2 +++ netinet/ip_fil.c 2000/09/08 14:18:14 @@ -1364,7 +1364,9 @@ frdest_t *fdp; i = 1; # endif # ifndef sparc +# ifndef __FreeBSD__ ip->ip_id = htons(ip->ip_id); +# endif ip->ip_len = htons(ip->ip_len); ip->ip_off = htons(ip->ip_off); # endif Index: netinet/ip_icmp.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_icmp.c,v retrieving revision 1.39.2.1 diff -u -p -r1.39.2.1 ip_icmp.c --- netinet/ip_icmp.c 2000/06/08 15:11:21 1.39.2.1 +++ netinet/ip_icmp.c 2000/09/08 14:18:14 @@ -199,7 +199,12 @@ icmp_error(n, type, code, dest, destifp) icp->icmp_code = code; bcopy((caddr_t)oip, (caddr_t)&icp->icmp_ip, icmplen); nip = &icp->icmp_ip; - nip->ip_len = htons((u_short)(nip->ip_len + oiplen)); + + /* + * Convert fields to network representation. + */ + HTONS(nip->ip_len); + HTONS(nip->ip_off); /* * Now, copy old ip header (without options) Index: netinet/ip_input.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_input.c,v retrieving revision 1.130.2.5 diff -u -p -r1.130.2.5 ip_input.c --- netinet/ip_input.c 2000/07/15 07:14:30 1.130.2.5 +++ netinet/ip_input.c 2000/09/08 14:18:14 @@ -341,7 +341,6 @@ ip_input(struct mbuf *m) ipstat.ips_badlen++; goto bad; } - NTOHS(ip->ip_id); NTOHS(ip->ip_off); /* @@ -508,18 +507,12 @@ pass: * The packet is returned (relatively) intact; if * ip_mforward() returns a non-zero value, the packet * must be discarded, else it may be accepted below. - * - * (The IP ident field is put in the same byte order - * as expected when ip_mforward() is called from - * ip_output().) */ - ip->ip_id = htons(ip->ip_id); if (ip_mforward(ip, m->m_pkthdr.rcvif, m, 0) != 0) { ipstat.ips_cantforward++; m_freem(m); return; } - ip->ip_id = ntohs(ip->ip_id); /* * The process-level routing demon needs to receive @@ -680,10 +673,8 @@ found: ip->ip_len += hlen; HTONS(ip->ip_len); HTONS(ip->ip_off); - HTONS(ip->ip_id); ip->ip_sum = 0; ip->ip_sum = in_cksum_hdr(ip); - NTOHS(ip->ip_id); NTOHS(ip->ip_off); NTOHS(ip->ip_len); ip->ip_len -= hlen; @@ -713,7 +704,6 @@ found: ip->ip_len += hlen; HTONS(ip->ip_len); HTONS(ip->ip_off); - HTONS(ip->ip_id); /* Deliver packet to divert input routine */ ip_divert_cookie = divert_cookie; @@ -1272,7 +1262,6 @@ nosourcerouting: } return (0); bad: - ip->ip_len -= IP_VHL_HL(ip->ip_vhl) << 2; /* XXX icmp_error adds in hdr length */ icmp_error(m, type, code, 0, 0); ipstat.ips_badoptions++; return (1); @@ -1478,7 +1467,6 @@ ip_forward(m, srcrt) m_freem(m); return; } - HTONS(ip->ip_id); #ifdef IPSTEALTH if (!ipstealth) { #endif @@ -1487,7 +1475,6 @@ ip_forward(m, srcrt) dest, 0); return; } - ip->ip_ttl -= IPTTLDEC; #ifdef IPSTEALTH } #endif @@ -1516,6 +1503,16 @@ ip_forward(m, srcrt) * we need to generate an ICMP message to the src. */ mcopy = m_copy(m, 0, imin((int)ip->ip_len, 64)); + if (mcopy && (mcopy->m_flags & M_EXT)) + m_copydata(mcopy, 0, sizeof(struct ip), mtod(mcopy, caddr_t)); + +#ifdef IPSTEALTH + if (!ipstealth) { +#endif + ip->ip_ttl -= IPTTLDEC; +#ifdef IPSTEALTH + } +#endif /* * If forwarding packet using same interface that it came in on, @@ -1654,6 +1651,8 @@ ip_forward(m, srcrt) m_freem(mcopy); return; } + if (mcopy->m_flags & M_EXT) + m_copyback(mcopy, 0, sizeof(struct ip), mtod(mcopy, caddr_t)); icmp_error(mcopy, type, code, dest, destifp); } Index: netinet/ip_output.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_output.c,v retrieving revision 1.99.2.6 diff -u -p -r1.99.2.6 ip_output.c --- netinet/ip_output.c 2000/07/15 07:14:30 1.99.2.6 +++ netinet/ip_output.c 2000/09/08 14:18:15 @@ -576,8 +576,8 @@ sendit: } m->m_pkthdr.csum_flags |= CSUM_IP_CHECKED | CSUM_IP_VALID; - ip->ip_len = htons((u_short)ip->ip_len); - ip->ip_off = htons((u_short)ip->ip_off); + HTONS(ip->ip_len); + HTONS(ip->ip_off); ip_input(m); goto done; } @@ -695,8 +695,8 @@ pass: m->m_pkthdr.csum_flags &= ~CSUM_DELAY_DATA; } - ip->ip_len = htons((u_short)ip->ip_len); - ip->ip_off = htons((u_short)ip->ip_off); + HTONS(ip->ip_len); + HTONS(ip->ip_off); error = ipsec4_output(&state, sp, flags); @@ -755,8 +755,8 @@ pass: } /* make it flipped, again. */ - ip->ip_len = ntohs((u_short)ip->ip_len); - ip->ip_off = ntohs((u_short)ip->ip_off); + NTOHS(ip->ip_len); + NTOHS(ip->ip_off); skip_ipsec: #endif /*IPSEC*/ @@ -774,8 +774,8 @@ skip_ipsec: */ if ((u_short)ip->ip_len <= ifp->if_mtu || ifp->if_hwassist & CSUM_FRAGMENT) { - ip->ip_len = htons((u_short)ip->ip_len); - ip->ip_off = htons((u_short)ip->ip_off); + HTONS(ip->ip_len); + HTONS(ip->ip_off); ip->ip_sum = 0; if (sw_csum & CSUM_DELAY_IP) { if (ip->ip_vhl == IP_VHL_BORING) { @@ -870,7 +870,7 @@ skip_ipsec: m->m_pkthdr.len = mhlen + len; m->m_pkthdr.rcvif = (struct ifnet *)0; m->m_pkthdr.csum_flags = m0->m_pkthdr.csum_flags; - mhip->ip_off = htons((u_short)mhip->ip_off); + HTONS(mhip->ip_off); mhip->ip_sum = 0; if (sw_csum & CSUM_DELAY_IP) { if (mhip->ip_vhl == IP_VHL_BORING) { @@ -898,7 +898,8 @@ skip_ipsec: m_adj(m, hlen + firstlen - (u_short)ip->ip_len); m->m_pkthdr.len = hlen + firstlen; ip->ip_len = htons((u_short)m->m_pkthdr.len); - ip->ip_off = htons((u_short)(ip->ip_off | IP_MF)); + ip->ip_off |= IP_MF; + HTONS(ip->ip_off); ip->ip_sum = 0; if (sw_csum & CSUM_DELAY_IP) { if (ip->ip_vhl == IP_VHL_BORING) { @@ -1838,8 +1839,8 @@ ip_mloopback(ifp, m, dst, hlen) * than the interface's MTU. Can this possibly matter? */ ip = mtod(copym, struct ip *); - ip->ip_len = htons((u_short)ip->ip_len); - ip->ip_off = htons((u_short)ip->ip_off); + HTONS(ip->ip_len); + HTONS(ip->ip_off); ip->ip_sum = 0; if (ip->ip_vhl == IP_VHL_BORING) { ip->ip_sum = in_cksum_hdr(ip); Index: netinet/udp_usrreq.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/udp_usrreq.c,v retrieving revision 1.64.2.3 diff -u -p -r1.64.2.3 udp_usrreq.c --- netinet/udp_usrreq.c 2000/08/03 00:09:36 1.64.2.3 +++ netinet/udp_usrreq.c 2000/09/08 14:18:15 @@ -353,15 +353,15 @@ udp_input(m, off, proto) udpstat.udps_noportbcast++; goto bad; } - *ip = save_ip; #ifdef ICMP_BANDLIM if (badport_bandlim(0) < 0) goto bad; #endif - if (!blackhole) - icmp_error(m, ICMP_UNREACH, ICMP_UNREACH_PORT, 0, 0); - else + if (blackhole) goto bad; + *ip = save_ip; + ip->ip_len += iphlen; + icmp_error(m, ICMP_UNREACH, ICMP_UNREACH_PORT, 0, 0); return; } #ifdef IPSEC Index: netinet6/ah_input.c =================================================================== RCS file: /home/ncvs/src/sys/netinet6/ah_input.c,v retrieving revision 1.1.2.1 diff -u -p -r1.1.2.1 ah_input.c --- netinet6/ah_input.c 2000/07/15 07:14:32 1.1.2.1 +++ netinet6/ah_input.c 2000/09/08 14:18:15 @@ -291,7 +291,6 @@ ah4_input(m, va_alist) * convert them back to network endian. VERY stupid. */ ip->ip_len = htons(ip->ip_len + hlen); - ip->ip_id = htons(ip->ip_id); ip->ip_off = htons(ip->ip_off); #endif if (ah4_calccksum(m, (caddr_t)cksum, siz1, algo, sav)) { @@ -305,7 +304,6 @@ ah4_input(m, va_alist) * flip them back. */ ip->ip_len = ntohs(ip->ip_len) - hlen; - ip->ip_id = ntohs(ip->ip_id); ip->ip_off = ntohs(ip->ip_off); #endif } --OXfL5xGRrasGEqWY-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Sep 8 8: 8:19 2000 Delivered-To: freebsd-net@freebsd.org Received: from smtp10.atl.mindspring.net (smtp10.atl.mindspring.net [207.69.200.246]) by hub.freebsd.org (Postfix) with ESMTP id 39C7B37B43E; Fri, 8 Sep 2000 08:08:15 -0700 (PDT) Received: from vtpr5 (user-33qticd.dialup.mindspring.com [199.174.201.141]) by smtp10.atl.mindspring.net (8.9.3/8.8.5) with SMTP id LAA02266; Fri, 8 Sep 2000 11:08:08 -0400 (EDT) Message-ID: <001401c019a6$a7e45b00$e40ffea9@vt.ny.us> From: "Vladimir Silyaev" To: "Michael Harnois" Cc: "Mattias Pantzare" , , References: <200009071609.SAA07463@mother.ludd.luth.se><001b01c0193c$6be3d780$e40ffea9@vt.ny.us> <86bsxzoajc.fsf@mharnois.workgroup.net> Subject: Re: vmware2 networking question Date: Fri, 8 Sep 2000 08:08:31 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hmm, strange. I'm pretty sure that I seen somewhere description about clusters on FreeBSD bridge. This is some points: - you have to set sysctl net.ether.bridge.bridge_cfg, with list of supported interfaces (a clue how to specify interfaces list you can get from state of the same sysctl after enabling bridge) - you can get futher information from /sys/net/bridge.c file - or contact Luigi Rizzo --- Vladimir ----- Original Message ----- From: Michael Harnois To: Vladimir Silyaev Cc: Mattias Pantzare ; Sent: Thursday, September 07, 2000 7:57 PM Subject: Re: vmware2 networking question > On Thu, 7 Sep 2000 19:28:04 -0700, "Vladimir Silyaev" said: > > > It's not so hard to get a bridging bettween only two ethernet > > adapters - you have just to specify so called 'bridge groups'. > > See bridge(4) for more info. > > I am using current, and that manpage has no reference to groups. > > -- > Michael D. Harnois, Redeemer Lutheran Church, Washburn, IA > mdharnois@home.com aa0bt@aa0bt.ampr.org > CYNIC, n. A blackguard whose faulty vision sees things as they are, > not as they ought to be. -- Ambrose Bierce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Sep 8 8:13:51 2000 Delivered-To: freebsd-net@freebsd.org Received: from c1030098-a.wtrlo1.ia.home.com (c1030098-a.wtrlo1.ia.home.com [24.14.126.45]) by hub.freebsd.org (Postfix) with ESMTP id 2F82037B43F; Fri, 8 Sep 2000 08:13:46 -0700 (PDT) Received: (from mdharnois@localhost) by c1030098-a.wtrlo1.ia.home.com (8.11.0/8.11.0) id e88FDjA01153; Fri, 8 Sep 2000 10:13:45 -0500 (CDT) (envelope-from mdharnois@home.com) X-Authentication-Warning: mharnois.workgroup.net: mdharnois set sender to mdharnois@home.com using -f To: "Vladimir Silyaev" Cc: "Mattias Pantzare" , , Subject: Re: vmware2 networking question References: <200009071609.SAA07463@mother.ludd.luth.se> <001b01c0193c$6be3d780$e40ffea9@vt.ny.us> <86bsxzoajc.fsf@mharnois.workgroup.net> <001401c019a6$a7e45b00$e40ffea9@vt.ny.us> From: Michael Harnois Date: 08 Sep 2000 10:13:45 -0500 In-Reply-To: "Vladimir Silyaev"'s message of "Fri, 8 Sep 2000 08:08:31 -0700" Message-ID: <86hf7q532u.fsf@mharnois.workgroup.net> Lines: 16 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.2 (Nike) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 8 Sep 2000 08:08:31 -0700, "Vladimir Silyaev" said: > This is some points: - you have to set sysctl > net.ether.bridge.bridge_cfg, with list of supported interfaces > (a clue how to specify interfaces list you can get from state of > the same sysctl after enabling bridge) - you can get futher > information from /sys/net/bridge.c file - or contact Luigi Rizzo Yes, I figured out how to do it manually, as I mentioned several notes upstream. It still doesn't work with vmware, however. -- Michael D. Harnois, Redeemer Lutheran Church, Washburn, IA mdharnois@home.com aa0bt@aa0bt.ampr.org "It's not what we don't know that hurts us, it's what we know for certain that just ain't so." -- Mark Twain To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Sep 8 8:38:14 2000 Delivered-To: freebsd-net@freebsd.org Received: from jade.chc-chimes.com (jade.chc-chimes.com [216.28.46.6]) by hub.freebsd.org (Postfix) with ESMTP id 5E15137B42C for ; Fri, 8 Sep 2000 08:38:12 -0700 (PDT) Received: by jade.chc-chimes.com (Postfix, from userid 1001) id 731291C6E; Fri, 8 Sep 2000 11:38:11 -0400 (EDT) Date: Fri, 8 Sep 2000 11:38:11 -0400 From: Bill Fumerola To: Paul Herman Cc: Ramses Smeyers , freebsd-net@FreeBSD.ORG Subject: Re: useripacct Message-ID: <20000908113811.X33771@jade.chc-chimes.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from pherman@frenchfries.net on Fri, Sep 08, 2000 at 01:18:13PM +0200 X-Operating-System: FreeBSD 3.3-STABLE i386 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Sep 08, 2000 at 01:18:13PM +0200, Paul Herman wrote: > ipfw doesn't implement quotas, but yes you would have to have a > separate rule for each uid/gid -- agreed, not so efficient for ipfw to > do. In the near future I will be committing patches that makes adding that many rules a tad bit more workable. ${DIETY} help you now you if want to add that many ipfw rules, though. -- Bill Fumerola - Network Architect, BOFH / Chimes, Inc. billf@chimesnet.com / billf@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Sep 8 9:35: 7 2000 Delivered-To: freebsd-net@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 69EB037B43E; Fri, 8 Sep 2000 09:35:02 -0700 (PDT) Received: from whistle.com (crab.whistle.com [207.76.205.112]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id JAA79560; Fri, 8 Sep 2000 09:23:13 -0700 (PDT) Received: (from ambrisko@localhost) by whistle.com (8.9.3/8.9.1) id JAA63625; Fri, 8 Sep 2000 09:22:59 -0700 (PDT) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200009081622.JAA63625@whistle.com> Subject: Re: vmware2 networking question In-Reply-To: <86hf7q532u.fsf@mharnois.workgroup.net> from Michael Harnois at "Sep 8, 2000 10:13:45 am" To: Michael Harnois Date: Fri, 8 Sep 2000 09:22:59 -0700 (PDT) Cc: Vladimir Silyaev , Mattias Pantzare , emulation@FreeBSD.ORG, 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 Michael Harnois writes: | On Fri, 8 Sep 2000 08:08:31 -0700, "Vladimir Silyaev" said: | | > This is some points: - you have to set sysctl | > net.ether.bridge.bridge_cfg, with list of supported interfaces | > (a clue how to specify interfaces list you can get from state of | > the same sysctl after enabling bridge) - you can get futher | > information from /sys/net/bridge.c file - or contact Luigi Rizzo | | Yes, I figured out how to do it manually, as I mentioned several notes | upstream. It still doesn't work with vmware, however. BTW I ran into this problem with multiple ethernet devices. The clustering didn't work and it caused the machine to reboot etc. So I asked our resident netgraph expert if we could use netgraph to just physical wire the vmware interface to a hardware interface. He said we could but then the TCP/IP stack wouldn't see any traffic on the FreeBSD machine. I said that is exactly what I wanted. I only wanted to see vmware interface to see the traffic. Here is the script I put into /usr/local/etc/rc.d/vmware_help.sh Note that dc0 is the physical interface and vmnet0 is the vmware interface -------------------------------------------------------------- #!/bin/sh dd if=/compat/linux/dev/vmnet0 bs=1 count=0 > /dev/null kldstat -v | grep -w ng_ether -q || kldload ng_ether ifconfig dc0 up ifconfig vmnet0 up ngctl connect dc0: vmnet0: lower lower ngctl msg dc0: setautosrc 0 ngctl msg dc0: setpromisc 1 ngctl msg vmnet0: setautosrc 0 ngctl msg vmnet0: setpromisc 1 -------------------------------------------------------------- If you do this you can remove the bridge stuff from your kernel etc. I don't have bridge in my kernel and this works just fine. Infact in my test environment I have the dc0 interface connected to a router and some jail sessions running on the this same machine tied to other interfaces. When I telnet to the jail from the vmware session it goes out to the router and then the router routes it back into the interface connected to the jail. The jail does the same thing. If the TCP/IP stack was involved then the stack would have directly routed the traffic back into the jail without going through the external router. Also we did not configure any IP address on either dc0 or vmnet0. This is on 4.1-stable, here are my dev entries: m25% ls -l /compat/linux/dev/vmnet* crw-rw-rw- 1 root wheel 149, 0x00010000 Aug 25 15:51 /compat/linux/dev/vmnet0 crw-rw-rw- 1 root wheel 149, 0x00010001 Aug 24 08:47 /compat/linux/dev/vmnet1 m25% Also I haven't had to deal with reboots etc. This may not met everyones needs but it works great for me. There is work under way for a real netgraph bridging node so it could also plug into the hosts TCP/IP stack etc. Doug A. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Sep 8 10:49:48 2000 Delivered-To: freebsd-net@freebsd.org Received: from urban.iinet.net.au (urban.iinet.net.au [203.59.24.231]) by hub.freebsd.org (Postfix) with ESMTP id AD89437B422 for ; Fri, 8 Sep 2000 10:49:43 -0700 (PDT) Received: from jules.elischer.org (reggae-34-156.nv.iinet.net.au [203.59.167.156]) by urban.iinet.net.au (8.8.7/8.8.7) with SMTP id BAA10570; Sat, 9 Sep 2000 01:48:33 +0800 Message-ID: <39B9266B.41C67EA6@elischer.org> Date: Fri, 08 Sep 2000 10:48:27 -0700 From: Julian Elischer X-Mailer: Mozilla 3.04Gold (X11; I; FreeBSD 5.0-CURRENT i386) MIME-Version: 1.0 To: Luigi Rizzo Cc: Paul Herman , Ramses Smeyers , freebsd-net@FreeBSD.ORG Subject: Re: useripacct References: <200009081126.NAA33256@info.iet.unipi.it> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Luigi Rizzo wrote: > > > ipfw doesn't implement quotas, but yes you would have to have a > > separate rule for each uid/gid -- agreed, not so efficient for ipfw to > > do. > > Not really. > There are several pieces now in ipfw/dummynet which can generate > rules and pipes from a template, (see the keep-state rules and the > "mask" specifier in dummynet pipes), so the implementation of > per-uid quotas would be efficient and rather trivial (basically a > small modification to dynamic pipes where you just check the quota). > > > Other than that, I can imagine an optional external daemon similar to > > natd(8) which enforces network quotas via a "divert" ipfw rule. > > killing performance in the meantime... write a netgraph module to do it.. > > cheers > luigi > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ presently in: Perth v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Sep 8 12:18:35 2000 Delivered-To: freebsd-net@freebsd.org Received: from gw.nectar.com (gw.nectar.com [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id C346D37B424 for ; Fri, 8 Sep 2000 12:18:32 -0700 (PDT) Received: by gw.nectar.com (Postfix, from userid 1001) id 564BB1925A; Fri, 8 Sep 2000 14:18:31 -0500 (CDT) Date: Fri, 8 Sep 2000 14:18:31 -0500 From: "Jacques A. Vidrine" To: freebsd-net@freebsd.org Subject: aironet help Message-ID: <20000908141831.A1202@spawn.nectar.com> Mail-Followup-To: "Jacques A. Vidrine" , freebsd-net@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i X-Url: http://www.nectar.com/ Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi all, I just got a Cisco Aironet PC Card and a PCI card, and slapped'em into a couple of machines here running 4.1-STABLE, ifconfig'd them, and tried to get'em talking. However, I'm having trouble on one of the machines (the one with the PCI card): I can't use the interface to send packets (no route to host). Machine spawn: an0: port 0xef00-0xef3f,0xec00-0xec7f mem 0xfebfdf80-0xfebfdfff irq 9 at device 20.0 on pci0 an0: Ethernet address: 00:40:96:33:a3:e7 an0: flags=8843 mtu 1500 inet6 fe80::240:96ff:fe33:a3e7%an0 prefixlen 64 scopeid 0x3 inet 10.0.2.1 netmask 0xffffff00 broadcast 10.0.2.255 inet6 fec0:2::240:96ff:fe33:a3e7 prefixlen 64 ether 00:40:96:33:a3:e7 Machine ophelia: an0: at port 0x240-0x27f irq 3 slot 0 on pccard0 an0: Ethernet address: 00:40:96:31:e6:3c an0: flags=8843 mtu 1500 inet 10.0.2.2 netmask 0xffffff00 broadcast 10.0.2.255 inet6 fe80::240:96ff:fe31:e63c%an0 prefixlen 64 scopeid 0x4 ether 00:40:96:31:e6:3c Now for some reason, I get `No route to host' on machine spawn: spawn% ping -c 1 -q 10.0.2.1 # ping myself PING 10.0.2.1 (10.0.2.1): 56 data bytes --- 10.0.2.1 ping statistics --- 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.127/0.127/0.127/0.000 ms spawn% ping -c 1 -q 10.0.2.2 # ping ophelia PING 10.0.2.2 (10.0.2.2): 56 data bytes ping: sendto: No route to host ^C spawn% ping -c 1 -q 10.0.2.255 # ping broadcast? PING 10.0.2.255 (10.0.2.255): 56 data bytes ping: sendto: No route to host ^C Oddly enough, on machine ophelia I have no such trouble: ophelia% ping -c 3 -q 10.0.2.1 # ping spawn PING 10.0.2.1 (10.0.2.1): 56 data bytes --- 10.0.2.1 ping statistics --- 3 packets transmitted, 0 packets received, 100% packet loss And I can even see the packets coming in on machine spawn! spawn% tcpdump -n -i an0 tcpdump: listening on an0 14:12:27.479190 10.0.2.2 > 10.0.2.1: icmp: echo request 14:12:28.483487 10.0.2.2 > 10.0.2.1: icmp: echo request 14:12:29.493505 10.0.2.2 > 10.0.2.1: icmp: echo request What could have gone wrong? The routing table looks right to me: spawn% netstat -rn | grep ^10.0.2 10.0.2/24 link#3 UC 0 0 an0 => 10.0.2.1 0:40:96:33:a3:e7 UHLW 0 10 lo0 10.0.2.2 link#3 UHLW 0 1 an0 => 10.0.2.255 ff:ff:ff:ff:ff:ff UHLWb 0 5 an0 Manually adding to the arp table doesn't change the symptoms. Does someone have a clue I could borrow? :-) -- Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Sep 8 14:25:28 2000 Delivered-To: freebsd-net@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 770EE37B505; Fri, 8 Sep 2000 14:23:23 -0700 (PDT) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e88LNNN14130; Fri, 8 Sep 2000 14:23:23 -0700 (PDT) Date: Fri, 8 Sep 2000 14:23:23 -0700 From: Alfred Perlstein To: wollman@freebsd.org Cc: net@freebsd.org Subject: Your comment re so_gencnt Message-ID: <20000908142322.I12231@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org this is from uipc_socket.c: if (so) { /* XXX race condition for reentrant kernel */ bzero(so, sizeof *so); so->so_gencnt = ++so_gencnt; so->so_zone = socket_zone; TAILQ_INIT(&so->so_aiojobq); } Is the race condition on the ++so_gencnt? I'm not sure I follow what's wrong here, so_gencnt doesn't seem to be used anywhere but during allocation and freeing of sockets (and when copied to xsockets) I think the only fix it needs is an atomic_inc of the so_gencnt, correct? Can you explain? -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Sep 8 15:34:18 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 1654237B423; Fri, 8 Sep 2000 15:34:16 -0700 (PDT) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id SAA56346; Fri, 8 Sep 2000 18:34:08 -0400 (EDT) (envelope-from wollman) Date: Fri, 8 Sep 2000 18:34:08 -0400 (EDT) From: Garrett Wollman Message-Id: <200009082234.SAA56346@khavrinen.lcs.mit.edu> To: Alfred Perlstein Cc: wollman@freebsd.org, net@freebsd.org Subject: Your comment re so_gencnt In-Reply-To: <20000908142322.I12231@fw.wintelcom.net> References: <20000908142322.I12231@fw.wintelcom.net> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > /* XXX race condition for reentrant kernel */ > bzero(so, sizeof *so); > so->so_gencnt = ++so_gencnt; > Is the race condition on the ++so_gencnt? No, the race condition is between the bzero (which might set so->so_gencnt to a currently-valid value) and the assignment to so->so_gencnt. Statistically speaking, it's a fairly unlikely race, but the correct thing to do would be to zero everything *but* the generation count, and do the assignment before zeroing anything. I didn't want to worry about that case. (I probably should have written ``preemptible'' rather than ``reentrant'' there.) -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Sep 8 15:43:23 2000 Delivered-To: freebsd-net@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 8BCF537B422; Fri, 8 Sep 2000 15:43:20 -0700 (PDT) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e88MhK016543; Fri, 8 Sep 2000 15:43:20 -0700 (PDT) Date: Fri, 8 Sep 2000 15:43:20 -0700 From: Alfred Perlstein To: net@freebsd.org Cc: chat@freebsd.org Subject: threading tcp/ip is fun. Message-ID: <20000908154320.J12231@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org http://www.wintelcom.net/~bright/thrsock.diff Should refresh every two minutes as I progress through the tcp/ip code in an attempt to thread it. If you have suggestions or works in progress please let me know. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Sep 8 15:57:16 2000 Delivered-To: freebsd-net@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 555C837B50B; Fri, 8 Sep 2000 15:57:13 -0700 (PDT) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e88MvCj17036; Fri, 8 Sep 2000 15:57:12 -0700 (PDT) Date: Fri, 8 Sep 2000 15:57:12 -0700 From: Alfred Perlstein To: Garrett Wollman Cc: wollman@freebsd.org, net@freebsd.org Subject: Re: Your comment re so_gencnt Message-ID: <20000908155712.L12231@fw.wintelcom.net> References: <20000908142322.I12231@fw.wintelcom.net> <200009082234.SAA56346@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <200009082234.SAA56346@khavrinen.lcs.mit.edu>; from wollman@khavrinen.lcs.mit.edu on Fri, Sep 08, 2000 at 06:34:08PM -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Garrett Wollman [000908 15:34] wrote: > < said: > > > /* XXX race condition for reentrant kernel */ > > bzero(so, sizeof *so); > > so->so_gencnt = ++so_gencnt; > > > Is the race condition on the ++so_gencnt? > > No, the race condition is between the bzero (which might set > so->so_gencnt to a currently-valid value) and the assignment to > so->so_gencnt. Statistically speaking, it's a fairly unlikely race, > but the correct thing to do would be to zero everything *but* the > generation count, and do the assignment before zeroing anything. I > didn't want to worry about that case. (I probably should have written > ``preemptible'' rather than ``reentrant'' there.) From reading the code there doesn't seem to be a single place that reads the gencount in the socket, except the xsocket stuff. I'm tempted to remove it, am I missing something though? -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Sep 8 16:54:19 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 4615A37B424 for ; Fri, 8 Sep 2000 16:54:16 -0700 (PDT) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id TAA56853; Fri, 8 Sep 2000 19:54:14 -0400 (EDT) (envelope-from wollman) Date: Fri, 8 Sep 2000 19:54:14 -0400 (EDT) From: Garrett Wollman Message-Id: <200009082354.TAA56853@khavrinen.lcs.mit.edu> To: Alfred Perlstein Cc: net@freebsd.org Subject: Re: Your comment re so_gencnt In-Reply-To: <20000908155712.L12231@fw.wintelcom.net> References: <20000908142322.I12231@fw.wintelcom.net> <200009082234.SAA56346@khavrinen.lcs.mit.edu> <20000908155712.L12231@fw.wintelcom.net> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > I'm tempted to remove it, am I missing something though? Yes, you're missing the entire point. Read the CVS log messages, and if you still don't understand, I'll explain it to you in private. -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 Sep 8 16:56: 5 2000 Delivered-To: freebsd-net@freebsd.org Received: from Awfulhak.org (tun.AwfulHak.org [194.242.139.173]) by hub.freebsd.org (Postfix) with ESMTP id B1AE737B43F; Fri, 8 Sep 2000 16:55:55 -0700 (PDT) Received: from hak.lan.Awfulhak.org (root@hak.lan.awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.0/8.11.0) with ESMTP id e88Np8e57686; Sat, 9 Sep 2000 00:51:08 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.0/8.11.0) with ESMTP id e88Nogn57839; Sat, 9 Sep 2000 00:50:42 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200009082350.e88Nogn57839@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Wes Peters Cc: Seigo Tanimura , current@FreeBSD.org, net@FreeBSD.org, brian@Awfulhak.org Subject: Re: the ifp to a removed pcmcia ethernet card is left in struct ip_moptions and struct ifmultiaddr In-Reply-To: Message from Wes Peters of "Tue, 05 Sep 2000 00:13:50 MDT." <39B48F1E.4C193F79@softweyr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 09 Sep 2000 00:50:42 +0100 From: Brian Somers Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Seigo Tanimura wrote: > > > > I have been suffering from this problem for almost 2 months. When I > > remove a pcmcia ethernet card from my laptop PC, routed(8) announces > > updated routing information by multicast, leading to a kernel > > panic. > > Ejecting an interface configured up will do that. ifconfig the interface > `down' and then `delete' before ejecting it. Interfaces in promiscuous mode will always result in a reboot. I *usually* get away with ejecting an active card if it's not in promiscuous mode. > -- > "Where am I, and what am I doing in this handbasket?" > > Wes Peters Softweyr LLC > wes@softweyr.com http://softweyr.com/ -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Sep 8 16:57:37 2000 Delivered-To: freebsd-net@freebsd.org Received: from gw.nectar.com (gw.nectar.com [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id CDCC937B449 for ; Fri, 8 Sep 2000 16:57:34 -0700 (PDT) Received: by gw.nectar.com (Postfix, from userid 1001) id 77DF51925A; Fri, 8 Sep 2000 18:57:34 -0500 (CDT) Date: Fri, 8 Sep 2000 18:57:34 -0500 From: "Jacques A. Vidrine" To: freebsd-net@freebsd.org Subject: Re: aironet help Message-ID: <20000908185734.D1317@spawn.nectar.com> Mail-Followup-To: "Jacques A. Vidrine" , freebsd-net@freebsd.org References: <20000908141831.A1202@spawn.nectar.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20000908141831.A1202@spawn.nectar.com>; from n@nectar.com on Fri, Sep 08, 2000 at 02:18:31PM -0500 X-Url: http://www.nectar.com/ Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Sep 08, 2000 at 02:18:31PM -0500, Jacques A. Vidrine wrote: > Hi all, > > I just got a Cisco Aironet PC Card and a PCI card, and slapped'em into a > couple of machines here running 4.1-STABLE, ifconfig'd them, and tried to > get'em talking. However, I'm having trouble on one of the machines (the > one with the PCI card): I can't use the interface to send packets (no > route to host). [snip] [This is just for the benefit of the archives] I actually had two problems: 1. Some (l)user forgot to configure IPFILTER for the new an0 interface. OK, it was me. This is what caused the `No route to host' error messages. 2. Doug Ambrisko was kind enough to point out that there is currently a bug in the driver such that if you put the card in promiscuous mode, it may wedge and no longer transmit packets. I used tcpdump, of course, during my debugging, which tickled this bug. -- Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Sep 8 22:39:53 2000 Delivered-To: freebsd-net@freebsd.org Received: from mail.m.iinet.net.au (opera3.iinet.net.au [203.59.24.51]) by hub.freebsd.org (Postfix) with SMTP id D9B8437B50D for ; Fri, 8 Sep 2000 22:39:48 -0700 (PDT) Received: (qmail 2497 invoked by uid 666); 9 Sep 2000 05:35:20 -0000 Received: from reggae-20-230.nv.iinet.net.au (HELO jules.elischer.org) (203.59.85.230) by mail.m.iinet.net.au with SMTP; 9 Sep 2000 05:35:20 -0000 Message-ID: <39B9CC11.41C67EA6@elischer.org> Date: Fri, 08 Sep 2000 22:35:13 -0700 From: Julian Elischer X-Mailer: Mozilla 3.04Gold (X11; I; FreeBSD 5.0-CURRENT i386) MIME-Version: 1.0 To: Alfred Perlstein Cc: net@freebsd.org, chat@freebsd.org Subject: Re: threading tcp/ip is fun. References: <20000908154320.J12231@fw.wintelcom.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Alfred Perlstein wrote: > > http://www.wintelcom.net/~bright/thrsock.diff > > Should refresh every two minutes as I progress through the tcp/ip > code in an attempt to thread it. > > If you have suggestions or works in progress please let me know. There is a lot of use of "atomic_ad_long()" nearly always with an increment of '1'. Would there be any advantage of having an "atomic_increment_long()"? (a_incl()) with the introduction of heavier weight operations at low level (e.g."atomic_add_long(a , 1);" vs "a += 1;" the optimal way if unrolling loops and threading decision trees may change.. e.g. if (XXX) a_incl(a); if (YYY) a_incl(b); if (ZZZ) a_incl(c); might be slower than: small_lock() if (XXX)a+=1; if (YYY)b+=1; if (ZZZ)c+=1; drop_small_lock(); (in this case not likely, but it's something to keep in mind I guess.) > > -- > -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] > "I have the heart of a child; I keep it in a jar on my desk." > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ presently in: Perth v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Sep 9 0:33:17 2000 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 347DF37B422 for ; Sat, 9 Sep 2000 00:33:14 -0700 (PDT) Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id E65D46E2BB9 for ; Sat, 9 Sep 2000 00:26:08 -0700 (PDT) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e897IYF00261; Sat, 9 Sep 2000 00:18:34 -0700 (PDT) Date: Sat, 9 Sep 2000 00:18:34 -0700 From: Alfred Perlstein To: Julian Elischer Cc: net@freebsd.org Subject: Re: threading tcp/ip is fun. Message-ID: <20000909001833.M12231@fw.wintelcom.net> References: <20000908154320.J12231@fw.wintelcom.net> <39B9CC11.41C67EA6@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <39B9CC11.41C67EA6@elischer.org>; from julian@elischer.org on Fri, Sep 08, 2000 at 10:35:13PM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Julian Elischer [000908 22:35] wrote: > Alfred Perlstein wrote: > > > > http://www.wintelcom.net/~bright/thrsock.diff > > > > Should refresh every two minutes as I progress through the tcp/ip > > code in an attempt to thread it. > > > > If you have suggestions or works in progress please let me know. > > > There is a lot of use of "atomic_ad_long()" > nearly always with an increment of '1'. > Would there be any advantage of having an > "atomic_increment_long()"? > (a_incl()) > > with the introduction of heavier weight operations at low level > (e.g."atomic_add_long(a , 1);" vs "a += 1;" > the optimal way if unrolling loops and threading decision > trees may change.. > > e.g. > > if (XXX) > a_incl(a); > if (YYY) > a_incl(b); > if (ZZZ) > a_incl(c); > > might be slower than: > small_lock() > if (XXX)a+=1; > if (YYY)b+=1; > if (ZZZ)c+=1; > drop_small_lock(); > > (in this case not likely, but it's something to keep in mind I guess.) Actually it's very good idea, however, right now I'm just trying to get it SMP safe, at a later date we may want to keep CPU private counters and in one operation update the tcpstat struct on exit from the routine. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Sep 9 9:17:29 2000 Delivered-To: freebsd-net@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 2245B37B423; Sat, 9 Sep 2000 09:17:26 -0700 (PDT) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id MAA68157; Sat, 9 Sep 2000 12:16:39 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Sat, 9 Sep 2000 12:16:39 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Brian Somers Cc: Wes Peters , Seigo Tanimura , current@FreeBSD.org, net@FreeBSD.org Subject: Re: the ifp to a removed pcmcia ethernet card is left in struct ip_moptions and struct ifmultiaddr In-Reply-To: <200009082350.e88Nogn57839@hak.lan.Awfulhak.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 Sat, 9 Sep 2000, Brian Somers wrote: > > Seigo Tanimura wrote: > > > > > > I have been suffering from this problem for almost 2 months. When I > > > remove a pcmcia ethernet card from my laptop PC, routed(8) announces > > > updated routing information by multicast, leading to a kernel > > > panic. > > > > Ejecting an interface configured up will do that. ifconfig the interface > > `down' and then `delete' before ejecting it. > > Interfaces in promiscuous mode will always result in a reboot. I > *usually* get away with ejecting an active card if it's not in > promiscuous mode. A while back I committed patches to use bpf_detach(), which elminated the struct ifnet pointer in the bpf described at detach time. This removed most of the panics I experience on ejecting pccards. This should be in 5.0-CURRENT and 4.1-STABLE. If you're still experiencing panics, we should track it down some more as presumably there is another reference (it could also be a race condition, or in-use mbuf during detach?) Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Sep 9 12:41:38 2000 Delivered-To: freebsd-net@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id 33E8837B43F; Sat, 9 Sep 2000 12:41:24 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 13WTsX-0003I6-00; Tue, 05 Sep 2000 19:19:53 -0600 Message-ID: <39B59BB9.22C4BDFE@softweyr.com> Date: Tue, 05 Sep 2000 19:19:53 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; FreeBSD 4.1-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: Seigo Tanimura Cc: current@freebsd.org, net@freebsd.org Subject: Re: the ifp to a removed pcmcia ethernet card is left in struct ip_moptions and struct ifmultiaddr References: <14772.34738.630468.85559N@rina> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Seigo Tanimura wrote: > > In ip_output(), imo->imo_multicast_ifp points to the removed > interface, which is passed to IN_LOOKUP_MULTI() to cause a panic. This > problem also occurs when we attempt to delete a multicast address from > a removed interface. if_delmulti() derefers an ifp to the removed > interface, ending up with a panic. The problem does not occur for > unicast. > > http://people.FreeBSD.org/~tanimura/patches/mcastif.diff.gz is a > workround patch. The idea is to track all of the active ifps, confirm > an ifp to be active prior to dereferencing it, and free orphaned > ifmultiaddrs attached to a removed ifp. It would be much more elegant > if we could clean up the multicast information related to a removed > interface, though. Warner Losh pointed out to me: > Tanimura-san did contribute patches. This problem isn't a race at the > eject, but rather the network layer incompletely cleaning up after a > device has gone away. This is, of course, exactly the problem you're looking at. There are several of these cached ifp's hanging around, all causing problems. Robert Watson and I had a nice discussion about how to approach that problem a while back. I've since gotten busy and forgotten about it, as has he (apparently). The quick (-ish) fix I came up with is to double all those cache ifp's all over the code, and always check the first pointer for a null reference before diving off through it. The disadvantage is the check and dereference on every access, the advantage is being able to nullify one pointer in the interface take-down and automagically have all the cached references die. You would leak a single pointer for every interface detach, unless you did reference counting or something like that. The full solution would be to implement ifs a full objects, and to always check the state of the interface before trying to exercise an associated function. It's an ugly problem with no real simple solutions (in C). -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Sep 9 12:41:49 2000 Delivered-To: freebsd-net@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id 806C937B506; Sat, 9 Sep 2000 12:41:26 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 13WS4m-0003Gf-00; Tue, 05 Sep 2000 17:24:24 -0600 Message-ID: <39B580A8.CE59B5CF@softweyr.com> Date: Tue, 05 Sep 2000 17:24:24 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; FreeBSD 4.1-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: Warner Losh Cc: Seigo Tanimura , current@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: the ifp to a removed pcmcia ethernet card is left in struct ip_moptions and struct ifmultiaddr References: <39B51375.4DE4C6FA@softweyr.com> <39B48F1E.4C193F79@softweyr.com> <14772.34738.630468.85559N@rina> <200009050609.AAA58464@harmony.village.org> <200009051535.JAA60822@harmony.village.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Warner Losh wrote: > > In message <39B51375.4DE4C6FA@softweyr.com> Wes Peters writes: > : state the code is in now, and if someone wants it to be better, we await > : their patches. As always. ;^) > > Tanimura-san did contribute patches. This problem isn't a race at the > eject, but rather the network layer incompletely cleaning up after a > device has gone away. Robert Watson and I had a nice discussion about how to approach that problem a while back. I've since gotten busy and forgotten about it, as has he (apparently). The quick (-ish) fix I came up with is to double all those cache ifp's all over the code, and always check the first pointer for a null reference before diving off through it. The disadvantage is the check and dereference on every access, the advantage is being able to nullify one pointer in the interface take-down and automagically have all the cached references die. You would leak a single pointer for every interface detach, unless you did reference counting or something like that. The full solution would be to implement reference counting in the if objects, and to always check the state of the interface before trying to exercise an associated function. It's an ugly problem with no real simple solutions (in C). -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Sep 9 19:45: 6 2000 Delivered-To: freebsd-net@freebsd.org Received: from xena.gsicomp.on.ca (strppp21.enoreo.on.ca [209.82.53.101]) by hub.freebsd.org (Postfix) with ESMTP id 96A9037B424 for ; Sat, 9 Sep 2000 19:45:02 -0700 (PDT) Received: from zircon (matt.gsicomp.on.ca [192.168.0.18]) by xena.gsicomp.on.ca (8.10.1/8.9.2) with SMTP id e8A2ipG05316; Sat, 9 Sep 2000 22:44:51 -0400 (EDT) (envelope-from matt@gsicomp.on.ca) Message-ID: <001101c01ad1$1c5feeb0$1200a8c0@zircon> From: "Matthew Emmerton" To: Cc: Subject: Suggestion for PPP Date: Sat, 9 Sep 2000 22:44:56 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi all, I've been using ppp for some time now, and have enjoyed how easily it can be configured to do all sorts of wierd and wonderful things (like PPP over SSH over TCP.) My current network setup is a cable modem (configured via DHCP) and a backup 56K analog link using PPP. My cable modem uses ipfw and natd to do firewalling and port forwarding, and I would like my PPP link to do the same. I realize that I can edit ppp.conf to add all my port forwarding rules, but would rather not since I use the -f argument to natd, and would rather not have to keep two files in sync. My proposal is to add 'nat config ' support to ppp, so that rules can be loaded from an external file. I would find this extremely beneficial, and I hope that others would too. If anyone thinks that this would be a worthwhile feature to implement, please drop me a line (I'm not on the freebsd-net list) and I will make it happen (with the ppp maintainer's blessings, of course.) -- Matthew Emmerton GSI Computer Services +1 (800) 217-5409 (Canada) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Sep 9 20:13:29 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 DDE3E37B43E for ; Sat, 9 Sep 2000 20:13:25 -0700 (PDT) Received: from whizzo.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.11.0/8.11.0) with ESMTP id e8A3DLG62901; Sat, 9 Sep 2000 23:13:21 -0400 (EDT) (envelope-from louie@whizzo.transsys.com) Message-Id: <200009100313.e8A3DLG62901@whizzo.transsys.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Alfred Perlstein Cc: Julian Elischer , net@FreeBSD.ORG X-Image-URL: http://www.transsys.com/louie/images/louie-mail.jpg From: "Louis A. Mamakos" Subject: Re: threading tcp/ip is fun. References: <20000908154320.J12231@fw.wintelcom.net> <39B9CC11.41C67EA6@elischer.org> <20000909001833.M12231@fw.wintelcom.net> In-reply-to: Your message of "Sat, 09 Sep 2000 00:18:34 PDT." <20000909001833.M12231@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 09 Sep 2000 23:13:21 -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > e.g. > > > > if (XXX) > > a_incl(a); > > if (YYY) > > a_incl(b); > > if (ZZZ) > > a_incl(c); > > > > might be slower than: > > small_lock() > > if (XXX)a+=1; > > if (YYY)b+=1; > > if (ZZZ)c+=1; > > drop_small_lock(); > > > > (in this case not likely, but it's something to keep in mind I guess.) > > Actually it's very good idea, however, right now I'm just trying > to get it SMP safe, at a later date we may want to keep CPU private > counters and in one operation update the tcpstat struct on exit > from the routine. Many moons ago, Van Jacobson did some optimizations to the TCP protocol implementation such that the code path for the "normal" TCP segement (e.g., connection already open, segment that arrives is at the left window edge, etc.) was very, very short. It would seem that locking the TCP per-connection state as a whole is probably sufficient given the short duration that the lock is likely to be held for. I don't think it makes sense to lock the individual operations since the goal is to keep the whole data structure consistant, and not just worrying about any single element. I don't see how you can convince yourself that the Right Thing happens unless you arbitrate access to the connection state as a whole. louie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Sep 9 23: 8:38 2000 Delivered-To: freebsd-net@freebsd.org Received: from field.videotron.net (field.videotron.net [205.151.222.108]) by hub.freebsd.org (Postfix) with ESMTP id 5FC8137B423; Sat, 9 Sep 2000 23:08:30 -0700 (PDT) Received: from modemcable136.203-201-24.mtl.mc.videotron.net ([24.201.203.136]) by field.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0G0N00G0AQE40V@field.videotron.net>; Sun, 10 Sep 2000 02:08:28 -0400 (EDT) Date: Sun, 10 Sep 2000 02:11:52 -0400 (EDT) From: Bosko Milekic Subject: mbuf system with mutexes X-Sender: bmilekic@jehovah.technokratis.com To: current@freebsd.org Cc: net@freebsd.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 For those interested, I have a preliminary patch that will add mutex locking in the mbuf subsystem and get rid of the splimp()s. It also fixes some race conditions previously existing and in relation to tsleep() (i.e. the wait routines). The patch is rough and early, but watch the same space for updates (soon), and please, if you have an SMP machine, give it a whirl (because I don't!). http://www.technokratis.com/code/mbuf/mbuf_mtx.patch Please note that this will only work for i386 for now. I have yet to clean up the initialization code such that it will run decently and as advertised. :-) Also, I plan to tackle as follows, and not necessarily in order: (roughly) a* sendfile(2) stuff SMP-izing b* cleanup mbuf_mtx, fix and tweak c* make sure m_reclaim is okay d* test for exhaustion e* test on real SMP machine f* make sure callers don't hold mutexes when calling with M_WAIT g* make sure the kmem_malloc() stuff has Giant h* atomic (real atomic) manipulation of mbstat * etc... Suggestions, as usual, are always welcome. Please don't consider anything in the above code final, it's the first and very early version. Finally, I'm trying to do this as closly as possible with Alfred's work, so Alfred, maybe you can also glance at point (f) above as well... :-) Cheers, Bosko Milekic bmilekic@technokratis.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message