From owner-freebsd-net Sun Oct 20 11:30:23 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DEB6637B401 for <freebsd-net@FreeBSD.ORG>; Sun, 20 Oct 2002 11:30:18 -0700 (PDT) Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8D12F43E9C for <freebsd-net@FreeBSD.ORG>; Sun, 20 Oct 2002 11:30:17 -0700 (PDT) (envelope-from archie@dellroad.org) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id LAA30861; Sun, 20 Oct 2002 11:18:39 -0700 (PDT) Received: from arch20m.dellroad.org (localhost [127.0.0.1]) by arch20m.dellroad.org (8.12.6/8.12.6) with ESMTP id g9KIIdON048200; Sun, 20 Oct 2002 11:18:39 -0700 (PDT) (envelope-from archie@arch20m.dellroad.org) Received: (from archie@localhost) by arch20m.dellroad.org (8.12.6/8.12.6/Submit) id g9KIIdqF048199; Sun, 20 Oct 2002 11:18:39 -0700 (PDT) From: Archie Cobbs <archie@dellroad.org> Message-Id: <200210201818.g9KIIdqF048199@arch20m.dellroad.org> Subject: Re: For those who had problems with MPD server and win clients In-Reply-To: <20021018132732.GA27692@otdel1.org> "from Nikolai Saoukh at Oct 18, 2002 05:27:32 pm" To: Nikolai Saoukh <bsd#nms@otdel-1.org> Date: Sun, 20 Oct 2002 11:18:39 -0700 (PDT) Cc: freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org Nikolai Saoukh writes: > IMHO, there is a combination of two bugs. > > 1) MPD (3.9, at least) calculates and sets mtu (bund.c/BundUpdateParams()) > at wrong time -- when one of MIN() args is still zero. ioctl with bizzare mtu > value rejected, thus leaving the default (1500), which in turn is above > MRU requested from win client (1400 for multilink). See my comments below... > 2) MS clients has setting 'Negotiate multi-link for single link connections'. > Even when this option is negotiated, ms client does not understand partial MP > (RFC1990) fragments. When both (begin, end) flags set, then everything is > fine, as long as everything fits MRU. If this is true, then "set bundle enable round-robin" should work around the windows problem.. can you verify this? > --- bund.c.orig Tue Oct 8 13:40:15 2002 > +++ bund.c Fri Oct 18 17:17:23 2002 > @@ -548,22 +548,20 @@ > mtu = NG_IFACE_MTU_DEFAULT; /* Reset to default settings */ > break; > case 1: > - if (!Enabled(&bund->conf.options, BUND_CONF_MULTILINK)) { > - mtu = MIN(bund->links[the_link]->lcp.peer_mru, > - bund->links[the_link]->phys->type->mtu); > - break; > - } > - /* FALLTHROUGH */ > + mtu = bund->links[the_link]->lcp.peer_mru; > + break; > default: /* We fragment everything, use bundle MRRU */ > mtu = bund->mp.peer_mrru; > break; > } It doesn't seem possible to me that "bund->links[the_link]->phys->type->mtu" could ever be zero as you claim because this is a static variable initialized at compile time. However, this code is in fact broken. As sent in private email, I think the correct fix is this: --- bund.c 17 Oct 2002 18:48:47 -0000 1.8 +++ bund.c 20 Oct 2002 18:11:00 -0000 @@ -548,7 +548,7 @@ mtu = NG_IFACE_MTU_DEFAULT; /* Reset to default settings */ break; case 1: - if (!Enabled(&bund->conf.options, BUND_CONF_MULTILINK)) { + if (!bund->multilink) { /* If no multilink, use peer MRU */ mtu = MIN(bund->links[the_link]->lcp.peer_mru, bund->links[the_link]->phys->type->mtu); break; > - /* Subtract to make room for various frame-bloating protocols */ > - if (Enabled(&bund->conf.options, BUND_CONF_COMPRESSION)) > - mtu = CcpSubtractBloat(mtu); > - if (Enabled(&bund->conf.options, BUND_CONF_ENCRYPTION)) > - mtu = EcpSubtractBloat(mtu); > + if (bm->n_up > 0) { > + /* Subtract to make room for various frame-bloating protocols */ > + if (bund->ccp.xmit != NULL) > + mtu = CcpSubtractBloat(mtu); > + if (bund->ecp.xmit != NULL) > + mtu = EcpSubtractBloat(mtu); > + } Looks good, though I have a modified version that fixes another bug as well (we were subtracting from the MTU even if compression negotation failed). > --- iface.c.orig Tue Oct 8 14:28:09 2002 > +++ iface.c Sat Oct 12 11:54:36 2002 > @@ -346,6 +346,8 @@ > /* Sanity */ > assert(!iface->ip_up); > > + BundUpdateParams(); > + > /* Set addresses and bring interface up */ > snprintf(hisaddr, sizeof(hisaddr), "%s", inet_ntoa(iface->peer_addr)); > ExecCmd(LG_IFACE, "%s %s %s %s netmask 0xffffffff %slink0", Doesn't hurt :-) I've combined your and my changes into the combined patch below. Please apply & let me know if this fixes the problems you're seeing. Thanks, -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com Index: bund.c =================================================================== RCS file: /home/cvs/archie/mpd/src/bund.c,v retrieving revision 1.8 diff -u -r1.8 bund.c --- bund.c 17 Oct 2002 18:48:47 -0000 1.8 +++ bund.c 20 Oct 2002 18:17:28 -0000 @@ -548,7 +548,7 @@ mtu = NG_IFACE_MTU_DEFAULT; /* Reset to default settings */ break; case 1: - if (!Enabled(&bund->conf.options, BUND_CONF_MULTILINK)) { + if (!bund->multilink) { /* If no multilink, use peer MRU */ mtu = MIN(bund->links[the_link]->lcp.peer_mru, bund->links[the_link]->phys->type->mtu); break; @@ -560,10 +560,12 @@ } /* Subtract to make room for various frame-bloating protocols */ - if (Enabled(&bund->conf.options, BUND_CONF_COMPRESSION)) - mtu = CcpSubtractBloat(mtu); - if (Enabled(&bund->conf.options, BUND_CONF_ENCRYPTION)) - mtu = EcpSubtractBloat(mtu); + if (bm->n_up > 0) { + if (Enabled(&bund->conf.options, BUND_CONF_COMPRESSION)) + mtu = CcpSubtractBloat(mtu); + if (Enabled(&bund->conf.options, BUND_CONF_ENCRYPTION)) + mtu = EcpSubtractBloat(mtu); + } /* Update interface MTU */ if (mtu > BUND_MAX_MTU) Index: ccp.c =================================================================== RCS file: /home/cvs/archie/mpd/src/ccp.c,v retrieving revision 1.4 diff -u -r1.4 ccp.c --- ccp.c 17 Oct 2002 18:48:47 -0000 1.4 +++ ccp.c 20 Oct 2002 18:17:28 -0000 @@ -578,12 +578,14 @@ CcpState const ccp = &bund->ccp; /* Account for CCP's protocol number overhead */ - size -= CCP_OVERHEAD; + if (OPEN_STATE(ccp->fsm.state)) + size -= CCP_OVERHEAD; /* Account for transmit compression overhead */ - if (OPEN_STATE(ccp->fsm.state) && ccp->xmit && ccp->xmit->SubtractBloat) { + if (OPEN_STATE(ccp->fsm.state) && ccp->xmit && ccp->xmit->SubtractBloat) size = (*ccp->xmit->SubtractBloat)(size); - } + + /* Done */ return(size); } Index: ecp.c =================================================================== RCS file: /home/cvs/archie/mpd/src/ecp.c,v retrieving revision 1.4 diff -u -r1.4 ecp.c --- ecp.c 17 Oct 2002 18:48:48 -0000 1.4 +++ ecp.c 20 Oct 2002 18:17:28 -0000 @@ -583,12 +583,14 @@ EcpState const ecp = &bund->ecp; /* Account for ECP's protocol number overhead */ - size -= ECP_OVERHEAD; + if (OPEN_STATE(ecp->fsm.state)) + size -= ECP_OVERHEAD; /* Check transmit encryption */ - if (OPEN_STATE(ecp->fsm.state) && ecp->xmit && ecp->xmit->SubtractBloat) { + if (OPEN_STATE(ecp->fsm.state) && ecp->xmit && ecp->xmit->SubtractBloat) size = (*ecp->xmit->SubtractBloat)(size); - } + + /* Done */ return(size); } Index: iface.c =================================================================== RCS file: /home/cvs/archie/mpd/src/iface.c,v retrieving revision 1.4 diff -u -r1.4 iface.c --- iface.c 19 Oct 2002 18:14:26 -0000 1.4 +++ iface.c 20 Oct 2002 18:17:28 -0000 @@ -346,6 +346,9 @@ /* Sanity */ assert(!iface->ip_up); + /* For good measure */ + BundUpdateParams(); + /* Set addresses and bring interface up */ snprintf(hisaddr, sizeof(hisaddr), "%s", inet_ntoa(iface->peer_addr)); ExecCmd(LG_IFACE, "%s %s %s %s netmask 0xffffffff %slink0", To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Oct 20 14:36:28 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 59A4E37B401 for <freebsd-net@FreeBSD.ORG>; Sun, 20 Oct 2002 14:36:27 -0700 (PDT) Received: from silver.he.iki.fi (silver.he.iki.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id 13E5D43E42 for <freebsd-net@FreeBSD.ORG>; Sun, 20 Oct 2002 14:36:21 -0700 (PDT) (envelope-from pete@he.iki.fi) Received: from PHE (silver.he.iki.fi [193.64.42.241]) by silver.he.iki.fi (8.12.6/8.11.4) with SMTP id g9KLa6Yj076911; Mon, 21 Oct 2002 00:36:13 +0300 (EEST) (envelope-from pete@he.iki.fi) Message-ID: <046c01c27880$c7c727a0$3500080a@PHE> From: "Petri Helenius" <pete@he.iki.fi> To: "Don Bowman" <don@sandvine.com>, <Kevin_Stevens@pursued-with.net> Cc: <freebsd-net@FreeBSD.ORG> References: <FE045D4D9F7AED4CBFF1B3B813C8533701022CD2@mail.sandvine.com> Subject: Re: ENOBUFS Date: Mon, 21 Oct 2002 00:36:36 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org > > Clearly I will have some tuning ahead, and likely I will not succeed, > but for sure my 1U XEON with 6 gigabit nics will work very hard > for its living :) > Which NICs seem to work best here? I´ve been playing more with em and it seems that the time spent in interrupts is quite high, I´m seeing 15-17% for 300Mbps on 2.4 Xeon. This number seems to stay the same whether I´m running UP or SMP kernel with 4.7-STABLE. Does "giant" in 4.X SMP context mean that the other CPU is idling while the other is either servicing interrupts or running kernel code? What would be the best course of action to implement optimizations possible with later chips like 82546 to the em driver? Talk to Intel? Pete To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Oct 20 14:53:46 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 29EF237B401 for <freebsd-net@FreeBSD.ORG>; Sun, 20 Oct 2002 14:53:45 -0700 (PDT) Received: from mail.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 94EE743E91 for <freebsd-net@FreeBSD.ORG>; Sun, 20 Oct 2002 14:53:44 -0700 (PDT) (envelope-from don@sandvine.com) Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19) id <42S9VBZM>; Sun, 20 Oct 2002 17:53:43 -0400 Message-ID: <FE045D4D9F7AED4CBFF1B3B813C8533701022CE5@mail.sandvine.com> From: Don Bowman <don@sandvine.com> To: 'Petri Helenius ' <pete@he.iki.fi>, Don Bowman <don@sandvine.com>, "'Kevin_Stevens@pursued-with.net '" <Kevin_Stevens@pursued-with.net> Cc: "'freebsd-net@FreeBSD.ORG '" <freebsd-net@FreeBSD.ORG> Subject: RE: ENOBUFS Date: Sun, 20 Oct 2002 17:53:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org From: Petri Helenius >> >> Clearly I will have some tuning ahead, and likely I will not = succeed, >> but for sure my 1U XEON with 6 gigabit nics will work very hard >> for its living :) >> >Which NICs seem to work best here? I=B4ve been playing more with em >and it seems that the time spent in interrupts is quite high, I=B4m = seeing >15-17% for 300Mbps on 2.4 Xeon. This number seems to stay the same >whether I=B4m running UP or SMP kernel with 4.7-STABLE. > >Does "giant" in 4.X SMP context mean that the other CPU is idling = while >the other is either servicing interrupts or running kernel code? > >What would be the best course of action to implement optimizations >possible with later chips like 82546 to the em driver? Talk to Intel? Well, I'm definitely finding that I have more CPU free when using the broadcom BCM570X NIC (bge) than the Intel 8254X NIC (em). http://www.etestinglabs.com/main/reports/broadcom.asp http://www.etestinglabs.com/main/reports/3com.asp has a benchmark of the broadcom versus the intel. This is on a win2k platform. These benchmarks were paid for by broadcom,=20 so take them with a grain of salt. As for tuning the driver for either chip, you will need an NDA to get the documentation. --don (don@sandvine.com www.sandvine.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Oct 20 15:34:20 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1C22837B401 for <freebsd-net@FreeBSD.ORG>; Sun, 20 Oct 2002 15:34:19 -0700 (PDT) Received: from pop015.verizon.net (pop015pub.verizon.net [206.46.170.172]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5A0A343E42 for <freebsd-net@FreeBSD.ORG>; Sun, 20 Oct 2002 15:34:18 -0700 (PDT) (envelope-from jimmcgra@bellatlantic.net) Received: from Default ([141.154.237.113]) by pop015.verizon.net (InterMail vM.5.01.05.09 201-253-122-126-109-20020611) with ESMTP id <20021020223417.BJEE28019.pop015.verizon.net@Default>; Sun, 20 Oct 2002 17:34:17 -0500 From: "Jim McGrath" <jimmcgra@bellatlantic.net> To: "Petri Helenius" <pete@he.iki.fi>, "Don Bowman" <don@sandvine.com>, <Kevin_Stevens@pursued-with.net> Cc: <freebsd-net@FreeBSD.ORG> Subject: RE: ENOBUFS Date: Sun, 20 Oct 2002 18:34:53 -0400 Message-ID: <NDBBKKEELKBCJJBEGDECMEIGCGAA.jimmcgra@bellatlantic.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <046c01c27880$c7c727a0$3500080a@PHE> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-Authentication-Info: Submitted using SMTP AUTH LOGIN at pop015.verizon.net from [141.154.237.113] at Sun, 20 Oct 2002 17:34:17 -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org You really need Intel documentation. The Receive Interrupt Delay Value helped a lot, but in the case of the 82544, caused chip lockup under very high load. It has been a while, but the optimal value in my implementation was 22 ticks. The on chip cache is skewed in favor of receive processing, something like 70/30. In a pass through application, setting it to 50/50 helps. I'm speaking from 82543/82544 experience. Things may have changed since then. Jim > What would be the best course of action to implement optimizations > possible with later chips like 82546 to the em driver? Talk to Intel? > > Pete > > > > 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 Oct 20 15:40:19 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A42B137B401 for <freebsd-net@FreeBSD.ORG>; Sun, 20 Oct 2002 15:40:18 -0700 (PDT) Received: from silver.he.iki.fi (silver.he.iki.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9172243E97 for <freebsd-net@FreeBSD.ORG>; Sun, 20 Oct 2002 15:40:17 -0700 (PDT) (envelope-from pete@he.iki.fi) Received: from PHE (silver.he.iki.fi [193.64.42.241]) by silver.he.iki.fi (8.12.6/8.11.4) with SMTP id g9KMeBYj077363; Mon, 21 Oct 2002 01:40:16 +0300 (EEST) (envelope-from pete@he.iki.fi) Message-ID: <049601c27889$ba8b01c0$3500080a@PHE> From: "Petri Helenius" <pete@he.iki.fi> To: "Don Bowman" <don@sandvine.com>, <Kevin_Stevens@pursued-with.net> Cc: <freebsd-net@FreeBSD.ORG> References: <FE045D4D9F7AED4CBFF1B3B813C8533701022CE5@mail.sandvine.com> Subject: Re: ENOBUFS Date: Mon, 21 Oct 2002 01:40:41 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org >Well, I'm definitely finding that I have more CPU free when using >the broadcom BCM570X NIC (bge) than the Intel 8254X NIC (em). What kind of difference are we talking about here? One third or less? >http://www.etestinglabs.com/main/reports/broadcom.asp >http://www.etestinglabs.com/main/reports/3com.asp >has a benchmark of the broadcom versus the intel. This is on >a win2k platform. These benchmarks were paid for by broadcom, >so take them with a grain of salt. I think I´ll put a 3com card onto the PCI-X slot on the same chassis and do some comparisons on the same exact hardware, traffic and kernel configuration. However, if I understand correctly, PCI-X would allow optimizations that are not present on the em driver? Pete To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Oct 20 16: 8:40 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BD45437B401 for <freebsd-net@FreeBSD.ORG>; Sun, 20 Oct 2002 16:08:39 -0700 (PDT) Received: from mail.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3CB5343E91 for <freebsd-net@FreeBSD.ORG>; Sun, 20 Oct 2002 16:08:39 -0700 (PDT) (envelope-from don@sandvine.com) Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19) id <42S9VB5R>; Sun, 20 Oct 2002 19:08:38 -0400 Message-ID: <FE045D4D9F7AED4CBFF1B3B813C8533701022CE6@mail.sandvine.com> From: Don Bowman <don@sandvine.com> To: 'Petri Helenius ' <pete@he.iki.fi> Cc: "'freebsd-net@FreeBSD.ORG '" <freebsd-net@FreeBSD.ORG> Subject: RE: ENOBUFS Date: Sun, 20 Oct 2002 19:08:38 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org From: Petri Helenius >>Well, I'm definitely finding that I have more CPU free when using >>the broadcom BCM570X NIC (bge) than the Intel 8254X NIC (em). >What kind of difference are we talking about here? One third or less? ... The idle time in a bridging application remains more or less constant for the bge, regardless of load. This stayed at around 9% of my CPU. For the em, the idle time decreased as I increased the load, to end up using about double the CPU for the same load. I will post results when I have them done. >I think I=B4ll put a 3com card onto the PCI-X slot on the same chassis >and do some comparisons on the same exact hardware, traffic and kernel >configuration. > >However, if I understand correctly, PCI-X would allow optimizations >that are not present on the em driver? I'm not sure what these optimisations would be other than clock rate which the driver doesn't care about. Watch that your GE cards use a 64-bit bus, and stay at at least 66MHz. For PCI-X, a single device can run @ 133, 2 @ 100, more than 2 @ 66MHz. In the supermicro servers I have, one of the 2 slots is better than the other since its only used by the expansion. --don (don@sandvine.com www.sandvine.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Oct 20 22:19:58 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5D3F037B401 for <freebsd-net@FreeBSD.ORG>; Sun, 20 Oct 2002 22:19:57 -0700 (PDT) Received: from chung.yikes.com (dsl-65-184-72-125.telocity.com [65.184.72.125]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9A00143E6A for <freebsd-net@FreeBSD.ORG>; Sun, 20 Oct 2002 22:19:56 -0700 (PDT) (envelope-from leonardc@cs.berkeley.edu) Received: from feather ([10.0.1.250]) by chung.yikes.com (8.12.6/8.11.6) with SMTP id g9L5JnGX013361; Sun, 20 Oct 2002 22:19:50 -0700 (PDT) (envelope-from leonardc@cs.berkeley.edu) From: "Leonard Chung" <leonardc@cs.berkeley.edu> To: "Archie Cobbs" <archie@dellroad.org> Cc: <freebsd-net@FreeBSD.ORG> Subject: RE: MPD PPTP tunneling intermittantly fails Date: Sun, 20 Oct 2002 22:19:46 -0700 Message-ID: <AEEMJFAIHDPJNCAKCHHBMELLCHAA.leonardc@cs.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <200210170001.g9H01xOU008365@arch20m.dellroad.org> Importance: Normal Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org Well, I did you one better and upgraded the system to 4.7-REL. Some additional info: from looking at an ethereal trace, I'm seeing source quenches coming back to the machine VPN'ing in. Interestingly, ethereal also reports an invalid checksum on a bunch of those packets. The strange thing is, this machine has acted as a router/NAT for quite a while and so of all the machines on the network, it's hardware is probably the most stable (easily 150+ day uptimes). Any ideas? Thanks for your help so far, Leonard -----Original Message----- From: Archie Cobbs [mailto:archie@dellroad.org] Sent: Wednesday, October 16, 2002 5:02 PM To: Leonard Chung Cc: freebsd-net@FreeBSD.ORG Subject: Re: MPD PPTP tunneling intermittantly fails Leonard Chung writes: > I'm just using Windows clients, so there are no OS X clients. > > Here's the ngctl output: > > chung# ngctl msg ng0:inet.ppp.link0 getstats > Rec'd response "getstats" (3) from "ng0:inet.ppp.link0": > Args: { xmitPackets=1967 xmitOctets=209321 xmitLoneAcks=395 xmitDrops=345 > recvPackets=1590 recvOctets=248518 recvAckTimeouts=55 } That doesn't look so good. But it doesn't look "crazy" from the netgraph side, just like a lot of packets are being dropped. There must be something specific about your setup that causes this. You're using 4.6.2? Try applying all of the patches in sys/netgraph that are in 4.7-REL that you don't have in 4.6.2... ? -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Oct 20 22:48: 1 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 38E2A37B404 for <freebsd-net@FreeBSD.org>; Sun, 20 Oct 2002 22:48:00 -0700 (PDT) Received: from web14603.mail.yahoo.com (web14603.mail.yahoo.com [216.136.224.83]) by mx1.FreeBSD.org (Postfix) with SMTP id D133F43E6E for <freebsd-net@FreeBSD.org>; Sun, 20 Oct 2002 22:47:59 -0700 (PDT) (envelope-from shubha_mr@yahoo.com) Message-ID: <20021021054759.83379.qmail@web14603.mail.yahoo.com> Received: from [12.151.32.25] by web14603.mail.yahoo.com via HTTP; Mon, 21 Oct 2002 06:47:59 BST Date: Mon, 21 Oct 2002 06:47:59 +0100 (BST) From: =?iso-8859-1?q?shubha=20mr?= <shubha_mr@yahoo.com> Subject: system startup To: freebsd-net@FreeBSD.org Cc: freebsd-questions@FreeBSD.ORG MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org Hi, Where can I find documentation on how various devices are identified and drivers loaded accordingly during system startup and how exactly kldload /kldunload works. Thanks, shubha __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Oct 20 23:26:18 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 098E637B401 for <freebsd-net@FreeBSD.ORG>; Sun, 20 Oct 2002 23:26:17 -0700 (PDT) Received: from silver.he.iki.fi (silver.he.iki.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id B53F243E77 for <freebsd-net@FreeBSD.ORG>; Sun, 20 Oct 2002 23:26:15 -0700 (PDT) (envelope-from pete@he.iki.fi) Received: from PHE (silver.he.iki.fi [193.64.42.241]) by silver.he.iki.fi (8.12.6/8.11.4) with SMTP id g9L6QBYj080410; Mon, 21 Oct 2002 09:26:13 +0300 (EEST) (envelope-from pete@he.iki.fi) Message-ID: <04da01c278ca$d29a9c30$3500080a@PHE> From: "Petri Helenius" <pete@he.iki.fi> To: "Don Bowman" <don@sandvine.com> Cc: <freebsd-net@FreeBSD.ORG> References: <FE045D4D9F7AED4CBFF1B3B813C8533701022CE6@mail.sandvine.com> Subject: Re: ENOBUFS Date: Mon, 21 Oct 2002 09:26:41 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org >The idle time in a bridging application remains more or less >constant for the bge, regardless of load. This stayed at around >9% of my CPU. For the em, the idle time decreased as I increased >the load, to end up using about double the CPU for the same load. >I will post results when I have them done. That would be great, thanks. >>However, if I understand correctly, PCI-X would allow optimizations >>that are not present on the em driver? >I'm not sure what these optimisations would be other than clock >rate which the driver doesn't care about. I understood that there are ways to put more stuff onto a single transfer. I´m not a PCI expert so I might be just making up things here. >Watch that your GE cards use a 64-bit bus, and stay at at least >66MHz. For PCI-X, a single device can run @ 133, 2 @ 100, more than >2 @ 66MHz. In the supermicro servers I have, one of the 2 slots >is better than the other since its only used by the expansion. Yes, I already got burned using the slot on the same bus than the em´s for 33MHz card. Now the chips should be running 100/64 but I have yet to figure out a way to verify this on a running OS. I have the 1U servers so that´s why I´m more biased towards the em, due to the fact that they come on the motherboard. Pete To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 21 1:33:26 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A9BCE37B401 for <freebsd-net@freebsd.org>; Mon, 21 Oct 2002 01:33:25 -0700 (PDT) Received: from gvr.gvr.org (gvr.gvr.org [212.61.40.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD18343E65 for <freebsd-net@freebsd.org>; Mon, 21 Oct 2002 01:33:24 -0700 (PDT) (envelope-from guido@gvr.org) Received: by gvr.gvr.org (Postfix, from userid 657) id 81EE897; Mon, 21 Oct 2002 10:33:23 +0200 (CEST) Date: Mon, 21 Oct 2002 10:33:23 +0200 From: Guido van Rooij <guido@gvr.org> To: Lars Eggert <larse@ISI.EDU> Cc: Charles Henrich <henrich@sigbus.com>, freebsd-net@freebsd.org Subject: Re: IPSEC/NAT issues Message-ID: <20021021083323.GA27359@gvr.gvr.org> References: <20021017162243.B89519@sigbus.com> <3DAF509C.6030002@isi.edu> <20021017172905.A91625@sigbus.com> <3DAF5C21.6000108@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DAF5C21.6000108@isi.edu> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org On Thu, Oct 17, 2002 at 05:56:01PM -0700, Lars Eggert wrote: > > Your packets don't seem to reach natd after IPsec inbound processing. > > Looks like ipfw processing happens before IPsec (so natd sees the > IPsec'ed packets, but doesn't know anything about them), and gets thems > them after IPsec inbound processing. What you want is a way to do IPsec > first, and then ipfw processing, but I don't know if that can be done. > > Try configuring an IPIP tunnel between B and C, and transport-mode IPsec > that. That way, your NAT packets get tunneled, and the tunneled packets > secured. On inbound, security processing comes first, then > decapsulation, then ipfw. Only with the following patch: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/ip_input.c.diff?r1=1.213&r2=1.214 -Guido To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 21 2: 1: 9 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 881EB37B401; Mon, 21 Oct 2002 02:01:08 -0700 (PDT) Received: from relay1.macomnet.ru (relay1.macomnet.ru [195.128.64.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2295943E3B; Mon, 21 Oct 2002 02:01:07 -0700 (PDT) (envelope-from maxim@macomnet.ru) Received: from news1.macomnet.ru (news1.macomnet.ru [195.128.64.14]) by relay1.macomnet.ru (8.11.6/8.11.6) with ESMTP id g9L915c1664314; Mon, 21 Oct 2002 13:01:05 +0400 (MSD) Date: Mon, 21 Oct 2002 13:01:05 +0400 (MSD) From: Maxim Konovalov <maxim@macomnet.ru> X-X-Sender: Maxim Konovalov <maxim@macomnet.ru> To: stable@freebsd.org Cc: net@freebsd.org Subject: MFC patch for "un-bzero'd sin_zero causes bind() in PF_INET to fail" problem Message-ID: <20021021125129.Q33128-100000@news1.macomnet.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org Hello, I am planning to MFC to RELENG_4 a diff below. Any objections? References: http://www.freebsd.org/cgi/query-pr.cgi?pr=31704 http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/36813 Index: src/sys/netinet/in_pcb.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/in_pcb.c,v retrieving revision 1.91 retrieving revision 1.92 diff -u -r1.91 -r1.92 --- src/sys/netinet/in_pcb.c 17 Oct 2001 18:07:05 -0000 1.91 +++ src/sys/netinet/in_pcb.c 6 Nov 2001 00:48:01 -0000 1.92 @@ -221,6 +221,7 @@ reuseport = SO_REUSEADDR|SO_REUSEPORT; } else if (sin->sin_addr.s_addr != INADDR_ANY) { sin->sin_port = 0; /* yech... */ + bzero(&sin->sin_zero, sizeof(sin->sin_zero)); if (ifa_ifwithaddr((struct sockaddr *)sin) == 0) return (EADDRNOTAVAIL); } %%% -- Maxim Konovalov, MAcomnet, Internet Dept., system engineer phone: +7 (095) 796-9079, mailto:maxim@macomnet.ru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 21 7: 6:32 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0571637B401 for <freebsd-net@freebsd.org>; Mon, 21 Oct 2002 07:06:32 -0700 (PDT) Received: from mail.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7CA1A43E3B for <freebsd-net@freebsd.org>; Mon, 21 Oct 2002 07:06:31 -0700 (PDT) (envelope-from don@sandvine.com) Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19) id <42S9VCJM>; Mon, 21 Oct 2002 10:06:25 -0400 Message-ID: <FE045D4D9F7AED4CBFF1B3B813C8533701022CED@mail.sandvine.com> From: Don Bowman <don@sandvine.com> To: 'Petri Helenius' <pete@he.iki.fi> Cc: "'freebsd-net@freebsd.org'" <freebsd-net@freebsd.org> Subject: RE: ENOBUFS Date: Mon, 21 Oct 2002 10:06:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org Re: which servers have broadcom GE on motherboard: The P4DL6 has the GC-LE which has the broadcom GE currently. http://www.supermicro.com/PRODUCT/MotherBoards/GC_LE/P4DL6.htm you'll have to ask supermicro for details on the new serverworks-based motherboards (http://www.serverworks.com/news/press2002/pr020903.html) which have dual broadcom GE in the chipset. These would be 533MHz FSB. The main difference between the GC-LE (serverworks) and the e7500 (intel) chipsets is bandwidth: the GC-LE has a 3.2GB/s (full duplex) IMB, the e7500 has a 1GB/s (half-duplex) hublink. http://www.inqst.com/articles/p4csio/0220main.htm has details. --don (don@sandvine.com www.sandvine.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 21 14:15:18 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C6FAE37B401 for <freebsd-net@FreeBSD.org>; Mon, 21 Oct 2002 14:15:17 -0700 (PDT) Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D38743E65 for <freebsd-net@FreeBSD.org>; Mon, 21 Oct 2002 14:15:17 -0700 (PDT) (envelope-from archie@dellroad.org) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id OAA51990; Mon, 21 Oct 2002 14:12:00 -0700 (PDT) Received: from arch20m.dellroad.org (localhost [127.0.0.1]) by arch20m.dellroad.org (8.12.6/8.12.6) with ESMTP id g9LLC0ON059904; Mon, 21 Oct 2002 14:12:00 -0700 (PDT) (envelope-from archie@arch20m.dellroad.org) Received: (from archie@localhost) by arch20m.dellroad.org (8.12.6/8.12.6/Submit) id g9LLBxUk059903; Mon, 21 Oct 2002 14:11:59 -0700 (PDT) From: Archie Cobbs <archie@dellroad.org> Message-Id: <200210212111.g9LLBxUk059903@arch20m.dellroad.org> Subject: Re: MPD PPTP tunneling intermittantly fails In-Reply-To: <20021018045853.GA329@otdel1.org> "from Nikolai Saoukh at Oct 18, 2002 08:58:53 am" To: Nikolai Saoukh <bsd#nms@otdel-1.org> Date: Mon, 21 Oct 2002 14:11:59 -0700 (PDT) Cc: freebsd-net@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org Nikolai Saoukh writes: > | > is the huge amount of CCP Reset Requests from win client. > | > | Hmm, try enabling the mpp-stateless option. > > When on direct modem link the win client refuses mpp-stateless. Well that should still be OK. If the client is sending a lot of CCP reset-request's then the most likely explanation is that a lot of packets getting dropped somewhere... -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 21 14:15:25 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8FF4437B404 for <freebsd-net@FreeBSD.ORG>; Mon, 21 Oct 2002 14:15:24 -0700 (PDT) Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2521643E3B for <freebsd-net@FreeBSD.ORG>; Mon, 21 Oct 2002 14:15:23 -0700 (PDT) (envelope-from archie@dellroad.org) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id OAA51965; Mon, 21 Oct 2002 14:05:26 -0700 (PDT) Received: from arch20m.dellroad.org (localhost [127.0.0.1]) by arch20m.dellroad.org (8.12.6/8.12.6) with ESMTP id g9LL5QON059865; Mon, 21 Oct 2002 14:05:26 -0700 (PDT) (envelope-from archie@arch20m.dellroad.org) Received: (from archie@localhost) by arch20m.dellroad.org (8.12.6/8.12.6/Submit) id g9LL5PjY059864; Mon, 21 Oct 2002 14:05:25 -0700 (PDT) From: Archie Cobbs <archie@dellroad.org> Message-Id: <200210212105.g9LL5PjY059864@arch20m.dellroad.org> Subject: Re: MPD PPTP tunneling intermittantly fails In-Reply-To: <AEEMJFAIHDPJNCAKCHHBMELLCHAA.leonardc@cs.berkeley.edu> "from Leonard Chung at Oct 20, 2002 10:19:46 pm" To: Leonard Chung <leonardc@cs.berkeley.edu> Date: Mon, 21 Oct 2002 14:05:25 -0700 (PDT) Cc: freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org Leonard Chung writes: > Some additional info: from looking at an ethereal trace, I'm seeing source > quenches coming back to the machine VPN'ing in. Interestingly, ethereal also > reports an invalid checksum on a bunch of those packets. The strange thing > is, this machine has acted as a router/NAT for quite a while and so of all > the machines on the network, it's hardware is probably the most stable > (easily 150+ day uptimes). Not sure what that all means, probably worth further investigation. Don't know about Etherreal, but tcpdump had a bug where it would declare an invalid checksum on packets for which only the first portion was captured (due to a limited snap length). Etherreal may possibly have the same problem. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 21 14:30:13 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B4DEC37B401 for <freebsd-net@FreeBSD.ORG>; Mon, 21 Oct 2002 14:30:12 -0700 (PDT) Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2A83D43E3B for <freebsd-net@FreeBSD.ORG>; Mon, 21 Oct 2002 14:30:12 -0700 (PDT) (envelope-from archie@dellroad.org) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id OAA52169; Mon, 21 Oct 2002 14:20:08 -0700 (PDT) Received: from arch20m.dellroad.org (localhost [127.0.0.1]) by arch20m.dellroad.org (8.12.6/8.12.6) with ESMTP id g9LLK7ON060054; Mon, 21 Oct 2002 14:20:07 -0700 (PDT) (envelope-from archie@arch20m.dellroad.org) Received: (from archie@localhost) by arch20m.dellroad.org (8.12.6/8.12.6/Submit) id g9LLK77d060052; Mon, 21 Oct 2002 14:20:07 -0700 (PDT) From: Archie Cobbs <archie@dellroad.org> Message-Id: <200210212120.g9LLK77d060052@arch20m.dellroad.org> Subject: Re: mpd PPTP server; client gateway In-Reply-To: <20021019014522.4446.qmail@web21408.mail.yahoo.com> "from Carlos Carnero at Oct 18, 2002 06:45:22 pm" To: Carlos Carnero <zopewiz@yahoo.com> Date: Mon, 21 Oct 2002 14:20:07 -0700 (PDT) Cc: freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org Carlos Carnero writes: > I've succesfully configured mpd as PPTP server for > VPNs. But I have one stumbling block: when I connect > to the server from a Windows XP client, the new > connection gets assigned the same IP address as the > default gateway. For instance: > > Client IP address: 192.168.250.240 > Client netmask: 255.255.255.0 > Client gateway: 192.168.250.240 > > the latter _should_ be 192.168.250.1. Why? I thought that was how Windows displayed the "gateway" for a point-to-point connection. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 21 23:39:34 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D37CA37B401; Mon, 21 Oct 2002 23:39:32 -0700 (PDT) Received: from out4.mx.nwbl.wi.voyager.net (out4.mx.nwbl.wi.voyager.net [169.207.3.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7B71B43E65; Mon, 21 Oct 2002 23:39:32 -0700 (PDT) (envelope-from silby@silby.com) Received: from [10.1.1.6] (d53.as5.nwbl0.wi.voyager.net [169.207.137.181]) by out4.mx.nwbl.wi.voyager.net (Postfix) with ESMTP id 03802C2CEB; Tue, 22 Oct 2002 01:39:30 -0500 (CDT) Date: Tue, 22 Oct 2002 01:44:09 -0500 (CDT) From: Mike Silbersack <silby@silby.com> To: freebsd-net@freebsd.org Cc: jlemon@freebsd.org, Harti Brandt <brandt@fokus.gmd.de> Subject: MII problem, need more eyes Message-ID: <20021022013605.D1194-100000@patrocles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org In trying to figure out why if_xl's mii_tick is such a pig, I think I've stumbled upon a bug in -current's MII routines which I'd like confirmation on before I go ahead and fix. First, pull up http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/mii/nsphy.c?rev=1.2.2.5&content-type=text/x-cvsweb-markup Which is nsphy.c from -stable. Scroll down to "case MII_TICK" and examine closely. Now look at the same thing in -current: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/mii/nsphy.c?rev=1.16&content-type=text/x-cvsweb-markup And look at mii_phy_tick in mii_physubr.c: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/mii/nsphy.c?rev=1.16&content-type=text/x-cvsweb-markup Now here's the problem: In the original version (which is still present in -stable), the MII_TICK case aborts out of the function due to a bunch of circumstances which indicate that no autonegotiation is necessary. mii_phy_tick does the same. HOWEVER, mii_phy_tick returns 0, which indicates to the new MII_TICK logic that autonegotiation _is_ necessary, thereby reautonegotiating _every second_. I believe that the correct fix would be: if (IFM_SUBTYPE(ife->ifm_media) != IFM_AUTO) - return (0); + return (EJUSTRETURN); /* Read the status register twice; BMSR_LINK is latch-low. */ reg = PHY_READ(sc, MII_BMSR) | PHY_READ(sc, MII_BMSR); if (reg & BMSR_LINK) { /* * See above. */ - return (0); + return (EJUSTRETURN); } Doing this results in much quicker mii_ticks, dropping the time taken for the normal case from 11ms to 3ms, without any of Harti Brandt's optimizations. Also, I believe that this change makes it operate more correctly. Could someone take a quick look over this to confirm that my patch makes sense? Thanks, Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 22 0:51: 0 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 55DED37B401; Tue, 22 Oct 2002 00:50:58 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 388D243E4A; Tue, 22 Oct 2002 00:50:57 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id RAA26021; Tue, 22 Oct 2002 17:50:49 +1000 Date: Tue, 22 Oct 2002 18:01:46 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> X-X-Sender: bde@gamplex.bde.org To: Mike Silbersack <silby@silby.com> Cc: freebsd-net@FreeBSD.ORG, <jlemon@FreeBSD.ORG>, Harti Brandt <brandt@fokus.gmd.de> Subject: Re: MII problem, need more eyes In-Reply-To: <20021022013605.D1194-100000@patrocles.silby.com> Message-ID: <20021022174319.V13842-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org On Tue, 22 Oct 2002, Mike Silbersack wrote: > In trying to figure out why if_xl's mii_tick is such a pig, I think I've > stumbled upon a bug in -current's MII routines which I'd like confirmation > on before I go ahead and fix. > ... > In the original version (which is still present in -stable), the MII_TICK > case aborts out of the function due to a bunch of circumstances which > indicate that no autonegotiation is necessary. mii_phy_tick does the > same. HOWEVER, mii_phy_tick returns 0, which indicates to the new > MII_TICK logic that autonegotiation _is_ necessary, thereby > reautonegotiating _every second_. > > I believe that the correct fix would be: > > if (IFM_SUBTYPE(ife->ifm_media) != IFM_AUTO) > - return (0); > + return (EJUSTRETURN); This return of 0 is apparently intentional. The comment before this says: /* * If we're not doing autonegotiation, we don't need to do * any extra work here. However, we need to check the link * status so we can generate an announcement if the status * changes. */ Here the "However" clause is not in RELENG_4. Returning 0 gets the status updated. I think this is just too expensive to do every second. Autonegotiation is only retried every 17 seconds (every 5 seconds in RELENG_4). > > /* Read the status register twice; BMSR_LINK is latch-low. */ > reg = PHY_READ(sc, MII_BMSR) | PHY_READ(sc, MII_BMSR); > if (reg & BMSR_LINK) { > /* > * See above. > */ > - return (0); > + return (EJUSTRETURN); > } I think the "However" clause applies to this return too. The status update code does lots more than the above to determine the exact state. > Doing this results in much quicker mii_ticks, dropping the time taken for > the normal case from 11ms to 3ms, without any of Harti Brandt's > optimizations. Also, I believe that this change makes it operate more > correctly. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 22 2:36:52 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C172937B401; Tue, 22 Oct 2002 02:36:51 -0700 (PDT) Received: from daemon.kr.FreeBSD.org (daemon.kr.freebsd.org [211.176.62.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F49743E6A; Tue, 22 Oct 2002 02:36:43 -0700 (PDT) (envelope-from cjh@kr.FreeBSD.org) Received: from gradius.wdb.co.kr (daemon [211.176.62.31]) by daemon.kr.FreeBSD.org (Postfix) with ESMTP id 174AD8F60B; Tue, 22 Oct 2002 18:36:32 +0900 (KST) Received: from localhost (localhost [127.0.0.1]) by gradius.wdb.co.kr (8.12.6/8.12.5) with ESMTP id g9M9aR0w070068; Tue, 22 Oct 2002 18:36:28 +0900 (KST) (envelope-from cjh@kr.FreeBSD.org) Date: Tue, 22 Oct 2002 18:36:26 +0900 (KST) Message-Id: <20021022.183626.122873841.cjh@kr.FreeBSD.org> To: freebsd-net@freebsd.org Cc: cjh@freebsd.org Subject: bridge + ipfw fwd? From: CHOI Junho <cjh@kr.FreeBSD.org> Organization: Korea FreeBSD Users Gruop X-URL: http://www.kr.FreeBSD.org/~cjh X-Mailer: Mew version 3.0.69 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org Hi, I found packet forwarding by 'ipfw fwd' doesn't work for bridged configuration - linking 2 ethernet cards. I use bridged firewall for our office network, I tried to configure transparent proxy in the level of firewall. I looked the code contains bdg_forward() in sys/, but I found only it is not implemented at least in 4.7. Is there any patches for implementing it or still it is to-do features? Or do we have a reason why bridge+ipfw fwd is impossible? p.s. Please keep me on Cc:. -- CHOI Junho <http://www.kr.FreeBSD.org/~cjh> <cjh at kr.FreeBSD.org> FreeBSD Project <cjh at FreeBSD.org> Web Data Bank <cjh at wdb.co.kr> Key fingerprint = 1369 7374 A45F F41A F3C0 07E3 4A01 C020 E602 60F5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 22 7:34:36 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D2A0937B401 for <freebsd-net@freebsd.org>; Tue, 22 Oct 2002 07:34:35 -0700 (PDT) Received: from hub.org (hub.org [64.49.215.141]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6E1CF43E6A for <freebsd-net@freebsd.org>; Tue, 22 Oct 2002 07:34:35 -0700 (PDT) (envelope-from scrappy@hub.org) Received: from hub.org (hub.org [64.49.215.141]) by hub.org (Postfix) with ESMTP id E130B8A1947 for <freebsd-net@freebsd.org>; Tue, 22 Oct 2002 11:34:28 -0300 (ADT) Date: Tue, 22 Oct 2002 11:34:28 -0300 (ADT) From: "Marc G. Fournier" <scrappy@hub.org> To: freebsd-net@freebsd.org Subject: dest vs source ports ... Message-ID: <20021022113147.X47756-100000@hub.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org Just a quick question ... how does the OS determine the 'source port' when connecting to a remote site? is it reasonably safe to assume that the lower of the two ports is the dest port? for instance, if I try to telnet to a remote site where the remote site is running a service on port 6667, is it a pretty safe bet that FreeBSD will pick a port >6667 to go out on? or is there an equal chance of it being lower? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 22 7:40:46 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 29FB537B401 for <freebsd-net@freebsd.org>; Tue, 22 Oct 2002 07:40:45 -0700 (PDT) Received: from mailb.telia.com (mailb.telia.com [194.22.194.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0E21643E6A for <freebsd-net@freebsd.org>; Tue, 22 Oct 2002 07:40:44 -0700 (PDT) (envelope-from erikt@midgard.homeip.net) Received: from d1o913.telia.com (d1o913.telia.com [195.252.44.241]) by mailb.telia.com (8.12.5/8.12.5) with ESMTP id g9MEeg15019217 for <freebsd-net@freebsd.org>; Tue, 22 Oct 2002 16:40:42 +0200 (CEST) X-Original-Recipient: <freebsd-net@freebsd.org> Received: from falcon.midgard.homeip.net (h76n3fls20o913.telia.com [213.67.148.76]) by d1o913.telia.com (8.8.8/8.8.8) with SMTP id QAA09535 for <freebsd-net@freebsd.org>; Tue, 22 Oct 2002 16:40:41 +0200 (CEST) Received: (qmail 68786 invoked by uid 1001); 22 Oct 2002 14:40:40 -0000 Date: Tue, 22 Oct 2002 16:40:40 +0200 From: Erik Trulsson <ertr1013@student.uu.se> To: "Marc G. Fournier" <scrappy@hub.org> Cc: freebsd-net@freebsd.org Subject: Re: dest vs source ports ... Message-ID: <20021022144040.GA68774@falcon.midgard.homeip.net> Mail-Followup-To: "Marc G. Fournier" <scrappy@hub.org>, freebsd-net@freebsd.org References: <20021022113147.X47756-100000@hub.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021022113147.X47756-100000@hub.org> User-Agent: Mutt/1.5.1i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org On Tue, Oct 22, 2002 at 11:34:28AM -0300, Marc G. Fournier wrote: > > Just a quick question ... how does the OS determine the 'source port' when > connecting to a remote site? is it reasonably safe to assume that the > lower of the two ports is the dest port? for instance, if I try to telnet > to a remote site where the remote site is running a service on port 6667, > is it a pretty safe bet that FreeBSD will pick a port >6667 to go out on? > or is there an equal chance of it being lower? If one does not specify the source port that is to be used the OS just picks one at random from the set of available port numbers. (Alright, it's not quite random, but it could as well be.) There is normally no relationship between source and destination port numbers. -- <Insert your favourite quote here.> Erik Trulsson ertr1013@student.uu.se To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 22 8: 5:27 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 939F437B401 for <freebsd-net@FreeBSD.ORG>; Tue, 22 Oct 2002 08:05:26 -0700 (PDT) Received: from tigger.pacehouse.com (adsl-63-201-229-115.dsl.snfc21.pacbell.net [63.201.229.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id CCA6743E3B for <freebsd-net@FreeBSD.ORG>; Tue, 22 Oct 2002 08:05:25 -0700 (PDT) (envelope-from jepace@pobox.com) Received: from tigger.pacehouse.com (localhost [127.0.0.1]) by tigger.pacehouse.com (8.12.6/8.12.5) with ESMTP id g9MF5KT2013283; Tue, 22 Oct 2002 08:05:20 -0700 (PDT) (envelope-from jepace@pobox.com) Received: from localhost (jepace@localhost) by tigger.pacehouse.com (8.12.6/8.12.6/Submit) with ESMTP id g9MF5K6x013280; Tue, 22 Oct 2002 08:05:20 -0700 (PDT) X-Authentication-Warning: tigger.pacehouse.com: jepace owned process doing -bs Date: Tue, 22 Oct 2002 08:05:20 -0700 (PDT) From: James Pace <jepace@pobox.com> X-X-Sender: jepace@tigger.pacehouse.com Reply-To: James Pace <jepace@pobox.com> To: "Marc G. Fournier" <scrappy@hub.org> Cc: freebsd-net@FreeBSD.ORG Subject: Re: dest vs source ports ... In-Reply-To: <20021022113147.X47756-100000@hub.org> Message-ID: <20021022075511.A85197-100000@tigger.pacehouse.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org On Tue, 22 Oct 2002, Marc G. Fournier wrote: > Just a quick question ... how does the OS determine the 'source port' when > connecting to a remote site? The OS picks one from a pool of ports, unless told to use one explicitly. These are called ephemeral ports. > is it reasonably safe to assume that the lower of the two ports is > the dest port? This seems dubious, at best. It is easy to exactly determine what the ports involved are, rather than coming up with a heuristic. Check out 'netstat -a' or 'lsof'. > for instance, if I try to telnet to a remote site where the remote > site is running a service on port 6667, is it a pretty safe bet that > FreeBSD will pick a port >6667 to go out on? or is there an equal > chance of it being lower? In general, it will be greater than 6667 (32000+), but not guaranteed. If the applications chooses to bind(2) to a port, it could be almost anything. I think this question is better suited for freebsd-questions than freebsd-net. I would also recommend picking up a tutorial on TCP/IP. Thanks, -James -- James Pace <jepace@pobox.com> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 22 8:39: 6 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9E6BD37B401 for <freebsd-net@freebsd.org>; Tue, 22 Oct 2002 08:39:05 -0700 (PDT) Received: from out2.mx.nwbl.wi.voyager.net (out2.mx.nwbl.wi.voyager.net [169.207.3.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id 477E343E6A for <freebsd-net@freebsd.org>; Tue, 22 Oct 2002 08:39:05 -0700 (PDT) (envelope-from silby@silby.com) Received: from [10.1.1.6] (d99.as4.nwbl0.wi.voyager.net [169.207.137.99]) by out2.mx.nwbl.wi.voyager.net (Postfix) with ESMTP id BD034282FA; Tue, 22 Oct 2002 10:38:54 -0500 (CDT) Date: Tue, 22 Oct 2002 10:43:36 -0500 (CDT) From: Mike Silbersack <silby@silby.com> To: "Marc G. Fournier" <scrappy@hub.org> Cc: freebsd-net@freebsd.org Subject: Re: dest vs source ports ... In-Reply-To: <20021022113147.X47756-100000@hub.org> Message-ID: <20021022104052.D3313-100000@patrocles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org On Tue, 22 Oct 2002, Marc G. Fournier wrote: > Just a quick question ... how does the OS determine the 'source port' when > connecting to a remote site? is it reasonably safe to assume that the > lower of the two ports is the dest port? for instance, if I try to telnet > to a remote site where the remote site is running a service on port 6667, > is it a pretty safe bet that FreeBSD will pick a port >6667 to go out on? > or is there an equal chance of it being lower? The ephemeral port range used for source ports on outbound connects is controllable through sysctl: net.inet.ip.portrange.first: 49152 net.inet.ip.portrange.last: 65535 And different between -stable and -current. (-stable uses the values 1024 through 5000.) Note also that there is a hifirst->hilast range as well, which is used by ftp and some other apps. You would be very wise to not create any firewall rules which depended on there being any relation between the ephemeral ports and whatever you are connecting to. (In addition, there's nothing stopping a program from picking a port 1024 < x < 65535 of its own choosing.) Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 22 10:47:43 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8D66D37B401 for <freebsd-net@freebsd.org>; Tue, 22 Oct 2002 10:47:41 -0700 (PDT) Received: from hub.org (hub.org [64.49.215.141]) by mx1.FreeBSD.org (Postfix) with ESMTP id 46C7F43E6E for <freebsd-net@freebsd.org>; Tue, 22 Oct 2002 10:47:41 -0700 (PDT) (envelope-from scrappy@hub.org) Received: from hub.org (hub.org [64.49.215.141]) by hub.org (Postfix) with ESMTP id A21678A1601 for <freebsd-net@freebsd.org>; Tue, 22 Oct 2002 14:47:36 -0300 (ADT) Date: Tue, 22 Oct 2002 14:47:36 -0300 (ADT) From: "Marc G. Fournier" <scrappy@hub.org> To: freebsd-net@freebsd.org Subject: determining "originator/source" of connection ... Message-ID: <20021022143427.Y47756-100000@hub.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org I've got FreeBSD setup as a firewall to our campus network, and its doing a great job of it, but we want to be able log statistics on traffic going in and out ... I have trafd running on the server, with it dumping its data to a PostgreSQL database, but for every ~8min "segment", it is logging ~12 000 records ... so ~90k/hr, or 2.16 million per day ... Now, I'm figuring that if I could determine direction of flow (did we originate the connection, or did someone off campus originate it), I could shrink that greatly, as right now I have stuff like: 216.158.133.242 80 131.162.158.24 3914 6 2356 4 216.158.133.242 80 131.162.158.24 3915 6 47767 34 216.158.133.242 80 131.162.158.24 3916 6 78962 56 216.158.133.242 80 131.162.158.24 3917 6 330141 224 216.158.133.242 80 131.162.158.24 3918 6 118862 89 216.158.133.242 80 131.162.158.24 3919 6 264139 185 216.158.133.242 80 131.162.158.24 3920 6 259543 179 216.158.133.242 80 131.162.158.24 3921 6 98014 73 216.158.133.242 80 131.162.158.24 3922 6 267772 186 216.158.133.242 80 131.162.158.24 3923 6 148879 109 216.158.133.242 80 131.162.158.24 3924 6 6406 8 216.158.133.242 80 131.162.158.24 3925 6 2486 5 216.158.133.242 80 131.162.158.24 3928 6 109584 75 216.158.133.242 80 131.162.158.24 3929 6 92435 62 216.158.133.242 80 131.162.158.24 3936 6 13059 9 216.158.133.242 80 131.162.158.24 3937 6 22641 17 where I don't care about the source port, only the dest port ... except, in the above, trafd is writing it as 'source port == 80' and 'dest port' is arbitray ... while later in the results, I'll get something like: 130.94.4.7 40072 131.162.138.193 25 6 2976 10 130.94.4.7 58562 131.162.138.193 25 6 5249 16 which does make sense (ie. source port -> dest port) ... is there something that i can do with libpcap that will give me better information then trafd does? is there a 'tag' in the IP headers that can be used to determine the originator of the connection? thanks ... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 22 11:21:43 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7E3AF37B401 for <freebsd-net@freebsd.org>; Tue, 22 Oct 2002 11:21:41 -0700 (PDT) Received: from mail2.dbitech.ca (radius.wavefire.com [64.141.13.252]) by mx1.FreeBSD.org (Postfix) with SMTP id C5F4943E3B for <freebsd-net@freebsd.org>; Tue, 22 Oct 2002 11:21:40 -0700 (PDT) (envelope-from darcy@wavefire.com) Received: (qmail 10322 invoked from network); 22 Oct 2002 18:44:05 -0000 Received: from dbitech.wavefire.com (HELO dbitech) (darcy@64.141.15.253) by radius.wavefire.com with SMTP; 22 Oct 2002 18:44:05 -0000 Content-Type: text/plain; charset="iso-8859-1" From: Darcy Buskermolen <darcy@wavefire.com> Organization: Wavefire Technologies Corp. To: "Marc G. Fournier" <scrappy@hub.org>, freebsd-net@freebsd.org Subject: Re: determining "originator/source" of connection ... Date: Tue, 22 Oct 2002 11:21:22 -0700 User-Agent: KMail/1.4.3 References: <20021022143427.Y47756-100000@hub.org> In-Reply-To: <20021022143427.Y47756-100000@hub.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200210221121.22487.darcy@wavefire.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org For this kind of thing I usualy use ntop with the cflow connector to outp= ut=20 the flow data as regular CISCO flowd stuff. This data can then be analyse= d=20 using tools like rdd and friends. On Tuesday 22 October 2002 10:47, Marc G. Fournier wrote: > I've got FreeBSD setup as a firewall to our campus network, and its doi= ng > a great job of it, but we want to be able log statistics on traffic goi= ng > in and out ... > > I have trafd running on the server, with it dumping its data to a > PostgreSQL database, but for every ~8min "segment", it is logging ~12 0= 00 > records ... so ~90k/hr, or 2.16 million per day ... > > Now, I'm figuring that if I could determine direction of flow (did we > originate the connection, or did someone off campus originate it), I co= uld > shrink that greatly, as right now I have stuff like: > > 216.158.133.242 80 131.162.158.24 3914 6 2356 4 > 216.158.133.242 80 131.162.158.24 3915 6 47767 34 > 216.158.133.242 80 131.162.158.24 3916 6 78962 56 > 216.158.133.242 80 131.162.158.24 3917 6 330141 224 > 216.158.133.242 80 131.162.158.24 3918 6 118862 89 > 216.158.133.242 80 131.162.158.24 3919 6 264139 185 > 216.158.133.242 80 131.162.158.24 3920 6 259543 179 > 216.158.133.242 80 131.162.158.24 3921 6 98014 73 > 216.158.133.242 80 131.162.158.24 3922 6 267772 186 > 216.158.133.242 80 131.162.158.24 3923 6 148879 109 > 216.158.133.242 80 131.162.158.24 3924 6 6406 8 > 216.158.133.242 80 131.162.158.24 3925 6 2486 5 > 216.158.133.242 80 131.162.158.24 3928 6 109584 75 > 216.158.133.242 80 131.162.158.24 3929 6 92435 62 > 216.158.133.242 80 131.162.158.24 3936 6 13059 9 > 216.158.133.242 80 131.162.158.24 3937 6 22641 17 > > where I don't care about the source port, only the dest port ... except= , > in the above, trafd is writing it as 'source port =3D=3D 80' and 'dest = port' > is arbitray ... > > while later in the results, I'll get something like: > > 130.94.4.7 40072 131.162.138.193 25 6 2976 10 > 130.94.4.7 58562 131.162.138.193 25 6 5249 16 > > which does make sense (ie. source port -> dest port) ... > > is there something that i can do with libpcap that will give me better > information then trafd does? is there a 'tag' in the IP headers that c= an > be used to determine the originator of the connection? > > thanks ... > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message --=20 Darcy Buskermolen Wavefire Technologies Corp. ph: 250.717.0200 fx: 250.763.1759 http://www.wavefire.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 22 11:27:49 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5C80437B401; Tue, 22 Oct 2002 11:27:48 -0700 (PDT) Received: from carp.icir.org (carp.icir.org [192.150.187.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id E061643E4A; Tue, 22 Oct 2002 11:27:47 -0700 (PDT) (envelope-from rizzo@carp.icir.org) Received: from carp.icir.org (localhost [127.0.0.1]) by carp.icir.org (8.12.3/8.12.3) with ESMTP id g9MIRlpJ034010; Tue, 22 Oct 2002 11:27:47 -0700 (PDT) (envelope-from rizzo@carp.icir.org) Received: (from rizzo@localhost) by carp.icir.org (8.12.3/8.12.3/Submit) id g9MIRl66034009; Tue, 22 Oct 2002 11:27:47 -0700 (PDT) (envelope-from rizzo) Date: Tue, 22 Oct 2002 11:27:47 -0700 From: Luigi Rizzo <rizzo@icir.org> To: CHOI Junho <cjh@kr.FreeBSD.org> Cc: freebsd-net@FreeBSD.ORG, cjh@FreeBSD.ORG Subject: Re: bridge + ipfw fwd? Message-ID: <20021022112747.B33933@carp.icir.org> References: <20021022.183626.122873841.cjh@kr.FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20021022.183626.122873841.cjh@kr.FreeBSD.org>; from cjh@kr.FreeBSD.org on Tue, Oct 22, 2002 at 06:36:26PM +0900 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org layer-2 forwaed is not supported, and the reason is that forwarding occurs at a different layer. One way to implement this feature is the following: + in bdg_forward(), when a packet matches a "forward" action, somehow mark the packet as having a local destination (e.g. overwrite the MAC DST address) and pass it to ether_input this requires a bit of care to avoid loops, i think. cheers luigi On Tue, Oct 22, 2002 at 06:36:26PM +0900, CHOI Junho wrote: > > Hi, > > I found packet forwarding by 'ipfw fwd' doesn't work for bridged > configuration - linking 2 ethernet cards. I use bridged firewall for > our office network, I tried to configure transparent proxy in the > level of firewall. > > I looked the code contains bdg_forward() in sys/, but I found only it > is not implemented at least in 4.7. Is there any patches for > implementing it or still it is to-do features? Or do we have a > reason why bridge+ipfw fwd is impossible? > > p.s. Please keep me on Cc:. > > -- > CHOI Junho <http://www.kr.FreeBSD.org/~cjh> <cjh at kr.FreeBSD.org> > FreeBSD Project <cjh at FreeBSD.org> Web Data Bank <cjh at wdb.co.kr> > Key fingerprint = 1369 7374 A45F F41A F3C0 07E3 4A01 C020 E602 60F5 > > 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 Oct 22 11:32:52 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8C3D837B401 for <freebsd-net@FreeBSD.ORG>; Tue, 22 Oct 2002 11:32:50 -0700 (PDT) Received: from carp.icir.org (carp.icir.org [192.150.187.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0212A43E42 for <freebsd-net@FreeBSD.ORG>; Tue, 22 Oct 2002 11:32:50 -0700 (PDT) (envelope-from rizzo@carp.icir.org) Received: from carp.icir.org (localhost [127.0.0.1]) by carp.icir.org (8.12.3/8.12.3) with ESMTP id g9MIWnpJ034065; Tue, 22 Oct 2002 11:32:49 -0700 (PDT) (envelope-from rizzo@carp.icir.org) Received: (from rizzo@localhost) by carp.icir.org (8.12.3/8.12.3/Submit) id g9MIWnIw034064; Tue, 22 Oct 2002 11:32:49 -0700 (PDT) (envelope-from rizzo) Date: Tue, 22 Oct 2002 11:32:49 -0700 From: Luigi Rizzo <rizzo@icir.org> To: "Marc G. Fournier" <scrappy@hub.org> Cc: freebsd-net@FreeBSD.ORG Subject: Re: determining "originator/source" of connection ... Message-ID: <20021022113249.C33933@carp.icir.org> References: <20021022143427.Y47756-100000@hub.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20021022143427.Y47756-100000@hub.org>; from scrappy@hub.org on Tue, Oct 22, 2002 at 02:47:36PM -0300 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org let me understand, you basically want something that puts flow statistics in the bucket identified by the <dst-ip,dst-port> of the first SYN packet you see (the assumption being that connections are initiated by clients towards a well known port, which appears as dst-port in the first syn packet ? Or if you are just happy to aggregate by IP, one solution i often use is the following (based on dummynet's dynamic pipes): # do not expire pipes even if they have no pending traffic sysctl net.inet.ip.dummynet.expire=0 # create separate pipes for src and dst masks ipfw pipe 20 config mask src-ip 0xffffffff buckets 256 ipfw pipe 21 config mask dst-ip 0xffffffff buckets 256 ipfw add pipe 20 ip from $my_subnet to any ipfw add pipe 21 ip from any to $my subnet cheers luigi On Tue, Oct 22, 2002 at 02:47:36PM -0300, Marc G. Fournier wrote: > > I've got FreeBSD setup as a firewall to our campus network, and its doing > a great job of it, but we want to be able log statistics on traffic going > in and out ... > > I have trafd running on the server, with it dumping its data to a > PostgreSQL database, but for every ~8min "segment", it is logging ~12 000 > records ... so ~90k/hr, or 2.16 million per day ... > > Now, I'm figuring that if I could determine direction of flow (did we > originate the connection, or did someone off campus originate it), I could > shrink that greatly, as right now I have stuff like: > > 216.158.133.242 80 131.162.158.24 3914 6 2356 4 > 216.158.133.242 80 131.162.158.24 3915 6 47767 34 > 216.158.133.242 80 131.162.158.24 3916 6 78962 56 > 216.158.133.242 80 131.162.158.24 3917 6 330141 224 > 216.158.133.242 80 131.162.158.24 3918 6 118862 89 > 216.158.133.242 80 131.162.158.24 3919 6 264139 185 > 216.158.133.242 80 131.162.158.24 3920 6 259543 179 > 216.158.133.242 80 131.162.158.24 3921 6 98014 73 > 216.158.133.242 80 131.162.158.24 3922 6 267772 186 > 216.158.133.242 80 131.162.158.24 3923 6 148879 109 > 216.158.133.242 80 131.162.158.24 3924 6 6406 8 > 216.158.133.242 80 131.162.158.24 3925 6 2486 5 > 216.158.133.242 80 131.162.158.24 3928 6 109584 75 > 216.158.133.242 80 131.162.158.24 3929 6 92435 62 > 216.158.133.242 80 131.162.158.24 3936 6 13059 9 > 216.158.133.242 80 131.162.158.24 3937 6 22641 17 > > where I don't care about the source port, only the dest port ... except, > in the above, trafd is writing it as 'source port == 80' and 'dest port' > is arbitray ... > > while later in the results, I'll get something like: > > 130.94.4.7 40072 131.162.138.193 25 6 2976 10 > 130.94.4.7 58562 131.162.138.193 25 6 5249 16 > > which does make sense (ie. source port -> dest port) ... > > is there something that i can do with libpcap that will give me better > information then trafd does? is there a 'tag' in the IP headers that can > be used to determine the originator of the connection? > > 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 Tue Oct 22 11:48:19 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D084737B401 for <freebsd-net@FreeBSD.ORG>; Tue, 22 Oct 2002 11:48:16 -0700 (PDT) Received: from hub.org (hub.org [64.49.215.141]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1BCEA43E3B for <freebsd-net@FreeBSD.ORG>; Tue, 22 Oct 2002 11:48:16 -0700 (PDT) (envelope-from scrappy@hub.org) Received: from hub.org (hub.org [64.49.215.141]) by hub.org (Postfix) with ESMTP id 804558A1F05; Tue, 22 Oct 2002 15:48:13 -0300 (ADT) Date: Tue, 22 Oct 2002 15:48:13 -0300 (ADT) From: "Marc G. Fournier" <scrappy@hub.org> To: Luigi Rizzo <rizzo@icir.org> Cc: freebsd-net@FreeBSD.ORG Subject: Re: determining "originator/source" of connection ... In-Reply-To: <20021022113249.C33933@carp.icir.org> Message-ID: <20021022154730.K25737-100000@hub.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org On Tue, 22 Oct 2002, Luigi Rizzo wrote: > let me understand, you basically want something that puts flow statistics > in the bucket identified by the <dst-ip,dst-port> of the first SYN > packet you see (the assumption being that connections are > initiated by clients towards a well known port, which appears > as dst-port in the first syn packet ? > > Or if you are just happy to aggregate by IP, one solution i often > use is the following (based on dummynet's dynamic pipes): > > # do not expire pipes even if they have no pending traffic > sysctl net.inet.ip.dummynet.expire=0 > > # create separate pipes for src and dst masks > ipfw pipe 20 config mask src-ip 0xffffffff buckets 256 > ipfw pipe 21 config mask dst-ip 0xffffffff buckets 256 > > ipfw add pipe 20 ip from $my_subnet to any > ipfw add pipe 21 ip from any to $my subnet I don't believe I could do this with ipfw ... $my_subnet == 131.162.0.0 :( I fear the machin would strat to smoke, no? :( > > cheers > luigi > > > On Tue, Oct 22, 2002 at 02:47:36PM -0300, Marc G. Fournier wrote: > > > > I've got FreeBSD setup as a firewall to our campus network, and its doing > > a great job of it, but we want to be able log statistics on traffic going > > in and out ... > > > > I have trafd running on the server, with it dumping its data to a > > PostgreSQL database, but for every ~8min "segment", it is logging ~12 000 > > records ... so ~90k/hr, or 2.16 million per day ... > > > > Now, I'm figuring that if I could determine direction of flow (did we > > originate the connection, or did someone off campus originate it), I could > > shrink that greatly, as right now I have stuff like: > > > > 216.158.133.242 80 131.162.158.24 3914 6 2356 4 > > 216.158.133.242 80 131.162.158.24 3915 6 47767 34 > > 216.158.133.242 80 131.162.158.24 3916 6 78962 56 > > 216.158.133.242 80 131.162.158.24 3917 6 330141 224 > > 216.158.133.242 80 131.162.158.24 3918 6 118862 89 > > 216.158.133.242 80 131.162.158.24 3919 6 264139 185 > > 216.158.133.242 80 131.162.158.24 3920 6 259543 179 > > 216.158.133.242 80 131.162.158.24 3921 6 98014 73 > > 216.158.133.242 80 131.162.158.24 3922 6 267772 186 > > 216.158.133.242 80 131.162.158.24 3923 6 148879 109 > > 216.158.133.242 80 131.162.158.24 3924 6 6406 8 > > 216.158.133.242 80 131.162.158.24 3925 6 2486 5 > > 216.158.133.242 80 131.162.158.24 3928 6 109584 75 > > 216.158.133.242 80 131.162.158.24 3929 6 92435 62 > > 216.158.133.242 80 131.162.158.24 3936 6 13059 9 > > 216.158.133.242 80 131.162.158.24 3937 6 22641 17 > > > > where I don't care about the source port, only the dest port ... except, > > in the above, trafd is writing it as 'source port == 80' and 'dest port' > > is arbitray ... > > > > while later in the results, I'll get something like: > > > > 130.94.4.7 40072 131.162.138.193 25 6 2976 10 > > 130.94.4.7 58562 131.162.138.193 25 6 5249 16 > > > > which does make sense (ie. source port -> dest port) ... > > > > is there something that i can do with libpcap that will give me better > > information then trafd does? is there a 'tag' in the IP headers that can > > be used to determine the originator of the connection? > > > > 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 Tue Oct 22 11:56:27 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B243737B401 for <freebsd-net@FreeBSD.ORG>; Tue, 22 Oct 2002 11:56:25 -0700 (PDT) Received: from carp.icir.org (carp.icir.org [192.150.187.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5EDC643E7B for <freebsd-net@FreeBSD.ORG>; Tue, 22 Oct 2002 11:56:25 -0700 (PDT) (envelope-from rizzo@carp.icir.org) Received: from carp.icir.org (localhost [127.0.0.1]) by carp.icir.org (8.12.3/8.12.3) with ESMTP id g9MIuPpJ034289; Tue, 22 Oct 2002 11:56:25 -0700 (PDT) (envelope-from rizzo@carp.icir.org) Received: (from rizzo@localhost) by carp.icir.org (8.12.3/8.12.3/Submit) id g9MIuOOI034288; Tue, 22 Oct 2002 11:56:24 -0700 (PDT) (envelope-from rizzo) Date: Tue, 22 Oct 2002 11:56:24 -0700 From: Luigi Rizzo <rizzo@icir.org> To: "Marc G. Fournier" <scrappy@hub.org> Cc: freebsd-net@FreeBSD.ORG Subject: Re: determining "originator/source" of connection ... Message-ID: <20021022115624.A34249@carp.icir.org> References: <20021022113249.C33933@carp.icir.org> <20021022154730.K25737-100000@hub.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20021022154730.K25737-100000@hub.org>; from scrappy@hub.org on Tue, Oct 22, 2002 at 03:48:13PM -0300 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org On Tue, Oct 22, 2002 at 03:48:13PM -0300, Marc G. Fournier wrote: > On Tue, 22 Oct 2002, Luigi Rizzo wrote: ... > > Or if you are just happy to aggregate by IP, one solution i often > > use is the following (based on dummynet's dynamic pipes): > > > > # do not expire pipes even if they have no pending traffic > > sysctl net.inet.ip.dummynet.expire=0 > > > > # create separate pipes for src and dst masks > > ipfw pipe 20 config mask src-ip 0xffffffff buckets 256 > > ipfw pipe 21 config mask dst-ip 0xffffffff buckets 256 > > > > ipfw add pipe 20 ip from $my_subnet to any > > ipfw add pipe 21 ip from any to $my subnet > > I don't believe I could do this with ipfw ... $my_subnet == 131.162.0.0 :( > I fear the machin would strat to smoke, no? :( as long as you have enough memory and set the number of buckets large enough (probably more in the 2-4k range), i do not see problems. Yes, each flow consumes a bit of memory (i think some 128 bytes) but for 64k flows this is still bearable. You'll actually save the work of copying every packet to userland which all bpf-based solutions must do. 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 Oct 22 19:50:42 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8CE7337B401; Tue, 22 Oct 2002 19:50:34 -0700 (PDT) Received: from mail.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id AE35E43E3B; Tue, 22 Oct 2002 19:50:33 -0700 (PDT) (envelope-from don@sandvine.com) Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19) id <42S9VFG5>; Tue, 22 Oct 2002 22:50:32 -0400 Message-ID: <FE045D4D9F7AED4CBFF1B3B813C8533701022D2D@mail.sandvine.com> From: Don Bowman <don@sandvine.com> To: "'freebsd-stable@freebsd.org'" <freebsd-stable@freebsd.org>, "'freebsd-net@freebsd.org'" <freebsd-net@freebsd.org> Subject: panic with ipfw / dummynet in 4.7 STABLE Date: Tue, 22 Oct 2002 22:50:31 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org Take a 4.7 image. Using if_em (if it matters). Turn on bridging (em0, em2), add these ipfw rules: ipfw add 305 prob 0.01 drop MAC any 00:04:76:f3:2d:0a setup ipfw add 310 prob 0.01 reject MAC any 00:04:76:f3:2d:0a setup ipfw add 320 prob 0.01 unreach host MAC any 00:04:76:f3:2d:0a setup ipfw add 325 prob 0.01 unreach port MAC any 00:04:76:f3:2d:0a setup ipfw add pipe 1 config delay 90 plr 0.0001 ipfw add pipe 2 config delay 150 plr 0.0005 ipfw add 340 prob 0.5 pipe 1 ip from any to any ipfw add 345 prob 0.5 pipe 2 ip from any to any The system panics almost immediately (~1s). The panic and trace is below. Its doubtful much traffic was present on the em0 or em2 interfaces so this probably happened on the first packet. I'll turn on -g in the kernel (I thought for sure it was, but seems no...) and re-run. This is with -DIPFW2 on. So I'm doing: # kldload if_em # sysctl net.link.ether.bridge_cfg="em0 em2" # sysctl net.link.ether.bridge=1 (after the machine has booted). Then I run the script above to add the ipfw rules, and it tips over. bash-2.05a# uname -a FreeBSD TPC-E1-34 4.7-STABLE FreeBSD 4.7-STABLE #7: Tue Oct 22 22:07:55 EDT 2002 don@bsd-make.sandvine.com:/usr/obj/usr/src/sys/TPC i386 Machine is a 2x XEON 2.0 GHz w/ Intel 82544 on the motherboard, and an Intel 82546EB dual GE card in a PCI slot. It is SMP enabled. SMP 4 cpus IdlePTD at phsyical address 0x00430000 initial pcb at physical address 0x00369780 panicstr: page fault panic messages: --- Fatal trap 12: page fault while in kernel mode mp_lock = 00000002; cpuid = 0; lapic.id = 00000000 fault virtual address = 0x40000007 fault code = supervisor read, page not present instruction pointer = 0x8:0xc0204565 stack pointer = 0x10:0xff807eb4 frame pointer = 0x10:0xff807edc code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = Idle interrupt mask = net <- SMP: XXX trap number = 12 panic: page fault mp_lock = 00000002; cpuid = 0; lapic.id = 00000000 boot() called on cpu#0 syncing disks... Fatal trap 12: page fault while in kernel mode mp_lock = 00000003; cpuid = 0; lapic.id = 00000000 fault virtual address = 0x30 fault code = supervisor read, page not present instruction pointer = 0x8:0xc0266e11 stack pointer = 0x10:0xff807cc4 frame pointer = 0x10:0xff807ccc code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = Idle interrupt mask = net bio <- SMP: XXX trap number = 12 panic: page fault mp_lock = 00000003; cpuid = 0; lapic.id = 00000000 boot() called on cpu#0 Uptime: 3m6s #0 0xc01b19b2 in dumpsys () #1 0xc01b1783 in boot () #2 0xc01b1bdc in poweroff_wait () #3 0xc02cb508 in trap_fatal () #4 0xc02cb199 in trap_pfault () #5 0xc02cad37 in trap () #6 0xc0266e11 in acquire_lock () #7 0xc026af24 in softdep_update_inodeblock () #8 0xc0265f45 in ffs_update () #9 0xc026e357 in ffs_sync () #10 0xc01e29bf in sync () #11 0xc01b151e in boot () #12 0xc01b1bdc in poweroff_wait () #13 0xc02cb508 in trap_fatal () #14 0xc02cb199 in trap_pfault () #15 0xc02cad37 in trap () #16 0xc0204565 in dummynet_io () #17 0xc020991c in ip_input () #18 0xc0209ec7 in ipintr () #19 0xc02bca91 in swi_net_next () Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.7-STABLE #7: Tue Oct 22 22:07:55 EDT 2002 don@bsd-make.sandvine.com:/usr/obj/usr/src/sys/TPC Timecounter "i8254" frequency 1193182 Hz CPU: Pentium 4 (1996.60-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf24 Stepping = 4 Features=0x3febfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA ,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,<b28>,ACC> real memory = 1073217536 (1048064K bytes) avail memory = 1039532032 (1015168K bytes) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 -> irq 0 Programming 24 pins in IOAPIC #1 Programming 24 pins in IOAPIC #2 FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 0, version: 0x00050014, at 0xfee00000 cpu1 (AP): apic id: 6, version: 0x00050014, at 0xfee00000 cpu2 (AP): apic id: 1, version: 0x00050014, at 0xfee00000 cpu3 (AP): apic id: 7, version: 0x00050014, at 0xfee00000 io0 (APIC): apic id: 2, version: 0x00178020, at 0xfec00000 io1 (APIC): apic id: 3, version: 0x00178020, at 0xfec80000 io2 (APIC): apic id: 4, version: 0x00178020, at 0xfec80400 Preloaded elf kernel "kernel" at 0xc0411000. Preloaded elf module "if_fxp.ko" at 0xc041109c. Preloaded elf module "miibus.ko" at 0xc041113c. netsmb_dev: loaded Pentium Pro MTRR support enabled md0: Malloc disk Using $PIR table, 24 entries at 0xc00fde40 npx0: <math processor> on motherboard npx0: INT 16 interface pcib0: <Host to PCI bridge> on motherboard IOAPIC #0 intpin 16 -> irq 2 IOAPIC #0 intpin 19 -> irq 10 IOAPIC #0 intpin 18 -> irq 11 pci0: <PCI bus> on pcib0 pci0: <unknown card> (vendor=0x8086, dev=0x2541) at 0.1 pcib1: <PCI to PCI bridge (vendor=8086 device=2543)> at device 2.0 on pci0 pci1: <PCI bus> on pcib1 pci1: <unknown card> (vendor=0x8086, dev=0x1461) at 28.0 pcib2: <PCI to PCI bridge (vendor=8086 device=1460)> at device 29.0 on pci1 IOAPIC #2 intpin 0 -> irq 16 IOAPIC #2 intpin 1 -> irq 17 pci2: <PCI bus> on pcib2 pci2: <unknown card> (vendor=0x8086, dev=0x1010) at 1.0 irq 16 pci2: <unknown card> (vendor=0x8086, dev=0x1010) at 1.1 irq 17 pci1: <unknown card> (vendor=0x8086, dev=0x1461) at 30.0 pcib3: <PCI to PCI bridge (vendor=8086 device=1460)> at device 31.0 on pci1 IOAPIC #1 intpin 4 -> irq 18 IOAPIC #1 intpin 5 -> irq 19 IOAPIC #1 intpin 7 -> irq 20 pci3: <PCI bus> on pcib3 ahc0: <Adaptec aic7899 Ultra160 SCSI adapter> port 0x4000-0x40ff mem 0xfc340000-0xfc340fff irq 18 at device 2.0 on pci3 aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs ahc1: <Adaptec aic7899 Ultra160 SCSI adapter> port 0x4400-0x44ff mem 0xfc341000-0xfc341fff irq 19 at device 2.1 on pci3 aic7899: Ultra160 Wide Channel B, SCSI Id=15, 32/253 SCBs pci3: <unknown card> (vendor=0x8086, dev=0x100d) at 4.0 irq 20 uhci0: <Intel 82801CA/CAM (ICH3) USB controller USB-A> port 0x2000-0x201f irq 2 at device 29.0 on pci0 usb0: <Intel 82801CA/CAM (ICH3) USB controller USB-A> on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: <Intel 82801CA/CAM (ICH3) USB controller USB-B> port 0x2020-0x203f irq 10 at device 29.1 on pci0 usb1: <Intel 82801CA/CAM (ICH3) USB controller USB-B> on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: <Intel 82801CA/CAM (ICH3) USB controller USB-C> port 0x2040-0x205f irq 11 at device 29.2 on pci0 usb2: <Intel 82801CA/CAM (ICH3) USB controller USB-C> on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered pcib4: <Intel 82801BA/BAM (ICH2) Hub to PCI bridge> at device 30.0 on pci0 IOAPIC #0 intpin 17 -> irq 21 pci4: <PCI bus> on pcib4 pci4: <ATI Mach64-GR graphics accelerator> at 1.0 irq 2 fxp0: <Intel Pro 10/100B/100+ Ethernet> port 0x5400-0x543f mem 0xfc420000-0xfc43ffff,0xfc401000-0xfc401fff irq 21 at device 2.0 on pci4 fxp0: Ethernet address 00:30:48:12:36:07 inphy0: <i82555 10/100 media interface> on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto isab0: <PCI to ISA bridge (vendor=8086 device=2480)> at device 31.0 on pci0 isa0: <ISA bus> on isab0 atapci0: <Intel ICH3 ATA100 controller> port 0x2060-0x206f,0x374-0x377,0x170-0x177,0x3f4-0x3f7,0x1f0-0x1f7 mem 0xfc000000-0xfc0003ff irq 0 at device 31.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 ichsmb0: <Intel 82801CA (ICH3) SMBus controller> port 0x1100-0x111f irq 0 at device 31.3 on pci0 pci_cfgintr_search: linked (61) to configured irq 21 at 4:2:0 pci_cfgintr: 0:31 INTB routed to irq 21 smbus0: <System Management Bus> on ichsmb0 smb0: <SMBus general purpose I/O> on smbus0 orm0: <Option ROMs> at iomem 0xc0000-0xc7fff,0xc8000-0xc8fff,0xce800-0xcf7ff,0xcf800-0xd07ff,0xdc000-0xdf fff,0xe0000-0xe3fff on isa0 fdc0: <NEC 72065B or clone> at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 atkbdc0: <Keyboard controller (i8042)> at port 0x60,0x64 on isa0 vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 sc0: <System console> at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x100> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A, console sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A APIC_IO: Testing 8254 interrupt delivery APIC_IO: routing 8254 via IOAPIC #0 intpin 2 BRIDGE 020214 loaded DUMMYNET initialized (011031) ipfw2 initialized, divert enabled, rule-based forwarding enabled, default to accept, logging disabled SMP: AP CPU #3 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #1 Launched! acd0: CDROM <MATSHITA CR-177> at ata1-master PIO4 Waiting 2 seconds for SCSI devices to settle pass1 at ahc0 bus 0 target 6 lun 0 pass1: <SUPER GEM318 0> Fixed Processor SCSI-2 device pass1: 3.300MB/s transfers da0 at ahc0 bus 0 target 0 lun 0 da0: <SEAGATE ST318452LC 0004> Fixed Direct Access SCSI-3 device da0: 160.000MB/s transfers (80.000MHz, offset 63, 16bit), Tagged Queueing Enabled da0: 17501MB (35843670 512 byte sectors: 255H 63S/T 2231C) Mounting root from ufs:/dev/da0s1a da0: raw partition size != slice size da0: start 63, end 1638629, size 1638567 da0c: start 63, end 1558304, size 1558242 WARNING: / was not properly dismounted bash-2.05a# --don (don@sandvine.com www.sandvine.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 22 19:57: 7 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 194C737B401; Tue, 22 Oct 2002 19:57:05 -0700 (PDT) Received: from mail.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5A75D43E3B; Tue, 22 Oct 2002 19:57:04 -0700 (PDT) (envelope-from don@sandvine.com) Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19) id <42S9VFG0>; Tue, 22 Oct 2002 22:57:03 -0400 Message-ID: <FE045D4D9F7AED4CBFF1B3B813C8533701022D2E@mail.sandvine.com> From: Don Bowman <don@sandvine.com> To: Don Bowman <don@sandvine.com>, "'freebsd-stable@freebsd.org'" <freebsd-stable@freebsd.org>, "'freebsd-net@freebsd.org'" <freebsd-net@freebsd.org> Subject: RE: panic with ipfw / dummynet in 4.7 STABLE Date: Tue, 22 Oct 2002 22:56:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org > From: Don Bowman [mailto:don@sandvine.com] > Take a 4.7 image. Using if_em (if it matters). Turn on > bridging (em0, em2), add these ipfw rules: ... Here's the same thing again with -g on. #0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:487 #1 0xc01b1783 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:316 #2 0xc01b1bdc in poweroff_wait (junk=0xc032b319, howto=-1070420497) at /usr/src/sys/kern/kern_shutdown.c:595 #3 0xc02cb508 in trap_fatal (frame=0xff807c84, eva=48) at /usr/src/sys/i386/i386/trap.c:974 #4 0xc02cb199 in trap_pfault (frame=0xff807c84, usermode=0, eva=48) at /usr/src/sys/i386/i386/trap.c:867 #5 0xc02cad37 in trap (frame={tf_fs = 1714618392, tf_es = -8388592, tf_ds = -935985136, tf_edi = 0, tf_esi = -935921920, tf_ebp = -8356660, tf_isp = -8356688, tf_ebx = -1070251844, tf_edx = 1744882756, tf_ecx = -424745920, tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = -1071223279, tf_cs = 8, tf_eflags = 66054, tf_esp = -935921920, tf_ss = -935921920}) at /usr/src/sys/i386/i386/trap.c:466 #6 0xc0266e11 in acquire_lock (lk=0xc03540bc) at machine/globals.h:114 #7 0xc026af24 in softdep_update_inodeblock (ip=0xc836f700, bp=0xd49e0184, waitfor=0) at /usr/src/sys/ufs/ffs/ffs_softdep.c:3813 #8 0xc0265f45 in ffs_update (vp=0xe6aee440, waitfor=0) at /usr/src/sys/ufs/ffs/ffs_inode.c:106 #9 0xc026e357 in ffs_sync (mp=0xc82af600, waitfor=2, cred=0xc2066700, p=0xc0382120) at /usr/src/sys/ufs/ffs/ffs_vfsops.c:1025 #10 0xc01e29bf in sync (p=0xc0382120, uap=0x0) at /usr/src/sys/kern/vfs_syscalls.c:576 #11 0xc01b151e in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:235 #12 0xc01b1bdc in poweroff_wait (junk=0xc032b319, howto=-1070420497) at /usr/src/sys/kern/kern_shutdown.c:595 #13 0xc02cb508 in trap_fatal (frame=0xff807e74, eva=1073741831) at /usr/src/sys/i386/i386/trap.c:974 #14 0xc02cb199 in trap_pfault (frame=0xff807e74, usermode=0, eva=1073741831) at /usr/src/sys/i386/i386/trap.c:867 #15 0xc02cad37 in trap (frame={tf_fs = -935985128, tf_es = -8388592, tf_ds = -1071644656, tf_edi = -1039546112, tf_esi = -1039546112, tf_ebp = -8356132, tf_isp = -8356192, tf_ebx = 1073741823, tf_edx = 1073741823, tf_ecx = -935640092, tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = -1071626907, tf_cs = 8, tf_eflags = 66054, tf_esp = 24, tf_ss = -1039697888}) at /usr/src/sys/i386/i386/trap.c:466 #16 0xc0204565 in dummynet_io (m=0xc209c900, pipe_nr=1, dir=2, fwa=0xff807f34) at /usr/src/sys/netinet/ip_dummynet.c:1103 #17 0xc020991c in ip_input (m=0xc209c900) at /usr/src/sys/netinet/ip_input.c:459 #18 0xc0209ec7 in ipintr () at /usr/src/sys/netinet/ip_input.c:843 #19 0xc02bca91 in swi_net_next () (kgdb) l 1098 * this is a dummynet rule, so we expect a O_PIPE or O_QUEUE rule 1099 */ 1100 fs = locate_flowset(pipe_nr, fwa->rule); 1101 if (fs == NULL) 1102 goto dropit ; /* this queue/pipe does not exist! */ 1103 pipe = fs->pipe ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 1104 if (pipe == NULL) { /* must be a queue, try find a matching pipe */ 1105 for (pipe = all_pipes; pipe && pipe->pipe_nr != fs->parent_nr; 1106 pipe = pipe->next) 1107 ; (kgdb) p fs $1 = (struct dn_flow_set *) 0x3fffffff <<<<<<<< ILLEGAL VALUE (kgdb) p pipe_nr $6 = 1714618368 (kgdb) p/x pipe_nr $7 = 0x66330000 (kgdb) p/x fwa $8 = 0xff807f34 (kgdb) p/x fwa->rule $9 = 0xc83b43c0 (kgdb) p/x *fwa->rule $10 = {next = 0xc83c2900, next_rule = 0x0, act_ofs = 0x0, cmd_len = 0x4, rulenum = 0x154, set = 0x0, _pad = 0x0, pcnt = 0x1, bcnt = 0x20, timestamp = 0x3db60b9b, cmd = {{opcode = 0x29, len = 0x2, arg1 = 0x0}}} (kgdb) --don (don@sandvine.com www.sandvine.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 22 20:53:58 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 099B137B401 for <freebsd-net@freebsd.org>; Tue, 22 Oct 2002 20:53:57 -0700 (PDT) Received: from vineyard.net (K1.VINEYARD.NET [204.17.195.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5D9FA43E6A for <freebsd-net@freebsd.org>; Tue, 22 Oct 2002 20:53:56 -0700 (PDT) (envelope-from ericx@vineyard.net) Received: from alice (loopback [127.0.0.1]) by vineyard.net (Postfix) with ESMTP id 68CF391F2D for <freebsd-net@freebsd.org>; Tue, 22 Oct 2002 23:53:45 -0400 (EDT) Message-ID: <009701c27a47$fb2d6c80$3ee380cc@alice> From: "Eric W. Bates" <ericx@vineyard.net> To: <freebsd-net@freebsd.org> Subject: debugging VLANs with tcpdump Date: Tue, 22 Oct 2002 23:55:09 -0400 Organization: Vineyard.NET, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org While using tcpdump to debug a new VLAN config, I noticed some problems and wanted to ask whether I was simply doing something wrong. I have 3 vlan interfaces attached to an fxp. The 3 vlan are bridged, but the fxp is not included in the group. The fxp has no IP. vlan0 has the IP for the bridge group. fxp0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500 ether 00:02:b3:5b:dd:98 media: Ethernet autoselect (100baseTX <full-duplex>) status: active vlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet 192.168.10.1 netmask 0xffffff00 broadcast 192.168.10.255 ether 00:02:b3:5b:dd:98 vlan: 5 parent interface: fxp0 lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384 inet 127.0.0.1 netmask 0xff000000 vlan1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 ether 00:02:b3:5b:dd:98 vlan: 10 parent interface: fxp0 vlan2: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 ether 00:02:b3:5b:dd:98 vlan: 20 parent interface: fxp0 I get the most useful information when I run tcpdump on the fxp. Doing so shows all the packets passing by the NIC and it labels VLAN packets with their tag. tcpdump -i fxp0 20:00:54.747032 802.1Q vlan#10 P0 192.168.10.98 > 192.168.10.1: icmp: echo request (ttl 32, id 232, len 60) 20:00:54.747210 802.1Q vlan#10 P0 192.168.10.1 > 192.168.10.98: icmp: echo reply (ttl 64, id 22505, len 60) As soon as I add an expression to the tcpdump, I lose the VLAN labels from the output. I tried: tcpdump -i fxp0 icmp tcpdump -i fxp0 vlan tcpdump -i fxp0 host fw.mvhost.com I also tried increasing verbosity (-vvv). Attaching tcpdump to a vlan was interesting. Presumably I was seeing only packets tagged with the pseudo-interface's VLAN ID; but the labels were gone again. Is this a bug? If not, how do I display the explicit tag information under more circumstances? Thanks for your time. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Oct 23 10:25:58 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 377F837B401; Wed, 23 Oct 2002 10:25:55 -0700 (PDT) Received: from inje.iskon.hr (inje.iskon.hr [213.191.128.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F38143E42; Wed, 23 Oct 2002 10:25:49 -0700 (PDT) (envelope-from zec@tel.fer.hr) Received: from tel.fer.hr (zg04-116.dialin.iskon.hr [213.191.137.117]) by mail.iskon.hr (8.11.4/8.11.4/Iskon 8.11.3-1) with ESMTP id g9NHOnE15127; Wed, 23 Oct 2002 19:24:53 +0200 (MEST) Message-ID: <3DB6DB7B.F1184FC@tel.fer.hr> Date: Wed, 23 Oct 2002 19:25:15 +0200 From: Marko Zec <zec@tel.fer.hr> X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bill Coutinho <bill.coutinho@dextra.com.br> Cc: freebsd-arch@freebsd.org, freebsd-net@freebsd.org Subject: Re: BSD network stack virtualization + IEEE 802.1Q References: <NEBBKGFCALOCPEPBDDBCKENFDIAA.bill.coutinho@dextra.com.br> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org Bill Coutinho wrote: > Sean Chittenden, in FreeBSD-Arch list, pointed me to your "BSD network stack > virtualization" site. > > What I'm trying to achieve is one box with many independent "virtual > servers" (using the Jail subsystem), but with each vistual server attached > to a different VLAN using the same physical NIC. This NIC should be > connected to a switch with the 802.1Q protocol. > > My question is: is it possible to associate a "virtual stack" to a VLAN > number in a 802.1Q enabled net interface, and combine it with the Jail > subsystem "struct jail"? Yes, you can do that with the virtualized network stack very easily, but without using jail(8). Here is a sample step-by-step example, which I hope accomplishes what you want: First, we have to create two new virtual images. Here we also set the hostnames for the new vimages, which is of course not the mandatory step, but makes things more comprehensible: tpx30# vimage -c my_virtual_node1 tpx30# vimage -c my_virtual_node2 tpx30# vimage my_virtual_node1 hostname node1 tpx30# vimage my_virtual_node2 hostname node2 We the create two vlan interfaces, and associate them with the physical ifc and vlan tags: tpx30# ifconfig vlan create vlan0 tpx30# ifconfig vlan create vlan1 tpx30# ifconfig vlan0 vlan 1001 vlandev fxp0 tpx30# ifconfig vlan1 vlan 1002 vlandev fxp0 tpx30# ifconfig fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet 192.168.201.130 netmask 0xffffff00 broadcast 192.168.201.255 ether 00:09:6b:e0:d5:fc media: Ethernet autoselect (10baseT/UTP) status: active vlan0: flags=8842<BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 ether 00:09:6b:e0:d5:fc vlan: 1001 parent interface: fxp0 vlan1: flags=8842<BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 ether 00:09:6b:e0:d5:fc vlan: 1002 parent interface: fxp0 lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384 inet 127.0.0.1 netmask 0xff000000 tpx30# Further, we move (reassign) the vlan interfaces to the appropriate virtual images. The vlan ifcs will disappear from the current (master) virtual image: tpx30# vimage -i my_virtual_node1 vlan0 tpx30# vimage -i my_virtual_node2 vlan1 tpx30# ifconfig fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet 192.168.201.130 netmask 0xffffff00 broadcast 192.168.201.255 ether 00:09:6b:e0:d5:fc media: Ethernet autoselect (10baseT/UTP) status: active lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384 inet 127.0.0.1 netmask 0xff000000 tpx30# Now we spawn a new interactive shell in one of the created virtual images. We can now manage the interfaces in the usual way, start new processes/daemons, configure ipfw... tpx30# vimage my_virtual_node1 Switched to vimage my_virtual_node1 node1# ifconfig vlan0 1.2.3.4 node1# ifconfig vlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet 1.2.3.4 netmask 0xff000000 broadcast 1.255.255.255 ether 00:09:6b:e0:d5:fc vlan: 1001 parent interface: fxp0@master lo0: flags=8008<LOOPBACK,MULTICAST> mtu 16384 node1# inetd node1# exit Note that you won`t be able to change the vlan tag and/or parent interface inside the virtual image where vlan interface resides, but only in the virtual image that contains the physical interface (that was the "master" vimage in this example). Finally, here is the summary output from vimage -l command issued in the master virtual image: tpx30# vimage -l "master": 37 processes, load averages: 0.00, 0.02, 0.00 CPU usage: 0.26% (0.26% user, 0.00% nice, 0.00% system) Nice level: 0, no CPU limit, no process limit, child limit: 15 2 network interfaces, 2 child vimages "my_virtual_node2": 0 processes, load averages: 0.00, 0.00, 0.00 CPU usage: 0.00% (0.00% user, 0.00% nice, 0.00% system) Nice level: 0, no CPU limit, no process limit 2 network interfaces, parent vimage: "master" "my_virtual_node1": 1 processes, load averages: 0.00, 0.00, 0.00 CPU usage: 0.24% (0.20% user, 0.00% nice, 0.04% system) Nice level: 0, no CPU limit, no process limit 2 network interfaces, parent vimage: "master" Hope this helps, Marko To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Oct 23 11:41:27 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 041F537B401 for <freebsd-net@freebsd.org>; Wed, 23 Oct 2002 11:41:26 -0700 (PDT) Received: from vineyard.net (K1.VINEYARD.NET [204.17.195.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4BA9443E42 for <freebsd-net@freebsd.org>; Wed, 23 Oct 2002 11:41:25 -0700 (PDT) (envelope-from ericx@vineyard.net) Received: by vineyard.net (Postfix, from userid 0) id 3980891F68; Wed, 23 Oct 2002 14:41:19 -0400 (EDT) To: freebsd-net@freebsd.org Subject: VLAN problems with replies to broadcast From: Charlie Root <ericx@vineyard.net> Reply-To: Charlie Root <ericx@vineyard.net> Date: Wed, 23 Oct 2002 14:41:19 -0400 Message-Id: <20021023184119.3980891F68@vineyard.net> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org We have built a machine with 3 vlan parenting off an fxp. The vlan are bridged and vlan0 has an IP. The fxp has no IP and is excluded from the bridge group. ** root@fw ** ~ ** Sat Oct 19 18:38:08 # ifconfig fxp0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500 ether 00:02:b3:5b:dd:98 media: Ethernet autoselect (100baseTX <full-duplex>) status: active vlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet 192.168.10.1 netmask 0xffffff00 broadcast 192.168.10.255 ether 00:02:b3:5b:dd:98 vlan: 5 parent interface: fxp0 lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384 inet 127.0.0.1 netmask 0xff000000 vlan1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 ether 00:02:b3:5b:dd:98 vlan: 10 parent interface: fxp0 vlan2: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 ether 00:02:b3:5b:dd:98 vlan: 20 parent interface: fxp0 The fxp is plugged into an SMC Tigerswitch. The SMC is configured to pass VLAN's 5, 10 and 20. Everything works except replies to broadcast packets. e.g. using tcpdump I observe an arp request coming from the SMC switch. tcpdump reports that there are 3 packets (one tagged with each VLAN -- not clear whether there really are 3 distinct packets or whether tcpdump is make a best-effort to report a broadcast packet). tcpdump also displays a single reply tagged with the one correct VLAN (the remote host's traffic is tagged by the SMC). The remote host does not receive the reply. Presumably the SMC is not forwarding the packet. The same behaviour is observable for dhcp requests. Is there some reason why a packet sent in reply from a VLAN interface might be tagged differently such that the SMC would refuse it? Has anyone else observed such behaviour? Can anyone suggest some tests I might try or further reading? Thank you for your time. --ericx To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Oct 23 11:41:49 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 91EA237B401 for <freebsd-net@freebsd.org>; Wed, 23 Oct 2002 11:41:48 -0700 (PDT) Received: from yama.geminisolutions.com (yama.geminisolutions.com [216.57.214.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id A80CC43E6A for <freebsd-net@freebsd.org>; Wed, 23 Oct 2002 11:41:44 -0700 (PDT) (envelope-from michael@staff.openaccess.org) Received: from [192.168.4.254] (internal.openaccess.org [216.57.214.120]) by yama.geminisolutions.com (8.12.3/8.11.6) with ESMTP id g9NIZAAo086855 for <freebsd-net@freebsd.org>; Wed, 23 Oct 2002 11:35:11 -0700 (PDT) (envelope-from michael@staff.openaccess.org) User-Agent: Microsoft-Entourage/10.0.0.1309 Date: Wed, 23 Oct 2002 11:41:44 -0700 Subject: Hostap mode and reboot From: Michael DeMan <michael@staff.openaccess.org> To: <freebsd-net@freebsd.org> Message-ID: <B9DC3B78.289FD%michael@staff.openaccess.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org Hi, We're running FBSD 4.6.2 in hostap mode to support a couple of wireless clients. The setup is pretty standard but there is one critical problem. If the hostap machine gets rebooted, the clients do not reconnect and we must also reboot them before they're back up. Has anybody else experienced this or know of any workarounds? Thanks, - Mike Michael F. DeMan Director of Technology OpenAccess Internet Services 1305 11th St., 3rd Floor Bellingham, WA 98225 Tel 360-647-0785 x204 Fax 360-738-9785 michael@staff.openaccess.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Oct 23 15:20:12 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A0D3837B40D for <freebsd-net@freebsd.org>; Wed, 23 Oct 2002 15:20:10 -0700 (PDT) Received: from sccrmhc03.attbi.com (sccrmhc03.attbi.com [204.127.202.63]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1EB2B43E4A for <freebsd-net@freebsd.org>; Wed, 23 Oct 2002 15:20:10 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by sccrmhc03.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20021023222009.XDBZ16403.sccrmhc03.attbi.com@InterJet.elischer.org>; Wed, 23 Oct 2002 22:20:09 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id PAA37568; Wed, 23 Oct 2002 15:18:14 -0700 (PDT) Date: Wed, 23 Oct 2002 15:18:13 -0700 (PDT) From: Julian Elischer <julian@elischer.org> To: Marko Zec <zec@tel.fer.hr> Cc: "J. 'LoneWolf' Mattsson" <lonewolf-freebsd@earthmagic.org>, freebsd-net@freebsd.org Subject: Re: RFC: BSD network stack virtualization In-Reply-To: <3DAE98B4.4058023A@tel.fer.hr> Message-ID: <Pine.BSF.4.21.0210231503010.36940-100000@InterJet.elischer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org I'm very impressed. I do however have some questions. (I have not read the code yet, just the writeup) 1/ How do you cope with each machine expecting to have it's own loopback interface? Is it sufficient to make lo1 lo2 lo3 etc. and attache them to the appropriate VMs? 2/ How much would be gained (i.e. is it worth it) to combine this with jail? Can you combine them? (does it work?) Does it make sense? 3/ You implemented this in 4.x which means that we need to reimplement it in -current before it has any chance of being 'included'. Do you think that would be abig problem? 5/ Does inclusion of the virtualisation have any measurable effect on throughputs for systems that are NOT using virtualisation. In other words, does the non Virtualised code-path get much extra work? (doi you have numbers?) (i.e. does it cost much for the OTHER users if we incorporated this into FreeBSD?) 6/ I think that your ng_dummy node is cute.. can I commit it separatly? (after porting it to -current..) 7/ the vmware image is a great idea. 8/ can you elaborate on the following: * hiding of "foreign" filesystem mounts within chrooted virtual images 9/ how does VIPA differ from the JAIL address binding? 10/ could you use ng_eiface instead of if_ve? 11/ why was ng_bridge unsuitable for your use? 12/ can you elaborate on the following: # fix netgraph interface node naming # fix the bugs in base networking code (statistics in "native" bridging, additional logic for ng_bridge...) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Oct 23 17:13:35 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C55FC37B401 for <net@freebsd.org>; Wed, 23 Oct 2002 17:13:18 -0700 (PDT) Received: from aaz.links.ru (aaz.links.ru [193.125.152.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3DC4843E6A for <net@freebsd.org>; Wed, 23 Oct 2002 17:13:17 -0700 (PDT) (envelope-from babolo@aaz.links.ru) Received: from aaz.links.ru (aaz.links.ru [193.125.152.37]) by aaz.links.ru (8.12.6/8.12.6) with ESMTP id g9O0DcDh081413 for <net@freebsd.org>; Thu, 24 Oct 2002 04:13:38 +0400 (MSD) (envelope-from babolo@aaz.links.ru) Received: (from babolo@localhost) by aaz.links.ru (8.12.6/8.12.6/Submit) id g9O0DcLT081412 for net@freebsd.org; Thu, 24 Oct 2002 04:13:38 +0400 (MSD) Message-Id: <200210240013.g9O0DcLT081412@aaz.links.ru> Subject: which resources ends with ste interface? X-ELM-OSV: (Our standard violations) hdr-charset=KOI8-R; no-hdr-encoding=1 To: net@freebsd.org Date: Thu, 24 Oct 2002 04:13:37 +0400 (MSD) From: "."@babolo.ru X-Mailer: ELM [version 2.4ME+ PL99b (25)] MIME-Version: 1.0 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org I have a router with 5 ste FX NIC and 1 xl TP NIC ste0 is upstream, one ste not used and all others are for home users net. after down/up ste0 works good. about 1 day or about 5..10 GByte, then some received packets delays for 1..2 seconds, then most received packets delays for 2..5 seconds, packet drop on receive drops. Transmit is good. Measured by ping between directly connected host and tcpdump on both, where instrument host has about zero traffic and has no problems (it is console server) User's ste interfaces works good after ifconfig down/up, and delays appear after massive arp scans, and usually such a scan stops interface, but state is UP. I have no instrumental host in that network, so I cant say, is tx functioning or not in that state. The good way to see breakage is tcpdump -npiste0 ether broadcast and not ip > & /some/file & (tcsh) and look in file after interface stops. It ends up with huge amount of arp requests on nonexistant hosts. I reprodused this breakage. 2 sec of intensive arp scanes leads to change ping time to one of users from usual 0..10 msec to 2..3 sec for at least 10 min after scan ends. I can't reproduce this reaction on arp scan on ste0, mean ping time do not change in or after scan time. But may be such a scan reduce time of good work of ste0. I can try to increase of arp scan time to test if need. So my question is: how can I found the cause? 0tw~(12)#netstat -m 391/1056/65536 mbufs in use (current/peak/max): 391 mbufs allocated to data 390/814/16384 mbuf clusters in use (current/peak/max) 1892 Kbytes allocated to network (3% of mb_map in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines I saw 3 times bigger peak values, but never saw values near the max. 0tw~(13)#uname -a FreeBSD tw 4.7-STABLE FreeBSD 4.7-STABLE #2: Wed Oct 16 05:37:50 MSD 2002 babolo@banny.pike.ru:/tmp/babolo/usr/src/sys/gw i386 dmesg exhausted by multiple arp: X attempts to modify permanent entry for Y on ste4 and ipfw: X Deny ... strings, so part of /var/log/all instead: Oct 23 16:18:39 tw /kernel: Copyright (c) 1992-2002 The FreeBSD Project. Oct 23 16:18:39 tw /kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Oct 23 16:18:39 tw /kernel: The Regents of the University of California. All rights reserved. Oct 23 16:18:39 tw /kernel: FreeBSD 4.7-STABLE #2: Wed Oct 16 05:37:50 MSD 2002 Oct 23 16:18:39 tw /kernel: babolo@banny.pike.ru:/tmp/babolo/usr/src/sys/gw Oct 23 16:18:39 tw /kernel: Calibrating clock(s) ... TSC clock: 865576478 Hz, i8254 clock: 1193259 Hz Oct 23 16:18:39 tw /kernel: CLK_USE_I8254_CALIBRATION not specified - using default frequency Oct 23 16:18:39 tw /kernel: Timecounter "i8254" frequency 1193182 Hz Oct 23 16:18:39 tw /kernel: CLK_USE_TSC_CALIBRATION not specified - using old calibration method Oct 23 16:18:39 tw /kernel: CPU: VIA C3 Samuel 2 (865.52-MHz 686-class CPU) Oct 23 16:18:39 tw /kernel: Origin = "CentaurHauls" Id = 0x678 Stepping = 8 Oct 23 16:18:39 tw /kernel: Features=0x803035<FPU,DE,TSC,MSR,MTRR,PGE,MMX> Oct 23 16:18:39 tw /kernel: real memory = 134152192 (131008K bytes) Oct 23 16:18:39 tw /kernel: Physical memory chunk(s): Oct 23 16:18:39 tw /kernel: 0x00001000 - 0x0009efff, 647168 bytes (158 pages) Oct 23 16:18:39 tw /kernel: 0x004d0000 - 0x07faffff, 128843776 bytes (31456 pages) Oct 23 16:18:39 tw /kernel: config> di adv0 Oct 23 16:18:39 tw /kernel: config> di aha0 Oct 23 16:18:39 tw /kernel: config> di aic0 Oct 23 16:18:39 tw /kernel: config> di bt0 Oct 23 16:18:39 tw /kernel: config> di cs0 Oct 23 16:18:39 tw /kernel: config> di ed0 Oct 23 16:18:39 tw /kernel: config> di fe0 Oct 23 16:18:39 tw /kernel: config> di fdc0 Oct 23 16:18:39 tw /kernel: config> di lnc0 Oct 23 16:18:39 tw /kernel: config> di sn0 Oct 23 16:18:39 tw /kernel: config> di sio2 Oct 23 16:18:39 tw /kernel: config> q Oct 23 16:18:39 tw /kernel: avail memory = 125022208 (122092K bytes) Oct 23 16:18:39 tw /kernel: bios32: Found BIOS32 Service Directory header at 0xc00fdb20 Oct 23 16:18:39 tw /kernel: bios32: Entry = 0xfdb30 (c00fdb30) Rev = 0 Len = 1 Oct 23 16:18:39 tw /kernel: pcibios: PCI BIOS entry at 0xdb51 Oct 23 16:18:39 tw /kernel: pnpbios: Found PnP BIOS data at 0xc00f6f70 Oct 23 16:18:39 tw /kernel: pnpbios: Entry = f0000:5fb4 Rev = 1.0 Oct 23 16:18:39 tw /kernel: Other BIOS signatures found: Oct 23 16:18:39 tw /kernel: ACPI: 000fc3e0 Oct 23 16:18:39 tw /kernel: Preloaded elf kernel "kernel" at 0xc04a9000. Oct 23 16:18:39 tw /kernel: Preloaded userconfig_script "/boot/kernel.conf" at 0xc04a90a8. Oct 23 16:18:39 tw /kernel: VESA: information block Oct 23 16:18:39 tw /kernel: 56 45 53 41 00 02 50 0b 00 c0 01 00 00 00 8b 0b Oct 23 16:18:39 tw /kernel: 00 c0 40 00 01 01 68 0b 00 c0 79 0b 00 c0 83 0b Oct 23 16:18:39 tw /kernel: 00 c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Oct 23 16:18:39 tw /kernel: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Oct 23 16:18:39 tw /kernel: VESA: 63 mode(s) found Oct 23 16:18:39 tw /kernel: VESA: v2.0, 4096k memory, flags:0x1, mode table:0xc00c0b8b (c0000b8b) Oct 23 16:18:39 tw /kernel: VESA: S3 Incorporated. 86C362 Oct 23 16:18:39 tw /kernel: VESA: S3 Incorporated. Trio3D/2X Rev C Oct 23 16:18:39 tw /kernel: pci_open(1): mode 1 addr port (0x0cf8) is 0x8000006c Oct 23 16:18:39 tw /kernel: pci_open(1a): mode1res=0x80000000 (0x80000000) Oct 23 16:18:39 tw /kernel: pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=30911106) Oct 23 16:18:39 tw /kernel: Using $PIR table, 10 entries at 0xc00f7590 Oct 23 16:18:39 tw /kernel: npx0: <math processor> on motherboard Oct 23 16:18:39 tw /kernel: npx0: INT 16 interface Oct 23 16:18:39 tw /kernel: pcib0: <Host to PCI bridge> on motherboard Oct 23 16:18:39 tw /kernel: found-> vendor=0x1106, dev=0x3091, revid=0x01 Oct 23 16:18:39 tw /kernel: class=06-00-00, hdrtype=0x00, mfdev=0 Oct 23 16:18:39 tw /kernel: subordinatebus=0 secondarybus=0 Oct 23 16:18:39 tw /kernel: map[10]: type 1, range 32, base e0000000, size 26 Oct 23 16:18:39 tw /kernel: found-> vendor=0x1106, dev=0xb091, revid=0x00 Oct 23 16:18:39 tw /kernel: class=06-04-00, hdrtype=0x01, mfdev=0 Oct 23 16:18:39 tw /kernel: subordinatebus=1 secondarybus=1 Oct 23 16:18:39 tw /kernel: found-> vendor=0x1186, dev=0x1002, revid=0x00 Oct 23 16:18:39 tw /kernel: class=02-00-00, hdrtype=0x00, mfdev=0 Oct 23 16:18:39 tw /kernel: subordinatebus=0 secondarybus=0 Oct 23 16:18:39 tw /kernel: intpin=a, irq=10 Oct 23 16:18:39 tw /kernel: map[10]: type 1, range 32, base 0000dc00, size 7 Oct 23 16:18:39 tw /kernel: map[14]: type 1, range 32, base dfffff80, size 7 Oct 23 16:18:39 tw /kernel: found-> vendor=0x1186, dev=0x1002, revid=0x00 Oct 23 16:18:39 tw /kernel: class=02-00-00, hdrtype=0x00, mfdev=0 Oct 23 16:18:39 tw /kernel: subordinatebus=0 secondarybus=0 Oct 23 16:18:39 tw /kernel: intpin=a, irq=11 Oct 23 16:18:39 tw /kernel: map[10]: type 1, range 32, base 0000d800, size 7 Oct 23 16:18:39 tw /kernel: map[14]: type 1, range 32, base dfffff00, size 7 Oct 23 16:18:39 tw /kernel: found-> vendor=0x1186, dev=0x1002, revid=0x00 Oct 23 16:18:39 tw /kernel: class=02-00-00, hdrtype=0x00, mfdev=0 Oct 23 16:18:39 tw /kernel: subordinatebus=0 secondarybus=0 Oct 23 16:18:39 tw /kernel: intpin=a, irq=12 Oct 23 16:18:39 tw /kernel: map[10]: type 1, range 32, base 0000d400, size 7 Oct 23 16:18:39 tw /kernel: map[14]: type 1, range 32, base dffffe80, size 7 Oct 23 16:18:39 tw /kernel: found-> vendor=0x1186, dev=0x1002, revid=0x00 Oct 23 16:18:39 tw /kernel: class=02-00-00, hdrtype=0x00, mfdev=0 Oct 23 16:18:39 tw /kernel: subordinatebus=0 secondarybus=0 Oct 23 16:18:39 tw /kernel: intpin=a, irq=5 Oct 23 16:18:39 tw /kernel: map[10]: type 1, range 32, base 0000d000, size 7 Oct 23 16:18:39 tw /kernel: map[14]: type 1, range 32, base dffffe00, size 7 Oct 23 16:18:39 tw /kernel: found-> vendor=0x1186, dev=0x1002, revid=0x00 Oct 23 16:18:39 tw /kernel: class=02-00-00, hdrtype=0x00, mfdev=0 Oct 23 16:18:39 tw /kernel: subordinatebus=0 secondarybus=0 Oct 23 16:18:39 tw /kernel: intpin=a, irq=10 Oct 23 16:18:39 tw /kernel: map[10]: type 1, range 32, base 0000cc00, size 7 Oct 23 16:18:39 tw /kernel: map[14]: type 1, range 32, base dffffd80, size 7 Oct 23 16:18:39 tw /kernel: found-> vendor=0x10b7, dev=0x9050, revid=0x00 Oct 23 16:18:39 tw /kernel: class=02-00-00, hdrtype=0x00, mfdev=0 Oct 23 16:18:39 tw /kernel: subordinatebus=0 secondarybus=0 Oct 23 16:18:39 tw /kernel: intpin=a, irq=11 Oct 23 16:18:39 tw /kernel: map[10]: type 1, range 32, base 0000c800, size 6 Oct 23 16:18:39 tw /kernel: found-> vendor=0x104c, dev=0x8020, revid=0x00 Oct 23 16:18:39 tw /kernel: class=0c-00-10, hdrtype=0x00, mfdev=0 Oct 23 16:18:39 tw /kernel: subordinatebus=0 secondarybus=0 Oct 23 16:18:39 tw /kernel: intpin=a, irq=12 Oct 23 16:18:39 tw /kernel: map[10]: type 1, range 32, base dffff000, size 11 Oct 23 16:18:39 tw /kernel: map[14]: type 1, range 32, base dfff8000, size 14 Oct 23 16:18:39 tw /kernel: found-> vendor=0x1106, dev=0x3074, revid=0x00 Oct 23 16:18:39 tw /kernel: class=06-01-00, hdrtype=0x00, mfdev=1 Oct 23 16:18:39 tw /kernel: subordinatebus=0 secondarybus=0 Oct 23 16:18:39 tw /kernel: found-> vendor=0x1106, dev=0x0571, revid=0x06 Oct 23 16:18:39 tw /kernel: class=01-01-8a, hdrtype=0x00, mfdev=0 Oct 23 16:18:39 tw /kernel: subordinatebus=0 secondarybus=0 Oct 23 16:18:39 tw /kernel: map[20]: type 1, range 32, base 0000ff00, size 4 Oct 23 16:18:39 tw /kernel: pci0: <PCI bus> on pcib0 Oct 23 16:18:39 tw /kernel: pcib1: <PCI to PCI bridge (vendor=1106 device=b091)> at device 1.0 on pci0 Oct 23 16:18:39 tw /kernel: found-> vendor=0x5333, dev=0x8a13, revid=0x02 Oct 23 16:18:39 tw /kernel: class=03-00-00, hdrtype=0x00, mfdev=0 Oct 23 16:18:39 tw /kernel: subordinatebus=0 secondarybus=0 Oct 23 16:18:39 tw /kernel: map[10]: type 1, range 32, base d8000000, size 26 Oct 23 16:18:39 tw /kernel: pci1: <PCI bus> on pcib1 Oct 23 16:18:39 tw /kernel: pci1: <S3 Trio3D/2X graphics accelerator> (vendor=0x5333, dev=0x8a13) at 0.0 Oct 23 16:18:39 tw /kernel: ste0: <D-Link DFE-550TX 10/100BaseTX> port 0xdc00-0xdc7f mem 0xdfffff80-0xdfffffff irq 10 at device 9.0 on pci0 Oct 23 16:18:39 tw /kernel: ste0: Ethernet address: 00:05:5d:f6:ac:57 Oct 23 16:18:39 tw /kernel: miibus0: <MII bus> on ste0 Oct 23 16:18:39 tw /kernel: acphy0: <AC101 10/100 media interface> on miibus0 Oct 23 16:18:39 tw /kernel: acphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX Oct 23 16:18:39 tw /kernel: bpf: ste0 attached Oct 23 16:18:39 tw /kernel: ste1: <D-Link DFE-550TX 10/100BaseTX> port 0xd800-0xd87f mem 0xdfffff00-0xdfffff7f irq 11 at device 10.0 on pci0 Oct 23 16:18:39 tw /kernel: ste1: Ethernet address: 00:05:5d:f6:ac:5b Oct 23 16:18:39 tw /kernel: miibus1: <MII bus> on ste1 Oct 23 16:18:39 tw /kernel: acphy1: <AC101 10/100 media interface> on miibus1 Oct 23 16:18:39 tw /kernel: acphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX Oct 23 16:18:39 tw /kernel: bpf: ste1 attached Oct 23 16:18:39 tw /kernel: ste2: <D-Link DFE-550TX 10/100BaseTX> port 0xd400-0xd47f mem 0xdffffe80-0xdffffeff irq 12 at device 11.0 on pci0 Oct 23 16:18:39 tw /kernel: ste2: Ethernet address: 00:05:5d:f6:af:f9 Oct 23 16:18:39 tw /kernel: miibus2: <MII bus> on ste2 Oct 23 16:18:39 tw /kernel: acphy2: <AC101 10/100 media interface> on miibus2 Oct 23 16:18:39 tw /kernel: acphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX Oct 23 16:18:39 tw /kernel: bpf: ste2 attached Oct 23 16:18:39 tw /kernel: ste3: <D-Link DFE-550TX 10/100BaseTX> port 0xd000-0xd07f mem 0xdffffe00-0xdffffe7f irq 5 at device 12.0 on pci0 Oct 23 16:18:39 tw /kernel: ste3: Ethernet address: 00:05:5d:f6:ad:ab Oct 23 16:18:39 tw /kernel: miibus3: <MII bus> on ste3 Oct 23 16:18:39 tw /kernel: acphy3: <AC101 10/100 media interface> on miibus3 Oct 23 16:18:39 tw /kernel: acphy3: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX Oct 23 16:18:39 tw /kernel: bpf: ste3 attached Oct 23 16:18:39 tw /kernel: ste4: <D-Link DFE-550TX 10/100BaseTX> port 0xcc00-0xcc7f mem 0xdffffd80-0xdffffdff irq 10 at device 13.0 on pci0 Oct 23 16:18:39 tw /kernel: using shared irq10. Oct 23 16:18:39 tw /kernel: ste4: Ethernet address: 00:05:5d:f6:b0:05 Oct 23 16:18:39 tw /kernel: miibus4: <MII bus> on ste4 Oct 23 16:18:39 tw /kernel: acphy4: <AC101 10/100 media interface> on miibus4 Oct 23 16:18:39 tw /kernel: acphy4: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX Oct 23 16:18:39 tw /kernel: bpf: ste4 attached Oct 23 16:18:39 tw /kernel: xl0: <3Com 3c905-TX Fast Etherlink XL> port 0xc800-0xc83f irq 11 at device 14.0 on pci0 Oct 23 16:18:39 tw /kernel: using shared irq11. Oct 23 16:18:39 tw /kernel: xl0: Ethernet address: 00:10:4b:31:8a:8e Oct 23 16:18:39 tw /kernel: xl0: media options word: e040 Oct 23 16:18:39 tw /kernel: xl0: found MII/AUTO Oct 23 16:18:39 tw /kernel: miibus5: <MII bus> on xl0 Oct 23 16:18:39 tw /kernel: nsphy0: <DP83840 10/100 media interface> on miibus5 Oct 23 16:18:39 tw /kernel: nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto Oct 23 16:18:39 tw /kernel: bpf: xl0 attached Oct 23 16:18:39 tw /kernel: pci0: <unknown card> (vendor=0x104c, dev=0x8020) at 15.0 irq 12 Oct 23 16:18:39 tw /kernel: viapropm0: SMBus I/O base at 0x400 Oct 23 16:18:39 tw /kernel: viapropm0: <VIA VT8233 Power Management Unit> port 0x400-0x40f at device 17.0 on pc i0 Oct 23 16:18:39 tw /kernel: viapropm0: SMBus revision code 0x0 Oct 23 16:18:39 tw /kernel: smb0: <SMBus general purpose I/O> on smbus0 Oct 23 16:18:39 tw /kernel: atapci0: <VIA 8233 ATA100 controller> port 0xff00-0xff0f at device 17.1 on pci0 Oct 23 16:18:39 tw /kernel: ata0: iobase=0x01f0 altiobase=0x03f6 bmaddr=0xff00 Oct 23 16:18:39 tw /kernel: ata0: mask=03 ostat0=50 ostat2=00 Oct 23 16:18:39 tw /kernel: ata0-master: ATAPI 00 00 Oct 23 16:18:39 tw /kernel: ata0-slave: ATAPI 00 00 Oct 23 16:18:39 tw /kernel: ata0: mask=03 stat0=50 stat1=00 Oct 23 16:18:39 tw /kernel: ata0-master: ATA 01 a5 Oct 23 16:18:39 tw /kernel: ata0: devices=01 Oct 23 16:18:39 tw /kernel: ata0: at 0x1f0 irq 14 on atapci0 Oct 23 16:18:39 tw /kernel: ata1: iobase=0x0170 altiobase=0x0376 bmaddr=0xff08 Oct 23 16:18:39 tw /kernel: ata1: mask=03 ostat0=50 ostat2=00 Oct 23 16:18:39 tw /kernel: ata1-master: ATAPI 00 00 Oct 23 16:18:39 tw /kernel: ata1-slave: ATAPI 00 00 Oct 23 16:18:39 tw /kernel: ata1: mask=03 stat0=50 stat1=00 Oct 23 16:18:39 tw /kernel: ata1-master: ATA 01 a5 Oct 23 16:18:39 tw /kernel: ata1: devices=01 Oct 23 16:18:39 tw /kernel: ata1: at 0x170 irq 15 on atapci0 Oct 23 16:18:39 tw /kernel: isa0: <ISA bus> on motherboard Oct 23 16:18:39 tw /kernel: ex_isa_identify() Oct 23 16:18:39 tw /kernel: ata-: ata0 exists, using next available unit number Oct 23 16:18:39 tw /kernel: ata-: ata1 exists, using next available unit number Oct 23 16:18:39 tw /kernel: Trying Read_Port at 203 Oct 23 16:18:39 tw /kernel: Trying Read_Port at 243 Oct 23 16:18:39 tw /kernel: Trying Read_Port at 283 Oct 23 16:18:39 tw /kernel: Trying Read_Port at 2c3 Oct 23 16:18:39 tw /kernel: Trying Read_Port at 303 Oct 23 16:18:39 tw /kernel: Trying Read_Port at 343 Oct 23 16:18:39 tw /kernel: Trying Read_Port at 383 Oct 23 16:18:39 tw /kernel: Trying Read_Port at 3c3 Oct 23 16:18:39 tw /kernel: isa_probe_children: disabling PnP devices Oct 23 16:18:39 tw /kernel: isa_probe_children: probing non-PnP devices Oct 23 16:18:39 tw /kernel: orm0: <Option ROM> at iomem 0xc0000-0xc7fff on isa0 Oct 23 16:18:39 tw /kernel: fdc0: not probed (disabled) Oct 23 16:18:39 tw /kernel: ata2 failed to probe at port 0x1f0 irq 14 on isa0 Oct 23 16:18:39 tw /kernel: ata3 failed to probe at port 0x170 irq 15 on isa0 Oct 23 16:18:39 tw /kernel: adv0: not probed (disabled) Oct 23 16:18:39 tw /kernel: bt0: not probed (disabled) Oct 23 16:18:39 tw /kernel: aha0: not probed (disabled) Oct 23 16:18:39 tw /kernel: aic0: not probed (disabled) Oct 23 16:18:39 tw /kernel: atkbdc0: <Keyboard controller (i8042)> at port 0x60,0x64 on isa0 Oct 23 16:18:39 tw /kernel: atkbd0: <AT Keyboard> irq 1 on atkbdc0 Oct 23 16:18:39 tw /kernel: atkbd: the current kbd controller command byte 0065 Oct 23 16:18:39 tw /kernel: atkbd: keyboard ID 0x41ab (2) Oct 23 16:18:39 tw /kernel: kbd0 at atkbd0 Oct 23 16:18:39 tw /kernel: kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 Oct 23 16:18:39 tw /kernel: psm0: current command byte:0065 Oct 23 16:18:39 tw /kernel: psm0: failed to reset the aux device. Oct 23 16:18:39 tw /kernel: vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Oct 23 16:18:39 tw /kernel: fb0: vga0, vga, type:VGA (5), flags:0x700ff Oct 23 16:18:39 tw /kernel: fb0: port:0x3c0-0x3df, crtc:0x3d4, mem:0xa0000 0x20000 Oct 23 16:18:39 tw /kernel: fb0: init mode:24, bios mode:3, current mode:24 Oct 23 16:18:39 tw /kernel: fb0: window:0xc00b8000 size:32k gran:32k, buf:0 size:32k Oct 23 16:18:39 tw /kernel: VGA parameters upon power-up Oct 23 16:18:39 tw /kernel: 50 18 10 00 00 00 03 00 02 67 5f 4f 50 82 55 81 Oct 23 16:18:39 tw /kernel: bf 1f 00 4f 0d 0e 00 00 05 50 9c 8e 8f 28 1f 96 Oct 23 16:18:39 tw /kernel: b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c Oct 23 16:18:39 tw /kernel: 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff Oct 23 16:18:39 tw /kernel: VGA parameters in BIOS for mode 24 Oct 23 16:18:39 tw /kernel: 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 Oct 23 16:18:39 tw /kernel: bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 Oct 23 16:18:39 tw /kernel: b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c Oct 23 16:18:39 tw /kernel: 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff Oct 23 16:18:39 tw /kernel: EGA/VGA parameters to be used for mode 24 Oct 23 16:18:39 tw /kernel: 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 Oct 23 16:18:39 tw /kernel: bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 Oct 23 16:18:39 tw /kernel: b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c Oct 23 16:18:39 tw /kernel: 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff Oct 23 16:18:39 tw /kernel: sc0: <System console> at flags 0x100 on isa0 Oct 23 16:18:39 tw /kernel: sc0: VGA <16 virtual consoles, flags=0x300> Oct 23 16:18:39 tw /kernel: sc0: fb0, kbd0, terminal emulator: sc (syscons terminal) Oct 23 16:18:39 tw /kernel: pcic0: not probed (disabled) Oct 23 16:18:39 tw /kernel: pcic1: not probed (disabled) Oct 23 16:18:39 tw /kernel: sio0: irq maps: 0x2001 0x2011 0x2001 0x2001 Oct 23 16:18:39 tw /kernel: sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 Oct 23 16:18:39 tw /kernel: sio0: type 16550A Oct 23 16:18:39 tw /kernel: sio1: irq maps: 0x2001 0x2009 0x2001 0x2001 Oct 23 16:18:39 tw /kernel: sio1 at port 0x2f8-0x2ff irq 3 on isa0 Oct 23 16:18:39 tw /kernel: sio1: type 16550A Oct 23 16:18:39 tw /kernel: sio2: not probed (disabled) Oct 23 16:18:39 tw /kernel: sio3: not probed (disabled) Oct 23 16:18:39 tw /kernel: dgb0: not probed (disabled) Oct 23 16:18:39 tw /kernel: ppc0: parallel port found at 0x378 Oct 23 16:18:39 tw /kernel: ppc0: using extended I/O port range Oct 23 16:18:39 tw /kernel: ppc0: ECP SPP ECP+EPP SPP Oct 23 16:18:39 tw /kernel: ppc0: <Parallel port> at port 0x378-0x37f irq 7 on isa0 Oct 23 16:18:39 tw /kernel: ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode Oct 23 16:18:39 tw /kernel: ppc0: FIFO with 16/16/9 bytes threshold Oct 23 16:18:39 tw /kernel: plip0: <PLIP network interface> on ppbus0 Oct 23 16:18:39 tw /kernel: bpf: lp0 attached Oct 23 16:18:39 tw /kernel: lpt0: <Printer> on ppbus0 Oct 23 16:18:39 tw /kernel: lpt0: Interrupt-driven port Oct 23 16:18:39 tw /kernel: ppi0: <Parallel I/O> on ppbus0 Oct 23 16:18:39 tw /kernel: vpo0: can't connect to the drive Oct 23 16:18:39 tw /kernel: imm0: (disconnect) s1=0x38 s2=0x38, s3=0x38 Oct 23 16:18:39 tw /kernel: imm0: (connect) s1=0x38 s2=0x38, s3=0x38 Oct 23 16:18:39 tw last message repeated 2 times Oct 23 16:18:39 tw /kernel: ed0: not probed (disabled) Oct 23 16:18:39 tw /kernel: fe0: not probed (disabled) Oct 23 16:18:39 tw /kernel: ie0 failed to probe at port 0x300 iomem 0xd0000 irq 10 on isa0 Oct 23 16:18:39 tw /kernel: lnc0: not probed (disabled) Oct 23 16:18:39 tw /kernel: cs0: not probed (disabled) Oct 23 16:18:39 tw /kernel: sn0: not probed (disabled) Oct 23 16:18:39 tw /kernel: pca0 at port 0x40 on isa0 Oct 23 16:18:39 tw /kernel: isa_probe_children: probing PnP devices Oct 23 16:18:39 tw /kernel: BIOS Geometries: Oct 23 16:18:39 tw /kernel: 0:03fefe3f 0..1022=1023 cylinders, 0..254=255 heads, 1..63=63 sectors Oct 23 16:18:39 tw /kernel: 0 accounted for Oct 23 16:18:39 tw /kernel: Device configuration finished. Oct 23 16:18:39 tw /kernel: bpf: lo0 attached Oct 23 16:18:39 tw /kernel: bpf: lo1 attached Oct 23 16:18:39 tw /kernel: bpf: lo2 attached Oct 23 16:18:39 tw /kernel: bpf: lo3 attached Oct 23 16:18:39 tw /kernel: bpf: ppp0 attached Oct 23 16:18:39 tw /kernel: new masks: bio 68c000, tty 63009a, net 671cba Oct 23 16:18:39 tw /kernel: bpf: ds0 attached Oct 23 16:18:39 tw /kernel: IPv6 packet filtering initialized, logging limited to 100 packets/entry Oct 23 16:18:39 tw /kernel: bpf: stf0 attached Oct 23 16:18:39 tw /kernel: DUMMYNET initialized (011031) Oct 23 16:18:39 tw /kernel: bpf: faith0 attached Oct 23 16:18:39 tw /kernel: ipfw2 initialized, divert enabled, rule-based forwarding enabled, default to accept , logging limited to 100 packets/entry by default Oct 23 16:18:39 tw /kernel: bpf: vlan0 attached Oct 23 16:18:39 tw /kernel: bpf: vlan1 attached Oct 23 16:18:39 tw /kernel: bpf: vlan2 attached Oct 23 16:18:39 tw /kernel: bpf: vlan3 attached Oct 23 16:18:39 tw /kernel: bpf: vlan4 attached Oct 23 16:18:39 tw /kernel: bpf: vlan5 attached Oct 23 16:18:39 tw /kernel: bpf: vlan6 attached Oct 23 16:18:39 tw /kernel: bpf: vlan7 attached Oct 23 16:18:39 tw /kernel: BRIDGE 020214 loaded Oct 23 16:18:39 tw /kernel: IP Filter: v3.4.29 initialized. Default = pass all, Logging = enabled Oct 23 16:18:39 tw /kernel: ad0: success setting UDMA5 on VIA chip Oct 23 16:18:39 tw /kernel: Creating DISK ad0 Oct 23 16:18:39 tw /kernel: ar: FreeBSD check1 failed Oct 23 16:18:39 tw /kernel: ad0: <SAMSUNG SV1021H/PJ100-21> ATA-6 disk at ata0-master Oct 23 16:18:39 tw /kernel: ad0: 9732MB (19932192 sectors), 19774 C, 16 H, 63 S, 512 B Oct 23 16:18:39 tw /kernel: ad0: 16 secs/int, 1 depth queue, UDMA100 Oct 23 16:18:39 tw /kernel: ad0: piomode=4 dmamode=2 udmamode=5 cblid=1 Oct 23 16:18:39 tw /kernel: ad2: success setting UDMA2 on VIA chip Oct 23 16:18:39 tw /kernel: Creating DISK ad2 Oct 23 16:18:39 tw /kernel: ar: FreeBSD check1 failed Oct 23 16:18:39 tw /kernel: ad2: <QUANTUM FIREBALL SE8.4A/API.0D00> ATA-3 disk at ata1-master Oct 23 16:18:39 tw /kernel: ad2: 8063MB (16514064 sectors), 16383 C, 16 H, 63 S, 512 B Oct 23 16:18:39 tw /kernel: ad2: 16 secs/int, 1 depth queue, UDMA33 Oct 23 16:18:39 tw /kernel: ad2: piomode=4 dmamode=2 udmamode=2 cblid=0 Oct 23 16:18:39 tw /kernel: Mounting root from ufs:/dev/ad0s1a Oct 23 16:18:39 tw /kernel: ad0s1: type 0xa5, start 127008, end = 16514063, size 16387056 : OK Oct 23 16:18:39 tw /kernel: ad0s4: type 0xa5, start 0, end = 127007, size 127008 : OK Oct 23 16:18:39 tw /kernel: start_init: trying /sbin/init Oct 23 16:18:39 tw /kernel: swapon: adding /dev/ad0s1b as swap device 141tw~(21)#strings /kernel | grep ^___ | sed -e 's|^___||' # # GENERIC -- Generic kernel configuration file for FreeBSD/i386 # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # # http://www.FreeBSD.org/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ./LINT configuration file. If you are # in doubt as to the purpose or necessity of a line, check first in LINT. # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.246.2.33 2001/07/30 17:31:40 wpaul Exp $ machine i386 #cpu I386_CPU #cpu I486_CPU cpu I586_CPU cpu I686_CPU #options CPU_SUSP_HLT options CPU_WT_ALLOC options NO_F00F_HACK ident gw maxusers 128 options MAXDSIZ="(512*1024*1024)" options INCLUDE_CONFIG_FILE # Include this file in kernel options MSGBUF_SIZE=262144 options NMBCLUSTERS=16384 options INVARIANTS options INVARIANT_SUPPORT options DIAGNOSTIC options AUTO_EOI_1 #options AUTO_EOI_2 makeoptions DEBUG=-g #Build kernel with gdb(1) debug symbols #options MATH_EMULATE #Support for x87 emulation options INET #InterNETworking options INET6 #IPv6 communications protocols options FFS #Berkeley Fast Filesystem options FFS_ROOT #FFS usable as root device [keep this!] options SOFTUPDATES #Enable FFS soft updates support options UFS_DIRHASH #Improve performance on big directories #options MFS #Memory Filesystem #options MD_ROOT #MD is a potential root device options NFS #Network Filesystem #options NFS_ROOT #NFS usable as root device, NFS required #options MSDOSFS #MSDOS Filesystem #options CD9660 #ISO 9660 Filesystem #options CD9660_ROOT #CD-ROM usable as root, CD9660 required options PROCFS #Process filesystem options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options SCSI_DELAY=15000 #Delay (in ms) before probing SCSI options UCONSOLE #Allow users to grab the console options USERCONFIG #boot -c editor options VISUAL_USERCONFIG #visual boot -c editor options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options SHMALL=16384 options SHMMAX="(SHMMAXPGS*PAGE_SIZE+1)" options SHMMAXPGS=8192 options SHMMIN=128 options SHMMNI=256 options SHMSEG=512 options NSWAPDEV=2 options P1003_1B #Posix P1003_1B real-time extensions options _KPOSIX_PRIORITY_SCHEDULING options ICMP_BANDLIM #Rate limit bad replies options KBD_INSTALL_CDEV # install a CDEV entry in /dev options USER_LDT #allow user-level control of i386 ldt options PERFMON options NETGRAPH #netgraph(4) system options MYLOOP_MASKLEN=24 options IPV6FIREWALL #firewall for IPv6 options IPV6FIREWALL_VERBOSE options IPV6FIREWALL_VERBOSE_LIMIT=100 options IPFIREWALL #firewall options IPFIREWALL_VERBOSE #print information about # dropped packets options IPFW2 options IPFIREWALL_FORWARD #enable transparent proxy support options IPFIREWALL_VERBOSE_LIMIT=100 #limit verbosity options IPFIREWALL_DEFAULT_TO_ACCEPT #allow everything by default options IPDIVERT #divert sockets options IPFILTER #ipfilter support options IPFILTER_LOG #ipfilter logging options IPSTEALTH #support for stealth forwarding options RANDOM_IP_ID options DUMMYNET options BRIDGE # To make an SMP kernel, the next two are needed #options SMP # Symmetric MultiProcessor Kernel #options APIC_IO # Symmetric (APIC) I/O device isa #device eisa device pci # Floppy drives device fdc0 at isa? port IO_FD1 irq 6 drq 2 device fd0 at fdc0 drive 0 device fd1 at fdc0 drive 1 # ATA and ATAPI devices device ata0 at isa? port IO_WD1 irq 14 device ata1 at isa? port IO_WD2 irq 15 device ata device atadisk # ATA disk drives device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives device atapist # ATAPI tape drives options ATA_STATIC_ID #Static device numbering # SCSI Controllers device ahc # AHA2940 and onboard AIC7xxx devices options AHC_ALLOW_MEMIO device amd # AMD 53C974 (Tekram DC-390(T)) device isp # Qlogic family device ncr # NCR/Symbios Logic device sym # NCR/Symbios Logic (newer chipsets) options SYM_SETUP_LP_PROBE_MAP=0x40 # Allow ncr to attach legacy NCR devices when # both sym and ncr are configured device adv0 at isa? device adw device bt0 at isa? device aha0 at isa? device aic0 at isa? # SCSI peripherals device scbus # SCSI bus (required) device da # Direct Access (disks) device sa # Sequential Access (tape etc) device cd # CD device pass # Passthrough device (direct SCSI access) # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc0 at isa? port IO_KBD device atkbd0 at atkbdc? irq 1 device psm0 at atkbdc? irq 12 device vga0 at isa? options VGA_WIDTH90 # support 90 column modes options VESA # splash screen/screen saver pseudo-device splash # syscons is the default console driver, resembling an SCO console device sc0 at isa? flags 0x100 options SC_HISTORY_SIZE=2118 # number of history buffer lines options SC_MOUSE_CHAR=0x3 # char code for text mode mouse cursor options SC_NORM_ATTR="(FG_BROWN|BG_BLACK)" options SC_NORM_REV_ATTR="(FG_BLACK|BG_RED)" options SC_KERNEL_CONS_ATTR="(FG_YELLOW|BG_BROWN)" options SC_KERNEL_CONS_REV_ATTR="(FG_WHITE|BG_RED)" # Enable this and PCVT_FREEBSD for pcvt vt220 compatible console driver #device vt0 at isa? #options XSERVER # support for X server on a vt console #options FAT_CURSOR # start with block cursor # If you have a ThinkPAD, uncomment this along with the rest of the PCVT lines #options PCVT_SCANSET=2 # IBM keyboards are non-std # Floating point support - do not disable. device npx0 at nexus? port IO_NPX irq 13 # Power management support (see LINT for more options) device apm0 at nexus? disable flags 0x20 # Advanced Power Management # PCCARD (PCMCIA) support device card device pcic0 at isa? irq 0 port 0x3e0 iomem 0xd0000 disable device pcic1 at isa? irq 0 port 0x3e2 iomem 0xd4000 disable # Serial (COM) ports options CONSPEED=115200 options COM_MULTIPORT #code for some cards with shared IRQs device sio0 at isa? port IO_COM1 flags 0x10 irq 4 device sio1 at isa? port IO_COM2 irq 3 device sio2 at isa? port IO_COM3 irq 5 device sio3 at isa? disable port IO_COM4 irq 9 device dgb0 at isa? disable port 0x320 iomem 0xc0000 flags 0x01 options NDGBPORTS=8 # Defaults to 16*NDGB #device dgm0 at isa? port 0x104 iomem 0xd0000 flags 0x01 # Parallel port device ppc0 at isa? irq 7 device ppbus # Parallel port bus (required) device lpt # Printer device plip # TCP/IP over parallel device ppi # Parallel port interface device device vpo # Requires scbus and da device lpbb #Philips parallel port I2C bit-banging interface options DEVICE_POLLING # PCI Ethernet NICs. device de # DEC/Intel DC21x4x (``Tulip'') device txp # 3Com 3cR990 (``Typhoon'') device vx # 3Com 3c590, 3c595 (``Vortex'') # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! device miibus # MII bus support device dc # DEC/Intel 21143 and various workalikes device fxp # Intel EtherExpress PRO/100B (82557, 82558) device pcn # AMD Am79C97x PCI 10/100 NICs device rl # RealTek 8129/8139 device sf # Adaptec AIC-6915 (``Starfire'') device sis # Silicon Integrated Systems SiS 900/SiS 7016 device ste # Sundance ST201 (D-Link DFE-550TX) device tl # Texas Instruments ThunderLAN device tx # SMC EtherPower II (83c170 ``EPIC'') device vr # VIA Rhine, Rhine II device wb # Winbond W89C840F device wx # Intel Gigabit Ethernet Card (``Wiseman'') device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') device bge # Broadcom BCM570x (``Tigon III'') # ISA Ethernet NICs. # 'device ed' requires 'device miibus' device ed0 at isa? port 0x280 irq 10 iomem 0xd8000 device ex device ep device fe0 at isa? port 0x300 # Xircom Ethernet device xe # PRISM I IEEE 802.11b wireless NIC. device awi # WaveLAN/IEEE 802.11 wireless NICs. Note: the WaveLAN/IEEE really # exists only as a PCMCIA device, so there is no ISA attachment needed # and resources will always be dynamically assigned by the pccard code. device wi # Aironet 4500/4800 802.11 wireless NICs. Note: the declaration below will # work for PCMCIA and PCI cards, as well as ISA cards set to ISA PnP # mode (the factory default). If you set the switches on your ISA # card for a manually chosen I/O address and IRQ, you must specify # those parameters here. device an # The probe order of these is presently determined by i386/isa/isa_compat.c. device ie0 at isa? port 0x300 irq 10 iomem 0xd0000 #device le0 at isa? port 0x300 irq 5 iomem 0xd0000 device lnc0 at isa? port 0x280 irq 10 drq 0 device cs0 at isa? port 0x300 device sn0 at isa? port 0x300 irq 10 # Pseudo devices - the number indicates how many units to allocate. pseudo-device loop 4 # Network loopback pseudo-device ether # Ethernet support pseudo-device vlan 8 #VLAN support #pseudo-device sl 4 # Kernel SLIP pseudo-device ppp 1 # Kernel PPP options PPP_BSDCOMP #PPP BSD-compress support options PPP_DEFLATE #PPP zlib/deflate/gzip support options PPP_FILTER #enable bpf filtering (needs bpf) pseudo-device tun 4 # Packet tunnel. pseudo-device pty # Pseudo-ttys (telnet etc) #pseudo-device md # Memory "disks" pseudo-device gif # IPv6 and IPv4 tunneling pseudo-device faith 1 # IPv6-to-IPv4 relaying (translation) pseudo-device stf 1 #6to4 IPv6 over IPv4 encapsulation pseudo-device speaker #Play IBM BASIC-style noises out your speaker pseudo-device gzip #Exec gzipped a.out's pseudo-device disc #Discard device (ds0, ds1, etc) # The `bpf' pseudo-device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! pseudo-device bpf 32 #Berkeley packet filter # USB support #device uhci # UHCI PCI->USB interface #device ohci # OHCI PCI->USB interface #device usb # USB Bus (required) #device ugen # Generic #device uhid # "Human Interface Devices" #device ukbd # Keyboard #device ulpt # Printer #device umass # Disks/Mass storage - Requires scbus and da #device umodem # USB modem support #device ums # Mouse #device uscanner # USB scanners # USB Ethernet, requires mii #device aue # ADMtek USB ethernet #device cue # CATC USB ethernet #device kue # Kawasaki LSI USB ethernet #device pcm device pca0 at isa? port IO_TIMER1 device smbus device intpm device alpm device viapm device ichsmb device smb device iicbus device iicbb device ic device iic device iicsmb # smb over i2c bridge 0tw~(22)#cat /etc/sysctl.conf # $FreeBSD: src/etc/sysctl.conf,v 1.1.2.3 2002/04/15 00:44:13 dougb Exp $ # # This file is read when going to multi-user and its contents piped thru # ``sysctl'' to adjust kernel values. ``man 5 sysctl.conf'' for details. # vfs.nfs.gatherdelay=0 vfs.nfs.async=1 kern.ipc.somaxconn=1024 kern.ipc.maxsockbuf=1048576 kern.polling.enable=1 vfs.vmiodirenable=1 net.inet.raw.recvspace=65536 net.inet.ip.fastforwarding=0 net.inet.ip.ttl=59 net.inet.ip.fw.one_pass=0 #net.inet.tcp.sendspace=65536 #net.inet.tcp.recvspace=65536 net.link.ether.inet.proxyall=1 debug.bpf_bufsize=524288 net.inet.ip.redirect=0 Lot of static arps, ipfw rules and routes to ds0 Sorry, my English is bad. -- @BABOLO http://links.ru/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Oct 23 17:29:38 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3A35A37B401 for <net@freebsd.org>; Wed, 23 Oct 2002 17:29:20 -0700 (PDT) Received: from yama.geminisolutions.com (yama.geminisolutions.com [216.57.214.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id EC6FD43E3B for <net@freebsd.org>; Wed, 23 Oct 2002 17:29:15 -0700 (PDT) (envelope-from michael@staff.openaccess.org) Received: from [192.168.4.254] (internal.openaccess.org [216.57.214.120]) by yama.geminisolutions.com (8.12.3/8.11.6) with ESMTP id g9O0MTAo091006; Wed, 23 Oct 2002 17:22:29 -0700 (PDT) (envelope-from michael@staff.openaccess.org) User-Agent: Microsoft-Entourage/10.0.0.1309 Date: Wed, 23 Oct 2002 17:29:06 -0700 Subject: Re: which resources ends with ste interface? From: Michael DeMan <michael@staff.openaccess.org> To: <"."@babolo.ru>, <net@freebsd.org> Message-ID: <B9DC8CE2.28A6A%michael@staff.openaccess.org> In-Reply-To: <200210240013.g9O0DcLT081412@aaz.links.ru> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org We have a nightmare situation with DFE-580TX 4-port cards that use the ste driver. The driver seems to just choke. I'm not sure if its an issue with PCI interrupts or what. It throttles back the time-outs, but even then after its been up for days one of the interfaces will start acting up and our LAN seems more like an ISDN to the file server. On 10/23/02 5:13 PM, ""."@babolo.ru" <"."@babolo.ru> wrote: > > I have a router with 5 ste FX NIC > and 1 xl TP NIC > > ste0 is upstream, one ste not used and > all others are for home users net. > > after down/up ste0 works good. > about 1 day or about 5..10 GByte, > then some received packets delays > for 1..2 seconds, then most received > packets delays for 2..5 seconds, > packet drop on receive drops. > Transmit is good. > Measured by ping between directly > connected host and tcpdump on both, > where instrument host has about zero traffic > and has no problems (it is console server) > > User's ste interfaces works good after > ifconfig down/up, and delays appear > after massive arp scans, and usually > such a scan stops interface, > but state is UP. > > I have no instrumental host in that > network, so I cant say, is tx functioning > or not in that state. > > The good way to see breakage is > tcpdump -npiste0 ether broadcast and not ip > & /some/file & > (tcsh) and look in file after interface stops. > It ends up with huge amount of arp requests on > nonexistant hosts. > I reprodused this breakage. > 2 sec of intensive arp scanes leads > to change ping time to one of users > from usual 0..10 msec to 2..3 sec for at least > 10 min after scan ends. > > I can't reproduce this reaction on arp scan on ste0, > mean ping time do not change in or after scan time. > But may be such a scan reduce time of good > work of ste0. I can try to increase of arp > scan time to test if need. > > So my question is: how can I found the cause? > 0tw~(12)#netstat -m > 391/1056/65536 mbufs in use (current/peak/max): > 391 mbufs allocated to data > 390/814/16384 mbuf clusters in use (current/peak/max) > 1892 Kbytes allocated to network (3% of mb_map in use) > 0 requests for memory denied > 0 requests for memory delayed > 0 calls to protocol drain routines > > I saw 3 times bigger peak values, but > never saw values near the max. > > 0tw~(13)#uname -a > FreeBSD tw 4.7-STABLE FreeBSD 4.7-STABLE #2: Wed Oct 16 05:37:50 MSD 2002 > babolo@banny.pike.ru:/tmp/babolo/usr/src/sys/gw i386 > > dmesg exhausted by multiple > arp: X attempts to modify permanent entry for Y on ste4 > and > ipfw: X Deny ... > strings, so part of /var/log/all instead: > > Oct 23 16:18:39 tw /kernel: Copyright (c) 1992-2002 The FreeBSD Project. > Oct 23 16:18:39 tw /kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, > 1991, 1992, 1993, 1994 > Oct 23 16:18:39 tw /kernel: The Regents of the University of California. All > rights reserved. > Oct 23 16:18:39 tw /kernel: FreeBSD 4.7-STABLE #2: Wed Oct 16 05:37:50 MSD > 2002 > Oct 23 16:18:39 tw /kernel: babolo@banny.pike.ru:/tmp/babolo/usr/src/sys/gw > Oct 23 16:18:39 tw /kernel: Calibrating clock(s) ... TSC clock: 865576478 Hz, > i8254 clock: 1193259 Hz > Oct 23 16:18:39 tw /kernel: CLK_USE_I8254_CALIBRATION not specified - using > default frequency > Oct 23 16:18:39 tw /kernel: Timecounter "i8254" frequency 1193182 Hz > Oct 23 16:18:39 tw /kernel: CLK_USE_TSC_CALIBRATION not specified - using old > calibration method > Oct 23 16:18:39 tw /kernel: CPU: VIA C3 Samuel 2 (865.52-MHz 686-class CPU) > Oct 23 16:18:39 tw /kernel: Origin = "CentaurHauls" Id = 0x678 Stepping = 8 > Oct 23 16:18:39 tw /kernel: Features=0x803035<FPU,DE,TSC,MSR,MTRR,PGE,MMX> > Oct 23 16:18:39 tw /kernel: real memory = 134152192 (131008K bytes) > Oct 23 16:18:39 tw /kernel: Physical memory chunk(s): > Oct 23 16:18:39 tw /kernel: 0x00001000 - 0x0009efff, 647168 bytes (158 pages) > Oct 23 16:18:39 tw /kernel: 0x004d0000 - 0x07faffff, 128843776 bytes (31456 > pages) > Oct 23 16:18:39 tw /kernel: config> di adv0 > Oct 23 16:18:39 tw /kernel: config> di aha0 > Oct 23 16:18:39 tw /kernel: config> di aic0 > Oct 23 16:18:39 tw /kernel: config> di bt0 > Oct 23 16:18:39 tw /kernel: config> di cs0 > Oct 23 16:18:39 tw /kernel: config> di ed0 > Oct 23 16:18:39 tw /kernel: config> di fe0 > Oct 23 16:18:39 tw /kernel: config> di fdc0 > Oct 23 16:18:39 tw /kernel: config> di lnc0 > Oct 23 16:18:39 tw /kernel: config> di sn0 > Oct 23 16:18:39 tw /kernel: config> di sio2 > Oct 23 16:18:39 tw /kernel: config> q > Oct 23 16:18:39 tw /kernel: avail memory = 125022208 (122092K bytes) > Oct 23 16:18:39 tw /kernel: bios32: Found BIOS32 Service Directory header at > 0xc00fdb20 > Oct 23 16:18:39 tw /kernel: bios32: Entry = 0xfdb30 (c00fdb30) Rev = 0 Len = > 1 > Oct 23 16:18:39 tw /kernel: pcibios: PCI BIOS entry at 0xdb51 > Oct 23 16:18:39 tw /kernel: pnpbios: Found PnP BIOS data at 0xc00f6f70 > Oct 23 16:18:39 tw /kernel: pnpbios: Entry = f0000:5fb4 Rev = 1.0 > Oct 23 16:18:39 tw /kernel: Other BIOS signatures found: > Oct 23 16:18:39 tw /kernel: ACPI: 000fc3e0 > Oct 23 16:18:39 tw /kernel: Preloaded elf kernel "kernel" at 0xc04a9000. > Oct 23 16:18:39 tw /kernel: Preloaded userconfig_script "/boot/kernel.conf" at > 0xc04a90a8. > Oct 23 16:18:39 tw /kernel: VESA: information block > Oct 23 16:18:39 tw /kernel: 56 45 53 41 00 02 50 0b 00 c0 01 00 00 00 8b 0b > Oct 23 16:18:39 tw /kernel: 00 c0 40 00 01 01 68 0b 00 c0 79 0b 00 c0 83 0b > Oct 23 16:18:39 tw /kernel: 00 c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > Oct 23 16:18:39 tw /kernel: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > Oct 23 16:18:39 tw /kernel: VESA: 63 mode(s) found > Oct 23 16:18:39 tw /kernel: VESA: v2.0, 4096k memory, flags:0x1, mode > table:0xc00c0b8b (c0000b8b) > Oct 23 16:18:39 tw /kernel: VESA: S3 Incorporated. 86C362 > Oct 23 16:18:39 tw /kernel: VESA: S3 Incorporated. Trio3D/2X Rev C > Oct 23 16:18:39 tw /kernel: pci_open(1): mode 1 addr port (0x0cf8) is > 0x8000006c > Oct 23 16:18:39 tw /kernel: pci_open(1a): mode1res=0x80000000 > (0x80000000) > Oct 23 16:18:39 tw /kernel: pci_cfgcheck: device 0 [class=060000] > [hdr=00] is there (id=30911106) > Oct 23 16:18:39 tw /kernel: Using $PIR table, 10 entries at 0xc00f7590 > Oct 23 16:18:39 tw /kernel: npx0: <math processor> on motherboard > Oct 23 16:18:39 tw /kernel: npx0: INT 16 interface > Oct 23 16:18:39 tw /kernel: pcib0: <Host to PCI bridge> on motherboard > Oct 23 16:18:39 tw /kernel: found-> vendor=0x1106, dev=0x3091, revid=0x01 > Oct 23 16:18:39 tw /kernel: class=06-00-00, hdrtype=0x00, mfdev=0 > Oct 23 16:18:39 tw /kernel: subordinatebus=0 secondarybus=0 > Oct 23 16:18:39 tw /kernel: map[10]: type 1, range 32, base e0000000, size 26 > Oct 23 16:18:39 tw /kernel: found-> vendor=0x1106, dev=0xb091, revid=0x00 > Oct 23 16:18:39 tw /kernel: class=06-04-00, hdrtype=0x01, mfdev=0 > Oct 23 16:18:39 tw /kernel: subordinatebus=1 secondarybus=1 > Oct 23 16:18:39 tw /kernel: found-> vendor=0x1186, dev=0x1002, revid=0x00 > Oct 23 16:18:39 tw /kernel: class=02-00-00, hdrtype=0x00, mfdev=0 > Oct 23 16:18:39 tw /kernel: subordinatebus=0 secondarybus=0 > Oct 23 16:18:39 tw /kernel: intpin=a, irq=10 > Oct 23 16:18:39 tw /kernel: map[10]: type 1, range 32, base 0000dc00, size 7 > Oct 23 16:18:39 tw /kernel: map[14]: type 1, range 32, base dfffff80, size 7 > Oct 23 16:18:39 tw /kernel: found-> vendor=0x1186, dev=0x1002, revid=0x00 > Oct 23 16:18:39 tw /kernel: class=02-00-00, hdrtype=0x00, mfdev=0 > Oct 23 16:18:39 tw /kernel: subordinatebus=0 secondarybus=0 > Oct 23 16:18:39 tw /kernel: intpin=a, irq=11 > Oct 23 16:18:39 tw /kernel: map[10]: type 1, range 32, base 0000d800, size 7 > Oct 23 16:18:39 tw /kernel: map[14]: type 1, range 32, base dfffff00, size 7 > Oct 23 16:18:39 tw /kernel: found-> vendor=0x1186, dev=0x1002, revid=0x00 > Oct 23 16:18:39 tw /kernel: class=02-00-00, hdrtype=0x00, mfdev=0 > Oct 23 16:18:39 tw /kernel: subordinatebus=0 secondarybus=0 > Oct 23 16:18:39 tw /kernel: intpin=a, irq=12 > Oct 23 16:18:39 tw /kernel: map[10]: type 1, range 32, base 0000d400, size 7 > Oct 23 16:18:39 tw /kernel: map[14]: type 1, range 32, base dffffe80, size 7 > Oct 23 16:18:39 tw /kernel: found-> vendor=0x1186, dev=0x1002, revid=0x00 > Oct 23 16:18:39 tw /kernel: class=02-00-00, hdrtype=0x00, mfdev=0 > Oct 23 16:18:39 tw /kernel: subordinatebus=0 secondarybus=0 > Oct 23 16:18:39 tw /kernel: intpin=a, irq=5 > Oct 23 16:18:39 tw /kernel: map[10]: type 1, range 32, base 0000d000, size 7 > Oct 23 16:18:39 tw /kernel: map[14]: type 1, range 32, base dffffe00, size 7 > Oct 23 16:18:39 tw /kernel: found-> vendor=0x1186, dev=0x1002, revid=0x00 > Oct 23 16:18:39 tw /kernel: class=02-00-00, hdrtype=0x00, mfdev=0 > Oct 23 16:18:39 tw /kernel: subordinatebus=0 secondarybus=0 > Oct 23 16:18:39 tw /kernel: intpin=a, irq=10 > Oct 23 16:18:39 tw /kernel: map[10]: type 1, range 32, base 0000cc00, size 7 > Oct 23 16:18:39 tw /kernel: map[14]: type 1, range 32, base dffffd80, size 7 > Oct 23 16:18:39 tw /kernel: found-> vendor=0x10b7, dev=0x9050, revid=0x00 > Oct 23 16:18:39 tw /kernel: class=02-00-00, hdrtype=0x00, mfdev=0 > Oct 23 16:18:39 tw /kernel: subordinatebus=0 secondarybus=0 > Oct 23 16:18:39 tw /kernel: intpin=a, irq=11 > Oct 23 16:18:39 tw /kernel: map[10]: type 1, range 32, base 0000c800, size 6 > Oct 23 16:18:39 tw /kernel: found-> vendor=0x104c, dev=0x8020, revid=0x00 > Oct 23 16:18:39 tw /kernel: class=0c-00-10, hdrtype=0x00, mfdev=0 > Oct 23 16:18:39 tw /kernel: subordinatebus=0 secondarybus=0 > Oct 23 16:18:39 tw /kernel: intpin=a, irq=12 > Oct 23 16:18:39 tw /kernel: map[10]: type 1, range 32, base dffff000, size 11 > Oct 23 16:18:39 tw /kernel: map[14]: type 1, range 32, base dfff8000, size 14 > Oct 23 16:18:39 tw /kernel: found-> vendor=0x1106, dev=0x3074, revid=0x00 > Oct 23 16:18:39 tw /kernel: class=06-01-00, hdrtype=0x00, mfdev=1 > Oct 23 16:18:39 tw /kernel: subordinatebus=0 secondarybus=0 > Oct 23 16:18:39 tw /kernel: found-> vendor=0x1106, dev=0x0571, revid=0x06 > Oct 23 16:18:39 tw /kernel: class=01-01-8a, hdrtype=0x00, mfdev=0 > Oct 23 16:18:39 tw /kernel: subordinatebus=0 secondarybus=0 > Oct 23 16:18:39 tw /kernel: map[20]: type 1, range 32, base 0000ff00, size 4 > Oct 23 16:18:39 tw /kernel: pci0: <PCI bus> on pcib0 > Oct 23 16:18:39 tw /kernel: pcib1: <PCI to PCI bridge (vendor=1106 > device=b091)> at device 1.0 on pci0 > Oct 23 16:18:39 tw /kernel: found-> vendor=0x5333, dev=0x8a13, revid=0x02 > Oct 23 16:18:39 tw /kernel: class=03-00-00, hdrtype=0x00, mfdev=0 > Oct 23 16:18:39 tw /kernel: subordinatebus=0 secondarybus=0 > Oct 23 16:18:39 tw /kernel: map[10]: type 1, range 32, base d8000000, size 26 > Oct 23 16:18:39 tw /kernel: pci1: <PCI bus> on pcib1 > Oct 23 16:18:39 tw /kernel: pci1: <S3 Trio3D/2X graphics accelerator> > (vendor=0x5333, dev=0x8a13) at 0.0 > Oct 23 16:18:39 tw /kernel: ste0: <D-Link DFE-550TX 10/100BaseTX> port > 0xdc00-0xdc7f mem 0xdfffff80-0xdfffffff > irq 10 at device 9.0 on pci0 > Oct 23 16:18:39 tw /kernel: ste0: Ethernet address: 00:05:5d:f6:ac:57 > Oct 23 16:18:39 tw /kernel: miibus0: <MII bus> on ste0 > Oct 23 16:18:39 tw /kernel: acphy0: <AC101 10/100 media interface> on miibus0 > Oct 23 16:18:39 tw /kernel: acphy0: 10baseT, 10baseT-FDX, 100baseTX, > 100baseTX-FDX > Oct 23 16:18:39 tw /kernel: bpf: ste0 attached > Oct 23 16:18:39 tw /kernel: ste1: <D-Link DFE-550TX 10/100BaseTX> port > 0xd800-0xd87f mem 0xdfffff00-0xdfffff7f > irq 11 at device 10.0 on pci0 > Oct 23 16:18:39 tw /kernel: ste1: Ethernet address: 00:05:5d:f6:ac:5b > Oct 23 16:18:39 tw /kernel: miibus1: <MII bus> on ste1 > Oct 23 16:18:39 tw /kernel: acphy1: <AC101 10/100 media interface> on miibus1 > Oct 23 16:18:39 tw /kernel: acphy1: 10baseT, 10baseT-FDX, 100baseTX, > 100baseTX-FDX > Oct 23 16:18:39 tw /kernel: bpf: ste1 attached > Oct 23 16:18:39 tw /kernel: ste2: <D-Link DFE-550TX 10/100BaseTX> port > 0xd400-0xd47f mem 0xdffffe80-0xdffffeff > irq 12 at device 11.0 on pci0 > Oct 23 16:18:39 tw /kernel: ste2: Ethernet address: 00:05:5d:f6:af:f9 > Oct 23 16:18:39 tw /kernel: miibus2: <MII bus> on ste2 > Oct 23 16:18:39 tw /kernel: acphy2: <AC101 10/100 media interface> on miibus2 > Oct 23 16:18:39 tw /kernel: acphy2: 10baseT, 10baseT-FDX, 100baseTX, > 100baseTX-FDX > Oct 23 16:18:39 tw /kernel: bpf: ste2 attached > Oct 23 16:18:39 tw /kernel: ste3: <D-Link DFE-550TX 10/100BaseTX> port > 0xd000-0xd07f mem 0xdffffe00-0xdffffe7f > irq 5 at device 12.0 on pci0 > Oct 23 16:18:39 tw /kernel: ste3: Ethernet address: 00:05:5d:f6:ad:ab > Oct 23 16:18:39 tw /kernel: miibus3: <MII bus> on ste3 > Oct 23 16:18:39 tw /kernel: acphy3: <AC101 10/100 media interface> on miibus3 > Oct 23 16:18:39 tw /kernel: acphy3: 10baseT, 10baseT-FDX, 100baseTX, > 100baseTX-FDX > Oct 23 16:18:39 tw /kernel: bpf: ste3 attached > Oct 23 16:18:39 tw /kernel: ste4: <D-Link DFE-550TX 10/100BaseTX> port > 0xcc00-0xcc7f mem 0xdffffd80-0xdffffdff > irq 10 at device 13.0 on pci0 > Oct 23 16:18:39 tw /kernel: using shared irq10. > Oct 23 16:18:39 tw /kernel: ste4: Ethernet address: 00:05:5d:f6:b0:05 > Oct 23 16:18:39 tw /kernel: miibus4: <MII bus> on ste4 > Oct 23 16:18:39 tw /kernel: acphy4: <AC101 10/100 media interface> on miibus4 > Oct 23 16:18:39 tw /kernel: acphy4: 10baseT, 10baseT-FDX, 100baseTX, > 100baseTX-FDX > Oct 23 16:18:39 tw /kernel: bpf: ste4 attached > Oct 23 16:18:39 tw /kernel: xl0: <3Com 3c905-TX Fast Etherlink XL> port > 0xc800-0xc83f irq 11 at device 14.0 on > pci0 > Oct 23 16:18:39 tw /kernel: using shared irq11. > Oct 23 16:18:39 tw /kernel: xl0: Ethernet address: 00:10:4b:31:8a:8e > Oct 23 16:18:39 tw /kernel: xl0: media options word: e040 > Oct 23 16:18:39 tw /kernel: xl0: found MII/AUTO > Oct 23 16:18:39 tw /kernel: miibus5: <MII bus> on xl0 > Oct 23 16:18:39 tw /kernel: nsphy0: <DP83840 10/100 media interface> on > miibus5 > Oct 23 16:18:39 tw /kernel: nsphy0: 10baseT, 10baseT-FDX, 100baseTX, > 100baseTX-FDX, auto > Oct 23 16:18:39 tw /kernel: bpf: xl0 attached > Oct 23 16:18:39 tw /kernel: pci0: <unknown card> (vendor=0x104c, dev=0x8020) > at 15.0 irq 12 > Oct 23 16:18:39 tw /kernel: viapropm0: SMBus I/O base at 0x400 > Oct 23 16:18:39 tw /kernel: viapropm0: <VIA VT8233 Power Management Unit> port > 0x400-0x40f at device 17.0 on pc > i0 > Oct 23 16:18:39 tw /kernel: viapropm0: SMBus revision code 0x0 > Oct 23 16:18:39 tw /kernel: smb0: <SMBus general purpose I/O> on smbus0 > Oct 23 16:18:39 tw /kernel: atapci0: <VIA 8233 ATA100 controller> port > 0xff00-0xff0f at device 17.1 on pci0 > Oct 23 16:18:39 tw /kernel: ata0: iobase=0x01f0 altiobase=0x03f6 bmaddr=0xff00 > Oct 23 16:18:39 tw /kernel: ata0: mask=03 ostat0=50 ostat2=00 > Oct 23 16:18:39 tw /kernel: ata0-master: ATAPI 00 00 > Oct 23 16:18:39 tw /kernel: ata0-slave: ATAPI 00 00 > Oct 23 16:18:39 tw /kernel: ata0: mask=03 stat0=50 stat1=00 > Oct 23 16:18:39 tw /kernel: ata0-master: ATA 01 a5 > Oct 23 16:18:39 tw /kernel: ata0: devices=01 > Oct 23 16:18:39 tw /kernel: ata0: at 0x1f0 irq 14 on atapci0 > Oct 23 16:18:39 tw /kernel: ata1: iobase=0x0170 altiobase=0x0376 bmaddr=0xff08 > Oct 23 16:18:39 tw /kernel: ata1: mask=03 ostat0=50 ostat2=00 > Oct 23 16:18:39 tw /kernel: ata1-master: ATAPI 00 00 > Oct 23 16:18:39 tw /kernel: ata1-slave: ATAPI 00 00 > Oct 23 16:18:39 tw /kernel: ata1: mask=03 stat0=50 stat1=00 > Oct 23 16:18:39 tw /kernel: ata1-master: ATA 01 a5 > Oct 23 16:18:39 tw /kernel: ata1: devices=01 > Oct 23 16:18:39 tw /kernel: ata1: at 0x170 irq 15 on atapci0 > Oct 23 16:18:39 tw /kernel: isa0: <ISA bus> on motherboard > Oct 23 16:18:39 tw /kernel: ex_isa_identify() > Oct 23 16:18:39 tw /kernel: ata-: ata0 exists, using next available unit > number > Oct 23 16:18:39 tw /kernel: ata-: ata1 exists, using next available unit > number > Oct 23 16:18:39 tw /kernel: Trying Read_Port at 203 > Oct 23 16:18:39 tw /kernel: Trying Read_Port at 243 > Oct 23 16:18:39 tw /kernel: Trying Read_Port at 283 > Oct 23 16:18:39 tw /kernel: Trying Read_Port at 2c3 > Oct 23 16:18:39 tw /kernel: Trying Read_Port at 303 > Oct 23 16:18:39 tw /kernel: Trying Read_Port at 343 > Oct 23 16:18:39 tw /kernel: Trying Read_Port at 383 > Oct 23 16:18:39 tw /kernel: Trying Read_Port at 3c3 > Oct 23 16:18:39 tw /kernel: isa_probe_children: disabling PnP devices > Oct 23 16:18:39 tw /kernel: isa_probe_children: probing non-PnP devices > Oct 23 16:18:39 tw /kernel: orm0: <Option ROM> at iomem 0xc0000-0xc7fff on > isa0 > Oct 23 16:18:39 tw /kernel: fdc0: not probed (disabled) > Oct 23 16:18:39 tw /kernel: ata2 failed to probe at port 0x1f0 irq 14 on isa0 > Oct 23 16:18:39 tw /kernel: ata3 failed to probe at port 0x170 irq 15 on isa0 > Oct 23 16:18:39 tw /kernel: adv0: not probed (disabled) > Oct 23 16:18:39 tw /kernel: bt0: not probed (disabled) > Oct 23 16:18:39 tw /kernel: aha0: not probed (disabled) > Oct 23 16:18:39 tw /kernel: aic0: not probed (disabled) > Oct 23 16:18:39 tw /kernel: atkbdc0: <Keyboard controller (i8042)> at port > 0x60,0x64 on isa0 > Oct 23 16:18:39 tw /kernel: atkbd0: <AT Keyboard> irq 1 on atkbdc0 > Oct 23 16:18:39 tw /kernel: atkbd: the current kbd controller command byte > 0065 > Oct 23 16:18:39 tw /kernel: atkbd: keyboard ID 0x41ab (2) > Oct 23 16:18:39 tw /kernel: kbd0 at atkbd0 > Oct 23 16:18:39 tw /kernel: kbd0: atkbd0, AT 101/102 (2), config:0x0, > flags:0x3d0000 > Oct 23 16:18:39 tw /kernel: psm0: current command byte:0065 > Oct 23 16:18:39 tw /kernel: psm0: failed to reset the aux device. > Oct 23 16:18:39 tw /kernel: vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem > 0xa0000-0xbffff on isa0 > Oct 23 16:18:39 tw /kernel: fb0: vga0, vga, type:VGA (5), flags:0x700ff > Oct 23 16:18:39 tw /kernel: fb0: port:0x3c0-0x3df, crtc:0x3d4, mem:0xa0000 > 0x20000 > Oct 23 16:18:39 tw /kernel: fb0: init mode:24, bios mode:3, current mode:24 > Oct 23 16:18:39 tw /kernel: fb0: window:0xc00b8000 size:32k gran:32k, buf:0 > size:32k > Oct 23 16:18:39 tw /kernel: VGA parameters upon power-up > Oct 23 16:18:39 tw /kernel: 50 18 10 00 00 00 03 00 02 67 5f 4f 50 82 55 81 > Oct 23 16:18:39 tw /kernel: bf 1f 00 4f 0d 0e 00 00 05 50 9c 8e 8f 28 1f 96 > Oct 23 16:18:39 tw /kernel: b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c > Oct 23 16:18:39 tw /kernel: 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff > Oct 23 16:18:39 tw /kernel: VGA parameters in BIOS for mode 24 > Oct 23 16:18:39 tw /kernel: 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 > Oct 23 16:18:39 tw /kernel: bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 > Oct 23 16:18:39 tw /kernel: b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c > Oct 23 16:18:39 tw /kernel: 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff > Oct 23 16:18:39 tw /kernel: EGA/VGA parameters to be used for mode 24 > Oct 23 16:18:39 tw /kernel: 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 > Oct 23 16:18:39 tw /kernel: bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 > Oct 23 16:18:39 tw /kernel: b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c > Oct 23 16:18:39 tw /kernel: 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff > Oct 23 16:18:39 tw /kernel: sc0: <System console> at flags 0x100 on isa0 > Oct 23 16:18:39 tw /kernel: sc0: VGA <16 virtual consoles, flags=0x300> > Oct 23 16:18:39 tw /kernel: sc0: fb0, kbd0, terminal emulator: sc (syscons > terminal) > Oct 23 16:18:39 tw /kernel: pcic0: not probed (disabled) > Oct 23 16:18:39 tw /kernel: pcic1: not probed (disabled) > Oct 23 16:18:39 tw /kernel: sio0: irq maps: 0x2001 0x2011 0x2001 0x2001 > Oct 23 16:18:39 tw /kernel: sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 > Oct 23 16:18:39 tw /kernel: sio0: type 16550A > Oct 23 16:18:39 tw /kernel: sio1: irq maps: 0x2001 0x2009 0x2001 0x2001 > Oct 23 16:18:39 tw /kernel: sio1 at port 0x2f8-0x2ff irq 3 on isa0 > Oct 23 16:18:39 tw /kernel: sio1: type 16550A > Oct 23 16:18:39 tw /kernel: sio2: not probed (disabled) > Oct 23 16:18:39 tw /kernel: sio3: not probed (disabled) > Oct 23 16:18:39 tw /kernel: dgb0: not probed (disabled) > Oct 23 16:18:39 tw /kernel: ppc0: parallel port found at 0x378 > Oct 23 16:18:39 tw /kernel: ppc0: using extended I/O port range > Oct 23 16:18:39 tw /kernel: ppc0: ECP SPP ECP+EPP SPP > Oct 23 16:18:39 tw /kernel: ppc0: <Parallel port> at port 0x378-0x37f irq 7 on > isa0 > Oct 23 16:18:39 tw /kernel: ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in > COMPATIBLE mode > Oct 23 16:18:39 tw /kernel: ppc0: FIFO with 16/16/9 bytes threshold > Oct 23 16:18:39 tw /kernel: plip0: <PLIP network interface> on ppbus0 > Oct 23 16:18:39 tw /kernel: bpf: lp0 attached > Oct 23 16:18:39 tw /kernel: lpt0: <Printer> on ppbus0 > Oct 23 16:18:39 tw /kernel: lpt0: Interrupt-driven port > Oct 23 16:18:39 tw /kernel: ppi0: <Parallel I/O> on ppbus0 > Oct 23 16:18:39 tw /kernel: vpo0: can't connect to the drive > Oct 23 16:18:39 tw /kernel: imm0: (disconnect) s1=0x38 s2=0x38, s3=0x38 > Oct 23 16:18:39 tw /kernel: imm0: (connect) s1=0x38 s2=0x38, s3=0x38 > Oct 23 16:18:39 tw last message repeated 2 times > Oct 23 16:18:39 tw /kernel: ed0: not probed (disabled) > Oct 23 16:18:39 tw /kernel: fe0: not probed (disabled) > Oct 23 16:18:39 tw /kernel: ie0 failed to probe at port 0x300 iomem 0xd0000 > irq 10 on isa0 > Oct 23 16:18:39 tw /kernel: lnc0: not probed (disabled) > Oct 23 16:18:39 tw /kernel: cs0: not probed (disabled) > Oct 23 16:18:39 tw /kernel: sn0: not probed (disabled) > Oct 23 16:18:39 tw /kernel: pca0 at port 0x40 on isa0 > Oct 23 16:18:39 tw /kernel: isa_probe_children: probing PnP devices > Oct 23 16:18:39 tw /kernel: BIOS Geometries: > Oct 23 16:18:39 tw /kernel: 0:03fefe3f 0..1022=1023 cylinders, 0..254=255 > heads, 1..63=63 sectors > Oct 23 16:18:39 tw /kernel: 0 accounted for > Oct 23 16:18:39 tw /kernel: Device configuration finished. > Oct 23 16:18:39 tw /kernel: bpf: lo0 attached > Oct 23 16:18:39 tw /kernel: bpf: lo1 attached > Oct 23 16:18:39 tw /kernel: bpf: lo2 attached > Oct 23 16:18:39 tw /kernel: bpf: lo3 attached > Oct 23 16:18:39 tw /kernel: bpf: ppp0 attached > Oct 23 16:18:39 tw /kernel: new masks: bio 68c000, tty 63009a, net 671cba > Oct 23 16:18:39 tw /kernel: bpf: ds0 attached > Oct 23 16:18:39 tw /kernel: IPv6 packet filtering initialized, logging limited > to 100 packets/entry > Oct 23 16:18:39 tw /kernel: bpf: stf0 attached > Oct 23 16:18:39 tw /kernel: DUMMYNET initialized (011031) > Oct 23 16:18:39 tw /kernel: bpf: faith0 attached > Oct 23 16:18:39 tw /kernel: ipfw2 initialized, divert enabled, rule-based > forwarding enabled, default to accept > , logging limited to 100 packets/entry by default > Oct 23 16:18:39 tw /kernel: bpf: vlan0 attached > Oct 23 16:18:39 tw /kernel: bpf: vlan1 attached > Oct 23 16:18:39 tw /kernel: bpf: vlan2 attached > Oct 23 16:18:39 tw /kernel: bpf: vlan3 attached > Oct 23 16:18:39 tw /kernel: bpf: vlan4 attached > Oct 23 16:18:39 tw /kernel: bpf: vlan5 attached > Oct 23 16:18:39 tw /kernel: bpf: vlan6 attached > Oct 23 16:18:39 tw /kernel: bpf: vlan7 attached > Oct 23 16:18:39 tw /kernel: BRIDGE 020214 loaded > Oct 23 16:18:39 tw /kernel: IP Filter: v3.4.29 initialized. Default = pass > all, Logging = enabled > Oct 23 16:18:39 tw /kernel: ad0: success setting UDMA5 on VIA chip > Oct 23 16:18:39 tw /kernel: Creating DISK ad0 > Oct 23 16:18:39 tw /kernel: ar: FreeBSD check1 failed > Oct 23 16:18:39 tw /kernel: ad0: <SAMSUNG SV1021H/PJ100-21> ATA-6 disk at > ata0-master > Oct 23 16:18:39 tw /kernel: ad0: 9732MB (19932192 sectors), 19774 C, 16 H, 63 > S, 512 B > Oct 23 16:18:39 tw /kernel: ad0: 16 secs/int, 1 depth queue, UDMA100 > Oct 23 16:18:39 tw /kernel: ad0: piomode=4 dmamode=2 udmamode=5 cblid=1 > Oct 23 16:18:39 tw /kernel: ad2: success setting UDMA2 on VIA chip > Oct 23 16:18:39 tw /kernel: Creating DISK ad2 > Oct 23 16:18:39 tw /kernel: ar: FreeBSD check1 failed > Oct 23 16:18:39 tw /kernel: ad2: <QUANTUM FIREBALL SE8.4A/API.0D00> ATA-3 disk > at ata1-master > Oct 23 16:18:39 tw /kernel: ad2: 8063MB (16514064 sectors), 16383 C, 16 H, 63 > S, 512 B > Oct 23 16:18:39 tw /kernel: ad2: 16 secs/int, 1 depth queue, UDMA33 > Oct 23 16:18:39 tw /kernel: ad2: piomode=4 dmamode=2 udmamode=2 cblid=0 > Oct 23 16:18:39 tw /kernel: Mounting root from ufs:/dev/ad0s1a > Oct 23 16:18:39 tw /kernel: ad0s1: type 0xa5, start 127008, end = 16514063, > size 16387056 : OK > Oct 23 16:18:39 tw /kernel: ad0s4: type 0xa5, start 0, end = 127007, size > 127008 : OK > Oct 23 16:18:39 tw /kernel: start_init: trying /sbin/init > Oct 23 16:18:39 tw /kernel: swapon: adding /dev/ad0s1b as swap device > > 141tw~(21)#strings /kernel | grep ^___ | sed -e 's|^___||' > # > # GENERIC -- Generic kernel configuration file for FreeBSD/i386 > # > # For more information on this file, please read the handbook section on > # Kernel Configuration Files: > # > # http://www.FreeBSD.org/handbook/kernelconfig-config.html > # > # The handbook is also available locally in /usr/share/doc/handbook > # if you've installed the doc distribution, otherwise always see the > # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the > # latest information. > # > # An exhaustive list of options and more detailed explanations of the > # device lines is also present in the ./LINT configuration file. If you are > # in doubt as to the purpose or necessity of a line, check first in LINT. > # > # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.246.2.33 2001/07/30 17:31:40 wpaul > Exp $ > machine i386 > #cpu I386_CPU > #cpu I486_CPU > cpu I586_CPU > cpu I686_CPU > #options CPU_SUSP_HLT > options CPU_WT_ALLOC > options NO_F00F_HACK > ident gw > maxusers 128 > options MAXDSIZ="(512*1024*1024)" > options INCLUDE_CONFIG_FILE # Include this file in kernel > options MSGBUF_SIZE=262144 > options NMBCLUSTERS=16384 > options INVARIANTS > options INVARIANT_SUPPORT > options DIAGNOSTIC > options AUTO_EOI_1 > #options AUTO_EOI_2 > makeoptions DEBUG=-g #Build kernel with gdb(1) debug > symbols > #options MATH_EMULATE #Support for x87 emulation > options INET #InterNETworking > options INET6 #IPv6 communications protocols > options FFS #Berkeley Fast Filesystem > options FFS_ROOT #FFS usable as root device [keep > this!] > options SOFTUPDATES #Enable FFS soft updates support > options UFS_DIRHASH #Improve performance on big > directories > #options MFS #Memory Filesystem > #options MD_ROOT #MD is a potential root device > options NFS #Network Filesystem > #options NFS_ROOT #NFS usable as root device, NFS > required > #options MSDOSFS #MSDOS Filesystem > #options CD9660 #ISO 9660 Filesystem > #options CD9660_ROOT #CD-ROM usable as root, CD9660 > required > options PROCFS #Process filesystem > options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] > options SCSI_DELAY=15000 #Delay (in ms) before probing SCSI > options UCONSOLE #Allow users to grab the console > options USERCONFIG #boot -c editor > options VISUAL_USERCONFIG #visual boot -c editor > options KTRACE #ktrace(1) support > options SYSVSHM #SYSV-style shared memory > options SYSVMSG #SYSV-style message queues > options SYSVSEM #SYSV-style semaphores > options SHMALL=16384 > options SHMMAX="(SHMMAXPGS*PAGE_SIZE+1)" > options SHMMAXPGS=8192 > options SHMMIN=128 > options SHMMNI=256 > options SHMSEG=512 > options NSWAPDEV=2 > options P1003_1B #Posix P1003_1B real-time extensions > options _KPOSIX_PRIORITY_SCHEDULING > options ICMP_BANDLIM #Rate limit bad replies > options KBD_INSTALL_CDEV # install a CDEV entry in /dev > options USER_LDT #allow user-level control of i386 ldt > options PERFMON > options NETGRAPH #netgraph(4) system > options MYLOOP_MASKLEN=24 > options IPV6FIREWALL #firewall for IPv6 > options IPV6FIREWALL_VERBOSE > options IPV6FIREWALL_VERBOSE_LIMIT=100 > options IPFIREWALL #firewall > options IPFIREWALL_VERBOSE #print information about > # dropped packets > options IPFW2 > options IPFIREWALL_FORWARD #enable transparent proxy support > options IPFIREWALL_VERBOSE_LIMIT=100 #limit verbosity > options IPFIREWALL_DEFAULT_TO_ACCEPT #allow everything by default > options IPDIVERT #divert sockets > options IPFILTER #ipfilter support > options IPFILTER_LOG #ipfilter logging > options IPSTEALTH #support for stealth forwarding > options RANDOM_IP_ID > options DUMMYNET > options BRIDGE > # To make an SMP kernel, the next two are needed > #options SMP # Symmetric MultiProcessor Kernel > #options APIC_IO # Symmetric (APIC) I/O > device isa > #device eisa > device pci > # Floppy drives > device fdc0 at isa? port IO_FD1 irq 6 drq 2 > device fd0 at fdc0 drive 0 > device fd1 at fdc0 drive 1 > # ATA and ATAPI devices > device ata0 at isa? port IO_WD1 irq 14 > device ata1 at isa? port IO_WD2 irq 15 > device ata > device atadisk # ATA disk drives > device atapicd # ATAPI CDROM drives > device atapifd # ATAPI floppy drives > device atapist # ATAPI tape drives > options ATA_STATIC_ID #Static device numbering > # SCSI Controllers > device ahc # AHA2940 and onboard AIC7xxx devices > options AHC_ALLOW_MEMIO > device amd # AMD 53C974 (Tekram DC-390(T)) > device isp # Qlogic family > device ncr # NCR/Symbios Logic > device sym # NCR/Symbios Logic (newer chipsets) > options SYM_SETUP_LP_PROBE_MAP=0x40 > # Allow ncr to attach legacy NCR devices when > # both sym and ncr are configured > device adv0 at isa? > device adw > device bt0 at isa? > device aha0 at isa? > device aic0 at isa? > # SCSI peripherals > device scbus # SCSI bus (required) > device da # Direct Access (disks) > device sa # Sequential Access (tape etc) > device cd # CD > device pass # Passthrough device (direct SCSI access) > # atkbdc0 controls both the keyboard and the PS/2 mouse > device atkbdc0 at isa? port IO_KBD > device atkbd0 at atkbdc? irq 1 > device psm0 at atkbdc? irq 12 > device vga0 at isa? > options VGA_WIDTH90 # support 90 column modes > options VESA > # splash screen/screen saver > pseudo-device splash > # syscons is the default console driver, resembling an SCO console > device sc0 at isa? flags 0x100 > options SC_HISTORY_SIZE=2118 # number of history buffer lines > options SC_MOUSE_CHAR=0x3 # char code for text mode mouse cursor > options SC_NORM_ATTR="(FG_BROWN|BG_BLACK)" > options SC_NORM_REV_ATTR="(FG_BLACK|BG_RED)" > options SC_KERNEL_CONS_ATTR="(FG_YELLOW|BG_BROWN)" > options SC_KERNEL_CONS_REV_ATTR="(FG_WHITE|BG_RED)" > # Enable this and PCVT_FREEBSD for pcvt vt220 compatible console driver > #device vt0 at isa? > #options XSERVER # support for X server on a vt console > #options FAT_CURSOR # start with block cursor > # If you have a ThinkPAD, uncomment this along with the rest of the PCVT lines > #options PCVT_SCANSET=2 # IBM keyboards are non-std > # Floating point support - do not disable. > device npx0 at nexus? port IO_NPX irq 13 > # Power management support (see LINT for more options) > device apm0 at nexus? disable flags 0x20 # Advanced Power > Management > # PCCARD (PCMCIA) support > device card > device pcic0 at isa? irq 0 port 0x3e0 iomem 0xd0000 disable > device pcic1 at isa? irq 0 port 0x3e2 iomem 0xd4000 disable > # Serial (COM) ports > options CONSPEED=115200 > options COM_MULTIPORT #code for some cards with shared IRQs > device sio0 at isa? port IO_COM1 flags 0x10 irq 4 > device sio1 at isa? port IO_COM2 irq 3 > device sio2 at isa? port IO_COM3 irq 5 > device sio3 at isa? disable port IO_COM4 irq 9 > device dgb0 at isa? disable port 0x320 iomem 0xc0000 flags 0x01 > options NDGBPORTS=8 # Defaults to 16*NDGB > #device dgm0 at isa? port 0x104 iomem 0xd0000 flags 0x01 > # Parallel port > device ppc0 at isa? irq 7 > device ppbus # Parallel port bus (required) > device lpt # Printer > device plip # TCP/IP over parallel > device ppi # Parallel port interface device > device vpo # Requires scbus and da > device lpbb #Philips parallel port I2C bit-banging interface > options DEVICE_POLLING > # PCI Ethernet NICs. > device de # DEC/Intel DC21x4x (``Tulip'') > device txp # 3Com 3cR990 (``Typhoon'') > device vx # 3Com 3c590, 3c595 (``Vortex'') > # PCI Ethernet NICs that use the common MII bus controller code. > # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! > device miibus # MII bus support > device dc # DEC/Intel 21143 and various workalikes > device fxp # Intel EtherExpress PRO/100B (82557, 82558) > device pcn # AMD Am79C97x PCI 10/100 NICs > device rl # RealTek 8129/8139 > device sf # Adaptec AIC-6915 (``Starfire'') > device sis # Silicon Integrated Systems SiS 900/SiS 7016 > device ste # Sundance ST201 (D-Link DFE-550TX) > device tl # Texas Instruments ThunderLAN > device tx # SMC EtherPower II (83c170 ``EPIC'') > device vr # VIA Rhine, Rhine II > device wb # Winbond W89C840F > device wx # Intel Gigabit Ethernet Card (``Wiseman'') > device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') > device bge # Broadcom BCM570x (``Tigon III'') > # ISA Ethernet NICs. > # 'device ed' requires 'device miibus' > device ed0 at isa? port 0x280 irq 10 iomem 0xd8000 > device ex > device ep > device fe0 at isa? port 0x300 > # Xircom Ethernet > device xe > # PRISM I IEEE 802.11b wireless NIC. > device awi > # WaveLAN/IEEE 802.11 wireless NICs. Note: the WaveLAN/IEEE really > # exists only as a PCMCIA device, so there is no ISA attachment needed > # and resources will always be dynamically assigned by the pccard code. > device wi > # Aironet 4500/4800 802.11 wireless NICs. Note: the declaration below will > # work for PCMCIA and PCI cards, as well as ISA cards set to ISA PnP > # mode (the factory default). If you set the switches on your ISA > # card for a manually chosen I/O address and IRQ, you must specify > # those parameters here. > device an > # The probe order of these is presently determined by i386/isa/isa_compat.c. > device ie0 at isa? port 0x300 irq 10 iomem 0xd0000 > #device le0 at isa? port 0x300 irq 5 iomem 0xd0000 > device lnc0 at isa? port 0x280 irq 10 drq 0 > device cs0 at isa? port 0x300 > device sn0 at isa? port 0x300 irq 10 > # Pseudo devices - the number indicates how many units to allocate. > pseudo-device loop 4 # Network loopback > pseudo-device ether # Ethernet support > pseudo-device vlan 8 #VLAN support > #pseudo-device sl 4 # Kernel SLIP > pseudo-device ppp 1 # Kernel PPP > options PPP_BSDCOMP #PPP BSD-compress support > options PPP_DEFLATE #PPP zlib/deflate/gzip support > options PPP_FILTER #enable bpf filtering (needs bpf) > pseudo-device tun 4 # Packet tunnel. > pseudo-device pty # Pseudo-ttys (telnet etc) > #pseudo-device md # Memory "disks" > pseudo-device gif # IPv6 and IPv4 tunneling > pseudo-device faith 1 # IPv6-to-IPv4 relaying (translation) > pseudo-device stf 1 #6to4 IPv6 over IPv4 encapsulation > pseudo-device speaker #Play IBM BASIC-style noises out your speaker > pseudo-device gzip #Exec gzipped a.out's > pseudo-device disc #Discard device (ds0, ds1, etc) > # The `bpf' pseudo-device enables the Berkeley Packet Filter. > # Be aware of the administrative consequences of enabling this! > pseudo-device bpf 32 #Berkeley packet filter > # USB support > #device uhci # UHCI PCI->USB interface > #device ohci # OHCI PCI->USB interface > #device usb # USB Bus (required) > #device ugen # Generic > #device uhid # "Human Interface Devices" > #device ukbd # Keyboard > #device ulpt # Printer > #device umass # Disks/Mass storage - Requires scbus and da > #device umodem # USB modem support > #device ums # Mouse > #device uscanner # USB scanners > # USB Ethernet, requires mii > #device aue # ADMtek USB ethernet > #device cue # CATC USB ethernet > #device kue # Kawasaki LSI USB ethernet > #device pcm > device pca0 at isa? port IO_TIMER1 > device smbus > device intpm > device alpm > device viapm > device ichsmb > device smb > device iicbus > device iicbb > device ic > device iic > device iicsmb # smb over i2c bridge > 0tw~(22)#cat /etc/sysctl.conf > # $FreeBSD: src/etc/sysctl.conf,v 1.1.2.3 2002/04/15 00:44:13 dougb Exp $ > # > # This file is read when going to multi-user and its contents piped thru > # ``sysctl'' to adjust kernel values. ``man 5 sysctl.conf'' for details. > # > > vfs.nfs.gatherdelay=0 > vfs.nfs.async=1 > kern.ipc.somaxconn=1024 > kern.ipc.maxsockbuf=1048576 > kern.polling.enable=1 > vfs.vmiodirenable=1 > net.inet.raw.recvspace=65536 > net.inet.ip.fastforwarding=0 > net.inet.ip.ttl=59 > net.inet.ip.fw.one_pass=0 > #net.inet.tcp.sendspace=65536 > #net.inet.tcp.recvspace=65536 > net.link.ether.inet.proxyall=1 > debug.bpf_bufsize=524288 > net.inet.ip.redirect=0 > > Lot of static arps, ipfw rules and routes to ds0 > > Sorry, my English is bad. > Michael F. DeMan Director of Technology OpenAccess Internet Services 1305 11th St., 3rd Floor Bellingham, WA 98225 Tel 360-647-0785 x204 Fax 360-738-9785 michael@staff.openaccess.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Oct 23 17:31:31 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4D27337B401; Wed, 23 Oct 2002 17:31:27 -0700 (PDT) Received: from inje.iskon.hr (inje.iskon.hr [213.191.128.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 42E5943E3B; Wed, 23 Oct 2002 17:31:25 -0700 (PDT) (envelope-from zec@tel.fer.hr) Received: from tel.fer.hr (zg05-053.dialin.iskon.hr [213.191.138.54]) by mail.iskon.hr (8.11.4/8.11.4/Iskon 8.11.3-1) with ESMTP id g9O0UIE24123; Thu, 24 Oct 2002 02:30:21 +0200 (MEST) Message-ID: <3DB73F31.5F02609C@tel.fer.hr> Date: Thu, 24 Oct 2002 02:30:41 +0200 From: Marko Zec <zec@tel.fer.hr> X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer <julian@elischer.org> Cc: "J. 'LoneWolf' Mattsson" <lonewolf-freebsd@earthmagic.org>, freebsd-net@freebsd.org, freebsd-arch@freebsd.org Subject: Re: RFC: BSD network stack virtualization References: <Pine.BSF.4.21.0210231503010.36940-100000@InterJet.elischer.org> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org Julian Elischer wrote: > I'm very impressed. I do however have some questions. > (I have not read the code yet, just the writeup) > > 1/ How do you cope with each machine expecting to have it's own loopback > interface? Is it sufficient to make lo1 lo2 lo3 etc. and attache them > to the appropriate VMs? The creation of "lo0" interface is done "automatically" at the time of creation of each new virtual image instance. The BSD networking code generally assumes the "lo0" interface exists all the times, so it just wouldn't be possible to create a network stack instance without a unique "lo" ifc. > 2/ How much would be gained (i.e. is it worth it) to combine this with > jail? Can you combine them? (does it work?) Does it make sense? Userland separation (hiding) between processes running in different virtual images is actually accomplished by reusing the jail framework. The networking work is completely free of jail legacy. Although I didn't test it, I'm 100% sure it should be possible to run multiple jails inside each of virtual images. For me it doesn't make too much sense though, that's why I didn't bother with testing... > 3/ You implemented this in 4.x which means that we need to reimplement > it in -current before it has any chance of being 'included'. Do you > think that would be abig problem? I must admit that I do not follow the development in -current, so it's hard to tell how much the network stacks have diverted in the areas affected by virtualization work. My initial intention was to "polish" the virtualization code on the 4.x platform - there are still some major chunks of coding yet to be done, such as removal of virtual images, and patching of IPv6 and IPSEC code. Hopefully this will be in sync with the release of 5.0, so than I can spend some time porting it to -current. However, if reasonable demand is created, I'm prepared to revise that approach... > 5/ Does inclusion of the virtualisation have any measurable effect on > throughputs for systems that are NOT using virtualisation. In other > words, does the non Virtualised code-path get much extra work? (doi you > have numbers?) (i.e. does it cost much for the OTHER users if we > incorporated this into FreeBSD?) The first thing in my pipeline is doing decent performance/throughput measurements, but these days I just cannot find enough spare time for doing that properly (I still have a daytime job...). The preliminary netperf tests show around 1-2% drop in maximum TCP throughput on loopback with 1500 bytes MTU, so in my opinion this is really a neglectable penalty. Of course, the applications limited by media speed won't experience any throughput degradation, except probably hardly measurable increase in CPU time spent in interrupt context. > 6/ I think that your ng_dummy node is cute.. > can I commit it separatly? (after porting it to -current..) Actually, this code is ugly, as I was stupid enough to invent my own queue management methods, instead of using the existing ones. However, from the user perspective the code seems to work without major problems, so if you want to commit it I would be glad... > 7/ the vmware image is a great idea. > > 8/ can you elaborate on the following: > * hiding of "foreign" filesystem mounts within chrooted virtual images Here is an self-explaining example of hiding "foreign" filesystem mounts: tpx30# vimage -c test1 chroot /opt/chrooted_vimage tpx30# mount /dev/ad0s1a on / (ufs, local, noatime) /dev/ad0s1g on /opt (ufs, local, noatime, soft-updates) /dev/ad0s1f on /usr (ufs, local, noatime, soft-updates) /dev/ad0s1e on /var (ufs, local, noatime, soft-updates) mfs:22 on /tmp (mfs, asynchronous, local, noatime) /dev/ad0s2 on /dos/c (msdos, local) /dev/ad0s5 on /dos/d (msdos, local) /dev/ad0s6 on /dos/e (msdos, local) procfs on /proc (procfs, local) procfs on /opt/chrooted_vimage/proc (procfs, local) /usr on /opt/chrooted_vimage/usr (null, local, read-only) tpx30# vimage test1 Switched to vimage test1 %mount procfs on /proc (procfs, local) /usr on /usr (null, local, read-only) % > 9/ how does VIPA differ from the JAIL address binding? Actually, VIPA feature should be considered completely independent of network stack virtualization work. The jail address is usually bound to an alias address configured on a physical interface. When this interface goes down, all the connections using this address drop dead instantly. VIPA is a loopback-type internal interface that will always remain up regardless of the physical network topology changes. If the system has multiple physical interfaces, and an alternative path can be established following an NIC or network route outage, the connections bound to VIPA will survive. Anyhow, the idea is borrowed from IBM's OS/390 TCP/IP implementation, so you can find more on this concept on http://www-1.ibm.com/servers/eserver/zseries/networking/vipa.html > 10/ could you use ng_eiface instead of if_ve? Most probably yes, but my system crashed each time when trying to configure ng_eiface, so I just took another path and constructed my own stub ethernet interface... > 11/ why was ng_bridge unsuitable for your use? Both the native and netgraph bridging code, I believe, were designed with the presumption that only one "upper" hook is really needed to establish the communication to kernel's single network stack. However, this concept doesn't hold on a kernel with multiple network stacks. I just picked the native bridging code first and extended it to support hooking to multiple "upper" hooks. The similar extensions have yet to be applied to ng_bridge, I just didn't have time to implement the same functionality in two different frameworks. > 12/ can you elaborate on the following: > # fix netgraph interface node naming > # fix the bugs in base networking code (statistics in > "native" bridging, additional logic for ng_bridge...) When the interface is moved to a different virtual image, it's unit number gets reassigned, so the interface that was named say "vlan3" in the master virtual image, will become "vlan0" when assigned to the child. The same thing happens when the child virtual image returns the interface back to its parent. The naming of netgraph nodes associated with interfaces (ng_iface, ng_ether) should be updated accordingly, which is currently not done. I also considered virtualizing a netgraph stack, this would be also very cool if each virtual image could manage its own netgraph tree. However, when weighting implementation priorities, I concluded that this was something that could wait for other more basic things to be reworked properly first. Therefore in the current implementation it is possible to manage the netgraph subsystem only from the "master" virtual image. Hope this was enough elaboration for actually testing the code :) Have fun, Marko To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Oct 23 17:57:23 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E325B37B401 for <net@freebsd.org>; Wed, 23 Oct 2002 17:57:21 -0700 (PDT) Received: from aaz.links.ru (aaz.links.ru [193.125.152.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id 013FD43E65 for <net@freebsd.org>; Wed, 23 Oct 2002 17:57:21 -0700 (PDT) (envelope-from babolo@aaz.links.ru) Received: from aaz.links.ru (aaz.links.ru [193.125.152.37]) by aaz.links.ru (8.12.6/8.12.6) with ESMTP id g9O0vgDh082752; Thu, 24 Oct 2002 04:57:42 +0400 (MSD) (envelope-from babolo@aaz.links.ru) Received: (from babolo@localhost) by aaz.links.ru (8.12.6/8.12.6/Submit) id g9O0vgjV082751; Thu, 24 Oct 2002 04:57:42 +0400 (MSD) Message-Id: <200210240057.g9O0vgjV082751@aaz.links.ru> Subject: Re: which resources ends with ste interface? X-ELM-OSV: (Our standard violations) hdr-charset=KOI8-R; no-hdr-encoding=1 In-Reply-To: <B9DC8CE2.28A6A%michael@staff.openaccess.org> To: Michael DeMan <michael@staff.openaccess.org> Date: Thu, 24 Oct 2002 04:57:42 +0400 (MSD) From: "."@babolo.ru Cc: net@freebsd.org X-Mailer: ELM [version 2.4ME+ PL99b (25)] MIME-Version: 1.0 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org > We have a nightmare situation with DFE-580TX 4-port cards that use the ste > driver. The driver seems to just choke. I'm not sure if its an issue with > PCI interrupts or what. It throttles back the time-outs, but even then > after its been up for days one of the interfaces will start acting up and > our LAN seems more like an ISDN to the file server. I have router with 1sw~(2)#ifconfig -l dc0 dc1 dc2 dc3 xl0 xl1 xl2 ste0 ste1 ste2 ste3 lp0 ppp0 stf0 faith0 vlan0 vlan1 vlan2 vlan3 vlan4 vlan5 vlan6 vlan7 lo0 lo1 lo2 lo3 Where dc0..3 and ste0..3 are 4-port cards total traffic about 150Gbyte/day. It works. Thank you for alert about DFE-580TX The hardware selection is like mined field - do not know where explode :-(( dc0: <Intel 21143 10/100BaseTX> port 0x7c00-0x7c7f mem 0xdfdffc00-0xdfdfffff irq 12 at device 4.0 on pci2 dc1: <Intel 21143 10/100BaseTX> port 0x7800-0x787f mem 0xdfdff800-0xdfdffbff irq 10 at device 5.0 on pci2 dc2: <Intel 21143 10/100BaseTX> port 0x7400-0x747f mem 0xdfdff400-0xdfdff7ff irq 5 at device 6.0 on pci2 dc3: <Intel 21143 10/100BaseTX> port 0x7000-0x707f mem 0xdfdff000-0xdfdff3ff irq 11 at device 7.0 on pci2 xl0: <3Com 3c905C-TX Fast Etherlink XL> port 0xdc00-0xdc7f mem 0xdfffff80-0xdffffff f irq 10 at device 10.0 on pci0 using shared irq10. xl1: <3Com 3c905-TX Fast Etherlink XL> port 0xd800-0xd83f irq 11 at device 12.0 on pci0 using shared irq11. xl2: <3Com 3c905-TX Fast Etherlink XL> port 0xd400-0xd43f irq 12 at device 13.0 on pci0 using shared irq12. ste0: <D-Link DFE-550TX 10/100BaseTX> port 0x9c00-0x9c7f irq 10 at device 4.0 on pc i3 ste1: <D-Link DFE-550TX 10/100BaseTX> port 0x9800-0x987f irq 5 at device 5.0 on pci 3 ste2: <D-Link DFE-550TX 10/100BaseTX> port 0x9400-0x947f irq 11 at device 6.0 on pc i3 ste3: <D-Link DFE-550TX 10/100BaseTX> port 0x9000-0x907f irq 12 at device 7.0 on pc i3 > Michael F. DeMan > Director of Technology > OpenAccess Internet Services > 1305 11th St., 3rd Floor > Bellingham, WA 98225 > Tel 360-647-0785 x204 > Fax 360-738-9785 > michael@staff.openaccess.org -- @BABOLO http://links.ru/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Oct 23 18: 0:18 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CF77537B401; Wed, 23 Oct 2002 18:00:14 -0700 (PDT) Received: from sccrmhc01.attbi.com (sccrmhc01.attbi.com [204.127.202.61]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3727043E4A; Wed, 23 Oct 2002 18:00:14 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by sccrmhc01.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20021024010013.DUCD24829.sccrmhc01.attbi.com@InterJet.elischer.org>; Thu, 24 Oct 2002 01:00:13 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id RAA38117; Wed, 23 Oct 2002 17:43:46 -0700 (PDT) Date: Wed, 23 Oct 2002 17:43:45 -0700 (PDT) From: Julian Elischer <julian@elischer.org> To: Marko Zec <zec@tel.fer.hr> Cc: "J. 'LoneWolf' Mattsson" <lonewolf-freebsd@earthmagic.org>, freebsd-net@freebsd.org, freebsd-arch@freebsd.org Subject: Re: RFC: BSD network stack virtualization In-Reply-To: <3DB73F31.5F02609C@tel.fer.hr> Message-ID: <Pine.BSF.4.21.0210231737330.36940-100000@InterJet.elischer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org On Thu, 24 Oct 2002, Marko Zec wrote: > Julian Elischer wrote: > > > > 11/ why was ng_bridge unsuitable for your use? > > Both the native and netgraph bridging code, I believe, were designed with > the presumption that only one "upper" hook is really needed to establish the > communication to kernel's single network stack. However, this concept > doesn't hold on a kernel with multiple network stacks. I just picked the > native bridging code first and extended it to support hooking to multiple > "upper" hooks. The similar extensions have yet to be applied to ng_bridge, I > just didn't have time to implement the same functionality in two different > frameworks. ng_bridge doesn't really distinguish between hooks to upper and lower detinations. it only knows wha tMAC addresses are seen to come from each hook and ensures that packets destined to those addresses are sent to those hooks.. you can have as many 'upper' hooks as you wish (and there are some uses for that). > > > 12/ can you elaborate on the following: > > # fix netgraph interface node naming > > # fix the bugs in base networking code (statistics in > > "native" bridging, additional logic for ng_bridge...) > > When the interface is moved to a different virtual image, it's unit number > gets reassigned, so the interface that was named say "vlan3" in the master > virtual image, will become "vlan0" when assigned to the child. The same > thing happens when the child virtual image returns the interface back to its > parent. The naming of netgraph nodes associated with interfaces (ng_iface, > ng_ether) should be updated accordingly, which is currently not done. > I also considered virtualizing a netgraph stack, this would be also very > cool if each virtual image could manage its own netgraph tree. However, when > weighting implementation priorities, I concluded that this was something > that could wait for other more basic things to be reworked properly first. > Therefore in the current implementation it is possible to manage the > netgraph subsystem only from the "master" virtual image. > > Hope this was enough elaboration for actually testing the code :) it's difficult because my test machines run -current (my 4.x machines are dedicated to production purposes though I may be able try with one.. > > Have fun, Thankyou.. p.s. I should drop down to Croatia next time I'm in Budapest. I'm told it's beautiful. p.p.s cute bear cubs on your site! > > Marko > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Oct 23 18:45: 0 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6B13937B401 for <freebsd-net@FreeBSD.ORG>; Wed, 23 Oct 2002 18:44:58 -0700 (PDT) Received: from isilon.com (isilon.com [65.101.129.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id 049C443E42 for <freebsd-net@FreeBSD.ORG>; Wed, 23 Oct 2002 18:44:58 -0700 (PDT) (envelope-from bbaumann@isilon.com) Received: from localhost (localhost [127.0.0.1]) by isilon.com (8.12.2/8.11.1) with ESMTP id g9O1iv3C041120 for <freebsd-net@FreeBSD.ORG>; Wed, 23 Oct 2002 18:44:57 -0700 (PDT) (envelope-from bbaumann@isilon.com) Date: Wed, 23 Oct 2002 18:44:57 -0700 (PDT) From: Bill Baumann <bbaumann@isilon.com> To: freebsd-net@FreeBSD.ORG Subject: tcp_input's header prediction and a collapsing send window In-Reply-To: <20021015115315.U7412-100000@mammoth.eat.frenchfries.net> Message-ID: <Pine.BSF.4.21.0210221616110.17276-100000@isilon.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org I'm experiencing a bug where snd_wnd collapses. I see snd_wnd approach zero even though data is sent/received and ack'ed successfully. After taking a close look at tcp_input, I think I see a senario where this could happen. Say header prediction handles ~2 GB of data without problems, then a retransmission happens. snd_wnd starts collapsing as it should. The header prediction code is correctly skipped as the snd_wnd no long matches the advertised window. We recover from the retransmission, *BUT* the code that reopens window is skipped because of rolled over sequence numbers. In the ack processing code (step 6), the variable snd_wl1 tracks the newest sequence number that we've seen. It helps prevent snd_wnd from being reopened on re-transmitted data. If snd_wl1 is greater than received sequence #, we skip it. This is fine unless we're 2^31 bytes ahead and SEQ_LT says we're behind. Since snd_wl1 is only updated if the condition is true -- we're stuck. snd_wl1 is only updated with in SYN/FIN processing code and in step 6. So if we process 2GB in the header prediction code -- where the step 6 never executes, and then somehow reach step 6. snd_wnd collapses and tcp_output stops sending. I have a trace mechanism that dumps various tcp_input variables that corroborates this theory. I have lined this up with tcpdump. The trace shows snd_wnd collapsing and snd_wl1 > th_seq even as healthy traffic is transmitted and received. The outcome is a halted transmitter. Possible remedy: update snd_wl1 in the header prediction code. What do you all think? Is this real? Or am I missing something? Regards, Bill Baumann To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Oct 23 19:42:13 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 32EB237B401; Wed, 23 Oct 2002 19:42:12 -0700 (PDT) Received: from mail.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7C5BD43E3B; Wed, 23 Oct 2002 19:42:11 -0700 (PDT) (envelope-from don@sandvine.com) Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19) id <42S9VG7Z>; Wed, 23 Oct 2002 22:42:10 -0400 Message-ID: <FE045D4D9F7AED4CBFF1B3B813C8533701022D4F@mail.sandvine.com> From: Don Bowman <don@sandvine.com> To: "'freebsd-stable@freebsd.org'" <freebsd-stable@freebsd.org>, "'freebsd-net@freebsd.org'" <freebsd-net@freebsd.org> Subject: Machine becomes non-responsive, only ^T shows it as alive under l oad: IPFW, TCP proxying Date: Wed, 23 Oct 2002 22:41:58 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org I have an application listening on an ipfw 'fwd' rule. I'm sending ~3K new sessions per second to it. It has to turn around and issue some of these out as a proxy, in response to which some of them the destination host won't exist. I have RST limiting on. I'm seeing messages like: Limiting open port RST response from 1312 to 200 packets per second come out sometimes. After a while of such operation (~1/2 hour), the machine becomes unresponsive: the network interfaces no longer respond, the serial console responds to ^T yielding a status line, but ^C etc do nothing, and the bash which was there won't give me a prompt. ^T indicates my bash is running, 0% of CPU in use, etc. I have no choice but to power-cycle it. Any suggestions for how one would start debugging this to find out where its stuck, and how? This is running 4.7 STABLE on a single XEON 2.0 GHz, 1GB of memory. The bandwidth wasn't that high, varying between 3 and 30Mbps. Perhaps related, sometimes I get: bge0: watchdog timeout -- resetting The only NIC which is active is bge0. I have an 'em0' which is idle (no IP), and an fxp0 (which has an IP but is idle). --don (don@sandvine.com www.sandvine.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Oct 23 20:39:26 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0F82437B401 for <freebsd-net@FreeBSD.ORG>; Wed, 23 Oct 2002 20:39:25 -0700 (PDT) Received: from pursued-with.net (adsl-66-125-9-242.dsl.sndg02.pacbell.net [66.125.9.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8116B43E6E for <freebsd-net@FreeBSD.ORG>; Wed, 23 Oct 2002 20:39:19 -0700 (PDT) (envelope-from Kevin_Stevens@pursued-with.net) Received: from pursued-with.net (fffinch [192.168.168.101]) by pursued-with.net (8.12.6/8.12.5) with ESMTP id g9O3dIIB011778; Wed, 23 Oct 2002 20:39:19 -0700 (PDT) (envelope-from Kevin_Stevens@pursued-with.net) Date: Wed, 23 Oct 2002 20:39:20 -0700 Subject: Re: Machine becomes non-responsive, only ^T shows it as alive under l oad: IPFW, TCP proxying Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: "'freebsd-net@freebsd.org'" <freebsd-net@FreeBSD.ORG> To: Don Bowman <don@sandvine.com> From: Kevin Stevens <Kevin_Stevens@pursued-with.net> In-Reply-To: <FE045D4D9F7AED4CBFF1B3B813C8533701022D4F@mail.sandvine.com> Message-Id: <2E426952-E702-11D6-B91F-003065715DA8@pursued-with.net> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org On Wednesday, Oct 23, 2002, at 19:41 US/Pacific, Don Bowman wrote: > I have an application listening on an ipfw 'fwd' rule. > I'm sending ~3K new sessions per second to it. It > has to turn around and issue some of these out as > a proxy, in response to which some of them the destination > host won't exist. > > I have RST limiting on. I'm seeing messages like: > Limiting open port RST response from 1312 to 200 packets per second > > come out sometimes. > > After a while of such operation (~1/2 hour), the machine > becomes unresponsive: the network interfaces no longer respond, > the serial console responds to ^T yielding a status line, > but ^C etc do nothing, and the bash which was there won't > give me a prompt. > > ^T indicates my bash is running, 0% of CPU in use, etc. > > I have no choice but to power-cycle it. > > Any suggestions for how one would start debugging this to > find out where its stuck, and how? At a guess, you need to tune the state-table retention time down. KeS To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Oct 23 20:50:49 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A04AD37B401 for <net@freebsd.org>; Wed, 23 Oct 2002 20:50:47 -0700 (PDT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 37BCC43E77 for <net@freebsd.org>; Wed, 23 Oct 2002 20:50:47 -0700 (PDT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (IDENT:brdavis@localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.12.3/8.12.3) with ESMTP id g9O3ods7023506 for <net@freebsd.org>; Wed, 23 Oct 2002 20:50:39 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.3/8.12.3/Submit) id g9O3oc0Q023503 for net@freebsd.org; Wed, 23 Oct 2002 20:50:38 -0700 Date: Wed, 23 Oct 2002 20:50:38 -0700 From: Brooks Davis <brooks@one-eyed-alien.net> To: net@freebsd.org Subject: [PATCH] switching to if_xname Message-ID: <20021023205038.B30597@Odin.AC.HMC.Edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="3MwIy2ne0vdjdPXF" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-Virus-Scanned: by amavisd-milter (http://amavis.org/) on odin.ac.hmc.edu Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org --3MwIy2ne0vdjdPXF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable As previously discussed, I've created a patch to replace if_unit and if_name with if_xname in struct ifnet following the example of NetBSD and OpenBSD. I've tried to place the more intresting parts of the diff near the top. This patch will break ports which use libkvm to read interface statistics. This effects at least wmnet and wmnet2 (though both segfault on current without this patch). The patches to fix this should be trivial since most of those applications probably support NetBSD or OpenBSD and I plan to bump __FreeBSD_version. Other then those issues and a generalization of interface globing in IPFW, this patch should be a giant no-op from the user perspective. Real features will come later, but the API/ABI change needs to happen soon or it's going to be a 6.0 feature. I'm running this patch on my laptop with a GENERIC kernel without any problems so far. For all it's size, most of the changes are log() or printf() calls plus a fairly consistant change to each network driver's attach function so this should be generally low impact. The patch is available at the URL below. I tried to send a copy to the list, but it looks like it got silently tossed as too large. If you want a copy e-mailed to you, feel free to ask me for one. http://people.freebsd.org/~brooks/patches/if_xname.diff Please review. Thanks, Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --3MwIy2ne0vdjdPXF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9t24MXY6L6fI4GtQRApV1AKCNFZ4B0PohaEtX+elB8Utz5BmCdACeLJ97 sPJct49DaK3emB86XZaEwNk= =Puo5 -----END PGP SIGNATURE----- --3MwIy2ne0vdjdPXF-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Oct 23 23: 6:32 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 19CCB37B407; Wed, 23 Oct 2002 23:06:31 -0700 (PDT) Received: from out6.mx.nwbl.wi.voyager.net (out6.mx.nwbl.wi.voyager.net [169.207.3.77]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8484743E42; Wed, 23 Oct 2002 23:06:30 -0700 (PDT) (envelope-from silby@silby.com) Received: from [10.1.1.6] (d173.as12.nwbl0.wi.voyager.net [169.207.136.175]) by out6.mx.nwbl.wi.voyager.net (Postfix) with ESMTP id A849DDABEF; Thu, 24 Oct 2002 01:06:28 -0500 (CDT) Date: Thu, 24 Oct 2002 01:11:15 -0500 (CDT) From: Mike Silbersack <silby@silby.com> To: Bruce Evans <bde@zeta.org.au> Cc: freebsd-net@FreeBSD.ORG, <jlemon@FreeBSD.ORG>, Harti Brandt <brandt@fokus.gmd.de> Subject: Re: MII problem, need more eyes In-Reply-To: <20021022174319.V13842-100000@gamplex.bde.org> Message-ID: <20021023210943.W4698-100000@patrocles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org On Tue, 22 Oct 2002, Bruce Evans wrote: > This return of 0 is apparently intentional. The comment before this > says: > > Here the "However" clause is not in RELENG_4. Returning 0 gets the > status updated. I think this is just too expensive to do every second. > Autonegotiation is only retried every 17 seconds (every 5 seconds in > RELENG_4). You're right, it looks like this is new functionality, not just code refactoring. I was hoping for a quick fix, and overlooked this. There are two things I think that I can do to reduce the amount of time taken up... #1, Don't do the status update every second, only have it run every 10 seconds or so. #2, Reduce the number of PHY operations. mii_phy_tick reads the status register, then nsphy_status rereads it basically immediately. I'll have to examine how the other phy drivers operate in this aspect. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Oct 24 1:50:21 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9509637B401 for <freebsd-net@freebsd.org>; Thu, 24 Oct 2002 01:50:20 -0700 (PDT) Received: from scribble.fsn.hu (scribble.fsn.hu [193.224.40.95]) by mx1.FreeBSD.org (Postfix) with SMTP id 908B643E42 for <freebsd-net@freebsd.org>; Thu, 24 Oct 2002 01:50:18 -0700 (PDT) (envelope-from bra@fsn.hu) Received: (qmail 31450 invoked by uid 1000); 24 Oct 2002 08:50:13 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 24 Oct 2002 08:50:13 -0000 Date: Thu, 24 Oct 2002 10:50:13 +0200 (CEST) From: Attila Nagy <bra@fsn.hu> To: Peter Erickson <redlamb@redlamb.net> Cc: FreeBSD-Net List <freebsd-net@freebsd.org> Subject: Re: Ethernet bonding with netgraph In-Reply-To: <20021018161748.GA16899@redlamb.net> Message-ID: <Pine.LNX.4.44.0210241048390.27438-100000@scribble.fsn.hu> References: <20021018161748.GA16899@redlamb.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org Hello, > Could someone please explain to me how to setup a channel-bond between > two ethernet cards? http://people.freebsd.org/~paul/FEC/ From there, you can fetch the needed source. You have to copy it into your source tree, compile and install. After you have the ng_fec module in /modules, see modules/netgraph/fec/load for defining the fec interface. ----------[ Free Software ISOs - http://www.fsn.hu/?f=download ]---------- Attila Nagy e-mail: Attila.Nagy@fsn.hu Free Software Network (FSN.HU) phone @work: +361 210 1415 (194) cell.: +3630 306 6758 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Oct 24 4:52:32 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1C86737B401 for <freebsd-net@freebsd.org>; Thu, 24 Oct 2002 04:52:31 -0700 (PDT) Received: from otdel-1.org (draculina.otdel-1.org [195.230.89.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 854AB43E42 for <freebsd-net@freebsd.org>; Thu, 24 Oct 2002 04:52:29 -0700 (PDT) (envelope-from bsd#nms@otdel-1.org) Received: by otdel-1.org (CommuniGate Pro PIPE 4.0) with PIPE id 2280564; Thu, 24 Oct 2002 15:52:13 +0400 Date: Thu, 24 Oct 2002 15:52:08 +0400 From: Nikolai Saoukh <bsd#nms@otdel-1.org> To: freebsd-net@FreeBSD.ORG Subject: Re: For those who had problems with MPD server and win clients Message-ID: <20021024115208.GA23575@otdel1.org> Mail-Followup-To: freebsd-net@FreeBSD.ORG References: <20021018132732.GA27692@otdel1.org> <200210201818.g9KIIdqF048199@arch20m.dellroad.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200210201818.g9KIIdqF048199@arch20m.dellroad.org> User-Agent: Mutt/1.5.1i X-Mailer: CommuniGate Pro CLI mailer Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org Applying patches to mpd does not fix bugs in MS software ;-) In MS software (Win XP Pro SP1 at least) there is the option 'negotiate multi-link for single link connections'. Unfortunately it can't handle it, when succesfully negotiated. One can verify it at (page to frame 82) http://www.otdel-1.org/nms/mpd/wire.txt (~700Kb) MS is not alone. Ethereal-0.9.7 can't handle rfc1990 fragments too ;-( IMHO, to make mpd damnMSproof, the interface mtu for single link scenario should be set to link mru. And if multilink negotiated, then mtu should be decremented for rfc1990 overhead to avoid fragmentation at all. Like this --- bund.c.orig Thu Oct 24 04:10:45 2002 +++ bund.c Thu Oct 24 15:44:12 2002 @@ -547,12 +547,13 @@ mtu = NG_IFACE_MTU_DEFAULT; /* Reset to default settings */ break; case 1: - if (!bund->multilink) { /* If no multilink, use peer MRU */ - mtu = MIN(bund->links[the_link]->lcp.peer_mru, + mtu = MIN(bund->links[the_link]->lcp.peer_mru, bund->links[the_link]->phys->type->mtu); - break; + if (bund->multilink) { + /* If multilink, decrease mtu to avoid MS bug */ + mtu -= 4; /* XXX: proper name for 4? */ } - /* FALLTHROUGH */ + break; default: /* We fragment everything, use bundle MRRU */ mtu = bund->mp.peer_mrru; break; P.S. Anyone knows how to submit bug report to MS & Ethereal? [without silly registrations] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Oct 24 6:38:21 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5B9DF37B401 for <freebsd-net@FreeBSD.ORG>; Thu, 24 Oct 2002 06:38:20 -0700 (PDT) Received: from web.cs.ndsu.nodak.edu (web.cs.ndsu.NoDak.edu [134.129.125.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id A6E6143E6A for <freebsd-net@FreeBSD.ORG>; Thu, 24 Oct 2002 06:38:19 -0700 (PDT) (envelope-from tinguely@web.cs.ndsu.nodak.edu) Received: (from tinguely@localhost) by web.cs.ndsu.nodak.edu (8.11.4/8.11.4) id g9ODcAx33485; Thu, 24 Oct 2002 08:38:10 -0500 (CDT) (envelope-from tinguely) Date: Thu, 24 Oct 2002 08:38:10 -0500 (CDT) From: mark tinguely <tinguely@web.cs.ndsu.nodak.edu> Message-Id: <200210241338.g9ODcAx33485@web.cs.ndsu.nodak.edu> To: bbaumann@isilon.com, freebsd-net@FreeBSD.ORG Subject: Re: tcp_input's header prediction and a collapsing send window In-Reply-To: <Pine.BSF.4.21.0210221616110.17276-100000@isilon.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org > After taking a close look at tcp_input, I think I see a senario where this > could happen. Say header prediction handles ~2 GB of data without > problems, then a retransmission happens. snd_wnd starts collapsing as it > should. The header prediction code is correctly skipped as the snd_wnd no > long matches the advertised window. We recover from the retransmission, > *BUT* the code that reopens window is skipped because of rolled over > sequence numbers. probably in the same sequence, we took a possibly un-necessay timeout because quick recovery was suppressed because of a wrapped snd_recover. These variables should be kept more up to date. --Mark Tinguely To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Oct 24 7:11:26 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 41ABA37B401 for <freebsd-net@FreeBSD.ORG>; Thu, 24 Oct 2002 07:11:25 -0700 (PDT) Received: from mail.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id B144943E75 for <freebsd-net@FreeBSD.ORG>; Thu, 24 Oct 2002 07:11:24 -0700 (PDT) (envelope-from don@sandvine.com) Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19) id <42S9VHKF>; Thu, 24 Oct 2002 10:11:23 -0400 Message-ID: <FE045D4D9F7AED4CBFF1B3B813C8533701022D52@mail.sandvine.com> From: Don Bowman <don@sandvine.com> To: 'Kevin Stevens' <Kevin_Stevens@pursued-with.net>, Don Bowman <don@sandvine.com> Cc: "'freebsd-net@freebsd.org'" <freebsd-net@FreeBSD.ORG> Subject: RE: Machine becomes non-responsive, only ^T shows it as alive und er l oad: IPFW, TCP proxying Date: Thu, 24 Oct 2002 10:11:22 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org > From: Kevin Stevens [mailto:Kevin_Stevens@pursued-with.net] > > Any suggestions for how one would start debugging this to > > find out where its stuck, and how? > > At a guess, you need to tune the state-table retention time down. If by that you mean the MSL? I've set the MSL to 5000 in this case. Or do you mean something else? Should the machine lockup this way? How does one debug where its gone? --don (don@sandvine.com www.sandvine.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Oct 24 7:13:27 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3985537B401 for <freebsd-net@FreeBSD.ORG>; Thu, 24 Oct 2002 07:13:26 -0700 (PDT) Received: from mail.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id B499F43E75 for <freebsd-net@FreeBSD.ORG>; Thu, 24 Oct 2002 07:13:25 -0700 (PDT) (envelope-from ddolson@sandvine.com) Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19) id <42S9VHKM>; Thu, 24 Oct 2002 10:13:25 -0400 Message-ID: <FE045D4D9F7AED4CBFF1B3B813C85337A6BA9F@mail.sandvine.com> From: Dave Dolson <ddolson@sandvine.com> To: freebsd-net@FreeBSD.ORG Subject: Method to share kernel mbufs with a user process? Date: Thu, 24 Oct 2002 10:13:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org Until the multi-threaded kernel becomes stable... (I'm using 4.6) Is there a quick & dirty way of sharing mbufs with a user process? The objective is to get the advantages of multi-processors yet avoid the syscall overhead for each packet. E.g., a netgraph node could queue mbufs in memory shared with a user process. One idea is to write a device with which I can mmap the entire kernel memory space. A problem with this is that it doesn't seem to be legal to mmap to the same virtual addresses (0xc0000000) used by the kernel, so all pointers would have to be translated. I'm hoping someone knows of a better mechanism which I haven't found yet. (Obviously multi-threading of the kernel will meet the needs eventually, so I don't want to do any major kernel hacking.) Thanks for any suggestions, David Dolson To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Oct 24 9: 4:33 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 53CEC37B404; Thu, 24 Oct 2002 09:04:28 -0700 (PDT) Received: from mail.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E9FD43E75; Thu, 24 Oct 2002 09:04:27 -0700 (PDT) (envelope-from don@sandvine.com) Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19) id <42S9VHRK>; Thu, 24 Oct 2002 12:04:21 -0400 Message-ID: <FE045D4D9F7AED4CBFF1B3B813C8533701022D56@mail.sandvine.com> From: Don Bowman <don@sandvine.com> To: Don Bowman <don@sandvine.com>, "'freebsd-stable@freebsd.org'" <freebsd-stable@freebsd.org>, "'freebsd-net@freebsd.org'" <freebsd-net@freebsd.org> Subject: RE: Machine becomes non-responsive, only ^T shows it as alive und er l oad: IPFW, TCP proxying Date: Thu, 24 Oct 2002 12:04:20 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org > > I have an application listening on an ipfw 'fwd' rule. > I'm sending ~3K new sessions per second to it. It > has to turn around and issue some of these out as > a proxy, in response to which some of them the destination > host won't exist. > > I have RST limiting on. I'm seeing messages like: > Limiting open port RST response from 1312 to 200 packets per second I've appended below the stack trace. I will re-run and try to reproduce with a -g kernel & source. Any suggestions are welcome. db> trace Debugger(c03572e9) at Debugger+0x34 scgetc(c341a000,2,c21f100e,c03c4480,0) at scgetc+0x3f2 sckbdevent(c03c4480,0,c341a000,c21f100e,e1a84bd8) at sckbdevent+0x1c9 atkbd_intr(c03c4480,0,e1a84bb0,c02e2aaf,c03c4480) at atkbd_intr+0x22 atkbd_isa_intr(c03c4480,66190000,18,10,15ad0010) at atkbd_isa_intr+0x18 Xresume1() at Xresume1+0x35 --- interrupt, eip = 0xc020abbc, esp = 0xe1a84ba0, ebp = 0xe1a84bb0 --- m_xhalf(e1a84c64,c,e1a84bd8,c363e180,4a) at m_xhalf+0x34 bpf_filter(c363e100,e1a84c64,4a,0) at bpf_filter+0xbe bpf_mtap(c3408000,e1a84c64) at bpf_mtap+0x43 ether_input(c3408000,c21f1002,c21c8c00) at ether_input+0x6a bge_rxeof(c3408000,c34080b8,c220b900,e1a84d58,c02e4ac5) at bge_rxeof+0x1f2 bge_intr(c3408000,62000000,c3630018,c2200010,10) at bge_intr+0xf1 Xresume16() at Xresume16+0x38 --- interrupt, eip = 0xc02fdd4c, esp = 0xe1a84d1c, ebp = 0xe1a84d58 --- splx(c3408000,c220b900,c3408000,3630901,0) at splx+0x30 ether_output(c3408000,c220b900,c342b2d0,c370d000,de6d1160) at ether_output+0x392 ip_output(c220b900,0,de6d10dc,0,0) at ip_output+0xa0d tcp_output(de6d1160,2,de171980,c037f208,0) at tcp_output+0xae2 tcp_usr_shutdown(de171980,0,e1a84f80,dc348f20,e1a84f24) at tcp_usr_shutdown+0x4e soshutdown(de171980,2,2,dc348f20,e1a84f80) at soshutdown+0x3d shutdown(dc348f20,e1a84f80,281e9944,0,2) at shutdown+0x34 syscall2(2f,2f,815002f,2,0) at syscall2+0x221 Xint0x80_syscall() at Xint0x80_syscall+0x2b --don (don@sandvine.com www.sandvine.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Oct 24 10:47:53 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 136C037B401 for <net@FreeBSD.ORG>; Thu, 24 Oct 2002 10:47:51 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 979B543E3B for <net@FreeBSD.ORG>; Thu, 24 Oct 2002 10:47:50 -0700 (PDT) (envelope-from larse@ISI.EDU) Received: from isi.edu (nik.isi.edu [128.9.168.58]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g9OHlnC23057; Thu, 24 Oct 2002 10:47:49 -0700 (PDT) Message-ID: <3DB83245.8010806@isi.edu> Date: Thu, 24 Oct 2002 10:47:49 -0700 From: Lars Eggert <larse@ISI.EDU> User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:1.2b) Gecko/20021016 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: Luigi Rizzo <rizzo@icir.org> Cc: net@FreeBSD.ORG Subject: Re: Bridging when one interface has no carrier References: <3D61224B.2020902@isi.edu> <20020819102951.A38869@iguana.icir.org> In-Reply-To: <3D61224B.2020902@isi.edu> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050506060300040200010400" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org This is a cryptographically signed message in MIME format. --------------ms050506060300040200010400 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Luigi Rizzo wrote: > I guess the responsible of the problem is this part of code > in sys/net/if_ethersubr.c:ether_demux(): > > /* Discard packet if interface is not up */ > if ((ifp->if_flags & IFF_UP) == 0) { > m_freem(m); > return; > } > > which is somewhat funny, because once we have the packet, we > might as well process it. That block is inside a "if (!(BDG_ACTIVE(ifp)))" block though - won't it be bypassed when bridging is enabled on the interface anyway? (I've disabled the block, but packets are still not bridged.) Lars -- Lars Eggert <larse@isi.edu> USC Information Sciences Institute --------------ms050506060300040200010400 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJtjCC AzgwggKhoAMCAQICEGZFcrfMdPXPY3ZFhNAukQEwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vydmlj ZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkG CSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAw MDBaFw0wNDA4MjcyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2Vy dGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAw LjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZ gpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqd knWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYALQmJ7JRr6aFp AgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTI5NzAS BgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQAxsUtH XfkBceX1U2xdedY9mMAmE2KBIqcS+CKV6BtJtyd7BDm6/ObyJOuR+r3sDSo491BVqGz3Da1M G7wD9LXrokefbKIMWI0xQgkRbLAaadErErJAXWr5edDqLiXdiuT82w0fnQLzWtvKPPZE6iZp h39Ins6ln+eE2MliYq0FxjCCAzkwggKioAMCAQICAwglQTANBgkqhkiG9w0BAQQFADCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMB4XDTAyMDgyNDE4NTMzOVoX DTAzMDgyNDE4NTMzOVowVDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYD VQQDEwtMYXJzIEVnZ2VydDEcMBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBANI2Rrt4ggaQ/IrOsDeOm2H4/R5FRIL6JjDY3StE aogp1r23WKniQ1Vj98Nu5WxlaZ3Iam3Jen5T66H8u7rtMNpK4qAeAGoBsVeyVr1+CTFeuv+m xCh7BvBJwhLdm0zDaoDT05YKYZaqtsT+F286FWJQg31Xtf+vTKLVVrHcsafnteyal2NEt7Ac yZZfjsVLwxp2Lq3cwYfRQRoo7/yCVzS7HsgM6jmbO4taEMo4yC2rpnUbWEUCDTaCYgpAXzAl oiNk7GDh0wz2s5ZSnHRvNSBMAjCmpNtSYHfXFI1ANwrrrHIJ7Ei83+XN32PWY4OPzO3iown9 VR+vM+8lNx9OX28CAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIBBAQTTDJ1TXlmZkJO VWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEEBQADgYEAXcrIlKmPLM/r8r3oz2ZLPLaT1AyMjYTZY2qq/R7SUtFa9BNlTIFh DG78QKfJ9lo2LMzTPQqMZgNLmj95GbNPI8P8OIq2K6MeCZWz08ROackqTFP6xWbIFIfXcBVR 1dZnDDyDKBBh05KkvyTPawSQyOBUeNBfQUyO4TE+3o58U8UwggM5MIICoqADAgECAgMIJUEw DQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MDAeFw0wMjA4MjQxODUzMzlaFw0wMzA4MjQxODUzMzlaMFQxDzANBgNVBAQTBkVnZ2VydDEN MAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkqhkiG9w0BCQEWDWxh cnNlQGlzaS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDSNka7eIIGkPyK zrA3jpth+P0eRUSC+iYw2N0rRGqIKda9t1ip4kNVY/fDbuVsZWmdyGptyXp+U+uh/Lu67TDa SuKgHgBqAbFXsla9fgkxXrr/psQoewbwScIS3ZtMw2qA09OWCmGWqrbE/hdvOhViUIN9V7X/ r0yi1Vax3LGn57XsmpdjRLewHMmWX47FS8Madi6t3MGH0UEaKO/8glc0ux7IDOo5mzuLWhDK OMgtq6Z1G1hFAg02gmIKQF8wJaIjZOxg4dMM9rOWUpx0bzUgTAIwpqTbUmB31xSNQDcK66xy CexIvN/lzd9j1mODj8zt4qMJ/VUfrzPvJTcfTl9vAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIB ADAaMBgCAQQEE0wydU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVk dTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAF3KyJSpjyzP6/K96M9mSzy2k9QM jI2E2WNqqv0e0lLRWvQTZUyBYQxu/ECnyfZaNizM0z0KjGYDS5o/eRmzTyPD/DiKtiujHgmV s9PETmnJKkxT+sVmyBSH13AVUdXWZww8gygQYdOSpL8kz2sEkMjgVHjQX0FMjuExPt6OfFPF MYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MAIDCCVBMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTAyMTAyNDE3NDc0OVowIwYJKoZIhvcNAQkEMRYEFB9Ytn7/IaQRoUcDucY4 W15MC3NNMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3EAQxgZ0w gZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNh cGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNl czEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCCVBMIGtBgsq hkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2Fw ZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRp ZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44 LjMwAgMIJUEwDQYJKoZIhvcNAQEBBQAEggEAY/3UJfrUeDjGoBkbSv7dlLHZQqsAAWFgj9qf CmhHITbHssOau3BgLKwsH9bHrzTM+Kwd8Wosy+3eWNAVWXN9zuw7pSl7hReQR+HjgQiOra5n gVlVqSDHBCIB+ZR9yvUEtAkO4LNyc9qV/GZoF61DxqsDbneu80DrL8p+tWILwpwNswynXssl AaprvlexAB2jEHD7LyBIILD7oNE8uAjWRlk183qfNyYepMUvT+UssD8JPi2QQdYwKjqEMzrN Xx0x25P480kSVfFzXUqzxuLkraJKI3zd8WsrBOmaf42pDwFy014ucPGhYfHA+vE7mSb4Ix87 pSACoUUUYRbvFnhW8gAAAAAAAA== --------------ms050506060300040200010400-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Oct 24 13:34:23 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A43F837B407 for <freebsd-net@FreeBSD.ORG>; Thu, 24 Oct 2002 13:34:22 -0700 (PDT) Received: from leida.eau.ee (leida.eau.ee [193.40.25.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4335843E4A for <freebsd-net@FreeBSD.ORG>; Thu, 24 Oct 2002 13:34:21 -0700 (PDT) (envelope-from markko@leida.eau.ee) Received: from localhost (markko@localhost) by leida.eau.ee (8.11.6/8.11.6) with ESMTP id g9OKGhs43961; Thu, 24 Oct 2002 23:16:46 +0300 (EEST) (envelope-from markko@leida.eau.ee) Date: Thu, 24 Oct 2002 23:16:42 +0300 (EEST) From: Markko Merzin <markko@torn.eau.ee> To: Charlie Root <ericx@vineyard.net> Cc: <freebsd-net@FreeBSD.ORG> Subject: Re: VLAN problems with replies to broadcast In-Reply-To: <20021023184119.3980891F68@vineyard.net> Message-ID: <Pine.BSF.4.32.0210242312390.43595-100000@leida.eau.ee> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org On Wed, 23 Oct 2002, Charlie Root wrote: > The fxp is plugged into an SMC Tigerswitch. The SMC is configured to > pass VLAN's 5, 10 and 20. .... > Can anyone suggest some tests I might try or further reading? Try SMC Tigerswitch printed manual. Some of the Tigerswitch series models cannot handle same mac-address in different VLANs. -- Markko To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Oct 24 16:44: 5 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 526DF37B401 for <net@FreeBSD.ORG>; Thu, 24 Oct 2002 16:44:00 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9AC3643E3B for <net@FreeBSD.ORG>; Thu, 24 Oct 2002 16:43:59 -0700 (PDT) (envelope-from larse@ISI.EDU) Received: from isi.edu (nik.isi.edu [128.9.168.58]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g9ONhwC01544; Thu, 24 Oct 2002 16:43:58 -0700 (PDT) Message-ID: <3DB885BD.8010203@isi.edu> Date: Thu, 24 Oct 2002 16:43:57 -0700 From: Lars Eggert <larse@ISI.EDU> User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:1.2b) Gecko/20021016 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: Luigi Rizzo <rizzo@icir.org> Cc: net@FreeBSD.ORG Subject: Re: Bridging when one interface has no carrier References: <3D61224B.2020902@isi.edu> <20020819102951.A38869@iguana.icir.org> In-Reply-To: <3D61224B.2020902@isi.edu> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020702020103090004050201" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org This is a cryptographically signed message in MIME format. --------------ms020702020103090004050201 Content-Type: multipart/mixed; boundary="------------020607080700020105050301" This is a multi-part message in MIME format. --------------020607080700020105050301 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, I debugged this a bit further and figured out what the problem is. The ISC dhcpd uses a bpf to "listen" on an interface. When a broadcast packet (e.g. DHCP request) comes in on one interface, the bridging code will correctly forward it out all the other interfaces in the cluster, and also deliver it locally. However, it will not send copies of the packet to all bpfs attached to all interfaces in the cluster, only to the one that the packet originally came in on. This causes the problem decribed in PR kern/41632 (http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/41632), where dhcpd "listens" on interface A which is bridged to interface B. When A has no carrier, DHCP requests arriving on B are ignored. When A has a carrier, dhcp will get a copy of the packet when it is bridge-forwarded out A, so the problem doesn't occur then. Attached is a rough patch to if_ethersubr.c that fixes the problem. It should probably further be tweaked (there's a chance for duplicates), but I wanted some comments first :-) Lars Luigi Rizzo wrote: > I guess the responsible of the problem is this part of code > in sys/net/if_ethersubr.c:ether_demux(): > > /* Discard packet if interface is not up */ > if ((ifp->if_flags & IFF_UP) == 0) { > m_freem(m); > return; > } > > which is somewhat funny, because once we have the packet, we > might as well process it. > > Now, one could bypass the test for the bridging case, > or remove it altogether... I am not sure which one is > the best approach. > > > On Mon, Aug 19, 2002 at 09:52:27AM -0700, Lars Eggert wrote: > > >I've filed a PR (kern/41632, > >http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/41632) on the following > >problem: > > > >FreeBSD box with two Ethernet NICs, e.g. if0 with IP address A and if1 > >with IP address B, bridged together: > > > >net.link.ether.bridge_cfg: if0 if1 > >net.link.ether.bridge: 1 > > > >Interface if0 is plugged in (has carrier), if1 isn't (no carrier). > >Packets arriving on if0 for IP address B (or the broadcast address) are > >not received by processes running on the bridging machine. > > > >Any ideas? -- Lars Eggert <larse@isi.edu> USC Information Sciences Institute --------------020607080700020105050301 Content-Type: text/plain; name="if_ethersubr.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="if_ethersubr.patch" --- if_ethersubr.c.old Thu Oct 24 16:19:38 2002 +++ if_ethersubr.c Thu Oct 24 16:42:06 2002 @@ -616,9 +616,32 @@ } if (bif == BDG_LOCAL || bif == BDG_BCAST - || bif == BDG_MCAST) - goto recvLocal; /* receive locally */ + || bif == BDG_MCAST) { + +#define BDG_CLUSTER(ifp) (ifp2sc[ifp->if_index].cluster) + +#define BDG_SAMECLUSTER(ifp,src) \ + (src == NULL || BDG_CLUSTER(ifp) == BDG_CLUSTER(src) ) + /* + * Deliver a copy of the packet to all bpfs attached + * to interfaces in the cluster. + */ + struct ifnet *ifp2; + TAILQ_FOREACH(ifp2, &ifnet, if_link) { + if (BDG_SAMECLUSTER(ifp, ifp2) && + ifp != ifp2 && + ifp2->if_bpf != NULL) { + struct m_hdr mh; + mh.mh_next = m; + mh.mh_data = (char *)eh; + mh.mh_len = ETHER_HDR_LEN; + bpf_mtap(ifp2, (struct mbuf *)&mh); + } + } + + goto recvLocal; /* receive locally */ + } /* If not local and not multicast, just drop it */ if (m != NULL) m_freem(m); --------------020607080700020105050301-- --------------ms020702020103090004050201 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJtjCC AzgwggKhoAMCAQICEGZFcrfMdPXPY3ZFhNAukQEwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vydmlj ZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkG CSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAw MDBaFw0wNDA4MjcyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2Vy dGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAw LjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZ gpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqd knWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYALQmJ7JRr6aFp AgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTI5NzAS BgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQAxsUtH XfkBceX1U2xdedY9mMAmE2KBIqcS+CKV6BtJtyd7BDm6/ObyJOuR+r3sDSo491BVqGz3Da1M G7wD9LXrokefbKIMWI0xQgkRbLAaadErErJAXWr5edDqLiXdiuT82w0fnQLzWtvKPPZE6iZp h39Ins6ln+eE2MliYq0FxjCCAzkwggKioAMCAQICAwglQTANBgkqhkiG9w0BAQQFADCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMB4XDTAyMDgyNDE4NTMzOVoX DTAzMDgyNDE4NTMzOVowVDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYD VQQDEwtMYXJzIEVnZ2VydDEcMBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBANI2Rrt4ggaQ/IrOsDeOm2H4/R5FRIL6JjDY3StE aogp1r23WKniQ1Vj98Nu5WxlaZ3Iam3Jen5T66H8u7rtMNpK4qAeAGoBsVeyVr1+CTFeuv+m xCh7BvBJwhLdm0zDaoDT05YKYZaqtsT+F286FWJQg31Xtf+vTKLVVrHcsafnteyal2NEt7Ac yZZfjsVLwxp2Lq3cwYfRQRoo7/yCVzS7HsgM6jmbO4taEMo4yC2rpnUbWEUCDTaCYgpAXzAl oiNk7GDh0wz2s5ZSnHRvNSBMAjCmpNtSYHfXFI1ANwrrrHIJ7Ei83+XN32PWY4OPzO3iown9 VR+vM+8lNx9OX28CAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIBBAQTTDJ1TXlmZkJO VWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEEBQADgYEAXcrIlKmPLM/r8r3oz2ZLPLaT1AyMjYTZY2qq/R7SUtFa9BNlTIFh DG78QKfJ9lo2LMzTPQqMZgNLmj95GbNPI8P8OIq2K6MeCZWz08ROackqTFP6xWbIFIfXcBVR 1dZnDDyDKBBh05KkvyTPawSQyOBUeNBfQUyO4TE+3o58U8UwggM5MIICoqADAgECAgMIJUEw DQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MDAeFw0wMjA4MjQxODUzMzlaFw0wMzA4MjQxODUzMzlaMFQxDzANBgNVBAQTBkVnZ2VydDEN MAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkqhkiG9w0BCQEWDWxh cnNlQGlzaS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDSNka7eIIGkPyK zrA3jpth+P0eRUSC+iYw2N0rRGqIKda9t1ip4kNVY/fDbuVsZWmdyGptyXp+U+uh/Lu67TDa SuKgHgBqAbFXsla9fgkxXrr/psQoewbwScIS3ZtMw2qA09OWCmGWqrbE/hdvOhViUIN9V7X/ r0yi1Vax3LGn57XsmpdjRLewHMmWX47FS8Madi6t3MGH0UEaKO/8glc0ux7IDOo5mzuLWhDK OMgtq6Z1G1hFAg02gmIKQF8wJaIjZOxg4dMM9rOWUpx0bzUgTAIwpqTbUmB31xSNQDcK66xy CexIvN/lzd9j1mODj8zt4qMJ/VUfrzPvJTcfTl9vAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIB ADAaMBgCAQQEE0wydU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVk dTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAF3KyJSpjyzP6/K96M9mSzy2k9QM jI2E2WNqqv0e0lLRWvQTZUyBYQxu/ECnyfZaNizM0z0KjGYDS5o/eRmzTyPD/DiKtiujHgmV s9PETmnJKkxT+sVmyBSH13AVUdXWZww8gygQYdOSpL8kz2sEkMjgVHjQX0FMjuExPt6OfFPF MYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MAIDCCVBMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTAyMTAyNDIzNDM1OFowIwYJKoZIhvcNAQkEMRYEFGrCQIFjEmz+np+D9ZsA QmLYhN+4MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3EAQxgZ0w gZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNh cGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNl czEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCCVBMIGtBgsq hkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2Fw ZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRp ZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44 LjMwAgMIJUEwDQYJKoZIhvcNAQEBBQAEggEAl4Sr3qF8HOc0slKvKdAAwDSa8cEz1lxLDGz9 JaXiEzg/7HskpbnaxKwVX5Rzw/wpWEYeTepLH3FosF7koK+MRgJGYLiBDoQHjoywuK1LVCgo jM3rCkFP9SwPYfS64W+BoS9i1oVi28v/YJsMUVX9nPpHFd9A+htE/jozEgFG2chyB3Qrpcqa ktSkhH64kkK6B5W3O24Zug8PgSyqO3GjGy0FnI9OCF8DUYyjG/M4sVbq0Wb749dauVl7BSYd NSKR6snfnY+ENFMEQSB6tzH3I4C08tpC4d3E8rhw1lwA7XuK6CvBLdAOc+sIW4vnpFwaRKnw NJFakzX+w1I7XpHrtQAAAAAAAA== --------------ms020702020103090004050201-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Oct 24 20: 7:34 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D251037B401; Thu, 24 Oct 2002 20:07:33 -0700 (PDT) Received: from mail.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3898B43E6A; Thu, 24 Oct 2002 20:07:33 -0700 (PDT) (envelope-from don@sandvine.com) Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19) id <42S9V23W>; Thu, 24 Oct 2002 23:07:32 -0400 Message-ID: <FE045D4D9F7AED4CBFF1B3B813C8533701022D68@mail.sandvine.com> From: Don Bowman <don@sandvine.com> To: "'freebsd-stable@freebsd.org'" <freebsd-stable@freebsd.org>, "'freebsd-net@freebsd.org'" <freebsd-net@freebsd.org> Subject: RE: Machine becomes non-responsive, only ^T shows it as alive und er l oad: IPFW, TCP proxying Date: Thu, 24 Oct 2002 23:07:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org > From: Don Bowman > > > > > > I have an application listening on an ipfw 'fwd' rule. > > I'm sending ~3K new sessions per second to it. It > > has to turn around and issue some of these out as > > a proxy, in response to which some of them the destination > > host won't exist. For reference, the solution is to upgrade to the latest -STABLE bge driver. The machine was getting stuck in interrupt. --don (don@sandvine.com www.sandvine.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 25 2:35:42 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ED9B037B401 for <net@FreeBSD.ORG>; Fri, 25 Oct 2002 02:35:38 -0700 (PDT) Received: from premijer.tel.fer.hr (premijer.tel.fer.hr [161.53.19.221]) by mx1.FreeBSD.org (Postfix) with ESMTP id DD6C643E6E for <net@FreeBSD.ORG>; Fri, 25 Oct 2002 02:35:30 -0700 (PDT) (envelope-from zec@tel.fer.hr) Received: from tel.fer.hr (unknown [161.53.19.178]) by premijer.tel.fer.hr (Postfix) with ESMTP id 291381380; Fri, 25 Oct 2002 11:35:01 +0200 (MET DST) Message-ID: <3DB91052.27104FA2@tel.fer.hr> Date: Fri, 25 Oct 2002 11:35:14 +0200 From: Marko Zec <zec@tel.fer.hr> X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Lars Eggert <larse@ISI.EDU> Cc: "net@FreeBSD.ORG" <net@FreeBSD.ORG>, Luigi Rizzo <rizzo@icir.org> Subject: Re: Bridging when one interface has no carrier References: <3D61224B.2020902@isi.edu> <20020819102951.A38869@iguana.icir.org> <3DB885BD.8010203@isi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org Lars Eggert wrote: > The ISC dhcpd uses a bpf to "listen" on an interface. When a broadcast > packet (e.g. DHCP request) comes in on one interface, the bridging code > will correctly forward it out all the other interfaces in the cluster, > and also deliver it locally. However, it will not send copies of the > packet to all bpfs attached to all interfaces in the cluster, only to > the one that the packet originally came in on. > > This causes the problem decribed in PR kern/41632 > (http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/41632), where dhcpd > "listens" on interface A which is bridged to interface B. When A has no > carrier, DHCP requests arriving on B are ignored. When A has a carrier, > dhcp will get a copy of the packet when it is bridge-forwarded out A, so > the problem doesn't occur then. This problem was also solved in the giant patch for network stack virtualization. As this patch completely removes the ifp2sc array, and instead extends struct arpcom to hold the bridge cluster association of the interface, it wouldn't make too much sense to post it here - you can check the entire patch at http://www.tel.fer.hr/zec/BSD/vimage/ This patch also solves the problem of bpf tapping on the outgoing traffic. Using the current bridging code, if you tap on a bridged interface that is either unplugged or actually transmits data over another interface in the cluster, the outgoing traffic (mbufs) will never reach this interface's outbound queue. As the bpf tapping on outgoing mbufs is left to the device driver (this is normally done in if_start routine), a bpf filter active on this interface will never catch such traffic. This problem is however not critical for normal applications, but can be very annoying when debugging the network connections, especially in a kernel with multiple network stack instances. This patch also ensures no duplicate or unnecessary tapping will occur. However, note that it currently badly breaks the bridging statistics. I hope to fix that in the near future... > Attached is a rough patch to if_ethersubr.c that fixes the problem. It > should probably further be tweaked (there's a chance for duplicates), > but I wanted some comments first :-) The looping proposed in your patch would be probably OK for BDG_MCAST and BDG_BCAST traffic, but definitely not for BDG_LOCAL, i think. > Lars > > Luigi Rizzo wrote: > > > I guess the responsible of the problem is this part of code > > in sys/net/if_ethersubr.c:ether_demux(): > > > > /* Discard packet if interface is not up */ > > if ((ifp->if_flags & IFF_UP) == 0) { > > m_freem(m); > > return; > > } > > > > which is somewhat funny, because once we have the packet, we > > might as well process it. > > > > Now, one could bypass the test for the bridging case, > > or remove it altogether... I am not sure which one is > > the best approach. > > > > > > On Mon, Aug 19, 2002 at 09:52:27AM -0700, Lars Eggert wrote: > > > > >I've filed a PR (kern/41632, > > >http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/41632) on the following > > >problem: > > > > > >FreeBSD box with two Ethernet NICs, e.g. if0 with IP address A and if1 > > >with IP address B, bridged together: > > > > > >net.link.ether.bridge_cfg: if0 if1 > > >net.link.ether.bridge: 1 > > > > > >Interface if0 is plugged in (has carrier), if1 isn't (no carrier). > > >Packets arriving on if0 for IP address B (or the broadcast address) are > > >not received by processes running on the bridging machine. > > > > > >Any ideas? > > -- > Lars Eggert <larse@isi.edu> USC Information Sciences Institute > > ------------------------------------------------------------------------ > --- if_ethersubr.c.old Thu Oct 24 16:19:38 2002 > +++ if_ethersubr.c Thu Oct 24 16:42:06 2002 > @@ -616,9 +616,32 @@ > } > if (bif == BDG_LOCAL > || bif == BDG_BCAST > - || bif == BDG_MCAST) > - goto recvLocal; /* receive locally */ > + || bif == BDG_MCAST) { > + > +#define BDG_CLUSTER(ifp) (ifp2sc[ifp->if_index].cluster) > + > +#define BDG_SAMECLUSTER(ifp,src) \ > + (src == NULL || BDG_CLUSTER(ifp) == BDG_CLUSTER(src) ) > > + /* > + * Deliver a copy of the packet to all bpfs attached > + * to interfaces in the cluster. > + */ > + struct ifnet *ifp2; > + TAILQ_FOREACH(ifp2, &ifnet, if_link) { > + if (BDG_SAMECLUSTER(ifp, ifp2) && > + ifp != ifp2 && > + ifp2->if_bpf != NULL) { > + struct m_hdr mh; > + mh.mh_next = m; > + mh.mh_data = (char *)eh; > + mh.mh_len = ETHER_HDR_LEN; > + bpf_mtap(ifp2, (struct mbuf *)&mh); > + } > + } > + > + goto recvLocal; /* receive locally */ > + } > /* If not local and not multicast, just drop it */ > if (m != NULL) > m_freem(m); To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 25 2:46: 0 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 85D7437B401; Fri, 25 Oct 2002 02:45:59 -0700 (PDT) Received: from premijer.tel.fer.hr (premijer.tel.fer.hr [161.53.19.221]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0AD7143E6A; Fri, 25 Oct 2002 02:45:59 -0700 (PDT) (envelope-from zec@tel.fer.hr) Received: from tel.fer.hr (unknown [161.53.19.178]) by premijer.tel.fer.hr (Postfix) with ESMTP id 2B2AA1380; Fri, 25 Oct 2002 11:45:38 +0200 (MET DST) Message-ID: <3DB912CF.DF6F7B74@tel.fer.hr> Date: Fri, 25 Oct 2002 11:45:51 +0200 From: Marko Zec <zec@tel.fer.hr> X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer <julian@elischer.org> Cc: "J. 'LoneWolf' Mattsson" <lonewolf-freebsd@earthmagic.org>, freebsd-net@freebsd.org, freebsd-arch@freebsd.org Subject: Re: RFC: BSD network stack virtualization References: <Pine.BSF.4.21.0210231737330.36940-100000@InterJet.elischer.org> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org Julian Elischer wrote: > On Thu, 24 Oct 2002, Marko Zec wrote: > > > Julian Elischer wrote: > > > > > > > 11/ why was ng_bridge unsuitable for your use? > > > > Both the native and netgraph bridging code, I believe, were designed with > > the presumption that only one "upper" hook is really needed to establish the > > communication to kernel's single network stack. However, this concept > > doesn't hold on a kernel with multiple network stacks. I just picked the > > native bridging code first and extended it to support hooking to multiple > > "upper" hooks. The similar extensions have yet to be applied to ng_bridge, I > > just didn't have time to implement the same functionality in two different > > frameworks. > > ng_bridge doesn't really distinguish between hooks to upper and lower > detinations. it only knows wha tMAC addresses are seen to come from each > hook and ensures that packets destined to those addresses are sent to > those hooks.. you can have as many > 'upper' hooks as you wish (and there are some uses for that). I just checked (only the functionality, not the ng_bridge code), and it doesn't work properly out of the box for bridging between the virtual network stacks. The inbound broadcast/multicast traffic seems to be delivered properly, but the outbound traffic doesn't pass the bridge when initiated outside the "master" virtual image. I'm just to lazy to dig into the code right now, maybe I'll check it more thoroughly later... Marko To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 25 7:53:24 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4F0FA37B434 for <freebsd-net@FreeBSD.ORG>; Fri, 25 Oct 2002 07:53:19 -0700 (PDT) Received: from smtp.ericx.net (ethel.ericx.net [204.128.227.33]) by mx1.FreeBSD.org (Postfix) with SMTP id 6222843E65 for <freebsd-net@FreeBSD.ORG>; Fri, 25 Oct 2002 07:53:18 -0700 (PDT) (envelope-from ericx@vineyard.net) Received: from fortiva (FORTIVA.VINEYARD.NET [204.17.195.104]) by smtp.ericx.net (Postfix) with SMTP id 13926163A3; Fri, 25 Oct 2002 10:53:12 -0400 (EDT) Message-ID: <008101c27c36$2d46fb60$68c311cc@vineyard.net> From: "Eric W. Bates" <ericx@vineyard.net> To: "Markko Merzin" <markko@torn.eau.ee> Cc: <freebsd-net@FreeBSD.ORG> References: <Pine.BSF.4.32.0210242312390.43595-100000@leida.eau.ee> Subject: Re: VLAN problems with replies to broadcast Date: Fri, 25 Oct 2002 10:52:44 -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 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org ----- Original Message ----- From: "Markko Merzin" <markko@torn.eau.ee> To: "Charlie Root" <ericx@vineyard.net> Cc: <freebsd-net@FreeBSD.ORG> Sent: Thursday, October 24, 2002 4:16 PM Subject: Re: VLAN problems with replies to broadcast > On Wed, 23 Oct 2002, Charlie Root wrote: > > > The fxp is plugged into an SMC Tigerswitch. The SMC is configured to > > pass VLAN's 5, 10 and 20. > > .... > > > Can anyone suggest some tests I might try or further reading? > > Try SMC Tigerswitch printed manual. Some of the Tigerswitch series models > cannot handle same mac-address in different VLANs. The SMC documentation is a bit lacking. However, this is only a problem with packets in response to a broadcast packet. In my limited understanding I find the behaviour a bit bizarre. ICMP pings will work from a remote windoze machine tagged as VLAN 10 as the packets pass into the switch until it's ARP entry for the freebsd box expires or I deliberately delete it. The arp request shows up at the FreeBSD machine, but the arp-reply back to the Windows machine doesn't get there. Can I trust tcpdump's output? It gives every indication there is a well formed arp-reply packet going back with the correct tag. > -- > Markko > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 25 9:40:28 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7ACFC37B401 for <net@FreeBSD.ORG>; Fri, 25 Oct 2002 09:40:25 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id E5F0143E6E for <net@FreeBSD.ORG>; Fri, 25 Oct 2002 09:40:24 -0700 (PDT) (envelope-from larse@ISI.EDU) Received: from isi.edu (nik.isi.edu [128.9.168.58]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g9PGeLC03099; Fri, 25 Oct 2002 09:40:21 -0700 (PDT) Message-ID: <3DB973F5.5070900@isi.edu> Date: Fri, 25 Oct 2002 09:40:21 -0700 From: Lars Eggert <larse@ISI.EDU> User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:1.2b) Gecko/20021016 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: Marko Zec <zec@tel.fer.hr> Cc: "net@FreeBSD.ORG" <net@FreeBSD.ORG>, Luigi Rizzo <rizzo@icir.org> Subject: Re: Bridging when one interface has no carrier References: <3D61224B.2020902@isi.edu> <20020819102951.A38869@iguana.icir.org> <3DB885BD.8010203@isi.edu> <3DB91052.27104FA2@tel.fer.hr> In-Reply-To: <3D61224B.2020902@isi.edu> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020307050803000904080606" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org This is a cryptographically signed message in MIME format. --------------ms020307050803000904080606 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Marko, Marko Zec wrote: > > This problem was also solved in the giant patch for network stack > virtualization. I had looked at that patch briefly, and it looked like VERY interesting work. If it fixes the bridging code, too, it's even better - I'll definitly look forward to using it, once it has become a bit more mature. > The looping proposed in your patch would be probably OK for BDG_MCAST > and BDG_BCAST traffic, but definitely not for BDG_LOCAL, i think. Yeah, I noticed that three seconds after I hit "send" :-) I moved the stuff up into the "if (bif != BDG_LOCAL)" branch. Still, there might be duplicate packets delivered to the bpf, I'll look into that today. Thanks for the feedback! Lars -- Lars Eggert <larse@isi.edu> USC Information Sciences Institute --------------ms020307050803000904080606 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJtjCC AzgwggKhoAMCAQICEGZFcrfMdPXPY3ZFhNAukQEwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vydmlj ZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkG CSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAw MDBaFw0wNDA4MjcyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2Vy dGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAw LjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZ gpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqd knWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYALQmJ7JRr6aFp AgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTI5NzAS BgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQAxsUtH XfkBceX1U2xdedY9mMAmE2KBIqcS+CKV6BtJtyd7BDm6/ObyJOuR+r3sDSo491BVqGz3Da1M G7wD9LXrokefbKIMWI0xQgkRbLAaadErErJAXWr5edDqLiXdiuT82w0fnQLzWtvKPPZE6iZp h39Ins6ln+eE2MliYq0FxjCCAzkwggKioAMCAQICAwglQTANBgkqhkiG9w0BAQQFADCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMB4XDTAyMDgyNDE4NTMzOVoX DTAzMDgyNDE4NTMzOVowVDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYD VQQDEwtMYXJzIEVnZ2VydDEcMBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBANI2Rrt4ggaQ/IrOsDeOm2H4/R5FRIL6JjDY3StE aogp1r23WKniQ1Vj98Nu5WxlaZ3Iam3Jen5T66H8u7rtMNpK4qAeAGoBsVeyVr1+CTFeuv+m xCh7BvBJwhLdm0zDaoDT05YKYZaqtsT+F286FWJQg31Xtf+vTKLVVrHcsafnteyal2NEt7Ac yZZfjsVLwxp2Lq3cwYfRQRoo7/yCVzS7HsgM6jmbO4taEMo4yC2rpnUbWEUCDTaCYgpAXzAl oiNk7GDh0wz2s5ZSnHRvNSBMAjCmpNtSYHfXFI1ANwrrrHIJ7Ei83+XN32PWY4OPzO3iown9 VR+vM+8lNx9OX28CAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIBBAQTTDJ1TXlmZkJO VWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEEBQADgYEAXcrIlKmPLM/r8r3oz2ZLPLaT1AyMjYTZY2qq/R7SUtFa9BNlTIFh DG78QKfJ9lo2LMzTPQqMZgNLmj95GbNPI8P8OIq2K6MeCZWz08ROackqTFP6xWbIFIfXcBVR 1dZnDDyDKBBh05KkvyTPawSQyOBUeNBfQUyO4TE+3o58U8UwggM5MIICoqADAgECAgMIJUEw DQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MDAeFw0wMjA4MjQxODUzMzlaFw0wMzA4MjQxODUzMzlaMFQxDzANBgNVBAQTBkVnZ2VydDEN MAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkqhkiG9w0BCQEWDWxh cnNlQGlzaS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDSNka7eIIGkPyK zrA3jpth+P0eRUSC+iYw2N0rRGqIKda9t1ip4kNVY/fDbuVsZWmdyGptyXp+U+uh/Lu67TDa SuKgHgBqAbFXsla9fgkxXrr/psQoewbwScIS3ZtMw2qA09OWCmGWqrbE/hdvOhViUIN9V7X/ r0yi1Vax3LGn57XsmpdjRLewHMmWX47FS8Madi6t3MGH0UEaKO/8glc0ux7IDOo5mzuLWhDK OMgtq6Z1G1hFAg02gmIKQF8wJaIjZOxg4dMM9rOWUpx0bzUgTAIwpqTbUmB31xSNQDcK66xy CexIvN/lzd9j1mODj8zt4qMJ/VUfrzPvJTcfTl9vAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIB ADAaMBgCAQQEE0wydU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVk dTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAF3KyJSpjyzP6/K96M9mSzy2k9QM jI2E2WNqqv0e0lLRWvQTZUyBYQxu/ECnyfZaNizM0z0KjGYDS5o/eRmzTyPD/DiKtiujHgmV s9PETmnJKkxT+sVmyBSH13AVUdXWZww8gygQYdOSpL8kz2sEkMjgVHjQX0FMjuExPt6OfFPF MYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MAIDCCVBMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTAyMTAyNTE2NDAyMVowIwYJKoZIhvcNAQkEMRYEFH1OtqEXGNpyIq1J6QWi uPSx9THNMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3EAQxgZ0w gZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNh cGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNl czEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCCVBMIGtBgsq hkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2Fw ZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRp ZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44 LjMwAgMIJUEwDQYJKoZIhvcNAQEBBQAEggEAENTDQFtw3ncahHpnikY1BkW+rV7dt2HFzfot m9pNP40Sf6Pw3iWHoe8gDVRCzclY4BI2aOoVm2fZd8p23LCr48OV/gy5IadcUSSYeBB02MgW dB6Ai/Cs7dqwI/cBhumuP9bwH6cpGj+6q4p9Uv0S8LGd3ZTbrHCZOm+tH5yTq7JvSMpDYYfk B+4YMBV4p5d4aADfNWtvjwVfMEMkQw2x8qQ2TIb2FjI8O5Z4bZ8SmpuQiTwASFc/N3nBE9v4 CavKlvQJ97RVpLYyDIe9f+SQOsDm84fkGYbHWR1RXPQA/pPUUoFxzRQ7KWynkuU9SY3uT1c/ JB5tHmqDmdU0hbBz0gAAAAAAAA== --------------ms020307050803000904080606-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 25 12: 0:30 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A62A337B401 for <freebsd-net@FreeBSD.ORG>; Fri, 25 Oct 2002 12:00:28 -0700 (PDT) Received: from kzsu.stanford.edu (KZSU.Stanford.EDU [171.66.118.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id 53F0C43E65 for <freebsd-net@FreeBSD.ORG>; Fri, 25 Oct 2002 12:00:28 -0700 (PDT) (envelope-from romain@kzsu.stanford.edu) Received: from kzsu.stanford.edu (localhost [127.0.0.1]) by kzsu.stanford.edu (8.12.3/8.12.3) with ESMTP id g9PJ0Rdj045546 for <freebsd-net@FreeBSD.ORG>; Fri, 25 Oct 2002 12:00:27 -0700 (PDT) (envelope-from romain@kzsu.stanford.edu) Received: (from romain@localhost) by kzsu.stanford.edu (8.12.3/8.12.3/Submit) id g9PJ0RPo045545 for freebsd-net@FreeBSD.ORG; Fri, 25 Oct 2002 12:00:27 -0700 (PDT) Date: Fri, 25 Oct 2002 12:00:27 -0700 From: Romain Kang <romain@kzsu.stanford.edu> To: freebsd-net@FreeBSD.ORG Subject: post-ifconfig delay causes ntpdate failure? Message-ID: <20021025190027.GA45509@kzsu.stanford.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-Scanned-By: MIMEDefang 2.15 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org I spent some time trying to figure out why the my ntpdate doesn't seem to work. It appears to me that the fxp0 isn't transmitting for a relatively long period of time following the ifconfig. The saga follows. On the client (10.10.1.101), I gave ntpdate the -d flag and saved its output. ntpdate claimed that the server (10.10.1.100) never replied to its ntp queries. I stuck a tcpdump into rc.network, then ran a ping loop to see how long it took before the first ping to the server succeeded. The shell code claimed 25 seconds: (T0=`date +%s` I=0 MAX=30 echo "rc.network: first ping test" while ! { ping -q -c1 10.10.1.100 > /dev/null; } do I=`expr $I + 1` test $I -ge $MAX && break sleep 1 done T1=`date +%s` DIFF=`expr $T1 - $T0` echo "$DIFF seconds to first successful ping") >> $LOG 2>&1 tcpdump on the client saw: 23:55:53.019046 arp who-has 10.10.1.100 (2e:2f:30:31:32:33) tell 10.10.1.101 23:56:05.219283 arp who-has 10.10.1.100 (2e:2f:30:31:32:33) tell 10.10.1.101 23:56:05.220140 arp reply 10.10.1.100 is-at 0:90:fb:8:71:fd 23:56:05.220172 10.10.1.101 > 10.10.1.100: icmp: echo request 23:56:05.221017 10.10.1.100 > 10.10.1.101: icmp: echo reply The server saw: 23:56:05.967915 arp who-has 10.10.1.100 (2e:2f:30:31:32:33) tell 10.10.1.101 23:56:05.967950 arp reply 10.10.1.100 is-at 0:90:fb:8:71:fd 23:56:05.969464 10.10.1.101 > 10.10.1.100: icmp: echo request 23:56:05.969513 10.10.1.100 > 10.10.1.101: icmp: echo reply With the ping loop inserted before ntpdate, the client was able to get its initial date set. This works, but it seems like a crude hack. Anyone have a better idea? -- Romain Kang Disclaimer: I speak for myself alone, romain@kzsu.stanford.edu except when indicated otherwise. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 25 12: 3:11 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0EF2837B401 for <freebsd-net@FreeBSD.ORG>; Fri, 25 Oct 2002 12:03:09 -0700 (PDT) Received: from silver.he.iki.fi (silver.he.iki.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9A9F643E4A for <freebsd-net@FreeBSD.ORG>; Fri, 25 Oct 2002 12:03:07 -0700 (PDT) (envelope-from pete@he.iki.fi) Received: from PHE (silver.he.iki.fi [193.64.42.241]) by silver.he.iki.fi (8.12.6/8.11.4) with SMTP id g9PJ2wYj026041; Fri, 25 Oct 2002 22:03:05 +0300 (EEST) (envelope-from pete@he.iki.fi) Message-ID: <053401c27c59$30aa83d0$862a40c1@PHE> From: "Petri Helenius" <pete@he.iki.fi> To: "Romain Kang" <romain@kzsu.stanford.edu>, <freebsd-net@FreeBSD.ORG> References: <20021025190027.GA45509@kzsu.stanford.edu> Subject: Re: post-ifconfig delay causes ntpdate failure? Date: Fri, 25 Oct 2002 22:03:21 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org Are you sure that this is not caused by spanning tree delay on the ethernet switch you are probably connected to? Pete ----- Original Message ----- From: "Romain Kang" <romain@kzsu.stanford.edu> To: <freebsd-net@FreeBSD.ORG> Sent: Friday, October 25, 2002 10:00 PM Subject: post-ifconfig delay causes ntpdate failure? > I spent some time trying to figure out why the my ntpdate doesn't > seem to work. It appears to me that the fxp0 isn't transmitting > for a relatively long period of time following the ifconfig. The > saga follows. > > On the client (10.10.1.101), I gave ntpdate the -d flag and saved > its output. ntpdate claimed that the server (10.10.1.100) never > replied to its ntp queries. > > I stuck a tcpdump into rc.network, then ran a ping loop to see how > long it took before the first ping to the server succeeded. The > shell code claimed 25 seconds: > (T0=`date +%s` > I=0 > MAX=30 > echo "rc.network: first ping test" > while ! { ping -q -c1 10.10.1.100 > /dev/null; } > do > I=`expr $I + 1` > test $I -ge $MAX && break > sleep 1 > done > T1=`date +%s` > DIFF=`expr $T1 - $T0` > echo "$DIFF seconds to first successful ping") >> $LOG 2>&1 > > tcpdump on the client saw: > > 23:55:53.019046 arp who-has 10.10.1.100 (2e:2f:30:31:32:33) tell 10.10.1.101 > 23:56:05.219283 arp who-has 10.10.1.100 (2e:2f:30:31:32:33) tell 10.10.1.101 > 23:56:05.220140 arp reply 10.10.1.100 is-at 0:90:fb:8:71:fd > 23:56:05.220172 10.10.1.101 > 10.10.1.100: icmp: echo request > 23:56:05.221017 10.10.1.100 > 10.10.1.101: icmp: echo reply > > The server saw: > > 23:56:05.967915 arp who-has 10.10.1.100 (2e:2f:30:31:32:33) tell 10.10.1.101 > 23:56:05.967950 arp reply 10.10.1.100 is-at 0:90:fb:8:71:fd > 23:56:05.969464 10.10.1.101 > 10.10.1.100: icmp: echo request > 23:56:05.969513 10.10.1.100 > 10.10.1.101: icmp: echo reply > > With the ping loop inserted before ntpdate, the client was able to > get its initial date set. This works, but it seems like a crude hack. > Anyone have a better idea? > -- > Romain Kang Disclaimer: I speak for myself alone, > romain@kzsu.stanford.edu except when indicated otherwise. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 25 12: 5:29 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 97E3337B401 for <freebsd-net@freebsd.org>; Fri, 25 Oct 2002 12:05:27 -0700 (PDT) Received: from 66-162-33-178.gen.twtelecom.net (66-162-33-178.gen.twtelecom.net [66.162.33.178]) by mx1.FreeBSD.org (Postfix) with ESMTP id 31C0543E42 for <freebsd-net@freebsd.org>; Fri, 25 Oct 2002 12:05:27 -0700 (PDT) (envelope-from steve@expertcity.com) Received: from [10.4.2.41] (helo=expertcity.com) by 66-162-33-178.gen.twtelecom.net with esmtp (Exim 3.22 #4) id 1859lu-0004s4-00; Fri, 25 Oct 2002 12:05:26 -0700 Message-ID: <3DB995F6.90506@expertcity.com> Date: Fri, 25 Oct 2002 12:05:26 -0700 From: Steve Francis <steve@expertcity.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2a) Gecko/20020910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Romain Kang <romain@kzsu.stanford.edu> Cc: freebsd-net@FreeBSD.ORG Subject: Re: post-ifconfig delay causes ntpdate failure? References: <20021025190027.GA45509@kzsu.stanford.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org Um.. Seems like its the switch port Spanning tree bringing the port active after 15 seconds of learning and 15 seconds of listening? Romain Kang wrote: >I spent some time trying to figure out why the my ntpdate doesn't >seem to work. It appears to me that the fxp0 isn't transmitting >for a relatively long period of time following the ifconfig. The >saga follows. > >On the client (10.10.1.101), I gave ntpdate the -d flag and saved >its output. ntpdate claimed that the server (10.10.1.100) never >replied to its ntp queries. > >I stuck a tcpdump into rc.network, then ran a ping loop to see how >long it took before the first ping to the server succeeded. The >shell code claimed 25 seconds: > (T0=`date +%s` > I=0 > MAX=30 > echo "rc.network: first ping test" > while ! { ping -q -c1 10.10.1.100 > /dev/null; } > do > I=`expr $I + 1` > test $I -ge $MAX && break > sleep 1 > done > T1=`date +%s` > DIFF=`expr $T1 - $T0` > echo "$DIFF seconds to first successful ping") >> $LOG 2>&1 > >tcpdump on the client saw: > >23:55:53.019046 arp who-has 10.10.1.100 (2e:2f:30:31:32:33) tell 10.10.1.101 >23:56:05.219283 arp who-has 10.10.1.100 (2e:2f:30:31:32:33) tell 10.10.1.101 >23:56:05.220140 arp reply 10.10.1.100 is-at 0:90:fb:8:71:fd >23:56:05.220172 10.10.1.101 > 10.10.1.100: icmp: echo request >23:56:05.221017 10.10.1.100 > 10.10.1.101: icmp: echo reply > >The server saw: > >23:56:05.967915 arp who-has 10.10.1.100 (2e:2f:30:31:32:33) tell 10.10.1.101 >23:56:05.967950 arp reply 10.10.1.100 is-at 0:90:fb:8:71:fd >23:56:05.969464 10.10.1.101 > 10.10.1.100: icmp: echo request >23:56:05.969513 10.10.1.100 > 10.10.1.101: icmp: echo reply > >With the ping loop inserted before ntpdate, the client was able to >get its initial date set. This works, but it seems like a crude hack. >Anyone have a better idea? >-- >Romain Kang Disclaimer: I speak for myself alone, >romain@kzsu.stanford.edu except when indicated otherwise. > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-net" in the body of the message > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 25 12:14:36 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 85CFD37B878 for <net@FreeBSD.ORG>; Fri, 25 Oct 2002 12:14:32 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id EC6BC43E6A for <net@FreeBSD.ORG>; Fri, 25 Oct 2002 12:14:31 -0700 (PDT) (envelope-from larse@ISI.EDU) Received: from isi.edu (nik.isi.edu [128.9.168.58]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g9PJEBC07774; Fri, 25 Oct 2002 12:14:11 -0700 (PDT) Message-ID: <3DB99802.6000306@isi.edu> Date: Fri, 25 Oct 2002 12:14:10 -0700 From: Lars Eggert <larse@ISI.EDU> User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:1.2b) Gecko/20021016 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: Lars Eggert <larse@ISI.EDU> Cc: Luigi Rizzo <rizzo@icir.org>, net@FreeBSD.ORG Subject: Re: Bridging when one interface has no carrier References: <3D61224B.2020902@isi.edu> <20020819102951.A38869@iguana.icir.org> <3DB885BD.8010203@isi.edu> In-Reply-To: <3D61224B.2020902@isi.edu> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060804000208080804050000" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org This is a cryptographically signed message in MIME format. --------------ms060804000208080804050000 Content-Type: multipart/mixed; boundary="------------000001050202060609080607" This is a multi-part message in MIME format. --------------000001050202060609080607 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Lars Eggert wrote: > Attached is a rough patch to if_ethersubr.c that fixes the problem. It > should probably further be tweaked (there's a chance for duplicates), > but I wanted some comments first :-) Here's a revised version of the patch (against bridge.c, which is a better place for it) that only affects broadcast and multicast packets and doesn't deliver duplicates to bpf. Lars -- Lars Eggert <larse@isi.edu> USC Information Sciences Institute --------------000001050202060609080607 Content-Type: text/plain; name="bridge.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="bridge.patch" --- bridge.c.old Thu Oct 24 16:21:45 2002 +++ bridge.c Fri Oct 25 12:02:26 2002 @@ -104,6 +104,7 @@ #include <net/if.h> #include <net/if_types.h> #include <net/if_var.h> +#include <net/bpf.h> #include <netinet/in.h> /* for struct arpcom */ #include <netinet/in_systm.h> @@ -1015,6 +1016,21 @@ return m0 ; /* the original is still there... */ } } + + /* + * Deliver a copy of the packet to the bpf even if the interface + * has no carrier. This fixes kern/41632. + */ + if ((!(last->if_flags & IFF_OACTIVE)) && last->if_bpf != NULL) { + struct m_hdr mh; + + /* This kludge is OK; BPF treats the "mbuf" as read-only */ + mh.mh_next = m; + mh.mh_data = (char *)eh; + mh.mh_len = ETHER_HDR_LEN; + bpf_mtap(last, (struct mbuf *)&mh); + } + /* * Add header (optimized for the common case of eh pointing * already into the mbuf) and execute last part of ether_output: --------------000001050202060609080607-- --------------ms060804000208080804050000 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJtjCC AzgwggKhoAMCAQICEGZFcrfMdPXPY3ZFhNAukQEwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vydmlj ZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkG CSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAw MDBaFw0wNDA4MjcyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2Vy dGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAw LjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZ gpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqd knWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYALQmJ7JRr6aFp AgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTI5NzAS BgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQAxsUtH XfkBceX1U2xdedY9mMAmE2KBIqcS+CKV6BtJtyd7BDm6/ObyJOuR+r3sDSo491BVqGz3Da1M G7wD9LXrokefbKIMWI0xQgkRbLAaadErErJAXWr5edDqLiXdiuT82w0fnQLzWtvKPPZE6iZp h39Ins6ln+eE2MliYq0FxjCCAzkwggKioAMCAQICAwglQTANBgkqhkiG9w0BAQQFADCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMB4XDTAyMDgyNDE4NTMzOVoX DTAzMDgyNDE4NTMzOVowVDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYD VQQDEwtMYXJzIEVnZ2VydDEcMBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBANI2Rrt4ggaQ/IrOsDeOm2H4/R5FRIL6JjDY3StE aogp1r23WKniQ1Vj98Nu5WxlaZ3Iam3Jen5T66H8u7rtMNpK4qAeAGoBsVeyVr1+CTFeuv+m xCh7BvBJwhLdm0zDaoDT05YKYZaqtsT+F286FWJQg31Xtf+vTKLVVrHcsafnteyal2NEt7Ac yZZfjsVLwxp2Lq3cwYfRQRoo7/yCVzS7HsgM6jmbO4taEMo4yC2rpnUbWEUCDTaCYgpAXzAl oiNk7GDh0wz2s5ZSnHRvNSBMAjCmpNtSYHfXFI1ANwrrrHIJ7Ei83+XN32PWY4OPzO3iown9 VR+vM+8lNx9OX28CAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIBBAQTTDJ1TXlmZkJO VWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEEBQADgYEAXcrIlKmPLM/r8r3oz2ZLPLaT1AyMjYTZY2qq/R7SUtFa9BNlTIFh DG78QKfJ9lo2LMzTPQqMZgNLmj95GbNPI8P8OIq2K6MeCZWz08ROackqTFP6xWbIFIfXcBVR 1dZnDDyDKBBh05KkvyTPawSQyOBUeNBfQUyO4TE+3o58U8UwggM5MIICoqADAgECAgMIJUEw DQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MDAeFw0wMjA4MjQxODUzMzlaFw0wMzA4MjQxODUzMzlaMFQxDzANBgNVBAQTBkVnZ2VydDEN MAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkqhkiG9w0BCQEWDWxh cnNlQGlzaS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDSNka7eIIGkPyK zrA3jpth+P0eRUSC+iYw2N0rRGqIKda9t1ip4kNVY/fDbuVsZWmdyGptyXp+U+uh/Lu67TDa SuKgHgBqAbFXsla9fgkxXrr/psQoewbwScIS3ZtMw2qA09OWCmGWqrbE/hdvOhViUIN9V7X/ r0yi1Vax3LGn57XsmpdjRLewHMmWX47FS8Madi6t3MGH0UEaKO/8glc0ux7IDOo5mzuLWhDK OMgtq6Z1G1hFAg02gmIKQF8wJaIjZOxg4dMM9rOWUpx0bzUgTAIwpqTbUmB31xSNQDcK66xy CexIvN/lzd9j1mODj8zt4qMJ/VUfrzPvJTcfTl9vAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIB ADAaMBgCAQQEE0wydU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVk dTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAF3KyJSpjyzP6/K96M9mSzy2k9QM jI2E2WNqqv0e0lLRWvQTZUyBYQxu/ECnyfZaNizM0z0KjGYDS5o/eRmzTyPD/DiKtiujHgmV s9PETmnJKkxT+sVmyBSH13AVUdXWZww8gygQYdOSpL8kz2sEkMjgVHjQX0FMjuExPt6OfFPF MYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MAIDCCVBMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTAyMTAyNTE5MTQxMFowIwYJKoZIhvcNAQkEMRYEFDvLPCud9W+EOEYw7sQq ebIit7ngMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3EAQxgZ0w gZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNh cGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNl czEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCCVBMIGtBgsq hkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2Fw ZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRp ZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44 LjMwAgMIJUEwDQYJKoZIhvcNAQEBBQAEggEAZixu+tJlzWqzUrBWtqWZzwULoMGWc14iC6kG JLl3eUlAB6G+q2DCoeNbT5k+IVV8+xrHI6r8pcOSgwqtt+sXqXYAX3daogjAz2lbrKwbAul9 R5IcT+UQtY0fgjv2m0zgEqXso9Pn5MPj6MuhJ5rZMAG8QF+ijFOlauL7vPrt6k+5Y7sCeXwv FJq+HdneDHcgduUgMeGVjp68Kla8Q6LFjxowSelAEcykSJjtZgy219ICYMij+TZ/C3ZHajZb ms55IZstdtnwg8uvQcchGJiWM5IJBocdHTJiHKoUxVQAFNZd3dNQkX++TmQoVYgSFob7tW9w e9xe7EZEPfCqKKDd1AAAAAAAAA== --------------ms060804000208080804050000-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 25 12:27: 0 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 141DD37BBB6 for <freebsd-net@FreeBSD.ORG>; Fri, 25 Oct 2002 12:27:00 -0700 (PDT) Received: from kzsu.stanford.edu (KZSU.Stanford.EDU [171.66.118.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id B7A2843E3B for <freebsd-net@FreeBSD.ORG>; Fri, 25 Oct 2002 12:26:59 -0700 (PDT) (envelope-from romain@kzsu.stanford.edu) Received: from kzsu.stanford.edu (localhost [127.0.0.1]) by kzsu.stanford.edu (8.12.3/8.12.3) with ESMTP id g9PJQrdj045870; Fri, 25 Oct 2002 12:26:54 -0700 (PDT) (envelope-from romain@kzsu.stanford.edu) Received: (from romain@localhost) by kzsu.stanford.edu (8.12.3/8.12.3/Submit) id g9PJQrRj045869; Fri, 25 Oct 2002 12:26:53 -0700 (PDT) Date: Fri, 25 Oct 2002 12:26:53 -0700 From: Romain Kang <romain@kzsu.stanford.edu> To: Petri Helenius <pete@he.iki.fi> Cc: freebsd-net@FreeBSD.ORG Subject: Re: post-ifconfig delay causes ntpdate failure? Message-ID: <20021025192653.GA45730@kzsu.stanford.edu> References: <20021025190027.GA45509@kzsu.stanford.edu> <053401c27c59$30aa83d0$862a40c1@PHE> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <053401c27c59$30aa83d0$862a40c1@PHE> User-Agent: Mutt/1.4i X-Scanned-By: MIMEDefang 2.15 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org On Fri, Oct 25, 2002 at 10:03:21PM +0300, Petri Helenius wrote: > Are you sure that this is not caused by spanning tree delay on the ethernet > switch you are probably connected to? Time for me to read up on STP bridging. However, I'd be a little surprised that the delay would occur when both hosts are on the same switch, and they were communicating immediately before the client was rebooted (as in my tests). Whatever the cause, is there some method better than the ping loop to determine if IP is actually getting out? Thanks, Romain To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 25 12:33:46 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EF01137BD36 for <freebsd-net@FreeBSD.ORG>; Fri, 25 Oct 2002 12:33:45 -0700 (PDT) Received: from silver.he.iki.fi (silver.he.iki.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id 937BC43E42 for <freebsd-net@FreeBSD.ORG>; Fri, 25 Oct 2002 12:33:44 -0700 (PDT) (envelope-from pete@he.iki.fi) Received: from PHE (silver.he.iki.fi [193.64.42.241]) by silver.he.iki.fi (8.12.6/8.11.4) with SMTP id g9PJXWYj026243; Fri, 25 Oct 2002 22:33:33 +0300 (EEST) (envelope-from pete@he.iki.fi) Message-ID: <055401c27c5d$7580e720$862a40c1@PHE> From: "Petri Helenius" <pete@he.iki.fi> To: "Romain Kang" <romain@kzsu.stanford.edu> Cc: <freebsd-net@FreeBSD.ORG> References: <20021025190027.GA45509@kzsu.stanford.edu> <053401c27c59$30aa83d0$862a40c1@PHE> <20021025192653.GA45730@kzsu.stanford.edu> Subject: Re: post-ifconfig delay causes ntpdate failure? Date: Fri, 25 Oct 2002 22:33:55 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org > Whatever the cause, is there some method better than the ping loop > to determine if IP is actually getting out? > Look at the lights on the switch or the card. Or put an analyzer on the wire. We use fxp´s extensively and have never seen this. Pete To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 25 13: 9:48 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EA3FB37B401 for <freebsd-net@FreeBSD.ORG>; Fri, 25 Oct 2002 13:09:42 -0700 (PDT) Received: from isilon.com (isilon.com [65.101.129.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id 742FF43E65 for <freebsd-net@FreeBSD.ORG>; Fri, 25 Oct 2002 13:09:42 -0700 (PDT) (envelope-from bbaumann@isilon.com) Received: from localhost (localhost [127.0.0.1]) by isilon.com (8.12.2/8.11.1) with ESMTP id g9PK9f3C077508 for <freebsd-net@FreeBSD.ORG>; Fri, 25 Oct 2002 13:09:41 -0700 (PDT) (envelope-from bbaumann@isilon.com) Date: Fri, 25 Oct 2002 13:09:41 -0700 (PDT) From: Bill Baumann <bbaumann@isilon.com> To: freebsd-net@FreeBSD.ORG Subject: Re: FreeBSD 4.5 and network problems Message-ID: <Pine.BSF.4.21.0210251145460.11368-100000@isilon.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org Funny, this was the exact topic of my e-mail just 2 days ago (tcp_input's header prediction and a collapsing send window). But you may have done a better job of explaining. My symptom was slightly different. When the send window drops below a segment size, tcp_output() stops sending. It only sends if it can send a whole packet, or if there's only a fractional bit left to send. Transmission was completely halted. I recommend a slightly different change. The location you've chosen to update wl1 and wl2 is not sufficent to guarantee that fast path processing will occur. I recommend placing wl1 and wl2 updates in the code blocks that actually avoid the window update code. if ( fast path ) { not so good here... if (tlen == 0) { if (SEQ_GT(th->th_ack, tp->snd_una) && SEQ_LEQ(th->th_ack, tp->snd_max) && tp->snd_cwnd >= tp->snd_wnd && tp->t_dupacks < tp->t_rexmtacks) { better in here... fast path ack processing return; } else if (th->th_ack == tp->snd_una && LIST_EMPTY(&tp->t_segq) && tlen <= sbspace(&so->so_rcv)) { and in here... fast path data processing return; } } ... if ( wl1 ... wl2 ... ) { do window update } The inner conditions can also prevent fast path processing. Placing the wl1 & wl2 updates right off has the potential of causing window updates to be missed. There are two other variables besides wl1 and wl2 that are problematic. rcv_up, and snd_recover are also in need of updating. rcv_up can easily be updated along with wl1. However, snd_recover is not as obvious to me. We could inadvertently avoid fast recovery in the condition described below. Should we update snd_recover along side wl1 as well? Regards, Bill Baumann On Wed, 17 Apr 2002, Damon Permezel wrote: > Not sure about the initial delays, but I found a bug which does cause > throughput to drop dramatically once it is hit. > > Consider the sender of a bulk data transfer (1/2 duplex). > When header prediction is successful, the ACK stream coming back > is handled by the fast path code. For this to be true, the window info > in that ACK stream cannot change. > > tiwin && tiwin == tp->snd_wnd > > > When the window finally does change, we go to the slow path. > There is a check against WL1 and WL2 to ensure that the window update is > not from an earlier packet. The fast-path code does not drag WL1/WL2 > along. In this example, only WL2 (the ACK) changes, as the peer is sending > no data. Because WL2 has not been dragged along, the check to see if the > current ACK is "fresh" can fail. I was seeing this all the time with > a gigabit-rate xfer I was using for a test. > > Because the slow-path ACKs do not update the window, the snd_wnd closes, > and becomes 0. > > Once snd_wnd becomes zero, we end up performing zero-window probes on the > sender. We send one byte. The receiver, meanwhile, has opened his > window up again, and ACKs the byte, with an open window. > > The slow-path processing of this ACK will still ignore the window update, > and the following code will set snd_wnd to -1. > > if (acked > so->so_snd.sb_cc) { > tp->snd_wnd -= so->so_snd.sb_cc; > sbdrop(&so->so_snd, (int)so->so_snd.sb_cc); > ourfinisacked = 1; > } else { > sbdrop(&so->so_snd, acked); > tp->snd_wnd -= acked; > ourfinisacked = 0; > } > > > acked was 1, tp->snd_wnd was 0. snd_wnd is unsigned. > We suddenly have a huge send window. Blast away! ... except we end up being > driven by the rexmit timer and slow start, again and again. > I am not really sure what happens in this mode. The activity light on the > link turns out except for brief, intermittent flashes, so I suppose it > rexmits, slow starts, gets going, overruns the window, ..... > > The snd_wnd keeps being decremented and will, given sufficient time, wrap > down to reasonable values, and this might recover. I have not had the > patience. > > There is a simple fix: > > if (tp->t_state == TCPS_ESTABLISHED && > (thflags & (TH_SYN|TH_FIN|TH_RST|TH_URG|TH_ACK)) == TH_ACK && > ((tp->t_flags & (TF_NEEDSYN|TF_NEEDFIN)) == 0) && > ((to.to_flags & TOF_TS) == 0 || > TSTMP_GEQ(to.to_tsval, tp->ts_recent)) && > /* > * Using the CC option is compulsory if once started: > * the segment is OK if no T/TCP was negotiated or > * if the segment has a CC option equal to CCrecv > */ > ((tp->t_flags & (TF_REQ_CC|TF_RCVD_CC)) != (TF_REQ_CC|TF_RCVD_CC) || > ((to.to_flags & TOF_CC) != 0 && to.to_cc == tp->cc_recv)) && > th->th_seq == tp->rcv_nxt && > tiwin && tiwin == tp->snd_wnd && > tp->snd_nxt == tp->snd_max) { > > /* > * drag along the snd_wl1 and snd_wl2 as we are implicitly > * updating the window with the new (same) value. > */ > > tp->snd_wl1 = th->th_seq; > tp->snd_wl2 = th->th_ack; > > BTW: I have not made this change to FreeBSD, but to a FreeBSD-derived > embedded network stack, so I can't even assure you that the above > two lines compile (as I had to edit them slightly to recast into the F-BSD > idiom). > > > Cheers, > Damon. > > > On Wed, Apr 17, 2002 at 01:13:47PM +0400, Alexander Isaev wrote: > > > > I have installed FreeBSD 4.5. Everything worked OK from the console. > > But when I tried to connect to it remotely (using SSH) I had some network troubles. > > From time to time to time the connection hangs for a short time. > > First of all I've tried to install another network card (I've replaced > > D-Link 550 with D-Link 538TX). But the problem still exists. Later > > I've noticed that network timeouts happen also when sending or > > receiving large files over SMTP/POP3. > > > > Can someone help me to solve this problem? > > > > Best regards, > > Alexander Isaev mailto:A.Isaev@astelit.ru > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-net" in the body of the message > > -- > -- > Damon Permezel > dap@damon.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 Fri Oct 25 13:13:13 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8F52F37B401 for <freebsd-net@FreeBSD.ORG>; Fri, 25 Oct 2002 13:13:11 -0700 (PDT) Received: from power.doogles.com (power.doogles.com [209.15.149.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id BB23E43E88 for <freebsd-net@FreeBSD.ORG>; Fri, 25 Oct 2002 13:13:09 -0700 (PDT) (envelope-from jyoung@power.doogles.com) Received: from localhost (jyoung@localhost) by power.doogles.com (8.11.6/8.11.6) with ESMTP id g9PKD6r02153; Fri, 25 Oct 2002 15:13:06 -0500 Date: Fri, 25 Oct 2002 15:13:06 -0500 (CDT) From: "Jason A. Young" <jyoung@power.doogles.com> To: Romain Kang <romain@kzsu.stanford.edu> Cc: Petri Helenius <pete@he.iki.fi>, <freebsd-net@FreeBSD.ORG> Subject: Re: post-ifconfig delay causes ntpdate failure? In-Reply-To: <20021025192653.GA45730@kzsu.stanford.edu> Message-ID: <Pine.LNX.4.44.0210251503370.5316-100000@power.doogles.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org On Fri, 25 Oct 2002, Romain Kang wrote: > On Fri, Oct 25, 2002 at 10:03:21PM +0300, Petri Helenius wrote: > > Are you sure that this is not caused by spanning tree delay on the ethernet > > switch you are probably connected to? > > Time for me to read up on STP bridging. However, I'd be a little > surprised that the delay would occur when both hosts are on the > same switch, and they were communicating immediately before the > client was rebooted (as in my tests). > > Whatever the cause, is there some method better than the ping loop > to determine if IP is actually getting out? > > Thanks, > Romain > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > This is a pretty common problem; often it stops you from getting a DHCP lease because the DHCP client will time out while the switch still has you in the listening or learning states. It doesn't matter that the two devices are on the same switch. Whenever a switch port with spanning-tree enabled comes up, the switchport you're on will not accept any traffic from you for 30 seconds or so. It's likely that your ifconfig statement causes link to drop briefly. The solution for this is to not run spanning-tree on that switchport. Or, if you have a Cisco switch or another type of switch that supports skipping the listening and learning stages of spanning-tree for ports you know only workstations are connected to, you can enable that. On Cisco IOS-based switches this is 'spanning-tree portfast'; on Cisco Catalyst OS-based switches, use 'set port host X/Y' - this disables a few things, including spanning-tree. If you don't have access to the switch, you're basically going to have to put up with it. If it's causing a problem in your boot sequence, insert a 30-second sleep after ifconfig. -- Jason Young, CCIE #8607, MCSE Sr. Network Technician, WAN Technologies (314)817-0131 http://www.wantec.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 25 14: 3:18 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3632837B401 for <freebsd-net@FreeBSD.ORG>; Fri, 25 Oct 2002 14:03:17 -0700 (PDT) Received: from tninet.se (lennier.tninet.se [195.100.94.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id 08BCC43E42 for <freebsd-net@FreeBSD.ORG>; Fri, 25 Oct 2002 14:03:15 -0700 (PDT) (envelope-from krs@canit.se) Received: from canit.se (h72n5c1o1026.bredband.skanova.com [217.209.176.72]) by lennier.tninet.se (BMR ErlangTM/OTP 3.0) with ESMTP id 96709.579794.1035.0s123004lennier for <freebsd-net@FreeBSD.ORG> ; Fri, 25 Oct 2002 23:03:14 +0200 Date: Sat, 26 Oct 2002 23:03:31 +0200 Mime-Version: 1.0 (Apple Message framework v546) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: Choosing interface for a destination From: Robert Staflin <krs@canit.se> To: freebsd-net@FreeBSD.ORG Content-Transfer-Encoding: 7bit Message-Id: <61AA1726-E926-11D6-B166-00039304172A@canit.se> X-Mailer: Apple Mail (2.546) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org I'm developing an application to set the interface to use for different IP addresses, e.g. if I want to use a modem to talk to certain "protected" nets while using the ordinary ethernet port for web access a.s.o. I've wracked my head for two days now, trying different ways of making "route" do the job, to no avail. At the moment I'm running with the ethernet card (en0) as 192.168.0.2 and a wlan card (en1) as 192.168.0.5. Now, I want to reach the address 192.168.0.3 through en1 instead of en0. If I try i.e. route -n add -host 192.168.0.3 -interface 192.168.0.5 no traffic at all gets through, and I have to delete the route again. Netstat -r gives me (no change after adding the above route): Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default UGSc 13 137 en0 localhost localhost UH 12 56901 lo0 169.254 link#4 UCS 0 0 en0 192.168.0 link#4 UCS 2 0 en0 0:5:5d:dc:33:3c UHLW 13 0 en0 765 localhost UHS 0 47 lo0 0:50:e4:30:7a:71 UHLW 0 54 en0 324 localhost UHS 0 0 lo0 I've only tried this in Windows before, so please bear with me if I seem like a total newbie! Thanks for any help! /Robert Staflin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 25 15:25:52 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 67D7837B401; Fri, 25 Oct 2002 15:25:48 -0700 (PDT) Received: from mail.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A88543E65; Fri, 25 Oct 2002 15:25:47 -0700 (PDT) (envelope-from don@sandvine.com) Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19) id <42S9VJ68>; Fri, 25 Oct 2002 18:25:46 -0400 Message-ID: <FE045D4D9F7AED4CBFF1B3B813C8533701022D87@mail.sandvine.com> From: Don Bowman <don@sandvine.com> To: "'freebsd-stable@freebsd.org'" <freebsd-stable@freebsd.org>, "'freebsd-net@freebsd.org'" <freebsd-net@freebsd.org> Subject: panic in 4.7 in close / sbdrop Date: Fri, 25 Oct 2002 18:25:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org I have a machine running 4.7. I can panic it by sending a reasonably high load of tcp open/close from/to it. The trace below is from a socket from localhost to localhost (sendmail). The max number of open file descriptors I would have had would be ~4500. The rx buffer says it has 43008 bytes, but there are no mbufs chained. The system was not out of mbufs or clusters. Suggestions on what I might look @? #0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:487 #1 0xc01c41c7 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:316 #2 0xc01c4639 in panic (fmt=0xc0331205 "sbdrop") at /usr/src/sys/kern/kern_shutdown.c:595 #3 0xc01e60e7 in sbdrop (sb=0xeaf677e8, len=43008) at /usr/src/sys/kern/uipc_socket2.c:877 #4 0xc01e607c in sbflush (sb=0xeaf677e8) at /usr/src/sys/kern/uipc_socket2.c:852 #5 0xc022697f in tcp_disconnect (tp=0xecf24a40) at /usr/src/sys/netinet/tcp_usrreq.c:1077 #6 0xc02260f2 in tcp_usr_disconnect (so=0xeaf677a0) at /usr/src/sys/netinet/tcp_usrreq.c:406 #7 0xc01e3450 in sodisconnect (so=0xeaf677a0) at /usr/src/sys/kern/uipc_socket.c:422 #8 0xc01e326a in soclose (so=0xeaf677a0) at /usr/src/sys/kern/uipc_socket.c:302 #9 0xc01d73fa in soo_close (fp=0xd049ab80, p=0xe91bd5a0) at /usr/src/sys/kern/sys_socket.c:195 #10 0xc01b9c37 in fdrop (fp=0xd049ab80, p=0xe91bd5a0) at /usr/src/sys/sys/file.h:217 #11 0xc01b9b7f in closef (fp=0xd049ab80, p=0xe91bd5a0) at /usr/src/sys/kern/kern_descrip.c:1277 #12 0xc01b978c in fdfree (p=0xe91bd5a0) at /usr/src/sys/kern/kern_descrip.c:1059 #13 0xc01bc475 in exit1 (p=0xe91bd5a0, rv=0) at /usr/src/sys/kern/kern_exit.c:187 #14 0xc01bc2dc in exit1 (p=0xe91bd5a0, rv=16777218) at /usr/src/sys/kern/kern_exit.c:103 #15 0xc02edc71 in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 0, tf_esi = 15, tf_ebp = -1077950764, tf_isp = -221909036, tf_ebx = 0, tf_edx = 126, tf_ecx = -1077950820, tf_eax = 1, tf_trapno = 0, tf_err = 2, tf_eip = 673302376, tf_cs = 31, tf_eflags = 659, tf_esp = -1077950856, tf_ss = 47}) at /usr/src/sys/i386/i386/trap.c:1175 #16 0xc02da38b in Xint0x80_syscall () void sbdrop(sb, len) register struct sockbuf *sb; register int len; { register struct mbuf *m; struct mbuf *next; next = (m = sb->sb_mb) ? m->m_nextpkt : 0; while (len > 0) { if (m == 0) { if (next == 0) panic("sbdrop");<<<<<<<<<<<<<<< m = next; next = m->m_nextpkt; continue; } (kgdb) p/x *sb $39 = {sb_cc = 0xa800, sb_hiwat = 0xe000, sb_mbcnt = 0xbd00, sb_mbmax = 0x40000, sb_lowat = 0x1, sb_mb = 0x0, sb_mbtail = 0x0, sb_lastrecord = 0x0, sb_sel = {si_pid = 0x0, si_note = {slh_first = 0x0}, si_flags = 0x0}, sb_flags = 0x0, sb_timeo = 0x0} called from: void sbflush(sb) register struct sockbuf *sb; { KASSERT((sb->sb_flags & SB_LOCK) == 0, ("sbflush: locked")); while (sb->sb_mbcnt) sbdrop(sb, (int)sb->sb_cc);<<<<<<<<<<<<<<<<<< called from: static struct tcpcb * tcp_disconnect(tp) register struct tcpcb *tp; { struct socket *so = tp->t_inpcb->inp_socket; if (tp->t_state < TCPS_ESTABLISHED) tp = tcp_close(tp); else if ((so->so_options & SO_LINGER) && so->so_linger == 0) tp = tcp_drop(tp, 0); else { soisdisconnecting(so); sbflush(&so->so_rcv); <<<<<<<<<<<<<<<<< tp = tcp_usrclosed(tp); if (tp) (void) tcp_output(tp); } return (tp); } (kgdb) p/x *tp $44 = {t_segq = {lh_first = 0x0}, t_dupacks = 0x0, unused = 0x0, tt_rexmt = 0xecf24b24, tt_persist = 0xecf24b3c, tt_keep = 0xecf24b54, tt_2msl = 0xecf24b6c, tt_delack = 0xecf24b84, t_inpcb = 0xecf24980, t_state = 0x4, t_flags = 0x801e0, t_force = 0x0, snd_una = 0x8bcbf58f, snd_max = 0x8bcbf58f, snd_nxt = 0x8bcbf58f, snd_up = 0x8bcbf58f, snd_wl1 = 0xab47117a, snd_wl2 = 0x8bcbf58f, iss = 0x8bcbf3cb, irs = 0xab4710f2, rcv_nxt = 0xab47fea8, rcv_adv = 0xab47f17a, rcv_wnd = 0xe000, rcv_up = 0xab47117a, snd_wnd = 0xe000, snd_cwnd = 0xffff, snd_bwnd = 0x3fffc000, snd_ssthresh = 0x3fffc000, snd_bandwidth = 0x0, snd_recover = 0x8bcbf3cb, t_maxopd = 0x3fd8, t_rcvtime = 0x101c3f1, t_starttime = 0x4588, t_rtttime = 0x0, t_rtseq = 0x8bcbf52f, t_bw_rtttime = 0x4588, t_bw_rtseq = 0x0, t_rxtcur = 0x4b0, t_maxseg = 0x3800, t_srtt = 0x14, t_rttvar = 0xb, t_rxtshift = 0x0, t_rttmin = 0x3e8, t_rttbest = 0x1f, t_rttupdated = 0x5, max_sndwnd = 0xe000, t_softerror = 0x0, t_oobflags = 0x0, t_iobc = 0x0, snd_scale = 0x0, rcv_scale = 0x0, request_r_scale = 0x0, requested_s_scale = 0x0, ts_recent = 0x101c3f1, ts_recent_age = 0x101c3f1, last_ack_sent = 0xab47fea8, cc_send = 0x0, cc_recv = 0x0, snd_cwnd_prev = 0x0, snd_ssthresh_prev = 0x0, t_badrxtwin = 0x0} (kgdb) p/x *so $45 = {so_type = 0x1, so_options = 0xc, so_linger = 0x0, so_state = 0x3a, so_pcb = 0xecf24980, so_proto = 0xc0376b28, so_head = 0x0, so_incomp = { tqh_first = 0x0, tqh_last = 0x0}, so_comp = {tqh_first = 0x0, tqh_last = 0x0}, so_list = {tqe_next = 0x0, tqe_prev = 0xeaf67a5c}, so_qlen = 0x0, so_incqlen = 0x0, so_qlimit = 0x0, so_timeo = 0x0, so_error = 0x0, so_sigio = 0x0, so_oobmark = 0x0, so_aiojobq = { tqh_first = 0x0, tqh_last = 0xeaf677e0}, so_rcv = {sb_cc = 0xa800, sb_hiwat = 0xe000, sb_mbcnt = 0xbd00, sb_mbmax = 0x40000, sb_lowat = 0x1, sb_mb = 0x0, sb_mbtail = 0x0, sb_lastrecord = 0x0, sb_sel = {si_pid = 0x0, si_note = {slh_first = 0x0}, si_flags = 0x0}, sb_flags = 0x0, sb_timeo = 0x0}, so_snd = {sb_cc = 0x0, sb_hiwat = 0xe000, sb_mbcnt = 0x0, sb_mbmax = 0x40000, sb_lowat = 0x800, sb_mb = 0x0, sb_mbtail = 0x0, sb_lastrecord = 0x0, sb_sel = {si_pid = 0x0, si_note = {slh_first = 0x0}, si_flags = 0x0}, sb_flags = 0x0, sb_timeo = 0x0}, so_upcall = 0x0, so_upcallarg = 0x0, so_cred = 0xd0490780, so_gencnt = 0xaf, so_emuldata = 0x0, so_accf = 0x0} (kgdb) p/x *so->so_proto $49 = {pr_type = 0x1, pr_domain = 0xc0376ce0, pr_protocol = 0x6, pr_flags = 0x2c, pr_input = 0xc0220334, pr_output = 0x0, pr_ctlinput = 0xc0224094, pr_ctloutput = 0xc02266c4, pr_ousrreq = 0x0, pr_init = 0xc022348c, pr_fasttimo = 0x0, pr_slowtimo = 0xc0225a1c, pr_drain = 0xc0223c70, pr_usrreqs = 0xc0378ca0} --don (don@sandvine.com www.sandvine.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 25 15:28:51 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2191D37B401 for <freebsd-net@FreeBSD.ORG>; Fri, 25 Oct 2002 15:28:48 -0700 (PDT) Received: from aker.amduat.net (aker.amduat.net [206.124.149.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0E9D243E65 for <freebsd-net@FreeBSD.ORG>; Fri, 25 Oct 2002 15:28:47 -0700 (PDT) (envelope-from jbarrett@amduat.net) Received: from amduat.net (nat-bhm1.attachmate.com [63.115.16.66]) (authenticated bits=0) by aker.amduat.net (8.12.5/8.12.5) with ESMTP id g9PMSdT7051541; Fri, 25 Oct 2002 15:28:40 -0700 (PDT) (envelope-from jbarrett@amduat.net) Message-ID: <3DB9C596.7090802@amduat.net> Date: Fri, 25 Oct 2002 15:28:38 -0700 From: "Jacob S. Barrett" <jbarrett@amduat.net> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b) Gecko/20021016 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Luigi Rizzo <rizzo@icir.org> Cc: freebsd-net@FreeBSD.ORG Subject: Re: determining "originator/source" of connection ... References: <20021022143427.Y47756-100000@hub.org> <20021022113249.C33933@carp.icir.org> In-Reply-To: <20021022143427.Y47756-100000@hub.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org Is there a way to zero out the packet/byte counters on pipes and queues like you can to the rules? The command "ipfw pipe|queue zero" display a message that accounting was cleared, but rather than clear out pipe or queue counters it clears the rules counters only. Am I missing something or is this just not possible yet? -Jake Luigi Rizzo wrote: > let me understand, you basically want something that puts flow statistics > in the bucket identified by the of the first SYN > packet you see (the assumption being that connections are > initiated by clients towards a well known port, which appears > as dst-port in the first syn packet ? > > Or if you are just happy to aggregate by IP, one solution i often > use is the following (based on dummynet's dynamic pipes): > > # do not expire pipes even if they have no pending traffic > sysctl net.inet.ip.dummynet.expire=0 > > # create separate pipes for src and dst masks > ipfw pipe 20 config mask src-ip 0xffffffff buckets 256 > ipfw pipe 21 config mask dst-ip 0xffffffff buckets 256 > > ipfw add pipe 20 ip from $my_subnet to any > ipfw add pipe 21 ip from any to $my subnet > > cheers > luigi > > > On Tue, Oct 22, 2002 at 02:47:36PM -0300, Marc G. Fournier wrote: > > >I've got FreeBSD setup as a firewall to our campus network, and its doing > >a great job of it, but we want to be able log statistics on traffic going > >in and out ... > > > >I have trafd running on the server, with it dumping its data to a > >PostgreSQL database, but for every ~8min "segment", it is logging ~12 000 > >records ... so ~90k/hr, or 2.16 million per day ... > > > >Now, I'm figuring that if I could determine direction of flow (did we > >originate the connection, or did someone off campus originate it), I > could > >shrink that greatly, as right now I have stuff like: > > > >216.158.133.242 80 131.162.158.24 3914 6 2356 4 > >216.158.133.242 80 131.162.158.24 3915 6 47767 34 > >216.158.133.242 80 131.162.158.24 3916 6 78962 56 > >216.158.133.242 80 131.162.158.24 3917 6 330141 224 > >216.158.133.242 80 131.162.158.24 3918 6 118862 89 > >216.158.133.242 80 131.162.158.24 3919 6 264139 185 > >216.158.133.242 80 131.162.158.24 3920 6 259543 179 > >216.158.133.242 80 131.162.158.24 3921 6 98014 73 > >216.158.133.242 80 131.162.158.24 3922 6 267772 186 > >216.158.133.242 80 131.162.158.24 3923 6 148879 109 > >216.158.133.242 80 131.162.158.24 3924 6 6406 8 > >216.158.133.242 80 131.162.158.24 3925 6 2486 5 > >216.158.133.242 80 131.162.158.24 3928 6 109584 75 > >216.158.133.242 80 131.162.158.24 3929 6 92435 62 > >216.158.133.242 80 131.162.158.24 3936 6 13059 9 > >216.158.133.242 80 131.162.158.24 3937 6 22641 17 > > > >where I don't care about the source port, only the dest port ... except, > >in the above, trafd is writing it as 'source port == 80' and 'dest port' > >is arbitray ... > > > >while later in the results, I'll get something like: > > > > 130.94.4.7 40072 131.162.138.193 25 6 2976 10 > > 130.94.4.7 58562 131.162.138.193 25 6 5249 16 > > > >which does make sense (ie. source port -> dest port) ... > > > >is there something that i can do with libpcap that will give me better > >information then trafd does? is there a 'tag' in the IP headers that can > >be used to determine the originator of the connection? > > > >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 -- Jacob S. Barrett jbarrett@amduat.net www.amduat.net "I don't suffer from insanity, I enjoy every minute of it." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Oct 26 0:54:39 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B02C737B401; Sat, 26 Oct 2002 00:54:38 -0700 (PDT) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by mx1.FreeBSD.org (Postfix) with SMTP id 4143F43E3B; Sat, 26 Oct 2002 00:54:37 -0700 (PDT) (envelope-from dwmalone@maths.tcd.ie) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id <aa78492@salmon>; 26 Oct 2002 08:54:36 +0100 (BST) Date: Sat, 26 Oct 2002 08:54:35 +0100 From: David Malone <dwmalone@maths.tcd.ie> To: Don Bowman <don@sandvine.com> Cc: "'freebsd-stable@freebsd.org'" <freebsd-stable@freebsd.org>, "'freebsd-net@freebsd.org'" <freebsd-net@freebsd.org> Subject: Re: panic in 4.7 in close / sbdrop Message-ID: <20021026075435.GA47984@walton.maths.tcd.ie> References: <FE045D4D9F7AED4CBFF1B3B813C8533701022D87@mail.sandvine.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <FE045D4D9F7AED4CBFF1B3B813C8533701022D87@mail.sandvine.com> User-Agent: Mutt/1.3.25i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org On Fri, Oct 25, 2002 at 06:25:44PM -0400, Don Bowman wrote: > I have a machine running 4.7. I can panic it by sending a reasonably > high load of tcp open/close from/to it. The trace below is from > a socket from localhost to localhost (sendmail). The max number > of open file descriptors I would have had would be ~4500. > The rx buffer says it has 43008 bytes, but there are no mbufs > chained. The system was not out of mbufs or clusters. > > Suggestions on what I might look @? I made a change in this area which doesn't show up in the call path, but might possibly be related. Can you edit /usr/src/sys/kern/uipc_socket2.c and comment out the call to sbdrop in soisdisconnected and see if it makes a difference? David. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Oct 26 1:39:14 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0311E37B401 for <freebsd-net@freebsd.org>; Sat, 26 Oct 2002 01:39:12 -0700 (PDT) Received: from mailhost.nxad.com (lan.ext.nxad.com [66.250.180.254]) by mx1.FreeBSD.org (Postfix) with ESMTP id 83C6143E6A for <freebsd-net@freebsd.org>; Sat, 26 Oct 2002 01:39:11 -0700 (PDT) (envelope-from sean@nxad.com) Received: from perrin.int.nxad.com (perrin.int.nxad.com [192.168.1.251]) by mailhost.nxad.com (Postfix) with ESMTP id 1C826212EF5 for <freebsd-net@freebsd.org>; Sat, 26 Oct 2002 01:39:01 -0700 (PDT) Received: by perrin.int.nxad.com (Postfix, from userid 1001) id E1A3C20F01; Sat, 26 Oct 2002 01:38:59 -0700 (PDT) Date: Sat, 26 Oct 2002 01:38:59 -0700 From: Sean Chittenden <sean@chittenden.org> To: freebsd-net@freebsd.org Subject: Max'ed out mbuf's while being rate shapped... Message-ID: <20021026083859.GA84959@perrin.int.nxad.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Q68bSM7Ycu6FN28Q" Content-Disposition: inline User-Agent: Mutt/1.4i X-PGP-Key: finger seanc@FreeBSD.org X-PGP-Fingerprint: 6CEB 1B06 BFD3 70F6 95BE 7E4D 8E85 2E0A 5F5B 3ECB X-Web-Homepage: http://sean.chittenden.org/ Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org --Q68bSM7Ycu6FN28Q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I had the lovely privilege of receiving an exorbitantly large amount of traffic that was sent to one host (not a DoS) and the box held up rather well until I slapped a cap on the particular machine. mbuf cluster usage went from around 8K to healthy 65536 in about 15sec. Now that things have leveled out and I've tossed three other servers at the problem, things have leveled out, however, I've got a few remaining questions on the topic. The web server I'm using is far, far, far from RAM or CPU bound. It wouldn't surprise me in the slightest if this server could handle 40K connections doing around 40Mbps. In fact, I'd actually be disappointed if I was only getting 40Mbps out of this box/webserver. Doing 20Mbps right now takes only 2-4% CPU and normally around only 8K mbuf clusters: I think I'm in good shape there. This is a dynamic server though, so there isn't an disk IO: think kqueue() meets write(). In the event that I slap a bandwidth a cap on the webserver, how can I prevent the system from getting run into the ground with mbuf depletion? On my desktop, it looks like 2^17 is as high as I can take number of mbuf clusters. Originally I had both the tcp send/recv space set to 65536, but that was naive. I've cranked things down to 24576 and 32768, respectively. I'm more worried about depletion of kernel resources than I am userland resources. I have some 1GB of free RAM that I'd love to have utilized. Here go the questions: 1) Is there a way of dynamically scaling the tcp send/recv space based off of mbuf cluster utilization? Being able to change the send space on the fly based off of current load usage would be hugely valuable.[1] 2) What's the minimum tcp send/recv space size that I could use? I'm less interested in flooding a switch/router with zillions of pps than I am in getting a host's ability to scale well under pressure. 3) From tuning(7), regarding tcp_inflight: "However, note that this feature only effects data transmission (uploading / server-side). It does not effect data reception (downloading)." Data transmission/receiving from who's point of view? A client's point of view or the servers? If I'm sending lots of data to thousands of connections, is it beneficial to have a min inflight value set? When were the inflight tunables were added? 4) Are there other tunables that I'm missing that I should look into? 5) On my upstream rate shaping device, are there any recommendations for the # of packets in queue and number of bits outstanding that help out with preventing a hosts mbufs being depleted in the event that a rate cap is hit? Thanks in advance. Here's a sample from one of my hosts. I've thrown a few more machines at things and have lifted the cap so things have gone down dramatically, however it wasn't more than two or three hours ago that these were maxed or hovering around 64K. -sc 1469/66416/262144 mbufs in use (current/peak/max): 1400 mbufs allocated to data 69 mbufs allocated to packet headers 1298/65536/65536 mbuf clusters in use (current/peak/max) 147676 Kbytes allocated to network (11% of mb_map in use) 1048972 requests for memory denied 11240 requests for memory delayed 0 calls to protocol drain routines [1] I know this is something I could dork out in a script, but under a burst of traffic, things will likely fall apart before a utility will have a chance to poll for data and adjust. Having the ability to turn off the incoming data, I did so upstream, and once I activated the service again, I was able to observe that my mbuf utilization went from 50K mbuf's to 65K in roughly 2sec... granted this isn't a fair test of 'normal.' --=20 Sean Chittenden --Q68bSM7Ycu6FN28Q Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Comment: Sean Chittenden <sean@chittenden.org> iD8DBQE9ulSjjoUuCl9bPssRAgjAAJ9Bj+GFHnJdZ6DjVB24ixZbOnSunACfe6pf nYUmqIIwS8Y5ve8h9SSvwjw= =IgCt -----END PGP SIGNATURE----- --Q68bSM7Ycu6FN28Q-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Oct 26 5:45:10 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3CB4437B401 for <freebsd-net@FreeBSD.ORG>; Sat, 26 Oct 2002 05:45:05 -0700 (PDT) Received: from tninet.se (sheridan.tninet.se [195.100.94.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id C99BC43E65 for <freebsd-net@FreeBSD.ORG>; Sat, 26 Oct 2002 05:45:03 -0700 (PDT) (envelope-from krs@canit.se) Received: from canit.se (h72n5c1o1026.bredband.skanova.com [217.209.176.72]) by sheridan.tninet.se (BMR ErlangTM/OTP 3.0) with ESMTP id 756662.636300.1035.1s415094sheridan for <freebsd-net@FreeBSD.ORG> ; Sat, 26 Oct 2002 14:45:00 +0200 Date: Sat, 26 Oct 2002 14:45:00 +0200 Subject: Re: Choosing interface for a destination Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v546) From: Robert Staflin <krs@canit.se> To: freebsd-net@FreeBSD.ORG Content-Transfer-Encoding: quoted-printable In-Reply-To: <61AA1726-E926-11D6-B166-00039304172A@canit.se> Message-Id: <BDD9A576-E8E0-11D6-B088-00039304172A@canit.se> X-Mailer: Apple Mail (2.546) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org It really was a newbie question - sorry for the bandwidth. If anyone=20 else wonders, email me and I'll help! /Robert Staflin On l=F6rdag, okt 26, 2002, at 23:03 Europe/Stockholm, Robert Staflin=20 wrote: > I'm developing an application to set the interface to use for=20 > different IP addresses, e.g. if I want to use a modem to talk to=20 > certain "protected" nets while using the ordinary ethernet port for=20 > web access a.s.o. > > I've wracked my head for two days now, trying different ways of making=20= > "route" do the job, to no avail. At the moment I'm running with the=20 > ethernet card (en0) as 192.168.0.2 and a wlan card (en1) as=20 > 192.168.0.5. Now, I want to reach the address 192.168.0.3 through en1=20= > instead of en0. If I try i.e. > > route -n add -host 192.168.0.3 -interface 192.168.0.5 > > no traffic at all gets through, and I have to delete the route again.=20= > Netstat -r gives me (no change after adding the above route): > > Routing tables > > Internet: > Destination Gateway Flags Refs Use Netif=20 > Expire > default UGSc 13 137 en0 > localhost localhost UH 12 56901 lo0 > 169.254 link#4 UCS 0 0 en0 > 192.168.0 link#4 UCS 2 0 en0 > 0:5:5d:dc:33:3c UHLW 13 0 en0 =20= > 765 > localhost UHS 0 47 lo0 > 0:50:e4:30:7a:71 UHLW 0 54 en0 =20= > 324 > localhost UHS 0 0 lo0 > > I've only tried this in Windows before, so please bear with me if I=20 > seem like a total newbie! > > Thanks for any help! > > /Robert Staflin > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D KRS Consulting =20 Robert Staflin Jenny Linds v=E4g 75 Tel: +46 (18)=20 369425 S-756 50 UPPSALA Mobile: +46 (708) 369578 SWEDEN To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Oct 26 11:17:50 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 721D637B401 for <freebsd-net@freebsd.org>; Sat, 26 Oct 2002 11:17:48 -0700 (PDT) Received: from smtp030.tiscali.dk (smtp030.tiscali.dk [212.54.64.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id C958043E75 for <freebsd-net@freebsd.org>; Sat, 26 Oct 2002 11:17:41 -0700 (PDT) (envelope-from thomas@gielfeldt.dk) Received: from [10.0.1.126] (213.237.34.52.adsl.suoe.worldonline.dk [213.237.34.52]) by smtp030.tiscali.dk (8.12.5/8.12.5) with SMTP id g9QIHcp4022487 for <freebsd-net@freebsd.org>; Sat, 26 Oct 2002 20:17:38 +0200 (MEST) From: Thomas Gielfeldt <thomas@gielfeldt.dk> Subject: Connecting two LANs via VPN To: freebsd-net@freebsd.org Date: Sat, 26 Oct 2002 20:22:15 +0200 Lines: 79 Message-ID: <MWMail.hbhkhbae@host.none> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mailer: Kaufman Mail Warrior 3,61 Final Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org Hi I'm trying to set up a VPN connection between two freebsd gateways. What I want to do is to setup a connection between the two gateways, so that all the hosts on the two networks are connected to each other, as if they physically were on one network. Below is a schematic of my network setup. +--------------+ <public ip> | Cisco Router | --------------- +--------------+ <172.16.0.1/16> | | | +--------------+ | Switch | +--------------+ / \ / \ / \ / \ <172.16.1.1/16> +-----------+ +-----------+ <172.16.2.1/16> ----------------- | Gateway A | | Gateway B | ----------------- <10.0.1.1/24> +-----------+ +-----------+ <10.0.2.1/24> | | | | | | +------------------------------+ +------------------------------+ | Network A | | Network B | | | | | | | | | | | | | | +---------+ +---------+ | | +---------+ +---------+ | | | Host A1 | | Host A2 | | | | Host B1 | | Host B2 | | | +---------+ +---------+ | | +---------+ +---------+ | | <10.0.1.2/24> <10.0.1.3/24> | | <10.0.2.2/24> <10.0.2.3/24> | +------------------------------+ +------------------------------+ I have tried it using: VTun 2.5 ppp PopTop mpd IPSec OpenVPN I have gotten them all to work, and all hosts can see each other. There's only one thing which doesn't work... Broadcast packets... The setup is intended for gaming, and most games search for servers by sending out broadcast packets to address 255.255.255.255. My goal is to make a packet from e.g. 10.0.1.2 destined for 255.255.255.255, forwarded to the 10.0.2.0 net. I think I've tried just about any approach I can think of, so now I need some help. I can see the packets destined for 255.255.255.255 comming in on the gateway through the tun- device, but they don't seem to get any further than that. Each gateway is more or less configured similarly, running IPFilter (with ipnat). If anyone has any ideas or examples on how to do this please don't hesitate to share them with me. If you need to see some of my config files just say so and I'll post the ones you want to see. (I didn't want to post every config file I've tried for this setup 'cause then this posting would really have gotten bloated). The IP's and netmasks given to the networks aren't essential in any way, so if they have to be changed, that's fine. BTW. IPSec only works for me sometimes? But I've dropped the IPSec solution, since I could understand that it wasn't possible to tunnel IPX packets through IPSec. IPX over this VPN connection is of course my next plan, once I've gotten this to work. Thanks in advance. Best Regards Thomas Gielfeldt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Oct 26 12: 0:26 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0C38937B401 for <freebsd-net@freebsd.org>; Sat, 26 Oct 2002 12:00:23 -0700 (PDT) Received: from InterJet.elischer.org (12-232-206-8.client.attbi.com [12.232.206.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 856E943E65 for <freebsd-net@freebsd.org>; Sat, 26 Oct 2002 12:00:22 -0700 (PDT) (envelope-from julian@elischer.org) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA13589; Sat, 26 Oct 2002 11:50:17 -0700 (PDT) Date: Sat, 26 Oct 2002 11:50:17 -0700 (PDT) From: Julian Elischer <julian@elischer.org> To: Thomas Gielfeldt <thomas@gielfeldt.dk> Cc: freebsd-net@freebsd.org Subject: Re: Connecting two LANs via VPN In-Reply-To: <MWMail.hbhkhbae@host.none> Message-ID: <Pine.BSF.4.21.0210261141590.13443-100000@InterJet.elischer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org gosh there are almost too many ways to do this.. I use mpd, connected by a UDP tunnel over IPSEC I use mpd for it's multilink capability, and have multiple UDP tunnels, connected via different ISPs, so if one goes down it only degrades my link rather than cutting it.. On Sat, 26 Oct 2002, Thomas Gielfeldt wrote: > Hi > > I'm trying to set up a VPN connection between two freebsd gateways. > What I want to do is to setup a connection between the two gateways, so that all the hosts on the > two networks are connected to each other, as if they physically were on one network. > > Below is a schematic of my network setup. > > > +--------------+ <public ip> > | Cisco Router | --------------- > +--------------+ <172.16.0.1/16> > | > | > | > +--------------+ > | Switch | > +--------------+ > / \ > / \ > / \ > / \ > <172.16.1.1/16> +-----------+ +-----------+ <172.16.2.1/16> > ----------------- | Gateway A | | Gateway B | ----------------- > <10.0.1.1/24> +-----------+ +-----------+ <10.0.2.1/24> > | | > | | > | | > +------------------------------+ +------------------------------+ > | Network A | | Network B | > | | | | > | | | | > | | | | > | +---------+ +---------+ | | +---------+ +---------+ | > | | Host A1 | | Host A2 | | | | Host B1 | | Host B2 | | > | +---------+ +---------+ | | +---------+ +---------+ | > | <10.0.1.2/24> <10.0.1.3/24> | | <10.0.2.2/24> <10.0.2.3/24> | > +------------------------------+ +------------------------------+ > > > I have tried it using: > VTun 2.5 > ppp > PopTop > mpd > IPSec > OpenVPN > > I have gotten them all to work, and all hosts can see each other. > There's only one thing which doesn't work... Broadcast packets... Broadcast packets can't be used between two networks. you need to be bridging, not routing.. > The setup is intended for gaming, and most games search for servers > by sending out broadcast packets to address 255.255.255.255. My goal > is to make a packet from e.g. 10.0.1.2 destined for 255.255.255.255, > forwarded to the 10.0.2.0 net. I think I've tried just about any > approach I can think of, so now I need some help. you can use ipfw and a divert socket to capture such packets and forward them. you will need to write your own daemon to forward them to the other net. > > I can see the packets destined for 255.255.255.255 comming in on the > gateway through the tun- device, but they don't seem to get any > further than that. > > Each gateway is more or less configured similarly, running IPFilter > (with ipnat). > > If anyone has any ideas or examples on how to do this please don't > hesitate to share them with me. If you need to see some of my config > files just say so and I'll post the ones you want to see. (I didn't > want to post every config file I've tried for this setup 'cause then > this posting would really have gotten bloated). The IP's and > netmasks given to the networks aren't essential in any way, so if > they have to be changed, that's fine. > > BTW. IPSec only works for me sometimes? But I've dropped the IPSec > solution, since I could understand that it wasn't possible to tunnel > IPX packets through IPSec. IPX over this VPN connection is of course > my next plan, once I've gotten this to work. then you need an encapsulation protocol that handles multiple protocols.. maybe ppp protocol. > > Thanks in advance. > > Best Regards > Thomas Gielfeldt BTW try keep line lengths below about 75 chars.. this was reformatted by my mailer so I could read it... > > > 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 Sat Oct 26 13:45:15 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 51CBB37B401 for <freebsd-net@FreeBSD.org>; Sat, 26 Oct 2002 13:45:14 -0700 (PDT) Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id A66E543E4A for <freebsd-net@FreeBSD.org>; Sat, 26 Oct 2002 13:45:13 -0700 (PDT) (envelope-from archie@dellroad.org) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id NAA45285; Sat, 26 Oct 2002 13:32:54 -0700 (PDT) Received: from arch20m.dellroad.org (localhost [127.0.0.1]) by arch20m.dellroad.org (8.12.6/8.12.6) with ESMTP id g9QKWrON035893; Sat, 26 Oct 2002 13:32:53 -0700 (PDT) (envelope-from archie@arch20m.dellroad.org) Received: (from archie@localhost) by arch20m.dellroad.org (8.12.6/8.12.6/Submit) id g9QKWrE4035892; Sat, 26 Oct 2002 13:32:53 -0700 (PDT) From: Archie Cobbs <archie@dellroad.org> Message-Id: <200210262032.g9QKWrE4035892@arch20m.dellroad.org> Subject: Re: Connecting two LANs via VPN In-Reply-To: <MWMail.hbhkhbae@host.none> "from Thomas Gielfeldt at Oct 26, 2002 08:22:15 pm" To: Thomas Gielfeldt <thomas@gielfeldt.dk> Date: Sat, 26 Oct 2002 13:32:53 -0700 (PDT) Cc: freebsd-net@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org Thomas Gielfeldt writes: > I have gotten them all to work, and all hosts can see each other. There's only one thing which > doesn't work... Broadcast packets... Of course, because broadcast packets are not routed. You might try configuring both sides to be on the same subnet (but with non-conflicting IP addresses) then use ng_bridge to set up a bridged network across your VPN (e.g.). You'd need a VPN technology compatible with netgraph, e.g., UDP-over-IPSec. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Oct 26 14:26:30 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 44AF237B401 for <freebsd-net@FreeBSD.ORG>; Sat, 26 Oct 2002 14:26:29 -0700 (PDT) Received: from pursued-with.net (adsl-66-125-9-242.dsl.sndg02.pacbell.net [66.125.9.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id B8A6043E4A for <freebsd-net@FreeBSD.ORG>; Sat, 26 Oct 2002 14:26:28 -0700 (PDT) (envelope-from Kevin_Stevens@pursued-with.net) Received: from pursued-with.net (fffinch [192.168.168.101]) by pursued-with.net (8.12.6/8.12.5) with ESMTP id g9QLQSsG001133 for <freebsd-net@FreeBSD.ORG>; Sat, 26 Oct 2002 14:26:28 -0700 (PDT) (envelope-from Kevin_Stevens@pursued-with.net) Date: Sat, 26 Oct 2002 14:26:27 -0700 Mime-Version: 1.0 (Apple Message framework v546) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: Annoying ARP warning messages. From: Kevin Stevens <Kevin_Stevens@pursued-with.net> To: freebsd-net@FreeBSD.ORG Content-Transfer-Encoding: 7bit Message-Id: <963CFD4C-E929-11D6-BF1E-003065715DA8@pursued-with.net> X-Mailer: Apple Mail (2.546) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org I have two systems connected through a common network (switch). They each have two NICs, with one addressed on one IP network and the second on another. IP works fine. My problem is that the kernel keeps bitching about seeing the same MAC addresses on both interfaces: Oct 26 06:15:03 babelfish /kernel: arp: 192.168.168.101 is on em0 but got reply from 00:30:65:00:e6:e6 on xl0 (Last message repeated ad nauseum) Any way of shutting the damn thing up? KeS To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Oct 26 14:28:40 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 076D037B401 for <freebsd-net@FreeBSD.ORG>; Sat, 26 Oct 2002 14:28:40 -0700 (PDT) Received: from mail.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7DD3943E42 for <freebsd-net@FreeBSD.ORG>; Sat, 26 Oct 2002 14:28:39 -0700 (PDT) (envelope-from don@sandvine.com) Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19) id <42S9VKQS>; Sat, 26 Oct 2002 17:28:38 -0400 Message-ID: <FE045D4D9F7AED4CBFF1B3B813C8533701022D92@mail.sandvine.com> From: Don Bowman <don@sandvine.com> To: 'Kevin Stevens' <Kevin_Stevens@pursued-with.net>, freebsd-net@FreeBSD.ORG Subject: RE: Annoying ARP warning messages. Date: Sat, 26 Oct 2002 17:28:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org Kevin Stevens wrote: > I have two systems connected through a common network (switch). They > each have two NICs, with one addressed on one IP network and the second > on another. IP works fine. My problem is that the kernel keeps > bitching about seeing the same MAC addresses on both interfaces: > > Oct 26 06:15:03 babelfish /kernel: arp: 192.168.168.101 is on em0 but > got reply from 00:30:65:00:e6:e6 on xl0 systcl net.link.ether.inet.log_arp_wrong_iface=0 --don (don@sandvine.com www.sandvine.com p2p) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Oct 26 14:31:27 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DDD8537B401 for <freebsd-net@FreeBSD.ORG>; Sat, 26 Oct 2002 14:31:26 -0700 (PDT) Received: from pursued-with.net (adsl-66-125-9-242.dsl.sndg02.pacbell.net [66.125.9.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 62A9B43E3B for <freebsd-net@FreeBSD.ORG>; Sat, 26 Oct 2002 14:31:26 -0700 (PDT) (envelope-from Kevin_Stevens@pursued-with.net) Received: from pursued-with.net (fffinch [192.168.168.101]) by pursued-with.net (8.12.6/8.12.5) with ESMTP id g9QLVQsG001158; Sat, 26 Oct 2002 14:31:26 -0700 (PDT) (envelope-from Kevin_Stevens@pursued-with.net) Date: Sat, 26 Oct 2002 14:31:25 -0700 Subject: Re: Annoying ARP warning messages. Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: freebsd-net@FreeBSD.ORG To: Don Bowman <don@sandvine.com> From: Kevin Stevens <Kevin_Stevens@pursued-with.net> In-Reply-To: <FE045D4D9F7AED4CBFF1B3B813C8533701022D92@mail.sandvine.com> Message-Id: <47B0ED2D-E92A-11D6-BF1E-003065715DA8@pursued-with.net> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org On Saturday, Oct 26, 2002, at 14:28 US/Pacific, Don Bowman wrote: > systcl net.link.ether.inet.log_arp_wrong_iface=0 Gee, why didn't that permutation of keystrokes occur to me? ;) Thanks. KeS To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Oct 26 16:40:20 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 83A8537B434 for <freebsd-net@FreeBSD.ORG>; Sat, 26 Oct 2002 16:40:18 -0700 (PDT) Received: from InterJet.elischer.org (12-232-206-8.client.attbi.com [12.232.206.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1B54143E3B for <freebsd-net@FreeBSD.ORG>; Sat, 26 Oct 2002 16:40:18 -0700 (PDT) (envelope-from julian@elischer.org) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id QAA14622; Sat, 26 Oct 2002 16:20:13 -0700 (PDT) Date: Sat, 26 Oct 2002 16:20:12 -0700 (PDT) From: Julian Elischer <julian@elischer.org> To: Don Bowman <don@sandvine.com> Cc: "'Kevin Stevens'" <Kevin_Stevens@pursued-with.net>, freebsd-net@FreeBSD.ORG Subject: RE: Annoying ARP warning messages. In-Reply-To: <FE045D4D9F7AED4CBFF1B3B813C8533701022D92@mail.sandvine.com> Message-ID: <Pine.BSF.4.21.0210261615400.13443-100000@InterJet.elischer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org On Sat, 26 Oct 2002, Don Bowman wrote: > Kevin Stevens wrote: > > I have two systems connected through a common network (switch). They > > each have two NICs, with one addressed on one IP network and the second > > on another. IP works fine. My problem is that the kernel keeps > > bitching about seeing the same MAC addresses on both interfaces: well, WHY is it seeing the same MA addresses on both interfaces? Is this your attempt to get more throughput using 2 logical nets through the same switch? I'd fork out the extra $5 for switched cable and connet them together directly and bypass the switch (for teh 2nd link) (probably faster too) > > > > Oct 26 06:15:03 babelfish /kernel: arp: 192.168.168.101 is on em0 but > > got reply from 00:30:65:00:e6:e6 on xl0 > > systcl net.link.ether.inet.log_arp_wrong_iface=0 > > --don (don@sandvine.com www.sandvine.com p2p) > > > 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 Sat Oct 26 17:20:21 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E1A4737B401 for <freebsd-net@FreeBSD.ORG>; Sat, 26 Oct 2002 17:20:19 -0700 (PDT) Received: from mail.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5479E43E42 for <freebsd-net@FreeBSD.ORG>; Sat, 26 Oct 2002 17:20:19 -0700 (PDT) (envelope-from don@sandvine.com) Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19) id <42S9VKST>; Sat, 26 Oct 2002 20:20:18 -0400 Message-ID: <FE045D4D9F7AED4CBFF1B3B813C8533701022D94@mail.sandvine.com> From: Don Bowman <don@sandvine.com> To: "'julian@elischer.org'" <julian@elischer.org> Cc: "'Kevin_Stevens@pursued-with.net'" <Kevin_Stevens@pursued-with.net>, "'freebsd-net@FreeBSD.ORG'" <freebsd-net@FreeBSD.ORG> Subject: Re: Annoying ARP warning messages. Date: Sat, 26 Oct 2002 20:20:11 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org This is common with l2 switched networks: the arp is seen everywhere even though the unicast traffic uses the learning mode. --don -----Original Message----- From: Julian Elischer <julian@elischer.org> To: Don Bowman <don@sandvine.com> CC: 'Kevin Stevens' <Kevin_Stevens@pursued-with.net>; freebsd-net@FreeBSD.ORG <freebsd-net@FreeBSD.ORG> Sent: Sat Oct 26 19:20:12 2002 Subject: RE: Annoying ARP warning messages. On Sat, 26 Oct 2002, Don Bowman wrote: > Kevin Stevens wrote: > > I have two systems connected through a common network (switch). They > > each have two NICs, with one addressed on one IP network and the second > > on another. IP works fine. My problem is that the kernel keeps > > bitching about seeing the same MAC addresses on both interfaces: well, WHY is it seeing the same MA addresses on both interfaces? Is this your attempt to get more throughput using 2 logical nets through the same switch? I'd fork out the extra $5 for switched cable and connet them together directly and bypass the switch (for teh 2nd link) (probably faster too) > > > > Oct 26 06:15:03 babelfish /kernel: arp: 192.168.168.101 is on em0 but > > got reply from 00:30:65:00:e6:e6 on xl0 > > systcl net.link.ether.inet.log_arp_wrong_iface=0 > > --don (don@sandvine.com www.sandvine.com p2p) > > > 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 Sat Oct 26 18:59:20 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 59C5B37B401 for <freebsd-net@FreeBSD.ORG>; Sat, 26 Oct 2002 18:59:19 -0700 (PDT) Received: from pursued-with.net (adsl-66-125-9-242.dsl.sndg02.pacbell.net [66.125.9.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9AF1843E4A for <freebsd-net@FreeBSD.ORG>; Sat, 26 Oct 2002 18:59:18 -0700 (PDT) (envelope-from Kevin_Stevens@pursued-with.net) Received: from pursued-with.net (fffinch [192.168.168.101]) by pursued-with.net (8.12.6/8.12.5) with ESMTP id g9R1wksG001552; Sat, 26 Oct 2002 18:58:46 -0700 (PDT) (envelope-from Kevin_Stevens@pursued-with.net) Date: Sat, 26 Oct 2002 18:58:45 -0700 Subject: Re: Annoying ARP warning messages. Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: freebsd-net@FreeBSD.ORG To: Julian Elischer <julian@elischer.org> From: Kevin Stevens <Kevin_Stevens@pursued-with.net> In-Reply-To: <Pine.BSF.4.21.0210261615400.13443-100000@InterJet.elischer.org> Message-Id: <A06F34F8-E94F-11D6-BF1E-003065715DA8@pursued-with.net> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org On Saturday, Oct 26, 2002, at 16:20 US/Pacific, Julian Elischer wrote: > > On Sat, 26 Oct 2002, Don Bowman wrote: > >> Kevin Stevens wrote: >>> I have two systems connected through a common network (switch). They >>> each have two NICs, with one addressed on one IP network and the >>> second >>> on another. IP works fine. My problem is that the kernel keeps >>> bitching about seeing the same MAC addresses on both interfaces: > > well, WHY is it seeing the same MA addresses on both interfaces? Because they're on the same network, as described above. > Is this your attempt to get more throughput using 2 logical nets > through > the same switch? No. > I'd fork out the extra $5 for switched cable and > connet them together directly and bypass the switch (for teh 2nd link) > (probably faster too) Then you'd be as unsuccessful at meeting my requirements as you've been unresponsive to the question I asked. Fortunately Mr. Bowman promptly gave me the answer below, which is exactly what was needed. KeS >>> >>> Oct 26 06:15:03 babelfish /kernel: arp: 192.168.168.101 is on em0 but >>> got reply from 00:30:65:00:e6:e6 on xl0 >> >> systcl net.link.ether.inet.log_arp_wrong_iface=0 >> >> --don (don@sandvine.com www.sandvine.com p2p) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Oct 26 20:40:15 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2F39037B404 for <freebsd-net@FreeBSD.ORG>; Sat, 26 Oct 2002 20:40:13 -0700 (PDT) Received: from InterJet.elischer.org (12-232-206-8.client.attbi.com [12.232.206.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 704E643E75 for <freebsd-net@FreeBSD.ORG>; Sat, 26 Oct 2002 20:40:12 -0700 (PDT) (envelope-from julian@elischer.org) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id UAA15540; Sat, 26 Oct 2002 20:24:27 -0700 (PDT) Date: Sat, 26 Oct 2002 20:24:26 -0700 (PDT) From: Julian Elischer <julian@elischer.org> To: Kevin Stevens <Kevin_Stevens@pursued-with.net> Cc: freebsd-net@FreeBSD.ORG Subject: Re: Annoying ARP warning messages. In-Reply-To: <A06F34F8-E94F-11D6-BF1E-003065715DA8@pursued-with.net> Message-ID: <Pine.BSF.4.21.0210262019480.13443-100000@InterJet.elischer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org On Sat, 26 Oct 2002, Kevin Stevens wrote: > > On Saturday, Oct 26, 2002, at 16:20 US/Pacific, Julian Elischer wrote: > > > > > On Sat, 26 Oct 2002, Don Bowman wrote: > > > >> Kevin Stevens wrote: > >>> I have two systems connected through a common network (switch). They > >>> each have two NICs, with one addressed on one IP network and the > >>> second > >>> on another. IP works fine. My problem is that the kernel keeps > >>> bitching about seeing the same MAC addresses on both interfaces: > > > > well, WHY is it seeing the same MA addresses on both interfaces? > > Because they're on the same network, as described above. Don't get snooty.. the question is :"why do you want to do that? Is it to get more bandwidth? > > > Is this your attempt to get more throughput using 2 logical nets > > through > > the same switch? > > No. ok, then..... "why?" > > > I'd fork out the extra $5 for switched cable and > > connet them together directly and bypass the switch (for teh 2nd link) > > (probably faster too) > > Then you'd be as unsuccessful at meeting my requirements as you've been > unresponsive to the question I asked. Well since you don;t SAY what your requirements are, I can only try guess.. and as you have now said hta tit is not the only valid reason I can think of, I can;t think of any other reason to do what you are trying to do. > > Fortunately Mr. Bowman promptly gave me the answer below, which is > exactly what was needed. which is fine but I'm stilll puzzled as to why someone would want to do that if it's not to get extra bandwidth. hmm maybe redundancy? but then you'd need an extra switch as well... > > KeS > > >>> > >>> Oct 26 06:15:03 babelfish /kernel: arp: 192.168.168.101 is on em0 but > >>> got reply from 00:30:65:00:e6:e6 on xl0 > >> > >> systcl net.link.ether.inet.log_arp_wrong_iface=0 > >> > >> --don (don@sandvine.com www.sandvine.com p2p) > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Oct 26 21:36:39 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 218CF37B401 for <freebsd-net@FreeBSD.ORG>; Sat, 26 Oct 2002 21:36:38 -0700 (PDT) Received: from mail.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8EABA43E42 for <freebsd-net@FreeBSD.ORG>; Sat, 26 Oct 2002 21:36:37 -0700 (PDT) (envelope-from don@sandvine.com) Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19) id <42S9VKV7>; Sun, 27 Oct 2002 00:36:29 -0400 Message-ID: <FE045D4D9F7AED4CBFF1B3B813C8533701022D95@mail.sandvine.com> From: Don Bowman <don@sandvine.com> To: 'Julian Elischer' <julian@elischer.org>, Kevin Stevens <Kevin_Stevens@pursued-with.net> Cc: freebsd-net@FreeBSD.ORG Subject: RE: Annoying ARP warning messages. Date: Sun, 27 Oct 2002 00:36:19 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org > From: Julian Elischer [mailto:julian@elischer.org] (removed as to why have two NICs on the same network, sending for general enlightenment of the list...) This is reasonably common in L2 switched Ethernet. You have a device which segments the traffic just fine with MAC learning. You have the cables all going to the desktops. You don't want to muck around with partially supported VLAN tagging @ the desktop. So you run another network overtop the same Ethernet. You probably wouldn't architect it up front for that (although I have in our lab, we use a cat6k for a virtual patch panel, but individual tests use whatever IP's they desire). @ the Ethernet level, addressing is only done via MAC address. Having two packets on the same wire with differing IP subnets is legal (in fact, you see it all the time with the destination or source address which is off your network). ARP's and all 1's broadcasts (e.g. DHCP) make a bit of a mess of such a network, but sometimes that's the lesser evil. This can also be seen, believe it or not, on a routed network, if you have something like spanning tree protocol which hasn't converged yet, but has been set for rapid convergence (which assumes the path isn't a loop until it discovers otherwise). Routers and switches are merging. --don (don@sandvine.com www.sandvine.com p2p) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Oct 26 21:45: 3 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A93E537B401 for <freebsd-net@FreeBSD.ORG>; Sat, 26 Oct 2002 21:45:01 -0700 (PDT) Received: from pursued-with.net (adsl-66-125-9-242.dsl.sndg02.pacbell.net [66.125.9.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1313943E4A for <freebsd-net@FreeBSD.ORG>; Sat, 26 Oct 2002 21:45:01 -0700 (PDT) (envelope-from Kevin_Stevens@pursued-with.net) Received: from pursued-with.net (fffinch [192.168.168.101]) by pursued-with.net (8.12.6/8.12.5) with ESMTP id g9R4iSsG001840; Sat, 26 Oct 2002 21:44:28 -0700 (PDT) (envelope-from Kevin_Stevens@pursued-with.net) Date: Sat, 26 Oct 2002 21:44:27 -0700 Subject: Re: Annoying ARP warning messages. Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: freebsd-net@FreeBSD.ORG To: Julian Elischer <julian@elischer.org> From: Kevin Stevens <Kevin_Stevens@pursued-with.net> In-Reply-To: <Pine.BSF.4.21.0210262019480.13443-100000@InterJet.elischer.org> Message-Id: <C61FB703-E966-11D6-BF1E-003065715DA8@pursued-with.net> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org On Saturday, Oct 26, 2002, at 20:24 US/Pacific, Julian Elischer wrote: > Don't get snooty.. > the question is :"why do you want to do that? > Is it to get more bandwidth? The answer is: None of your business. It was a simple technical question, to which I was given a simple technical answer, which made me warm and fuzzy and happy all over. There's no need to answer your irrelevant questions. If you don't think my response is polite and friendly - well, you're the one who challenged the design without knowing the requirements, which is fairly rude to begin with. >>> Is this your attempt to get more throughput using 2 logical nets >>> through >>> the same switch? >> >> No. > ok, then..... "why?" See above. >> >>> I'd fork out the extra $5 for switched cable and >>> connet them together directly and bypass the switch (for teh 2nd >>> link) >>> (probably faster too) >> >> Then you'd be as unsuccessful at meeting my requirements as you've >> been >> unresponsive to the question I asked. > > Well since you don;t SAY what your requirements are, I can only try > guess.. and as you have now said hta tit is not the only valid reason I > can think of, I can;t think of any other reason to do what you are > trying to do. I can think of a lot of reasons to have multiple physical interfaces on the same network. I didn't ask for a critique of the solution design, I asked how to stop the kernel messages. If you knew the answer, why didn't you give it? Since you apparently didn't know the answer, why didn't you simply hold your peace? >> Fortunately Mr. Bowman promptly gave me the answer below, which is >> exactly what was needed. > > which is fine but I'm stilll puzzled as to why someone would want to do > that if it's not to get extra bandwidth. While you're cogitating, you might ask yourself why there actually exists a sysctl switch for that setting. Apparently other people have the need to use it as well. <end thread> KeS To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Oct 26 21:52:13 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 64F7F37B401 for <freebsd-net@FreeBSD.ORG>; Sat, 26 Oct 2002 21:52:12 -0700 (PDT) Received: from pursued-with.net (adsl-66-125-9-242.dsl.sndg02.pacbell.net [66.125.9.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB28643E6A for <freebsd-net@FreeBSD.ORG>; Sat, 26 Oct 2002 21:52:11 -0700 (PDT) (envelope-from Kevin_Stevens@pursued-with.net) Received: from pursued-with.net (fffinch [192.168.168.101]) by pursued-with.net (8.12.6/8.12.5) with ESMTP id g9R4qBsG001853; Sat, 26 Oct 2002 21:52:11 -0700 (PDT) (envelope-from Kevin_Stevens@pursued-with.net) Date: Sat, 26 Oct 2002 21:52:11 -0700 Subject: Re: Annoying ARP warning messages. Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: freebsd-net@FreeBSD.ORG To: Don Bowman <don@sandvine.com> From: Kevin Stevens <Kevin_Stevens@pursued-with.net> In-Reply-To: <FE045D4D9F7AED4CBFF1B3B813C8533701022D95@mail.sandvine.com> Message-Id: <DA8037B8-E967-11D6-BF1E-003065715DA8@pursued-with.net> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org On Saturday, Oct 26, 2002, at 21:36 US/Pacific, Don Bowman wrote: > This can also be seen, believe it or not, on a routed > network, if you have something like spanning tree > protocol which hasn't converged yet, but has been set > for rapid convergence (which assumes the path isn't > a loop until it discovers otherwise). Routers and > switches are merging. > > --don (don@sandvine.com www.sandvine.com p2p) Which is an evil all unto itself - my brain still locks up when Cisco references "layer 3 switching". ;) I've got some interesting scars from a scenario where HSRP on a distribution router set was flapping due to misconfigured spanning tree roots on multiple access switches. KeS To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Oct 26 22: 7:45 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0797437B401 for <net@freebsd.org>; Sat, 26 Oct 2002 22:07:44 -0700 (PDT) Received: from tp.databus.com (p70-227.acedsl.com [66.114.70.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 53A6D43E3B for <net@freebsd.org>; Sat, 26 Oct 2002 22:07:43 -0700 (PDT) (envelope-from barney@tp.databus.com) Received: from tp.databus.com (localhost.databus.com [127.0.0.1]) by tp.databus.com (8.12.6/8.12.6) with ESMTP id g9R57bCA040514 for <net@freebsd.org>; Sun, 27 Oct 2002 01:07:37 -0400 (EDT) (envelope-from barney@tp.databus.com) Received: (from barney@localhost) by tp.databus.com (8.12.6/8.12.6/Submit) id g9R57bpe040513 for net@freebsd.org; Sun, 27 Oct 2002 01:07:37 -0400 (EDT) Date: Sun, 27 Oct 2002 01:07:37 -0400 From: Barney Wolff <barney@tp.databus.com> To: net@freebsd.org Subject: the arp thread Message-ID: <20021027050737.GA40493@tp.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-Scanned-By: MIMEDefang 2.21 (www . roaringpenguin . com / mimedefang) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: <freebsd-net.FreeBSD.ORG> List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions) List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net> List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net> X-Loop: FreeBSD.org Ah, the first entry into my procmail block regex from a freebsd list. All the other s**theads are from nanog. Good luck next time, fella. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message