From owner-freebsd-net Sun Jun 16 2:13:54 2002 Delivered-To: freebsd-net@freebsd.org Received: from pipenetworks.com (cartman.pipenetworks.com [202.4.251.18]) by hub.freebsd.org (Postfix) with ESMTP id D6EDA37B407 for ; Sun, 16 Jun 2002 02:13:31 -0700 (PDT) Received: from internal (internal.pipenetworks.com [10.10.10.1]) by pipenetworks.com (8.11.2/8.11.2) with ESMTP id g5G9A9Q10915 for ; Sun, 16 Jun 2002 19:10:10 +1000 Date: Sun, 16 Jun 2002 19:14:14 +1000 (EST) From: To: Subject: Netgraph bridging vlans Message-ID: 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 have been working with Netgrpah in bridging vlans using the vtun package. I recently tried to extend this to bridging vlans but found that it did not work. I think the reason was that the scriptI had been using (/usr/share/examples/netgraph/ether.bridge)to happily do bridging between two real interfaces seemed not to place the vlan interfaces into PROMISC mode. When I start the ether.bridge I do get a message saying promiscuos mode enabled on the vlan1 interface but subsequent "ifconfig" commands do not show the flag set on the interface. Has anybody come across this before ? I am running i386 hardware and 4.5-RELEASE if that helps. Thanks. -- Stephen Baxter Director - PIPE Networks phone : 07 3220 1100/ 0417 818 695 fax : 07 3220 1800 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jun 16 6: 8:47 2002 Delivered-To: freebsd-net@freebsd.org Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id D32C537B412 for ; Sun, 16 Jun 2002 06:08:40 -0700 (PDT) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g5GD8aV22621; Sun, 16 Jun 2002 06:08:36 -0700 (PDT) (envelope-from rizzo) Date: Sun, 16 Jun 2002 06:08:36 -0700 From: Luigi Rizzo To: steve@pipenetworks.com Cc: freebsd-net@FreeBSD.ORG Subject: Re: Netgraph bridging vlans Message-ID: <20020616060836.A22557@iguana.icir.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from steve@pipenetworks.com on Sun, Jun 16, 2002 at 07:14:14PM +1000 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 Sun, Jun 16, 2002 at 07:14:14PM +1000, steve@pipenetworks.com wrote: > > Hello, > > I have been working with Netgrpah in bridging vlans using the vtun > package. I recently tried to extend this to bridging vlans but found that native (not netgraph) bridging in 4.6 works with vlans too. cheers luigi > it did not work. I think the reason was that the scriptI had been using > (/usr/share/examples/netgraph/ether.bridge)to happily do bridging between > two real interfaces seemed not to place the vlan interfaces into PROMISC > mode. > > When I start the ether.bridge I do get a message saying promiscuos mode > enabled on the vlan1 interface but subsequent "ifconfig" commands do not > show the flag set on the interface. > > Has anybody come across this before ? > > I am running i386 hardware and 4.5-RELEASE if that helps. > > Thanks. > > -- > Stephen Baxter > Director - PIPE Networks > phone : 07 3220 1100/ 0417 818 695 > fax : 07 3220 1800 > > > > 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 Jun 16 6:55:51 2002 Delivered-To: freebsd-net@freebsd.org Received: from ns1.interbgc.com (mail.interbgc.com [217.9.224.3]) by hub.freebsd.org (Postfix) with SMTP id D697B37B411 for ; Sun, 16 Jun 2002 06:55:40 -0700 (PDT) Received: (qmail 12805 invoked by uid 1005); 16 Jun 2002 13:55:35 -0000 Received: from misho@interbgc.com by keeper.interbgc.com with qmail-scanner-1.01 (uvscan: v4.0.50/v4206. . Clean. Processed in 0.321259 secs); 16 Jun 2002 13:55:35 -0000 Received: from unknown (HELO misho) (217.9.226.238) by mail.interbgc.com with SMTP; 16 Jun 2002 13:55:35 -0000 Message-ID: <004701c2153d$28068720$eee209d9@interbgc.com> Reply-To: "Mihail Balikov" From: "Mihail Balikov" To: References: <20020616060836.A22557@iguana.icir.org> Subject: Re: Netgraph bridging vlans Date: Sun, 16 Jun 2002 16:53:12 +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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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 have not succeeded to setup vlan bridging even with 4.6. Looking in source code : if_vlan.c : [...] case SIOCSIFFLAGS: /* * We don't support promiscuous mode * right now because it would require help from the * underlying drivers, which hasn't been implemented. */ if (ifr->ifr_flags & (IFF_PROMISC)) { ifp->if_flags &= ~(IFF_PROMISC); error = EINVAL; } break; [...] In if_ethersubr.c ether_demux() it's easy to see that vlan packets with unicast mac addresses different of parent mac would be dropped. for freebsd 4.4 I have wrote small patch to allow promisc mode on vlan interfaces and bridgiing of vlan interfaces. If you are interested I will renew it for 4.6. regards, misho ----- Original Message ----- From: "Luigi Rizzo" To: Cc: Sent: Sunday, June 16, 2002 4:08 PM Subject: Re: Netgraph bridging vlans > On Sun, Jun 16, 2002 at 07:14:14PM +1000, steve@pipenetworks.com wrote: > > > > Hello, > > > > I have been working with Netgrpah in bridging vlans using the vtun > > package. I recently tried to extend this to bridging vlans but found that > > native (not netgraph) bridging in 4.6 works with vlans too. > > cheers > luigi > > > it did not work. I think the reason was that the scriptI had been using > > (/usr/share/examples/netgraph/ether.bridge)to happily do bridging between > > two real interfaces seemed not to place the vlan interfaces into PROMISC > > mode. > > > > When I start the ether.bridge I do get a message saying promiscuos mode > > enabled on the vlan1 interface but subsequent "ifconfig" commands do not > > show the flag set on the interface. > > > > Has anybody come across this before ? > > > > I am running i386 hardware and 4.5-RELEASE if that helps. > > > > Thanks. > > > > -- > > Stephen Baxter > > Director - PIPE Networks > > phone : 07 3220 1100/ 0417 818 695 > > fax : 07 3220 1800 > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-net" in the body of the message > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jun 16 12:50:27 2002 Delivered-To: freebsd-net@freebsd.org Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by hub.freebsd.org (Postfix) with ESMTP id 1DDD137B419 for ; Sun, 16 Jun 2002 12:50:22 -0700 (PDT) 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 g5GJoFM3004651; Sun, 16 Jun 2002 12:50:15 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.3/8.12.3/Submit) id g5GJoEDI004650; Sun, 16 Jun 2002 12:50:14 -0700 Date: Sun, 16 Jun 2002 12:50:14 -0700 From: Brooks Davis To: Mihail Balikov Cc: freebsd-net@FreeBSD.ORG Subject: Re: Netgraph bridging vlans Message-ID: <20020616125014.A3462@Odin.AC.HMC.Edu> References: <20020616060836.A22557@iguana.icir.org> <004701c2153d$28068720$eee209d9@interbgc.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="qDbXVdCdHGoSgWSk" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <004701c2153d$28068720$eee209d9@interbgc.com>; from misho@interbgc.com on Sun, Jun 16, 2002 at 04:53:12PM +0300 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) on odin.ac.hmc.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 --qDbXVdCdHGoSgWSk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jun 16, 2002 at 04:53:12PM +0300, Mihail Balikov wrote: > for freebsd 4.4 I have wrote small patch to allow promisc mode on vlan > interfaces and bridgiing of vlan interfaces. If you are interested I will > renew it for 4.6. If you want to see it included in the system, please create a patch against current. -- 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 --qDbXVdCdHGoSgWSk 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 iD8DBQE9DOv2XY6L6fI4GtQRAlnkAKCShBW9GlQ6kaeCk2MDFGvx5PEvKACffj4U KkNtlXuFjU5ZAfiy0cRzZDs= =TmJT -----END PGP SIGNATURE----- --qDbXVdCdHGoSgWSk-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jun 16 15: 0:42 2002 Delivered-To: freebsd-net@freebsd.org Received: from pipenetworks.com (cartman.pipenetworks.com [202.4.251.18]) by hub.freebsd.org (Postfix) with ESMTP id EF24D37B428 for ; Sun, 16 Jun 2002 15:00:35 -0700 (PDT) Received: from internal (internal.pipenetworks.com [10.10.10.1]) by pipenetworks.com (8.11.2/8.11.2) with ESMTP id g5GLv4Q19620; Mon, 17 Jun 2002 07:57:06 +1000 Date: Mon, 17 Jun 2002 08:01:11 +1000 (EST) From: To: Mihail Balikov Cc: Subject: Re: Netgraph bridging vlans In-Reply-To: <004701c2153d$28068720$eee209d9@interbgc.com> Message-ID: 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 Mihail, > I have not succeeded to setup vlan bridging even with 4.6. Looking in source > code : > if_vlan.c : > [...] > case SIOCSIFFLAGS: > /* > * We don't support promiscuous mode > * right now because it would require help from the > * underlying drivers, which hasn't been implemented. > */ > if (ifr->ifr_flags & (IFF_PROMISC)) { > ifp->if_flags &= ~(IFF_PROMISC); > error = EINVAL; > } > break; > [...] > > In if_ethersubr.c ether_demux() it's easy to see that vlan packets with > unicast mac addresses different of parent mac would be dropped. > > for freebsd 4.4 I have wrote small patch to allow promisc mode on vlan > interfaces and bridgiing of vlan interfaces. If you are interested I will > renew it for 4.6. I am very interested :-) Any chance it would work on 4.5 ? SB > > regards, > misho > > > > > ----- Original Message ----- > From: "Luigi Rizzo" > To: > Cc: > Sent: Sunday, June 16, 2002 4:08 PM > Subject: Re: Netgraph bridging vlans > > > > On Sun, Jun 16, 2002 at 07:14:14PM +1000, steve@pipenetworks.com wrote: > > > > > > Hello, > > > > > > I have been working with Netgrpah in bridging vlans using the vtun > > > package. I recently tried to extend this to bridging vlans but found > that > > > > native (not netgraph) bridging in 4.6 works with vlans too. > > > > cheers > > luigi > > > > > it did not work. I think the reason was that the scriptI had been using > > > (/usr/share/examples/netgraph/ether.bridge)to happily do bridging > between > > > two real interfaces seemed not to place the vlan interfaces into PROMISC > > > mode. > > > > > > When I start the ether.bridge I do get a message saying promiscuos mode > > > enabled on the vlan1 interface but subsequent "ifconfig" commands do not > > > show the flag set on the interface. > > > > > > Has anybody come across this before ? > > > > > > I am running i386 hardware and 4.5-RELEASE if that helps. > > > > > > Thanks. > > > > > > -- > > > Stephen Baxter > > > Director - PIPE Networks > > > phone : 07 3220 1100/ 0417 818 695 > > > fax : 07 3220 1800 > > > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > > with "unsubscribe freebsd-net" in the body of the message > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-net" in the body of the message > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > -- Stephen Baxter Director - PIPE Networks phone : 07 3220 1100/ 0417 818 695 fax : 07 3220 1800 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jun 16 18:20:13 2002 Delivered-To: freebsd-net@freebsd.org Received: from sccrmhc01.attbi.com (sccrmhc01.attbi.com [204.127.202.61]) by hub.freebsd.org (Postfix) with ESMTP id F0C0D37B41F for ; Sun, 16 Jun 2002 18:20:08 -0700 (PDT) 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 <20020617012008.UCBE1024.sccrmhc01.attbi.com@InterJet.elischer.org>; Mon, 17 Jun 2002 01:20:08 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id SAA11813; Sun, 16 Jun 2002 18:00:26 -0700 (PDT) Date: Sun, 16 Jun 2002 18:00:25 -0700 (PDT) From: Julian Elischer To: steve@pipenetworks.com Cc: Mihail Balikov , freebsd-net@FreeBSD.ORG Subject: Re: Netgraph bridging vlans In-Reply-To: Message-ID: 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 Mon, 17 Jun 2002 steve@pipenetworks.com wrote: > > Mihail, > > > > > In if_ethersubr.c ether_demux() it's easy to see that vlan packets with > > unicast mac addresses different of parent mac would be dropped. > > > > for freebsd 4.4 I have wrote small patch to allow promisc mode on vlan > > interfaces and bridgiing of vlan interfaces. If you are interested I will > > renew it for 4.6. > > I am very interested :-) Any chance it would work on 4.5 ? Yes, if it seems clean I will commit it, but let us see it first :-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jun 17 9:57:45 2002 Delivered-To: freebsd-net@freebsd.org Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id E8A1737B40C; Mon, 17 Jun 2002 09:57:02 -0700 (PDT) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g5HGv2X36243; Mon, 17 Jun 2002 09:57:02 -0700 (PDT) (envelope-from rizzo) Date: Mon, 17 Jun 2002 09:57:02 -0700 From: "'Luigi Rizzo'" To: ipfw@FreeBSD.ORG Subject: third ipfw snapshot available Message-ID: <20020617095702.C36073@iguana.icir.org> References: <20020613171319.D93980@iguana.icir.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: <20020613171319.D93980@iguana.icir.org>; from rizzo@icir.org on Thu, Jun 13, 2002 at 05:13:19PM -0700 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 [Bcc to -net] A third snapshot of my rewrite of the ipfw code is available at http://info.iet.unipi.it/~luigi/ipfw5.20020617.tgz This code is for -current, and it implements all the existing ipfw features with the exception of ipprecedence, iptos and icmptypes (these will be added in the next snapshot). It also lets you put "not" and "or" connectives in front of almost any field of an ipfw rule, so you can likely write more compact and efficient rulesets. Being the work almost complete, I should be able to run performance tests and produce a -stable version of this code shortly. I would be grateful if you could give this code a try and tell me how it works for you on the rulesets you use (it is supposed to be 100% compatible with the existing ipfw). You need to have a version of -current after May 15th, replace sys/netinet/ip_fw.c sys/netinet/ip_fw.h sys/netinet/ip_dummynet.c sbin/ipfw/ipfw.c with the files in the archive, rebuild a kernel and /sbin/ipfw. Both success and failure reports are welcome. cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jun 17 16: 8:14 2002 Delivered-To: freebsd-net@freebsd.org Received: from crufty.research.bell-labs.com (ns2.research.bell-labs.com [204.178.16.49]) by hub.freebsd.org (Postfix) with ESMTP id A800137B40E for ; Mon, 17 Jun 2002 16:08:07 -0700 (PDT) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by crufty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g5HN86CT054766 for ; Mon, 17 Jun 2002 19:08:06 -0400 (EDT) Received: from aura.research.bell-labs.com (aura.research.bell-labs.com [135.104.46.10]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g5HN80o02560 for ; Mon, 17 Jun 2002 19:08:00 -0400 (EDT) Received: from aura.research.bell-labs.com (localhost [127.0.0.1]) by aura.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g5HN7x9m009504 for ; Mon, 17 Jun 2002 19:07:59 -0400 (EDT) Received: from localhost (gopi@localhost) by aura.research.bell-labs.com (8.12.2/8.12.2/Submit) with ESMTP id g5HN7xaY009501 for ; Mon, 17 Jun 2002 19:07:59 -0400 (EDT) X-Authentication-Warning: aura.research.bell-labs.com: gopi owned process doing -bs Date: Mon, 17 Jun 2002 19:07:59 -0400 (EDT) From: Gopinath KN To: Subject: ti0 Gigabit driver Message-ID: 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 All, I am noticing that a FreeBSD router is dropping many packets in the ip_output() routine (when called from ip_forward()). It was confirmed by "packets not forwardable/packets dropped due to lack of mbufs etc." messages of "netstat -s -p ip". The correponding output interface is the Netgear Gigabit (ti0). The giagbit driver sets the interface queue (if_snd of the ifnet structure) to a value which is 512 (The TX ring count of the NIC). This queue is where the packets are being dropped from. Can I increase this value to a larger number (say, 1024)? I am not sure what side-effect this is going to have as this might involve playing with some device memory. Does the NIC hardware/software assume that this value should not be beyond the maximum TX ring size (512) as indicated in one of the headers? Otherwise, can you suggest anyways of reducing/eliminating these drops - the CPU is not saturated - it is atleast 20% idle. Thanks, Gopi PS: Kindly CC replies to me. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jun 17 17: 5:32 2002 Delivered-To: freebsd-net@freebsd.org Received: from loquat.bbn.com (crodrigues.bbn.com [128.89.72.49]) by hub.freebsd.org (Postfix) with ESMTP id C3B0637B40D for ; Mon, 17 Jun 2002 17:05:28 -0700 (PDT) Received: (from crodrigu@localhost) by loquat.bbn.com (8.11.2/8.11.2) id g5I05SA03407 for freebsd-net@freebsd.org; Mon, 17 Jun 2002 20:05:28 -0400 Date: Mon, 17 Jun 2002 20:05:28 -0400 From: Craig Rodrigues To: freebsd-net@freebsd.org Subject: Retrieving SONET alarms with FreeBSD? Message-ID: <20020617200528.A898@bbn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i 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 am trying to learn about network management systems (NMS) and SONET. I was wondering, are any device drivers available for FreeBSD which can propagate SONET alarms from the network element device level to a user-level ioctl() or system call? Under Linux, some of the linux-atm drivers implement a proprietary ioctl() calls SONET_GETDIAG which can be used to get some SONET alarm information. Is there anything equivalent (or better :) available from FreeBSD? I couldn't find anything by grepping the FreeBSD 4.6 source code. Since I am learning about this stuff on my machine at home, which does not connect to any real SONET equipment, I would be interested in writing a device driver which could at least simulate the SONET alarm information, so that I can experiment with writing a home grown NMS. :) Thanks. -- Craig Rodrigues Distributed Systems and Logistics, Office 6/304 crodrigu@bbn.com BBN Technologies, a Verizon company (617) 873-4725 Cambridge, MA To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jun 17 17:24:33 2002 Delivered-To: freebsd-net@freebsd.org Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by hub.freebsd.org (Postfix) with ESMTP id 278C437B412; Mon, 17 Jun 2002 17:24:29 -0700 (PDT) Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by crufty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g5I0OPCT055406; Mon, 17 Jun 2002 20:24:28 -0400 (EDT) Received: from aura.research.bell-labs.com (aura.research.bell-labs.com [135.104.46.10]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g5I0OJk20343; Mon, 17 Jun 2002 20:24:19 -0400 (EDT) Received: from aura.research.bell-labs.com (localhost [127.0.0.1]) by aura.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g5I0OJ9m012213; Mon, 17 Jun 2002 20:24:19 -0400 (EDT) Received: from localhost (gopi@localhost) by aura.research.bell-labs.com (8.12.2/8.12.2/Submit) with ESMTP id g5I0OJfL012210; Mon, 17 Jun 2002 20:24:19 -0400 (EDT) X-Authentication-Warning: aura.research.bell-labs.com: gopi owned process doing -bs Date: Mon, 17 Jun 2002 20:24:19 -0400 (EDT) From: Gopinath KN To: Jeffrey Hsu Cc: Subject: Re: ti0 Gigabit driver In-Reply-To: <0GXV0013AI9ZDU@mta5.snfc21.pbi.net> Message-ID: 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 Sorry that I forgot to metion that "netstat -m" shows lot of mbufs and clusters are there in the system - I had bumped up the value. It basically seems to be a "ti0 Queue Drop" problem. Thanks, Gopi On Mon, 17 Jun 2002, Jeffrey Hsu wrote: > What does netstat -m say? > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jun 17 20:34:21 2002 Delivered-To: freebsd-net@freebsd.org Received: from jester.ti.com (jester.ti.com [192.94.94.1]) by hub.freebsd.org (Postfix) with ESMTP id 228CE37B41F; Mon, 17 Jun 2002 20:34:13 -0700 (PDT) Received: from dlep8.itg.ti.com ([157.170.134.88]) by jester.ti.com (8.11.6/8.11.6) with ESMTP id g5I3YBK12187; Mon, 17 Jun 2002 22:34:12 -0500 (CDT) Received: from dlep8.itg.ti.com (localhost [127.0.0.1]) by dlep8.itg.ti.com (8.9.3/8.9.3) with ESMTP id WAA23975; Mon, 17 Jun 2002 22:34:11 -0500 (CDT) Received: from popsvr.india.ti.com (popsvr.india.ti.com [157.87.95.215]) by dlep8.itg.ti.com (8.9.3/8.9.3) with ESMTP id WAA23949; Mon, 17 Jun 2002 22:34:08 -0500 (CDT) Received: from gautham ([192.168.185.126]) by popsvr.india.ti.com (8.8.8/8.8.8) with SMTP id JAA01395; Tue, 18 Jun 2002 09:03:58 +0530 (IST) Reply-To: From: "Gautham Ganapathy" To: "Terry Lambert" Cc: "FreeBSD.org - Hackers" , "FreeBSD. org - Net" Subject: RE: Inserting a kernel module b/w IP and ethernet (Moving to net-) Date: Tue, 18 Jun 2002 09:05:10 +0530 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.2910.0) In-Reply-To: <3D0DF45F.C616C7CA@mindspring.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 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 On Monday, June 17, 2002 8:08 PM, Terry Lambert wrote: > > Gautham Ganapathy wrote: > > How can I add an extra layer of processing b/w the IP and > ethernet layers > > using a kernel module ? If I load a module, I should be able to > access the > > functions exported by IP and ethernet. Also, I think the > ethernet layer can > > be configured to use my module as the protocol by patching > ifconfig. Am I > > right so far ? So, how do I get IP to use my module as it's > link layer ? If > > I am wrong, what's the proper way ? Or is there any other > simpler way ? My > > requirement is to add a compression layer (RFC 2507) > > Questions like this should probably be sent to -net, rather than > -hackers. You will probably find a better answer than mine, just > by searching the -net list archives at www.freebsd.org. > ok. will do > The RFC specifically references a NetBSD implementation for PPP; is > this for PPP? If it's for PPP, then mpd may have already implemented > what you need as a netgraph node. One thing you aren't going to be > able to do is BPF on input after netgraph catches the data. > it is not for ppp. this will currently be used on a LAN. it is used for reducing header bandwidth on wireless transmission systems. the ip packets generated after compression are not compatible with standard ipv4 packets and probably cannot be used on the same network. as in tcp/ip, there is no dependency on an underlying protocol. i'll check if the netbsd ppp will be of use. > Don't bother with a protocol family, unless you want to have to > implement everything; TCP in tcp_output() calls ip_output() > directly, so you will not be able to wedge it in there (TCP and IP > are not implemented as stackable protocol layers seperate and > distinct from each other). I can point you at code that does > this, but it requires changing your application in order to > make it open sockets with the new family instead of AF_INET; if > you ar adamant, the code is at Rice University, as part of the > Scala Server Project. i won't need to embed it between tcp and ip. it would have to be between ip and ethernet. > My particular choice for an example would be /sys/netgraph/ng_pppoe.c > but others might point you to something else. Julian or Archie are > always the best people to ask (obviously). > > You could also create an interface (see /sys/netgraph/ng_iface.c) > that pretended to be a plain old interface, and did the > encapsulation/deincapsulation, and sent to the regular interface. > this sounds good, but i think i have a lot of code to go through since i have just started studying the kernel. > The basics are going to be that you replace the mbuf with your > modified mbuf, rather than eating it outright, if you want the > input/output processing to proceed normally on the (de)compressed > packet. > > I don't know if there is a ng_null that anyone has written; it > would *really* be the best starting point. > thanx a lot To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jun 17 20:55:56 2002 Delivered-To: freebsd-net@freebsd.org Received: from wall.polstra.com (wall-gw.polstra.com [206.213.73.130]) by hub.freebsd.org (Postfix) with ESMTP id 93ED237B403 for ; Mon, 17 Jun 2002 20:55:50 -0700 (PDT) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.11.3/8.11.3) with ESMTP id g5I3sTf75246; Mon, 17 Jun 2002 20:54:29 -0700 (PDT) (envelope-from jdp@wall.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.11.6/8.11.0) id g5I3sQO19132; Mon, 17 Jun 2002 20:54:26 -0700 (PDT) (envelope-from jdp) Date: Mon, 17 Jun 2002 20:54:26 -0700 (PDT) Message-Id: <200206180354.g5I3sQO19132@vashon.polstra.com> To: net@freebsd.org From: John Polstra Cc: spe@selectbourse.net Subject: Re: Problem using ng_ether In-Reply-To: <001f01c21493$b0612620$010110ac@SPEWIN> References: <001f01c21493$b0612620$010110ac@SPEWIN> Organization: Polstra & Co., Seattle, WA 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 article <001f01c21493$b0612620$010110ac@SPEWIN>, Sebastien Petit wrote: > Apparently, my kernel contains the fix already: > [spe@artik /usr/src/sys/netgraph]$ grep "if_hwassist" ng_ether.c > priv->hwassist = ifp->if_hwassist; > priv->ifp->if_hwassist = 0; > priv->ifp->if_hwassist = priv->hwassist; /* restore h/w > csum */ > > So, Why I've problem with checksums ? I don't know. Are you sure your running kernel was actually built from those sources? Beyond that, my only advice at this point is for you to dig into it with kgdb. John -- John Polstra John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jun 17 23:28:23 2002 Delivered-To: freebsd-net@freebsd.org Received: from ns1.interbgc.com (mail.interbgc.com [217.9.224.3]) by hub.freebsd.org (Postfix) with SMTP id 8A57937B417 for ; Mon, 17 Jun 2002 23:28:08 -0700 (PDT) Received: (qmail 36517 invoked by uid 1005); 18 Jun 2002 06:28:02 -0000 Received: from misho@interbgc.com by keeper.interbgc.com with qmail-scanner-1.01 (uvscan: v4.0.50/v4207. . Clean. Processed in 1.02965 secs); 18 Jun 2002 06:28:02 -0000 Received: from unknown (HELO misho) (217.9.226.238) by mail.interbgc.com with SMTP; 18 Jun 2002 06:28:01 -0000 Message-ID: <002d01c21690$f417d720$eee209d9@interbgc.com> Reply-To: "Mihail Balikov" From: "Mihail Balikov" To: "Luigi Rizzo" Cc: References: <20020616060836.A22557@iguana.icir.org> Subject: Re: Netgraph bridging vlans Date: Tue, 18 Jun 2002 09:25:34 +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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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 http://gosho.interbgc.com/vlan_bridge.diff ----- Original Message ----- From: "Luigi Rizzo" To: Cc: Sent: Sunday, June 16, 2002 4:08 PM Subject: Re: Netgraph bridging vlans > On Sun, Jun 16, 2002 at 07:14:14PM +1000, steve@pipenetworks.com wrote: > > > > Hello, > > > > I have been working with Netgrpah in bridging vlans using the vtun > > package. I recently tried to extend this to bridging vlans but found that > > native (not netgraph) bridging in 4.6 works with vlans too. > > cheers > luigi > > > it did not work. I think the reason was that the scriptI had been using > > (/usr/share/examples/netgraph/ether.bridge)to happily do bridging between > > two real interfaces seemed not to place the vlan interfaces into PROMISC > > mode. > > > > When I start the ether.bridge I do get a message saying promiscuos mode > > enabled on the vlan1 interface but subsequent "ifconfig" commands do not > > show the flag set on the interface. > > > > Has anybody come across this before ? > > > > I am running i386 hardware and 4.5-RELEASE if that helps. > > > > Thanks. > > > > -- > > Stephen Baxter > > Director - PIPE Networks > > phone : 07 3220 1100/ 0417 818 695 > > fax : 07 3220 1800 > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-net" in the body of the message > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 18 3:29:21 2002 Delivered-To: freebsd-net@freebsd.org Received: from mails.tsinghua.edu.cn (mails.tsinghua.edu.cn [166.111.8.16]) by hub.freebsd.org (Postfix) with ESMTP id DAA3237B40D for ; Tue, 18 Jun 2002 03:29:12 -0700 (PDT) Received: (eyou send program); Tue, 18 Jun 2002 18:27:39 +0800 Received: from 202.112.0.70 by mails.tsinghua.edu.cn with HTTP; Tue, 18 Jun 2002 18:27:39 +0800 X-WebMAIL-MUA: [202.112.0.70] From: "ef90b7323131bdf05e" To: freebsd-net@freebsd.org Date: Tue, 18 Jun 2002 18:27:39 +0800 Reply-To: "ef90b7323131bdf05e" Subject: How cwnd is set after a loss in FreeBSD TCP? Content-Type: text/plain Message-Id: <20020618102912.DAA3237B40D@hub.freebsd.org> 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 use freebsd 4.5, and find a really unexplainable behavior of TCP. If there is no loss, TCP grows its cwnd and finally reaches the maximum window size advertised by the receiver, for example 12 packets, after a while a packet is lost. When the loss is recovered, TCP will begin its another windows increase cycle. As I thought, TCP should enter congestion avoidance when its cwnd reaches 7 (7=12/2+1). However, I found that TCP may still in slow start even when the cwnd is 8 or even greater. And it seems that the longer TCP stays in rcv_wnd before the loss, the larger beginning cwnd of AI is. For example: 31680 is the max rcv_wnd <- 139.817066 . 5385601:5387040(1440) ack 1 win 65535 owin 31680 then detect a loss... then slow start... until <- 143.046655 . 5444641:5446080(1440) ack 1 win 65535 owin 24480 TCP enters congestion avoidance, where 24480 >> 31680/2 = 15840 My explanation to this is that the ssthresh is not exactly half of the cwnd after detecting the loss. However, the explanation seems contradicts with RFC2581, which say ssthresh must be no more than max( FlightSize /2, 2*SMSS). The behavior puzzled me for a while. Is it a bug or just the right behavior? Can anyone help to explain it? I have dump file the the figure of this behavior, if anyone want, I will email it. ************************************** Lu Guohan Department of Electronical Engineering Tsinghua University, P.R. China lguohan00@mails.tsinghua.edu.cn ************************************** To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 18 5:33:20 2002 Delivered-To: freebsd-net@freebsd.org Received: from sbserv0.intra.selectbourse.net (APuteaux-107-2-1-3.abo.wanadoo.fr [217.128.228.3]) by hub.freebsd.org (Postfix) with ESMTP id 9E54837B400 for ; Tue, 18 Jun 2002 05:33:13 -0700 (PDT) Received: from there (artik.intra.selectbourse.net [172.16.2.3]) by sbserv0.intra.selectbourse.net (Postfix) with SMTP id 9A20EBA19; Tue, 18 Jun 2002 14:29:20 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" From: Sebastien Petit To: John Polstra Subject: Re: Problem using ng_ether Date: Tue, 18 Jun 2002 14:38:10 +0200 X-Mailer: KMail [version 1.3.2] References: <001f01c21493$b0612620$010110ac@SPEWIN> <200206180354.g5I3sQO19132@vashon.polstra.com> In-Reply-To: <200206180354.g5I3sQO19132@vashon.polstra.com> Cc: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20020618122920.9A20EBA19@sbserv0.intra.selectbourse.net> 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 Tuesday 18 June 2002 05:54, you wrote: > In article <001f01c21493$b0612620$010110ac@SPEWIN>, > > Sebastien Petit wrote: > > Apparently, my kernel contains the fix already: > > [spe@artik /usr/src/sys/netgraph]$ grep "if_hwassist" ng_ether.c > > priv->hwassist = ifp->if_hwassist; > > priv->ifp->if_hwassist = 0; > > priv->ifp->if_hwassist = priv->hwassist; /* restore h/w > > csum */ > > > > So, Why I've problem with checksums ? > > I don't know. Are you sure your running kernel was actually built > from those sources? Ok, I think that I've found the problem, this patch was not applied in RELENG_4_5 branch and is just available on RELENG_4 (so FreeBSD-4.6) Effectlivly, my running kernel was not actually built from those sources. So now all is working fine, thank you for your help John. I've two other questions: * Why this patch was not applied on 4.5-STABLE branch ? * How can I distribute my software working with ng_ether without forcing the user to upgrade his kernel to FreeBSD-4.6 that is not released for the moment ? Regards, Sebastien -- spe@selectbourse.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 18 6:40: 7 2002 Delivered-To: freebsd-net@freebsd.org Received: from proton.hexanet.fr (proton.hexanet.fr [81.23.32.33]) by hub.freebsd.org (Postfix) with ESMTP id EE04B37B408 for ; Tue, 18 Jun 2002 06:39:58 -0700 (PDT) Received: from hexanet.fr (localhost [127.0.0.1]) by proton.hexanet.fr (8.12.3/8.12.3) with SMTP id g5IDdufS003940 for ; Tue, 18 Jun 2002 15:39:56 +0200 (CEST) (envelope-from c.prevotaux@hexanet.fr) Date: Tue, 18 Jun 2002 15:39:56 +0200 From: Christophe Prevotaux To: net@freebsd.org Subject: IPIP (kind of) with Payload Encryption only Message-Id: <20020618153956.2a9352fa.c.prevotaux@hexanet.fr> Organization: HEXANET Sarl X-Mailer: Sylpheed version 0.7.4 (GTK+ 1.2.10; i386-portbld-freebsd4.4) X-NCC-RegID: fr.hexanet 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, Could someone tell me if there is a way to build a VPN(like) tunnel from a FreeBSD machine acting as a VPN gateway to another machine acting as another VPN gateway using normal IP packets that have only their data payload encrypted. Of course there would have to be a way to setup the tunnel and still retain the network addressing of each side of the VPN I thought about some kind of IPIP tunneling but with data payload encryption and some kind of key exchange for authentication has anyone made or seen such a system yet ? I do not want to use (I can't) AH and ESP for this because of some technical contraints +-------------+ +---------+ | VPN gateway |---| Router |--------+ --Network A===|==FreeBSD====|===|=========|== | +-------------+ +---------+ || | VPN Internet || | +-------------+ +---------+ || | --Network B===|=VPN gateway=|===|=Router==|== | | FreeBSD |---| |--------+ +-------------+ +---------+ -- =============================================================== Christophe Prevotaux Email: c.prevotaux@hexanet.fr HEXANET SARL URL: http://www.hexanet.fr/ Z.A.C Les Charmilles Tel: +33 (0)3 26 79 30 05 3 Allée Thierry Sabine Direct: +33 (0)3 26 61 77 72 BP202 Fax: +33 (0)3 26 79 30 06 51686 Reims Cedex 2 FRANCE HEXANET Network Operation Center =============================================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 18 6:52:55 2002 Delivered-To: freebsd-net@freebsd.org Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (Postfix) with ESMTP id E1CEE37B407 for ; Tue, 18 Jun 2002 06:52:52 -0700 (PDT) Received: from whizzo.transsys.com (#6@localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.12.3/8.12.3) with ESMTP id g5IDqqnq047326; Tue, 18 Jun 2002 09:52:52 -0400 (EDT) (envelope-from louie@whizzo.transsys.com) Message-Id: <200206181352.g5IDqqnq047326@whizzo.transsys.com> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Christophe Prevotaux Cc: net@FreeBSD.ORG X-Image-URL: http://www.transsys.com/louie/images/louie-mail.jpg From: "Louis A. Mamakos" Subject: Re: IPIP (kind of) with Payload Encryption only References: <20020618153956.2a9352fa.c.prevotaux@hexanet.fr> In-reply-to: Your message of "Tue, 18 Jun 2002 15:39:56 +0200." <20020618153956.2a9352fa.c.prevotaux@hexanet.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Tue, 18 Jun 2002 09:52:52 -0400 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, > = > Could someone tell me if there is a way to build a VPN(like) tunnel fro= m > a FreeBSD machine acting as a VPN gateway to another machine acting as > another VPN gateway using normal IP packets that have only their data > payload encrypted. Of course there would have to be a way to setup the > tunnel and still retain the network addressing of each side of the VPN Look at vtun in /usr/ports/net/vtun to see if this can address your problem. I use it over a (cable modem) network that seems to = filter IPSEC traffic. louie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 18 7:29:20 2002 Delivered-To: freebsd-net@freebsd.org Received: from wall.polstra.com (wall-gw.polstra.com [206.213.73.130]) by hub.freebsd.org (Postfix) with ESMTP id 4EBF237B404 for ; Tue, 18 Jun 2002 07:29:15 -0700 (PDT) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.11.3/8.11.3) with ESMTP id g5IETCf79216; Tue, 18 Jun 2002 07:29:12 -0700 (PDT) (envelope-from jdp@wall.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.11.6/8.11.0) id g5IETBk19887; Tue, 18 Jun 2002 07:29:11 -0700 (PDT) (envelope-from jdp) Date: Tue, 18 Jun 2002 07:29:11 -0700 (PDT) Message-Id: <200206181429.g5IETBk19887@vashon.polstra.com> To: net@freebsd.org From: John Polstra Cc: spe@selectbourse.net Subject: Re: Problem using ng_ether In-Reply-To: <20020618122920.9A20EBA19@sbserv0.intra.selectbourse.net> References: <001f01c21493$b0612620$010110ac@SPEWIN> <200206180354.g5I3sQO19132@vashon.polstra.com> <20020618122920.9A20EBA19@sbserv0.intra.selectbourse.net> Organization: Polstra & Co., Seattle, WA 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 article <20020618122920.9A20EBA19@sbserv0.intra.selectbourse.net>, Sebastien Petit wrote: > Ok, I think that I've found the problem, this patch was not applied in > RELENG_4_5 branch and is just available on RELENG_4 (so FreeBSD-4.6) > Effectlivly, my running kernel was not actually built from those sources. So > now all is working fine, thank you for your help John. Thanks for the follow-up. I'm glad to hear that the fix actually works. :-) > I've two other questions: > * Why this patch was not applied on 4.5-STABLE branch ? RELENG_4_5 is a security branch. Nothing is added to it except important security-related fixes. Ordinary bug fixes are not added to that branch. If you want bug fixes too, you should use RELENG_4. > * How can I distribute my software working with ng_ether without forcing the > user to upgrade his kernel to FreeBSD-4.6 that is not released for the moment > ? It is released now. But here's another option for you. Along with your software, distribute the fixed version of the ng_ether kernel loadable module (ng_ether.ko). Tell your users not to configure NETGRAPH_ETHER into their kernels. Instead, they should load the module. That should solve the problem for them. I think the fixed module should work fine with a 4.5 kernel. John -- John Polstra John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 18 8: 0:39 2002 Delivered-To: freebsd-net@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id 28FEB37B42B for ; Tue, 18 Jun 2002 08:00:15 -0700 (PDT) Received: from isi.edu (c1-vpn3.isi.edu [128.9.176.29]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g5IF0Ar15685; Tue, 18 Jun 2002 08:00:10 -0700 (PDT) Message-ID: <3D0F4AFA.3000908@isi.edu> Date: Tue, 18 Jun 2002 08:00:10 -0700 From: Lars Eggert Organization: USC Information Sciences Institute User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1a) Gecko/20020611 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Louis A. Mamakos" Cc: Christophe Prevotaux , net@FreeBSD.ORG Subject: Re: IPIP (kind of) with Payload Encryption only References: <20020618153956.2a9352fa.c.prevotaux@hexanet.fr> <200206181352.g5IDqqnq047326@whizzo.transsys.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010400090708090504080309" 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 This is a cryptographically signed message in MIME format. --------------ms010400090708090504080309 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Louis A. Mamakos wrote: >> >>Could someone tell me if there is a way to build a VPN(like) tunnel from >>a FreeBSD machine acting as a VPN gateway to another machine acting as >>another VPN gateway using normal IP packets that have only their data >>payload encrypted. Of course there would have to be a way to setup the >>tunnel and still retain the network addressing of each side of the VPN > > > Look at vtun in /usr/ports/net/vtun to see if this can address your > problem. I use it over a (cable modem) network that seems to > filter IPSEC traffic. Too bad you can't use IPsec, this seems like the perfect scenario for it. I've also used vtun in such a scenario, and can second that it'll work UNLESS you need your tunnel to go through a NAT box - vtun uses the client's IP address during its authentication handshake (which is dumb, since stronger shared secrets need be in place anyway.) Archie's daemonnews article has an example of how to do UDP tunneling with netgraph, which nets about a 2x performance improvement over vtun (without encryption, haven't figured out how tie in ng_mppc). Lars -- Lars Eggert USC Information Sciences Institute --------------ms010400090708090504080309 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIrjCC ArUwggIeoAMCAQICAwWBRzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAxMDgyNDE2NDAwMFoXDTAyMDgyNDE2NDAwMFowVDEP MA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2VydDEc MBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEA0AvLBsD78nxcUHeHkaMgl3b4qYPnfgbf8Lh+HQP8RgGMRG/Yb+vTpkGezlwt9pkJxiD1 1uZDy4CNNJUu3gKxKSb+zRV70O+lkwwftuHoLHoH4xwo3LcQ2LGDpd+I95tUN4dfJ3TmeEcU SF50dC/SuUI4w8AlhXQ8IxrhgdayTpECAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIB BAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1Ud EwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAheZhn0pQA8zI7U2K1ZIAl11j0a1DKxnp3GtT vOUrGRB3WvYxidvdZ1kizhEsWeXU81TkNDH0DaRqtOEeu6Q2OhB+jeKEqY7IDAJE4/fI0e+d 6PnG1hd+vEvYmsKHkmzBhPc94XUOKNWO+qVNP2NGyNI3QIDy5wX4fdcOo1S34r4wggK1MIIC HqADAgECAgMFgUcwDQYJKoZIhvcNAQECBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYD VQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg UlNBIDIwMDAuOC4zMDAeFw0wMTA4MjQxNjQwMDBaFw0wMjA4MjQxNjQwMDBaMFQxDzANBgNV BAQTBkVnZ2VydDENMAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkq hkiG9w0BCQEWDWxhcnNlQGlzaS5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANAL ywbA+/J8XFB3h5GjIJd2+KmD534G3/C4fh0D/EYBjERv2G/r06ZBns5cLfaZCcYg9dbmQ8uA jTSVLt4CsSkm/s0Ve9DvpZMMH7bh6Cx6B+McKNy3ENixg6XfiPebVDeHXyd05nhHFEhedHQv 0rlCOMPAJYV0PCMa4YHWsk6RAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy dU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBAgUAA4GBAIXmYZ9KUAPMyO1NitWSAJddY9GtQysZ6dxrU7zlKxkQ d1r2MYnb3WdZIs4RLFnl1PNU5DQx9A2karThHrukNjoQfo3ihKmOyAwCROP3yNHvnej5xtYX frxL2JrCh5JswYT3PeF1DijVjvqlTT9jRsjSN0CA8ucF+H3XDqNUt+K+MIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYICpjCCAqICAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDBYFHMAkGBSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAyMDYxODE1MDAxMFowIwYJKoZIhvcNAQkEMRYEFF7z94vU7yRw 8iap7DQnmKC2qvs/MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0B CRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG A1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRl IFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMF gUcwDQYJKoZIhvcNAQEBBQAEgYBDVdW8XIT1dV0Tu/oVfuUmXKGq1soFBRJXFN2AvRU/8mtu QLTgiqefj0OlRzCDerGR7Pm3nyFPlT+F4nN8H0m1mXb0ukz35HWWlDV0dLtYGefD6fgQNe+r hpeYBjJ4vcucChFJ1Gk2OaV2TUwltBUsAH6fh30aE+fBL6fsktfKtAAAAAAAAA== --------------ms010400090708090504080309-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 18 8: 6:49 2002 Delivered-To: freebsd-net@freebsd.org Received: from proton.hexanet.fr (proton.hexanet.fr [81.23.32.33]) by hub.freebsd.org (Postfix) with ESMTP id 814D937B40C for ; Tue, 18 Jun 2002 08:06:41 -0700 (PDT) Received: from hexanet.fr (localhost [127.0.0.1]) by proton.hexanet.fr (8.12.3/8.12.3) with SMTP id g5IF6dfS004253; Tue, 18 Jun 2002 17:06:39 +0200 (CEST) (envelope-from c.prevotaux@hexanet.fr) Date: Tue, 18 Jun 2002 17:06:39 +0200 From: Christophe Prevotaux To: Lars Eggert Cc: net@freebsd.org Subject: Re: IPIP (kind of) with Payload Encryption only Message-Id: <20020618170639.3754910d.c.prevotaux@hexanet.fr> In-Reply-To: <3D0F4AFA.3000908@isi.edu> References: <20020618153956.2a9352fa.c.prevotaux@hexanet.fr> <200206181352.g5IDqqnq047326@whizzo.transsys.com> <3D0F4AFA.3000908@isi.edu> Organization: HEXANET Sarl X-Mailer: Sylpheed version 0.7.4 (GTK+ 1.2.10; i386-portbld-freebsd4.4) X-NCC-RegID: fr.hexanet 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 I can use AH/ESP however since I am using a satellite link thru a modem/hub(NOC) that fiddles around with packets in order to optimize them , I can't encrypt the headers otherwise the optimizer can't see inside the packets and therefore can't see the headers , so no optimization is done ,and I end up with a 33,6Kbps like speed for the VPN , which is useless (at best 56Kbps). SKIP seems like a goes solution, I am going to look at it and see what it does. On Tue, 18 Jun 2002 08:00:10 -0700 Lars Eggert wrote: > Louis A. Mamakos wrote: > >> > >>Could someone tell me if there is a way to build a VPN(like) tunnel from > >>a FreeBSD machine acting as a VPN gateway to another machine acting as > >>another VPN gateway using normal IP packets that have only their data > >>payload encrypted. Of course there would have to be a way to setup the > >>tunnel and still retain the network addressing of each side of the VPN > > > > > > Look at vtun in /usr/ports/net/vtun to see if this can address your > > problem. I use it over a (cable modem) network that seems to > > filter IPSEC traffic. > > Too bad you can't use IPsec, this seems like the perfect scenario for it. > > I've also used vtun in such a scenario, and can second that it'll work > UNLESS you need your tunnel to go through a NAT box - vtun uses the > client's IP address during its authentication handshake (which is dumb, > since stronger shared secrets need be in place anyway.) > > Archie's daemonnews article has an example of how to do UDP tunneling > with netgraph, which nets about a 2x performance improvement over vtun > (without encryption, haven't figured out how tie in ng_mppc). > > Lars > -- > Lars Eggert USC Information Sciences Institute > -- =============================================================== Christophe Prevotaux Email: c.prevotaux@hexanet.fr HEXANET SARL URL: http://www.hexanet.fr/ Z.A.C Les Charmilles Tel: +33 (0)3 26 79 30 05 3 Allée Thierry Sabine Direct: +33 (0)3 26 61 77 72 BP202 Fax: +33 (0)3 26 79 30 06 51686 Reims Cedex 2 FRANCE HEXANET Network Operation Center =============================================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 18 8:16: 9 2002 Delivered-To: freebsd-net@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id 8BDB437B406 for ; Tue, 18 Jun 2002 08:16:00 -0700 (PDT) Received: from isi.edu (c1-vpn3.isi.edu [128.9.176.29]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g5IFFwr27744; Tue, 18 Jun 2002 08:15:58 -0700 (PDT) Message-ID: <3D0F4EAE.5090207@isi.edu> Date: Tue, 18 Jun 2002 08:15:58 -0700 From: Lars Eggert Organization: USC Information Sciences Institute User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1a) Gecko/20020611 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christophe Prevotaux Cc: net@freebsd.org Subject: Re: IPIP (kind of) with Payload Encryption only References: <20020618153956.2a9352fa.c.prevotaux@hexanet.fr> <200206181352.g5IDqqnq047326@whizzo.transsys.com> <3D0F4AFA.3000908@isi.edu> <20020618170639.3754910d.c.prevotaux@hexanet.fr> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010601060805090305030807" 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 This is a cryptographically signed message in MIME format. --------------ms010601060805090305030807 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Christophe Prevotaux wrote: > I can use AH/ESP however since I am using a satellite link > thru a modem/hub(NOC) that fiddles around with packets in order > to optimize them , I can't encrypt the headers otherwise the > optimizer can't see inside the packets and therefore can't see the > headers , so no optimization is done ,and I end up with a 33,6Kbps > like speed for the VPN , which is useless (at best 56Kbps). You could try (transport mode) IPsec over a UDP tunnel, if your middlebox mucks with the L4 headers. Then again, your middlebox probably only "optimizes" TCP - have you benmarked TCP vs. UDP performance over the link? (If so, you'll need to use a TCP tunnel.) Lars -- Lars Eggert USC Information Sciences Institute --------------ms010601060805090305030807 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIrjCC ArUwggIeoAMCAQICAwWBRzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAxMDgyNDE2NDAwMFoXDTAyMDgyNDE2NDAwMFowVDEP MA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2VydDEc MBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEA0AvLBsD78nxcUHeHkaMgl3b4qYPnfgbf8Lh+HQP8RgGMRG/Yb+vTpkGezlwt9pkJxiD1 1uZDy4CNNJUu3gKxKSb+zRV70O+lkwwftuHoLHoH4xwo3LcQ2LGDpd+I95tUN4dfJ3TmeEcU SF50dC/SuUI4w8AlhXQ8IxrhgdayTpECAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIB BAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1Ud EwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAheZhn0pQA8zI7U2K1ZIAl11j0a1DKxnp3GtT vOUrGRB3WvYxidvdZ1kizhEsWeXU81TkNDH0DaRqtOEeu6Q2OhB+jeKEqY7IDAJE4/fI0e+d 6PnG1hd+vEvYmsKHkmzBhPc94XUOKNWO+qVNP2NGyNI3QIDy5wX4fdcOo1S34r4wggK1MIIC HqADAgECAgMFgUcwDQYJKoZIhvcNAQECBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYD VQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg UlNBIDIwMDAuOC4zMDAeFw0wMTA4MjQxNjQwMDBaFw0wMjA4MjQxNjQwMDBaMFQxDzANBgNV BAQTBkVnZ2VydDENMAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkq hkiG9w0BCQEWDWxhcnNlQGlzaS5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANAL ywbA+/J8XFB3h5GjIJd2+KmD534G3/C4fh0D/EYBjERv2G/r06ZBns5cLfaZCcYg9dbmQ8uA jTSVLt4CsSkm/s0Ve9DvpZMMH7bh6Cx6B+McKNy3ENixg6XfiPebVDeHXyd05nhHFEhedHQv 0rlCOMPAJYV0PCMa4YHWsk6RAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy dU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBAgUAA4GBAIXmYZ9KUAPMyO1NitWSAJddY9GtQysZ6dxrU7zlKxkQ d1r2MYnb3WdZIs4RLFnl1PNU5DQx9A2karThHrukNjoQfo3ihKmOyAwCROP3yNHvnej5xtYX frxL2JrCh5JswYT3PeF1DijVjvqlTT9jRsjSN0CA8ucF+H3XDqNUt+K+MIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYICpjCCAqICAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDBYFHMAkGBSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAyMDYxODE1MTU1OFowIwYJKoZIhvcNAQkEMRYEFKqTEBE9AkBs 31lHLGhnXxhkk7A4MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0B CRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG A1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRl IFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMF gUcwDQYJKoZIhvcNAQEBBQAEgYByGLJpCEkZMXA/2296XBtVBAERq3NiS+3rV28gHGehH77y ROGzNeQR1BhtUZq0u7lfVKbleRR4LZVstKEUZe5VfOgn5GnaIE8HBaNPR+kq1HdCA2kRBbtW AQGyO5nCHUKEYuYiPGuW2OkvtdXkL9JQAUPCZLCNQtm+iheTjUsgegAAAAAAAA== --------------ms010601060805090305030807-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 18 8:43:50 2002 Delivered-To: freebsd-net@freebsd.org Received: from smtp.inode.at (goliath.inode.at [195.58.161.55]) by hub.freebsd.org (Postfix) with ESMTP id 9E0C637B403 for ; Tue, 18 Jun 2002 08:43:43 -0700 (PDT) Received: from line-c-242.adsl-dynamic.inode.at ([62.99.151.242] helo=inode.at) by smtp.inode.at with esmtp (Exim 3.34 #1) id 17KL8q-000059-00 for freebsd-net@freebsd.org; Tue, 18 Jun 2002 17:43:36 +0200 Message-ID: <3D0F54BE.6070701@inode.at> Date: Tue, 18 Jun 2002 17:41:50 +0200 From: Michael Bretterklieber User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-AT; rv:0.9.9) Gecko/20020311 X-Accept-Language: de-at, de-de, de, en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: ppp callback-question Content-Type: text/plain; charset=us-ascii; format=flowed 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 have a dialin-Box with FreeBSD 3.5. I use the callback (cbcp) option from ppp and the problem is, that ppp waites about 30 seconds until he starts the callback. Is there any option to reduce this timeout? bye, -- -- -------------------------------------- E-mail: Michael.Bretterklieber@jawa.at ---------------------------- JAWA Management Software GmbH Liebenauer Hauptstr. 200 A-8041 GRAZ Tel: ++43-(0)316-403274-12 Fax: ++43-(0)316-403274-10 GSM: ++43-(0)676-93 96 698 homepage: http://www.jawa.at --------- privat ----------- E-mail: mbretter@inode.at homepage: http://www.inode.at/mbretter -------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 18 10:33:36 2002 Delivered-To: freebsd-net@freebsd.org Received: from hawk.dcu.ie (mail.dcu.ie [136.206.1.5]) by hub.freebsd.org (Postfix) with ESMTP id 1BEDC37B403 for ; Tue, 18 Jun 2002 10:33:08 -0700 (PDT) Received: from prodigy.redbrick.dcu.ie (136.206.15.10) by hawk.dcu.ie (6.0.040) id 3CC55D79001898E6 for freebsd-net@freebsd.org; Tue, 18 Jun 2002 18:33:07 +0100 Received: by prodigy.redbrick.dcu.ie (Postfix, from userid 2027) id 0B088DA4A; Tue, 18 Jun 2002 18:33:06 +0100 (IST) Date: Tue, 18 Jun 2002 18:33:06 +0100 From: Colin Whittaker To: freebsd-net@freebsd.org Subject: bge driver issue Message-ID: <20020618183306.A1796@prodigy.Redbrick.DCU.IE> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Organization: North East Technologies Ltd. X-subliminal-message: Give Colin all your money. 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 have a dell poweredge 2550 with which I am having all sorts of nasty network problems. The network interface will just stop responding. I get an error message like this: Jun 18 08:19:38 shekondar /kernel: bge0: watchdog timeout -- resetting This is using the broadcom 10/100/1000 NIC on the mother board, the intel 10/100 has had similar issues but produces no log messages. duplex and speed settings are forced on both the card and the switch. sometimes the kernel reset will clear the fault but sometimes you need to ifconfig down / up the interface to get it going again. This box has been running fine for several weeks, it is only as we have started to shift to production levels of traffic to it that it has started this. Approx 30M bits/sec out and 12M bits/sec inbound. There was a simple ipfw ruleset on the box but I have disable that just now to see if it helps. Googleing has given me people who report similar problems but no solutions / work arounds. Have anyone got any suggestions as to what to do next. Colin Here is the output of postconf bge0@pci1:8:0: class=0x020000 card=0x00d11028 chip=0x164414e4 rev=0x12 hdr=0x00 vendor = 'Broadcom Corporation' device = 'BCM5700/1 Gigabit Ethernet Controller' class = network subclass = ethernet -- "Design" is like a religion - too much of it makes you inflexibly and unpopular. Linus Torvalds To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 18 10:37:37 2002 Delivered-To: freebsd-net@freebsd.org Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by hub.freebsd.org (Postfix) with ESMTP id 2A75D37B407 for ; Tue, 18 Jun 2002 10:37:25 -0700 (PDT) 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 g5IHbNdq008249; Tue, 18 Jun 2002 10:37:23 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.3/8.12.3/Submit) id g5IHbNrJ008248; Tue, 18 Jun 2002 10:37:23 -0700 Date: Tue, 18 Jun 2002 10:37:23 -0700 From: Brooks Davis To: Colin Whittaker Cc: freebsd-net@FreeBSD.ORG Subject: Re: bge driver issue Message-ID: <20020618103723.A7817@Odin.AC.HMC.Edu> References: <20020618183306.A1796@prodigy.Redbrick.DCU.IE> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="0OAP2g/MAC+5xKAE" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020618183306.A1796@prodigy.Redbrick.DCU.IE>; from grimnar+freebsd-net@redbrick.dcu.ie on Tue, Jun 18, 2002 at 06:33:06PM +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) on odin.ac.hmc.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 --0OAP2g/MAC+5xKAE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 18, 2002 at 06:33:06PM +0100, Colin Whittaker wrote: > I have a dell poweredge 2550 with which I am having all sorts of > nasty network problems. > The network interface will just stop responding. > I get an error message like this: > Jun 18 08:19:38 shekondar /kernel: bge0: watchdog timeout -- resetting You don't say what version of FreeBSD you are running. There were a number of changes made to the bge driver a month or so ago which are supposed to help with some problems. If you are running 4.5-RELEASE you will certaintly have trouble. -- 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 --0OAP2g/MAC+5xKAE 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 iD8DBQE9D2/SXY6L6fI4GtQRAkjwAKDa0Vyzwo1RJT1cxOoAVWGxYrsJlQCfWC3K zh0XxTUqNm0qFXYEwveP26k= =VoMo -----END PGP SIGNATURE----- --0OAP2g/MAC+5xKAE-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 18 13:22:31 2002 Delivered-To: freebsd-net@freebsd.org Received: from web21101.mail.yahoo.com (web21101.mail.yahoo.com [216.136.227.103]) by hub.freebsd.org (Postfix) with SMTP id 9E80237B43F for ; Tue, 18 Jun 2002 13:22:09 -0700 (PDT) Message-ID: <20020618202209.39996.qmail@web21101.mail.yahoo.com> Received: from [152.15.26.29] by web21101.mail.yahoo.com via HTTP; Tue, 18 Jun 2002 13:22:09 PDT Date: Tue, 18 Jun 2002 13:22:09 -0700 (PDT) From: Vinod Subject: sensing network bandwidth To: freebsd-net@freebsd.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 whats the best way to sense the network bandwidth available to your network at a certain moment? i am trying to implement a variable rate control on my video server and i want to base the rate on the current bandwidth available to my clients.Any suggestions would be greatly appreciated. Thanks, Vinod __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 18 13:52:43 2002 Delivered-To: freebsd-net@freebsd.org Received: from obsidian.sentex.ca (obsidian.sentex.ca [64.7.128.101]) by hub.freebsd.org (Postfix) with ESMTP id 4FE1C37B401; Tue, 18 Jun 2002 13:52:35 -0700 (PDT) Received: from simian.sentex.net (pyroxene.sentex.ca [199.212.134.18]) by obsidian.sentex.ca (8.12.2/8.12.2) with ESMTP id g5IKqW7U081735; Tue, 18 Jun 2002 16:52:33 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <5.1.0.14.0.20020618163928.05018cf0@marble.sentex.ca> X-Sender: mdtpop@marble.sentex.ca X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 18 Jun 2002 16:54:49 -0400 To: freebsd-net@FreeBSD.ORG From: Mike Tancsa Subject: tracking down strange MTU issues with PPPoE) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: By Sentex Communications (obsidian/20020220) 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 DSL whole supplier we use (Bell Canada) has been turfing their Redback SMSes and moving to an ERX from unisphere networks. With the Redback, all was great... I had a FreeBSD box acting as a NAT gateway for a number of Windows boxes and all was great. Then, the customer got moved over to one of these ERXes and there is now some strange MTU problem. Couple of things. Supposedly the default MTU on the ERX is 1472 (or 1452) depending on who you talk to and not 1492. e.g. when doing a fetch to >> lynx2.8.4rel.1.tar.bz2 doesn't seem to exist in /usr/ports/distfiles/. >> Attempting to fetch from http://lynx.isc.org/current/. Receiving lynx2.8.4rel.1.tar.bz2 (1940531 bytes): 0%^C 16682 bytes transferred in 89.5 seconds (186.41 Bps) fetch: transfer interrupted Notice the speed... Its totally brutal. yet, a transfer from just a few hops away is fine. My question is, how can I track this problem down ? There seems to be some strange interaction with FreeBSD because if I put a Windows box on the other end, it does not suffer from this same problem. I can easily repeat the problem, but the question is, how can I track down the issue and then explain it to my telco. (Note, I have tried various MTU and MRU settings. Thanks for any pointers. 4.6-STABLE FreeBSD 4.6-STABLE #0: Tue Jun 18 default: set log Phase Chat LCP IPCP CCP tun command ident user-ppp VERSION (built COMPILATIONDATE) # Ensure that "device" references the correct serial port # for your modem. (cuaa0 = COM1, cuaa1 = COM2) # set device /dev/cuaa1 set speed 115200 set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \ \"\" AT OK-AT-OK ATE1Q0 OK \\dATDT\\T TIMEOUT 40 CONNECT" set timeout 180 # 3 minute idle timer (the default) enable dns # request DNS info (for resolv.conf) pppoe: set device PPPoE:fxp1 #set mtu 1452 #set mru 1452 set speed sync enable lqr set lqrperiod 5 set cd 5 set dial set login set timeout 0 disable deflate pred1 mppe deny deflate pred1 mppe set authname user@example.com set authkey thepassword set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0 add default HISADDR ---Mike -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 18 14: 9:28 2002 Delivered-To: freebsd-net@freebsd.org Received: from cody.jharris.com (cody.jharris.com [205.238.128.83]) by hub.freebsd.org (Postfix) with ESMTP id 263BF37B400 for ; Tue, 18 Jun 2002 14:09:25 -0700 (PDT) Received: from localhost (nick@localhost) by cody.jharris.com (8.11.1/8.9.3) with ESMTP id g5ILYL096930; Tue, 18 Jun 2002 16:34:21 -0500 (CDT) (envelope-from nick@rogness.net) Date: Tue, 18 Jun 2002 16:34:20 -0500 (CDT) From: Nick Rogness X-Sender: nick@cody.jharris.com To: Mike Tancsa Cc: freebsd-net@FreeBSD.ORG Subject: Re: tracking down strange MTU issues with PPPoE) In-Reply-To: <5.1.0.14.0.20020618163928.05018cf0@marble.sentex.ca> Message-ID: 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, 18 Jun 2002, Mike Tancsa wrote: > > The DSL whole supplier we use (Bell Canada) has been turfing their > Redback SMSes and moving to an ERX from unisphere networks. There was, at one time, MTU problems with PPPoE. See the tcpmssd port or other online documentation. I don't know if anything has changed recently concerning this. Nick Rogness - Don't mind me...I'm just sniffing your packets To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 18 14:14:45 2002 Delivered-To: freebsd-net@freebsd.org Received: from obsidian.sentex.ca (obsidian.sentex.ca [64.7.128.101]) by hub.freebsd.org (Postfix) with ESMTP id 5830837B400 for ; Tue, 18 Jun 2002 14:14:38 -0700 (PDT) Received: from simian.sentex.net (pyroxene.sentex.ca [199.212.134.18]) by obsidian.sentex.ca (8.12.2/8.12.2) with ESMTP id g5ILEa7U083410; Tue, 18 Jun 2002 17:14:37 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <5.1.0.14.0.20020618171528.05ee9d98@marble.sentex.ca> X-Sender: mdtpop@marble.sentex.ca X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 18 Jun 2002 17:16:50 -0400 To: Nick Rogness From: Mike Tancsa Subject: Re: tracking down strange MTU issues with PPPoE) Cc: freebsd-net@FreeBSD.ORG In-Reply-To: References: <5.1.0.14.0.20020618163928.05018cf0@marble.sentex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: By Sentex Communications (obsidian/20020220) 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, the mss fixup is enabled by default and is part of the stock PPP from what I understand. Also, this was all working just great when the other end was a redback. The problems only started when the telco moved the termination to the ERX. ---Mike At 04:34 PM 18/06/2002 -0500, Nick Rogness wrote: >On Tue, 18 Jun 2002, Mike Tancsa wrote: > > > > > The DSL whole supplier we use (Bell Canada) has been turfing their > > Redback SMSes and moving to an ERX from unisphere networks. > > There was, at one time, MTU problems with PPPoE. See the tcpmssd > port or other online documentation. I don't know if anything has > changed recently concerning this. > >Nick Rogness > - Don't mind me...I'm just sniffing your packets To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 18 15:35:39 2002 Delivered-To: freebsd-net@freebsd.org Received: from pacbell.net (adsl-63-199-179-203.dsl.snfc21.pacbell.net [63.199.179.203]) by hub.freebsd.org (Postfix) with ESMTP id 1E1B137B406 for ; Tue, 18 Jun 2002 15:35:31 -0700 (PDT) Received: (from paleph@localhost) by pacbell.net (8.11.0/8.9.3) id g5IM6P003388 for freebsd-net@freebsd.org; Tue, 18 Jun 2002 15:06:25 -0700 From: paleph@pacbell.net Message-Id: <200206182206.g5IM6P003388@pacbell.net> Subject: Re: bge driver issue To: freebsd-net@freebsd.org Date: Tue, 18 Jun 2002 15:06:25 -0700 (PDT) X-Mailer: ELM [version 2.5 PL3] 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 We have a Dell poweredge 2650 (successor to 2550). We also saw the same problem with 4.5. I tried the current bge driver from 4.6 without success. The problem seems to be a size problem. When we ftp a small file, things work fine. However, when we try a 18 Megabyte file, the ftp hands and we see the problem descriped below. The linux system that came with the hardware (from dell) worked fine. BTW. This was occuring with a 100 Mbit link. I have not been able to get any resolution on this. The only replies seem to indicate that something is seriously broken with the bge driver. Paul Fronberg paleph@pacbell.net > I have a dell poweredge 2550 with which I am having all sorts of > nasty network problems. > The network interface will just stop responding. > I get an error message like this: > Jun 18 08:19:38 shekondar /kernel: bge0: watchdog timeout -- resetting > > This is using the broadcom 10/100/1000 NIC on the mother board, the > intel 10/100 has had similar issues but produces no log messages. > > duplex and speed settings are forced on both the card and the switch. > sometimes the kernel reset will clear the fault but sometimes you > need to ifconfig down / up the interface to get it going again. > > This box has been running fine for several weeks, it is only as we have > started to shift to production levels of traffic to it that it has started > this. Approx 30M bits/sec out and 12M bits/sec inbound. > > There was a simple ipfw ruleset on the box but I have disable that > just now to see if it helps. > > > Googleing has given me people who report similar problems but no > solutions / work arounds. > > Have anyone got any suggestions as to what to do next. > > Colin > > Here is the output of postconf > > bge0@pci1:8:0: class=0x020000 card=0x00d11028 chip=0x164414e4 rev=0x12 > hdr=0x00 vendor = 'Broadcom Corporation' > device = 'BCM5700/1 Gigabit Ethernet Controller' > class = network > subclass = ethernet To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 18 16: 9:53 2002 Delivered-To: freebsd-net@freebsd.org Received: from misery.sdf.com (misery.sdf.com [207.200.153.226]) by hub.freebsd.org (Postfix) with ESMTP id 11E6037B404 for ; Tue, 18 Jun 2002 16:09:42 -0700 (PDT) Received: from tom (helo=localhost) by misery.sdf.com with local-esmtp (Exim 2.12 #1) id 17KRAW-0007Se-00; Tue, 18 Jun 2002 15:09:44 -0700 Date: Tue, 18 Jun 2002 15:09:42 -0700 (PDT) From: Tom Samplonius To: Mike Tancsa Cc: freebsd-net@FreeBSD.ORG Subject: Re: tracking down strange MTU issues with PPPoE) In-Reply-To: <5.1.0.14.0.20020618163928.05018cf0@marble.sentex.ca> Message-ID: 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 Well, if you need to find the MTU, the ppp logs should tell you what the remote end is telling you to use. Usually, if you are having a MTU problem, it relates to fragmentation, MTU detection and ICMP filters. FreeBSD uses MTU detection by default. However, MTU detection requires that ICMP "can't fragment" messages be received, and some broken sites filter all ICMP. I know that the Redback has an "ignore don't fragment" feature. If this is enabled, it will fragment packets, it would normally throw away. This feature will break MTU detection too, but at least the end user won't notice, and packets will flow. Tom On Tue, 18 Jun 2002, Mike Tancsa wrote: > > The DSL whole supplier we use (Bell Canada) has been turfing their Redback > SMSes and moving to an ERX from unisphere networks. > > With the Redback, all was great... I had a FreeBSD box acting as a NAT > gateway for a number of Windows boxes and all was great. Then, the > customer got moved over to one of these ERXes and there is now some strange > MTU problem. Couple of things. Supposedly the default MTU on the ERX is > 1472 (or 1452) depending on who you talk to and not 1492. > > e.g. when doing a fetch to > >> lynx2.8.4rel.1.tar.bz2 doesn't seem to exist in /usr/ports/distfiles/. > >> Attempting to fetch from http://lynx.isc.org/current/. > Receiving lynx2.8.4rel.1.tar.bz2 (1940531 bytes): 0%^C > 16682 bytes transferred in 89.5 seconds (186.41 Bps) > fetch: transfer interrupted > > Notice the speed... Its totally brutal. yet, a transfer from just a few > hops away is fine. > > My question is, how can I track this problem down ? There seems to be some > strange interaction with FreeBSD because if I put a Windows box on the > other end, it does not suffer from this same problem. I can easily repeat > the problem, but the question is, how can I track down the issue and then > explain it to my telco. > > (Note, I have tried various MTU and MRU settings. > > Thanks for any pointers. > > 4.6-STABLE FreeBSD 4.6-STABLE #0: Tue Jun 18 > > > default: > set log Phase Chat LCP IPCP CCP tun command > ident user-ppp VERSION (built COMPILATIONDATE) > > # Ensure that "device" references the correct serial port > # for your modem. (cuaa0 = COM1, cuaa1 = COM2) > # > set device /dev/cuaa1 > > set speed 115200 > set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \ > \"\" AT OK-AT-OK ATE1Q0 OK \\dATDT\\T TIMEOUT 40 CONNECT" > set timeout 180 # 3 minute idle timer (the default) > enable dns # request DNS info (for resolv.conf) > > > pppoe: > set device PPPoE:fxp1 > #set mtu 1452 > #set mru 1452 > set speed sync > enable lqr > set lqrperiod 5 > set cd 5 > set dial > set login > set timeout 0 > disable deflate pred1 mppe > deny deflate pred1 mppe > set authname user@example.com > set authkey thepassword > set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0 > add default HISADDR > > > > ---Mike > -------------------------------------------------------------------- > Mike Tancsa, tel +1 519 651 3400 > Sentex Communications, mike@sentex.net > Providing Internet since 1994 www.sentex.net > Cambridge, Ontario Canada www.sentex.net/mike > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-isp" 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 Jun 18 16:18:45 2002 Delivered-To: freebsd-net@freebsd.org Received: from ebola.biohz.net (adsl-64-168-80-140.dsl.snfc21.pacbell.net [64.168.80.140]) by hub.freebsd.org (Postfix) with ESMTP id 0E4F337B420 for ; Tue, 18 Jun 2002 16:18:31 -0700 (PDT) Received: from flu (localhost [127.0.0.1]) by ebola.biohz.net (Postfix) with SMTP id 1BE3D1152FA; Tue, 18 Jun 2002 16:18:30 -0700 (PDT) Message-ID: <00c501c2171e$7538a720$011211ac@biohz.net> From: "Renaud Waldura" To: "Mike Tancsa" Cc: References: Subject: Re: tracking down strange MTU issues with PPPoE) Date: Tue, 18 Jun 2002 16:18:29 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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 Section 6.3 of the following document describes this issue in detail and may help you solve it. http://renaud.waldura.com/doc/freebsd/pppoe/ ----- Original Message ----- From: "Tom Samplonius" To: "Mike Tancsa" Cc: Sent: Tuesday, June 18, 2002 3:09 PM Subject: Re: tracking down strange MTU issues with PPPoE) > > Well, if you need to find the MTU, the ppp logs should tell you what the > remote end is telling you to use. > > Usually, if you are having a MTU problem, it relates to fragmentation, > MTU detection and ICMP filters. FreeBSD uses MTU detection by default. > However, MTU detection requires that ICMP "can't fragment" messages be > received, and some broken sites filter all ICMP. I know that the Redback > has an "ignore don't fragment" feature. If this is enabled, it will > fragment packets, it would normally throw away. This feature will break > MTU detection too, but at least the end user won't notice, and packets > will flow. > > > Tom > > > On Tue, 18 Jun 2002, Mike Tancsa wrote: > > > > > The DSL whole supplier we use (Bell Canada) has been turfing their Redback > > SMSes and moving to an ERX from unisphere networks. > > > > With the Redback, all was great... I had a FreeBSD box acting as a NAT > > gateway for a number of Windows boxes and all was great. Then, the > > customer got moved over to one of these ERXes and there is now some strange > > MTU problem. Couple of things. Supposedly the default MTU on the ERX is > > 1472 (or 1452) depending on who you talk to and not 1492. > > > > e.g. when doing a fetch to > > >> lynx2.8.4rel.1.tar.bz2 doesn't seem to exist in /usr/ports/distfiles/. > > >> Attempting to fetch from http://lynx.isc.org/current/. > > Receiving lynx2.8.4rel.1.tar.bz2 (1940531 bytes): 0%^C > > 16682 bytes transferred in 89.5 seconds (186.41 Bps) > > fetch: transfer interrupted > > > > Notice the speed... Its totally brutal. yet, a transfer from just a few > > hops away is fine. > > > > My question is, how can I track this problem down ? There seems to be some > > strange interaction with FreeBSD because if I put a Windows box on the > > other end, it does not suffer from this same problem. I can easily repeat > > the problem, but the question is, how can I track down the issue and then > > explain it to my telco. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 18 16:33:38 2002 Delivered-To: freebsd-net@freebsd.org Received: from Awfulhak.org (gw.Awfulhak.org [217.204.245.18]) by hub.freebsd.org (Postfix) with ESMTP id C2BAA37B404 for ; Tue, 18 Jun 2002 16:33:30 -0700 (PDT) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [IPv6:fec0::1:12]) by Awfulhak.org (8.12.3/8.12.3) with ESMTP id g5INXRMt071226; Wed, 19 Jun 2002 00:33:28 +0100 (BST) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [IPv6:::1]) by hak.lan.Awfulhak.org (8.12.4/8.12.4) with SMTP id g5INXQmv034840; Wed, 19 Jun 2002 00:33:26 +0100 (BST) (envelope-from brian@Awfulhak.org) Date: Wed, 19 Jun 2002 00:33:26 +0100 From: Brian Somers To: Mike Tancsa Cc: freebsd-net@FreeBSD.ORG Subject: Re: tracking down strange MTU issues with PPPoE) Message-Id: <20020619003326.6cc5740d.brian@Awfulhak.org> In-Reply-To: <5.1.0.14.0.20020618163928.05018cf0@marble.sentex.ca> References: <5.1.0.14.0.20020618163928.05018cf0@marble.sentex.ca> X-Mailer: Sylpheed version 0.7.6claws (GTK+ 1.2.10; i386-portbld-freebsd5.0) 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 Perhaps adding set mtu max 1452 will help ? On Tue, 18 Jun 2002 16:54:49 -0400, Mike Tancsa wrote: > > The DSL whole supplier we use (Bell Canada) has been turfing their Redback > SMSes and moving to an ERX from unisphere networks. > > With the Redback, all was great... I had a FreeBSD box acting as a NAT > gateway for a number of Windows boxes and all was great. Then, the > customer got moved over to one of these ERXes and there is now some strange > MTU problem. Couple of things. Supposedly the default MTU on the ERX is > 1472 (or 1452) depending on who you talk to and not 1492. > > e.g. when doing a fetch to > >> lynx2.8.4rel.1.tar.bz2 doesn't seem to exist in /usr/ports/distfiles/. > >> Attempting to fetch from http://lynx.isc.org/current/. > Receiving lynx2.8.4rel.1.tar.bz2 (1940531 bytes): 0%^C > 16682 bytes transferred in 89.5 seconds (186.41 Bps) > fetch: transfer interrupted > > Notice the speed... Its totally brutal. yet, a transfer from just a few > hops away is fine. > > My question is, how can I track this problem down ? There seems to be some > strange interaction with FreeBSD because if I put a Windows box on the > other end, it does not suffer from this same problem. I can easily repeat > the problem, but the question is, how can I track down the issue and then > explain it to my telco. > > (Note, I have tried various MTU and MRU settings. > > Thanks for any pointers. > > 4.6-STABLE FreeBSD 4.6-STABLE #0: Tue Jun 18 > > > default: > set log Phase Chat LCP IPCP CCP tun command > ident user-ppp VERSION (built COMPILATIONDATE) > > # Ensure that "device" references the correct serial port > # for your modem. (cuaa0 = COM1, cuaa1 = COM2) > # > set device /dev/cuaa1 > > set speed 115200 > set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \ > \"\" AT OK-AT-OK ATE1Q0 OK \\dATDT\\T TIMEOUT 40 CONNECT" > set timeout 180 # 3 minute idle timer (the default) > enable dns # request DNS info (for resolv.conf) > > > pppoe: > set device PPPoE:fxp1 > #set mtu 1452 > #set mru 1452 > set speed sync > enable lqr > set lqrperiod 5 > set cd 5 > set dial > set login > set timeout 0 > disable deflate pred1 mppe > deny deflate pred1 mppe > set authname user@example.com > set authkey thepassword > set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0 > add default HISADDR > > > > ---Mike > -------------------------------------------------------------------- > Mike Tancsa, tel +1 519 651 3400 > Sentex Communications, mike@sentex.net > Providing Internet since 1994 www.sentex.net > Cambridge, Ontario Canada www.sentex.net/mike > -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 18 17: 0:48 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id E88B637B409 for ; Tue, 18 Jun 2002 17:00:17 -0700 (PDT) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020619000017.LBWL2751.rwcrmhc52.attbi.com@InterJet.elischer.org>; Wed, 19 Jun 2002 00:00:17 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id QAA21936; Tue, 18 Jun 2002 16:41:25 -0700 (PDT) Date: Tue, 18 Jun 2002 16:41:23 -0700 (PDT) From: Julian Elischer To: Christophe Prevotaux Cc: net@freebsd.org Subject: Re: IPIP (kind of) with Payload Encryption only In-Reply-To: <20020618153956.2a9352fa.c.prevotaux@hexanet.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN 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 you can set up pseudo interfaces using netgraph iface and ksocket nodes so that anything going into the interface is encapsulated in a UDP packet. The set up IPSEC to encrypt the packets tat aer sent to the virtual interface.. you get ESP inside normal UDP. (will that do?) It's all in setting up the routing so that the ESP packets get routed to the netgraph interfaces, which are attached to the ksocket nodes which are set to UDP and bound to addresses.. I use something similar here except that I then re-encrypt the final tunnel as well :-) On Tue, 18 Jun 2002, Christophe Prevotaux wrote: > Hi, >=20 > Could someone tell me if there is a way to build a VPN(like) tunnel from > a FreeBSD machine acting as a VPN gateway to another machine acting as > another VPN gateway using normal IP packets that have only their data > payload encrypted. Of course there would have to be a way to setup the > tunnel and still retain the network addressing of each side of the VPN >=20 > I thought about some kind of IPIP tunneling but with data payload > encryption and some kind of key exchange for authentication >=20 > has anyone made or seen such a system yet ?=20 >=20 > I do not want to use (I can't) AH and ESP for this because of some > technical contraints=20 >=20 > +-------------+ +---------+ > | VPN gateway |---| Router |--------+ > --Network A=3D=3D=3D|=3D=3DFreeBSD=3D=3D=3D=3D|=3D=3D=3D|=3D=3D=3D=3D=3D= =3D=3D=3D=3D|=3D=3D | > +-------------+ +---------+ || | =20 > VPN Internet =20 > || | =20 > +-------------+ +---------+ || | =20 > --Network B=3D=3D=3D|=3DVPN gateway=3D|=3D=3D=3D|=3DRouter=3D=3D|=3D=3D = | > | FreeBSD |---| |--------+ > +-------------+ +---------+ >=20 > -- > =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=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Christophe Prevotaux Email: c.prevotaux@hexanet.fr > HEXANET SARL URL: http://www.hexanet.fr/ > Z.A.C Les Charmilles Tel: +33 (0)3 26 79 30 05=20 > 3 All=E9e Thierry Sabine Direct: +33 (0)3 26 61 77 72=20 > BP202 Fax: +33 (0)3 26 79 30 06 > 51686 Reims Cedex 2 =09=09 =20 > FRANCE HEXANET Network Operation Center =20 > =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=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message >=20 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 18 17:36:49 2002 Delivered-To: freebsd-net@freebsd.org Received: from vinyl2.sentex.ca (vinyl2.sentex.ca [199.212.134.13]) by hub.freebsd.org (Postfix) with ESMTP id 1D45237B401 for ; Tue, 18 Jun 2002 17:36:32 -0700 (PDT) Received: from house.sentex.net (cage.simianscience.com [64.7.134.1]) (authenticated bits=0) by vinyl2.sentex.ca (8.12.3/8.12.2) with ESMTP id g5J0aTdc061502; Tue, 18 Jun 2002 20:36:30 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <5.1.0.14.0.20020618191155.01c08f18@192.168.0.12> X-Sender: mdtancsa@192.168.0.12 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 18 Jun 2002 19:17:43 -0400 To: Tom Samplonius From: Mike Tancsa Subject: Re: tracking down strange MTU issues with PPPoE) Cc: freebsd-net@FreeBSD.ORG In-Reply-To: References: <5.1.0.14.0.20020618163928.05018cf0@marble.sentex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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, In terms of the MTU, I can set that in my router as I am the ISP :-) Not sure how it works with Telus on the west coast, but with Bell, PPPoE is done between the client and the DSL concentrator. Then the session is handed off to the ISP via an L2TP tunnel. I can control that part on my router (a cisco) e.g. vpdn-group 72 description info describing the particular DSL concentrator - redback or ERX accept-dialin protocol any virtual-template 3 terminate-from hostname our-l2tp-tunnel-endpoint local name my-local-auth-name-to-the-telco lcp renegotiation always l2tp tunnel password the-big-pass-to-that-concentrator source-ip 1.2.3.4 ! Then with the virt-template, I can control what the other end negotiates as the MTU size. In the past, 1492 and all was happy on the planet. interface Virtual-Template3 description ERX-Only-Virtual-Template mtu 1492 ip unnumbered Loopback0 peer default ip address pool -our-pool-names ppp authentication pap chap callin ! I have tried adjusting the MTU to various sizes but with no luck. In case someone reading this has been down the same boat, yes, I do clear vpdn lt2p tun our-l2tp-tunnel-endpoint and then connect again with the client... ifconfig tun0 on the client side does indeed show the MTU specified in the virt-template. ---Mike At 03:09 PM 6/18/2002 -0700, Tom Samplonius wrote: > Well, if you need to find the MTU, the ppp logs should tell you what the >remote end is telling you to use. > > Usually, if you are having a MTU problem, it relates to fragmentation, >MTU detection and ICMP filters. FreeBSD uses MTU detection by default. >However, MTU detection requires that ICMP "can't fragment" messages be >received, and some broken sites filter all ICMP. I know that the Redback >has an "ignore don't fragment" feature. If this is enabled, it will >fragment packets, it would normally throw away. This feature will break >MTU detection too, but at least the end user won't notice, and packets >will flow. > > >Tom > > >On Tue, 18 Jun 2002, Mike Tancsa wrote: > > > > > The DSL whole supplier we use (Bell Canada) has been turfing their Redback > > SMSes and moving to an ERX from unisphere networks. > > > > With the Redback, all was great... I had a FreeBSD box acting as a NAT > > gateway for a number of Windows boxes and all was great. Then, the > > customer got moved over to one of these ERXes and there is now some > strange > > MTU problem. Couple of things. Supposedly the default MTU on the ERX is > > 1472 (or 1452) depending on who you talk to and not 1492. > > > > e.g. when doing a fetch to > > >> lynx2.8.4rel.1.tar.bz2 doesn't seem to exist in /usr/ports/distfiles/. > > >> Attempting to fetch from http://lynx.isc.org/current/. > > Receiving lynx2.8.4rel.1.tar.bz2 (1940531 bytes): 0%^C > > 16682 bytes transferred in 89.5 seconds (186.41 Bps) > > fetch: transfer interrupted > > > > Notice the speed... Its totally brutal. yet, a transfer from just a few > > hops away is fine. > > > > My question is, how can I track this problem down ? There seems to be > some > > strange interaction with FreeBSD because if I put a Windows box on the > > other end, it does not suffer from this same problem. I can easily repeat > > the problem, but the question is, how can I track down the issue and then > > explain it to my telco. > > > > (Note, I have tried various MTU and MRU settings. > > > > Thanks for any pointers. > > > > 4.6-STABLE FreeBSD 4.6-STABLE #0: Tue Jun 18 > > > > > > default: > > set log Phase Chat LCP IPCP CCP tun command > > ident user-ppp VERSION (built COMPILATIONDATE) > > > > # Ensure that "device" references the correct serial port > > # for your modem. (cuaa0 = COM1, cuaa1 = COM2) > > # > > set device /dev/cuaa1 > > > > set speed 115200 > > set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \ > > \"\" AT OK-AT-OK ATE1Q0 OK \\dATDT\\T TIMEOUT 40 CONNECT" > > set timeout 180 # 3 minute idle timer (the > default) > > enable dns # request DNS info (for > resolv.conf) > > > > > > pppoe: > > set device PPPoE:fxp1 > > #set mtu 1452 > > #set mru 1452 > > set speed sync > > enable lqr > > set lqrperiod 5 > > set cd 5 > > set dial > > set login > > set timeout 0 > > disable deflate pred1 mppe > > deny deflate pred1 mppe > > set authname user@example.com > > set authkey thepassword > > set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0 > > add default HISADDR > > > > > > > > ---Mike > > -------------------------------------------------------------------- > > Mike Tancsa, tel +1 519 651 3400 > > Sentex Communications, mike@sentex.net > > Providing Internet since 1994 www.sentex.net > > Cambridge, Ontario Canada www.sentex.net/mike > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-isp" in the body of the message > > > > -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 18 17:36:51 2002 Delivered-To: freebsd-net@freebsd.org Received: from vinyl2.sentex.ca (vinyl2.sentex.ca [199.212.134.13]) by hub.freebsd.org (Postfix) with ESMTP id 99E0937B405 for ; Tue, 18 Jun 2002 17:36:37 -0700 (PDT) Received: from house.sentex.net (cage.simianscience.com [64.7.134.1]) (authenticated bits=0) by vinyl2.sentex.ca (8.12.3/8.12.2) with ESMTP id g5J0aTdg061502; Tue, 18 Jun 2002 20:36:33 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <5.1.0.14.0.20020618203201.07212f30@192.168.0.12> X-Sender: mdtancsa@192.168.0.12 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 18 Jun 2002 20:32:43 -0400 To: Brian Somers From: Mike Tancsa Subject: Re: tracking down strange MTU issues with PPPoE) Cc: freebsd-net@FreeBSD.ORG In-Reply-To: <20020619003326.6cc5740d.brian@Awfulhak.org> References: <5.1.0.14.0.20020618163928.05018cf0@marble.sentex.ca> <5.1.0.14.0.20020618163928.05018cf0@marble.sentex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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 Yes, that did it! Thanks very much! What is different about that, and me setting it on the other end as part of the virt-template ? ---Mike At 12:33 AM 6/19/2002 +0100, Brian Somers wrote: >Perhaps adding > > set mtu max 1452 > >will help ? > >On Tue, 18 Jun 2002 16:54:49 -0400, Mike Tancsa wrote: > > > > The DSL whole supplier we use (Bell Canada) has been turfing their Redback > > SMSes and moving to an ERX from unisphere networks. > > > > With the Redback, all was great... I had a FreeBSD box acting as a NAT > > gateway for a number of Windows boxes and all was great. Then, the > > customer got moved over to one of these ERXes and there is now some > strange > > MTU problem. Couple of things. Supposedly the default MTU on the ERX is > > 1472 (or 1452) depending on who you talk to and not 1492. > > > > e.g. when doing a fetch to > > >> lynx2.8.4rel.1.tar.bz2 doesn't seem to exist in /usr/ports/distfiles/. > > >> Attempting to fetch from http://lynx.isc.org/current/. > > Receiving lynx2.8.4rel.1.tar.bz2 (1940531 bytes): 0%^C > > 16682 bytes transferred in 89.5 seconds (186.41 Bps) > > fetch: transfer interrupted > > > > Notice the speed... Its totally brutal. yet, a transfer from just a few > > hops away is fine. > > > > My question is, how can I track this problem down ? There seems to be > some > > strange interaction with FreeBSD because if I put a Windows box on the > > other end, it does not suffer from this same problem. I can easily repeat > > the problem, but the question is, how can I track down the issue and then > > explain it to my telco. > > > > (Note, I have tried various MTU and MRU settings. > > > > Thanks for any pointers. > > > > 4.6-STABLE FreeBSD 4.6-STABLE #0: Tue Jun 18 > > > > > > default: > > set log Phase Chat LCP IPCP CCP tun command > > ident user-ppp VERSION (built COMPILATIONDATE) > > > > # Ensure that "device" references the correct serial port > > # for your modem. (cuaa0 = COM1, cuaa1 = COM2) > > # > > set device /dev/cuaa1 > > > > set speed 115200 > > set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \ > > \"\" AT OK-AT-OK ATE1Q0 OK \\dATDT\\T TIMEOUT 40 CONNECT" > > set timeout 180 # 3 minute idle timer (the > default) > > enable dns # request DNS info (for > resolv.conf) > > > > > > pppoe: > > set device PPPoE:fxp1 > > #set mtu 1452 > > #set mru 1452 > > set speed sync > > enable lqr > > set lqrperiod 5 > > set cd 5 > > set dial > > set login > > set timeout 0 > > disable deflate pred1 mppe > > deny deflate pred1 mppe > > set authname user@example.com > > set authkey thepassword > > set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0 > > add default HISADDR > > > > > > > > ---Mike > > -------------------------------------------------------------------- > > Mike Tancsa, tel +1 519 651 3400 > > Sentex Communications, mike@sentex.net > > Providing Internet since 1994 www.sentex.net > > Cambridge, Ontario Canada www.sentex.net/mike > > > > >-- >Brian > >Don't _EVER_ lose your sense of humour ! -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 18 18:16:28 2002 Delivered-To: freebsd-net@freebsd.org Received: from misery.sdf.com (misery.sdf.com [207.200.153.226]) by hub.freebsd.org (Postfix) with ESMTP id 7E82137B403 for ; Tue, 18 Jun 2002 18:16:16 -0700 (PDT) Received: from tom (helo=localhost) by misery.sdf.com with local-esmtp (Exim 2.12 #1) id 17KT90-0000SA-00; Tue, 18 Jun 2002 17:16:18 -0700 Date: Tue, 18 Jun 2002 17:16:16 -0700 (PDT) From: Tom Samplonius To: Mike Tancsa Cc: freebsd-net@FreeBSD.ORG Subject: Re: tracking down strange MTU issues with PPPoE) In-Reply-To: <5.1.0.14.0.20020618191155.01c08f18@192.168.0.12> Message-ID: 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 Possibly. There is a PPPoE session to the Redback (or ERX), then usually a L2TP session to the ISP. A PPPoE client connecting to the Redback (or ERX) should be told a valid MTU. PPP tunel to L2TP tunnel raises some interesting possiblities. I wonder how much mucking about the SMS does to the protocol. Obviously it is doing something, since the Redback works, but the ERX does not. Or the Bell network is broken :) Tom On Tue, 18 Jun 2002, Mike Tancsa wrote: > > Hi, > In terms of the MTU, I can set that in my router as I am the ISP > :-) Not sure how it works with Telus on the west coast, but with Bell, > PPPoE is done between the client and the DSL concentrator. Then the session > is handed off to the ISP via an L2TP tunnel. I can control that part on my > router (a cisco) > > e.g. > > vpdn-group 72 > description info describing the particular DSL concentrator - redback or ERX > accept-dialin > protocol any > virtual-template 3 > terminate-from hostname our-l2tp-tunnel-endpoint > local name my-local-auth-name-to-the-telco > lcp renegotiation always > l2tp tunnel password the-big-pass-to-that-concentrator > source-ip 1.2.3.4 > ! > > Then with the virt-template, I can control what the other end negotiates as > the MTU size. In the past, 1492 and all was happy on the planet. > > > interface Virtual-Template3 > description ERX-Only-Virtual-Template > mtu 1492 > ip unnumbered Loopback0 > peer default ip address pool -our-pool-names > ppp authentication pap chap callin > ! > > > I have tried adjusting the MTU to various sizes but with no luck. In case > someone reading this has been down the same boat, yes, I do clear vpdn lt2p > tun our-l2tp-tunnel-endpoint and then connect again with the client... > ifconfig tun0 on the client side does indeed show the MTU specified in the > virt-template. > > ---Mike > > At 03:09 PM 6/18/2002 -0700, Tom Samplonius wrote: > > > Well, if you need to find the MTU, the ppp logs should tell you what the > >remote end is telling you to use. > > > > Usually, if you are having a MTU problem, it relates to fragmentation, > >MTU detection and ICMP filters. FreeBSD uses MTU detection by default. > >However, MTU detection requires that ICMP "can't fragment" messages be > >received, and some broken sites filter all ICMP. I know that the Redback > >has an "ignore don't fragment" feature. If this is enabled, it will > >fragment packets, it would normally throw away. This feature will break > >MTU detection too, but at least the end user won't notice, and packets > >will flow. > > > > > >Tom > > > > > >On Tue, 18 Jun 2002, Mike Tancsa wrote: > > > > > > > > The DSL whole supplier we use (Bell Canada) has been turfing their Redback > > > SMSes and moving to an ERX from unisphere networks. > > > > > > With the Redback, all was great... I had a FreeBSD box acting as a NAT > > > gateway for a number of Windows boxes and all was great. Then, the > > > customer got moved over to one of these ERXes and there is now some > > strange > > > MTU problem. Couple of things. Supposedly the default MTU on the ERX is > > > 1472 (or 1452) depending on who you talk to and not 1492. > > > > > > e.g. when doing a fetch to > > > >> lynx2.8.4rel.1.tar.bz2 doesn't seem to exist in /usr/ports/distfiles/. > > > >> Attempting to fetch from http://lynx.isc.org/current/. > > > Receiving lynx2.8.4rel.1.tar.bz2 (1940531 bytes): 0%^C > > > 16682 bytes transferred in 89.5 seconds (186.41 Bps) > > > fetch: transfer interrupted > > > > > > Notice the speed... Its totally brutal. yet, a transfer from just a few > > > hops away is fine. > > > > > > My question is, how can I track this problem down ? There seems to be > > some > > > strange interaction with FreeBSD because if I put a Windows box on the > > > other end, it does not suffer from this same problem. I can easily repeat > > > the problem, but the question is, how can I track down the issue and then > > > explain it to my telco. > > > > > > (Note, I have tried various MTU and MRU settings. > > > > > > Thanks for any pointers. > > > > > > 4.6-STABLE FreeBSD 4.6-STABLE #0: Tue Jun 18 > > > > > > > > > default: > > > set log Phase Chat LCP IPCP CCP tun command > > > ident user-ppp VERSION (built COMPILATIONDATE) > > > > > > # Ensure that "device" references the correct serial port > > > # for your modem. (cuaa0 = COM1, cuaa1 = COM2) > > > # > > > set device /dev/cuaa1 > > > > > > set speed 115200 > > > set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \ > > > \"\" AT OK-AT-OK ATE1Q0 OK \\dATDT\\T TIMEOUT 40 CONNECT" > > > set timeout 180 # 3 minute idle timer (the > > default) > > > enable dns # request DNS info (for > > resolv.conf) > > > > > > > > > pppoe: > > > set device PPPoE:fxp1 > > > #set mtu 1452 > > > #set mru 1452 > > > set speed sync > > > enable lqr > > > set lqrperiod 5 > > > set cd 5 > > > set dial > > > set login > > > set timeout 0 > > > disable deflate pred1 mppe > > > deny deflate pred1 mppe > > > set authname user@example.com > > > set authkey thepassword > > > set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0 > > > add default HISADDR > > > > > > > > > > > > ---Mike > > > -------------------------------------------------------------------- > > > Mike Tancsa, tel +1 519 651 3400 > > > Sentex Communications, mike@sentex.net > > > Providing Internet since 1994 www.sentex.net > > > Cambridge, Ontario Canada www.sentex.net/mike > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > > with "unsubscribe freebsd-isp" in the body of the message > > > > > > > > -------------------------------------------------------------------- > Mike Tancsa, tel +1 519 651 3400 > Sentex Communications, mike@sentex.net > Providing Internet since 1994 www.sentex.net > Cambridge, Ontario Canada www.sentex.net/mike > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 18 18:49: 8 2002 Delivered-To: freebsd-net@freebsd.org Received: from vinyl2.sentex.ca (vinyl2.sentex.ca [199.212.134.13]) by hub.freebsd.org (Postfix) with ESMTP id 1192737B409 for ; Tue, 18 Jun 2002 18:49:03 -0700 (PDT) Received: from house.sentex.net (cage.simianscience.com [64.7.134.1]) (authenticated bits=0) by vinyl2.sentex.ca (8.12.3/8.12.2) with ESMTP id g5J1n0dc064099; Tue, 18 Jun 2002 21:49:01 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <5.1.0.14.0.20020618213845.01c42aa0@192.168.0.12> X-Sender: mdtancsa@192.168.0.12 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 18 Jun 2002 21:47:00 -0400 To: Tom Samplonius From: Mike Tancsa Subject: Re: tracking down strange MTU issues with PPPoE) Cc: freebsd-net@FreeBSD.ORG In-Reply-To: References: <5.1.0.14.0.20020618191155.01c08f18@192.168.0.12> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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 At 05:16 PM 6/18/2002 -0700, Tom Samplonius wrote: > Possibly. There is a PPPoE session to the Redback (or ERX), then >usually a L2TP session to the ISP. A PPPoE client connecting to the >Redback (or ERX) should be told a valid MTU. PPP tunel to L2TP tunnel >raises some interesting possiblities. I wonder how much mucking about the >SMS does to the protocol. Obviously it is doing something, since the >Redback works, but the ERX does not. Or the Bell network is broken :) b) is always a possibility. Actually, there is some bug in the ERX where the setting "IP TUNNEL REASSEMBLY" gets turned off when doing unrelated configs. The first time we encountered this, we had no end of trouble for 2 days and tracking down the right people to talk to was insane. There are groups in Bell who look after the DSL concentrators, groups who look after the DSLAMS, groups who look after the ATM network, but it seems not one individual knows how all the components work together, or at least they are not reachable. At one point one of the ATM guys said something to the effect that this was a known bug and I had to set the MTU on my terminating router's ethernet to 1450. I asked why and where the document was to which he responded that he was not allowed to share such information..... whatever.... Its ironic that the old kids game of "broken telephone" comes into play with the telco :-( ... But, Brian@freebsd.org's suggestion of set max mtu did the trick. I am curious to know why this is necessary on the ERX and not on the SMSes. ---Mike -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 18 19: 0:47 2002 Delivered-To: freebsd-net@freebsd.org Received: from vinyl2.sentex.ca (vinyl2.sentex.ca [199.212.134.13]) by hub.freebsd.org (Postfix) with ESMTP id 7E09A37B40E for ; Tue, 18 Jun 2002 19:00:18 -0700 (PDT) Received: from house.sentex.net (cage.simianscience.com [64.7.134.1]) (authenticated bits=0) by vinyl2.sentex.ca (8.12.3/8.12.2) with ESMTP id g5J20Cdc064463; Tue, 18 Jun 2002 22:00:13 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <5.1.0.14.0.20020618215651.05137298@192.168.0.12> X-Sender: mdtancsa@192.168.0.12 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 18 Jun 2002 21:58:10 -0400 To: Tom Samplonius From: Mike Tancsa Subject: Re: tracking down strange MTU issues with PPPoE) Cc: freebsd-net@FreeBSD.ORG In-Reply-To: References: <5.1.0.14.0.20020618191155.01c08f18@192.168.0.12> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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 Actually, I spoke too soon. The host I was testing against was the wrong one :( Its still broken with the set mtu max 1452 statement. ---Mike At 05:16 PM 6/18/2002 -0700, Tom Samplonius wrote: > Possibly. There is a PPPoE session to the Redback (or ERX), then >usually a L2TP session to the ISP. A PPPoE client connecting to the >Redback (or ERX) should be told a valid MTU. PPP tunel to L2TP tunnel >raises some interesting possiblities. I wonder how much mucking about the >SMS does to the protocol. Obviously it is doing something, since the >Redback works, but the ERX does not. Or the Bell network is broken :) > > >Tom > > >On Tue, 18 Jun 2002, Mike Tancsa wrote: > > > > > Hi, > > In terms of the MTU, I can set that in my router as I am the ISP > > :-) Not sure how it works with Telus on the west coast, but with Bell, > > PPPoE is done between the client and the DSL concentrator. Then the > session > > is handed off to the ISP via an L2TP tunnel. I can control that part > on my > > router (a cisco) > > > > e.g. > > > > vpdn-group 72 > > description info describing the particular DSL concentrator - redback > or ERX > > accept-dialin > > protocol any > > virtual-template 3 > > terminate-from hostname our-l2tp-tunnel-endpoint > > local name my-local-auth-name-to-the-telco > > lcp renegotiation always > > l2tp tunnel password the-big-pass-to-that-concentrator > > source-ip 1.2.3.4 > > ! > > > > Then with the virt-template, I can control what the other end > negotiates as > > the MTU size. In the past, 1492 and all was happy on the planet. > > > > > > interface Virtual-Template3 > > description ERX-Only-Virtual-Template > > mtu 1492 > > ip unnumbered Loopback0 > > peer default ip address pool -our-pool-names > > ppp authentication pap chap callin > > ! > > > > > > I have tried adjusting the MTU to various sizes but with no luck. In case > > someone reading this has been down the same boat, yes, I do clear vpdn > lt2p > > tun our-l2tp-tunnel-endpoint and then connect again with the client... > > ifconfig tun0 on the client side does indeed show the MTU specified in the > > virt-template. > > > > ---Mike > > > > At 03:09 PM 6/18/2002 -0700, Tom Samplonius wrote: > > > > > Well, if you need to find the MTU, the ppp logs should tell you > what the > > >remote end is telling you to use. > > > > > > Usually, if you are having a MTU problem, it relates to fragmentation, > > >MTU detection and ICMP filters. FreeBSD uses MTU detection by default. > > >However, MTU detection requires that ICMP "can't fragment" messages be > > >received, and some broken sites filter all ICMP. I know that the Redback > > >has an "ignore don't fragment" feature. If this is enabled, it will > > >fragment packets, it would normally throw away. This feature will break > > >MTU detection too, but at least the end user won't notice, and packets > > >will flow. > > > > > > > > >Tom > > > > > > > > >On Tue, 18 Jun 2002, Mike Tancsa wrote: > > > > > > > > > > > The DSL whole supplier we use (Bell Canada) has been turfing their > Redback > > > > SMSes and moving to an ERX from unisphere networks. > > > > > > > > With the Redback, all was great... I had a FreeBSD box acting as a NAT > > > > gateway for a number of Windows boxes and all was great. Then, the > > > > customer got moved over to one of these ERXes and there is now some > > > strange > > > > MTU problem. Couple of things. Supposedly the default MTU on the > ERX is > > > > 1472 (or 1452) depending on who you talk to and not 1492. > > > > > > > > e.g. when doing a fetch to > > > > >> lynx2.8.4rel.1.tar.bz2 doesn't seem to exist in > /usr/ports/distfiles/. > > > > >> Attempting to fetch from http://lynx.isc.org/current/. > > > > Receiving lynx2.8.4rel.1.tar.bz2 (1940531 bytes): 0%^C > > > > 16682 bytes transferred in 89.5 seconds (186.41 Bps) > > > > fetch: transfer interrupted > > > > > > > > Notice the speed... Its totally brutal. yet, a transfer from just a few > > > > hops away is fine. > > > > > > > > My question is, how can I track this problem down ? There seems to be > > > some > > > > strange interaction with FreeBSD because if I put a Windows box on the > > > > other end, it does not suffer from this same problem. I can easily > repeat > > > > the problem, but the question is, how can I track down the issue > and then > > > > explain it to my telco. > > > > > > > > (Note, I have tried various MTU and MRU settings. > > > > > > > > Thanks for any pointers. > > > > > > > > 4.6-STABLE FreeBSD 4.6-STABLE #0: Tue Jun 18 > > > > > > > > > > > > default: > > > > set log Phase Chat LCP IPCP CCP tun command > > > > ident user-ppp VERSION (built COMPILATIONDATE) > > > > > > > > # Ensure that "device" references the correct serial port > > > > # for your modem. (cuaa0 = COM1, cuaa1 = COM2) > > > > # > > > > set device /dev/cuaa1 > > > > > > > > set speed 115200 > > > > set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \ > > > > \"\" AT OK-AT-OK ATE1Q0 OK \\dATDT\\T TIMEOUT 40 CONNECT" > > > > set timeout 180 # 3 minute idle timer (the > > > default) > > > > enable dns # request DNS info (for > > > resolv.conf) > > > > > > > > > > > > pppoe: > > > > set device PPPoE:fxp1 > > > > #set mtu 1452 > > > > #set mru 1452 > > > > set speed sync > > > > enable lqr > > > > set lqrperiod 5 > > > > set cd 5 > > > > set dial > > > > set login > > > > set timeout 0 > > > > disable deflate pred1 mppe > > > > deny deflate pred1 mppe > > > > set authname user@example.com > > > > set authkey thepassword > > > > set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0 > > > > add default HISADDR > > > > > > > > > > > > > > > > ---Mike > > > > -------------------------------------------------------------------- > > > > Mike Tancsa, tel +1 519 > 651 3400 > > > > Sentex Communications, mike@sentex.net > > > > Providing Internet since 1994 www.sentex.net > > > > Cambridge, Ontario Canada www.sentex.net/mike > > > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > > > with "unsubscribe freebsd-isp" in the body of the message > > > > > > > > > > > > -------------------------------------------------------------------- > > Mike Tancsa, tel +1 519 651 3400 > > Sentex Communications, mike@sentex.net > > Providing Internet since 1994 www.sentex.net > > Cambridge, Ontario Canada www.sentex.net/mike > > > > > > -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 18 19: 7:24 2002 Delivered-To: freebsd-net@freebsd.org Received: from vinyl2.sentex.ca (vinyl2.sentex.ca [199.212.134.13]) by hub.freebsd.org (Postfix) with ESMTP id F2DCE37B421 for ; Tue, 18 Jun 2002 19:06:53 -0700 (PDT) Received: from house.sentex.net (cage.simianscience.com [64.7.134.1]) (authenticated bits=0) by vinyl2.sentex.ca (8.12.3/8.12.2) with ESMTP id g5J26pdc064840; Tue, 18 Jun 2002 22:06:51 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <5.1.0.14.0.20020618215923.03242f10@192.168.0.12> X-Sender: mdtancsa@192.168.0.12 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 18 Jun 2002 22:04:48 -0400 To: "Renaud Waldura" From: Mike Tancsa Subject: Re: tracking down strange MTU issues with PPPoE) Cc: In-Reply-To: <00c501c2171e$7538a720$011211ac@biohz.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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 Actually, in your documentation you mention that its broken for the situation where the FreeBSD box acts as a gateway. In my case, its broken right from the FreeBSD box. But the same machine connected with Windows 98 does not have the problem. ---Mike At 04:18 PM 6/18/2002 -0700, Renaud Waldura wrote: >Section 6.3 of the following document describes this issue in detail and may >help you solve it. > >http://renaud.waldura.com/doc/freebsd/pppoe/ > > > > >----- Original Message ----- >From: "Tom Samplonius" >To: "Mike Tancsa" >Cc: >Sent: Tuesday, June 18, 2002 3:09 PM >Subject: Re: tracking down strange MTU issues with PPPoE) > > > > > > Well, if you need to find the MTU, the ppp logs should tell you what the > > remote end is telling you to use. > > > > Usually, if you are having a MTU problem, it relates to fragmentation, > > MTU detection and ICMP filters. FreeBSD uses MTU detection by default. > > However, MTU detection requires that ICMP "can't fragment" messages be > > received, and some broken sites filter all ICMP. I know that the Redback > > has an "ignore don't fragment" feature. If this is enabled, it will > > fragment packets, it would normally throw away. This feature will break > > MTU detection too, but at least the end user won't notice, and packets > > will flow. > > > > > > Tom > > > > > > On Tue, 18 Jun 2002, Mike Tancsa wrote: > > > > > > > > The DSL whole supplier we use (Bell Canada) has been turfing their >Redback > > > SMSes and moving to an ERX from unisphere networks. > > > > > > With the Redback, all was great... I had a FreeBSD box acting as a NAT > > > gateway for a number of Windows boxes and all was great. Then, the > > > customer got moved over to one of these ERXes and there is now some >strange > > > MTU problem. Couple of things. Supposedly the default MTU on the ERX >is > > > 1472 (or 1452) depending on who you talk to and not 1492. > > > > > > e.g. when doing a fetch to > > > >> lynx2.8.4rel.1.tar.bz2 doesn't seem to exist in >/usr/ports/distfiles/. > > > >> Attempting to fetch from http://lynx.isc.org/current/. > > > Receiving lynx2.8.4rel.1.tar.bz2 (1940531 bytes): 0%^C > > > 16682 bytes transferred in 89.5 seconds (186.41 Bps) > > > fetch: transfer interrupted > > > > > > Notice the speed... Its totally brutal. yet, a transfer from just a few > > > hops away is fine. > > > > > > My question is, how can I track this problem down ? There seems to be >some > > > strange interaction with FreeBSD because if I put a Windows box on the > > > other end, it does not suffer from this same problem. I can easily >repeat > > > the problem, but the question is, how can I track down the issue and >then > > > explain it to my telco. -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 18 21:11:19 2002 Delivered-To: freebsd-net@freebsd.org Received: from vinyl2.sentex.ca (vinyl2.sentex.ca [199.212.134.13]) by hub.freebsd.org (Postfix) with ESMTP id B84E137B40A for ; Tue, 18 Jun 2002 21:11:10 -0700 (PDT) Received: from house.sentex.net (cage.simianscience.com [64.7.134.1]) (authenticated bits=0) by vinyl2.sentex.ca (8.12.3/8.12.2) with ESMTP id g5J4B5dc068986; Wed, 19 Jun 2002 00:11:05 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <5.1.0.14.0.20020618232129.0639eef8@192.168.0.12> X-Sender: mdtancsa@192.168.0.12 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 18 Jun 2002 23:32:12 -0400 To: "Renaud Waldura" From: Mike Tancsa Subject: Re: tracking down strange MTU issues with PPPoE) Cc: In-Reply-To: <00c501c2171e$7538a720$011211ac@biohz.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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 Looking at the TCPDump, to a host that works, I see iscar# tcpdump -n -i tun0 'tcp[13] & 2 != 0' tcpdump: listening on tun0 23:21:37.506516 64.7.134.131.1029 > 199.212.134.1.80: S 3285534554:3285534554(0) win 57344 (DF) 23:21:37.528294 199.212.134.1.80 > 64.7.134.131.1029: S 2139469875:2139469875(0) ack 3285534555 win 65535 If I let this transfer go, I will see a good megabit + speeds. But to the host below (and from a non pppoe connection on the other side, I get a good 5Mb/s), I see the following 23:21:45.400445 64.7.134.131.1030 > 204.152.184.112.80: S 1898183196:1898183196(0) win 57344 (DF) 23:21:45.498440 204.152.184.112.80 > 64.7.134.131.1030: S 1924929184:1924929184(0) ack 1898183197 win 61440 and the speed is a few hundred bytes /s But, when I do the same from my connection at home, I see the same sorts of flags and speeds are as expected ---Mike At 04:18 PM 6/18/2002 -0700, Renaud Waldura wrote: >Section 6.3 of the following document describes this issue in detail and may >help you solve it. > >http://renaud.waldura.com/doc/freebsd/pppoe/ > > > > >----- Original Message ----- >From: "Tom Samplonius" >To: "Mike Tancsa" >Cc: >Sent: Tuesday, June 18, 2002 3:09 PM >Subject: Re: tracking down strange MTU issues with PPPoE) > > > > > > Well, if you need to find the MTU, the ppp logs should tell you what the > > remote end is telling you to use. > > > > Usually, if you are having a MTU problem, it relates to fragmentation, > > MTU detection and ICMP filters. FreeBSD uses MTU detection by default. > > However, MTU detection requires that ICMP "can't fragment" messages be > > received, and some broken sites filter all ICMP. I know that the Redback > > has an "ignore don't fragment" feature. If this is enabled, it will > > fragment packets, it would normally throw away. This feature will break > > MTU detection too, but at least the end user won't notice, and packets > > will flow. > > > > > > Tom > > > > > > On Tue, 18 Jun 2002, Mike Tancsa wrote: > > > > > > > > The DSL whole supplier we use (Bell Canada) has been turfing their >Redback > > > SMSes and moving to an ERX from unisphere networks. > > > > > > With the Redback, all was great... I had a FreeBSD box acting as a NAT > > > gateway for a number of Windows boxes and all was great. Then, the > > > customer got moved over to one of these ERXes and there is now some >strange > > > MTU problem. Couple of things. Supposedly the default MTU on the ERX >is > > > 1472 (or 1452) depending on who you talk to and not 1492. > > > > > > e.g. when doing a fetch to > > > >> lynx2.8.4rel.1.tar.bz2 doesn't seem to exist in >/usr/ports/distfiles/. > > > >> Attempting to fetch from http://lynx.isc.org/current/. > > > Receiving lynx2.8.4rel.1.tar.bz2 (1940531 bytes): 0%^C > > > 16682 bytes transferred in 89.5 seconds (186.41 Bps) > > > fetch: transfer interrupted > > > > > > Notice the speed... Its totally brutal. yet, a transfer from just a few > > > hops away is fine. > > > > > > My question is, how can I track this problem down ? There seems to be >some > > > strange interaction with FreeBSD because if I put a Windows box on the > > > other end, it does not suffer from this same problem. I can easily >repeat > > > the problem, but the question is, how can I track down the issue and >then > > > explain it to my telco. -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 18 21:36:46 2002 Delivered-To: freebsd-net@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id D470F37B400; Tue, 18 Jun 2002 21:36:36 -0700 (PDT) Received: (from ken@localhost) by panzer.kdm.org (8.11.6/8.9.1) id g5J4aaZ98387; Tue, 18 Jun 2002 22:36:36 -0600 (MDT) (envelope-from ken) Date: Tue, 18 Jun 2002 22:36:36 -0600 From: "Kenneth D. Merry" To: current@FreeBSD.org Cc: net@FreeBSD.org Subject: new zero copy sockets snapshot Message-ID: <20020618223635.A98350@panzer.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.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 I've released a new zero copy sockets snapshot, against -current from June 18th, 2002. http://people.FreeBSD.org/~ken/zero_copy The fixes that went into this snapshot: - Take mutex locking out of ti_attach(), it isn't really needed. As long as we can assume that probes of successive ti(4) instances happen sequentially, we'll be safe in doing this. Thanks to John Baldwin for pointing out the solution to that problem. (The lock in ti_attach() was causing all sorts of WITNESS warnings when bus_setup_intr() was called.) - Added a new routine, vm_object_allocate_wait(). This is a variant of vm_object_allocate() that allows the user to specify whether the uma_zalloc() call inside vm_object_allocate_wait() is called with M_WAITOK or M_NOWAIT. This eliminates a WITNESS warning caused when jumbo_vm_init() calls vm_object_allocate() with the jumbo lock held, and potentially gives other callers the option of eliminating the mandatory wait on the uma_zalloc() call. (vm_object_allocate() now just calls vm_object_allocate_wait() with the proper argument.) With those fixes, plus several fixes that have gone into -current over the past week or so, the zero copy sockets code runs without any WITNESS warnings at all now. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 18 21:43:25 2002 Delivered-To: freebsd-net@freebsd.org Received: from angelica.unixdaemons.com (angelica.unixdaemons.com [209.148.64.135]) by hub.freebsd.org (Postfix) with ESMTP id 879B437B410; Tue, 18 Jun 2002 21:43:19 -0700 (PDT) Received: from angelica.unixdaemons.com (bmilekic@localhost.unixdaemons.com [127.0.0.1]) by angelica.unixdaemons.com (8.12.4/8.12.1) with ESMTP id g5J4hEXU030242; Wed, 19 Jun 2002 00:43:14 -0400 (EDT) X-Authentication-Warning: angelica.unixdaemons.com: Host bmilekic@localhost.unixdaemons.com [127.0.0.1] claimed to be angelica.unixdaemons.com Received: (from bmilekic@localhost) by angelica.unixdaemons.com (8.12.4/8.12.1/Submit) id g5J4hDBt030241; Wed, 19 Jun 2002 00:43:13 -0400 (EDT) (envelope-from bmilekic) Date: Wed, 19 Jun 2002 00:43:13 -0400 From: Bosko Milekic To: "Kenneth D. Merry" Cc: current@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: new zero copy sockets snapshot Message-ID: <20020619004313.A29911@unixdaemons.com> References: <20020618223635.A98350@panzer.kdm.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: <20020618223635.A98350@panzer.kdm.org>; from ken@kdm.org on Tue, Jun 18, 2002 at 10:36:36PM -0600 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, Jun 18, 2002 at 10:36:36PM -0600, Kenneth D. Merry wrote: > > I've released a new zero copy sockets snapshot, against -current from June > 18th, 2002. > > http://people.FreeBSD.org/~ken/zero_copy > > The fixes that went into this snapshot: > > - Take mutex locking out of ti_attach(), it isn't really needed. > As long as we can assume that probes of successive ti(4) instances > happen sequentially, we'll be safe in doing this. Thanks to John > Baldwin for pointing out the solution to that problem. (The lock in > ti_attach() was causing all sorts of WITNESS warnings when > bus_setup_intr() was called.) > > - Added a new routine, vm_object_allocate_wait(). This is a variant of > vm_object_allocate() that allows the user to specify whether the > uma_zalloc() call inside vm_object_allocate_wait() is called with > M_WAITOK or M_NOWAIT. This eliminates a WITNESS warning caused when > jumbo_vm_init() calls vm_object_allocate() with the jumbo lock held, and > potentially gives other callers the option of eliminating the mandatory > wait on the uma_zalloc() call. I think this problem was fixed in recent -CURRENT by JeffR. Notably, the VM system should not allow itself to recurse on itself when called with M_NOWAIT. > (vm_object_allocate() now just calls vm_object_allocate_wait() with the > proper argument.) > > With those fixes, plus several fixes that have gone into -current over the > past week or so, the zero copy sockets code runs without any WITNESS > warnings at all now. > > Ken > -- > Kenneth Merry > ken@kdm.org > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > -- Bosko Milekic bmilekic@unixdaemons.com bmilekic@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 18 22: 7: 9 2002 Delivered-To: freebsd-net@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id CA20C37B415; Tue, 18 Jun 2002 22:06:45 -0700 (PDT) Received: (from ken@localhost) by panzer.kdm.org (8.11.6/8.9.1) id g5J56YP98626; Tue, 18 Jun 2002 23:06:34 -0600 (MDT) (envelope-from ken) Date: Tue, 18 Jun 2002 23:06:34 -0600 From: "Kenneth D. Merry" To: Bosko Milekic Cc: current@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: new zero copy sockets snapshot Message-ID: <20020618230634.A98564@panzer.kdm.org> References: <20020618223635.A98350@panzer.kdm.org> <20020619004313.A29911@unixdaemons.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020619004313.A29911@unixdaemons.com>; from bmilekic@unixdaemons.com on Wed, Jun 19, 2002 at 12:43:13AM -0400 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 Wed, Jun 19, 2002 at 00:43:13 -0400, Bosko Milekic wrote: > On Tue, Jun 18, 2002 at 10:36:36PM -0600, Kenneth D. Merry wrote: > > > > I've released a new zero copy sockets snapshot, against -current from June > > 18th, 2002. > > > > http://people.FreeBSD.org/~ken/zero_copy > > > > The fixes that went into this snapshot: > > > > - Take mutex locking out of ti_attach(), it isn't really needed. > > As long as we can assume that probes of successive ti(4) instances > > happen sequentially, we'll be safe in doing this. Thanks to John > > Baldwin for pointing out the solution to that problem. (The lock in > > ti_attach() was causing all sorts of WITNESS warnings when > > bus_setup_intr() was called.) > > > > - Added a new routine, vm_object_allocate_wait(). This is a variant of > > vm_object_allocate() that allows the user to specify whether the > > uma_zalloc() call inside vm_object_allocate_wait() is called with > > M_WAITOK or M_NOWAIT. This eliminates a WITNESS warning caused when > > jumbo_vm_init() calls vm_object_allocate() with the jumbo lock held, and > > potentially gives other callers the option of eliminating the mandatory > > wait on the uma_zalloc() call. > > I think this problem was fixed in recent -CURRENT by JeffR. Notably, > the VM system should not allow itself to recurse on itself when called > with M_NOWAIT. A number of problems have been fixed, but I don't think this one would get fixed by internal VM system changes: vm_object_t vm_object_allocate(objtype_t type, vm_size_t size) { vm_object_t result; result = (vm_object_t) uma_zalloc(obj_zone, M_WAITOK); _vm_object_allocate(type, size, result); return (result); } uma_zalloc() is called with M_WAITOK unconditionally. My solution: vm_object_t vm_object_allocate_wait(objtype_t type, vm_size_t size, int flags) { vm_object_t result; result = (vm_object_t) uma_zalloc(obj_zone, flags); if (result != NULL) _vm_object_allocate(type, size, result); return (result); } vm_object_allocate() is implemented by calling vm_object_allocate_wait() with M_WAITOK. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 18 22:45:28 2002 Delivered-To: freebsd-net@freebsd.org Received: from tp.databus.com (p72-186.acedsl.com [66.114.72.186]) by hub.freebsd.org (Postfix) with ESMTP id 204BA37B400 for ; Tue, 18 Jun 2002 22:45:21 -0700 (PDT) Received: from databus.com (localhost.databus.com [127.0.0.1]) by tp.databus.com (8.12.3/8.12.3) with ESMTP id g5J5jKGC020184; Wed, 19 Jun 2002 01:45:20 -0400 (EDT) (envelope-from barney@databus.com) Received: (from barney@localhost) by databus.com (8.12.3/8.12.3/Submit) id g5J5jJFw020183; Wed, 19 Jun 2002 01:45:19 -0400 (EDT) Date: Wed, 19 Jun 2002 01:45:19 -0400 From: Barney Wolff To: Mike Tancsa Cc: Renaud Waldura , freebsd-net@FreeBSD.ORG Subject: Re: tracking down strange MTU issues with PPPoE) Message-ID: <20020619014519.A20138@tp.databus.com> References: <00c501c2171e$7538a720$011211ac@biohz.net> <5.1.0.14.0.20020618232129.0639eef8@192.168.0.12> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <5.1.0.14.0.20020618232129.0639eef8@192.168.0.12>; from mike@sentex.net on Tue, Jun 18, 2002 at 11:32:12PM -0400 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 There's something odd here - MSS does not include headers, and is 1460 on a straight ethernet connection. So your MSS of 1452 equates to an MTU of 1492. I'd try setting MTU (or MSS) way down, to 1024. If that works, you can do a binary search to find the max working value. You haven't shown enough of the dump to see if DF is set in packets from either the working or non-working host, or to see just how big the packets are. On Tue, Jun 18, 2002 at 11:32:12PM -0400, Mike Tancsa wrote: > > Looking at the TCPDump, to a host that works, I see > > iscar# tcpdump -n -i tun0 'tcp[13] & 2 != 0' > tcpdump: listening on tun0 > 23:21:37.506516 64.7.134.131.1029 > 199.212.134.1.80: S > 3285534554:3285534554(0) win 57344 59058 0> (DF) > 23:21:37.528294 199.212.134.1.80 > 64.7.134.131.1029: S > 2139469875:2139469875(0) ack 3285534555 win 65535 1,nop,nop,timestamp 67282456 59058> > > If I let this transfer go, I will see a good megabit + speeds. > > But to the host below (and from a non pppoe connection on the other side, I > get a good 5Mb/s), I see the following > > 23:21:45.400445 64.7.134.131.1030 > 204.152.184.112.80: S > 1898183196:1898183196(0) win 57344 59847 0> (DF) > 23:21:45.498440 204.152.184.112.80 > 64.7.134.131.1030: S > 1924929184:1924929184(0) ack 1898183197 win 61440 > > and the speed is a few hundred bytes /s > > But, when I do the same from my connection at home, I see the same sorts of > flags and speeds are as expected > > > > > > ---Mike > > > > At 04:18 PM 6/18/2002 -0700, Renaud Waldura wrote: > >Section 6.3 of the following document describes this issue in detail and may > >help you solve it. > > > >http://renaud.waldura.com/doc/freebsd/pppoe/ > > > > > > > > > >----- Original Message ----- > >From: "Tom Samplonius" > >To: "Mike Tancsa" > >Cc: > >Sent: Tuesday, June 18, 2002 3:09 PM > >Subject: Re: tracking down strange MTU issues with PPPoE) > > > > > > > > > > Well, if you need to find the MTU, the ppp logs should tell you what the > > > remote end is telling you to use. > > > > > > Usually, if you are having a MTU problem, it relates to fragmentation, > > > MTU detection and ICMP filters. FreeBSD uses MTU detection by default. > > > However, MTU detection requires that ICMP "can't fragment" messages be > > > received, and some broken sites filter all ICMP. I know that the Redback > > > has an "ignore don't fragment" feature. If this is enabled, it will > > > fragment packets, it would normally throw away. This feature will break > > > MTU detection too, but at least the end user won't notice, and packets > > > will flow. > > > > > > > > > Tom > > > > > > > > > On Tue, 18 Jun 2002, Mike Tancsa wrote: > > > > > > > > > > > The DSL whole supplier we use (Bell Canada) has been turfing their > >Redback > > > > SMSes and moving to an ERX from unisphere networks. > > > > > > > > With the Redback, all was great... I had a FreeBSD box acting as a NAT > > > > gateway for a number of Windows boxes and all was great. Then, the > > > > customer got moved over to one of these ERXes and there is now some > >strange > > > > MTU problem. Couple of things. Supposedly the default MTU on the ERX > >is > > > > 1472 (or 1452) depending on who you talk to and not 1492. > > > > > > > > e.g. when doing a fetch to > > > > >> lynx2.8.4rel.1.tar.bz2 doesn't seem to exist in > >/usr/ports/distfiles/. > > > > >> Attempting to fetch from http://lynx.isc.org/current/. > > > > Receiving lynx2.8.4rel.1.tar.bz2 (1940531 bytes): 0%^C > > > > 16682 bytes transferred in 89.5 seconds (186.41 Bps) > > > > fetch: transfer interrupted > > > > > > > > Notice the speed... Its totally brutal. yet, a transfer from just a few > > > > hops away is fine. > > > > > > > > My question is, how can I track this problem down ? There seems to be > >some > > > > strange interaction with FreeBSD because if I put a Windows box on the > > > > other end, it does not suffer from this same problem. I can easily > >repeat > > > > the problem, but the question is, how can I track down the issue and > >then > > > > explain it to my telco. > > -------------------------------------------------------------------- > Mike Tancsa, tel +1 519 651 3400 > Sentex Communications, mike@sentex.net > Providing Internet since 1994 www.sentex.net > Cambridge, Ontario Canada www.sentex.net/mike > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message -- Barney Wolff I never met a computer I didn't like. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 18 22:54:34 2002 Delivered-To: freebsd-net@freebsd.org Received: from hawk.dcu.ie (mail.dcu.ie [136.206.1.5]) by hub.freebsd.org (Postfix) with ESMTP id 6209237B407 for ; Tue, 18 Jun 2002 22:54:29 -0700 (PDT) Received: from prodigy.redbrick.dcu.ie (136.206.15.10) by hawk.dcu.ie (6.0.040) id 3CC55D790018BCC1 for freebsd-net@FreeBSD.ORG; Wed, 19 Jun 2002 06:54:28 +0100 Received: by prodigy.redbrick.dcu.ie (Postfix, from userid 2027) id 1FBC0DA4B; Wed, 19 Jun 2002 06:54:28 +0100 (IST) Date: Wed, 19 Jun 2002 06:54:27 +0100 From: Colin Whittaker To: freebsd-net@FreeBSD.ORG Subject: Re: bge driver issue Message-ID: <20020619065427.A13331@prodigy.Redbrick.DCU.IE> References: <20020618183306.A1796@prodigy.Redbrick.DCU.IE> <20020618103723.A7817@Odin.AC.HMC.Edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Mutt/1.2.5i In-Reply-To: <20020618103723.A7817@Odin.AC.HMC.Edu>; from brooks@one-eyed-alien.net on Tue, Jun 18, 2002 at 10:37:23AM -0700 Organization: North East Technologies Ltd. X-subliminal-message: Give Colin all your money. 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 Brooks Davis stated the following on Tue, Jun 18, 2002 at 10:37:23AM -0700 : > On Tue, Jun 18, 2002 at 06:33:06PM +0100, Colin Whittaker wrote: > > I have a dell poweredge 2550 with which I am having all sorts of > > nasty network problems. > > The network interface will just stop responding. > > I get an error message like this: > > Jun 18 08:19:38 shekondar /kernel: bge0: watchdog timeout -- resetting >=20 > You don't say what version of FreeBSD you are running. There were a > number of changes made to the bge driver a month or so ago which are > supposed to help with some problems. If you are running 4.5-RELEASE you > will certaintly have trouble. Sorry uname -a says: FreeBSD shekondar.heanet.ie 4.6-RC FreeBSD 4.6-RC #0: Fri May 24 15:48:31 I= ST 2002 =20 I have seen this happen with the fxp interface as well and I have seen this mail http://docs.freebsd.org/cgi/getmsg.cgi?fetch=3D22093+0+current/freebsd-isp which leads me to believe that switching to using the intel pro1000 car don the box will do me no good either. Colin --=20 "Design" is like a religion - too much of it makes you inflexibly and unpop= ular. Linus Torvalds To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 18 23:47:10 2002 Delivered-To: freebsd-net@freebsd.org Received: from mel-rto4.wanadoo.fr (smtp-out-4.wanadoo.fr [193.252.19.23]) by hub.freebsd.org (Postfix) with ESMTP id 2175337B407 for ; Tue, 18 Jun 2002 23:47:03 -0700 (PDT) Received: from mel-rta8.wanadoo.fr (193.252.19.79) by mel-rto4.wanadoo.fr (6.5.007) id 3D09BE8D002AED91; Wed, 19 Jun 2002 08:46:58 +0200 Received: from localhost (193.253.211.159) by mel-rta8.wanadoo.fr (6.5.007) id 3CFB23D900946CC3; Wed, 19 Jun 2002 08:46:58 +0200 Date: Wed, 19 Jun 2002 08:46:43 +0200 From: Fabien THOMAS X-Mailer: The Bat! (v1.60c) Reply-To: Fabien THOMAS X-Priority: 3 (Normal) Message-ID: <15175218220.20020619084643@wanadoo.fr> To: paleph@pacbell.net Cc: freebsd-net@freebsd.org Subject: Re[2]: bge driver issue In-Reply-To: <200206182206.g5IM6P003388@pacbell.net> References: <200206182206.g5IM6P003388@pacbell.net> 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 I've the same problems and i fixed partially the problem by bumping the return ring count. #define BGE_RETURN_RING_CNT 1024 -> #define BGE_RETURN_RING_CNT 2048 i dont think it is THE solution but it works better than before for me... ppn> We have a Dell poweredge 2650 (successor to 2550). ppn> We also saw the same problem with 4.5. I tried the current bge driver from 4.6 ppn> without success. The problem seems to be a size problem. When we ftp a small ppn> file, things work fine. However, when we try a 18 Megabyte file, the ftp ppn> hands and we see the problem descriped below. The linux system that came ppn> with the hardware (from dell) worked fine. ppn> BTW. This was occuring with a 100 Mbit link. ppn> I have not been able to get any resolution on this. The only replies seem to ppn> indicate that something is seriously broken with the bge driver. ppn> Paul Fronberg ppn> paleph@pacbell.net >> I have a dell poweredge 2550 with which I am having all sorts of >> nasty network problems. >> The network interface will just stop responding. >> I get an error message like this: >> Jun 18 08:19:38 shekondar /kernel: bge0: watchdog timeout -- resetting >> >> This is using the broadcom 10/100/1000 NIC on the mother board, the >> intel 10/100 has had similar issues but produces no log messages. >> >> duplex and speed settings are forced on both the card and the switch. >> sometimes the kernel reset will clear the fault but sometimes you >> need to ifconfig down / up the interface to get it going again. >> >> This box has been running fine for several weeks, it is only as we have >> started to shift to production levels of traffic to it that it has started >> this. Approx 30M bits/sec out and 12M bits/sec inbound. >> >> There was a simple ipfw ruleset on the box but I have disable that >> just now to see if it helps. >> >> >> Googleing has given me people who report similar problems but no >> solutions / work arounds. >> >> Have anyone got any suggestions as to what to do next. >> >> Colin >> >> Here is the output of postconf >> >> bge0@pci1:8:0: class=0x020000 card=0x00d11028 chip=0x164414e4 rev=0x12 >> hdr=0x00 vendor = 'Broadcom Corporation' >> device = 'BCM5700/1 Gigabit Ethernet Controller' >> class = network >> subclass = ethernet ppn> To Unsubscribe: send mail to majordomo@FreeBSD.org ppn> with "unsubscribe freebsd-net" in the body of the message -- Cordialement, Fabien mailto:fabien.thomas@netasq.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 19 0:49:59 2002 Delivered-To: freebsd-net@freebsd.org Received: from patrocles.silby.com (d182.as20.nwbl0.wi.voyager.net [169.207.139.184]) by hub.freebsd.org (Postfix) with ESMTP id 4756E37B409 for ; Wed, 19 Jun 2002 00:49:53 -0700 (PDT) Received: from patrocles.silby.com (localhost [127.0.0.1]) by patrocles.silby.com (8.12.4/8.12.4) with ESMTP id g5J7pacv024083; Wed, 19 Jun 2002 02:51:36 -0500 (CDT) (envelope-from silby@silby.com) Received: from localhost (silby@localhost) by patrocles.silby.com (8.12.4/8.12.4/Submit) with ESMTP id g5J7pLK2024080; Wed, 19 Jun 2002 02:51:36 -0500 (CDT) X-Authentication-Warning: patrocles.silby.com: silby owned process doing -bs Date: Wed, 19 Jun 2002 02:51:21 -0500 (CDT) From: Mike Silbersack To: ef90b7323131bdf05e Cc: freebsd-net@freebsd.org Subject: Re: How cwnd is set after a loss in FreeBSD TCP? In-Reply-To: <20020618102912.DAA3237B40D@hub.freebsd.org> Message-ID: <20020619024843.D23787-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, 18 Jun 2002, ef90b7323131bdf05e wrote: > My explanation to this is that the ssthresh is not exactly half of the cwnd after > detecting the loss. However, the explanation seems contradicts with RFC2581, which > say ssthresh must be no more than max( FlightSize /2, 2*SMSS). The behavior > puzzled me for a while. Is it a bug or just the right behavior? Can anyone help to > explain it? > > I have dump file the the figure of this behavior, if anyone want, I will email > it. > > ************************************** > Lu Guohan It's certainly possible that there's a bug. To explain the behavior, you'll probably have to wander around tcp_output.c a bit. When doing so, also take into consideration new reno (rfc 2582, I think.) If you find something that you believe is a definite problem, please post back to this list. I'd love to help, but I'm busy with other matters at the moment. 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 Wed Jun 19 0:56: 6 2002 Delivered-To: freebsd-net@freebsd.org Received: from proton.hexanet.fr (proton.hexanet.fr [81.23.32.33]) by hub.freebsd.org (Postfix) with ESMTP id D60F037B40B; Wed, 19 Jun 2002 00:55:51 -0700 (PDT) Received: from hexanet.fr (localhost [127.0.0.1]) by proton.hexanet.fr (8.12.3/8.12.3) with SMTP id g5J7tnfS006838; Wed, 19 Jun 2002 09:55:49 +0200 (CEST) (envelope-from c.prevotaux@hexanet.fr) Date: Wed, 19 Jun 2002 09:55:49 +0200 From: Christophe Prevotaux To: atm@freebsd.org Cc: net@freebsd.org Subject: hfa0 (PCA200E) Crashes Message-Id: <20020619095549.68ce15c5.c.prevotaux@hexanet.fr> Organization: HEXANET Sarl X-Mailer: Sylpheed version 0.7.4 (GTK+ 1.2.10; i386-portbld-freebsd4.4) X-NCC-RegID: fr.hexanet 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, I have been using a PCA200E in one of my router machines and apart from the driver having major bugs (as well as the HARP and the 'atm' command) I now get the hfa0 driver crashing , it just plainly stops working bringing the link down. I am at a loss, since I can't seem to be able to find out what is the problem. I am using an ASUS CU4VX Dual Proc motherboard with an lge Gigabit ethernet and a PCA200E card. All board have a separate IRQ. And I am using FreeBSD 4.5 I keep getting "lge0 up" messages in the in the logs, I don't quite understand what this means since the interface is always up (should be) but I don't get any messsages concerning the hfa0 atm interface. Would anyone know what to do ? or what could be the problem ? I think the ATM stack needs a major overall in STABLE. -- =============================================================== Christophe Prevotaux Email: c.prevotaux@hexanet.fr HEXANET SARL URL: http://www.hexanet.fr/ Z.A.C Les Charmilles Tel: +33 (0)3 26 79 30 05 3 Allée Thierry Sabine Direct: +33 (0)3 26 61 77 72 BP202 Fax: +33 (0)3 26 79 30 06 51686 Reims Cedex 2 FRANCE HEXANET Network Operation Center =============================================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 19 4: 0:50 2002 Delivered-To: freebsd-net@freebsd.org Received: from viefep13-int.chello.at (viefep13-int.chello.at [213.46.255.15]) by hub.freebsd.org (Postfix) with ESMTP id 30E4937B405 for ; Wed, 19 Jun 2002 04:00:43 -0700 (PDT) Received: from www.wsf.at ([212.186.91.40]) by viefep13-int.chello.at (InterMail vM.5.01.03.06 201-253-122-118-106-20010523) with SMTP id <20020619105957.KDZO9315.viefep13-int.chello.at@www.wsf.at> for ; Wed, 19 Jun 2002 12:59:57 +0200 subject: natd punch_fw for passive ftp ? Message-Id: <20020619105957.KDZO9315.viefep13-int.chello.at@www.wsf.at> Date: Wed, 19 Jun 2002 13:00:41 +0200 From: net@wsf.at To: undisclosed-recipients:; 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 there, (I hope this is the right list) I am in doubt about my understanding of the punch_fw option in natd, running on the client side: Should this option create temporary rules for passive ftp or not ? If it should - it does not (at least not on my 4.5-RELEASE box) If it should not - is there a reason for this difference compared to active mode ? What I try to setup is a ipfw-ruleset for strictly checking the flow between several interfaces. So I allow established traffic and only SYN packets to specfied ports, based on recv/xmit interface. As usual, ftp causes the biggest problems. Active ftp works fine using punch_fw but passive mode would require to open all high ports for outgoing SYN - exactly what I try to avoid. Any hints are welcome, Thanks Thomas To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 19 5:27:12 2002 Delivered-To: freebsd-net@freebsd.org Received: from vinyl2.sentex.ca (vinyl2.sentex.ca [199.212.134.13]) by hub.freebsd.org (Postfix) with ESMTP id 7429537B407 for ; Wed, 19 Jun 2002 05:27:02 -0700 (PDT) Received: from house.sentex.net (cage.simianscience.com [64.7.134.1]) (authenticated bits=0) by vinyl2.sentex.ca (8.12.3/8.12.2) with ESMTP id g5JCQxdc084705; Wed, 19 Jun 2002 08:26:59 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <5.1.0.14.0.20020619082306.059ac010@192.168.0.12> X-Sender: mdtancsa@192.168.0.12 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 19 Jun 2002 08:24:58 -0400 To: Barney Wolff From: Mike Tancsa Subject: Re: tracking down strange MTU issues with PPPoE) Cc: Renaud Waldura , freebsd-net@FreeBSD.ORG In-Reply-To: <20020619014519.A20138@tp.databus.com> References: <5.1.0.14.0.20020618232129.0639eef8@192.168.0.12> <00c501c2171e$7538a720$011211ac@biohz.net> <5.1.0.14.0.20020618232129.0639eef8@192.168.0.12> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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 At 01:45 AM 6/19/2002 -0400, Barney Wolff wrote: >There's something odd here - MSS does not include headers, and is 1460 >on a straight ethernet connection. So your MSS of 1452 equates to an >MTU of 1492. > >I'd try setting MTU (or MSS) way down, to 1024. Hi, I tried going way down to 512 and 576 and with the same results :-( >You haven't shown enough of the dump to see if DF is set in packets from >either the working or non-working host, or to see just how big the packets >are. What flags should I use to provide the necessary info ? Unfortunately at this level my knowledge is rather tenuous :( ---Mike >On Tue, Jun 18, 2002 at 11:32:12PM -0400, Mike Tancsa wrote: > > > > Looking at the TCPDump, to a host that works, I see > > > > iscar# tcpdump -n -i tun0 'tcp[13] & 2 != 0' > > tcpdump: listening on tun0 > > 23:21:37.506516 64.7.134.131.1029 > 199.212.134.1.80: S > > 3285534554:3285534554(0) win 57344 0,nop,nop,timestamp > > 59058 0> (DF) > > 23:21:37.528294 199.212.134.1.80 > 64.7.134.131.1029: S > > 2139469875:2139469875(0) ack 3285534555 win 65535 > 1,nop,nop,timestamp 67282456 59058> > > > > If I let this transfer go, I will see a good megabit + speeds. > > > > But to the host below (and from a non pppoe connection on the other > side, I > > get a good 5Mb/s), I see the following > > > > 23:21:45.400445 64.7.134.131.1030 > 204.152.184.112.80: S > > 1898183196:1898183196(0) win 57344 0,nop,nop,timestamp > > 59847 0> (DF) > > 23:21:45.498440 204.152.184.112.80 > 64.7.134.131.1030: S > > 1924929184:1924929184(0) ack 1898183197 win 61440 > > > > and the speed is a few hundred bytes /s > > > > But, when I do the same from my connection at home, I see the same > sorts of > > flags and speeds are as expected > > > > > > > > > > > > ---Mike > > > > > > > > At 04:18 PM 6/18/2002 -0700, Renaud Waldura wrote: > > >Section 6.3 of the following document describes this issue in detail > and may > > >help you solve it. > > > > > >http://renaud.waldura.com/doc/freebsd/pppoe/ > > > > > > > > > > > > > > >----- Original Message ----- > > >From: "Tom Samplonius" > > >To: "Mike Tancsa" > > >Cc: > > >Sent: Tuesday, June 18, 2002 3:09 PM > > >Subject: Re: tracking down strange MTU issues with PPPoE) > > > > > > > > > > > > > > Well, if you need to find the MTU, the ppp logs should tell you > what the > > > > remote end is telling you to use. > > > > > > > > Usually, if you are having a MTU problem, it relates to > fragmentation, > > > > MTU detection and ICMP filters. FreeBSD uses MTU detection by default. > > > > However, MTU detection requires that ICMP "can't fragment" messages be > > > > received, and some broken sites filter all ICMP. I know that the > Redback > > > > has an "ignore don't fragment" feature. If this is enabled, it will > > > > fragment packets, it would normally throw away. This feature will > break > > > > MTU detection too, but at least the end user won't notice, and packets > > > > will flow. > > > > > > > > > > > > Tom > > > > > > > > > > > > On Tue, 18 Jun 2002, Mike Tancsa wrote: > > > > > > > > > > > > > > The DSL whole supplier we use (Bell Canada) has been turfing their > > >Redback > > > > > SMSes and moving to an ERX from unisphere networks. > > > > > > > > > > With the Redback, all was great... I had a FreeBSD box acting as > a NAT > > > > > gateway for a number of Windows boxes and all was great. Then, the > > > > > customer got moved over to one of these ERXes and there is now some > > >strange > > > > > MTU problem. Couple of things. Supposedly the default MTU on > the ERX > > >is > > > > > 1472 (or 1452) depending on who you talk to and not 1492. > > > > > > > > > > e.g. when doing a fetch to > > > > > >> lynx2.8.4rel.1.tar.bz2 doesn't seem to exist in > > >/usr/ports/distfiles/. > > > > > >> Attempting to fetch from http://lynx.isc.org/current/. > > > > > Receiving lynx2.8.4rel.1.tar.bz2 (1940531 bytes): 0%^C > > > > > 16682 bytes transferred in 89.5 seconds (186.41 Bps) > > > > > fetch: transfer interrupted > > > > > > > > > > Notice the speed... Its totally brutal. yet, a transfer from just > a few > > > > > hops away is fine. > > > > > > > > > > My question is, how can I track this problem down ? There seems > to be > > >some > > > > > strange interaction with FreeBSD because if I put a Windows box > on the > > > > > other end, it does not suffer from this same problem. I can easily > > >repeat > > > > > the problem, but the question is, how can I track down the issue and > > >then > > > > > explain it to my telco. > > > > -------------------------------------------------------------------- > > Mike Tancsa, tel +1 519 651 3400 > > Sentex Communications, mike@sentex.net > > Providing Internet since 1994 www.sentex.net > > Cambridge, Ontario Canada www.sentex.net/mike > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-net" in the body of the message > >-- >Barney Wolff >I never met a computer I didn't like. -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 19 6:55:32 2002 Delivered-To: freebsd-net@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 2CDB837B405; Wed, 19 Jun 2002 06:55:21 -0700 (PDT) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 2155D5361; Wed, 19 Jun 2002 15:55:19 +0200 (CEST) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: "Kenneth D. Merry" Cc: current@FreeBSD.org, net@FreeBSD.org Subject: Re: new zero copy sockets snapshot References: <20020618223635.A98350@panzer.kdm.org> From: Dag-Erling Smorgrav Date: 19 Jun 2002 15:55:18 +0200 In-Reply-To: <20020618223635.A98350@panzer.kdm.org> Message-ID: Lines: 10 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.2 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 "Kenneth D. Merry" writes: > With those fixes, plus several fixes that have gone into -current over the > past week or so, the zero copy sockets code runs without any WITNESS > warnings at all now. Planning to commit soon? DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 19 8: 1: 9 2002 Delivered-To: freebsd-net@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 0D8A537B40C; Wed, 19 Jun 2002 08:00:55 -0700 (PDT) Received: (from ken@localhost) by panzer.kdm.org (8.11.6/8.9.1) id g5JF0kH02081; Wed, 19 Jun 2002 09:00:46 -0600 (MDT) (envelope-from ken) Date: Wed, 19 Jun 2002 09:00:46 -0600 From: "Kenneth D. Merry" To: Dag-Erling Smorgrav Cc: current@FreeBSD.org, net@FreeBSD.org Subject: Re: new zero copy sockets snapshot Message-ID: <20020619090046.A2063@panzer.kdm.org> References: <20020618223635.A98350@panzer.kdm.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: ; from des@ofug.org on Wed, Jun 19, 2002 at 03:55:18PM +0200 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 Wed, Jun 19, 2002 at 15:55:18 +0200, Dag-Erling Smorgrav wrote: > "Kenneth D. Merry" writes: > > With those fixes, plus several fixes that have gone into -current over the > > past week or so, the zero copy sockets code runs without any WITNESS > > warnings at all now. > > Planning to commit soon? That's the plan. I need to see if any comments come up, and then make sure I'll be in town for a few days at least to handle any problems that come up. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 19 9: 9:20 2002 Delivered-To: freebsd-net@freebsd.org Received: from tesla.distributel.net (nat.MTL.distributel.NET [66.38.181.24]) by hub.freebsd.org (Postfix) with ESMTP id 1856637B404; Wed, 19 Jun 2002 09:09:10 -0700 (PDT) Received: (from bmilekic@localhost) by tesla.distributel.net (8.11.6/8.11.6) id g5JG6fR18603; Wed, 19 Jun 2002 12:06:41 -0400 (EDT) (envelope-from bmilekic@unixdaemons.com) Date: Wed, 19 Jun 2002 12:06:41 -0400 From: Bosko Milekic To: "Kenneth D. Merry" Cc: Dag-Erling Smorgrav , current@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: new zero copy sockets snapshot Message-ID: <20020619120641.A18434@unixdaemons.com> References: <20020618223635.A98350@panzer.kdm.org> <20020619090046.A2063@panzer.kdm.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: <20020619090046.A2063@panzer.kdm.org>; from ken@kdm.org on Wed, Jun 19, 2002 at 09:00:46AM -0600 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 Wed, Jun 19, 2002 at 09:00:46AM -0600, Kenneth D. Merry wrote: > On Wed, Jun 19, 2002 at 15:55:18 +0200, Dag-Erling Smorgrav wrote: > > "Kenneth D. Merry" writes: > > > With those fixes, plus several fixes that have gone into -current over the > > > past week or so, the zero copy sockets code runs without any WITNESS > > > warnings at all now. > > > > Planning to commit soon? > > That's the plan. I need to see if any comments come up, and then make sure > I'll be in town for a few days at least to handle any problems that come > up. I have a few comments and questions: - In uipc_jumbo.c, you appear to avoid using some of the SLIST macros, notably when grabbing something off the inuse or free lists. - Is the mutex really necessary in jumbo_vm_init()? I suspect that if you need to ensure mutual exclusion here, there's something wrong; (why would you be running the jumbo vm code before having initialized it?) - perhaps you could init the mtx at runtime in the jumbo_vm_init routine. - It's kind of unfortunate that uipc_jumbo.c has to roll its own allocator; There are a couple of alternatives; to just use UMA or mb_alloc for this sort of thing. mb_alloc will wire all pages allocated through it, though, so maybe it would be worth looking at what UMA can do in this respect. If it cannot do exactly what you're looking for, then modifying it to do what you want should be relatively simple. The added advantage is that you'll now be using per-CPU caches for allocations of jumbo bufs, and not the single freelist that you currently use. - I don't know anything about the if_ti code, but it sure looks like it's holding the ti mutex a long time in some places (not only in your patch). > Ken > -- > Kenneth Merry > ken@kdm.org Regards, -- Bosko Milekic bmilekic@unixdaemons.com bmilekic@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 19 9:44:53 2002 Delivered-To: freebsd-net@freebsd.org Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id DFC5C37B415; Wed, 19 Jun 2002 09:44:20 -0700 (PDT) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g5JGiK859140; Wed, 19 Jun 2002 09:44:20 -0700 (PDT) (envelope-from rizzo) Date: Wed, 19 Jun 2002 09:44:20 -0700 From: Luigi Rizzo To: julian@freebsd.org Cc: net@freebsd.org Subject: removing global variables from the network stack Message-ID: <20020619094420.C58636@iguana.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.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 Hi, I am trying to cleanup as much as possible the use of global variables in the network stack, both for code clarity, and to ease the use of this code in an SMP context. The two offenders I am concentrating upon are IPFW/DUMMYNET and DIVERT. For the former, I am the guilty one:) I know how to fix it. For DIVERT, I think this is someone else's code, so here's my understanding of the problem and proposed fix: The global variable in question is "ip_divert_cookie", declared in ip_divert.c and used to pass the divert port to divert_packet(), and from div_output() to ip_output()/ip_input() For the former the fix is trivial, we just need to add an additional argument to divert_packet(). For the latter, it *would* be easy to add an argument to ip_output() but if we do not want to change the interface, perhaps the easiest trick is to pass the annotation in the same way as it is done for dummynet info, i.e. using a fake mbuf prepended to the actual chain. Something like this: ip_divert.c::div_output() ... make ip_divert_cookie a local variable ... struct m_hdr fake_mbuf; fake_mbuf.mh_type = MT_DIVERT; fake_mbuf.mh_next = m; fake_mbuf.mh_len = ip_divert_cookie; ... if ( ) { error = ip_output(&fake_mbuf, ...); ... } else { /* incoming packet */ ... ip_input(&fake_mbuf); } ip_output.c::ip_output() ip_output.c::ip_input() ... right after local variables instead of fetching ip_divert_cookie if (m->m_type == MT_DIVERT) { divert_cookie = m->mh_len; m = m->mh_next; } ... continue with regular processing ... Does this look right ? As a matter of fact, ip_input() is used only in a couple of places so it might be possible to change the interface and add a second parameter to carry the divert_cookie. However the use of an annotation block in front of it seems a bit less intrusive and easier to extend to other annotations we might want to add. cheers luigi -----------------------------------+------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) Mobile +39-347-0373137 -----------------------------------+------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 19 11:31: 5 2002 Delivered-To: freebsd-net@freebsd.org Received: from Awfulhak.org (gw.Awfulhak.org [217.204.245.18]) by hub.freebsd.org (Postfix) with ESMTP id 6447D37B407 for ; Wed, 19 Jun 2002 11:30:54 -0700 (PDT) Received: from mail.lan.Awfulhak.org (brian@hak.Awfulhak.org [IPv6:2001:6f8:602:1::12]) by Awfulhak.org (8.12.3/8.12.3) with SMTP id g5JIUpMt077701; Wed, 19 Jun 2002 19:30:51 +0100 (BST) (envelope-from brian@Awfulhak.org) Date: Wed, 19 Jun 2002 19:30:45 +0100 From: Brian Somers To: Mike Tancsa Cc: freebsd-net@FreeBSD.ORG Subject: Re: tracking down strange MTU issues with PPPoE) Message-Id: <20020619193045.439046ce.brian@Awfulhak.org> In-Reply-To: <5.1.0.14.0.20020618203201.07212f30@192.168.0.12> References: <5.1.0.14.0.20020618163928.05018cf0@marble.sentex.ca> <5.1.0.14.0.20020618163928.05018cf0@marble.sentex.ca> <5.1.0.14.0.20020618203201.07212f30@192.168.0.12> X-Mailer: Sylpheed version 0.7.6claws (GTK+ 1.2.10; i386-portbld-freebsd5.0) 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, The difference is that without the max bit, ppp treats the mtu as a suggestion rather than as a hard limit.... To see the difference, enable LCP logging and see what's being negotiated. On Tue, 18 Jun 2002 20:32:43 -0400, Mike Tancsa wrote: > > Yes, that did it! Thanks very much! What is different about that, and me > setting it on the other end as part of the virt-template ? > > ---Mike > > At 12:33 AM 6/19/2002 +0100, Brian Somers wrote: > >Perhaps adding > > > > set mtu max 1452 > > > >will help ? > > > >On Tue, 18 Jun 2002 16:54:49 -0400, Mike Tancsa wrote: > > > > > > The DSL whole supplier we use (Bell Canada) has been turfing their Redback > > > SMSes and moving to an ERX from unisphere networks. > > > > > > With the Redback, all was great... I had a FreeBSD box acting as a NAT > > > gateway for a number of Windows boxes and all was great. Then, the > > > customer got moved over to one of these ERXes and there is now some > > strange > > > MTU problem. Couple of things. Supposedly the default MTU on the ERX is > > > 1472 (or 1452) depending on who you talk to and not 1492. > > > > > > e.g. when doing a fetch to > > > >> lynx2.8.4rel.1.tar.bz2 doesn't seem to exist in /usr/ports/distfiles/. > > > >> Attempting to fetch from http://lynx.isc.org/current/. > > > Receiving lynx2.8.4rel.1.tar.bz2 (1940531 bytes): 0%^C > > > 16682 bytes transferred in 89.5 seconds (186.41 Bps) > > > fetch: transfer interrupted > > > > > > Notice the speed... Its totally brutal. yet, a transfer from just a few > > > hops away is fine. > > > > > > My question is, how can I track this problem down ? There seems to be > > some > > > strange interaction with FreeBSD because if I put a Windows box on the > > > other end, it does not suffer from this same problem. I can easily repeat > > > the problem, but the question is, how can I track down the issue and then > > > explain it to my telco. > > > > > > (Note, I have tried various MTU and MRU settings. > > > > > > Thanks for any pointers. > > > > > > 4.6-STABLE FreeBSD 4.6-STABLE #0: Tue Jun 18 > > > > > > > > > default: > > > set log Phase Chat LCP IPCP CCP tun command > > > ident user-ppp VERSION (built COMPILATIONDATE) > > > > > > # Ensure that "device" references the correct serial port > > > # for your modem. (cuaa0 = COM1, cuaa1 = COM2) > > > # > > > set device /dev/cuaa1 > > > > > > set speed 115200 > > > set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \ > > > \"\" AT OK-AT-OK ATE1Q0 OK \\dATDT\\T TIMEOUT 40 CONNECT" > > > set timeout 180 # 3 minute idle timer (the > > default) > > > enable dns # request DNS info (for > > resolv.conf) > > > > > > > > > pppoe: > > > set device PPPoE:fxp1 > > > #set mtu 1452 > > > #set mru 1452 > > > set speed sync > > > enable lqr > > > set lqrperiod 5 > > > set cd 5 > > > set dial > > > set login > > > set timeout 0 > > > disable deflate pred1 mppe > > > deny deflate pred1 mppe > > > set authname user@example.com > > > set authkey thepassword > > > set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0 > > > add default HISADDR > > > > > > > > > > > > ---Mike > > > -------------------------------------------------------------------- > > > Mike Tancsa, tel +1 519 651 3400 > > > Sentex Communications, mike@sentex.net > > > Providing Internet since 1994 www.sentex.net > > > Cambridge, Ontario Canada www.sentex.net/mike > > > > > > > > >-- > >Brian > > > >Don't _EVER_ lose your sense of humour ! > > -------------------------------------------------------------------- > Mike Tancsa, tel +1 519 651 3400 > Sentex Communications, mike@sentex.net > Providing Internet since 1994 www.sentex.net > Cambridge, Ontario Canada www.sentex.net/mike > -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 19 11:51:26 2002 Delivered-To: freebsd-net@freebsd.org Received: from garbo.lodgenet.com (garbo.lodgenet.com [204.124.122.252]) by hub.freebsd.org (Postfix) with ESMTP id E7AB837B40C for ; Wed, 19 Jun 2002 11:51:18 -0700 (PDT) Received: from hardy.lodgenet.com (hardy.lodgenet.com [10.0.104.235]) by garbo.lodgenet.com (8.11.4/8.11.4) with ESMTP id g5JIpBt04510; Wed, 19 Jun 2002 13:51:12 -0500 (CDT) Received: from chaplin.lodgenet.com (not verified[10.0.104.215]) by hardy.lodgenet.com with MailMarshal (4,2,5,0) id ; Wed, 19 Jun 2002 13:51:11 -0500 Received: by chaplin.lodgenet.com with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Jun 2002 13:46:40 -0500 Message-ID: <3EA88113DE92D211807300805FA7994209149EC2@chaplin.lodgenet.com> From: "McKenna, Lee" To: "'Fabien THOMAS'" , paleph@pacbell.net Cc: freebsd-net@freebsd.org Subject: RE: bge driver issue Date: Wed, 19 Jun 2002 13:46:40 -0500 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: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I just loaded 4.5-RELEASE, and cvsup/make world upgraded to 4.6-STABLE dated June 17, and have 2 machines with 3C996B-T cards using the bge driver with the two machines connected directly to each other using a crossover cable. Machines are both "home made" with Supermicro mobos with 1.2GHz CPUs. Using /dev/zero I created a file some 1.2 GBytes in size. I am getting 7 MBytes/s using scp and 30 MBytes/s using ftp. So, it looks like the max is about 240 Mbits/s. This is why we affectionately call gigabit Ethernet "a couple-hundred megabit ethernet", and we cant wait for Ken's zero copy code to reach -STABLE :) This test also includes tweaking the tcp and udp send and recv space buffers to 512K, by the way... I have not seen the error message or problem you indicated below. Not that this helps you fix your problem any, but I wanted to let you know that these cards and the bge driver does appear to work - at least for me. Let me know if you need further specifics on my setup, or want me to try anything else. --Lee > -----Original Message----- > From: Fabien THOMAS [mailto:fabien.thomas@netasq.com] > Sent: Wednesday, June 19, 2002 1:47 AM > To: paleph@pacbell.net > Cc: freebsd-net@FreeBSD.ORG > Subject: Re[2]: bge driver issue > > > I've the same problems and i fixed partially the problem by bumping > the return ring count. > > #define BGE_RETURN_RING_CNT 1024 > -> > #define BGE_RETURN_RING_CNT 2048 > > i dont think it is THE solution but it works better than > before for me... > > ppn> We have a Dell poweredge 2650 (successor to 2550). > > ppn> We also saw the same problem with 4.5. I tried the > current bge driver from 4.6 > ppn> without success. The problem seems to be a size problem. > When we ftp a small > ppn> file, things work fine. However, when we try a 18 > Megabyte file, the ftp > ppn> hands and we see the problem descriped below. The linux > system that came > ppn> with the hardware (from dell) worked fine. > > ppn> BTW. This was occuring with a 100 Mbit link. > > ppn> I have not been able to get any resolution on this. The > only replies seem to > ppn> indicate that something is seriously broken with the bge driver. > > ppn> Paul Fronberg > ppn> paleph@pacbell.net > > >> I have a dell poweredge 2550 with which I am having all sorts of > >> nasty network problems. > >> The network interface will just stop responding. > >> I get an error message like this: > >> Jun 18 08:19:38 shekondar /kernel: bge0: watchdog timeout > -- resetting > >> > >> This is using the broadcom 10/100/1000 NIC on the mother board, the > >> intel 10/100 has had similar issues but produces no log messages. > >> > >> duplex and speed settings are forced on both the card and > the switch. > >> sometimes the kernel reset will clear the fault but sometimes you > >> need to ifconfig down / up the interface to get it going again. > >> > >> This box has been running fine for several weeks, it is > only as we have > >> started to shift to production levels of traffic to it > that it has started > >> this. Approx 30M bits/sec out and 12M bits/sec inbound. > >> > >> There was a simple ipfw ruleset on the box but I have disable that > >> just now to see if it helps. > >> > >> > >> Googleing has given me people who report similar problems but no > >> solutions / work arounds. > >> > >> Have anyone got any suggestions as to what to do next. > >> > >> Colin > >> > >> Here is the output of postconf > >> > >> bge0@pci1:8:0: class=0x020000 card=0x00d11028 > chip=0x164414e4 rev=0x12 > >> hdr=0x00 vendor = 'Broadcom Corporation' > >> device = 'BCM5700/1 Gigabit Ethernet Controller' > >> class = network > >> subclass = ethernet > > ppn> To Unsubscribe: send mail to majordomo@FreeBSD.org > ppn> with "unsubscribe freebsd-net" in the body of the message > > > > -- > Cordialement, > Fabien mailto:fabien.thomas@netasq.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 Wed Jun 19 12: 0:52 2002 Delivered-To: freebsd-net@freebsd.org Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by hub.freebsd.org (Postfix) with ESMTP id 9CB5937B403; Wed, 19 Jun 2002 12:00:20 -0700 (PDT) Received: from InterJet.elischer.org ([12.232.206.8]) by sccrmhc02.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020619190019.CGAJ1547.sccrmhc02.attbi.com@InterJet.elischer.org>; Wed, 19 Jun 2002 19:00:19 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA26320; Wed, 19 Jun 2002 11:58:33 -0700 (PDT) Date: Wed, 19 Jun 2002 11:58:32 -0700 (PDT) From: Julian Elischer To: Luigi Rizzo Cc: julian@freebsd.org, net@freebsd.org Subject: Re: removing global variables from the network stack In-Reply-To: <20020619094420.C58636@iguana.icir.org> Message-ID: 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 Wed, 19 Jun 2002, Luigi Rizzo wrote: > Hi, > I am trying to cleanup as much as possible the use of global > variables in the network stack, both for code clarity, and > to ease the use of this code in an SMP context. > > The two offenders I am concentrating upon are IPFW/DUMMYNET and DIVERT. > For the former, I am the guilty one:) I know how to fix it. > > For DIVERT, I think this is someone else's code, so here's my > understanding of the problem and proposed fix: Since Archie and I am responsible for this I will speak up.. It is not just the divert code, but teh ipfw 'fwd' code also makes use of a global variable I think. The added information needs to travel with the packet in some way. I suggest that we make use of metadata stored in the m_aux packet to remove this sort of stuff. Dummynet and ALTQ data as well as firewall classification information and divert/forward information can be stored in there if we have a format to do it.. > > The global variable in question is "ip_divert_cookie", > declared in ip_divert.c and used to pass the divert port > to divert_packet(), and from div_output() to ip_output()/ip_input() > > For the former the fix is trivial, we just need to add an additional > argument to divert_packet(). > > For the latter, it *would* be easy to add an argument to ip_output() > but if we do not want to change the interface, perhaps the easiest > trick is to pass the annotation in the same way as it is done for > dummynet info, i.e. using a fake mbuf prepended to the actual chain. > Something like this: > > ip_divert.c::div_output() > > ... make ip_divert_cookie a local variable ... > > struct m_hdr fake_mbuf; what's wrong with a real mbuf? fake anythings in the kernel scare me.. > > fake_mbuf.mh_type = MT_DIVERT; > fake_mbuf.mh_next = m; > fake_mbuf.mh_len = ip_divert_cookie; > ... > if ( ) { > error = ip_output(&fake_mbuf, ...); > ... > } else { /* incoming packet */ > ... > ip_input(&fake_mbuf); > } > > ip_output.c::ip_output() > ip_output.c::ip_input() > > ... right after local variables instead of fetching ip_divert_cookie > > if (m->m_type == MT_DIVERT) { > divert_cookie = m->mh_len; > m = m->mh_next; > } > ... continue with regular processing ... > > Does this look right ? > As a matter of fact, ip_input() is used only in a couple of places > so it might be possible to change the interface and add a second > parameter to carry the divert_cookie. However the use of an annotation > block in front of it seems a bit less intrusive and easier to extend > to other annotations we might want to add. I think that it shuld be a real mbuf and it should be using a generic metadata scheme. KAME have given us m_aux.. let's use it. also check the interaction of divert and IP reassembly codes. (sorry to not be more costructive right now but My head is in teh thread scheduler of KSE rather than the network stack right now..) Julian > > cheers > luigi > -----------------------------------+------------------------------------- > Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione > http://www.iet.unipi.it/~luigi/ . Universita` di Pisa > TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) > Mobile +39-347-0373137 > -----------------------------------+------------------------------------- > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 19 12:25:55 2002 Delivered-To: freebsd-net@freebsd.org Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id AEB9F37B40E; Wed, 19 Jun 2002 12:25:38 -0700 (PDT) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g5JJPZn60481; Wed, 19 Jun 2002 12:25:35 -0700 (PDT) (envelope-from rizzo) Date: Wed, 19 Jun 2002 12:25:35 -0700 From: Luigi Rizzo To: Julian Elischer Cc: julian@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: removing global variables from the network stack Message-ID: <20020619122535.A60231@iguana.icir.org> References: <20020619094420.C58636@iguana.icir.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: ; from julian@elischer.org on Wed, Jun 19, 2002 at 11:58:32AM -0700 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 Wed, Jun 19, 2002 at 11:58:32AM -0700, Julian Elischer wrote: ... > Since Archie and I am responsible for this I will that was because you were on the To: list :) > It is not just the divert code, but teh ipfw 'fwd' code also makes use of > a global variable I think. oh yes, i forgot that. > The added information needs to travel with the packet in some way. in general, yes. In these specific cases (ipfw, divert, forward), obviously this is not true because we have a single instance of 3 global variables which are only used while the packet is being processed, not when it resides in some queue. > I suggest that we make use of metadata stored in the m_aux packet to > remove this sort of stuff. Dummynet and ALTQ data as well as firewall > classification information and divert/forward information can be stored in > there if we have a format to do it.. I agree with you (and Sam Leffler, who suggested a similar approach based on the m_tag as in NetBSD) as a long term solution (though I have some concerns on performance, as i mentioned in the dev.summit in february). However, proper handling of m_aux/m_tag chains (just look at Sam's patch) requires quite extensive changes, and I am afraid to break ipv6/kame stuff (which I have no way to test) in the process. I do not see this as a viable solution for RELENG_4. So take my suggestion as a short-term, very little intrusive step towards the correct solution. > > struct m_hdr fake_mbuf; > > what's wrong with a real mbuf? nothing, except that you only use the m_hdr part, and being this a volatile piece of info used just to avoid changing the interface of ip_input() and friends, it is overkill and way too expensive to allocate it with MGET and have to release it a moment after with m_freem(). > (sorry to not be more costructive right now but My head is in teh thread > scheduler of KSE rather than the network stack right now..) don't worry, and thanks for the feedback. I'll try to document what i do so it will be easier to change it when it is needed. cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 19 12:49:41 2002 Delivered-To: freebsd-net@freebsd.org Received: from obsidian.sentex.ca (obsidian.sentex.ca [64.7.128.101]) by hub.freebsd.org (Postfix) with ESMTP id 51B5837B40C for ; Wed, 19 Jun 2002 12:49:34 -0700 (PDT) Received: from simian.sentex.net (pyroxene.sentex.ca [199.212.134.18]) by obsidian.sentex.ca (8.12.2/8.12.2) with ESMTP id g5JJnU7U072623; Wed, 19 Jun 2002 15:49:30 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <5.1.0.14.0.20020619153843.04ac1868@marble.sentex.ca> X-Sender: mdtpop@marble.sentex.ca X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 19 Jun 2002 15:51:48 -0400 To: Brian Somers From: Mike Tancsa Subject: FreeBSD PPPoE Broken ? (was Re: tracking down strange MTU issues with PPPoE) Cc: freebsd-net@FreeBSD.ORG In-Reply-To: <20020619193045.439046ce.brian@Awfulhak.org> References: <5.1.0.14.0.20020618203201.07212f30@192.168.0.12> <5.1.0.14.0.20020618163928.05018cf0@marble.sentex.ca> <5.1.0.14.0.20020618163928.05018cf0@marble.sentex.ca> <5.1.0.14.0.20020618203201.07212f30@192.168.0.12> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: By Sentex Communications (obsidian/20020220) 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 OK, just completed some more testing. Something is definitely really strange between FreeBSD's PPPoE and the ERX. I have 2 FreeBSD boxes in 2 different locations, both that were working great off Redbacks. The Telco switched out the Redbacks and put Unisphere ERXs in place. At these 2 sites, if I take out the FreeBSD boxes and put in either Windows 2000, Linux 2.4.x or a Cisco 827 all works great. With FreeBSD, I can browse and fetch data from some sites, but not all. The problem sites, transfer rates become bytes per second. If I take out those 2 FreeBSD boxes and move them physically to a different site where its terminated off a redback, all works as expected. So it would seem one or some of the following a) Something wrong with my config b) Something wrong with the ERX c) Something wrong with FreeBSD's PPPoE implementation as far as the ERX is concerned. d) Something wrong with my Telco's config. a) is always possible. But the same simple PPPoE config has been working for some time and the first box in question only stopped working when the telco switch the termination device from a RedBack SMS to the ERX. b) Possible, but all the other implementations seem to work c) Not sure where to start d) Again, certainly possible, but would it not affect all the PPPoE implementations equally? Any help is much appreciated as I dont want to abandon FreeBSD of course at these sites for Linux. ---Mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 19 13:56:52 2002 Delivered-To: freebsd-net@freebsd.org Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by hub.freebsd.org (Postfix) with ESMTP id 5807B37B407; Wed, 19 Jun 2002 13:56:45 -0700 (PDT) Received: from melange (melange.errno.com [66.127.85.82]) (authenticated bits=0) by ebb.errno.com (8.12.1/8.12.1) with ESMTP id g5JKugr4039189 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 19 Jun 2002 13:56:43 -0700 (PDT)?g (envelope-from sam@errno.com)œ Message-ID: <06bb01c217d3$d131b7f0$52557f42@errno.com> From: "Sam Leffler" To: "Luigi Rizzo" , "Julian Elischer" Cc: , References: <20020619094420.C58636@iguana.icir.org> <20020619122535.A60231@iguana.icir.org> Subject: Re: removing global variables from the network stack Date: Wed, 19 Jun 2002 13:56:42 -0700 Organization: Errno Consulting MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 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 agree with you (and Sam Leffler, who suggested a similar approach > based on the m_tag as in NetBSD) as a long term solution (though I > have some concerns on performance, as i mentioned in the dev.summit > in february). However, proper handling of m_aux/m_tag chains (just > look at Sam's patch) requires quite extensive changes, and I am > afraid to break ipv6/kame stuff (which I have no way to test) in > the process. I do not see this as a viable solution for RELENG_4. > FWIW my m_tag mods are based on openbsd code (which may well have come from netbsd). Using m_tag actually simplifies the KAME code considerably since there's no reuse of aux bufs (KAME plays some games with identifying what an aux buf is used for based on it's size). I've been running IPV6 and IPSEC "tortute tests" with these mods for 4+ months but they definitely need more testing before committing anywhere (-stable or -current). Also, as I said to you privately, m_tag support is required for the hardware crypto mods I'm working on. They also are the mechanism by which NIC drivers pass onboard processing state back up to the IPSEC code (i.e. crypto results done on the NIC). I'll think about how to add them to -stable w/o breaking binary compatibility. Sam To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 19 13:58:16 2002 Delivered-To: freebsd-net@freebsd.org Received: from soho1.binc.net (soho1.binc.net [64.73.16.3]) by hub.freebsd.org (Postfix) with SMTP id 7144537B400 for ; Wed, 19 Jun 2002 13:58:01 -0700 (PDT) Received: (qmail 10059 invoked from network); 19 Jun 2002 20:57:59 -0000 Received: from localhost (HELO the-rob.com) ([127.0.0.1]) (envelope-sender ) by localhost (qmail-ldap-1.03) with SMTP for ; 19 Jun 2002 20:57:59 -0000 Received: from 216.170.185.67 (SquirrelMail authenticated user rob@the-rob.com) by www.soho.berbee.com with HTTP; Wed, 19 Jun 2002 15:57:59 -0500 (CDT) Message-ID: <3029.216.170.185.67.1024520279.squirrel@www.soho.berbee.com> Date: Wed, 19 Jun 2002 15:57:59 -0500 (CDT) Subject: =?iso-8859-1?Q?Issues_with_PPPoE_and_4.6=3F_(config_files_and_dumps_attatched,_kinda_long)_?= From: To: X-Mailer: SquirrelMail (version 1.2.0 [cvs]) 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 Hello, how are you? The other day I upgraded to 4.6 on my firewall machine, upon reboot the machine did not pull an IP address. I troubleshoot and after about an hour of troubleshooting I attempted to ping the outside world another time and it came up. I woke up this afternoon and had no connectivity to the outside world. ifconfig showed I had an IP address but I was unable to browse the internet. I attempted to ping yahoo.com I got a name lookup failure. I attempted to ping the IP address and I got "No buffer space avaliable" So I rebooted the machine. Upon this reboot it did not pull an IP address. Could their be something wrong with pppoe in 4.6? Has anyone mentioned this already ( in the short short time 4.6 has been stable?) I did not change anything in my ppp.conf, my kernel, or rc.conf. Mergemaster did not change any of these files. When I run tcpdump on the interface that's plugged into the DSL modem I get a bunch of lines and then " [Generic- Error "session closed"]" message (Full dump is at the end of this email.) Any thoughts suggestions? I have included the dump from the uname -a, outside interface, ppp.conf, and kernel as stated earlier, none of these config files have been changed since I was running 4.5 Please CC me, because I'm not on the list. Thank you PITA#uname -a FreeBSD PITA.the-rob.com 4.6-STABLE FreeBSD 4.6-STABLE #: Tue Jun 18 04:02:05 CDT 2002 zietlow@PITA.the- rob.com:/usr/src/sys/compile/FIREWALL i386 15:36:52.807254 PPPoE PADI [Host-Uniq UTF8] 15:36:54.802440 PPPoE PADI [Host-Uniq UTF8] 15:36:54.828153 PPPoE PADO [Host-Uniq UTF8] [Service-Name] [AC-Name "miwi- 6400-inet-nrp0"] [AC-Cookie UTF8] 15:36:54.828240 PPPoE PADR [Host-Uniq UTF8] [AC-Cookie UTF8] [AC-Name "miwi- 6400-inet-nrp0"] 15:36:55.134631 PPPoE PADS [ses 0xe6] [Host-Uniq UTF8] [AC-Cookie UTF8] [AC- Name "miwi-6400-inet-nrp0"] 15:36:55.179944 PPPoE [ses 0xe6] LCP 20: Conf-Req(1), MRU=1492, Auth-Prot PAP, Magic-Num=75f2765e 15:36:57.182623 PPPoE [ses 0xe6] LCP 20: Conf-Req(2), MRU=1492, Auth-Prot PAP, Magic-Num=75f2765e 15:36:57.854311 PPPoE PADT [ses 0xe6] [Generic-Error "session closed"] 15:36:59.182260 PPPoE [ses 0xe6] LCP 20: Conf-Req(3), MRU=1492, Auth-Prot PAP, Magic-Num=75f2765e 15:37:01.182047 PPPoE [ses 0xe6] LCP 20: Conf-Req(4), MRU=1492, Auth-Prot PAP, Magic-Num=75f2765e 15:37:03.183085 PPPoE [ses 0xe6] LCP 20: Conf-Req(5), MRU=1492, Auth-Prot PAP, Magic-Num=75f2765e 15:37:05.183860 PPPoE [ses 0xe6] LCP 20: Conf-Req(6), MRU=1492, Auth-Prot PAP, Magic-Num=75f2765e 15:37:07.185145 PPPoE [ses 0xe6] LCP 20: Conf-Req(7), MRU=1492, Auth-Prot PAP, Magic-Num=75f2765e 15:37:09.185917 PPPoE [ses 0xe6] LCP 20: Conf-Req(8), MRU=1492, Auth-Prot PAP, Magic-Num=75f2765e 15:37:11.186448 PPPoE [ses 0xe6] LCP 20: Conf-Req(9), MRU=1492, Auth-Prot PAP, Magic-Num=75f2765e 15:37:13.187240 PPPoE [ses 0xe6] LCP 20: Conf-Req(10), MRU=1492, Auth-Prot PAP, Magic-Num=75f2765e 15:37:15.188766 PPPoE PADT [ses 0xe6] 15:37:27.877649 PPPoE PADI [Host-Uniq UTF8] 15:37:29.872969 PPPoE PADI [Host-Uniq UTF8] 15:37:29.900095 PPPoE PADO [Host-Uniq UTF8] [Service-Name] [AC-Name "miwi- 6400-inet-nrp0"] [AC-Cookie UTF8] 15:37:29.900183 PPPoE PADR [Host-Uniq UTF8] [AC-Cookie UTF8] [AC-Name "miwi- 6400-inet-nrp0"] 15:37:30.307095 PPPoE PADS [ses 0xe8] [Host-Uniq UTF8] [AC-Cookie UTF8] [AC- Name "miwi-6400-inet-nrp0"] 15:37:30.354136 PPPoE [ses 0xe8] LCP 20: Conf-Req(1), MRU=1492, Auth-Prot PAP, Magic-Num=75f2ffbd 15:37:32.366754 PPPoE [ses 0xe8] LCP 20: Conf-Req(2), MRU=1492, Auth-Prot PAP, Magic-Num=75f2ffbd 15:37:32.924827 PPPoE PADT [ses 0xe8] [Generic-Error "session closed"] 15:37:34.364336 PPPoE [ses 0xe8] LCP 20: Conf-Req(3), MRU=1492, Auth-Prot PAP, Magic-Num=75f2ffbd 15:37:36.432861 PPPoE [ses 0xe8] LCP 20: Conf-Req(4), MRU=1492, Auth-Prot PAP, Magic-Num=75f2ffbd 15:37:38.430697 PPPoE [ses 0xe8] LCP 20: Conf-Req(5), MRU=1492, Auth-Prot PAP, Magic-Num=75f2ffbd 15:37:40.430983 PPPoE [ses 0xe8] LCP 20: Conf-Req(6), MRU=1492, Auth-Prot PAP, Magic-Num=75f2ffbd 15:37:42.433783 PPPoE [ses 0xe8] LCP 20: Conf-Req(7), MRU=1492, Auth-Prot PAP, Magic-Num=75f2ffbd 15:37:44.432795 PPPoE [ses 0xe8] LCP 20: Conf-Req(8), MRU=1492, Auth-Prot PAP, Magic-Num=75f2ffbd 15:37:46.539021 PPPoE [ses 0xe8] LCP 20: Conf-Req(9), MRU=1492, Auth-Prot PAP, Magic-Num=75f2ffbd 15:37:48.538820 PPPoE [ses 0xe8] LCP 20: Conf-Req(10), MRU=1492, Auth-Prot PAP, Magic-Num=75f2ffbd 15:37:50.539347 PPPoE PADT [ses 0xe8] 15:38:02.948139 PPPoE PADI [Host-Uniq UTF8] 15:38:04.943496 PPPoE PADI [Host-Uniq UTF8] 15:38:04.971560 PPPoE PADO [Host-Uniq UTF8] [Service-Name] [AC-Name "miwi- 6400-inet-nrp0"] [AC-Cookie UTF8] 15:38:04.971644 PPPoE PADR [Host-Uniq UTF8] [AC-Cookie UTF8] [AC-Name "miwi- 6400-inet-nrp0"] 15:38:05.384470 PPPoE PADS [ses 0xe9] [Host-Uniq UTF8] [AC-Cookie UTF8] [AC- Name "miwi-6400-inet-nrp0"] 15:38:05.468476 PPPoE [ses 0xe9] LCP 20: Conf-Req(1), MRU=1492, Auth-Prot PAP, Magic-Num=75f388dc PITA#cat /etc/ppp/ppp.conf ################################################################# # PPP Sample Configuration File # Originally written by Toshiharu OHNO # Simplified 5/14/1999 by wself@cdrom.com # # See /usr/share/examples/ppp/ for some examples # # $FreeBSD: src/etc/ppp/ppp.conf,v 1.2.2.5 2001/07/13 10:55:23 brian Exp $ ################################################################# default: #ppp over ethernet set device PPPoE:xl0: set speed sync set mru 1492 set mtu 1492 set ctsrts off # monitor line quality enable lqr # log just a big set log Phase tun # insert default route upon connection add default HISADDR # download /etc/resolv.conf enable dns tds: set authname set authkey PITA# cat /usr/src/sys/i386/conf/FIREWALL # # 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.38 2002/01/25 17:41:40 murray Exp $ machine i386 cpu I686_CPU ident FIREWALL maxusers 32 #makeoptions DEBUG=-g #Build kernel with gdb(1) debug symbols makeoptions MODULES_OVERRIDE="linux libiconv smbfs netgraph netgraph/ng_pppoe /netgraph/ng_ether netgraph/ng_socket" 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 NFS #Network Filesystem options MSDOSFS #MSDOS Filesystem options CD9660 #ISO 9660 Filesystem options PROCFS #Process filesystem options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] 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 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 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 options ATA_STATIC_ID #Static device numbering # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc0 at isa? port IO_KBD device atkbd0 at atkbdc? irq 1 flags 0x1 device psm0 at atkbdc? irq 12 device vga0 at isa? # splash screen/screen saver pseudo-device splash # syscons is the default console driver, resembling an SCO console device sc0 at isa? flags 0x100 # 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 # Serial (COM) ports device sio0 at isa? port IO_COM1 flags 0x10 irq 4 device sio1 at isa? port IO_COM2 irq 3 device sio2 at isa? disable port IO_COM3 irq 5 device sio3 at isa? disable port IO_COM4 irq 9 # 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 xl # intel card # Pseudo devices - the number indicates how many units to allocate. pseudo-device loop # Network loopback pseudo-device ether # Ethernet support pseudo-device tun # Packet tunnel. pseudo-device pty # Pseudo-ttys (telnet etc) # The `bpf' pseudo-device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! pseudo-device bpf #Berkeley packet filter #Self added values #Firewall options IPFILTER options IPFILTER_LOG options VESA options IPSEC options IPSTEALTH options USER_LDT options PERFMON options SC_KERNEL_CONS_ATTR="(FG_GREEN|BG_BLACK)" options SC_NORM_ATTR="(FG_RED|BG_BLACK)" options MAXMEM="(96*1024)" options IPFIREWALL_DEFAULT_TO_ACCEPT #allow everything by default options RANDOM_IP_ID To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 19 14:26:48 2002 Delivered-To: freebsd-net@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id CF90737B41F for ; Wed, 19 Jun 2002 14:26:25 -0700 (PDT) Received: (from ken@localhost) by panzer.kdm.org (8.11.6/8.9.1) id g5JLQCm05591; Wed, 19 Jun 2002 15:26:12 -0600 (MDT) (envelope-from ken) Date: Wed, 19 Jun 2002 15:26:12 -0600 From: "Kenneth D. Merry" To: "McKenna, Lee" Cc: "'Fabien THOMAS'" , paleph@pacbell.net, freebsd-net@FreeBSD.ORG Subject: Re: bge driver issue Message-ID: <20020619152612.A5514@panzer.kdm.org> References: <3EA88113DE92D211807300805FA7994209149EC2@chaplin.lodgenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3EA88113DE92D211807300805FA7994209149EC2@chaplin.lodgenet.com>; from lmckenna@lodgenet.com on Wed, Jun 19, 2002 at 01:46:40PM -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 On Wed, Jun 19, 2002 at 13:46:40 -0500, McKenna, Lee wrote: > I just loaded 4.5-RELEASE, and cvsup/make world upgraded to 4.6-STABLE dated > June 17, and have 2 machines with 3C996B-T cards using the bge driver with > the two machines connected directly to each other using a crossover cable. > Machines are both "home made" with Supermicro mobos with 1.2GHz CPUs. > > Using /dev/zero I created a file some 1.2 GBytes in size. I am getting 7 > MBytes/s using scp and 30 MBytes/s using ftp. So, it looks like the max is > about 240 Mbits/s. This is why we affectionately call gigabit Ethernet "a > couple-hundred megabit ethernet", and we cant wait for Ken's zero copy code > to reach -STABLE :) That likely won't happen until -current becomes -stable, but I won't rule it out completely. > This test also includes tweaking the tcp and udp send and recv space buffers > to 512K, by the way... That can help, but it would probably be better to use a better benchmarking program. scp has all the overhead of encryption to slow it down. ftp is notoriously bad as a benchmarking tool for the most part, because of the way it moves data around and the socket buffer sizes it uses. I would recommend using netperf (in /usr/ports/benchmarks). Just crank up the 'netserver' daemon on one end, and then run 'netperf -H hostname' on the other end. Try playing with the send and receive buffer sizes to see what kind of throughput you can get. With two machines very similar to yours, it sounds like, I can get wire speed between two ti(4) boards (Netgear GA620T's) using jumbo frames under a stock version of -stable. (I can't get that with 1500 byte frames, but that's not surprising with the Tigon 2.) Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 19 14:42:48 2002 Delivered-To: freebsd-net@freebsd.org Received: from Awfulhak.org (gw.Awfulhak.org [217.204.245.18]) by hub.freebsd.org (Postfix) with ESMTP id 38E5737B405 for ; Wed, 19 Jun 2002 14:42:39 -0700 (PDT) Received: from mail.lan.Awfulhak.org (brian@hak.Awfulhak.org [IPv6:2001:6f8:602:1::12]) by Awfulhak.org (8.12.3/8.12.3) with SMTP id g5JLgZMt078982; Wed, 19 Jun 2002 22:42:36 +0100 (BST) (envelope-from brian@Awfulhak.org) Date: Wed, 19 Jun 2002 22:42:29 +0100 From: Brian Somers To: Mike Tancsa Cc: freebsd-net@FreeBSD.ORG Subject: Re: FreeBSD PPPoE Broken ? (was Re: tracking down strange MTU issues with PPPoE) Message-Id: <20020619224229.55be2f1d.brian@Awfulhak.org> In-Reply-To: <5.1.0.14.0.20020619153843.04ac1868@marble.sentex.ca> References: <5.1.0.14.0.20020618203201.07212f30@192.168.0.12> <5.1.0.14.0.20020618163928.05018cf0@marble.sentex.ca> <5.1.0.14.0.20020618163928.05018cf0@marble.sentex.ca> <5.1.0.14.0.20020618203201.07212f30@192.168.0.12> <5.1.0.14.0.20020619153843.04ac1868@marble.sentex.ca> X-Mailer: Sylpheed version 0.7.6claws (GTK+ 1.2.10; i386-portbld-freebsd5.0) 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 Can you send me a log of the connection with set log +lcp ipcp phase tun command ccp Cheers. On Wed, 19 Jun 2002 15:51:48 -0400, Mike Tancsa wrote: > > OK, just completed some more testing. Something is definitely really > strange between FreeBSD's PPPoE and the ERX. I have 2 FreeBSD boxes in 2 > different locations, both that were working great off Redbacks. The Telco > switched out the Redbacks and put Unisphere ERXs in place. At these 2 > sites, if I take out the FreeBSD boxes and put in either > Windows 2000, > Linux 2.4.x > or a Cisco 827 > all works great. With FreeBSD, I can browse and fetch data from some > sites, but not all. The problem sites, transfer rates become bytes per second. > If I take out those 2 FreeBSD boxes and move them physically to a different > site where its terminated off a redback, all works as expected. > > So it would seem one or some of the following > > a) Something wrong with my config > b) Something wrong with the ERX > c) Something wrong with FreeBSD's PPPoE implementation as far as the ERX is > concerned. > d) Something wrong with my Telco's config. > > > a) is always possible. But the same simple PPPoE config has been working > for some time and the first box in question only stopped working when the > telco switch the termination device from a RedBack SMS to the ERX. > b) Possible, but all the other implementations seem to work > c) Not sure where to start > d) Again, certainly possible, but would it not affect all the PPPoE > implementations equally? > > Any help is much appreciated as I dont want to abandon FreeBSD of course at > these sites for Linux. > > > ---Mike > -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 19 15:18:17 2002 Delivered-To: freebsd-net@freebsd.org Received: from obsidian.sentex.ca (obsidian.sentex.ca [64.7.128.101]) by hub.freebsd.org (Postfix) with ESMTP id 69B6937BA94 for ; Wed, 19 Jun 2002 15:12:51 -0700 (PDT) Received: from 192.168.42.92 (pyroxene.sentex.ca [199.212.134.18]) by obsidian.sentex.ca (8.12.2/8.12.2) with SMTP id g5JMCo7T082728 for ; Wed, 19 Jun 2002 18:12:50 -0400 (EDT) (envelope-from damian@sentex.net) Date: Wed, 19 Jun 2002 18:14:06 -0400 From: Damian Gerow Subject: Re: tracking down strange MTU issues with PPPoE) To: freebsd-net@freebsd.org Message-ID: In-Reply-To: <20020619014519.A20138@tp.databus.com> X-Mailer: MicroPlanet Gravity v2.30 X-Virus-Scanned: By Sentex Communications (obsidian/20020220) 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 been working with Mike on this same problem, as I'm seeing it from my home machine. I took my home machine in to another DSL line with a Redback concentrator, and got full connect speeds -- it looks like it's something to do with the ERX. On Wed, 19 Jun 2002 01:45:19 -0400, barney@tp.databus.com stated: > There's something odd here - MSS does not include headers, and is 1460 > on a straight ethernet connection. So your MSS of 1452 equates to an > MTU of 1492. > > I'd try setting MTU (or MSS) way down, to 1024. If that works, you can > do a binary search to find the max working value. Like Mike said, I've tried this as well, to no avail. > You haven't shown enough of the dump to see if DF is set in packets from > either the working or non-working host, or to see just how big the packets > are. We've done a bunch of testing, and just for fun, I've put up the binary tcpdump output on: http://www.sentex.net/~damian/tcpdump Text versions can be found in text/. It's named by freebsd.- and windows., both of these from the viewpoint of the ISP. All dumps are getting ftp://ftp.isc.org/isc/bind9/9.2.1/bind-9.2.1.tar.gz. Maybe that will help a bit...? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 19 15:20:55 2002 Delivered-To: freebsd-net@freebsd.org Received: from soho1.binc.net (soho1.binc.net [64.73.16.3]) by hub.freebsd.org (Postfix) with SMTP id 2FBFF37B48D for ; Wed, 19 Jun 2002 15:18:06 -0700 (PDT) Received: (qmail 15572 invoked from network); 19 Jun 2002 22:18:05 -0000 Received: from localhost (HELO the-rob.com) ([127.0.0.1]) (envelope-sender ) by localhost (qmail-ldap-1.03) with SMTP for ; 19 Jun 2002 22:18:05 -0000 Received: from 216.170.184.170 (SquirrelMail authenticated user rob@the-rob.com) by www.soho.berbee.com with HTTP; Wed, 19 Jun 2002 17:18:05 -0500 (CDT) Message-ID: <3396.216.170.184.170.1024525085.squirrel@www.soho.berbee.com> Date: Wed, 19 Jun 2002 17:18:05 -0500 (CDT) Subject: =?iso-8859-1?Q?Re:_Issues_with_PPPoE_and_4.6=3F_(config_files_and_dumps_attatched,_kinda_long)?= From: To: In-Reply-To: References: Cc: , X-Mailer: SquirrelMail (version 1.2.0 [cvs]) 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 > please add -e to your tcpdump... Enclosed below > someone is ignoring the PADT (possibly us?) > so far so good.. > > why doesn't it respond to the session it told us to use? > > please include a startup of a GOOD session.... If I had one I would include it. I'm stuck on my windows box....I've been walking the modem back and forth between rooms. Thanks Rob Here's tcpdump with the -e 17:05:17.694304 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0x241] LCP 20: Conf-Req(2), MRU=1492, Auth-Prot PAP, Magic-Num= 7643522b 17:05:18.338541 0:4:76:b8:26:7c 0:2:4b:a4:b7:87 8863 38: PPPoE PADT [ses 0x241] [Generic-Error "session closed"] 17:05:19.692611 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0x241] LCP 20: Conf-Req(3), MRU=1492, Auth-Prot PAP, Magic-Num= 7643522b 17:05:21.693882 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0x241] LCP 20: Conf-Req(4), MRU=1492, Auth-Prot PAP, Magic-Num= 7643522b 17:05:23.695407 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0x241] LCP 20: Conf-Req(5), MRU=1492, Auth-Prot PAP, Magic-Num= 7643522b 17:05:25.695209 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0x241] LCP 20: Conf-Req(6), MRU=1492, Auth-Prot PAP, Magic-Num= 7643522b 17:05:27.695975 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0x241] LCP 20: Conf-Req(7), MRU=1492, Auth-Prot PAP, Magic-Num= 7643522b 17:05:29.696760 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0x241] LCP 20: Conf-Req(8), MRU=1492, Auth-Prot PAP, Magic-Num= 7643522b 17:05:31.698529 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0x241] LCP 20: Conf-Req(9), MRU=1492, Auth-Prot PAP, Magic-Num= 7643522b 17:05:33.699305 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0x241] LCP 20: Conf-Req(10), MRU=1492, Auth-Prot PAP, Magic-Num =7643522b 17:05:35.699605 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8863 60: PPPoE PADT [ses 0x241] 17:05:48.361992 0:4:76:b8:26:7c Broadcast 8863 32: PPPoE PADI [Host-Uniq UTF8] 17:05:50.357254 0:4:76:b8:26:7c Broadcast 8863 32: PPPoE PADI [Host-Uniq UTF8] 17:05:50.382848 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8863 75: PPPoE PADO [Host- Uniq UTF8] [Service-Name] [AC-Name "miwi-6400-inet-nrp0"] [AC-Cookie UTF8] 17:05:50.382933 0:4:76:b8:26:7c 0:2:4b:a4:b7:87 8863 75: PPPoE PADR [Host- Uniq UTF8] [AC-Cookie UTF8] [AC-Name "miwi-6400-inet-nrp0" ] 17:05:50.801432 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8863 75: PPPoE PADS [ses 0x244] [Host-Uniq UTF8] [AC-Cookie UTF8] [AC-Name "miwi-640 0-inet-nrp0"] 17:05:50.826304 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0x244] LCP 20: Conf-Req(1), MRU=1492, Auth-Prot PAP, Magic-Num= 7643db5e 17:05:52.823642 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0x244] LCP 20: Conf-Req(2), MRU=1492, Auth-Prot PAP, Magic-Num= 7643db5e 17:05:53.409024 0:4:76:b8:26:7c 0:2:4b:a4:b7:87 8863 38: PPPoE PADT [ses 0x244] [Generic-Error "session closed"] 17:05:54.824413 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0x244] LCP 20: Conf-Req(3), MRU=1492, Auth-Prot PAP, Magic-Num= 7643db5e 17:05:56.824948 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0x244] LCP 20: Conf-Req(4), MRU=1492, Auth-Prot PAP, Magic-Num= 7643db5e 17:05:58.826230 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0x244] LCP 20: Conf-Req(5), MRU=1492, Auth-Prot PAP, Magic-Num= 7643db5e 17:06:00.826519 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0x244] LCP 20: Conf-Req(6), MRU=1492, Auth-Prot PAP, Magic-Num= 7643db5e 17:06:02.828277 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0x244] LCP 20: Conf-Req(7), MRU=1492, Auth-Prot PAP, Magic-Num= 7643db5e 17:06:04.828316 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0x244] LCP 20: Conf-Req(8), MRU=1492, Auth-Prot PAP, Magic-Num= 7643db5e 17:06:06.852261 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0x244] LCP 20: Conf-Req(9), MRU=1492, Auth-Prot PAP, Magic-Num= 7643db5e 17:06:08.894935 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0x244] LCP 20: Conf-Req(10), MRU=1492, Auth-Prot PAP, Magic-Num =7643db5e 17:06:10.896203 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8863 60: PPPoE PADT [ses 0x244] 17:06:23.432539 0:4:76:b8:26:7c Broadcast 8863 32: PPPoE PADI [Host-Uniq UTF8] 17:06:25.427781 0:4:76:b8:26:7c Broadcast 8863 32: PPPoE PADI [Host-Uniq UTF8] 17:06:25.455524 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8863 75: PPPoE PADO [Host- Uniq UTF8] [Service-Name] [AC-Name "miwi-6400-inet-nrp0"] [AC-Cookie UTF8] 17:06:25.455607 0:4:76:b8:26:7c 0:2:4b:a4:b7:87 8863 75: PPPoE PADR [Host- Uniq UTF8] [AC-Cookie UTF8] [AC-Name "miwi-6400-inet-nrp0" ] 17:06:25.782714 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8863 75: PPPoE PADS [ses 0x24a] [Host-Uniq UTF8] [AC-Cookie UTF8] [AC-Name "miwi-640 0-inet-nrp0"] 17:06:25.883944 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0x24a] LCP 20: Conf-Req(1), MRU=1492, Auth-Prot PAP, Magic-Num= 76446454 17:06:27.882768 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0x24a] LCP 20: Conf-Req(2), MRU=1492, Auth-Prot PAP, Magic-Num= 76446454 17:06:28.479622 0:4:76:b8:26:7c 0:2:4b:a4:b7:87 8863 38: PPPoE PADT [ses 0x24a] [Generic-Error "session closed"] 17:06:29.883537 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0x24a] LCP 20: Conf-Req(3), MRU=1492, Auth-Prot PAP, Magic-Num= 76446454 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 19 16: 0:35 2002 Delivered-To: freebsd-net@freebsd.org Received: from sccrmhc03.attbi.com (sccrmhc03.attbi.com [204.127.202.63]) by hub.freebsd.org (Postfix) with ESMTP id C51F037B40C; Wed, 19 Jun 2002 16:00:14 -0700 (PDT) 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 <20020619230013.ZXQG20219.sccrmhc03.attbi.com@InterJet.elischer.org>; Wed, 19 Jun 2002 23: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 PAA27383; Wed, 19 Jun 2002 15:44:15 -0700 (PDT) Date: Wed, 19 Jun 2002 15:44:13 -0700 (PDT) From: Julian Elischer To: rob@the-rob.com Cc: net@freebsd.org, brian@freebsd.org Subject: Re:Issues_with_PPPoE_and_4.6 In-Reply-To: <3396.216.170.184.170.1024525085.squirrel@www.soho.berbee.com> Message-ID: 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 Ok Here's a rough translation of what the log says.. looks a bit like a freeBSD problem.. On Wed, 19 Jun 2002 rob@the-rob.com wrote: > > please add -e to your tcpdump... > > Enclosed below > > > > > someone is ignoring the PADT (possibly us?) > > > > > so far so good.. > > > > why doesn't it respond to the session it told us to use? > > > > please include a startup of a GOOD session.... > > If I had one I would include it. I'm stuck on my windows box....I've been > walking the modem back and forth between rooms. do the tcpdump with the windows box doing the pppoe.. i.e. put them on the same ehternet segment. the BSD box just listenning... > > Thanks > > Rob > > Here's tcpdump with the -e > > > > 17:05:48.361992 0:4:76:b8:26:7c Broadcast 8863 32: PPPoE PADI [Host-Uniq UTF8] "yoohoo,, ISP, Are you there? foo calling.." [2 second silence] > 17:05:50.357254 0:4:76:b8:26:7c Broadcast 8863 32: PPPoE PADI [Host-Uniq UTF8] "I Said... yoohoo,, ISP, Are you there? foo calling.." > 17:05:50.382848 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8863 75: PPPoE PADO > [Host Uniq UTF8] [Service-Name] [AC-Name "miwi-6400-inet-nrp0"] > [AC-Cookie UTF8] "wha..wha..err Yup foo, I'm here.. call me 'mumble'" > 17:05:50.382933 0:4:76:b8:26:7c 0:2:4b:a4:b7:87 8863 75: PPPoE PADR [Host-Uniq UTF8] [AC-Cookie UTF8] [AC-Name"miwi-6400-inet-nrp0"] "Ok Mumble, Foo here again, I want a session from your 'miwi-6400-inet-nrp0' server.." > 17:05:50.801432 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8863 75: PPPoE PADS [ses 0x244] [Host-Uniq UTF8] [AC-Cookie UTF8] [AC-Name "miwi-6400-inet-nrp0"] "Ok foo, this is mumble. You are cleared to take off on session 0x233" "ppp control will contact you directly" > 17:05:50.826304 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0x244] "ISP ppp control here, calling session0x224. Start your take-off" [2 seconds silence] > LCP 20: Conf-Req(1), MRU=1492, Auth-Prot PAP, Magic-Num=7643db5e "I said.... ISP ppp control here, calling session0x224. Start your take-off" [2 seconds silence] > 17:05:52.823642 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0x244] > LCP 20: Conf-Req(2), MRU=1492, Auth-Prot PAP, Magic-Num=7643db5e "Foo, This is mumble here again.. ppp control says he can't contact you.. abort takeoff.. closing the frequency and going to lunch" > 17:05:53.409024 0:4:76:b8:26:7c 0:2:4b:a4:b7:87 8863 38: PPPoE PADT [ses > 0x244] [Generic-Error "session closed"] "This is Foo, calling ppp-control, can I take off yet?" > 17:05:54.824413 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0x244] > LCP 20: Conf-Req(3), MRU=1492, Auth-Prot PAP, Magic-Num=7643db5e "This is Foo, calling ppp-control, can I take off yet?" > 17:05:56.824948 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0x244] > LCP 20: Conf-Req(4), MRU=1492, Auth-Prot PAP, Magic-Num= > 7643db5e "This is Foo, calling ppp-control, can I take off yet?" > 17:05:58.826230 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0x244] > LCP 20: Conf-Req(5), MRU=1492, Auth-Prot PAP, Magic-Num=7643db5e etc. this actually sounds like a FreeBSD (foo) problem. 1/ firstly we didn't respond to the initial session (at least not quick enough) (why not...? 2 seconds is more than enough time) 2/ We didn't abort when the link was closed.. Julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 19 16: 5:48 2002 Delivered-To: freebsd-net@freebsd.org Received: from vinyl2.sentex.ca (vinyl2.sentex.ca [199.212.134.13]) by hub.freebsd.org (Postfix) with ESMTP id 0D00037B419 for ; Wed, 19 Jun 2002 16:04:05 -0700 (PDT) Received: from house.sentex.net (cage.simianscience.com [64.7.134.1]) (authenticated bits=0) by vinyl2.sentex.ca (8.12.3/8.12.2) with ESMTP id g5JN3wdc025998; Wed, 19 Jun 2002 19:03:59 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <5.1.0.14.0.20020619185445.031f0928@192.168.0.12> X-Sender: mdtancsa@192.168.0.12 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 19 Jun 2002 19:01:59 -0400 To: Brian Somers From: Mike Tancsa Subject: Re: FreeBSD PPPoE Broken ? (was Re: tracking down strange MTU issues with PPPoE) Cc: freebsd-net@FreeBSD.ORG In-Reply-To: <20020619224229.55be2f1d.brian@Awfulhak.org> References: <5.1.0.14.0.20020619153843.04ac1868@marble.sentex.ca> <5.1.0.14.0.20020618203201.07212f30@192.168.0.12> <5.1.0.14.0.20020618163928.05018cf0@marble.sentex.ca> <5.1.0.14.0.20020618163928.05018cf0@marble.sentex.ca> <5.1.0.14.0.20020618203201.07212f30@192.168.0.12> <5.1.0.14.0.20020619153843.04ac1868@marble.sentex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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 Thanks, here you go! Jun 19 18:56:23 iscar ppp[55]: tun0: LCP: deflink: RecvEchoReply(41) state = Opened Jun 19 18:57:28 iscar ppp[55]: tun0: Phase: Received NGM_PPPOE_ACNAME (hook "bas8-toronto63") Jun 19 18:57:29 iscar ppp[55]: tun0: Phase: Received NGM_PPPOE_<11> (hook "+^K^H^Hh^P^K^H") Jun 19 18:57:30 iscar ppp[55]: tun0: Phase: Received NGM_PPPOE_SUCCESS (hook "tun0") Jun 19 18:57:30 iscar ppp[55]: tun0: Phase: deflink: carrier -> login Jun 19 18:57:30 iscar ppp[55]: tun0: Phase: deflink: login -> lcp Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: FSM: Using "deflink" as a transport Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: deflink: State change Initial --> Closed Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: deflink: State change Closed --> Stopped Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: deflink: RecvConfigReq(58) state = Stopped Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: MRU[4] 1492 Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: AUTHPROTO[4] 0xc023 (PAP) Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: MAGICNUM[6] 0x3cc22f0d Jun 19 18:57:30 iscar ppp[55]: tun0: Warning: deflink: Reducing configured MRU from 1500 to 1492 Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: deflink: SendConfigReq(1) state = Stopped Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: MRU[4] 1492 Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: MAGICNUM[6] 0xada0b92c Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: QUALPROTO[8] proto c025, interval 5000ms Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: deflink: SendConfigAck(58) state = Stopped Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: MRU[4] 1492 Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: AUTHPROTO[4] 0xc023 (PAP) Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: MAGICNUM[6] 0x3cc22f0d Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: deflink: LayerStart Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: deflink: State change Stopped --> Ack-Sent Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: deflink: RecvConfigRej(1) state = Ack-Sent Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: Sending ident magic ada0b92c text user-ppp 2.3.3 (built Jun 18 2002) Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: deflink: SendIdent(0) state = Ack-Sent Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: QUALPROTO[8] proto c025, interval 5000ms Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: deflink: SendConfigReq(2) state = Ack-Sent Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: MRU[4] 1492 Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: MAGICNUM[6] 0xada0b92c Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: deflink: RecvConfigAck(2) state = Ack-Sent Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: deflink: State change Ack-Sent --> Opened Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: deflink: LayerUp Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: deflink: SendEchoRequest(0) state = Opened Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: Sending ident magic ada0b92c text user-ppp 2.3.3 (built Jun 18 2002) Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: deflink: SendIdent(1) state = Opened Jun 19 18:57:30 iscar ppp[55]: tun0: Phase: bundle: Authenticate Jun 19 18:57:30 iscar ppp[55]: tun0: Phase: deflink: his = PAP, mine = none Jun 19 18:57:30 iscar ppp[55]: tun0: Phase: Pap Output: iscar@sentex.ca ******** Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: deflink: RecvEchoReply(0) state = Opened Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: deflink: RecvConfigReq(1) state = Opened Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: deflink: LayerDown Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: deflink: LayerDown Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: MRU[4] 1492 Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: AUTHPROTO[4] 0xc023 (PAP) Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: MAGICNUM[6] 0xf6666b1e Jun 19 18:57:30 iscar ppp[55]: tun0: Warning: deflink: Reducing configured MRU from 1500 to 1492 Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: deflink: SendConfigReq(3) state = Opened Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: MRU[4] 1492 Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: MAGICNUM[6] 0xc0fa0be2 Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: QUALPROTO[8] proto c025, interval 5000ms Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: deflink: SendConfigAck(1) state = Opened Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: MRU[4] 1492 Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: AUTHPROTO[4] 0xc023 (PAP) Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: MAGICNUM[6] 0xf6666b1e Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: deflink: State change Opened --> Ack-Sent Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: deflink: RecvConfigNak(3) state = Ack-Sent Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: QUALPROTO[8] proto c025, interval 10000ms Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: deflink: SendConfigReq(4) state = Ack-Sent Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: MRU[4] 1492 Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: MAGICNUM[6] 0xc0fa0be2 Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: QUALPROTO[8] proto c025, interval 5000ms Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: deflink: RecvConfigNak(4) state = Ack-Sent Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: QUALPROTO[8] proto c025, interval 10000ms Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: deflink: SendConfigReq(5) state = Ack-Sent Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: MRU[4] 1492 Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: MAGICNUM[6] 0xc0fa0be2 Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: QUALPROTO[8] proto c025, interval 5000ms Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: deflink: RecvConfigNak(5) state = Ack-Sent Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: QUALPROTO[8] proto c025, interval 10000ms Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: deflink: SendConfigReq(6) state = Ack-Sent Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: MRU[4] 1492 Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: MAGICNUM[6] 0xc0fa0be2 Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: QUALPROTO[8] proto c025, interval 5000ms Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: deflink: RecvConfigNak(6) state = Ack-Sent Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: QUALPROTO[8] proto c025, interval 10000ms Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: deflink: SendConfigReq(7) state = Ack-Sent Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: MRU[4] 1492 Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: MAGICNUM[6] 0xc0fa0be2 Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: QUALPROTO[8] proto c025, interval 5000ms Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: deflink: RecvConfigNak(7) state = Ack-Sent Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: QUALPROTO[8] proto c025, interval 10000ms Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: deflink: SendConfigReq(8) state = Ack-Sent Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: MRU[4] 1492 Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: MAGICNUM[6] 0xc0fa0be2 Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: QUALPROTO[8] proto c025, interval 5000ms Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: deflink: RecvConfigRej(8) state = Ack-Sent Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: Sending ident magic c0fa0be2 text user-ppp 2.3.3 (built Jun 18 2002) Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: deflink: SendIdent(2) state = Ack-Sent Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: QUALPROTO[8] proto c025, interval 5000ms Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: deflink: SendConfigReq(9) state = Ack-Sent Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: MRU[4] 1492 Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: MAGICNUM[6] 0xc0fa0be2 Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: deflink: RecvConfigAck(9) state = Ack-Sent Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: deflink: State change Ack-Sent --> Opened Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: deflink: LayerUp Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: deflink: SendEchoRequest(0) state = Opened Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: Sending ident magic c0fa0be2 text user-ppp 2.3.3 (built Jun 18 2002) Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: deflink: SendIdent(3) state = Opened Jun 19 18:57:30 iscar ppp[55]: tun0: Phase: deflink: his = PAP, mine = none Jun 19 18:57:30 iscar ppp[55]: tun0: Phase: Pap Output: iscar@sentex.ca ******** Jun 19 18:57:30 iscar ppp[55]: tun0: LCP: deflink: RecvEchoReply(0) state = Opened Jun 19 18:57:30 iscar ppp[55]: tun0: Phase: Pap Input: SUCCESS () Jun 19 18:57:30 iscar ppp[55]: tun0: IPCP: Using trigger address 0.0.0.0 Jun 19 18:57:30 iscar ppp[55]: tun0: Phase: deflink: lcp -> open Jun 19 18:57:30 iscar ppp[55]: tun0: Phase: bundle: Network Jun 19 18:57:30 iscar ppp[55]: tun0: IPCP: FSM: Using "deflink" as a transport Jun 19 18:57:30 iscar ppp[55]: tun0: IPCP: deflink: State change Initial --> Closed Jun 19 18:57:30 iscar ppp[55]: tun0: IPCP: deflink: LayerStart. Jun 19 18:57:30 iscar ppp[55]: tun0: IPCP: deflink: SendConfigReq(1) state = Closed Jun 19 18:57:30 iscar ppp[55]: tun0: IPCP: IPADDR[6] 0.0.0.0 Jun 19 18:57:30 iscar ppp[55]: tun0: IPCP: COMPPROTO[6] 16 VJ slots with slot compression Jun 19 18:57:30 iscar ppp[55]: tun0: IPCP: PRIDNS[6] 199.212.134.11 Jun 19 18:57:30 iscar ppp[55]: tun0: IPCP: SECDNS[6] 64.7.128.99 Jun 19 18:57:30 iscar ppp[55]: tun0: IPCP: deflink: State change Closed --> Req-Sent Jun 19 18:57:30 iscar ppp[55]: tun0: IPCP: deflink: RecvConfigReq(1) state = Req-Sent Jun 19 18:57:30 iscar ppp[55]: tun0: IPCP: COMPPROTO[6] 16 VJ slots without slot compression Jun 19 18:57:30 iscar ppp[55]: tun0: IPCP: IPADDR[6] 64.7.134.129 Jun 19 18:57:30 iscar ppp[55]: tun0: IPCP: deflink: SendConfigAck(1) state = Req-Sent Jun 19 18:57:30 iscar ppp[55]: tun0: IPCP: COMPPROTO[6] 16 VJ slots without slot compression Jun 19 18:57:30 iscar ppp[55]: tun0: IPCP: IPADDR[6] 64.7.134.129 Jun 19 18:57:30 iscar ppp[55]: tun0: IPCP: deflink: State change Req-Sent --> Ack-Sent Jun 19 18:57:30 iscar ppp[55]: tun0: IPCP: deflink: RecvConfigReq(2) state = Ack-Sent Jun 19 18:57:30 iscar ppp[55]: tun0: IPCP: COMPPROTO[6] 16 VJ slots without slot compression Jun 19 18:57:30 iscar ppp[55]: tun0: IPCP: IPADDR[6] 64.7.134.129 Jun 19 18:57:30 iscar ppp[55]: tun0: IPCP: deflink: SendConfigAck(2) state = Ack-Sent Jun 19 18:57:30 iscar ppp[55]: tun0: IPCP: COMPPROTO[6] 16 VJ slots without slot compression Jun 19 18:57:30 iscar ppp[55]: tun0: IPCP: IPADDR[6] 64.7.134.129 Jun 19 18:57:30 iscar ppp[55]: tun0: IPCP: deflink: RecvConfigNak(1) state = Ack-Sent Jun 19 18:57:30 iscar ppp[55]: tun0: IPCP: IPADDR[6] 64.7.134.131 Jun 19 18:57:30 iscar ppp[55]: tun0: IPCP: IPADDR[6] changing address: 0.0.0.0 --> 64.7.134.131 Jun 19 18:57:30 iscar ppp[55]: tun0: IPCP: deflink: SendConfigReq(2) state = Ack-Sent Jun 19 18:57:30 iscar ppp[55]: tun0: IPCP: IPADDR[6] 64.7.134.131 Jun 19 18:57:30 iscar ppp[55]: tun0: IPCP: COMPPROTO[6] 16 VJ slots with slot compression Jun 19 18:57:30 iscar ppp[55]: tun0: IPCP: PRIDNS[6] 199.212.134.11 Jun 19 18:57:30 iscar ppp[55]: tun0: IPCP: SECDNS[6] 64.7.128.99 Jun 19 18:57:30 iscar ppp[55]: tun0: IPCP: deflink: RecvConfigAck(2) state = Ack-Sent Jun 19 18:57:30 iscar ppp[55]: tun0: IPCP: deflink: State change Ack-Sent --> Opened Jun 19 18:57:30 iscar ppp[55]: tun0: IPCP: deflink: LayerUp. Jun 19 18:57:30 iscar ppp[55]: tun0: IPCP: myaddr 64.7.134.131 hisaddr = 64.7.134.129 Jun 19 18:57:35 iscar ppp[55]: tun0: LCP: deflink: SendEchoRequest(1) state = Opened Jun 19 18:57:35 iscar ppp[55]: tun0: LCP: deflink: RecvEchoReply(1) state = Opened Jun 19 18:57:40 iscar ppp[55]: tun0: LCP: deflink: RecvEchoRequest(1) state = Opened Jun 19 18:57:40 iscar ppp[55]: tun0: LCP: deflink: SendEchoReply(1) state = Opened Jun 19 18:57:40 iscar ppp[55]: tun0: LCP: deflink: SendEchoRequest(2) state = Opened Jun 19 18:57:40 iscar ppp[55]: tun0: LCP: deflink: RecvEchoReply(2) state = Opened Jun 19 18:57:45 iscar ppp[55]: tun0: LCP: deflink: SendEchoRequest(3) state = Opened Jun 19 18:57:45 iscar ppp[55]: tun0: LCP: deflink: RecvEchoReply(3) state = Opened Jun 19 18:57:50 iscar ppp[55]: tun0: LCP: deflink: SendEchoRequest(4) state = Opened Jun 19 18:57:51 iscar ppp[55]: tun0: LCP: deflink: RecvEchoReply(4) state = Opened Jun 19 18:57:56 iscar ppp[55]: tun0: LCP: deflink: SendEchoRequest(5) state = Opened This was generated using default: #set log Phase Chat LCP IPCP CCP tun command set log +lcp ipcp phase tun command ccp ident user-ppp VERSION (built COMPILATIONDATE) # Ensure that "device" references the correct serial port # for your modem. (cuaa0 = COM1, cuaa1 = COM2) # set timeout 180 # 3 minute idle timer (the default) enable dns # request DNS info (for resolv.conf) papchap: # # edit the next three lines and replace the items in caps with # the values which have been assigned by your ISP. # set phone PHONE_NUM set authname USERNAME set authkey PASSWORD set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0 add default HISADDR # Add a (sticky) default route pppoe: set device PPPoE:fxp1 #set mru 1454 #set mtu 1454 set speed sync enable lqr set lqrperiod 5 disable deflate pred1 mppe deny deflate pred1 mppe set cd 5 set dial set login set timeout 0 set authname username set authkey thepassword set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0 add default HISADDR and the virt template is interface Virtual-Template1 mtu 1492 ip unnumbered Loopback0 peer default ip address pool dynamic1 dynamic2 ppp authentication pap chap callin optional ! I have tried adjusting the virt template to 1452 and 1480 and 1454 without luck. ---Mike At 10:42 PM 6/19/2002 +0100, Brian Somers wrote: >Can you send me a log of the connection with > > set log +lcp ipcp phase tun command ccp > >Cheers. > >On Wed, 19 Jun 2002 15:51:48 -0400, Mike Tancsa wrote: > > > > OK, just completed some more testing. Something is definitely really > > strange between FreeBSD's PPPoE and the ERX. I have 2 FreeBSD boxes in 2 > > different locations, both that were working great off Redbacks. The Telco > > switched out the Redbacks and put Unisphere ERXs in place. At these 2 > > sites, if I take out the FreeBSD boxes and put in either > > Windows 2000, > > Linux 2.4.x > > or a Cisco 827 > > all works great. With FreeBSD, I can browse and fetch data from some > > sites, but not all. The problem sites, transfer rates become bytes per > second. > > If I take out those 2 FreeBSD boxes and move them physically to a > different > > site where its terminated off a redback, all works as expected. > > > > So it would seem one or some of the following > > > > a) Something wrong with my config > > b) Something wrong with the ERX > > c) Something wrong with FreeBSD's PPPoE implementation as far as the > ERX is > > concerned. > > d) Something wrong with my Telco's config. > > > > > > a) is always possible. But the same simple PPPoE config has been working > > for some time and the first box in question only stopped working when the > > telco switch the termination device from a RedBack SMS to the ERX. > > b) Possible, but all the other implementations seem to work > > c) Not sure where to start > > d) Again, certainly possible, but would it not affect all the PPPoE > > implementations equally? > > > > Any help is much appreciated as I dont want to abandon FreeBSD of > course at > > these sites for Linux. > > > > > > ---Mike > > > > >-- >Brian > >Don't _EVER_ lose your sense of humour ! -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 19 16:12: 7 2002 Delivered-To: freebsd-net@freebsd.org Received: from soho1.binc.net (soho1.binc.net [64.73.16.3]) by hub.freebsd.org (Postfix) with SMTP id 51D2937B400 for ; Wed, 19 Jun 2002 16:11:56 -0700 (PDT) Received: (qmail 31621 invoked from network); 19 Jun 2002 23:11:55 -0000 Received: from localhost (HELO the-rob.com) ([127.0.0.1]) (envelope-sender ) by localhost (qmail-ldap-1.03) with SMTP for ; 19 Jun 2002 23:11:55 -0000 Received: from 216.170.184.53 (SquirrelMail authenticated user rob@the-rob.com) by www.soho.berbee.com with HTTP; Wed, 19 Jun 2002 18:11:55 -0500 (CDT) Message-ID: <3756.216.170.184.53.1024528315.squirrel@www.soho.berbee.com> Date: Wed, 19 Jun 2002 18:11:55 -0500 (CDT) Subject: Re:Issues_with_PPPoE_and_4.6 From: To: In-Reply-To: References: Cc: , X-Mailer: SquirrelMail (version 1.2.0 [cvs]) 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 > do the tcpdump with the windows box doing the pppoe.. > i.e. put them on the same ehternet segment. the BSD box just > listenning... > > etc. > > this actually sounds like a FreeBSD (foo) problem. > > 1/ firstly we didn't respond to the initial session (at least not quick > enough) (why not...? 2 seconds is more than enough time) > 2/ We didn't abort when the link was closed.. Here is the windows dump Hope it helps. 18:09:12.652151 0:1:2:26:2d:a2 Broadcast 8863 60: PPPoE PADI [Host-Uniq UTF8] 18:09:12.682797 0:2:4b:a4:b7:87 0:1:2:26:2d:a2 8863 77: PPPoE PADO [Host- Uniq UTF8] [Service-Name] [AC-Name "miwi-6400-inet-nrp0"] [AC-Cookie UTF8] 18:09:12.682878 0:1:2:26:2d:a2 0:2:4b:a4:b7:87 8863 60: PPPoE PADR [Host- Uniq UTF8] [Service-Name] [AC-Cookie UTF8] 18:09:13.070138 0:2:4b:a4:b7:87 0:1:2:26:2d:a2 8863 60: PPPoE PADS [ses 0x326] [Host-Uniq UTF8] [Service-Name] [AC-Cookie UTF8] 18:09:13.072777 0:1:2:26:2d:a2 0:2:4b:a4:b7:87 8864 60: PPPoE [ses 0x326] LCP 12: Conf-Req(1), Magic-Num=703d0c48 18:09:13.105383 0:2:4b:a4:b7:87 0:1:2:26:2d:a2 8864 60: PPPoE [ses 0x326] LCP 20: Conf-Req(1), MRU=1492, Auth-Prot PAP, Magic-Num=767da987 18:09:13.132895 0:1:2:26:2d:a2 0:2:4b:a4:b7:87 8864 60: PPPoE [ses 0x326] LCP 20: Conf-Ack(1), MRU=1492, Auth-Prot PAP, Magic-Num=767da987 18:09:15.103280 0:2:4b:a4:b7:87 0:1:2:26:2d:a2 8864 60: PPPoE [ses 0x326] LCP 20: Conf-Req(2), MRU=1492, Auth-Prot PAP, Magic-Num=767da987 18:09:15.116155 0:1:2:26:2d:a2 0:2:4b:a4:b7:87 8864 60: PPPoE [ses 0x326] LCP 20: Conf-Ack(2), MRU=1492, Auth-Prot PAP, Magic-Num=767da987 18:09:16.378230 0:1:2:26:2d:a2 0:2:4b:a4:b7:87 8864 60: PPPoE [ses 0x326] LCP 12: Conf-Req(2), Magic-Num=703d0c48 18:09:16.391005 0:2:4b:a4:b7:87 0:1:2:26:2d:a2 8864 60: PPPoE [ses 0x326] LCP 12: Conf-Ack(2), Magic-Num=703d0c48 18:09:16.438310 0:1:2:26:2d:a2 0:2:4b:a4:b7:87 8864 60: PPPoE [ses 0x326] PAP 25: Auth-Req(1), Peer=, Name= 18:09:16.594322 0:2:4b:a4:b7:87 0:1:2:26:2d:a2 8864 60: PPPoE [ses 0x326] PAP 7: Auth-Ack(1), Msg= 18:09:16.595762 0:2:4b:a4:b7:87 0:1:2:26:2d:a2 8864 60: PPPoE [ses 0x326] IPCP 12: Conf-Req(1), IP-Addr=216.170.184.1 18:09:16.618623 0:1:2:26:2d:a2 0:2:4b:a4:b7:87 8864 60: PPPoE [ses 0x326] IPCP 36: Conf-Req(1), IP-Addr=0.0.0.0, Pri-DNS=0.0.0.0, Sec-DNS=0.0.0.0, Pri-NBNS=0.0.0.0, Sec-NBNS=0.0.0.0 18:09:16.618658 0:1:2:26:2d:a2 0:2:4b:a4:b7:87 8864 60: PPPoE [ses 0x326] IPCP 12: Conf-Ack(1), IP-Addr=216.170.184.1 18:09:16.632239 0:2:4b:a4:b7:87 0:1:2:26:2d:a2 8864 60: PPPoE [ses 0x326] IPCP 18: Conf-Rej(1), Pri-NBNS=0.0.0.0, Sec-NBNS=0.0.0.0 18:09:16.670925 0:2:4b:a4:b7:87 0:1:2:26:2d:a2 8864 60: PPPoE [ses 0x326] LCP 14: Echo-Req(1), Magic-Num=767da987 18:09:16.678709 0:1:2:26:2d:a2 0:2:4b:a4:b7:87 8864 60: PPPoE [ses 0x326] LCP 14: Echo-Rep(1), Magic-Num=703d0c48 18:09:16.678747 0:1:2:26:2d:a2 0:2:4b:a4:b7:87 8864 60: PPPoE [ses 0x326] IPCP 24: Conf-Req(2), IP-Addr=0.0.0.0, Pri-DNS=0.0.0.0, Sec-DNS=0.0.0.0 18:09:16.693843 0:2:4b:a4:b7:87 0:1:2:26:2d:a2 8864 60: PPPoE [ses 0x326] IPCP 24: Conf-Nak(2), IP-Addr=216.170.184.53, Pri-DNS=204.246.1.20, Sec- DNS=204.70.128.1 18:09:16.738811 0:1:2:26:2d:a2 0:2:4b:a4:b7:87 8864 60: PPPoE [ses 0x326] IPCP 24: Conf-Req(3), IP-Addr=216.170.184.53, Pri-DNS=204.246.1.20, Sec- DNS=204.70.128.1 18:09:16.752490 0:2:4b:a4:b7:87 0:1:2:26:2d:a2 8864 60: PPPoE [ses 0x326] IPCP 24: Conf-Ack(3), IP-Addr=216.170.184.53, Pri-DNS=204.246.1.20, Sec- DNS=204.70.128.1 18:09:17.607581 0:2:4b:a4:b7:87 0:1:2:26:2d:a2 8864 70: PPPoE [ses 0x326] IP 50: 62.166.35.142.61952 > 216.170.184.53.1214: S 4260125279:4260125279 (0) win 4380 (DF) 18:09:17.769473 0:2:4b:a4:b7:87 0:1:2:26:2d:a2 8864 70: PPPoE [ses 0x326] IP 50: 24.30.145.50.37954 > 216.170.184.53.1214: S 15397360:15397360(0) win 8192 (DF) 18:09:19.263912 0:2:4b:a4:b7:87 0:1:2:26:2d:a2 8864 70: PPPoE [ses 0x326] IP 50: 67.1.188.124.2550 > 216.170.184.53.1214: S 8331921:8331921(0) win 8192 (DF) 18:09:19.686673 0:1:2:26:2d:a2 0:2:4b:a4:b7:87 8864 118: PPPoE [ses 0x326] IP 98: 216.170.184.53.netbios-ns > 216.170.184.255.netbios-ns: 18:09:19.703270 0:2:4b:a4:b7:87 0:1:2:26:2d:a2 8864 78: PPPoE [ses 0x326] IP 58: 216.170.184.1 > 216.170.184.53: icmp: redirect 216.170.184.255 to net 216.170.184.255 18:09:20.296373 0:2:4b:a4:b7:87 0:1:2:26:2d:a2 8864 70: PPPoE [ses 0x326] IP 50: 80.0.125.42.blackjack > 216.170.184.53.1214: S 1165994832:1165994832 (0) win 16384 (DF) 18:09:20.308444 0:2:4b:a4:b7:87 0:1:2:26:2d:a2 8864 70: PPPoE [ses 0x326] IP 50: 200.59.193.178.www-dev > 216.170.184.53.1214: S 37978266:37978266(0) win 2144 (DF) 18:09:20.308550 0:1:2:26:2d:a2 0:2:4b:a4:b7:87 8864 62: PPPoE [ses 0x326] IP 42: 216.170.184.53.1214 > 80.0.125.42.blackjack: R 0:0(0) ack 1165994833 win 0 18:09:20.308559 0:1:2:26:2d:a2 0:2:4b:a4:b7:87 8864 62: PPPoE [ses 0x326] IP 42: 216.170.184.53.1214 > 200.59.193.178.www-dev: R 0:0(0) ack 37978267 win 0 18:09:20.434987 0:1:2:26:2d:a2 0:2:4b:a4:b7:87 8864 118: PPPoE [ses 0x326] IP 98: 216.170.184.53.netbios-ns > 216.170.184.255.netbios-ns: 18:09:20.448665 0:2:4b:a4:b7:87 0:1:2:26:2d:a2 8864 78: PPPoE [ses 0x326] IP 58: 216.170.184.1 > 216.170.184.53: icmp: redirect 216.170.184.255 to net 216.170.184.255 18:09:20.782778 0:2:4b:a4:b7:87 0:1:2:26:2d:a2 8864 70: PPPoE [ses 0x326] IP 50: 24.30.145.50.37954 > 216.170.184.53.1214: S 15397360:15397360(0) win 8192 (DF) 18:09:20.797644 0:1:2:26:2d:a2 0:2:4b:a4:b7:87 8864 62: PPPoE [ses 0x326] IP 42: 216.170.184.53.1214 > 24.30.145.50.37954: R 0:0(0) ack 1 win 0 18:09:20.800072 0:1:2:26:2d:a2 0:2:4b:a4:b7:87 8864 60: PPPoE [ses 0x326] IP 30: 216.170.184.53 > 204.246.1.20: icmp: echo request 18:09:20.814804 0:2:4b:a4:b7:87 0:1:2:26:2d:a2 8864 60: PPPoE [ses 0x326] IP 30: 204.246.1.20 > 216.170.184.53: icmp: echo reply (DF) 18:09:20.815668 0:1:2:26:2d:a2 0:2:4b:a4:b7:87 8864 60: PPPoE [ses 0x326] IP 30: 216.170.184.53 > 204.70.128.1: icmp: echo request 18:09:20.863592 0:2:4b:a4:b7:87 0:1:2:26:2d:a2 8864 60: PPPoE [ses 0x326] IP 30: 204.70.128.1 > 216.170.184.53: icmp: echo reply (DF) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 19 17: 0:26 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id 5C5E737B413; Wed, 19 Jun 2002 17:00:10 -0700 (PDT) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020620000010.UDKT11426.rwcrmhc51.attbi.com@InterJet.elischer.org>; Thu, 20 Jun 2002 00:00:10 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id QAA27636; Wed, 19 Jun 2002 16:49:42 -0700 (PDT) Date: Wed, 19 Jun 2002 16:49:40 -0700 (PDT) From: Julian Elischer To: rob@the-rob.com Cc: net@freebsd.org, brian@freebsd.org Subject: Re:Issues_with_PPPoE_and_4.6 In-Reply-To: <3756.216.170.184.53.1024528315.squirrel@www.soho.berbee.com> Message-ID: 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 Wed, 19 Jun 2002 rob@the-rob.com wrote: > > do the tcpdump with the windows box doing the pppoe.. > > i.e. put them on the same ehternet segment. the BSD box just > > listenning... > > > > > > > etc. > > > > this actually sounds like a FreeBSD (foo) problem. > > > > 1/ firstly we didn't respond to the initial session (at least not quick > > enough) (why not...? 2 seconds is more than enough time) > > 2/ We didn't abort when the link was closed.. > > > Here is the windows dump Hope it helps. > > 18:09:12.652151 0:1:2:26:2d:a2 Broadcast 8863 60: PPPoE PADI [Host-Uniq UTF8] PC: "you there tower?" > 18:09:12.682797 0:2:4b:a4:b7:87 0:1:2:26:2d:a2 8863 77: PPPoE PADO [Host- Uniq UTF8] [Service-Name] [AC-Name "miwi-6400-inet-nrp0"] [AC-Cookie UTF8] ISP: yep > 18:09:12.682878 0:1:2:26:2d:a2 0:2:4b:a4:b7:87 8863 60: PPPoE PADR [Host- Uniq UTF8] [Service-Name] [AC-Cookie UTF8] PC: "got a session for me?" > 18:09:13.070138 0:2:4b:a4:b7:87 0:1:2:26:2d:a2 8863 60: PPPoE PADS [ses 0x326] [Host-Uniq UTF8] [Service-Name] [AC-Cookie UTF8] ISP: "yep, try 0x326" > 18:09:13.072777 0:1:2:26:2d:a2 0:2:4b:a4:b7:87 8864 60: PPPoE [ses 0x326] LCP 12: Conf-Req(1), Magic-Num=703d0c48 PC: (on session 326: "startup ppp" totoal time elapsed 0.420626 seconds.. so the problem is definitly with the FreeBSD.. BTW I assume you DID power down the modem between sessions? sometimes they remember MAC addresses.. and add confusion. now what would be good would be simultaneously recording a tcpdump session of the first few packets and showing a verbose ppp log .. set the following for ppp. set log +lcp ipcp phase tun command ccp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 19 17:24: 4 2002 Delivered-To: freebsd-net@freebsd.org Received: from soho1.binc.net (soho1.binc.net [64.73.16.3]) by hub.freebsd.org (Postfix) with SMTP id 1B5A837B414 for ; Wed, 19 Jun 2002 17:23:54 -0700 (PDT) Received: (qmail 30186 invoked from network); 20 Jun 2002 00:23:53 -0000 Received: from localhost (HELO the-rob.com) ([127.0.0.1]) (envelope-sender ) by localhost (qmail-ldap-1.03) with SMTP for ; 20 Jun 2002 00:23:52 -0000 Received: from 216.170.185.66 (SquirrelMail authenticated user rob@the-rob.com) by www.soho.berbee.com with HTTP; Wed, 19 Jun 2002 19:23:53 -0500 (CDT) Message-ID: <4064.216.170.185.66.1024532633.squirrel@www.soho.berbee.com> Date: Wed, 19 Jun 2002 19:23:53 -0500 (CDT) Subject: Re:Issues_with_PPPoE_and_4.6 From: To: In-Reply-To: References: Cc: , , X-Mailer: SquirrelMail (version 1.2.0 [cvs]) 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 > BTW I assume you DID power down the modem between sessions? > sometimes they remember MAC addresses.. and add confusion. Yep, I've been walking my modem back and forth between rooms. > now what would be good would be simultaneously recording a tcpdump > session of the first few packets and showing a verbose ppp log .. > > set the following for ppp. > > set log +lcp ipcp phase tun command ccp done. here is tcpdump -i xl0 -e and /var/log/ppp.log 19:13:12.316811 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0x41e] LCP 20: Conf-Req(6), MRU=1492, Auth-Prot PAP, Magic-Num= 76b84620 19:13:14.318081 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0x41e] LCP 20: Conf-Req(7), MRU=1492, Auth-Prot PAP, Magic-Num= 76b84620 19:13:16.318618 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0x41e] LCP 20: Conf-Req(8), MRU=1492, Auth-Prot PAP, Magic-Num= 76b84620 19:13:18.319397 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0x41e] LCP 20: Conf-Req(9), MRU=1492, Auth-Prot PAP, Magic-Num= 76b84620 19:13:20.381296 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0x41e] LCP 20: Conf-Req(10), MRU=1492, Auth-Prot PAP, Magic-Num =76b84620 19:13:22.381087 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8863 60: PPPoE PADT [ses 0x41e] 19:13:34.938184 0:4:76:b8:26:7c Broadcast 8863 32: PPPoE PADI [Host-Uniq UTF8] 19:13:36.933311 0:4:76:b8:26:7c Broadcast 8863 32: PPPoE PADI [Host-Uniq UTF8] 19:13:37.011352 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8863 75: PPPoE PADO [Host- Uniq UTF8] [Service-Name] [AC-Name "miwi-6400-inet-nrp0"] [AC-Cookie UTF8] 19:13:37.011438 0:4:76:b8:26:7c 0:2:4b:a4:b7:87 8863 75: PPPoE PADR [Host- Uniq UTF8] [AC-Cookie UTF8] [AC-Name "miwi-6400-inet-nrp0" ] 19:13:37.424289 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8863 75: PPPoE PADS [ses 0x420] [Host-Uniq UTF8] [AC-Cookie UTF8] [AC-Name "miwi-640 0-inet-nrp0"] 19:13:37.443722 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0x420] LCP 20: Conf-Req(1), MRU=1492, Auth-Prot PAP, Magic-Num= 76b8cf4e 19:13:39.440323 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0x420] LCP 20: Conf-Req(2), MRU=1492, Auth-Prot PAP, Magic-Num= 76b8cf4e 19:13:39.985084 0:4:76:b8:26:7c 0:2:4b:a4:b7:87 8863 38: PPPoE PADT [ses 0x420] [Generic-Error "session closed"] 19:13:41.440618 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0x420] LCP 20: Conf-Req(3), MRU=1492, Auth-Prot PAP, Magic-Num= 76b8cf4e 19:13:43.441888 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0x420] LCP 20: Conf-Req(4), MRU=1492, Auth-Prot PAP, Magic-Num= 76b8cf4e 19:13:45.442922 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0x420] LCP 20: Conf-Req(5), MRU=1492, Auth-Prot PAP, Magic-Num= 76b8cf4e 19:13:47.443709 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0x420] LCP 20: Conf-Req(6), MRU=1492, Auth-Prot PAP, Magic-Num= 76b8cf4e 19:13:49.530228 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0x420] LCP 20: Conf-Req(7), MRU=1492, Auth-Prot PAP, Magic-Num= 76b8cf4e 19:13:51.529866 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0x420] LCP 20: Conf-Req(8), MRU=1492, Auth-Prot PAP, Magic-Num= 76b8cf4e 19:13:53.530308 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0x420] LCP 20: Conf-Req(9), MRU=1492, Auth-Prot PAP, Magic-Num= 76b8cf4e 19:13:55.531092 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0x420] LCP 20: Conf-Req(10), MRU=1492, Auth-Prot PAP, Magic-Num =76b8cf4e 19:13:57.533588 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8863 60: PPPoE PADT [ses 0x420] Jun 19 19:13:39 PITA ppp[72]: tun0: Phase: deflink: hangup -> opening Jun 19 19:13:39 PITA ppp[72]: tun0: Phase: deflink: Enter pause (30) for redialing. Jun 19 19:14:10 PITA ppp[72]: tun0: Phase: deflink: Connected! Jun 19 19:14:10 PITA ppp[72]: tun0: Phase: deflink: opening -> dial Jun 19 19:14:10 PITA ppp[72]: tun0: Phase: deflink: dial -> carrier Jun 19 19:14:13 PITA ppp[72]: tun0: Phase: Received NGM_PPPOE_ACNAME (hook "miwi-6400-inet-n¼ù¿¿¯â^G^HM-^@± ^H^P ^K^H") Jun 19 19:14:14 PITA ppp[72]: tun0: Phase: Received NGM_PPPOE_<11> (hook "$^D^H^Hh ^K^H") Jun 19 19:14:15 PITA ppp[72]: tun0: Phase: deflink: Disconnected! Jun 19 19:14:15 PITA ppp[72]: tun0: Phase: deflink: carrier -> hangup Jun 19 19:14:15 PITA ppp[72]: tun0: Phase: deflink: Connect time: 5 secs: 0 octets in, 0 octets out Jun 19 19:14:15 PITA ppp[72]: tun0: Phase: deflink: : 0 packets in, 0 packets out Jun 19 19:14:15 PITA ppp[72]: tun0: Phase: total 0 bytes/sec, peak 0 bytes/sec on Wed Jun 19 19:14:10 2002 Jun 19 19:14:15 PITA ppp[72]: tun0: Phase: deflink: hangup -> opening Jun 19 19:14:15 PITA ppp[72]: tun0: Phase: deflink: Enter pause (30) for redialing. Jun 19 19:14:45 PITA ppp[72]: tun0: Phase: deflink: Connected! Jun 19 19:14:45 PITA ppp[72]: tun0: Phase: deflink: opening -> dial Jun 19 19:14:45 PITA ppp[72]: tun0: Phase: deflink: dial -> carrier Jun 19 19:14:48 PITA ppp[72]: tun0: Phase: Received NGM_PPPOE_ACNAME (hook "miwi-6400-inet-n¼ù¿¿¯â^G^HM-^@± ^H^P ^K^H") Jun 19 19:14:49 PITA ppp[72]: tun0: Phase: Received NGM_PPPOE_<11> (hook "(^D^H^Hh ^K^H") Jun 19 19:14:50 PITA ppp[72]: tun0: Phase: deflink: Disconnected! Jun 19 19:14:50 PITA ppp[72]: tun0: Phase: deflink: carrier -> hangup Jun 19 19:14:50 PITA ppp[72]: tun0: Phase: deflink: Connect time: 5 secs: 0 octets in, 0 octets out Jun 19 19:14:50 PITA ppp[72]: tun0: Phase: deflink: : 0 packets in, 0 packets out Jun 19 19:14:50 PITA ppp[72]: tun0: Phase: total 0 bytes/sec, peak 0 bytes/sec on Wed Jun 19 19:14:45 2002 Jun 19 19:14:50 PITA ppp[72]: tun0: Phase: deflink: hangup -> opening Jun 19 19:14:50 PITA ppp[72]: tun0: Phase: deflink: Enter pause (30) for redialing. Jun 19 19:15:20 PITA ppp[72]: tun0: Phase: deflink: Connected! Jun 19 19:15:20 PITA ppp[72]: tun0: Phase: deflink: opening -> dial Jun 19 19:15:20 PITA ppp[72]: tun0: Phase: deflink: dial -> carrier Jun 19 19:15:23 PITA ppp[72]: tun0: Phase: Received NGM_PPPOE_ACNAME (hook "miwi-6400-inet-n¼ù¿¿¯â^G^HM-^@± ^H^P ^K^H") Jun 19 19:15:24 PITA ppp[72]: tun0: Phase: Received NGM_PPPOE_<11> (hook "*^D^H^Hh ^K^H") Jun 19 19:15:25 PITA ppp[72]: tun0: Phase: deflink: Disconnected! Jun 19 19:15:25 PITA ppp[72]: tun0: Phase: deflink: carrier -> hangup Jun 19 19:15:25 PITA ppp[72]: tun0: Phase: deflink: Connect time: 5 secs: 0 octets in, 0 octets out Jun 19 19:15:25 PITA ppp[72]: tun0: Phase: deflink: : 0 packets in, 0 packets out Jun 19 19:15:25 PITA ppp[72]: tun0: Phase: total 0 bytes/sec, peak 0 bytes/sec on Wed Jun 19 19:15:20 2002 Jun 19 19:15:25 PITA ppp[72]: tun0: Phase: deflink: hangup -> opening Jun 19 19:15:25 PITA ppp[72]: tun0: Phase: deflink: Enter pause (30) for redialing. Jun 19 19:15:55 PITA ppp[72]: tun0: Phase: deflink: Connected! Jun 19 19:15:55 PITA ppp[72]: tun0: Phase: deflink: opening -> dial Jun 19 19:15:55 PITA ppp[72]: tun0: Phase: deflink: dial -> carrier Jun 19 19:15:58 PITA ppp[72]: tun0: Phase: Received NGM_PPPOE_ACNAME (hook "miwi-6400-inet-n¼ù¿¿¯â^G^HM-^@± ^H^P ^K^H") Jun 19 19:15:59 PITA ppp[72]: tun0: Phase: Received NGM_PPPOE_<11> (hook "+^D^H^Hh ^K^H") Jun 19 19:16:00 PITA ppp[72]: tun0: Phase: deflink: Disconnected! Jun 19 19:16:00 PITA ppp[72]: tun0: Phase: deflink: carrier -> hangup Jun 19 19:16:00 PITA ppp[72]: tun0: Phase: deflink: Connect time: 5 secs: 0 octets in, 0 octets out Jun 19 19:16:00 PITA ppp[72]: tun0: Phase: deflink: : 0 packets in, 0 packets out Jun 19 19:16:00 PITA ppp[72]: tun0: Phase: total 0 bytes/sec, peak 0 bytes/sec on Wed Jun 19 19:15:55 2002 Jun 19 19:16:00 PITA ppp[72]: tun0: Phase: deflink: hangup -> opening Jun 19 19:16:00 PITA ppp[72]: tun0: Phase: deflink: Enter pause (30) for redialing. PITA# To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 19 18: 7: 5 2002 Delivered-To: freebsd-net@freebsd.org Received: from tp.databus.com (p72-186.acedsl.com [66.114.72.186]) by hub.freebsd.org (Postfix) with ESMTP id 7776A37B414 for ; Wed, 19 Jun 2002 18:07:00 -0700 (PDT) Received: from databus.com (localhost.databus.com [127.0.0.1]) by tp.databus.com (8.12.3/8.12.3) with ESMTP id g5K16pGC036718; Wed, 19 Jun 2002 21:06:51 -0400 (EDT) (envelope-from barney@databus.com) Received: (from barney@localhost) by databus.com (8.12.3/8.12.3/Submit) id g5K16ktV036717; Wed, 19 Jun 2002 21:06:46 -0400 (EDT) Date: Wed, 19 Jun 2002 21:06:46 -0400 From: Barney Wolff To: "McKenna, Lee" Cc: "'Fabien THOMAS'" , paleph@pacbell.net, freebsd-net@FreeBSD.ORG Subject: Re: bge driver issue Message-ID: <20020619210646.A36559@tp.databus.com> References: <3EA88113DE92D211807300805FA7994209149EC2@chaplin.lodgenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3EA88113DE92D211807300805FA7994209149EC2@chaplin.lodgenet.com>; from lmckenna@lodgenet.com on Wed, Jun 19, 2002 at 01:46:40PM -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 Er, you would appear to be measuring the transfer rate of your disk, unless you actually have enough ram to cache a 1.2GB file. By coincidence, tonight I hooked my dual 1.0GHz PIII running fbsd 4.6-stable to a Mac G4 OS-X (also dual 1GHz cpus) using an Intel PRO/1000T desktop adapter on the fbsd side. Here's the result of the Mac doing an ftp get from fbsd: ftp> get X11R6-011112.tgz /dev/null local: /dev/null remote: X11R6-011112.tgz 200 PORT command successful. 150 Opening BINARY mode data connection for 'X11R6-011112.tgz' (194432456 bytes). 226 Transfer complete. 194432456 bytes received in 6.45 seconds (30123284 bytes/s) ftp> get X11R6-011112.tgz /dev/null local: /dev/null remote: X11R6-011112.tgz 200 PORT command successful. 150 Opening BINARY mode data connection for 'X11R6-011112.tgz' (194432456 bytes). 226 Transfer complete. 194432456 bytes received in 1.76 seconds (110555016 bytes/s) The first transfer shows the speed of my disk. The second is really pretty good. Adding in the header overhead, we're over 920 Mbps. Going in the other direction I never got over 500 Mbps, don't yet know why. Windows were 65535 on both sides. Bumping the window over 100KB resulted in a sharp drop in performance, also as yet unexplained. Setting the send window above about 200KB resulted in failure to open a connection - no bufs available. That too will need some investigation. The test was run through a Dell 2508 switch - I could not get 1000baseTX with a crossover cable, but perhaps it was not good enough, although marked cat5. On Wed, Jun 19, 2002 at 01:46:40PM -0500, McKenna, Lee wrote: > I just loaded 4.5-RELEASE, and cvsup/make world upgraded to 4.6-STABLE dated > June 17, and have 2 machines with 3C996B-T cards using the bge driver with > the two machines connected directly to each other using a crossover cable. > Machines are both "home made" with Supermicro mobos with 1.2GHz CPUs. > > Using /dev/zero I created a file some 1.2 GBytes in size. I am getting 7 > MBytes/s using scp and 30 MBytes/s using ftp. So, it looks like the max is > about 240 Mbits/s. This is why we affectionately call gigabit Ethernet "a > couple-hundred megabit ethernet", and we cant wait for Ken's zero copy code > to reach -STABLE :) > > This test also includes tweaking the tcp and udp send and recv space buffers > to 512K, by the way... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 19 18:42:23 2002 Delivered-To: freebsd-net@freebsd.org Received: from soho1.binc.net (soho1.binc.net [64.73.16.3]) by hub.freebsd.org (Postfix) with SMTP id 59C9737B405 for ; Wed, 19 Jun 2002 18:42:09 -0700 (PDT) Received: (qmail 25035 invoked from network); 20 Jun 2002 01:42:08 -0000 Received: from localhost (HELO the-rob.com) ([127.0.0.1]) (envelope-sender ) by localhost (qmail-ldap-1.03) with SMTP for ; 20 Jun 2002 01:42:08 -0000 Received: from 216.170.186.25 (SquirrelMail authenticated user rob@the-rob.com) by www.soho.berbee.com with HTTP; Wed, 19 Jun 2002 20:42:08 -0500 (CDT) Message-ID: <4382.216.170.186.25.1024537328.squirrel@www.soho.berbee.com> Date: Wed, 19 Jun 2002 20:42:08 -0500 (CDT) Subject: [Fwd: Re:Issues_with_PPPoE_and_4.6] From: To: X-Mailer: SquirrelMail (version 1.2.0 [cvs]) 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 forgot reply to all. -------- Original Message -------- Subject: Re:Issues_with_PPPoE_and_4.6 From: To: > unfortunatly it doesn;t look like these were SIMULTANEOUS sessions.. > when you examine the timestamps it appears that they do not cover the > same connection attempt... > > the tcpdump covers 19:13:12 -> 19:13:57. > and the ppp log covers 19:13:39 -> 19:16:00 > > which overlaps, but th e PADI negotioation all happens between 19:13:34 > and 19:13:39.4 which is all before the ppp log started.. here it is again tcpdump 20:30:56 -> 20:31:37 /var/log/ppp.log 20:30:49 -> 20:31:44 Here is the dump and the ppp.conf at the end just to make sure I have the logging options setup as you requested. 20:30:56.683293 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0x55f] LCP 20: Conf-Req(5), MRU=1492, Auth-Prot PAP, Magic-Num= 76ff7611 20:30:58.684063 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0x55f] LCP 20: Conf-Req(6), MRU=1492, Auth-Prot PAP, Magic-Num= 76ff7611 20:31:00.763678 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0x55f] LCP 20: Conf-Req(7), MRU=1492, Auth-Prot PAP, Magic-Num= 76ff7611 20:31:02.764955 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0x55f] LCP 20: Conf-Req(8), MRU=1492, Auth-Prot PAP, Magic-Num= 76ff7611 20:31:03.973960 0:4:76:b8:26:7c Broadcast arp 42: arp who-has 10.0.0.1 (20:63:61:72:72:69) tell 10.0.0.1 20:31:04.319409 0:4:76:b8:26:7c Broadcast 8863 32: PPPoE PADI [Host-Uniq UTF8] 20:31:04.766025 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0x55f] LCP 20: Conf-Req(9), MRU=1492, Auth-Prot PAP, Magic-Num= 76ff7611 20:31:06.313453 0:4:76:b8:26:7c Broadcast 8863 32: PPPoE PADI [Host-Uniq UTF8] 20:31:06.339572 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8863 75: PPPoE PADO [Host- Uniq UTF8] [Service-Name] [AC-Name "miwi-6400-inet-nrp0"] [AC-Cookie UTF8] 20:31:06.339656 0:4:76:b8:26:7c 0:2:4b:a4:b7:87 8863 75: PPPoE PADR [Host- Uniq UTF8] [AC-Cookie UTF8] [AC-Name "miwi-6400-inet-nrp0" ] 20:31:06.777365 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0x55f] LCP 20: Conf-Req(10), MRU=1492, Auth-Prot PAP, Magic-Num =76ff7611 20:31:06.818273 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8863 75: PPPoE PADS [ses 0x560] [Host-Uniq UTF8] [AC-Cookie UTF8] [AC-Name "miwi-640 0-inet-nrp0"] 20:31:06.848555 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0x560] LCP 20: Conf-Req(1), MRU=1492, Auth-Prot PAP, Magic-Num= 76ffbd03 20:31:08.777901 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8863 60: PPPoE PADT [ses 0x55f] 20:31:08.895167 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0x560] LCP 20: Conf-Req(2), MRU=1492, Auth-Prot PAP, Magic-Num= 76ffbd03 20:31:09.365445 0:4:76:b8:26:7c 0:2:4b:a4:b7:87 8863 38: PPPoE PADT [ses 0x560] [Generic-Error "session closed"] 20:31:10.893737 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0x560] LCP 20: Conf-Req(3), MRU=1492, Auth-Prot PAP, Magic-Num= 76ffbd03 20:31:12.894763 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0x560] LCP 20: Conf-Req(4), MRU=1492, Auth-Prot PAP, Magic-Num= 76ffbd03 20:31:14.895535 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0x560] LCP 20: Conf-Req(5), MRU=1492, Auth-Prot PAP, Magic-Num= 76ffbd03 20:31:16.896818 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0x560] LCP 20: Conf-Req(6), MRU=1492, Auth-Prot PAP, Magic-Num= 76ffbd03 20:31:18.897602 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0x560] LCP 20: Conf-Req(7), MRU=1492, Auth-Prot PAP, Magic-Num= 76ffbd03 20:31:19.318397 0:4:76:b8:26:7c Broadcast 8863 32: PPPoE PADI [Host-Uniq UTF8] 20:31:20.898634 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0x560] LCP 20: Conf-Req(8), MRU=1492, Auth-Prot PAP, Magic-Num= 76ffbd03 20:31:21.313674 0:4:76:b8:26:7c Broadcast 8863 32: PPPoE PADI [Host-Uniq UTF8] 20:31:21.485248 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8863 75: PPPoE PADO [Host- Uniq UTF8] [Service-Name] [AC-Name "miwi-6400-inet-nrp0"] [AC-Cookie UTF8] 20:31:21.485325 0:4:76:b8:26:7c 0:2:4b:a4:b7:87 8863 75: PPPoE PADR [Host- Uniq UTF8] [AC-Cookie UTF8] [AC-Name "miwi-6400-inet-nrp0" ] 20:31:21.853316 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8863 75: PPPoE PADS [ses 0x562] [Host-Uniq UTF8] [AC-Cookie UTF8] [AC-Name "miwi-640 0-inet-nrp0"] 20:31:21.875986 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0x562] LCP 20: Conf-Req(1), MRU=1492, Auth-Prot PAP, Magic-Num= 76fff7b1 20:31:22.899403 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0x560] LCP 20: Conf-Req(9), MRU=1492, Auth-Prot PAP, Magic-Num= 76ffbd03 20:31:23.876023 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0x562] LCP 20: Conf-Req(2), MRU=1492, Auth-Prot PAP, Magic-Num= 76fff7b1 20:31:24.365475 0:4:76:b8:26:7c 0:2:4b:a4:b7:87 8863 38: PPPoE PADT [ses 0x562] [Generic-Error "session closed"] 20:31:24.900197 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0x560] LCP 20: Conf-Req(10), MRU=1492, Auth-Prot PAP, Magic-Num =76ffbd03 20:31:25.876806 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0x562] LCP 20: Conf-Req(3), MRU=1492, Auth-Prot PAP, Magic-Num= 76fff7b1 20:31:26.901464 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8863 60: PPPoE PADT [ses 0x560] 20:31:27.878089 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0x562] LCP 20: Conf-Req(4), MRU=1492, Auth-Prot PAP, Magic-Num= 76fff7b1 20:31:29.878869 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0x562] LCP 20: Conf-Req(5), MRU=1492, Auth-Prot PAP, Magic-Num= 76fff7b1 20:31:31.879407 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0x562] LCP 20: Conf-Req(6), MRU=1492, Auth-Prot PAP, Magic-Num= 76fff7b1 20:31:33.880174 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0x562] LCP 20: Conf-Req(7), MRU=1492, Auth-Prot PAP, Magic-Num= 76fff7b1 20:31:35.880966 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0x562] LCP 20: Conf-Req(8), MRU=1492, Auth-Prot PAP, Magic-Num= 76fff7b1 20:31:37.881996 0:2:4b:a4:b7:87 0:4:76:b8:26:7c 8864 60: PPPoE [ses 0x562] LCP 20: Conf-Req(9), MRU=1492, Auth-Prot PAP, Magic-Num= 76fff7b1 %less ppp Jun 19 20:30:49 PITA ppp[72]: tun0: Phase: deflink: hangup -> opening Jun 19 20:30:49 PITA ppp[72]: tun0: Phase: deflink: Enter pause (30) for redialing. Jun 19 20:31:04 PITA ppp[309]: Phase: Using interface: tun1 Jun 19 20:31:04 PITA ppp[309]: Phase: deflink: Created in closed state Jun 19 20:31:04 PITA ppp[309]: tun1: Command: default: add default HISADDR Jun 19 20:31:04 PITA ppp[309]: tun1: Command: default: enable dns Jun 19 20:31:04 PITA ppp[309]: tun1: Command: tds: set authname rzietlow2 Jun 19 20:31:04 PITA ppp[309]: tun1: Command: tds: set authkey ******** Jun 19 20:31:04 PITA ppp[310]: tun1: Phase: PPP Started (ddial mode). Jun 19 20:31:04 PITA ppp[310]: tun1: Phase: bundle: Establish Jun 19 20:31:04 PITA ppp[310]: tun1: Phase: deflink: closed -> opening Jun 19 20:31:04 PITA ppp[310]: tun1: Phase: deflink: Connected! Jun 19 20:31:04 PITA ppp[310]: tun1: Phase: deflink: opening -> dial Jun 19 20:31:04 PITA ppp[310]: tun1: Phase: deflink: dial -> carrier Jun 19 20:31:07 PITA ppp[310]: tun1: Phase: Received NGM_PPPOE_ACNAME (hook "miwi-6400-inet-n^G^HM-^@ ^H ^P^P^K^H") Jun 19 20:31:08 PITA ppp[310]: tun1: Phase: Received NGM_PPPOE_<11> (hook "`^E^H^Hh^P^K^H") Jun 19 20:31:09 PITA ppp[310]: tun1: Phase: deflink: Disconnected! Jun 19 20:31:09 PITA ppp[310]: tun1: Phase: deflink: carrier -> hangup Jun 19 20:31:09 PITA ppp[310]: tun1: Phase: deflink: Connect time: 5 secs: 0 octets in, 0 octets out Jun 19 20:31:09 PITA ppp[310]: tun1: Phase: deflink: : 0 packets in, 0 packets out Jun 19 20:31:09 PITA ppp[310]: tun1: Phase: total 0 bytes/sec, peak 0 bytes/sec on Wed Jun 19 20:31:04 2002 Jun 19 20:31:09 PITA ppp[310]: tun1: Phase: deflink: hangup -> opening Jun 19 20:31:09 PITA ppp[310]: tun1: Phase: deflink: Enter pause (30) for redialing. Jun 19 20:31:19 PITA ppp[72]: tun0: Phase: deflink: Connected! Jun 19 20:31:19 PITA ppp[72]: tun0: Phase: deflink: opening -> dial Jun 19 20:31:19 PITA ppp[72]: tun0: Phase: deflink: dial -> carrier Jun 19 20:31:22 PITA ppp[72]: tun0: Phase: Received NGM_PPPOE_ACNAME (hook "miwi-6400-inet-n^G^HM-^@ ^H^ P ^K^H") Jun 19 20:31:23 PITA ppp[72]: tun0: Phase: Received NGM_PPPOE_<11> (hook "b^E^H^Hh ^K^H") Jun 19 20:31:24 PITA ppp[72]: tun0: Phase: deflink: Disconnected! Jun 19 20:31:24 PITA ppp[72]: tun0: Phase: deflink: carrier -> hangup Jun 19 20:31:24 PITA ppp[72]: tun0: Phase: deflink: Connect time: 5 secs: 0 octets in, 0 octets out Jun 19 20:31:24 PITA ppp[72]: tun0: Phase: deflink: : 0 packets in, 0 packets out Jun 19 20:31:24 PITA ppp[72]: tun0: Phase: total 0 bytes/sec, peak 0 bytes/sec on Wed Jun 19 20:31:19 2002 Jun 19 20:31:24 PITA ppp[72]: tun0: Phase: deflink: hangup -> opening Jun 19 20:31:24 PITA ppp[72]: tun0: Phase: deflink: Enter pause (30) for redialing. Jun 19 20:31:39 PITA ppp[310]: tun1: Phase: deflink: Connected! Jun 19 20:31:39 PITA ppp[310]: tun1: Phase: deflink: opening -> dial Jun 19 20:31:39 PITA ppp[310]: tun1: Phase: deflink: dial -> carrier Jun 19 20:31:42 PITA ppp[310]: tun1: Phase: Received NGM_PPPOE_ACNAME (hook "miwi-6400-inet-n^G^HM-^@ ^H ^P^P^K^H") Jun 19 20:31:43 PITA ppp[310]: tun1: Phase: Received NGM_PPPOE_<11> (hook "c^E^H^Hh^P^K^H") Jun 19 20:31:44 PITA ppp[310]: tun1: Phase: deflink: Disconnected! Jun 19 20:31:44 PITA ppp[310]: tun1: Phase: deflink: carrier -> hangup Jun 19 20:31:44 PITA ppp[310]: tun1: Phase: deflink: Connect time: 5 secs: 0 octets in, 0 octets out Jun 19 20:31:44 PITA ppp[310]: tun1: Phase: deflink: : 0 packets in, 0 packets out Jun 19 20:31:44 PITA ppp[310]: tun1: Phase: total 0 bytes/sec, peak 0 bytes/sec on Wed Jun 19 20:31:39 2002 ppp (END) PITA# less /etc/ppp/ppp.conf ################################################################# # PPP Sample Configuration File # Originally written by Toshiharu OHNO # Simplified 5/14/1999 by wself@cdrom.com # # See /usr/share/examples/ppp/ for some examples # # $FreeBSD: src/etc/ppp/ppp.conf,v 1.2.2.5 2001/07/13 10:55:23 brian Exp $ ################################################################# default: #ppp over ethernet set device PPPoE:xl0: set speed sync set mru 1492 set mtu 1492 set ctsrts off # monitor line quality enable lqr # log just a bit set log +lcp ipcp phase tun command ccp # insert default route upon connection add default HISADDR # download /etc/resolv.conf enable dns tds: set authname set authkey To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 19 19:45:38 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id AE44837B415 for ; Wed, 19 Jun 2002 19:45:31 -0700 (PDT) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020619220019.PWZF2751.rwcrmhc52.attbi.com@InterJet.elischer.org>; Wed, 19 Jun 2002 22:00:19 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id OAA27160; Wed, 19 Jun 2002 14:58:30 -0700 (PDT) Date: Wed, 19 Jun 2002 14:58:29 -0700 (PDT) From: Julian Elischer To: rob@the-rob.com Cc: net@freebsd.org Subject: Re: =?iso-8859-1?Q?Issues_with_PPPoE_and_4.6=3F_(config_files_and_dumps_attatched,_kinda_long)_?= In-Reply-To: <3029.216.170.185.67.1024520279.squirrel@www.soho.berbee.com> Message-ID: 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 Wed, 19 Jun 2002 rob@the-rob.com wrote: please add -e to your tcpdump... > 6400-inet-nrp0"] [AC-Cookie UTF8] > 15:36:54.828240 PPPoE PADR [Host-Uniq UTF8] [AC-Cookie UTF8] [AC-Name "miwi- > 6400-inet-nrp0"] > 15:36:55.134631 PPPoE PADS [ses 0xe6] [Host-Uniq UTF8] [AC-Cookie UTF8] [AC- > Name "miwi-6400-inet-nrp0"] > 15:36:55.179944 PPPoE [ses 0xe6] LCP 20: Conf-Req(1), MRU=1492, Auth-Prot > PAP, Magic-Num=75f2765e > 15:36:57.182623 PPPoE [ses 0xe6] LCP 20: Conf-Req(2), MRU=1492, Auth-Prot > PAP, Magic-Num=75f2765e > 15:36:57.854311 PPPoE PADT [ses 0xe6] [Generic-Error "session closed"] > 15:36:59.182260 PPPoE [ses 0xe6] LCP 20: Conf-Req(3), MRU=1492, Auth-Prot > PAP, Magic-Num=75f2765e someone is ignoring the PADT (possibly us?) > 15:37:01.182047 PPPoE [ses 0xe6] LCP 20: Conf-Req(4), MRU=1492, Auth-Prot > PAP, Magic-Num=75f2765e > 15:37:03.183085 PPPoE [ses 0xe6] LCP 20: Conf-Req(5), MRU=1492, Auth-Prot > PAP, Magic-Num=75f2765e > 15:37:05.183860 PPPoE [ses 0xe6] LCP 20: Conf-Req(6), MRU=1492, Auth-Prot > PAP, Magic-Num=75f2765e > 15:37:07.185145 PPPoE [ses 0xe6] LCP 20: Conf-Req(7), MRU=1492, Auth-Prot > PAP, Magic-Num=75f2765e > 15:37:09.185917 PPPoE [ses 0xe6] LCP 20: Conf-Req(8), MRU=1492, Auth-Prot > PAP, Magic-Num=75f2765e > 15:37:11.186448 PPPoE [ses 0xe6] LCP 20: Conf-Req(9), MRU=1492, Auth-Prot > PAP, Magic-Num=75f2765e > 15:37:13.187240 PPPoE [ses 0xe6] LCP 20: Conf-Req(10), MRU=1492, Auth-Prot > PAP, Magic-Num=75f2765e > 15:37:15.188766 PPPoE PADT [ses 0xe6] ok, reset and restart.... > 15:37:27.877649 PPPoE PADI [Host-Uniq UTF8] > 15:37:29.872969 PPPoE PADI [Host-Uniq UTF8] > 15:37:29.900095 PPPoE PADO [Host-Uniq UTF8] [Service-Name] [AC-Name "miwi- > 6400-inet-nrp0"] [AC-Cookie UTF8] > 15:37:29.900183 PPPoE PADR [Host-Uniq UTF8] [AC-Cookie UTF8] [AC-Name "miwi- > 6400-inet-nrp0"] > 15:37:30.307095 PPPoE PADS [ses 0xe8] [Host-Uniq UTF8] [AC-Cookie UTF8] [AC- > Name "miwi-6400-inet-nrp0"] so far so good.. why doesn't it respond to the session it told us to use? please include a startup of a GOOD session.... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 19 19:45:39 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id 7C44737B416 for ; Wed, 19 Jun 2002 19:45:33 -0700 (PDT) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020619220039.PXGR2751.rwcrmhc52.attbi.com@InterJet.elischer.org>; Wed, 19 Jun 2002 22:00:39 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id OAA27144; Wed, 19 Jun 2002 14:47:26 -0700 (PDT) Date: Wed, 19 Jun 2002 14:47:24 -0700 (PDT) From: Julian Elischer To: Mike Tancsa Cc: Brian Somers , freebsd-net@FreeBSD.ORG Subject: Re: FreeBSD PPPoE Broken ? (was Re: tracking down strange MTU issues with PPPoE) In-Reply-To: <5.1.0.14.0.20020619153843.04ac1868@marble.sentex.ca> Message-ID: 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 Wed, 19 Jun 2002, Mike Tancsa wrote: > > OK, just completed some more testing. Something is definitely really > strange between FreeBSD's PPPoE and the ERX. I have 2 FreeBSD boxes in 2 > different locations, both that were working great off Redbacks. The Telco > switched out the Redbacks and put Unisphere ERXs in place. At these 2 > sites, if I take out the FreeBSD boxes and put in either > Windows 2000, > Linux 2.4.x > or a Cisco 827 > all works great. With FreeBSD, I can browse and fetch data from some > sites, but not all. The problem sites, transfer rates become bytes per second. > If I take out those 2 FreeBSD boxes and move them physically to a different > site where its terminated off a redback, all works as expected. > > So it would seem one or some of the following > > a) Something wrong with my config > b) Something wrong with the ERX > c) Something wrong with FreeBSD's PPPoE implementation as far as the ERX is > concerned. > d) Something wrong with my Telco's config. My guess: Something wrong with the ERX that doesn't hit the windows machines because they tested with those.. The PPPOE implementation on FReeBSD does follow the spec very closely, but it doesn;t act as windows does. This sometimes upsets equipment that just assumes that the world is windows.. do you have packet traces? do a tcpdump on the ethernet interface you are using.. tcpdump knows how to handle pppoe. > > > a) is always possible. But the same simple PPPoE config has been working > for some time and the first box in question only stopped working when the > telco switch the termination device from a RedBack SMS to the ERX. > b) Possible, but all the other implementations seem to work > c) Not sure where to start > d) Again, certainly possible, but would it not affect all the PPPoE > implementations equally? > > Any help is much appreciated as I dont want to abandon FreeBSD of course at > these sites for Linux. > > > ---Mike > > > 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 Wed Jun 19 19:52:53 2002 Delivered-To: freebsd-net@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 71AE837B410; Wed, 19 Jun 2002 19:52:46 -0700 (PDT) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id WAA18593; Wed, 19 Jun 2002 22:52:36 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id g5K2q6p29304; Wed, 19 Jun 2002 22:52:06 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15633.17238.109126.952673@grasshopper.cs.duke.edu> Date: Wed, 19 Jun 2002 22:52:06 -0400 (EDT) To: Bosko Milekic Cc: "Kenneth D. Merry" , current@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: new zero copy sockets snapshot In-Reply-To: <20020619120641.A18434@unixdaemons.com> References: <20020618223635.A98350@panzer.kdm.org> <20020619090046.A2063@panzer.kdm.org> <20020619120641.A18434@unixdaemons.com> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid 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 Bosko Milekic writes: > > - It's kind of unfortunate that uipc_jumbo.c has to roll its own > allocator; There are a couple of alternatives; to just use The point of uipc_jumbo.c rolling its own allocator is that it allocates free pages which can be "flipped" (re-mapped) into user-space to avoid a memory copy. The use of this allocator is confined to nic's with firmware which is smart enough to split off headers from payloads. (Currently only Ken's modified if_ti.c; and my old Trapeze/Myrinet driver though I plan to implment this in the official Myricom GM firmware/FreeBSD driver if the zero-copy sockets patch is committed). Its somewhat out of date, but you might want to read my '99 Freenix paper. It gives a good overview of the zero-copy patch. http://www.cs.duke.edu/ari/publications/tcpgig.pdf This is orthogonal to the zero-copy patch, but it _would_ be nice to have general purpose mbuf allocator which could allocate mbuf clusters with 9K physically contigous for dumber nics. There are a whole slew of drivers (unpatched ti, bge, nge, lge, etc) which roll their own for no better reason than the system doesn't offer this feature. That's what needs fixing. Heck, if such an allocator was available, we could use it for copyin's of large chunks of data. Tru64 has 8K and 2K clusters and does this. (based from emperical evidence garnered at the driver level). Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 19 20:37:37 2002 Delivered-To: freebsd-net@freebsd.org Received: from angelica.unixdaemons.com (angelica.unixdaemons.com [209.148.64.135]) by hub.freebsd.org (Postfix) with ESMTP id 32E7D37B405; Wed, 19 Jun 2002 20:37:30 -0700 (PDT) Received: from angelica.unixdaemons.com (bmilekic@localhost.unixdaemons.com [127.0.0.1]) by angelica.unixdaemons.com (8.12.4/8.12.1) with ESMTP id g5K3bM14032885; Wed, 19 Jun 2002 23:37:22 -0400 (EDT) X-Authentication-Warning: angelica.unixdaemons.com: Host bmilekic@localhost.unixdaemons.com [127.0.0.1] claimed to be angelica.unixdaemons.com Received: (from bmilekic@localhost) by angelica.unixdaemons.com (8.12.4/8.12.1/Submit) id g5K3bLmm032884; Wed, 19 Jun 2002 23:37:21 -0400 (EDT) (envelope-from bmilekic) Date: Wed, 19 Jun 2002 23:37:21 -0400 From: Bosko Milekic To: Andrew Gallatin Cc: "Kenneth D. Merry" , current@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: new zero copy sockets snapshot Message-ID: <20020619233721.A30669@unixdaemons.com> References: <20020618223635.A98350@panzer.kdm.org> <20020619090046.A2063@panzer.kdm.org> <20020619120641.A18434@unixdaemons.com> <15633.17238.109126.952673@grasshopper.cs.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <15633.17238.109126.952673@grasshopper.cs.duke.edu>; from gallatin@cs.duke.edu on Wed, Jun 19, 2002 at 10:52:06PM -0400 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 Wed, Jun 19, 2002 at 10:52:06PM -0400, Andrew Gallatin wrote: > > Bosko Milekic writes: > > > > - It's kind of unfortunate that uipc_jumbo.c has to roll its own > > allocator; There are a couple of alternatives; to just use > > The point of uipc_jumbo.c rolling its own allocator is that it > allocates free pages which can be "flipped" (re-mapped) into > user-space to avoid a memory copy. The use of this allocator is > confined to nic's with firmware which is smart enough to split off > headers from payloads. (Currently only Ken's modified if_ti.c; and my > old Trapeze/Myrinet driver though I plan to implment this in the > official Myricom GM firmware/FreeBSD driver if the zero-copy sockets > patch is committed). Yes, I know that that's what it does. What I meant was that it would be convenient to have UMA handle the allocation bit. It should be possible to have UMA do this sort of allocation and keep the free pages in per-CPU caches. The problem right now, as you know, is that UMA (nor mb_alloc for that matter) will allow you to play those vm-tricks you play on the allocated pages. I was just pointing out that it is an unfortunate thing and that, hopefully, UMA will allow for this sort of thing at some point in the future. By the way, my other two comments have been deleted, but reading the page that Ken maintains I noticed that Alfred already pointed them out. However, I'm looking at the 18th of June patch from the same webpage and I still see that the uipc_jumbo.c code does not use the SLIST_FIRST macro. I think with those two bogons fixed, and assuming that the stuff in if_ti is OK, this is almost ready to go in under the ZERO_COPY kernel option? *gulp* [...] > This is orthogonal to the zero-copy patch, but it _would_ be nice to > have general purpose mbuf allocator which could allocate mbuf clusters > with 9K physically contigous for dumber nics. There are a whole slew > of drivers (unpatched ti, bge, nge, lge, etc) which roll their own for > no better reason than the system doesn't offer this feature. That's > what needs fixing. Heck, if such an allocator was available, we could > use it for copyin's of large chunks of data. Tru64 has 8K and 2K > clusters and does this. (based from emperical evidence garnered at the > driver level). Right. It's very hard to do > PAGE_SIZE allocations that are backed by physically contiguous memory in FreeBSD right now. I agree that this would be very useful, though. > Drew -- Bosko Milekic bmilekic@unixdaemons.com bmilekic@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 19 20:43:24 2002 Delivered-To: freebsd-net@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id C4B7037B400; Wed, 19 Jun 2002 20:43:14 -0700 (PDT) Received: (from ken@localhost) by panzer.kdm.org (8.11.6/8.9.1) id g5K3h8n08351; Wed, 19 Jun 2002 21:43:08 -0600 (MDT) (envelope-from ken) Date: Wed, 19 Jun 2002 21:43:08 -0600 From: "Kenneth D. Merry" To: Bosko Milekic Cc: Dag-Erling Smorgrav , current@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: new zero copy sockets snapshot Message-ID: <20020619214308.A8221@panzer.kdm.org> References: <20020618223635.A98350@panzer.kdm.org> <20020619090046.A2063@panzer.kdm.org> <20020619120641.A18434@unixdaemons.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020619120641.A18434@unixdaemons.com>; from bmilekic@unixdaemons.com on Wed, Jun 19, 2002 at 12:06:41PM -0400 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 Wed, Jun 19, 2002 at 12:06:41 -0400, Bosko Milekic wrote: > On Wed, Jun 19, 2002 at 09:00:46AM -0600, Kenneth D. Merry wrote: > > On Wed, Jun 19, 2002 at 15:55:18 +0200, Dag-Erling Smorgrav wrote: > > > "Kenneth D. Merry" writes: > > > > With those fixes, plus several fixes that have gone into -current over the > > > > past week or so, the zero copy sockets code runs without any WITNESS > > > > warnings at all now. > > > > > > Planning to commit soon? > > > > That's the plan. I need to see if any comments come up, and then make sure > > I'll be in town for a few days at least to handle any problems that come > > up. > > I have a few comments and questions: > > - In uipc_jumbo.c, you appear to avoid using some of the SLIST macros, > notably when grabbing something off the inuse or free lists. Thanks for pointing that out. I only see two instances, the attached patch should fix them. > - Is the mutex really necessary in jumbo_vm_init()? I suspect that > if you need to ensure mutual exclusion here, there's something > wrong; (why would you be running the jumbo vm code before having > initialized it?) - perhaps you could init the mtx at runtime in the > jumbo_vm_init routine. The reason for the mutex protection in jumbo_vm_init() is to protect against simultaneous callers. I'm going on the assumption that I don't know exactly who might be calling jumbo_vm_init(), or when, so it's better to make sure it is locked down than risk duplicate callers. > - It's kind of unfortunate that uipc_jumbo.c has to roll its own > allocator; There are a couple of alternatives; to just use > UMA or mb_alloc for this sort of thing. mb_alloc will wire > all pages allocated through it, though, so maybe it would be worth > looking at what UMA can do in this respect. If it cannot do exactly > what you're looking for, then modifying it to do what you want > should be relatively simple. The added advantage is that you'll now > be using per-CPU caches for allocations of jumbo bufs, and not the > single freelist that you currently use. See Drew's response. (thanks Drew!) > - I don't know anything about the if_ti code, but it sure looks like > it's holding the ti mutex a long time in some places (not only in > your patch). (backround information) Bill did the conversion in if_ti.c in many places by substituting TI_LOCK() for splimp(). (from looking at rev 1.36) There were a couple of additional places where he adding locking as well. I followed more or less the same pattern with converting the new portions of the ti(4) driver. I need to take a close look at the driver to see whether some of the places where locks are held can be reduced somewhat. If you've got some suggestions on places that might be tweaked, I'd like to hear them! If you're referring to the memory copy routines (ti_copy_mem(), ti_copy_scratch()), I'd rather leave the locking in for them. They modify the window/segment pointers to read/write memory, and it would cause problems if those pointers got changed out from under us. In any case, those routines are only used for debugging, so they're not on the normal critical code path. I'd be more concerned with reducing the amount of time under lock for the general packet paths. I see one instance where the lock can be taken out -- ti_newbuf_jumbo() (the new version) doesn't need it, since it is always called with the lock held anyway. Thanks for the feedback! Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 19 20:44:17 2002 Delivered-To: freebsd-net@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 6118037B40A; Wed, 19 Jun 2002 20:44:01 -0700 (PDT) Received: (from ken@localhost) by panzer.kdm.org (8.11.6/8.9.1) id g5K3hvS08388; Wed, 19 Jun 2002 21:43:57 -0600 (MDT) (envelope-from ken) Date: Wed, 19 Jun 2002 21:43:56 -0600 From: "Kenneth D. Merry" To: Bosko Milekic Cc: Dag-Erling Smorgrav , current@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: new zero copy sockets snapshot Message-ID: <20020619214356.B8221@panzer.kdm.org> References: <20020618223635.A98350@panzer.kdm.org> <20020619090046.A2063@panzer.kdm.org> <20020619120641.A18434@unixdaemons.com> <20020619214308.A8221@panzer.kdm.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="zYM0uCDKw75PZbzx" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020619214308.A8221@panzer.kdm.org>; from ken@kdm.org on Wed, Jun 19, 2002 at 09:43:08PM -0600 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 --zYM0uCDKw75PZbzx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Jun 19, 2002 at 21:43:08 -0600, Kenneth D. Merry wrote: > On Wed, Jun 19, 2002 at 12:06:41 -0400, Bosko Milekic wrote: > > On Wed, Jun 19, 2002 at 09:00:46AM -0600, Kenneth D. Merry wrote: > > > On Wed, Jun 19, 2002 at 15:55:18 +0200, Dag-Erling Smorgrav wrote: > > > > "Kenneth D. Merry" writes: > > > > > With those fixes, plus several fixes that have gone into -current over the > > > > > past week or so, the zero copy sockets code runs without any WITNESS > > > > > warnings at all now. > > > > > > > > Planning to commit soon? > > > > > > That's the plan. I need to see if any comments come up, and then make sure > > > I'll be in town for a few days at least to handle any problems that come > > > up. > > > > I have a few comments and questions: > > > > - In uipc_jumbo.c, you appear to avoid using some of the SLIST macros, > > notably when grabbing something off the inuse or free lists. > > Thanks for pointing that out. I only see two instances, the attached patch > should fix them. Oops, forgot the patch. Here it is. Ken -- Kenneth Merry ken@kdm.org --zYM0uCDKw75PZbzx Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="uipc_jumbo.c.diffs.20020619" ==== //depot/FreeBSD-zero/src/sys/kern/uipc_jumbo.c#4 - /usr/home/ken/perforce/FreeBSD-zero/src/sys/kern/uipc_jumbo.c ==== *** /tmp/tmp.940.0 Wed Jun 19 20:07:29 2002 --- /usr/home/ken/perforce/FreeBSD-zero/src/sys/kern/uipc_jumbo.c Wed Jun 19 20:06:01 2002 *************** *** 199,205 **** pg = NULL; mtx_lock(&jumbo_mutex); ! entry = jumbo_kmap_free.slh_first; if (entry != NULL){ pindex = atop(entry->kva - jumbo_basekva); pg = vm_page_alloc(jumbo_vm_object, pindex, VM_ALLOC_INTERRUPT); --- 199,205 ---- pg = NULL; mtx_lock(&jumbo_mutex); ! entry = SLIST_FIRST(&jumbo_kmap_free); if (entry != NULL){ pindex = atop(entry->kva - jumbo_basekva); pg = vm_page_alloc(jumbo_vm_object, pindex, VM_ALLOC_INTERRUPT); *************** *** 238,244 **** mtx_lock(&jumbo_mutex); pmap_qremove(addr,1); ! entry = jumbo_kmap_inuse.slh_first; entry->kva = addr; SLIST_REMOVE_HEAD(&jumbo_kmap_inuse, entries); SLIST_INSERT_HEAD(&jumbo_kmap_free, entry, entries); --- 238,244 ---- mtx_lock(&jumbo_mutex); pmap_qremove(addr,1); ! entry = SLIST_FIRST(jumbo_kmap_inuse); entry->kva = addr; SLIST_REMOVE_HEAD(&jumbo_kmap_inuse, entries); SLIST_INSERT_HEAD(&jumbo_kmap_free, entry, entries); --zYM0uCDKw75PZbzx-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 19 20:49:13 2002 Delivered-To: freebsd-net@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 59ACD37B406; Wed, 19 Jun 2002 20:49:01 -0700 (PDT) Received: (from ken@localhost) by panzer.kdm.org (8.11.6/8.9.1) id g5K3mvp08450; Wed, 19 Jun 2002 21:48:57 -0600 (MDT) (envelope-from ken) Date: Wed, 19 Jun 2002 21:48:57 -0600 From: "Kenneth D. Merry" To: Bosko Milekic Cc: Andrew Gallatin , current@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: new zero copy sockets snapshot Message-ID: <20020619214857.C8221@panzer.kdm.org> References: <20020618223635.A98350@panzer.kdm.org> <20020619090046.A2063@panzer.kdm.org> <20020619120641.A18434@unixdaemons.com> <15633.17238.109126.952673@grasshopper.cs.duke.edu> <20020619233721.A30669@unixdaemons.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020619233721.A30669@unixdaemons.com>; from bmilekic@unixdaemons.com on Wed, Jun 19, 2002 at 11:37:21PM -0400 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 Wed, Jun 19, 2002 at 23:37:21 -0400, Bosko Milekic wrote: > On Wed, Jun 19, 2002 at 10:52:06PM -0400, Andrew Gallatin wrote: > > > > Bosko Milekic writes: > > > > > > - It's kind of unfortunate that uipc_jumbo.c has to roll its own > > > allocator; There are a couple of alternatives; to just use > > > > The point of uipc_jumbo.c rolling its own allocator is that it > > allocates free pages which can be "flipped" (re-mapped) into > > user-space to avoid a memory copy. The use of this allocator is > > confined to nic's with firmware which is smart enough to split off > > headers from payloads. (Currently only Ken's modified if_ti.c; and my > > old Trapeze/Myrinet driver though I plan to implment this in the > > official Myricom GM firmware/FreeBSD driver if the zero-copy sockets > > patch is committed). > > Yes, I know that that's what it does. What I meant was that it would > be convenient to have UMA handle the allocation bit. It should be > possible to have UMA do this sort of allocation and keep the free pages > in per-CPU caches. The problem right now, as you know, is that UMA > (nor mb_alloc for that matter) will allow you to play those vm-tricks > you play on the allocated pages. I was just pointing out that it is an > unfortunate thing and that, hopefully, UMA will allow for this sort of > thing at some point in the future. It would be nice. Perhaps with an application for such functionality sitting in the tree, it might provide an incentive for someone to write the UMA code to do it. :) > By the way, my other two comments have been deleted, but reading the > page that Ken maintains I noticed that Alfred already pointed them out. > However, I'm looking at the 18th of June patch from the same webpage and > I still see that the uipc_jumbo.c code does not use the SLIST_FIRST > macro. I think with those two bogons fixed, and assuming that the stuff > in if_ti is OK, this is almost ready to go in under the ZERO_COPY kernel > option? *gulp* You're right, I fixed one instance but not the other two. Those are fixed in my local tree. If you've got some ideas on reducing the lock time in the ti(4) driver, I'd be glad to hear them. (As I said previously, I wouldn't worry too much about the memory copy functions, they're only used when the debugging interface is active.) > [...] > > This is orthogonal to the zero-copy patch, but it _would_ be nice to > > have general purpose mbuf allocator which could allocate mbuf clusters > > with 9K physically contigous for dumber nics. There are a whole slew > > of drivers (unpatched ti, bge, nge, lge, etc) which roll their own for > > no better reason than the system doesn't offer this feature. That's > > what needs fixing. Heck, if such an allocator was available, we could > > use it for copyin's of large chunks of data. Tru64 has 8K and 2K > > clusters and does this. (based from emperical evidence garnered at the > > driver level). > > Right. It's very hard to do > PAGE_SIZE allocations that are backed > by physically contiguous memory in FreeBSD right now. I agree that this > would be very useful, though. Thanks again for the feedback! Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 19 21: 0: 6 2002 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id 77BFA37B40B; Wed, 19 Jun 2002 21:00:02 -0700 (PDT) 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 UAA07537; Wed, 19 Jun 2002 20:47:05 -0700 (PDT) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g5K3kbC47150; Wed, 19 Jun 2002 20:46:37 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200206200346.g5K3kbC47150@arch20m.dellroad.org> Subject: Re: removing global variables from the network stack In-Reply-To: <20020619094420.C58636@iguana.icir.org> "from Luigi Rizzo at Jun 19, 2002 09:44:20 am" To: Luigi Rizzo Date: Wed, 19 Jun 2002 20:46:37 -0700 (PDT) Cc: julian@FreeBSD.ORG, 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 Luigi Rizzo writes: > The global variable in question is "ip_divert_cookie", > declared in ip_divert.c and used to pass the divert port > to divert_packet(), and from div_output() to ip_output()/ip_input() > > For the former the fix is trivial, we just need to add an additional > argument to divert_packet(). > > For the latter, it *would* be easy to add an argument to ip_output() > but if we do not want to change the interface, perhaps the easiest > trick is to pass the annotation in the same way as it is done for > dummynet info, i.e. using a fake mbuf prepended to the actual chain. > Something like this: I don't think adding another parameter to ip_input() is such a bad thing, because presumably it would only exist in kernels with the IPDIVERT option. For "normal" people there would be no slowdown (and consequently no complaints :-) This is also simpler and faster than the aux mbuf, etc. schemes.. after all, all you are passing here is a 16 bit value. -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 Thu Jun 20 8:24:47 2002 Delivered-To: freebsd-net@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 2673B37B406; Thu, 20 Jun 2002 08:24:37 -0700 (PDT) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id LAA02499; Thu, 20 Jun 2002 11:24:35 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id g5KFO5I30340; Thu, 20 Jun 2002 11:24:05 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15633.62357.79381.405511@grasshopper.cs.duke.edu> Date: Thu, 20 Jun 2002 11:24:05 -0400 (EDT) To: Bosko Milekic Cc: "Kenneth D. Merry" , current@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: new zero copy sockets snapshot In-Reply-To: <20020619233721.A30669@unixdaemons.com> References: <20020618223635.A98350@panzer.kdm.org> <20020619090046.A2063@panzer.kdm.org> <20020619120641.A18434@unixdaemons.com> <15633.17238.109126.952673@grasshopper.cs.duke.edu> <20020619233721.A30669@unixdaemons.com> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid 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 Bosko Milekic writes: > > On Wed, Jun 19, 2002 at 10:52:06PM -0400, Andrew Gallatin wrote: <...> > Yes, I know that that's what it does. What I meant was that it would > be convenient to have UMA handle the allocation bit. It should be > possible to have UMA do this sort of allocation and keep the free pages > in per-CPU caches. The problem right now, as you know, is that UMA > (nor mb_alloc for that matter) will allow you to play those vm-tricks > you play on the allocated pages. I was just pointing out that it is an > unfortunate thing and that, hopefully, UMA will allow for this sort of > thing at some point in the future. Ah, OK, point taken. I'm sorry if I gave offense. > By the way, my other two comments have been deleted, but reading the > page that Ken maintains I noticed that Alfred already pointed them out. <...> Ken has been maintaining the patchset on his own for quite some time. I must admit that I've not looked closely at these issues, so I didn't feel it was appropriate for me to comment on them. I didn't mean to discount your other comments. > [...] > > This is orthogonal to the zero-copy patch, but it _would_ be nice to > > have general purpose mbuf allocator which could allocate mbuf clusters > > with 9K physically contigous for dumber nics. There are a whole slew > > of drivers (unpatched ti, bge, nge, lge, etc) which roll their own for > > no better reason than the system doesn't offer this feature. That's > > what needs fixing. Heck, if such an allocator was available, we could > > use it for copyin's of large chunks of data. Tru64 has 8K and 2K > > clusters and does this. (based from emperical evidence garnered at the > > driver level). > > Right. It's very hard to do > PAGE_SIZE allocations that are backed > by physically contiguous memory in FreeBSD right now. I agree that this > would be very useful, though. > Years ago, I used Wollman's MCLBYTES > PAGE_SIZE support (introduced in rev 1.20 of uipc_mbuf.c) and it seemed to work OK then. But having 16K clusters is a huge waste of space. ;). Do you think it would be feasable to glue in a new jumbo (10K?) allocator on top of the existing mbuf and mcl allocators using the existing mechanisms and the existing MCLBYTES > PAGE_SIZE support (but broken out into separte functions and macros)? Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 20 8:48: 4 2002 Delivered-To: freebsd-net@freebsd.org Received: from tesla.distributel.net (nat.MTL.distributel.NET [66.38.181.24]) by hub.freebsd.org (Postfix) with ESMTP id 386AA37B408; Thu, 20 Jun 2002 08:47:32 -0700 (PDT) Received: (from bmilekic@localhost) by tesla.distributel.net (8.11.6/8.11.6) id g5KFjBt22455; Thu, 20 Jun 2002 11:45:11 -0400 (EDT) (envelope-from bmilekic@unixdaemons.com) Date: Thu, 20 Jun 2002 11:45:11 -0400 From: Bosko Milekic To: Andrew Gallatin Cc: "Kenneth D. Merry" , current@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: new zero copy sockets snapshot Message-ID: <20020620114511.A22413@unixdaemons.com> References: <20020618223635.A98350@panzer.kdm.org> <20020619090046.A2063@panzer.kdm.org> <20020619120641.A18434@unixdaemons.com> <15633.17238.109126.952673@grasshopper.cs.duke.edu> <20020619233721.A30669@unixdaemons.com> <15633.62357.79381.405511@grasshopper.cs.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <15633.62357.79381.405511@grasshopper.cs.duke.edu>; from gallatin@cs.duke.edu on Thu, Jun 20, 2002 at 11:24:05AM -0400 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, Jun 20, 2002 at 11:24:05AM -0400, Andrew Gallatin wrote: > > Bosko Milekic writes: > > > > On Wed, Jun 19, 2002 at 10:52:06PM -0400, Andrew Gallatin wrote: > > <...> > > > Yes, I know that that's what it does. What I meant was that it would > > be convenient to have UMA handle the allocation bit. It should be > > possible to have UMA do this sort of allocation and keep the free pages > > in per-CPU caches. The problem right now, as you know, is that UMA > > (nor mb_alloc for that matter) will allow you to play those vm-tricks > > you play on the allocated pages. I was just pointing out that it is an > > unfortunate thing and that, hopefully, UMA will allow for this sort of > > thing at some point in the future. > > Ah, OK, point taken. I'm sorry if I gave offense. Hey, I'm sorry if I accidently suggested that I took offense! Really, I wasn't offended at all. :-) > > By the way, my other two comments have been deleted, but reading the > > page that Ken maintains I noticed that Alfred already pointed them out. > > <...> > > Ken has been maintaining the patchset on his own for quite some time. > I must admit that I've not looked closely at these issues, so I didn't > feel it was appropriate for me to comment on them. I didn't mean to > discount your other comments. Ken has already taken care of it. I'm really impressed that Ken has maintained the patchset for so long. It's really good that the zero-copy stuff has not been dropped over the years. > > [...] > > > This is orthogonal to the zero-copy patch, but it _would_ be nice to > > > have general purpose mbuf allocator which could allocate mbuf clusters > > > with 9K physically contigous for dumber nics. There are a whole slew > > > of drivers (unpatched ti, bge, nge, lge, etc) which roll their own for > > > no better reason than the system doesn't offer this feature. That's > > > what needs fixing. Heck, if such an allocator was available, we could > > > use it for copyin's of large chunks of data. Tru64 has 8K and 2K > > > clusters and does this. (based from emperical evidence garnered at the > > > driver level). > > > > Right. It's very hard to do > PAGE_SIZE allocations that are backed > > by physically contiguous memory in FreeBSD right now. I agree that this > > would be very useful, though. > > > > Years ago, I used Wollman's MCLBYTES > PAGE_SIZE support (introduced > in rev 1.20 of uipc_mbuf.c) and it seemed to work OK then. But having > 16K clusters is a huge waste of space. ;). Since then, the mbuf allocator in -CURRENT has totally changed. It is still possible to provide allocations of > PAGE_SIZE buffers, however they will likely not map physically contiguous memory. If you happen to have a device that doesn't support scatter/gather for DMA, then these buffers will be broken for it (I know that if_ti is not a problem). The other issue is that the mbuf allocator then as well as the new mbuf allocator uses the kmem_malloc() interface that was also used by malloc() to perform allocations of wired-down pages. I am not sure if you'll be able to play those tricks where you unmap and remap the page that is allocated for you once it comes out of the mbuf allocator. Do you think it would work? > Do you think it would be feasable to glue in a new jumbo (10K?) > allocator on top of the existing mbuf and mcl allocators using the > existing mechanisms and the existing MCLBYTES > PAGE_SIZE support > (but broken out into separte functions and macros)? Assuming that you can still play those VM tricks with the pages spit out by mb_alloc (kern/subr_mbuf.c in -CURRENT), then this wouldn't be a problem at all. It's easy to add a new fixed-size type allocation to mb_alloc. In fact, it would be beneficial. mb_alloc uses per-CPU caches and also makes mbuf and cluster allocations share the same per-CPU lock. What could be done is that the jumbo buffer allocations could share the same lock as well (since they will likely usually be allocated right after an mbuf is). This would give us jumbo-cluster support, but it would only be useful for devices clued enough to break up the cluster into PAGE_SIZE chunks and do scatter/gather. For most worthy gigE devices, I don't think this should be a problem. > Drew Regards, -- Bosko Milekic bmilekic@unixdaemons.com bmilekic@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 20 9: 9:55 2002 Delivered-To: freebsd-net@freebsd.org Received: from wall.polstra.com (wall-gw.polstra.com [206.213.73.130]) by hub.freebsd.org (Postfix) with ESMTP id C931437B406 for ; Thu, 20 Jun 2002 09:09:49 -0700 (PDT) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.11.3/8.11.3) with ESMTP id g5KG9kf96910; Thu, 20 Jun 2002 09:09:46 -0700 (PDT) (envelope-from jdp@wall.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.11.6/8.11.0) id g5KG9kS22944; Thu, 20 Jun 2002 09:09:46 -0700 (PDT) (envelope-from jdp) Date: Thu, 20 Jun 2002 09:09:46 -0700 (PDT) Message-Id: <200206201609.g5KG9kS22944@vashon.polstra.com> To: net@freebsd.org From: John Polstra Cc: paleph@pacbell.net Subject: Re: bge driver issue In-Reply-To: <200206182206.g5IM6P003388@pacbell.net> References: <200206182206.g5IM6P003388@pacbell.net> Organization: Polstra & Co., Seattle, WA 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 article <200206182206.g5IM6P003388@pacbell.net>, wrote: > We have a Dell poweredge 2650 (successor to 2550). > > We also saw the same problem with 4.5. I tried the current bge driver from 4.6 > without success. The problem seems to be a size problem. When we ftp a small > file, things work fine. However, when we try a 18 Megabyte file, the ftp > hands and we see the problem descriped below. The linux system that came > with the hardware (from dell) worked fine. On the 2650 or any other x86 PCI-X system, please try the following simple experiment. Edit "src/sys/dev/bge/if_bgereg.h". Find this line: #define ETHER_ALIGN 2 Change the "2" to "0". Build and install a new kernel. See whether it solves the problem. Here is the reasoning behind the experiment. The bge driver sets things up so that the NIC DMAs received packets into mbuf clusters starting ETHER_ALIGN bytes from the beginning of the buffer. That is done so the payload after the 14- or 18-byte Ethernet header will be aligned in memory at a 4-byte boundary. The Linux driver from 3Com for the 3c996B-T does the same thing. However, on PCI-X busses only, that driver disables the 2-byte offsetting and stores received packets at the very beginning of the buffer in memory. It is reasonable to assume that they went to all that trouble for a reason -- for example, a chip bug. This change will impact performance on the x86 architecture, and it will flat-out break Alphas and most other architectures. The actual fix would have to be more intelligent, but this is just an experiment. Please report back after you have tried this change. I know two people who have reported that it solved the problems they were having with BCM5701 chips in PCI-X systems. John -- John Polstra John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 20 9:14: 4 2002 Delivered-To: freebsd-net@freebsd.org Received: from ns.giranti.co.id (ns.giranti.co.id [202.95.136.78]) by hub.freebsd.org (Postfix) with SMTP id 25F0E37B407 for ; Thu, 20 Jun 2002 09:13:55 -0700 (PDT) Received: (qmail 654 invoked by uid 1008); 20 Jun 2002 16:09:33 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 20 Jun 2002 16:09:33 -0000 Date: Thu, 20 Jun 2002 23:09:33 +0700 (WIT) From: hantu To: freebsd-net@freebsd.org Subject: digiboard pc/8i .. Message-ID: <20020620230039.U636-100000@ns.giranti.co.id> 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 all i have digiboard pc/8i adapter,... i try to check all the port using command tip if i put modem on port 1, the port 1 run well, the other drop .. only can be connected but can't put modem command like AT or something else. please help me,.. thanks -oo- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 20 9:28: 5 2002 Delivered-To: freebsd-net@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id CBB1B37B40B; Thu, 20 Jun 2002 09:26:30 -0700 (PDT) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id MAA04622; Thu, 20 Jun 2002 12:26:28 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id g5KGPwu30393; Thu, 20 Jun 2002 12:25:58 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15634.534.696063.241224@grasshopper.cs.duke.edu> Date: Thu, 20 Jun 2002 12:25:58 -0400 (EDT) To: Bosko Milekic Cc: "Kenneth D. Merry" , current@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: new zero copy sockets snapshot In-Reply-To: <20020620114511.A22413@unixdaemons.com> References: <20020618223635.A98350@panzer.kdm.org> <20020619090046.A2063@panzer.kdm.org> <20020619120641.A18434@unixdaemons.com> <15633.17238.109126.952673@grasshopper.cs.duke.edu> <20020619233721.A30669@unixdaemons.com> <15633.62357.79381.405511@grasshopper.cs.duke.edu> <20020620114511.A22413@unixdaemons.com> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid 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 Bosko Milekic writes: > > Years ago, I used Wollman's MCLBYTES > PAGE_SIZE support (introduced > > in rev 1.20 of uipc_mbuf.c) and it seemed to work OK then. But having > > 16K clusters is a huge waste of space. ;). > > Since then, the mbuf allocator in -CURRENT has totally changed. It is > still possible to provide allocations of > PAGE_SIZE buffers, however > they will likely not map physically contiguous memory. If you happen to > have a device that doesn't support scatter/gather for DMA, then these > buffers will be broken for it (I know that if_ti is not a problem). Actually, it will be a problem for if_ti. The original tigon 1s didn't support s/g DMA. I think we should just not support jumbo frames on tigon 1s.. > The other issue is that the mbuf allocator then as well as the new > mbuf allocator uses the kmem_malloc() interface that was also used by > malloc() to perform allocations of wired-down pages. I am not sure if > you'll be able to play those tricks where you unmap and remap the page > that is allocated for you once it comes out of the mbuf allocator. Do > you think it would work? I don't think so, but I haven't read the code carefully and I don't know for certain. However, my intent was to use a jumbo mbuf type for copyin and to clean up the existing infastructure for drivers w/brain dead firmware, not to use a new 10K cluster as a framework for zero-copy. > > Do you think it would be feasable to glue in a new jumbo (10K?) > > allocator on top of the existing mbuf and mcl allocators using the > > existing mechanisms and the existing MCLBYTES > PAGE_SIZE support > > (but broken out into separte functions and macros)? > > Assuming that you can still play those VM tricks with the pages spit > out by mb_alloc (kern/subr_mbuf.c in -CURRENT), then this wouldn't be a > problem at all. It's easy to add a new fixed-size type allocation to > mb_alloc. In fact, it would be beneficial. mb_alloc uses per-CPU > caches and also makes mbuf and cluster allocations share the same > per-CPU lock. What could be done is that the jumbo buffer allocations > could share the same lock as well (since they will likely usually be > allocated right after an mbuf is). This would give us jumbo-cluster > support, but it would only be useful for devices clued enough to break > up the cluster into PAGE_SIZE chunks and do scatter/gather. For most > worthy gigE devices, I don't think this should be a problem. I'm a bit worried about other devices.. Tradidtionally, mbufs have never crossed page boundaries so most drivers never bother to check for a transmit mbuf crossing a page boundary. Using physically discontigous mbufs could lead to a lot of subtle data corruption. One question. I've observed some really anomolous behaviour under -stable with my Myricom GM driver (2Gb/s + 2Gb/s link speed, Dual 1GHz pIII). When I use 4K mbufs for receives, the best speed I see is about 1300Mb/sec. However, if I use private 9K physically contiguous buffers I see 1850Mb/sec (iperf TCP). The obvious conclusion is that there's a lot of overhead in setting up the DMA engines, but that's not the case; we have a fairly quick chain dma engine. I've provided a "control" by breaking my contiguous buffers down into 4K chunks so that I do the same number of DMAs in both cases and I still see ~1850 Mb/sec for the 9K buffers. A coworker suggested that the problem was that when doing copyouts to userspace, the PIII was doing speculative reads and loading the cache with the next page. However, we then start copying from a totally different address using discontigous buffers, so we effectively take 2x the number of cache misses we'd need to. Does that sound reasonable to you? I need to try malloc'ing virtually contigous and physically discontigous buffers & see if I get the same (good) performance... Cheers, Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 20 10:49:54 2002 Delivered-To: freebsd-net@freebsd.org Received: from tesla.distributel.net (nat.MTL.distributel.NET [66.38.181.24]) by hub.freebsd.org (Postfix) with ESMTP id 334C137B409; Thu, 20 Jun 2002 10:49:45 -0700 (PDT) Received: (from bmilekic@localhost) by tesla.distributel.net (8.11.6/8.11.6) id g5KHlNZ22976; Thu, 20 Jun 2002 13:47:23 -0400 (EDT) (envelope-from bmilekic@unixdaemons.com) Date: Thu, 20 Jun 2002 13:47:23 -0400 From: Bosko Milekic To: Andrew Gallatin Cc: "Kenneth D. Merry" , current@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: new zero copy sockets snapshot Message-ID: <20020620134723.A22954@unixdaemons.com> References: <20020618223635.A98350@panzer.kdm.org> <20020619090046.A2063@panzer.kdm.org> <20020619120641.A18434@unixdaemons.com> <15633.17238.109126.952673@grasshopper.cs.duke.edu> <20020619233721.A30669@unixdaemons.com> <15633.62357.79381.405511@grasshopper.cs.duke.edu> <20020620114511.A22413@unixdaemons.com> <15634.534.696063.241224@grasshopper.cs.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <15634.534.696063.241224@grasshopper.cs.duke.edu>; from gallatin@cs.duke.edu on Thu, Jun 20, 2002 at 12:25:58PM -0400 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, Jun 20, 2002 at 12:25:58PM -0400, Andrew Gallatin wrote: [...] > > > Do you think it would be feasable to glue in a new jumbo (10K?) > > > allocator on top of the existing mbuf and mcl allocators using the > > > existing mechanisms and the existing MCLBYTES > PAGE_SIZE support > > > (but broken out into separte functions and macros)? > > > > Assuming that you can still play those VM tricks with the pages spit > > out by mb_alloc (kern/subr_mbuf.c in -CURRENT), then this wouldn't be a > > problem at all. It's easy to add a new fixed-size type allocation to > > mb_alloc. In fact, it would be beneficial. mb_alloc uses per-CPU > > caches and also makes mbuf and cluster allocations share the same > > per-CPU lock. What could be done is that the jumbo buffer allocations > > could share the same lock as well (since they will likely usually be > > allocated right after an mbuf is). This would give us jumbo-cluster > > support, but it would only be useful for devices clued enough to break > > up the cluster into PAGE_SIZE chunks and do scatter/gather. For most > > worthy gigE devices, I don't think this should be a problem. > > I'm a bit worried about other devices.. Tradidtionally, mbufs have > never crossed page boundaries so most drivers never bother to check > for a transmit mbuf crossing a page boundary. Using physically > discontigous mbufs could lead to a lot of subtle data corruption. I assume here that when you say "mbuf" you mean "jumbo buffer attached to an mbuf." In that case, yeah, all that we need to make sure of is that the driver knows that it's dealing with non-physically-contiguous pages. For what concerns regular 2K mbuf clusters as well as the 256 byte mbufs themselves, they never cross page boundaries so this should not be a problem for those drivers that do not use jumbo clusters. > One question. I've observed some really anomolous behaviour under > -stable with my Myricom GM driver (2Gb/s + 2Gb/s link speed, Dual 1GHz > pIII). When I use 4K mbufs for receives, the best speed I see is > about 1300Mb/sec. However, if I use private 9K physically contiguous > buffers I see 1850Mb/sec (iperf TCP). > > The obvious conclusion is that there's a lot of overhead in setting up > the DMA engines, but that's not the case; we have a fairly quick chain > dma engine. I've provided a "control" by breaking my contiguous > buffers down into 4K chunks so that I do the same number of DMAs in > both cases and I still see ~1850 Mb/sec for the 9K buffers. > > A coworker suggested that the problem was that when doing copyouts to > userspace, the PIII was doing speculative reads and loading the cache > with the next page. However, we then start copying from a totally > different address using discontigous buffers, so we effectively take > 2x the number of cache misses we'd need to. Does that sound > reasonable to you? I need to try malloc'ing virtually contigous and > physically discontigous buffers & see if I get the same (good) > performance... I believe that the Intel chips do "virtual page caching" and that the logic that does the virtual -> physical address translation sits between the L2 cache and RAM. If that is indeed the case, then your idea of testing with virtually contiguous pages is a good one. Unfortunately, I don't know if the PIII is doing speculative cache-loads, but it could very well be the case. If it is and if in fact the chip does caching based on virtual addresses, then providing it with virtually contiguous address space may yield better results. If you try this, please let me know. I'm extremely interested in seeing the results! > Cheers, > > Drew Regards, -- Bosko Milekic bmilekic@unixdaemons.com bmilekic@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 20 11:17:11 2002 Delivered-To: freebsd-net@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id BC63637B404; Thu, 20 Jun 2002 11:17:02 -0700 (PDT) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id OAA08166; Thu, 20 Jun 2002 14:16:58 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id g5KIGSZ30476; Thu, 20 Jun 2002 14:16:28 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15634.7164.58371.9141@grasshopper.cs.duke.edu> Date: Thu, 20 Jun 2002 14:16:28 -0400 (EDT) To: Bosko Milekic Cc: "Kenneth D. Merry" , current@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: new zero copy sockets snapshot In-Reply-To: <20020620134723.A22954@unixdaemons.com> References: <20020618223635.A98350@panzer.kdm.org> <20020619090046.A2063@panzer.kdm.org> <20020619120641.A18434@unixdaemons.com> <15633.17238.109126.952673@grasshopper.cs.duke.edu> <20020619233721.A30669@unixdaemons.com> <15633.62357.79381.405511@grasshopper.cs.duke.edu> <20020620114511.A22413@unixdaemons.com> <15634.534.696063.241224@grasshopper.cs.duke.edu> <20020620134723.A22954@unixdaemons.com> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid 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 Bosko Milekic writes: > > > > I'm a bit worried about other devices.. Tradidtionally, mbufs have > > never crossed page boundaries so most drivers never bother to check > > for a transmit mbuf crossing a page boundary. Using physically > > discontigous mbufs could lead to a lot of subtle data corruption. > > I assume here that when you say "mbuf" you mean "jumbo buffer attached > to an mbuf." In that case, yeah, all that we need to make sure of is Yes. > that the driver knows that it's dealing with non-physically-contiguous > pages. For what concerns regular 2K mbuf clusters as well as the 256 > byte mbufs themselves, they never cross page boundaries so this should > not be a problem for those drivers that do not use jumbo clusters. But it would be problematic if we used the 10K jumbo cluster in so_send() like I'd like to. Ah, the pains of legacy code... :-( I'm also having a little trouble convincing myself that page-crossing jumbo clusters would be safe in all scenarios. I suppose if you were to make the transmit logic in all drivers which supported jumbo frames clueful, then using them for receives would be safe. > > One question. I've observed some really anomolous behaviour under > > -stable with my Myricom GM driver (2Gb/s + 2Gb/s link speed, Dual 1GHz > > pIII). When I use 4K mbufs for receives, the best speed I see is > > about 1300Mb/sec. However, if I use private 9K physically contiguous > > buffers I see 1850Mb/sec (iperf TCP). > > > > The obvious conclusion is that there's a lot of overhead in setting up > > the DMA engines, but that's not the case; we have a fairly quick chain > > dma engine. I've provided a "control" by breaking my contiguous > > buffers down into 4K chunks so that I do the same number of DMAs in > > both cases and I still see ~1850 Mb/sec for the 9K buffers. > > > > A coworker suggested that the problem was that when doing copyouts to > > userspace, the PIII was doing speculative reads and loading the cache > > with the next page. However, we then start copying from a totally > > different address using discontigous buffers, so we effectively take > > 2x the number of cache misses we'd need to. Does that sound > > reasonable to you? I need to try malloc'ing virtually contigous and > > physically discontigous buffers & see if I get the same (good) > > performance... > > I believe that the Intel chips do "virtual page caching" and that the > logic that does the virtual -> physical address translation sits between > the L2 cache and RAM. If that is indeed the case, then your idea of > testing with virtually contiguous pages is a good one. > Unfortunately, I don't know if the PIII is doing speculative > cache-loads, but it could very well be the case. If it is and if in > fact the chip does caching based on virtual addresses, then providing it > with virtually contiguous address space may yield better results. If > you try this, please let me know. I'm extremely interested in seeing > the results! Thanks for your input. I'll post the results when I get to it. I'm working on an AIX driver right now and I need to finish that before I have any playtime.. (AIX is utterly bizzare; pagable kernel, misleading docs, etc, etc) Thanks again, Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 20 14:29:41 2002 Delivered-To: freebsd-net@freebsd.org Received: from smtp05.wxs.nl (smtp05.wxs.nl [195.121.6.57]) by hub.freebsd.org (Postfix) with ESMTP id 1272E37B408; Thu, 20 Jun 2002 14:29:22 -0700 (PDT) Received: from bsdpc ([80.60.248.65]) by smtp05.wxs.nl (Netscape Messaging Server 4.15) with ESMTP id GY0X0W00.U3B; Thu, 20 Jun 2002 23:29:20 +0200 Content-Type: text/plain; charset="us-ascii" From: "Peter J. Blok" To: freebsd-hackers@freebsd.org, freebsd-net@freebsd.org Subject: multiple gateways Date: Thu, 20 Jun 2002 23:29:17 +0200 User-Agent: KMail/1.4.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200206202329.17885.Peter.Blok@inter.NL.net> 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 know this topic has been brought up numerous times. I have 4 IP4 internal networks (sf0 .. sf3) I have a cable modem connection ep0 and a DSL ep1 connection too. I'd like to route all traffic from sf0 and sf1 to the DSL connection and the others to the cable modem. At the same time I'd like to offer the protection of ipfilter. Traffic on sf0 should not see traffic on sf1 etc. Since this seems not possible with the both stable and current, I would like to make a solution for it, inside the kernel. I am thinking of creating a routing table based on source address and designate the right gateway. Thoughts and opinions are very welcome. Where do you suggest I start? Peter P.S. If this functionality exists (without bridging) I'd like to know as well To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 20 14:34:34 2002 Delivered-To: freebsd-net@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id A0BA737B408; Thu, 20 Jun 2002 14:34:11 -0700 (PDT) Received: by elvis.mu.org (Postfix, from userid 1098) id 69DD7AE2BE; Thu, 20 Jun 2002 14:34:11 -0700 (PDT) Date: Thu, 20 Jun 2002 14:34:11 -0700 From: Bill Fumerola To: "Peter J. Blok" Cc: freebsd-hackers@freebsd.org, freebsd-net@freebsd.org Subject: Re: multiple gateways Message-ID: <20020620213411.GD75238@elvis.mu.org> References: <200206202329.17885.Peter.Blok@inter.NL.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200206202329.17885.Peter.Blok@inter.NL.net> User-Agent: Mutt/1.3.27i X-Operating-System: FreeBSD 4.5-MUORG-20020423 i386 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, Jun 20, 2002 at 11:29:17PM +0200, Peter J. Blok wrote: > Since this seems not possible with the both stable and current, I would like > to make a solution for it, inside the kernel. I am thinking of creating a > routing table based on source address and designate the right gateway. man ipfw, particularly the section describing 'fwd'. for future reference, questions belong on , not cross-posted to -hackers & -net. -- - bill fumerola / fumerola@yahoo-inc.com / billf@FreeBSD.org / billf@mu.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 20 16: 2:28 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id 45D5137B420; Thu, 20 Jun 2002 16:00:31 -0700 (PDT) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020620230030.ZOAX11426.rwcrmhc51.attbi.com@InterJet.elischer.org>; Thu, 20 Jun 2002 23:00:30 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id PAA32992; Thu, 20 Jun 2002 15:56:07 -0700 (PDT) Date: Thu, 20 Jun 2002 15:56:06 -0700 (PDT) From: Julian Elischer To: "Peter J. Blok" Cc: freebsd-hackers@freebsd.org, freebsd-net@freebsd.org Subject: Re: multiple gateways In-Reply-To: <200206202329.17885.Peter.Blok@inter.NL.net> Message-ID: 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 You an do this for OUTGOING packets using ipfw and teh 'fwd' keyword. (it can be used to override 'next hop' routing decisions.) INCOMING is a whole different problem. On Thu, 20 Jun 2002, Peter J. Blok wrote: > Hi, > > I know this topic has been brought up numerous times. I have 4 IP4 internal > networks (sf0 .. sf3) > > I have a cable modem connection ep0 and a DSL ep1 connection too. I'd like to > route all traffic from sf0 and sf1 to the DSL connection and the others to > the cable modem. At the same time I'd like to offer the protection of > ipfilter. Traffic on sf0 should not see traffic on sf1 etc. > > Since this seems not possible with the both stable and current, I would like > to make a solution for it, inside the kernel. I am thinking of creating a > routing table based on source address and designate the right gateway. > > Thoughts and opinions are very welcome. Where do you suggest I start? > > Peter > > P.S. If this functionality exists (without bridging) I'd like to know as well > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" 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 Thu Jun 20 18:44:37 2002 Delivered-To: freebsd-net@freebsd.org Received: from soho1.binc.net (soho1.binc.net [64.73.16.3]) by hub.freebsd.org (Postfix) with SMTP id C4E4437B40A for ; Thu, 20 Jun 2002 18:44:22 -0700 (PDT) Received: (qmail 19276 invoked from network); 21 Jun 2002 01:44:20 -0000 Received: from miwi1dsl-a64.wi.tds.net (HELO Homer.the-rob.com) ([216.170.184.65]) (envelope-sender ) by the-rob.com (qmail-ldap-1.03) with SMTP for ; 21 Jun 2002 01:44:20 -0000 Content-Type: text/plain; charset="iso-8859-1" From: Rob Zietlow To: Brian Somers , Julian Elischer , net@freebsd.org Subject: Re: Issues_with_PPPoE_and_4.6 (got on now) Date: Thu, 20 Jun 2002 20:44:20 -0500 User-Agent: KMail/1.4.1 Cc: rob@the-rob.com References: <4363.216.170.186.25.1024537217.squirrel@www.soho.berbee.com> <20020620212247.564903ee.brian@FreeBSD.org> In-Reply-To: <20020620212247.564903ee.brian@FreeBSD.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200206202044.20669.Rob@the-rob.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 On Thursday 20 June 2002 03:22 pm, Brian Somers wrote: > I get this here: > > Jun 12 22:31:38 gw ppp[93193]: Phase: Received NGM_PPPOE_ACNAME (hook > "hak") Jun 12 22:31:39 gw ppp[93193]: Phase: Received NGM_PPPOE_SESSION= ID > (hook "*") Jun 12 22:31:40 gw ppp[93193]: Phase: Received NGM_PPPOE_SUC= CESS > (hook "tun1") > > But I'm a little confused as to why the most recent of these messages > are from June 12. I should see some nearly every day in my logs here. > > The NGM_PPPOE_<11> message is the new session id message which ppp does= n't > yet recognise (but does in my local version). > > I'll look into this some more. Well....I'm online now. I just let it sit and I opened up some stuff and = it=20 tried to connect up to the internet and it worked.. So it appears touch = and=20 go. I had this same issue the first time I ran 4.6-RC...3 I think, but i= t=20 was an RC vers. below is from the ppp.log from when I connected.=20 Jun 20 20:10:11 PITA ppp[72]: tun0: Phase: Received NGM_PPPOE_ACNAME (hoo= k=20 "miwi-6400-inet-n^G^HM-^@ ^H^P ^K^H") Jun 20 20:10:12 PITA ppp[72]: tun0: Phase: Received NGM_PPPOE_<11> (hook=20 "`^U^H^Hh ^K^H") Jun 20 20:10:13 PITA ppp[72]: tun0: Phase: Received NGM_PPPOE_SUCCESS (ho= ok=20 "tun0") Jun 20 20:10:13 PITA ppp[72]: tun0: Phase: deflink: carrier -> login Jun 20 20:10:13 PITA ppp[72]: tun0: Phase: deflink: login -> lcp Jun 20 20:10:13 PITA ppp[72]: tun0: LCP: FSM: Using "deflink" as a transp= ort Jun 20 20:10:13 PITA ppp[72]: tun0: LCP: deflink: State change Initial --= >=20 Closed Jun 20 20:10:13 PITA ppp[72]: tun0: LCP: deflink: State change Closed -->= =20 Stopped Jun 20 20:10:13 PITA ppp[72]: tun0: LCP: deflink: RecvConfigReq(1) state = =3D=20 Stopped Jun 20 20:10:13 PITA ppp[72]: tun0: LCP: MRU[4] 1492 Jun 20 20:10:13 PITA ppp[72]: tun0: LCP: AUTHPROTO[4] 0xc023 (PAP) Jun 20 20:10:13 PITA ppp[72]: tun0: LCP: MAGICNUM[6] 0x7c12a05b Jun 20 20:09:39 PITA ppp[72]: tun0: Phase: deflink: : 0 packets in, 0 pac= kets=20 out Jun 20 20:09:39 PITA ppp[72]: tun0: Phase: total 0 bytes/sec, peak 0=20 bytes/sec on Thu Jun 20 20:09:34 2002 Jun 20 20:09:39 PITA ppp[72]: tun0: Phase: deflink: hangup -> opening Jun 20 20:09:39 PITA ppp[72]: tun0: Phase: deflink: Enter pause (30) for=20 redialing. Jun 20 20:10:09 PITA ppp[72]: tun0: Phase: deflink: Connected! Jun 20 20:10:09 PITA ppp[72]: tun0: Phase: deflink: opening -> dial Jun 20 20:10:09 PITA ppp[72]: tun0: Phase: deflink: dial -> carrier Jun 20 20:10:11 PITA ppp[72]: tun0: Phase: Received NGM_PPPOE_ACNAME (hoo= k=20 "miwi-6400-inet-n^G^HM-^@ ^H^P ^K^H") Jun 20 20:10:12 PITA ppp[72]: tun0: Phase: Received NGM_PPPOE_<11> (hook=20 "`^U^H^Hh ^K^H") Jun 20 20:10:13 PITA ppp[72]: tun0: Phase: Received NGM_PPPOE_SUCCESS (ho= ok=20 "tun0") Jun 20 20:10:13 PITA ppp[72]: tun0: Phase: deflink: carrier -> login Jun 20 20:10:13 PITA ppp[72]: tun0: Phase: deflink: login -> lcp Jun 20 20:10:13 PITA ppp[72]: tun0: LCP: FSM: Using "deflink" as a transp= ort Jun 20 20:10:13 PITA ppp[72]: tun0: LCP: deflink: State change Initial --= >=20 Closed Jun 20 20:10:13 PITA ppp[72]: tun0: LCP: deflink: State change Closed -->= =20 Stopped Jun 20 20:10:13 PITA ppp[72]: tun0: LCP: deflink: RecvConfigReq(1) state = =3D=20 Stopped Jun 20 20:10:13 PITA ppp[72]: tun0: LCP: MRU[4] 1492 Jun 20 20:10:13 PITA ppp[72]: tun0: LCP: AUTHPROTO[4] 0xc023 (PAP) Jun 20 20:10:13 PITA ppp[72]: tun0: LCP: MAGICNUM[6] 0x7c12a05b Jun 20 20:10:13 PITA ppp[72]: tun0: LCP: deflink: SendConfigReq(1) state = =3D=20 Stopped Jun 20 20:10:13 PITA ppp[72]: tun0: LCP: MRU[4] 1492 Jun 20 20:10:13 PITA ppp[72]: tun0: LCP: MAGICNUM[6] 0x62314bc6 Jun 20 20:10:13 PITA ppp[72]: tun0: LCP: QUALPROTO[8] proto c025, interv= al=20 30000ms Jun 20 20:10:13 PITA ppp[72]: tun0: LCP: deflink: SendConfigAck(1) state = =3D=20 Stopped Jun 20 20:10:13 PITA ppp[72]: tun0: LCP: MRU[4] 1492 Jun 20 20:10:13 PITA ppp[72]: tun0: LCP: AUTHPROTO[4] 0xc023 (PAP) Jun 20 20:10:13 PITA ppp[72]: tun0: LCP: MAGICNUM[6] 0x7c12a05b Jun 20 20:10:13 PITA ppp[72]: tun0: LCP: deflink: LayerStart Jun 20 20:10:13 PITA ppp[72]: tun0: LCP: deflink: State change Stopped --= >=20 Ack-Sent Jun 20 20:10:13 PITA ppp[72]: tun0: LCP: deflink: RecvConfigAck(1) state = =3D=20 Ack-Sent Jun 20 20:10:13 PITA ppp[72]: tun0: LCP: deflink: State change Ack-Sent -= ->=20 Opened Jun 20 20:10:13 PITA ppp[72]: tun0: LCP: deflink: LayerUp Jun 20 20:10:13 PITA ppp[72]: tun0: Phase: bundle: Authenticate Jun 20 20:10:13 PITA ppp[72]: tun0: Phase: deflink: his =3D PAP, mine =3D= none Jun 20 20:10:13 PITA ppp[72]: tun0: Phase: Pap Output: rzietlow2 ******** Jun 20 20:10:13 PITA ppp[72]: tun0: Phase: Pap Input: SUCCESS () Jun 20 20:10:13 PITA ppp[72]: tun0: CCP: FSM: Using "deflink" as a transp= ort Jun 20 20:10:13 PITA ppp[72]: tun0: CCP: deflink: State change Initial --= >=20 Closed Jun 20 20:10:13 PITA ppp[72]: tun0: CCP: deflink: LayerStart. Jun 20 20:10:13 PITA ppp[72]: tun0: CCP: MPPE: Not usable without CHAP81 Jun 20 20:10:13 PITA ppp[72]: tun0: CCP: deflink: SendConfigReq(1) state = =3D=20 Closed Jun 20 20:10:13 PITA ppp[72]: tun0: CCP: DEFLATE[4] win 15 Jun 20 20:10:13 PITA ppp[72]: tun0: CCP: PRED1[2] Jun 20 20:10:13 PITA ppp[72]: tun0: CCP: deflink: State change Closed -->= =20 Req-Sent Jun 20 20:10:13 PITA ppp[72]: tun0: Phase: deflink: lcp -> open Jun 20 20:10:13 PITA ppp[72]: tun0: Phase: bundle: Network Jun 20 20:10:13 PITA ppp[72]: tun0: IPCP: FSM: Using "deflink" as a trans= port Jun 20 20:10:13 PITA ppp[72]: tun0: IPCP: deflink: State change Initial -= ->=20 Closed Jun 20 20:10:13 PITA ppp[72]: tun0: IPCP: deflink: LayerStart. Jun 20 20:10:13 PITA ppp[72]: tun0: IPCP: deflink: SendConfigReq(1) state= =3D=20 Closed Jun 20 20:10:13 PITA ppp[72]: tun0: IPCP: IPADDR[6] 192.168.1.1 Jun 20 20:10:13 PITA ppp[72]: tun0: IPCP: COMPPROTO[6] 16 VJ slots with= slot=20 compression Jun 20 20:10:13 PITA ppp[72]: tun0: IPCP: PRIDNS[6] 204.246.1.20 Jun 20 20:10:13 PITA ppp[72]: tun0: IPCP: SECDNS[6] 204.70.128.1 Jun 20 20:10:13 PITA ppp[72]: tun0: IPCP: deflink: State change Closed --= >=20 Req-Sent Jun 20 20:10:13 PITA ppp[72]: tun0: IPCP: deflink: RecvConfigReq(1) state= =3D=20 Req-Sent Jun 20 20:10:13 PITA ppp[72]: tun0: IPCP: IPADDR[6] 216.170.184.1 Jun 20 20:10:13 PITA ppp[72]: tun0: IPCP: deflink: SendConfigAck(1) state= =3D=20 Req-Sent Jun 20 20:10:13 PITA ppp[72]: tun0: IPCP: IPADDR[6] 216.170.184.1 Jun 20 20:10:13 PITA ppp[72]: tun0: IPCP: deflink: State change Req-Sent = -->=20 Ack-Sent Jun 20 20:10:13 PITA ppp[72]: tun0: LCP: deflink: RecvProtocolRej(2) stat= e =3D=20 Opened Jun 20 20:10:13 PITA ppp[72]: tun0: LCP: deflink: -- Protocol 0x80fd=20 (Compression Control Protocol) was rejected! Jun 20 20:10:13 PITA ppp[72]: tun0: CCP: deflink: State change Req-Sent -= ->=20 Stopped Jun 20 20:10:13 PITA ppp[72]: tun0: IPCP: deflink: RecvConfigRej(1) state= =3D=20 Ack-Sent Jun 20 20:10:13 PITA ppp[72]: tun0: IPCP: COMPPROTO[6] 16 VJ slots with= slot=20 compression Jun 20 20:10:13 PITA ppp[72]: tun0: IPCP: deflink: SendConfigReq(2) state= =3D=20 Ack-Sent Jun 20 20:10:13 PITA ppp[72]: tun0: IPCP: IPADDR[6] 192.168.1.1 Jun 20 20:10:13 PITA ppp[72]: tun0: IPCP: PRIDNS[6] 204.246.1.20 Jun 20 20:10:13 PITA ppp[72]: tun0: IPCP: SECDNS[6] 204.70.128.1 Jun 20 20:10:13 PITA ppp[72]: tun0: IPCP: deflink: RecvConfigNak(2) state= =3D=20 Ack-Sent Jun 20 20:10:13 PITA ppp[72]: tun0: IPCP: IPADDR[6] 216.170.184.65 Jun 20 20:10:13 PITA ppp[72]: tun0: IPCP: IPADDR[6] changing address:=20 192.168.1.1 --> 216.170.184.65 Jun 20 20:10:13 PITA ppp[72]: tun0: IPCP: deflink: SendConfigReq(3) state= =3D=20 Ack-Sent Jun 20 20:10:13 PITA ppp[72]: tun0: IPCP: IPADDR[6] 216.170.184.65 Jun 20 20:10:13 PITA ppp[72]: tun0: IPCP: PRIDNS[6] 204.246.1.20 Jun 20 20:10:13 PITA ppp[72]: tun0: IPCP: SECDNS[6] 204.70.128.1 Jun 20 20:10:13 PITA ppp[72]: tun0: IPCP: deflink: RecvConfigAck(3) state= =3D=20 Ack-Sent Jun 20 20:10:13 PITA ppp[72]: tun0: IPCP: deflink: State change Ack-Sent = -->=20 Opened Jun 20 20:10:13 PITA ppp[72]: tun0: IPCP: deflink: LayerUp. Jun 20 20:10:13 PITA ppp[72]: tun0: IPCP: myaddr 216.170.184.65 hisaddr =3D= =20 216.170.184.1 Jun 20 20:10:22 PITA ppp[72]: tun0: LCP: deflink: RecvEchoRequest(1) stat= e =3D=20 Opened : To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 20 19:16:58 2002 Delivered-To: freebsd-net@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 4086F37B413; Thu, 20 Jun 2002 19:16:52 -0700 (PDT) Received: (from ken@localhost) by panzer.kdm.org (8.11.6/8.9.1) id g5L2GeL16810; Thu, 20 Jun 2002 20:16:40 -0600 (MDT) (envelope-from ken) Date: Thu, 20 Jun 2002 20:16:40 -0600 From: "Kenneth D. Merry" To: Bosko Milekic Cc: Andrew Gallatin , current@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: new zero copy sockets snapshot Message-ID: <20020620201640.A16781@panzer.kdm.org> References: <20020618223635.A98350@panzer.kdm.org> <20020619090046.A2063@panzer.kdm.org> <20020619120641.A18434@unixdaemons.com> <15633.17238.109126.952673@grasshopper.cs.duke.edu> <20020619233721.A30669@unixdaemons.com> <15633.62357.79381.405511@grasshopper.cs.duke.edu> <20020620114511.A22413@unixdaemons.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020620114511.A22413@unixdaemons.com>; from bmilekic@unixdaemons.com on Thu, Jun 20, 2002 at 11:45:11AM -0400 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, Jun 20, 2002 at 11:45:11 -0400, Bosko Milekic wrote: > On Thu, Jun 20, 2002 at 11:24:05AM -0400, Andrew Gallatin wrote: > > Bosko Milekic writes: > > > > By the way, my other two comments have been deleted, but reading the > > > page that Ken maintains I noticed that Alfred already pointed them out. > > > > <...> > > > > Ken has been maintaining the patchset on his own for quite some time. > > I must admit that I've not looked closely at these issues, so I didn't > > feel it was appropriate for me to comment on them. I didn't mean to > > discount your other comments. > > Ken has already taken care of it. I'm really impressed that Ken has > maintained the patchset for so long. It's really good that the > zero-copy stuff has not been dropped over the years. Perforce certainly helps. :) Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 20 21:44:10 2002 Delivered-To: freebsd-net@freebsd.org Received: from voodooland.net (voodooland.net [63.173.37.6]) by hub.freebsd.org (Postfix) with ESMTP id 1B76637B40D for ; Thu, 20 Jun 2002 21:44:04 -0700 (PDT) Received: from 65-221-226-228.sutv.com (65-221-226-228.sutv.com [65.221.226.228]) by voodooland.net (Postfix) with ESMTP id 5063B70609 for ; Thu, 20 Jun 2002 23:42:39 -0500 (CDT) Date: Thu, 20 Jun 2002 23:44:00 -0500 Mime-Version: 1.0 (Apple Message framework v482) Content-Type: multipart/alternative; boundary=Apple-Mail-3--917199499 Subject: Neat litle packet generator... From: Chris Watson To: freebsd-net@freebsd.org Message-Id: <815C315E-84D1-11D6-AFA6-0003937B4040@voodooland.net> X-Mailer: Apple Mail (2.482) 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 --Apple-Mail-3--917199499 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed While reading the Secure BGP template for a new Juniper M series router I need to config the author of the paper wore a neat little util for testing firewalls and it uses ipfw and dummynet for rate limiting. I thought someone else out there might find it neat and/or useful. Chris -- ibm said they were investing 1 billion $ into open source projects Asmodee`: do you know what happens when you invest money in opensource projects? NOTHING! it buys the coders some beer, nachos, and porn to watch instead of coding. --Apple-Mail-3--917199499 Content-Transfer-Encoding: 7bit Content-Type: text/enriched; charset=US-ASCII While reading the Secure BGP template for a new Juniper M series router I need to config the author of the paper wore a neat little util for testing firewalls and it uses ipfw and dummynet for rate limiting. I thought someone else out there might find it neat and/or useful. Chris -- Courier New< ibm said they were investing 1 billion $ into open source projects < Asmodee`: do you know what happens when you invest money in opensource projects? < NOTHING! it buys the coders some beer, nachos, and porn to watch instead of coding.Times New Roman --Apple-Mail-3--917199499-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 20 21:45: 7 2002 Delivered-To: freebsd-net@freebsd.org Received: from voodooland.net (voodooland.net [63.173.37.6]) by hub.freebsd.org (Postfix) with ESMTP id 65B1137B40E for ; Thu, 20 Jun 2002 21:45:01 -0700 (PDT) Received: from 65-221-226-228.sutv.com (65-221-226-228.sutv.com [65.221.226.228]) by voodooland.net (Postfix) with ESMTP id 47D2870609 for ; Thu, 20 Jun 2002 23:43:38 -0500 (CDT) Date: Thu, 20 Jun 2002 23:44:59 -0500 Mime-Version: 1.0 (Apple Message framework v482) Content-Type: multipart/alternative; boundary=Apple-Mail-4--917140552 Subject: Neat little packet generator Pt.II From: Chris Watson To: freebsd-net@freebsd.org Message-Id: X-Mailer: Apple Mail (2.482) 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 --Apple-Mail-4--917140552 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Might help if I include the URL before hitting send... http://www.qorbit.net/tools.html It's called scooter. Chris -- ibm said they were investing 1 billion $ into open source projects Asmodee`: do you know what happens when you invest money in opensource projects? NOTHING! it buys the coders some beer, nachos, and porn to watch instead of coding. --Apple-Mail-4--917140552 Content-Transfer-Encoding: 7bit Content-Type: text/enriched; charset=US-ASCII Might help if I include the URL before hitting send... http://www.qorbit.net/tools.html It's called scooter. Chris -- Courier New< ibm said they were investing 1 billion $ into open source projects < Asmodee`: do you know what happens when you invest money in opensource projects? < NOTHING! it buys the coders some beer, nachos, and porn to watch instead of coding.Times New Roman --Apple-Mail-4--917140552-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 20 22:44:41 2002 Delivered-To: freebsd-net@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id EE02B37B409; Thu, 20 Jun 2002 22:44:36 -0700 (PDT) Received: (from ken@localhost) by panzer.kdm.org (8.11.6/8.9.1) id g5L5iar18208; Thu, 20 Jun 2002 23:44:36 -0600 (MDT) (envelope-from ken) Date: Thu, 20 Jun 2002 23:44:35 -0600 From: "Kenneth D. Merry" To: current@FreeBSD.org Cc: net@FreeBSD.org Subject: updated zero copy sockets snapshot available Message-ID: <20020620234435.A18183@panzer.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.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 I've released a new zero copy sockets snapshot, based on -current from June 20th, 2002. http://people.FreeBSD.org/~ken/zero_copy This fixes the following issues: - Use SLIST_FIRST() macros to access the first entry in a SLIST in uipc_jumbo.c. I didn't fix all of these when Alfred pointed out the problem. (Pointed out by Bosko Milekic.) - Remove superfluous TI_LOCK()/TI_UNLOCK() calls in the zero copy version of ti_newbuf_jumbo(). We already have the lock in all the places ti_newbuf_jumbo() is called. (Prompted by Bosko Milekic.) - In the SIOCGIFMEDIA ioctl in ifmedia_ioctl(), avoid calling malloc() with M_WAITOK. Return an error if the M_NOWAIT malloc fails. The ti(4) driver and the wi(4) driver, at least, call this with a mutex held. This causes witness warnings for 'ifconfig -a' with a wi(4) or ti(4) board in the system. (I've only verified for ti(4)). Feedback and comments are welcome! Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 20 23: 4:57 2002 Delivered-To: freebsd-net@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 83F2E37B405 for ; Thu, 20 Jun 2002 23:04:52 -0700 (PDT) Received: (from ken@localhost) by panzer.kdm.org (8.11.6/8.9.1) id g5L64di18382; Fri, 21 Jun 2002 00:04:39 -0600 (MDT) (envelope-from ken) Date: Fri, 21 Jun 2002 00:04:39 -0600 From: "Kenneth D. Merry" To: Barney Wolff Cc: "McKenna, Lee" , "'Fabien THOMAS'" , paleph@pacbell.net, freebsd-net@FreeBSD.ORG Subject: Re: bge driver issue Message-ID: <20020621000439.A18344@panzer.kdm.org> References: <3EA88113DE92D211807300805FA7994209149EC2@chaplin.lodgenet.com> <20020619210646.A36559@tp.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020619210646.A36559@tp.databus.com>; from barney@tp.databus.com on Wed, Jun 19, 2002 at 09:06:46PM -0400 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 Wed, Jun 19, 2002 at 21:06:46 -0400, Barney Wolff wrote: > Er, you would appear to be measuring the transfer rate of your disk, > unless you actually have enough ram to cache a 1.2GB file. > > By coincidence, tonight I hooked my dual 1.0GHz PIII running fbsd 4.6-stable > to a Mac G4 OS-X (also dual 1GHz cpus) using an Intel PRO/1000T desktop > adapter on the fbsd side. Here's the result of the Mac doing an ftp get > from fbsd: > > ftp> get X11R6-011112.tgz /dev/null > local: /dev/null remote: X11R6-011112.tgz > 200 PORT command successful. > 150 Opening BINARY mode data connection for 'X11R6-011112.tgz' (194432456 bytes). > 226 Transfer complete. > 194432456 bytes received in 6.45 seconds (30123284 bytes/s) > ftp> get X11R6-011112.tgz /dev/null > local: /dev/null remote: X11R6-011112.tgz > 200 PORT command successful. > 150 Opening BINARY mode data connection for 'X11R6-011112.tgz' (194432456 bytes). > 226 Transfer complete. > 194432456 bytes received in 1.76 seconds (110555016 bytes/s) > > The first transfer shows the speed of my disk. The second is really > pretty good. Adding in the header overhead, we're over 920 Mbps. > > Going in the other direction I never got over 500 Mbps, don't yet know why. > Windows were 65535 on both sides. Bumping the window over 100KB resulted > in a sharp drop in performance, also as yet unexplained. Setting the send > window above about 200KB resulted in failure to open a connection - no bufs > available. That too will need some investigation. The reason you probably got such good performance doing a get from the Mac box is that FreeBSD's ftpd uses sendfile() -- zero copy for file I/O. MacOS X probably doesn't use sendfile() in its ftp daemon. > The test was run through a Dell 2508 switch - I could not get 1000baseTX > with a crossover cable, but perhaps it was not good enough, although > marked cat5. In my experience, a straight-through cat5 cable works fine as a "crossover" between two 1000baseT NICs. Since 1000baseT transmits and receives on all 8 wires simultaneously, you can't exactly hook the send and receive wires up like you can with 10baseT and 100baseTX. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jun 21 0:36:14 2002 Delivered-To: freebsd-net@freebsd.org Received: from aaz.links.ru (aaz.links.ru [193.125.152.37]) by hub.freebsd.org (Postfix) with ESMTP id 45A5637B40E; Fri, 21 Jun 2002 00:36:04 -0700 (PDT) Received: (from babolo@localhost) by aaz.links.ru (8.9.3/8.9.3) id LAA16091; Fri, 21 Jun 2002 11:37:10 +0400 (MSD) Message-Id: <200206210737.LAA16091@aaz.links.ru> Subject: Re: multiple gateways In-Reply-To: <200206202329.17885.Peter.Blok@inter.NL.net> from "Peter J. Blok" at "Jun 20, 2 11:29:17 pm" To: Peter.Blok@inter.NL.net (Peter J. Blok) Date: Fri, 21 Jun 2002 11:37:09 +0400 (MSD) Cc: freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG From: "."@babolo.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: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Peter J. Blok writes: > I know this topic has been brought up numerous times. I have 4 IP4 internal > networks (sf0 .. sf3) > > I have a cable modem connection ep0 and a DSL ep1 connection too. I'd like to > route all traffic from sf0 and sf1 to the DSL connection and the others to > the cable modem. At the same time I'd like to offer the protection of > ipfilter. Traffic on sf0 should not see traffic on sf1 etc. > > Since this seems not possible with the both stable and current, I would like > to make a solution for it, inside the kernel. I am thinking of creating a > routing table based on source address and designate the right gateway. Source interface instead of source address. source address can be spoofed Or better some thing for routes as jail for processes? Different routing tables in one kernel And assign interfaces to tables. > Thoughts and opinions are very welcome. Where do you suggest I start? > > Peter > > P.S. If this functionality exists (without bridging) I'd like to know as well -- @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 Fri Jun 21 1:18:57 2002 Delivered-To: freebsd-net@freebsd.org Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 9E48B37B404; Fri, 21 Jun 2002 01:18:48 -0700 (PDT) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g5L8Imq77435; Fri, 21 Jun 2002 01:18:48 -0700 (PDT) (envelope-from rizzo) Date: Fri, 21 Jun 2002 01:18:47 -0700 From: Luigi Rizzo To: julian@freebsd.org Cc: net@freebsd.org Subject: Re: removing global variables from the network stack Message-ID: <20020621011847.C77089@iguana.icir.org> References: <20020619094420.C58636@iguana.icir.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: <20020619094420.C58636@iguana.icir.org>; from rizzo@icir.org on Wed, Jun 19, 2002 at 09:44:20AM -0700 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 Followup to my message, on which I got some valuable input from the usual suspects -- thanks to those who replied. Obviously an architecturally clean solution would be to import the m_tag thing done in NetBSD/OpenBSD and modify the mbuf routines to properly handle the tag chains. As a temporary and much less intrusive workaround, I have come up with the following solution which seems rather clean anyways: + It does not need any change in the system but in sys/sys/mbuf.h for the definition of the PACKET_TAG_* constants (which I have already committed); + it only involves simple modifications of the interested functions (callers and callees) + it is quite efficient because it does not require malloc'ing/freeing of the tags. + and it is similar in spirit to the m_tag approach so it will be hopefully easy to upgrade should we decide to go for m_tag at some point. Comments please ? I have used this to remove global variables which carried packet state from DIVERT, FORWARD, DUMMYNET and it took very very little, mostly deleting lines! I'd like to commit this stuff soon. As a matter of fact, I also thought of doing the commit in two steps -- first the infrastructure, then applications of it, but it turns out that there is no infrastructure other than the constants in mbuf.h :) cheers luigi ------------------------------------------------------------------- === A PROPOSAL TO CARRY STATE ALONG WITH PACKETS === To carry state along with packets, the mbuf chains are prepended with mbuf lookalikes (same as it was done for dummynet) which carry the required info. These 'tags' all start with an m_hdr containing: mh_type = MT_TAG; mh_flags = PACKET_TAG_foo; /* the required type */ mh_next = (MT_TAG is currently defined as MT_CONTROL, which already exists and was unused. But we could maybe define a new mbuf type, MT_TAG, and use it here). Other m_hdr fields (mh_nextpkt, mh_data) are available for tag-specific data. mh_len is available too, but i prefer to keep it unused. If a tag (such as dummynet ones) needs more room, you can use a larger structure with the m_hdr at the beginning e.g. struct dn_pkt { struct m_hdr m_hdr; } It is important to notice that IT IS THE CALLER'S RESPONSIBILITY to free the storage associated with the tags. This simplifies handling in the callee, which can safely skip over the blocks it is not interested in. Also, the callee cannot expect the info in the tags to survive beyond the call -- it needs to copy the data from the tags, not just take a reference. === TAG PROCESSING -- CALLEE === A routine which needs the info associated with the tags will have to do something like this near the very beginning: while (m->m_type == MT_TAG) { switch(m->m_tag_id) { default: printf("foo: unrecognised MT_TAG tag %d\n", m->m_tag_id); m = m->next; break; case PACKET_TAG_IPFORWARD: next_hop = (struct sockaddr_in *)m->m_hdr.mh_data; m = m->m_next; break; ... } } with the simplest case (just ignore any tag which might be there) being while (m->m_type == MT_TAG) m = m->next; === TAG PROCESSING -- CALLER === A routine wishing to insert a tag in front of the chain can do something like this: if (next_hop != NULL) { struct m_hdr tag; tag.mh_type = MT_TAG; tag.mh_flags = PACKET_TAG_IPFORWARD; tag.mh_next = m; tag.mh_data = (caddr_t)next_hop; /* tag-specific data */ ... ip_input((struct mbuf *)&tag); } Note that the tag is allocated on the stack, as per the rules defined above, and the callee is not supposed to free it or keep references to it. Of course you should make sure NOT TO SEND TAGS to routines which are unable to process them! ======================================================================== On Wed, Jun 19, 2002 at 09:44:20AM -0700, Luigi Rizzo wrote: > Hi, > I am trying to cleanup as much as possible the use of global > variables in the network stack, both for code clarity, and > to ease the use of this code in an SMP context. ... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jun 22 11:23:24 2002 Delivered-To: freebsd-net@freebsd.org Received: from Awfulhak.org (gw.Awfulhak.org [217.204.245.18]) by hub.freebsd.org (Postfix) with ESMTP id 2478B37B409 for ; Sat, 22 Jun 2002 11:23:12 -0700 (PDT) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [IPv6:fec0::1:12]) by Awfulhak.org (8.12.3/8.12.3) with ESMTP id g5MIN9Nl030422; Sat, 22 Jun 2002 19:23:09 +0100 (BST) (envelope-from brian@FreeBSD.org) Received: from hak.lan.Awfulhak.org (brian@localhost [IPv6:::1]) by hak.lan.Awfulhak.org (8.12.4/8.12.4) with SMTP id g5MIN2mv091434; Sat, 22 Jun 2002 19:23:03 +0100 (BST) (envelope-from brian@FreeBSD.org) Date: Sat, 22 Jun 2002 19:23:02 +0100 From: Brian Somers To: Michael Bretterklieber Cc: freebsd-net@FreeBSD.org Subject: Re: ppp callback-question Message-Id: <20020622192302.28711480.brian@FreeBSD.org> In-Reply-To: <3D0F54BE.6070701@inode.at> References: <3D0F54BE.6070701@inode.at> X-Mailer: Sylpheed version 0.7.6claws (GTK+ 1.2.10; i386-portbld-freebsd5.0) 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 I think I already answered this, but you should be able to set redial 3 to reduce the timeout. On Tue, 18 Jun 2002 17:41:50 +0200, Michael Bretterklieber wrote: > Hi, > > I have a dialin-Box with FreeBSD 3.5. I use the callback (cbcp) option > from ppp and the problem is, that ppp waites about 30 seconds until he > starts the callback. > Is there any option to reduce this timeout? > > bye, > -- > -- > -------------------------------------- > E-mail: Michael.Bretterklieber@jawa.at > ---------------------------- > JAWA Management Software GmbH > Liebenauer Hauptstr. 200 > A-8041 GRAZ > Tel: ++43-(0)316-403274-12 > Fax: ++43-(0)316-403274-10 > GSM: ++43-(0)676-93 96 698 > homepage: http://www.jawa.at > --------- privat ----------- > E-mail: mbretter@inode.at > homepage: http://www.inode.at/mbretter > -------------------------------------- -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jun 22 14:15:24 2002 Delivered-To: freebsd-net@freebsd.org Received: from Awfulhak.org (gw.Awfulhak.org [217.204.245.18]) by hub.freebsd.org (Postfix) with ESMTP id A506C37B400 for ; Sat, 22 Jun 2002 14:15:18 -0700 (PDT) Received: from mail.lan.Awfulhak.org (brian@hak.Awfulhak.org [IPv6:2001:6f8:602:1::12]) by Awfulhak.org (8.12.4/8.12.4) with SMTP id g5MLF8xq000722; Sat, 22 Jun 2002 22:15:16 +0100 (BST) (envelope-from brian@Awfulhak.org) Date: Sat, 22 Jun 2002 22:15:07 +0100 From: Brian Somers To: hantu Cc: freebsd-net@FreeBSD.ORG Subject: Re: digiboard pc/8i .. Message-Id: <20020622221507.1c23c701.brian@Awfulhak.org> In-Reply-To: <20020620230039.U636-100000@ns.giranti.co.id> References: <20020620230039.U636-100000@ns.giranti.co.id> X-Mailer: Sylpheed version 0.7.6claws (GTK+ 1.2.10; i386-portbld-freebsd5.0) 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 What driver are you using, what version of FreeBSD and what devices ? I've assuming the pc/8i is an ISA card ? If so, you should be using the dgb driver and /dev/cuaDxx in both -stable and -current... On Thu, 20 Jun 2002 23:09:33 +0700 (WIT), hantu wrote: > > hello all > > i have digiboard pc/8i adapter,... > i try to check all the port using command tip > if i put modem on port 1, the port 1 run well, the other drop .. only can > be connected but can't put modem command like AT or something else. > > please help me,.. > > thanks > -oo- -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jun 22 14:24:33 2002 Delivered-To: freebsd-net@freebsd.org Received: from 141.com (mail1.141.com [65.168.139.2]) by hub.freebsd.org (Postfix) with ESMTP id 578B637B403 for ; Sat, 22 Jun 2002 14:24:25 -0700 (PDT) Received: from 141.com [151.200.76.182] by 141.com with ESMTP (SMTPD32-7.10) id AB50C8910110; Sat, 22 Jun 2002 15:25:36 -0600 To: brian@awfulhak.org, freebsd-net@freebsd.org Subject: More pppoe debugging info Date: Sat, 22 Jun 2002 17:24:23 -0400 From: Andrew Lankford Message-Id: <200206221525187.SM01584@141.com> X-RBL-Warning: SPAMHEADERS: This E-mail has headers consistent with spam [4000020e]. X-Note: This E-mail was scanned for spam. 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 Below is my final attempt at documenting my problems using the latest stable ppp/netgraph combo with my DSL modem and 3Com 3c905C-TX ethernet card: Looks like the NGM_PPPOE_<11> (hook "M-^HM-^V^H^Hh ^K^H") string no longer bears any resemblance to the session id bytes. Sorry for not making sure all the text is wrapped properly, but I figure that would make it only harder to read. Andrew Lankford VERSION INFO: FreeBSD bogushost2 4.6-STABLE FreeBSD 4.6-STABLE #0: Sat Jun 22 15:48:33 EDT 2002 root@bogushost2:/usr/obj/usr/src/sys/ARL0402 i386 PPP Version 2.3.3 - Jun 22 2002 Contents of ppp.conf: default: allow users arlankfo nat unregistered_only yes set log +lcp ipcp phase tun command ccp verizondsl: # deny pap # deny chap # accept chap81 set socket /var/ppp/ppp "" 0117 set device PPPoE:xl0 set authname vze2ztys set authkey van48wee set speed sync set mru 1492 set redial 2 set timeout 0 # enable lqr to see if this will deal with bad connections or disconnects? enable lqr set dial set login set ifaddr 10.10.10.9/0 10.1.32.1/0 set urgent udp +53 # DNS searches faster? # enable dns add default HISADDR dial PPP.LOG: Jun 22 16:40:58 bogushost2 ppp[333]: Phase: Using interface: tun0 Jun 22 16:40:58 bogushost2 ppp[333]: Phase: deflink: Created in closed state Jun 22 16:40:58 bogushost2 ppp[333]: tun0: Command: verizondsl: set socket /var/ppp/ppp 0117 Jun 22 16:40:58 bogushost2 ppp[333]: tun0: Phase: Listening at local socket /var/ppp/ppp. Jun 22 16:40:58 bogushost2 ppp[333]: tun0: Command: verizondsl: set device PPPoE:xl0 Jun 22 16:40:58 bogushost2 ppp[333]: tun0: Command: verizondsl: set authname vze2ztys Jun 22 16:40:58 bogushost2 ppp[333]: tun0: Command: verizondsl: set authkey ******** Jun 22 16:40:58 bogushost2 ppp[333]: tun0: Command: verizondsl: set speed sync Jun 22 16:40:58 bogushost2 ppp[333]: tun0: Command: verizondsl: set mru 1492 Jun 22 16:40:58 bogushost2 ppp[333]: tun0: Command: verizondsl: set redial 2 Jun 22 16:40:58 bogushost2 ppp[333]: tun0: Command: verizondsl: set timeout 0 Jun 22 16:40:58 bogushost2 ppp[333]: tun0: Command: verizondsl: enable lqr Jun 22 16:40:58 bogushost2 ppp[333]: tun0: Command: verizondsl: set dial Jun 22 16:40:58 bogushost2 ppp[333]: tun0: Command: verizondsl: set login Jun 22 16:40:58 bogushost2 ppp[333]: tun0: Command: verizondsl: set ifaddr 10.10.10.9/0 10.1.32.1/0 Jun 22 16:40:58 bogushost2 ppp[333]: tun0: Command: verizondsl: set urgent udp +53 Jun 22 16:40:58 bogushost2 ppp[333]: tun0: Command: verizondsl: add default HISADDR Jun 22 16:40:58 bogushost2 ppp[333]: tun0: Command: verizondsl: dial Jun 22 16:40:58 bogushost2 ppp[333]: tun0: Phase: bundle: Establish Jun 22 16:40:58 bogushost2 ppp[333]: tun0: Phase: deflink: closed -> opening Jun 22 16:40:58 bogushost2 ppp[334]: tun0: Phase: PPP Started (auto mode). Jun 22 16:40:58 bogushost2 ppp[334]: tun0: Phase: deflink: Connected! Jun 22 16:40:58 bogushost2 ppp[334]: tun0: Phase: deflink: opening -> dial Jun 22 16:40:58 bogushost2 ppp[334]: tun0: Phase: deflink: dial -> carrier Jun 22 16:41:01 bogushost2 ppp[334]: tun0: Phase: Received NGM_PPPOE_ACNAME (hook "RES-6400-3-NRP2") Jun 22 16:41:02 bogushost2 ppp[334]: tun0: Phase: Received NGM_PPPOE_<11> (hook "M-^HM-^V^H^Hh ^K^H") Jun 22 16:41:03 bogushost2 ppp[334]: tun0: Phase: deflink: Disconnected! Jun 22 16:41:03 bogushost2 ppp[334]: tun0: Phase: deflink: carrier -> hangup Jun 22 16:41:03 bogushost2 ppp[334]: tun0: Phase: deflink: Connect time: 5 secs: 0 octets in, 0 octets out Jun 22 16:41:03 bogushost2 ppp[334]: tun0: Phase: deflink: : 0 packets in, 0 packets out Jun 22 16:41:03 bogushost2 ppp[334]: tun0: Phase: total 0 bytes/sec, peak 0 bytes/sec on Sat Jun 22 16:40:58 2002 Jun 22 16:41:03 bogushost2 ppp[334]: tun0: Phase: deflink: hangup -> closed Jun 22 16:41:03 bogushost2 ppp[334]: tun0: Phase: bundle: Dead Jun 22 16:41:50 bogushost2 ppp[334]: tun0: Phase: Connected to local client. Jun 22 16:41:50 bogushost2 ppp[334]: tun0: Command: /var/ppp/ppp: quit all Jun 22 16:41:50 bogushost2 ppp[334]: tun0: Phase: /var/ppp/ppp: Client connection dropped. Jun 22 16:41:50 bogushost2 ppp[334]: tun0: Phase: PPP Terminated (normal). TCPDUMP OUTPUT: 16:40:58.645213 PPPoE PADI [Host-Uniq UTF8] 16:41:00.643094 PPPoE PADI [Host-Uniq UTF8] 16:41:00.673124 PPPoE PADO [Host-Uniq UTF8] [Service-Name] [AC-Name "RES-6400-3-NRP2"] [AC-Cookie UTF8] 16:41:00.673173 PPPoE PADR [Host-Uniq UTF8] [AC-Cookie UTF8] [AC-Name "RES-6400-3-NRP2"] 16:41:00.739685 PPPoE PADS [ses 0x9688] [Host-Uniq UTF8] [AC-Cookie UTF8] [AC-Name "RES-6400-3-NRP2"] 16:41:00.758209 PPPoE [ses 0x9688] LCP 20: Conf-Req(69), MRU=1492, Auth-Prot PAP, Magic-Num=cca2f534 16:41:02.757866 PPPoE [ses 0x9688] LCP 20: Conf-Req(70), MRU=1492, Auth-Prot PAP, Magic-Num=cca2f534 16:41:03.695201 PPPoE PADT [ses 0x9688] [Generic-Error "session closed"] 16:41:04.777302 PPPoE [ses 0x9688] LCP 20: Conf-Req(71), MRU=1492, Auth-Prot PAP, Magic-Num=cca2f534 16:41:06.777516 PPPoE [ses 0x9688] LCP 20: Conf-Req(72), MRU=1492, Auth-Prot PAP, Magic-Num=cca2f534 16:41:08.781707 PPPoE [ses 0x9688] LCP 20: Conf-Req(73), MRU=1492, Auth-Prot PAP, Magic-Num=cca2f534 16:41:10.780905 PPPoE [ses 0x9688] LCP 20: Conf-Req(74), MRU=1492, Auth-Prot PAP, Magic-Num=cca2f534 16:41:12.789758 PPPoE [ses 0x9688] LCP 20: Conf-Req(75), MRU=1492, Auth-Prot PAP, Magic-Num=cca2f534 16:41:14.801761 PPPoE [ses 0x9688] LCP 20: Conf-Req(76), MRU=1492, Auth-Prot PAP, Magic-Num=cca2f534 16:41:16.786442 PPPoE [ses 0x9688] LCP 20: Conf-Req(77), MRU=1492, Auth-Prot PAP, Magic-Num=cca2f534 16:41:18.788879 PPPoE [ses 0x9688] LCP 20: Conf-Req(78), MRU=1492, Auth-Prot PAP, Magic-Num=cca2f534 16:41:20.791069 PPPoE [ses 0x9688] LCP 20: Conf-Req(79), MRU=1492, Auth-Prot PAP, Magic-Num=cca2f534 16:41:22.792005 PPPoE PADT [ses 0x9688] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jun 22 14:46:19 2002 Delivered-To: freebsd-net@freebsd.org Received: from Awfulhak.org (gw.Awfulhak.org [217.204.245.18]) by hub.freebsd.org (Postfix) with ESMTP id 6BCBA37B41A for ; Sat, 22 Jun 2002 14:46:07 -0700 (PDT) Received: from mail.lan.Awfulhak.org (brian@hak.Awfulhak.org [IPv6:2001:6f8:602:1::12]) by Awfulhak.org (8.12.4/8.12.4) with SMTP id g5MLk4xq000999; Sat, 22 Jun 2002 22:46:04 +0100 (BST) (envelope-from brian@Awfulhak.org) Date: Sat, 22 Jun 2002 22:46:01 +0100 From: Brian Somers To: "Andrew Lankford" Cc: freebsd-net@FreeBSD.ORG Subject: Re: More pppoe debugging info Message-Id: <20020622224601.61cc4ca1.brian@Awfulhak.org> In-Reply-To: <200206221525187.SM01584@141.com> References: <200206221525187.SM01584@141.com> X-Mailer: Sylpheed version 0.7.6claws (GTK+ 1.2.10; i386-portbld-freebsd5.0) 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 On Sat, 22 Jun 2002 17:24:23 -0400, Andrew Lankford wrote: > > Below is my final attempt at documenting my problems using the latest stable > ppp/netgraph combo with my DSL modem and 3Com 3c905C-TX ethernet card: > > Looks like the NGM_PPPOE_<11> (hook "M-^HM-^V^H^Hh ^K^H") string > no longer bears any resemblance to the session id bytes. > > Sorry for not making sure all the text is wrapped properly, but I > figure that would make it only harder to read. > > Andrew Lankford [.....] > PPP.LOG: [.....] > Jun 22 16:40:58 bogushost2 ppp[334]: tun0: Phase: deflink: dial -> carrier > Jun 22 16:41:01 bogushost2 ppp[334]: tun0: Phase: Received NGM_PPPOE_ACNAME (hook "RES-6400-3-NRP2") > Jun 22 16:41:02 bogushost2 ppp[334]: tun0: Phase: Received NGM_PPPOE_<11> (hook "M-^HM-^V^H^Hh ^K^H") These not-terminated strings have now been fixed. I don't believe they're the source of the problem though. [.....] > TCPDUMP OUTPUT: > > > 16:40:58.645213 PPPoE PADI [Host-Uniq UTF8] > 16:41:00.643094 PPPoE PADI [Host-Uniq UTF8] > 16:41:00.673124 PPPoE PADO [Host-Uniq UTF8] [Service-Name] [AC-Name "RES-6400-3-NRP2"] [AC-Cookie UTF8] > 16:41:00.673173 PPPoE PADR [Host-Uniq UTF8] [AC-Cookie UTF8] [AC-Name "RES-6400-3-NRP2"] > 16:41:00.739685 PPPoE PADS [ses 0x9688] [Host-Uniq UTF8] [AC-Cookie UTF8] [AC-Name "RES-6400-3-NRP2"] > 16:41:00.758209 PPPoE [ses 0x9688] LCP 20: Conf-Req(69), MRU=1492, Auth-Prot PAP, Magic-Num=cca2f534 > 16:41:02.757866 PPPoE [ses 0x9688] LCP 20: Conf-Req(70), MRU=1492, Auth-Prot PAP, Magic-Num=cca2f534 > 16:41:03.695201 PPPoE PADT [ses 0x9688] [Generic-Error "session closed"] [.....] Can you try the latest version (committed about an hour ago) and add a -e to the tcpdump command and repost your findings ? Cheers. -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jun 22 20:13:12 2002 Delivered-To: freebsd-net@freebsd.org Received: from 141.com (mail1.141.com [65.168.139.2]) by hub.freebsd.org (Postfix) with ESMTP id 569C337B400 for ; Sat, 22 Jun 2002 20:13:03 -0700 (PDT) Received: from 141.com [151.200.58.202] by 141.com with ESMTP (SMTPD32-7.10) id AD065A34002C; Sat, 22 Jun 2002 21:14:14 -0600 To: Brian Somers , freebsd-net@freebsd.org Subject: Re: More pppoe debugging info In-Reply-To: Your message of "Sun, 23 Jun 2002 00:17:25 BST." <20020623001725.214aa17f.brian@Awfulhak.org> Date: Sat, 22 Jun 2002 23:13:03 -0400 From: Andrew Lankford Message-Id: <200206222114390.SM01584@141.com> X-RBL-Warning: SPAMHEADERS: This E-mail has headers consistent with spam [4000020e]. X-Note: This E-mail was scanned for spam. 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 Another one.... This may not prove to be very helpful, because this wasn't a successful connection. After rebooting and (on a wild hunch) typing sh /etc/rc.firewall open My connection came up a minute or two later. I don't remember the ipfw rules interfering with my ppp connection before, but... ... perhaps it's a coincidence and something else is going on. The connection only comes up after lots of attempts long after I boot up when I boot up with rc.firewall in "open". Think I'll rebuild world and build a kernel with ipfw disabled. Andrew Lankford VERSION INFO: FreeBSD bogushost2 4.6-STABLE FreeBSD 4.6-STABLE #2: Sat Jun 22 20:47:48 EDT 2002 (same src tree as before,but a recompile) Same ppp compile as before. PPP.CONF: default: allow users arlankfo nat unregistered_only yes set log +lcp +debug +physical ipcp phase tun command ccp verizondsl: # deny pap # deny chap # accept chap81 set socket /var/ppp/ppp "" 0117 set device PPPoE:xl0 set authname ******* set authkey ******** set speed sync set mru 1492 set redial 2 set timeout 0 # enable lqr to see if this will deal with bad connections or disconnects? enable lqr set dial set login set ifaddr 10.10.10.9/0 10.1.32.1/0 set urgent udp +53 # DNS searches faster? # enable dns add default HISADDR # dial PPP.LOG: Jun 22 21:03:06 bogushost2 ppp[294]: Phase: Using interface: tun0 Jun 22 21:03:06 bogushost2 ppp[294]: Phase: deflink: Created in closed state Jun 22 21:03:06 bogushost2 ppp[294]: tun0: Debug: ReadSystem: Checking verizondsl (/etc/ppp/ppp.conf). Jun 22 21:03:06 bogushost2 ppp[294]: tun0: Command: verizondsl: set socket /var/ppp/ppp 0117 Jun 22 21:03:06 bogushost2 ppp[294]: tun0: Phase: Listening at local socket /var/ppp/ppp. Jun 22 21:03:06 bogushost2 ppp[294]: tun0: Command: verizondsl: set device PPPoE:xl0 Jun 22 21:03:06 bogushost2 ppp[294]: tun0: Command: verizondsl: set authname vze2ztys Jun 22 21:03:06 bogushost2 ppp[294]: tun0: Command: verizondsl: set authkey ******** Jun 22 21:03:06 bogushost2 ppp[294]: tun0: Command: verizondsl: set speed sync Jun 22 21:03:06 bogushost2 ppp[294]: tun0: Command: verizondsl: set mru 1492 Jun 22 21:03:06 bogushost2 ppp[294]: tun0: Command: verizondsl: set redial 2 Jun 22 21:03:06 bogushost2 ppp[294]: tun0: Command: verizondsl: set timeout 0 Jun 22 21:03:06 bogushost2 ppp[294]: tun0: Command: verizondsl: enable lqr Jun 22 21:03:06 bogushost2 ppp[294]: tun0: Command: verizondsl: set dial Jun 22 21:03:06 bogushost2 ppp[294]: tun0: Command: verizondsl: set login Jun 22 21:03:06 bogushost2 ppp[294]: tun0: Command: verizondsl: set ifaddr 10.10.10.9/0 10.1.32.1/0 Jun 22 21:03:06 bogushost2 ppp[294]: tun0: Debug: Add 10.10.10.9 -> 10.1.32.1 Jun 22 21:03:06 bogushost2 ppp[294]: tun0: Command: verizondsl: set urgent udp +53 Jun 22 21:03:06 bogushost2 ppp[294]: tun0: Command: verizondsl: add default HISADDR Jun 22 21:03:06 bogushost2 ppp[294]: tun0: Debug: wrote 140: cmd = Add, dst = 0, gateway = 120010a Jun 22 21:03:06 bogushost2 ppp[295]: tun0: Phase: PPP Started (auto mode). Jun 22 21:03:06 bogushost2 ppp[295]: tun0: Debug: Select changes time: no Jun 22 21:03:13 bogushost2 ppp[295]: tun0: Phase: Connected to local client. Jun 22 21:03:13 bogushost2 ppp[295]: tun0: Command: /var/ppp/ppp: dial Jun 22 21:03:13 bogushost2 ppp[295]: tun0: Phase: bundle: Establish Jun 22 21:03:13 bogushost2 ppp[295]: tun0: Phase: deflink: closed -> opening Jun 22 21:03:13 bogushost2 ppp[295]: tun0: Debug: List of netgraph node ``xl0:'' (id 2) hooks: Jun 22 21:03:13 bogushost2 ppp[295]: tun0: Debug: Found orphans -> ethernet Jun 22 21:03:13 bogushost2 ppp[295]: tun0: Debug: Connecting netgraph socket .:tun0 -> [4]::tun0 Jun 22 21:03:13 bogushost2 ppp[295]: tun0: Debug: Sending PPPOE_CONNECT to .:tun0 Jun 22 21:03:13 bogushost2 ppp[295]: tun0: Phase: deflink: Connected! Jun 22 21:03:13 bogushost2 ppp[295]: tun0: Phase: deflink: opening -> dial Jun 22 21:03:13 bogushost2 ppp[295]: tun0: Phase: deflink: dial -> carrier Jun 22 21:03:13 bogushost2 ppp[295]: tun0: Debug: Waiting for carrier Jun 22 21:03:13 bogushost2 ppp[295]: tun0: Phase: /var/ppp/ppp: Client connection closed. Jun 22 21:03:13 bogushost2 ppp[295]: tun0: Debug: Waiting for carrier Jun 22 21:03:15 bogushost2 last message repeated 2 times Jun 22 21:03:16 bogushost2 ppp[295]: tun0: Phase: Received NGM_PPPOE_ACNAME (hook "RES-6400-3-NRP2") Jun 22 21:03:16 bogushost2 ppp[295]: tun0: Debug: Waiting for carrier Jun 22 21:03:17 bogushost2 ppp[295]: tun0: Phase: deflink: Disconnected! Jun 22 21:03:17 bogushost2 ppp[295]: tun0: Phase: deflink: carrier -> hangup Jun 22 21:03:17 bogushost2 ppp[295]: tun0: Debug: deflink: Close Jun 22 21:03:17 bogushost2 ppp[295]: tun0: Phase: deflink: Connect time: 4 secs: 0 octets in, 0 octets out Jun 22 21:03:17 bogushost2 ppp[295]: tun0: Phase: deflink: : 0 packets in, 0 packets out Jun 22 21:03:17 bogushost2 ppp[295]: tun0: Phase: total 0 bytes/sec, peak 0 bytes/sec on Sat Jun 22 21:03:13 2002 Jun 22 21:03:17 bogushost2 ppp[295]: tun0: Phase: deflink: hangup -> closed Jun 22 21:03:17 bogushost2 ppp[295]: tun0: Phase: bundle: Dead TCPDUMP OUTPUT: 21:03:13.526350 0:1:2:73:ee:49 Broadcast 8863 32: PPPoE PADI [Host-Uniq UTF8] 21:03:15.523805 0:1:2:73:ee:49 Broadcast 8863 32: PPPoE PADI [Host-Uniq UTF8] 21:03:15.551092 0:4:c1:48:cb:13 0:1:2:73:ee:49 8863 71: PPPoE PADO [Host-Uniq UTF8] [Service-Name] [AC-Name "RES-6400-3-NRP2"] [AC-Cookie UTF8] 21:03:15.551140 0:1:2:73:ee:49 0:4:c1:48:cb:13 8863 71: PPPoE PADR [Host-Uniq UTF8] [AC-Cookie UTF8] [AC-Name "RES-6400-3-NRP2"] 21:03:15.610007 0:4:c1:48:cb:13 0:1:2:73:ee:49 8863 71: PPPoE PADS [ses 0x9bc0] [Host-Uniq UTF8] [AC-Cookie UTF8] [AC-Name "RES-6400-3-NRP2"] 21:03:15.632923 0:4:c1:48:cb:13 0:1:2:73:ee:49 8864 60: PPPoE [ses 0x9bc0] LCP 20: Conf-Req(74), MRU=1492, Auth-Prot PAP, Magic-Num=cd931399 21:03:17.565353 0:1:2:73:ee:49 0:4:c1:48:cb:13 8863 38: PPPoE PADT [ses 0x9bc0] [Generic-Error "session closed"] 21:03:17.643232 0:4:c1:48:cb:13 0:1:2:73:ee:49 8864 60: PPPoE [ses 0x9bc0] LCP 20: Conf-Req(75), MRU=1492, Auth-Prot PAP, Magic-Num=cd931399 21:03:19.644930 0:4:c1:48:cb:13 0:1:2:73:ee:49 8864 60: PPPoE [ses 0x9bc0] LCP 20: Conf-Req(76), MRU=1492, Auth-Prot PAP, Magic-Num=cd931399 21:03:21.645385 0:4:c1:48:cb:13 0:1:2:73:ee:49 8864 60: PPPoE [ses 0x9bc0] LCP 20: Conf-Req(77), MRU=1492, Auth-Prot PAP, Magic-Num=cd931399 21:03:23.646871 0:4:c1:48:cb:13 0:1:2:73:ee:49 8864 60: PPPoE [ses 0x9bc0] LCP 20: Conf-Req(78), MRU=1492, Auth-Prot PAP, Magic-Num=cd931399 21:03:25.649299 0:4:c1:48:cb:13 0:1:2:73:ee:49 8864 60: PPPoE [ses 0x9bc0] LCP 20: Conf-Req(79), MRU=1492, Auth-Prot PAP, Magic-Num=cd931399 21:03:27.662022 0:4:c1:48:cb:13 0:1:2:73:ee:49 8864 60: PPPoE [ses 0x9bc0] LCP 20: Conf-Req(80), MRU=1492, Auth-Prot PAP, Magic-Num=cd931399 21:03:29.660258 0:4:c1:48:cb:13 0:1:2:73:ee:49 8864 60: PPPoE [ses 0x9bc0] LCP 20: Conf-Req(81), MRU=1492, Auth-Prot PAP, Magic-Num=cd931399 21:03:31.662180 0:4:c1:48:cb:13 0:1:2:73:ee:49 8864 60: PPPoE [ses 0x9bc0] LCP 20: Conf-Req(82), MRU=1492, Auth-Prot PAP, Magic-Num=cd931399 21:03:33.664153 0:4:c1:48:cb:13 0:1:2:73:ee:49 8864 60: PPPoE [ses 0x9bc0] LCP 20: Conf-Req(83), MRU=1492, Auth-Prot PAP, Magic-Num=cd931399 21:03:35.665355 0:4:c1:48:cb:13 0:1:2:73:ee:49 8864 60: PPPoE [ses 0x9bc0] LCP 20: Conf-Req(84), MRU=1492, Auth-Prot PAP, Magic-Num=cd931399 21:03:37.666760 0:4:c1:48:cb:13 0:1:2:73:ee:49 8863 60: PPPoE PADT [ses 0x9bc0] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message