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