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 ; 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 ; 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 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 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: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: 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 ; 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 ; 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" To: "Don Bowman" , Cc: References: 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: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: 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 ; 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 ; 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: From: Don Bowman To: 'Petri Helenius ' , Don Bowman , "'Kevin_Stevens@pursued-with.net '" Cc: "'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: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: 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 ; 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 ; 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" To: "Petri Helenius" , "Don Bowman" , Cc: Subject: RE: ENOBUFS Date: Sun, 20 Oct 2002 18:34:53 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) 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: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: 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 ; 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 ; 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" To: "Don Bowman" , Cc: References: 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: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: 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 ; 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 ; 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: From: Don Bowman To: 'Petri Helenius ' Cc: "'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: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: 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 ; 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 ; 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" To: "Archie Cobbs" Cc: Subject: RE: MPD PPTP tunneling intermittantly fails Date: Sun, 20 Oct 2002 22:19:46 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) 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: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: 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 ; 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 ; 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?= 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: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: 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 ; 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 ; 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" To: "Don Bowman" Cc: References: 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: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: 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 ; 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 ; 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 To: Lars Eggert Cc: Charles Henrich , 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: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: 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 X-X-Sender: Maxim Konovalov 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: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: 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 ; 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 ; 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: From: Don Bowman To: 'Petri Helenius' Cc: "'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: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: 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 ; 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 ; 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 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 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: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: 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 ; 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 ; 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 Message-Id: <200210212105.g9LL5PjY059864@arch20m.dellroad.org> Subject: Re: MPD PPTP tunneling intermittantly fails In-Reply-To: "from Leonard Chung at Oct 20, 2002 10:19:46 pm" To: Leonard Chung 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: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: 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 ; 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 ; 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 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 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: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: 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 To: freebsd-net@freebsd.org Cc: jlemon@freebsd.org, Harti Brandt 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: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: 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 X-X-Sender: bde@gamplex.bde.org To: Mike Silbersack Cc: freebsd-net@FreeBSD.ORG, , Harti Brandt 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: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: 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 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: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: 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 FreeBSD Project Web Data Bank 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 ; 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 ; 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 ; Tue, 22 Oct 2002 11:34:28 -0300 (ADT) Date: Tue, 22 Oct 2002 11:34:28 -0300 (ADT) From: "Marc G. Fournier" 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: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: 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 ; 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 ; 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 ; Tue, 22 Oct 2002 16:40:42 +0200 (CEST) X-Original-Recipient: 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 ; 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 To: "Marc G. Fournier" 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" , 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: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: 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. -- 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 ; 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 ; 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 X-X-Sender: jepace@tigger.pacehouse.com Reply-To: James Pace To: "Marc G. Fournier" 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: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: 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 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 ; 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 ; 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 To: "Marc G. Fournier" 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: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: 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 ; 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 ; 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 ; Tue, 22 Oct 2002 14:47:36 -0300 (ADT) Date: Tue, 22 Oct 2002 14:47:36 -0300 (ADT) From: "Marc G. Fournier" 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: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: 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 ; 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 ; 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 Organization: Wavefire Technologies Corp. To: "Marc G. Fournier" , 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: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: 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 To: CHOI Junho 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: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: 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 > FreeBSD Project Web Data Bank > 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 ; 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 ; 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 To: "Marc G. Fournier" 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: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org 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 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 ; 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 ; 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" To: Luigi Rizzo 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: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: 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 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 ; 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 ; 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 To: "Marc G. Fournier" 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: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: 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: From: Don Bowman To: "'freebsd-stable@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: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: 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,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: on motherboard npx0: INT 16 interface pcib0: on motherboard IOAPIC #0 intpin 16 -> irq 2 IOAPIC #0 intpin 19 -> irq 10 IOAPIC #0 intpin 18 -> irq 11 pci0: on pcib0 pci0: (vendor=0x8086, dev=0x2541) at 0.1 pcib1: at device 2.0 on pci0 pci1: on pcib1 pci1: (vendor=0x8086, dev=0x1461) at 28.0 pcib2: at device 29.0 on pci1 IOAPIC #2 intpin 0 -> irq 16 IOAPIC #2 intpin 1 -> irq 17 pci2: on pcib2 pci2: (vendor=0x8086, dev=0x1010) at 1.0 irq 16 pci2: (vendor=0x8086, dev=0x1010) at 1.1 irq 17 pci1: (vendor=0x8086, dev=0x1461) at 30.0 pcib3: 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: on pcib3 ahc0: 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: 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: (vendor=0x8086, dev=0x100d) at 4.0 irq 20 uhci0: port 0x2000-0x201f irq 2 at device 29.0 on pci0 usb0: 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: port 0x2020-0x203f irq 10 at device 29.1 on pci0 usb1: 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: port 0x2040-0x205f irq 11 at device 29.2 on pci0 usb2: 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: at device 30.0 on pci0 IOAPIC #0 intpin 17 -> irq 21 pci4: on pcib4 pci4: at 1.0 irq 2 fxp0: 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: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: 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: 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: on ichsmb0 smb0: on smbus0 orm0: