From owner-freebsd-net Sun Oct 6 3:10:25 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6B85637B401; Sun, 6 Oct 2002 03:10:21 -0700 (PDT) Received: from vbook.express.ru (vbook.nc.express.ru [212.24.37.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7182B43E65; Sun, 6 Oct 2002 03:10:20 -0700 (PDT) (envelope-from vova@express.ru) Received: from vova by vbook.express.ru with local (Exim 3.36 #1) id 17xVBM-0000Sz-00; Fri, 04 Oct 2002 20:20:04 +0400 Subject: Re: zebra interface flags problem on 4.7-RC2 (IFF_PROMISC) From: "Vladimir B. " Grebenschikov To: Vincent Jardin Cc: sumikawa@FreeBSD.org, freebsd-net@FreeBSD.org, sobomax@FreeBSD.org In-Reply-To: <20021004153903.B4FE41503A0@venus.vincentjardin.net> References: <1033739506.1060.16.camel@vbook.express.ru> <20021004153903.B4FE41503A0@venus.vincentjardin.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: Ximian Evolution 1.0.7 Date: 04 Oct 2002 20:20:04 +0400 Message-Id: <1033748404.1060.32.camel@vbook.express.ru> Mime-Version: 1.0 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 =D0=92 Fri, 04.10.2002, =D0=B2 19:39, Vincent Jardin =D0=BD=D0=B0=D0=BF=D0= =B8=D1=81=D0=B0=D0=BB: > It looks like your BSD kernel is not compiled with the IPv6 support. Yes, I know > Le Vendredi 4 Octobre 2002 15:51, "Vladimir B. " Grebenschikov a =C3=A9cr= it : > > Hi > > > > I have tried to install fresh zebra (from ports) on 4.7-RC2 > > > > have a problem - zebra turns on promiscuity mode on interface, > > it is completely unacceptable when interface connected to HUB (not > > switch) - router begins resend all packets. > > > > # ifconfig fxp1 > > fxp1: flags=3D8843 mtu 1500 > > inet 193.125.143.129 netmask 0xffffff00 broadcast > > 193.125.143.255 > > ether 00:a0:c9:41:a3:a3 > > media: Ethernet autoselect (10baseT/UTP) > > status: active >=20 > You do not have any link-local address on this interface. Please explain what you mean, interface have AF_LINK address. =20 > > # zebra -d > > 2002/10/04 16:33:42 ZEBRA: can't get ip6forwarding value >=20 > If you do not need any IPv6 support, you can compile zebra without the IP= v6=20 > support: > --disable-ipv6 Yes, I know, but it should not hurt interface promisc mode anyway. Actually zebra port lacks of -DWITHOUT_IPV6 make option --=20 Vladimir B. Grebenschikov vova@sw.ru, SWsoft, Inc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Oct 6 6:36:28 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7FDCD37B401 for ; Sun, 6 Oct 2002 06:36:26 -0700 (PDT) Received: from smtp.cwnt.com (smtp.cwnt.com [192.116.246.129]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7044D43E3B for ; Sun, 6 Oct 2002 06:36:11 -0700 (PDT) (envelope-from ido@cwnt.com) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Help with net.inet.ip.intr_queue_maxlen Date: Sun, 6 Oct 2002 16:35:57 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Help with net.inet.ip.intr_queue_maxlen Thread-Index: AcJszPAH6N3JMPkrTveC1FpT4NosUQAbpyfA From: "Ido Barnea" To: "Steve Francis" , 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 > -----Original Message----- > From: Steve Francis [mailto:steve@expertcity.com] > Sent: Sunday, October 06, 2002 3:13 AM > To: freebsd-net@freebsd.org > Subject: Help with net.inet.ip.intr_queue_maxlen >=20 >=20 > Can someone help me with net.inet.ip.intr_queue_maxlen tuning? >=20 > Firstly, its the "size of the IP input queue", per the source. >=20 > So does that mean after the NIC has received the packet, the interupt > from the NIC has been processed and the packet retrieved from the NIC, > then the packet is placed in this queue, before the IP stack=20 > looks at it? > i.e. its unrelated to interupt coalescing or polling, or NIC > performance, as they have already occurred in order to put the packet > into the queue. Yes? >=20 Absolutely correct > I am getting incrementing net.inet.ip.intr_queue_drops at around 8,000 > pps (increasing drops at rate of 10 or so per second.) > Yet, if my statement above about what the queue is, is=20 > correct, then it > just means that the system was busy doing stuff before it had a chance > to process the incoming packets, so there was no room for new ones to > enter the queue. But as the system was only 50% busy, then if=20 > I increase > the input queue, I should be able to avoid these drops, correct? At > least until the system gets a lot busier. >=20 Correct again > Is there a sane upper recommended limit to the queue length? >=20 Basically there shouldn't be a problem incrementing the queue length, = since the space is not allocated in advance. So, you should experiment with few values until the drop rate drops to a = reasonable value. The only problem I can think of is that you (or an attacker) can exhaust = your mbuf pool if you allow the queue length to become too large. You can check out the state of your mbuf poll using = 'netstat -m' > Or am I way off base here? > Thanks >=20 >=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 Sun Oct 6 9:50:22 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CE0C737B404 for ; Sun, 6 Oct 2002 09:50:21 -0700 (PDT) Received: from mail.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 491FC43E3B for ; Sun, 6 Oct 2002 09:50:21 -0700 (PDT) (envelope-from don@sandvine.com) Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19) id <42S94PS7>; Sun, 6 Oct 2002 12:50:20 -0400 Message-ID: From: Don Bowman To: "'freebsd-net@freebsd.org'" Subject: intel dual gigabit, 82546EB support Date: Sun, 6 Oct 2002 12:50:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Is anyone using the intel dual gigabit 82546EB? Does it appear as two separate em devices, eg em0 and em1? http://www.intel.com/network/connectivity/products/pro1000mt_dual_server_ada pter.htm is a card that has it, also some of the newer supermicro motherboards (and probably others) incorporate this device. The em driver does have support for it, but I can't see how it would make two interfaces from it? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Oct 6 10:10:53 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D93B537B401 for ; Sun, 6 Oct 2002 10:10:52 -0700 (PDT) Received: from artemis.drwilco.net (artemis.drwilco.net [209.162.234.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3117F43E77 for ; Sun, 6 Oct 2002 10:10:52 -0700 (PDT) (envelope-from drwilco@drwilco.net) Received: from ceres.drwilco.net (docwilco.xs4all.nl [213.84.68.230]) by artemis.drwilco.net (8.12.3/8.12.3) with ESMTP id g96HAbC1032353 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NO); Sun, 6 Oct 2002 13:10:45 -0400 (EDT) (envelope-from drwilco@drwilco.net) Message-Id: <5.1.1.6.2.20021006190925.0228cbc0@mail.drwilco.net> X-Sender: lists@mail.drwilco.net X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Sun, 06 Oct 2002 19:15:14 +0200 To: "Ido Barnea" , freebsd-net@freebsd.org From: "Rogier R. Mulhuijzen" Subject: RE: Help with net.inet.ip.intr_queue_maxlen In-Reply-To: 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 Is there a write-up anywhere about what variables are tuneable, where to look to see if they need tuning and what the downsides/ramifications are? I already discovered kern.ipc.maxsockbuf needs to be raised to accommodate raising the various send and recv spaces. =) Greets, DocWilco To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Oct 6 10:32:48 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E967C37B401 for ; Sun, 6 Oct 2002 10:32:47 -0700 (PDT) Received: from skynet.stack.nl (skynet.stack.nl [131.155.140.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3226A43E65 for ; Sun, 6 Oct 2002 10:32:47 -0700 (PDT) (envelope-from dean@dragon.stack.nl) Received: from dragon.stack.nl (dragon.stack.nl [2001:610:1108:5011:207:e9ff:fe09:230]) by skynet.stack.nl (Postfix) with ESMTP id 6EF784038; Sun, 6 Oct 2002 19:33:41 +0200 (CEST) Received: by dragon.stack.nl (Postfix, from userid 1600) id EE1AD9891; Sun, 6 Oct 2002 19:32:03 +0200 (CEST) Date: Sun, 6 Oct 2002 19:32:03 +0200 From: Dean Strik To: Don Bowman Cc: "'freebsd-net@freebsd.org'" Subject: Re: intel dual gigabit, 82546EB support Message-ID: <20021006173203.GA27842@dragon.stack.nl> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Editor: VIM Rulez! http://www.vim.org/ X-MUD: Outerspace - telnet://mud.stack.nl:3333 X-Really: Yes User-Agent: Mutt/1.5.1i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Don Bowman wrote: > Is anyone using the intel dual gigabit 82546EB? Does it appear as two > separate em devices, eg em0 and em1? Yup: em0: port 0x1000-0x103f em0: Speed:100 Mbps Duplex:Full em1: port 0x1040-0x107f em1: Speed:N/A Duplex:N/A -- Dean C. Strik Eindhoven University of Technology dean@stack.nl | dean@ipnet6.org | http://www.ipnet6.org/ "This isn't right. This isn't even wrong." -- Wolfgang Pauli To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Oct 6 11:59:15 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0382037B401; Sun, 6 Oct 2002 11:59:11 -0700 (PDT) Received: from vbook.express.ru (vbook.nc.express.ru [212.24.37.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id F2EBF43E65; Sun, 6 Oct 2002 11:59:08 -0700 (PDT) (envelope-from vova@express.ru) Received: from vova by vbook.express.ru with local (Exim 3.36 #1) id 17yGcN-0000HO-00; Sun, 06 Oct 2002 22:59:07 +0400 Subject: Re: zebra interface flags problem on 4.7-RC2 (IFF_PROMISC) From: "Vladimir B. " Grebenschikov To: Maxim Sobolev Cc: freebsd-net@freebsd.org In-Reply-To: <3D9DC7F3.7B966349@FreeBSD.org> References: <1033739506.1060.16.camel@vbook.express.ru> <20021004140644.GB61661@vega.vega.com> <1033741307.1060.22.camel@vbook.express.ru> <3D9DC7F3.7B966349@FreeBSD.org> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable X-Mailer: Ximian Evolution 1.0.7 Date: 06 Oct 2002 22:59:06 +0400 Message-Id: <1033930746.916.1.camel@vbook.express.ru> Mime-Version: 1.0 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 =F7 Fri, 04.10.2002, =D7 20:55, Maxim Sobolev =CE=C1=D0=C9=D3=C1=CC: > Closer look at zebra's code revealed that my initial guess was > entirely correct. The problem is that it doesn't bother to zero out > ifreq structure allocated on stack, which leads to this misbehaviour. >=20 > Attached patch should fix the problem - unfortunately due to code > freeze I can't commit it immediately. Yes, it works for me, thank you. May be you need approve commit of this patch with re@ ? I think it is not good idea to have not working zebra in release. > -Maxim >=20 > "Vladimir B. Grebenschikov" wrote: > >=20 > > =F7 Fri, 04.10.2002, =D7 18:06, Maxim Sobolev =CE=C1=D0=C9=D3=C1=CC: > > > On Fri, Oct 04, 2002 at 05:51:46PM +0400, Vladimir B. Grebenschikov = wrote: > > > > > > > > Hi > > > > > > > > I have tried to install fresh zebra (from ports) on 4.7-RC2 > > > > > > > > have a problem - zebra turns on promiscuity mode on interface, > > > > it is completely unacceptable when interface connected to HUB (not > > > > switch) - router begins resend all packets. > > > > > > > > # ifconfig fxp1 > > > > fxp1: flags=3D8843 mtu 1500 > > > > inet 193.125.143.129 netmask 0xffffff00 broadcast > > > > 193.125.143.255 > > > > ether 00:a0:c9:41:a3:a3 > > > > media: Ethernet autoselect (10baseT/UTP) > > > > status: active > > > > # zebra -d > > > > 2002/10/04 16:33:42 ZEBRA: can't get ip6forwarding value > > > > # ifconfig fxp1 > > > > fxp1: flags=3D8943 = mtu > > > > 1500 > > > > inet 193.125.143.129 netmask 0xffffff00 broadcast > > > > 193.125.143.255 > > > > ether 00:a0:c9:41:a3:a3 > > > > media: Ethernet autoselect (10baseT/UTP) > > > > status: active > > > > > > > > > > > > Nothing special in zebra config, just installed 4.7-RC2, just upgra= ded > > > > zebra. > > > > > > > > I am not sure is it Zebra-related or FreeBSD-related problem > > > > digging into zebra code do not show any abnormal interface flags > > > > installed. > > > > > > This is probably a bug in zebra - I guess that it's doesn't clear > > > 'struct ifreq' properly before SIOCSIFFLAGS ioctl(2). > >=20 > > Zebra explicitly sets flags like this: > > ioctl.c: ifreq.ifr_flags =3D ifp->flags; > > ioctl.c: ifreq.ifr_flags |=3D flags; > >=20 > > and I have tried to change code: > >=20 > > ioctl.c: ifreq.ifr_flags =3D ifp->flags; > > ioctl.c: ifreq.ifr_flags |=3D flags; > > ioctl.c: ifreq.ifr_flags &=3D ~(IFF_PROMISC); > >=20 > > - does not help. > >=20 > > > -Maxim > > > > > > > > > > > May be problem related to following commit: > > > > > > > > date: 2002/08/30 14:23:38; author: sobomax; state: Exp; lines: += 25 -4 > > > > MFC: user-setable promisc mode. The code is slightly diffrent (and > > > > uglier) > > > > than in HEAD, because we have had to preserve kernel ABI, so that > > > > increasing > > > > if_flags to 32 bits was not an option. > > > > > > > > > > > > -- > > > > Vladimir B. Grebenschikov > > > > vova@sw.ru, SWsoft, Inc. > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > > with "unsubscribe freebsd-net" in the body of the message > > > > > -- > > Vladimir B. Grebenschikov > > vova@sw.ru, SWsoft, Inc. > ---- >=20 > Index: Makefile > =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=3D=3D=3D=3D > RCS file: /home/ncvs/ports/net/zebra/Makefile,v > retrieving revision 1.64 > diff -d -u -r1.64 Makefile > --- Makefile 13 Sep 2002 07:57:25 -0000 1.64 > +++ Makefile 4 Oct 2002 16:50:07 -0000 > @@ -7,6 +7,7 @@ > =20 > PORTNAME=3D zebra > PORTVERSION=3D 0.93b > +PORTREVISION=3D 1 > CATEGORIES=3D net ipv6 > MASTER_SITES=3D ftp://ftp.zebra.org/pub/zebra/ \ > ftp://ftp.ripe.net/mirrors/sites/ftp.zebra.org/pub/zebra/ \ > Index: files/patch-ioctl.c > =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=3D=3D=3D=3D > RCS file: /home/ncvs/ports/net/zebra/files/patch-ioctl.c,v > retrieving revision 1.1 > diff -d -u -r1.1 patch-ioctl.c > --- files/patch-ioctl.c 12 Dec 2001 18:08:55 -0000 1.1 > +++ files/patch-ioctl.c 4 Oct 2002 16:50:07 -0000 > @@ -1,6 +1,25 @@ > ---- zebra/ioctl.c.orig Wed Dec 12 18:02:16 2001 > -+++ zebra/ioctl.c Wed Dec 12 18:02:30 2001 > -@@ -478,6 +478,9 @@ > + > +$FreeBSD$ > + > +--- zebra/ioctl.c.orig Tue Oct 23 11:31:29 2001 > ++++ zebra/ioctl.c Fri Oct 4 19:45:04 2002 > +@@ -349,6 +349,7 @@ > + int ret; > + struct ifreq ifreq; > +=20 > ++ bzero(&ifreq, sizeof(struct ifreq)); > + ifreq_set_name (&ifreq, ifp); > +=20 > + ifreq.ifr_flags =3D ifp->flags; > +@@ -371,6 +372,7 @@ > + int ret; > + struct ifreq ifreq; > +=20 > ++ bzero(&ifreq, sizeof(struct ifreq)); > + ifreq_set_name (&ifreq, ifp); > +=20 > + ifreq.ifr_flags =3D ifp->flags; > +@@ -473,6 +475,9 @@ > mask.sin6_len =3D sizeof (struct sockaddr_in6); > #endif > memcpy (&addreq.ifra_prefixmask, &mask, sizeof (struct sockaddr_in6))= ; > @@ -8,5 +27,5 @@ > + addreq.ifra_lifetime.ia6t_vltime =3D 0xffffffff; > + addreq.ifra_lifetime.ia6t_pltime =3D 0xffffffff; > =20 > - ret =3D if_ioctl_ipv6 (SIOCAIFADDR_IN6, (caddr_t) &addreq); > - if (ret < 0) > + addreq.ifra_lifetime.ia6t_pltime =3D ND6_INFINITE_LIFETIME;=20 > + addreq.ifra_lifetime.ia6t_vltime =3D ND6_INFINITE_LIFETIME;=20 --=20 Vladimir B. Grebenschikov vova@sw.ru, SWsoft, Inc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Oct 6 16:16:56 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A634B37B401 for ; Sun, 6 Oct 2002 16:16:54 -0700 (PDT) Received: from carp.icir.org (carp.icir.org [192.150.187.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3B7BC43E42 for ; Sun, 6 Oct 2002 16:16:54 -0700 (PDT) (envelope-from rizzo@carp.icir.org) Received: from carp.icir.org (localhost [127.0.0.1]) by carp.icir.org (8.12.3/8.12.3) with ESMTP id g96NGqO2015528; Sun, 6 Oct 2002 16:16:52 -0700 (PDT) (envelope-from rizzo@carp.icir.org) Received: (from rizzo@localhost) by carp.icir.org (8.12.3/8.12.3/Submit) id g96NGq2T015527; Sun, 6 Oct 2002 16:16:52 -0700 (PDT) (envelope-from rizzo) Date: Sun, 6 Oct 2002 16:16:52 -0700 From: Luigi Rizzo To: Steve Francis Cc: freebsd-net@FreeBSD.ORG Subject: Re: Help with net.inet.ip.intr_queue_maxlen Message-ID: <20021006161652.A15352@carp.icir.org> References: <3D9F8002.70500@expertcity.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: <3D9F8002.70500@expertcity.com>; from steve@expertcity.com on Sat, Oct 05, 2002 at 05:12:50PM -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 Sat, Oct 05, 2002 at 05:12:50PM -0700, Steve Francis wrote: ... > So does that mean after the NIC has received the packet, the interupt > from the NIC has been processed and the packet retrieved from the NIC, > then the packet is placed in this queue, before the IP stack looks at it? yes, unless the packet is being forwarded and you are using fastforwarding. > i.e. its unrelated to interupt coalescing or polling, or NIC > performance, as they have already occurred in order to put the packet > into the queue. Yes? the only exception is polling, where after placing in the queue at most kern.polling.poll_burst packets per interface, the kernel will call the ip stack to give it a chance to drain the ip input queue. If the drops you are seeing are the result of some periodic bursts generated by clients, then it might make sense to raise the queue size to some higher value (100-200) to absorb the bursts -- consider that NICs have receive queues which can be as large as 256 entries. Also keep in mind that several drivers (some NICs, lpt, maybe others) are not very well behaved, and periodically tend to run at splimp() for long periods of time (up to 10's of milliseconds) thus causing large queues to build up in other drivers. E.g. the "xl" driver was recently reported to take a long time every second to read some info (statistics ?) from the NIC; at 8kpps, 10ms is roughly 80 packets, which would easily explain the drops you are seeing. Other effects of such delays could be drops in the NIC (often reported as input errors in netstat), delayed operation of the polling code (which used to report this as "poll stalled"), and delayed processing of timeouts. cheers luigi ----------------------------------+----------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone: (510) 666 2988 ----------------------------------+----------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Oct 6 17: 0:42 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 99FE537B404 for ; Sun, 6 Oct 2002 17:00:41 -0700 (PDT) Received: from out0.mx.nwbl.wi.voyager.net (out0.mx.nwbl.wi.voyager.net [169.207.3.118]) by mx1.FreeBSD.org (Postfix) with ESMTP id CF35D43E75 for ; Sun, 6 Oct 2002 17:00:40 -0700 (PDT) (envelope-from silby@silby.com) Received: from pop4.nwbl.wi.voyager.net (pop4.nwbl.wi.voyager.net [169.207.2.83]) by out0.mx.nwbl.wi.voyager.net (Postfix) with ESMTP id 0E4DF83690; Sun, 6 Oct 2002 19:00:40 -0500 (CDT) Received: from [10.1.1.6] (d45.as8.nwbl0.wi.voyager.net [169.207.132.45]) by pop4.nwbl.wi.voyager.net (8.10.2/8.10.2) with ESMTP id g9700do56831; Sun, 6 Oct 2002 19:00:39 -0500 (CDT) Date: Sun, 6 Oct 2002 19:05:04 -0500 (CDT) From: Mike Silbersack To: Luigi Rizzo Cc: Steve Francis , Subject: Re: Help with net.inet.ip.intr_queue_maxlen In-Reply-To: <20021006161652.A15352@carp.icir.org> Message-ID: <20021006190135.J14377-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 Sun, 6 Oct 2002, Luigi Rizzo wrote: > large queues to build up in other drivers. E.g. the "xl" > driver was recently reported to take a long time every second to > read some info (statistics ?) from the NIC; at 8kpps, 10ms > is roughly 80 packets, which would easily explain the drops you > are seeing. The assertion that statistics retrieval was taking up lots of time turned out to be completely false. In the past, the statistics update also triggered a MII poll, which is why the statistics interrupt seemed to be the culprit. But yes, the MII poll was taking 10ms every second until I recently committed Harti Brandt's changes to -current. Now it "only" takes 1ms, which is still too long, but hard to reduce further. The MFC will have to wait until after 4.7-release is tagged, unfortunately. 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 Sun Oct 6 17: 2: 8 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CDBB037B401 for ; Sun, 6 Oct 2002 17:02:06 -0700 (PDT) Received: from dibbler.ne.client2.attbi.com (dibbler.ne.client2.attbi.com [24.61.41.247]) by mx1.FreeBSD.org (Postfix) with ESMTP id 360FA43E75 for ; Sun, 6 Oct 2002 17:02:06 -0700 (PDT) (envelope-from rodrigc@attbi.com) Received: from dibbler.ne.client2.attbi.com (localhost.ne.attbi.com [127.0.0.1]) by dibbler.ne.client2.attbi.com (8.12.6/8.12.5) with ESMTP id g9702kPe004860 for ; Sun, 6 Oct 2002 20:02:46 -0400 (EDT) (envelope-from rodrigc@dibbler.ne.client2.attbi.com) Received: (from rodrigc@localhost) by dibbler.ne.client2.attbi.com (8.12.6/8.12.6/Submit) id g9702j2p004859 for freebsd-net@freebsd.org; Sun, 6 Oct 2002 20:02:45 -0400 (EDT) Date: Sun, 6 Oct 2002 20:02:45 -0400 From: Craig Rodrigues To: freebsd-net@freebsd.org Subject: Netgraph and fxp0 interface? Message-ID: <20021006200245.A4829@attbi.com> 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 learn about Netgraph. I have set up a -CURRENT system for testing. I am reading the tutorial at: http://www.daemonnews.org/200003/netgraph.html According to this tutorial: "if your kernel was compiled with options NETGRAPH and you have an Ethernet interface fxp0, this command will redirect all packets received by the Ethernet card and dump them to standard output in hex/ASCII format: nghook -a fxp0: divert " On my system, I do have an fxp0 network card: fxp0: port 0x7c60-0x7c7f mem 0xf3d00000-0xf3dfffff,0xf3cff000-0xf3cfffff irq 11 at device 3.0 on pci0 I also have the following specified in my kernel config file: device fxp # Intel EtherExpress PRO/100B (82557, 82558) options NETGRAPH # netgraph networking However, if I execute nghook -a fxp0: divert (as the root user), I get: nghook: can't connect to node If I do: ngctl list, I get: There are 2 total nodes: Name: ngctl3796 Type: socket ID: 0000001d Num hooks: 0 Name: fatm0 Type: atm ID: 0000000a Num hooks: 0 The fatm0 is from Harti Brandt's Netgraph ATM system which I am trying out. ( http://www.fokus.fhg.de/research/cc/cats/employees/hartmut.brandt/ngatm/ ) Can someone tell me why doing an nghook on fxp0: is not working? Thanks. -- Craig Rodrigues http://www.gis.net/~craigr rodrigc@attbi.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Oct 6 19: 0:28 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 96E9137B401 for ; Sun, 6 Oct 2002 19:00:26 -0700 (PDT) Received: from sccrmhc01.attbi.com (sccrmhc01.attbi.com [204.127.202.61]) by mx1.FreeBSD.org (Postfix) with ESMTP id 13ECA43E81 for ; Sun, 6 Oct 2002 19:00:26 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by sccrmhc01.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20021007020025.QETB6431.sccrmhc01.attbi.com@InterJet.elischer.org>; Mon, 7 Oct 2002 02:00:25 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id SAA30890; Sun, 6 Oct 2002 18:45:59 -0700 (PDT) Date: Sun, 6 Oct 2002 18:45:59 -0700 (PDT) From: Julian Elischer To: Craig Rodrigues Cc: freebsd-net@freebsd.org Subject: Re: Netgraph and fxp0 interface? In-Reply-To: <20021006200245.A4829@attbi.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 you also need the ng_eter option.. you can probably get it by: kldload ng_ether On Sun, 6 Oct 2002, Craig Rodrigues wrote: > Hi, > > I am trying to learn about Netgraph. I have set up > a -CURRENT system for testing. I am reading the tutorial at: > http://www.daemonnews.org/200003/netgraph.html > > According to this tutorial: > > "if your kernel was compiled with options NETGRAPH and you have an Ethernet > interface fxp0, this command will redirect all packets received by the > Ethernet card and dump them to standard output in hex/ASCII format: > > nghook -a fxp0: divert > " > > > On my system, I do have an fxp0 network card: > fxp0: port 0x7c60-0x7c7f mem 0xf3d00000-0xf3dfffff,0xf3cff000-0xf3cfffff irq 11 at device 3.0 on pci0 > > I also have the following specified in my kernel config file: > > device fxp # Intel EtherExpress PRO/100B (82557, 82558) > options NETGRAPH # netgraph networking > > > > However, if I execute nghook -a fxp0: divert (as the root user), I get: > > nghook: can't connect to node > > > If I do: ngctl list, I get: > > There are 2 total nodes: > Name: ngctl3796 Type: socket ID: 0000001d Num hooks: 0 > Name: fatm0 Type: atm ID: 0000000a Num hooks: 0 > > The fatm0 is from Harti Brandt's Netgraph ATM system which I am trying out. > ( http://www.fokus.fhg.de/research/cc/cats/employees/hartmut.brandt/ngatm/ ) > > Can someone tell me why doing an nghook on fxp0: is not working? > > Thanks. > > -- > Craig Rodrigues > http://www.gis.net/~craigr > rodrigc@attbi.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 Sun Oct 6 19:13: 2 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ABE9F37B401 for ; Sun, 6 Oct 2002 19:13:01 -0700 (PDT) Received: from dibbler.ne.client2.attbi.com (dibbler.ne.client2.attbi.com [24.61.41.247]) by mx1.FreeBSD.org (Postfix) with ESMTP id E3BBB43E86 for ; Sun, 6 Oct 2002 19:13:00 -0700 (PDT) (envelope-from rodrigc@attbi.com) Received: from dibbler.ne.client2.attbi.com (localhost.ne.attbi.com [127.0.0.1]) by dibbler.ne.client2.attbi.com (8.12.6/8.12.5) with ESMTP id g972DePe007602 for ; Sun, 6 Oct 2002 22:13:40 -0400 (EDT) (envelope-from rodrigc@dibbler.ne.client2.attbi.com) Received: (from rodrigc@localhost) by dibbler.ne.client2.attbi.com (8.12.6/8.12.6/Submit) id g972De38007601 for freebsd-net@freebsd.org; Sun, 6 Oct 2002 22:13:40 -0400 (EDT) Date: Sun, 6 Oct 2002 22:13:40 -0400 From: Craig Rodrigues To: freebsd-net@freebsd.org Subject: Re: Netgraph and fxp0 interface? Message-ID: <20021006221340.A7583@attbi.com> References: <20021006200245.A4829@attbi.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: ; from julian@elischer.org on Sun, Oct 06, 2002 at 06:45:59PM -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 Sun, Oct 06, 2002 at 06:45:59PM -0700, Julian Elischer wrote: > you also need the ng_eter option.. > you can probably get it by: > kldload ng_ether Ah, OK, if I did kldload ng_ether and then did nghook -a fxp0: divert it then worked. This wasn't clear from the daemonnews.org tutorial. Thanks. -- Craig Rodrigues http://www.gis.net/~craigr rodrigc@attbi.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Oct 6 21:35:44 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0CF0937B401 for ; Sun, 6 Oct 2002 21:35:44 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 163E743E42 for ; Sun, 6 Oct 2002 21:35:43 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id OAA22460; Mon, 7 Oct 2002 14:35:24 +1000 Date: Mon, 7 Oct 2002 14:45:18 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Mike Silbersack Cc: Luigi Rizzo , Steve Francis , Subject: Re: Help with net.inet.ip.intr_queue_maxlen In-Reply-To: <20021006190135.J14377-100000@patrocles.silby.com> Message-ID: <20021007144349.P27837-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sun, 6 Oct 2002, Mike Silbersack wrote: > But yes, the MII poll was taking 10ms every second until I recently > committed Harti Brandt's changes to -current. Now it "only" takes 1ms, > which is still too long, but hard to reduce further. The MFC will have to > wait until after 4.7-release is tagged, unfortunately. Preferably longer. ISTR a PR about it. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Oct 6 21:38:32 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 47F8E37B401; Sun, 6 Oct 2002 21:38:31 -0700 (PDT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id D6EF243E7B; Sun, 6 Oct 2002 21:38:30 -0700 (PDT) (envelope-from sam@errno.com) Received: from melange (melange.errno.com [66.127.85.82]) (authenticated bits=0) by ebb.errno.com (8.12.5/8.12.1) with ESMTP id g974cR1H000716 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sun, 6 Oct 2002 21:38:30 -0700 (PDT)?g (envelope-from sam@errno.com)œ X-Authentication-Warning: ebb.errno.com: Host melange.errno.com [66.127.85.82] claimed to be melange Message-ID: <13e901c26dbb$63059f60$52557f42@errno.com> From: "Sam Leffler" To: , Subject: CFR: m_tag patch Date: Sun, 6 Oct 2002 21:38:26 -0700 Organization: Errno Consulting MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" 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 http://www.freebsd.org/~sam/mtag.patch has changes to -current to replace the "aux mbuf" with a more general mechanism borrowed from openbsd. Rather than dangling mbuf's off a packet when auxiliary information needs to be associated with a packet a list of variable-size struct m_tag's are kept. This is better because it: 1. Eliminates the use of mbufs as a general-purpose memory allocator. 2. Avoids confusing and problematic code (e.g. ipsec stuffs multiple data structures into an mbuf and often consults m_len to determine what might/should be present). 3. Means arbitrary size data can be stored (w/ mbufs you get what fits in a fixed-size mbuf or--if it were implemented--in a cluster). 4. Removes a recursive dependency that complicates locking in the mbuf code. The patch actually contains three sets of changes that are intertwined: 1. Remove use of aux mbufs and replace with m_tag's. 2. Add an additional parameter to ip_output and ip6_output that was previously passed through an aux mbuf. 3. Rename luigi's m_tag_id hack #define to avoid name conflict with the m_tag definition. I've been running something like this patch for ~9 months. The patch actually eliminates more code than it adds and is likely to improve performance (haven't measured). There should be no functional changes after this patch is applied. Timely feedback is desired as I'd like to commit these changes in time for DP2. Sam To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Oct 6 22: 2: 3 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 69A9837B49A for ; Sun, 6 Oct 2002 22:01:59 -0700 (PDT) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id C28FC43E81 for ; Sun, 6 Oct 2002 22:01:58 -0700 (PDT) (envelope-from nate@rootlabs.com) Received: (qmail 5907 invoked by uid 1000); 7 Oct 2002 05:02:01 -0000 Date: Sun, 6 Oct 2002 22:02:01 -0700 (PDT) From: Nate Lawson To: freebsd-arch@freebsd.org Cc: freebsd-net@freebsd.org Subject: Re: CFR: m_tag patch In-Reply-To: <13e901c26dbb$63059f60$52557f42@errno.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 Sun, 6 Oct 2002, Sam Leffler wrote: > http://www.freebsd.org/~sam/mtag.patch > > has changes to -current to replace the "aux mbuf" with a more general > mechanism borrowed from openbsd. Rather than dangling mbuf's off a packet > when auxiliary information needs to be associated with a packet a list of > variable-size struct m_tag's are kept. This is better because it: > > 1. Eliminates the use of mbufs as a general-purpose memory allocator. > 2. Avoids confusing and problematic code (e.g. ipsec stuffs multiple data > structures into an mbuf and often consults m_len to determine what > might/should be present). > 3. Means arbitrary size data can be stored (w/ mbufs you get what fits in a > fixed-size mbuf or--if it were implemented--in a cluster). > 4. Removes a recursive dependency that complicates locking in the mbuf code. > > The patch actually contains three sets of changes that are intertwined: > > 1. Remove use of aux mbufs and replace with m_tag's. > 2. Add an additional parameter to ip_output and ip6_output that was > previously passed through an aux mbuf. > 3. Rename luigi's m_tag_id hack #define to avoid name conflict with the > m_tag definition. > > I've been running something like this patch for ~9 months. The patch > actually eliminates more code than it adds and is likely to improve > performance (haven't measured). There should be no functional changes after > this patch is applied. > > Timely feedback is desired as I'd like to commit these changes in time for > DP2. > > Sam I'm not familiar with that code so only a few questions: 1. Is ordering important or is an SLIST sufficient for all cases? 2. Is it possible to attach the aux argument to the mbuf chain instead of adding it as a new parameter to ip_output? -Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Oct 6 22:21:45 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EE78637B401; Sun, 6 Oct 2002 22:21:43 -0700 (PDT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8EA1843E97; Sun, 6 Oct 2002 22:21:43 -0700 (PDT) (envelope-from sam@errno.com) Received: from melange (melange.errno.com [66.127.85.82]) (authenticated bits=0) by ebb.errno.com (8.12.5/8.12.1) with ESMTP id g975Lg1H000879 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sun, 6 Oct 2002 22:21:43 -0700 (PDT)?g (envelope-from sam@errno.com)œ X-Authentication-Warning: ebb.errno.com: Host melange.errno.com [66.127.85.82] claimed to be melange Message-ID: <142f01c26dc1$6c4fa5b0$52557f42@errno.com> From: "Sam Leffler" To: "Nate Lawson" , Cc: References: Subject: Re: CFR: m_tag patch Date: Sun, 6 Oct 2002 22:21:35 -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 > 1. Is ordering important or is an SLIST sufficient for all cases? Order is not important. > 2. Is it possible to attach the aux argument to the mbuf chain instead of > adding it as a new parameter to ip_output? > The "aux argument" _was_ originally attached to the mbuf chain. The change to add an extra arg to ip*_output was done to eliminate one of the biggest uses of the aux mbuf; the socket to use to get IPsec policy. This is a performance win and worth doing independent of the aux->m_tag switch. One could split the ip_output change out but doing it together avoids converting code that would just eventually be eliminated (unless you did the ip_output change first and then the m_tag switch). Sam To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Oct 6 23:11:19 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6EEC437B401; Sun, 6 Oct 2002 23:11:17 -0700 (PDT) Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D32843E9C; Sun, 6 Oct 2002 23:11:17 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0081.cvx40-bradley.dialup.earthlink.net ([216.244.42.81] helo=mindspring.com) by hawk.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17yR6f-00041e-00; Sun, 06 Oct 2002 23:11:06 -0700 Message-ID: <3DA12517.6D1B4EC2@mindspring.com> Date: Sun, 06 Oct 2002 23:09:27 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Sam Leffler Cc: Nate Lawson , freebsd-arch@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: CFR: m_tag patch References: <142f01c26dc1$6c4fa5b0$52557f42@errno.com> 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 Sam Leffler wrote: > > 1. Is ordering important or is an SLIST sufficient for all cases? > > Order is not important. Hm. I don't know if this is actually correct. I think if it went LIFO, you might not be very happy. I think it depends on what it's used for. > > 2. Is it possible to attach the aux argument to the mbuf chain instead of > > adding it as a new parameter to ip_output? > > The "aux argument" _was_ originally attached to the mbuf chain. The change > to add an extra arg to ip*_output was done to eliminate one of the biggest > uses of the aux mbuf; the socket to use to get IPsec policy. This is a > performance win and worth doing independent of the aux->m_tag switch. > > One could split the ip_output change out but doing it together avoids > converting code that would just eventually be eliminated (unless you did the > ip_output change first and then the m_tag switch). The IPSEC for IPv4 stuff is very ugly. It's tempting to say that it has nothing to do with the IP encapsulation, proper (conceptually, it should not). The big problem is that the IPSEC allocations are are there if IPSEC is compiled into the kernel at all, even if IPSEC is not being used on a particular socket. Actually, the integration into IPv4 strikes me as little more than an afterthought: the KAME code handles it in IPv6 without the extra overhead for the non-IPSEC sockets, and the IPv4 support is more of a bolt-on than something designed in. I'd almost want to see the IPSEC stuff treated as a separate encapsulation layer, on its own. Adding a aparameter for it specifically adds more cruft on the cruft that's already there, and makes the IPSEC *not* an encapsulation, in any way. 8-(. Is there another way to do this? A general extension mechanism for attributin mbufs seems to be a good idea. People have wanted this before, for credentials (e.g. Robert suggested something like this before). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Oct 6 23:40:15 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1BC0937B404; Sun, 6 Oct 2002 23:40:14 -0700 (PDT) Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 71F3343E9E; Sun, 6 Oct 2002 23:40:13 -0700 (PDT) (envelope-from julian@elischer.org) 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 <20021007064012.ULJA27763.sccrmhc02.attbi.com@InterJet.elischer.org>; Mon, 7 Oct 2002 06:40:12 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id XAA32049; Sun, 6 Oct 2002 23:32:35 -0700 (PDT) Date: Sun, 6 Oct 2002 23:32:34 -0700 (PDT) From: Julian Elischer To: Sam Leffler Cc: freebsd-arch@freebsd.org, freebsd-net@freebsd.org Subject: Re: CFR: m_tag patch In-Reply-To: <13e901c26dbb$63059f60$52557f42@errno.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 This is not a techincal comment but more a project question.. What is the relationship between these changes and the KAME code? In particular, are they goign to take these changes back into Kame? Can you outline the compatibility issues, both with KAME, and with NetBSD and OpenBSD, as I know you have been looking at OpenBSD? (Am looking at the patches now will respond technically searatly.) On Sun, 6 Oct 2002, Sam Leffler wrote: > http://www.freebsd.org/~sam/mtag.patch > > has changes to -current to replace the "aux mbuf" with a more general > mechanism borrowed from openbsd. Rather than dangling mbuf's off a packet > when auxiliary information needs to be associated with a packet a list of > variable-size struct m_tag's are kept. This is better because it: > > 1. Eliminates the use of mbufs as a general-purpose memory allocator. > 2. Avoids confusing and problematic code (e.g. ipsec stuffs multiple data > structures into an mbuf and often consults m_len to determine what > might/should be present). > 3. Means arbitrary size data can be stored (w/ mbufs you get what fits in a > fixed-size mbuf or--if it were implemented--in a cluster). > 4. Removes a recursive dependency that complicates locking in the mbuf code. > > The patch actually contains three sets of changes that are intertwined: > > 1. Remove use of aux mbufs and replace with m_tag's. > 2. Add an additional parameter to ip_output and ip6_output that was > previously passed through an aux mbuf. > 3. Rename luigi's m_tag_id hack #define to avoid name conflict with the > m_tag definition. > > I've been running something like this patch for ~9 months. The patch > actually eliminates more code than it adds and is likely to improve > performance (haven't measured). There should be no functional changes after > this patch is applied. > > Timely feedback is desired as I'd like to commit these changes in time for > DP2. > > Sam > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" 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 Mon Oct 7 0:40:13 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DB9A137B401; Mon, 7 Oct 2002 00:40:09 -0700 (PDT) Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 72FD043EAA; Mon, 7 Oct 2002 00:40:09 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20021007074008.OLCB18767.rwcrmhc53.attbi.com@InterJet.elischer.org>; Mon, 7 Oct 2002 07:40: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 AAA32405; Mon, 7 Oct 2002 00:29:36 -0700 (PDT) Date: Mon, 7 Oct 2002 00:29:35 -0700 (PDT) From: Julian Elischer To: Sam Leffler Cc: Nate Lawson , freebsd-arch@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: CFR: m_tag patch In-Reply-To: <142f01c26dc1$6c4fa5b0$52557f42@errno.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 Sun, 6 Oct 2002, Sam Leffler wrote: > > 1. Is ordering important or is an SLIST sufficient for all cases? > > Order is not important. I do similar in Netgraph but could move to whatever scheme becomes standard in the rest of the system. However I have some serious comments. In netgraph I have a separate structure for the packet that contains a pointer to the mbuf chain as well a pointer to a malloc'd memory buffer that can contain metadata such as is kept here. the metadata is of the form [header][field][field][field].... where each field was defined as: struct meta_field_header { u_long cookie; /* cookie for the field. Skip fields you don't * know about (same cookie as in messgaes) */ u_short type; /* field ID within this cookie scheme */ u_short len; /* total len of this field including extra * data */ char data[0]; /* data starts here */ }; the header for metadata is: struct ng_meta { char priority; /* -ve is less priority, 0 is default */ char discardability; /* higher is less valuable.. discard first */ u_short allocated_len; /* amount malloc'd */ u_short used_len; /* sum of all fields, options etc. */ u_short flags; /* see below.. generic flags */ struct meta_field_header options[0]; /* add as (if) needed */ }; /* Flags for meta-data */ #define NGMF_TEST 0x01 /* discard at the last moment before sending */ #define NGMF_TRACE 0x02 /* trace when handing this data to a node */ One metadata collection is associated with each packet. similar to what you do except that in 4.x Ipass it as an arguent and in 5.0 I have a packet header that is passed around that identifies both data and metadata. ( I need the header for other reasons anyway) I show this only to show that I have tackled the same problem with a similar but different scheme. My thought was that a packet usually only has at most a couple of tags, and the tags are usually short, so that it was ok to malloc a bigger chunk and using the length fields walk them. If you didn't have room you could malloc a bigger one and copy the intitial fields, and then add your new ones at the end. It would probably almost never happen.. I did however find a need to delete a tag once the packet passed out of the scope of the module in question. (the "cookie" represents a particular "ABI" the "type" is only valid withing the ABI. If you do not support a particular cookie type you cannot interpret the contents aof that field) Protocols and such have their own cookies. I point this out as a feature because the TAG values need to only be defined within their own ABI/API include files. If a module that supports a particular cookie passes a packet out to the rest of the world, it probably should invalidate some fields that are set with that particular cookie, in case that packet should in some way be redirected back towards a module that does support it, and that might cause unexpected results. For this reason I needed to 'remove' fields. I ended leaving them in place and setting the cookie to a special "invalid" cookie value that no-one would match. In a similar vein, I can imagine wanting to remove one of the 'tags' in your lists. Each module has a cookie field that is pretty much guaranteed to be unique (time since epoch when written) so in your terms, the IP code would only know and recognise TAGS prepended with the IP cookie and would handle other tags as opaque data. Similarly IPSEC code would only see into tags with the IPSEC cookie prepended.. I don't think you should be defining the TAG values in a global file, but rather each module should identify its own tags and ignode others. If two modules need to share data, a .h file can contain the defineitions for that API and the cookie that identifies such tags, and both modules would include that shared include. That way the base code need not know about future improvements, which has always been "difficult" :-) > > > 2. Is it possible to attach the aux argument to the mbuf chain instead of > > adding it as a new parameter to ip_output? > > > > The "aux argument" _was_ originally attached to the mbuf chain. The change > to add an extra arg to ip*_output was done to eliminate one of the biggest > uses of the aux mbuf; the socket to use to get IPsec policy. This is a > performance win and worth doing independent of the aux->m_tag switch. > > One could split the ip_output change out but doing it together avoids > converting code that would just eventually be eliminated (unless you did the > ip_output change first and then the m_tag switch). I'm not sure but it's possible m_aux was invented so that ip_output() would not change interfaces to match with was defined in some interface method table. I think NetBSD added entries in their interface method tables with varargs (yech) to get around some of this.. So in summary: is it worth making it a linked list? how many tags do you see on packets, and how large are they? CAn you use a sche,e suc as that outlined so that each module can define its own tags privatly? > > Sam > > > 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 Mon Oct 7 1:35: 0 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EC21737B401 for ; Mon, 7 Oct 2002 01:34:59 -0700 (PDT) Received: from insomnia.spc.org (insomnia.spc.org [195.224.94.183]) by mx1.FreeBSD.org (Postfix) with SMTP id ED2EA43E7B for ; Mon, 7 Oct 2002 01:34:58 -0700 (PDT) (envelope-from bms@insomnia.spc.org) Received: (qmail 31642 invoked by uid 1031); 7 Oct 2002 08:30:08 -0000 Date: Mon, 7 Oct 2002 09:30:07 +0100 From: Bruce M Simpson To: freebsd@coal.sentex.ca Cc: freebsd-net@freebsd.org Subject: Re: Linux <-> FreeBSD ipip/gre tunnel Message-ID: <20021007083007.GG27978@spc.org> Mail-Followup-To: Bruce M Simpson , freebsd@coal.sentex.ca, freebsd-net@freebsd.org References: <16552555060.20021004100947@sentex.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16552555060.20021004100947@sentex.net> User-Agent: Mutt/1.3.28i 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 Fri, Oct 04, 2002 at 10:09:47AM -0400, freebsd@coal.sentex.ca wrote: > I haven't been able to turn up anything under Google... > > Has anyone ever successfully gotten an IP-IP or GRE tunnel working > between a FreeBSD machine (4-STABLE) and a Linux machine (2.4.x)? I > can get a tunnel up between two FreeeBSD machines no problem, but not > between the two OSes. I wrote a GRE driver for 4.5 about a year ago. I can happily tar it up and post it here (probably should, in fact - I've heard that NetBSD's GRE driver got imported into -STABLE). We had this code working with NetBSD and Cisco IOS peers. BMS To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 7 1:55:54 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 92A0937B401 for ; Mon, 7 Oct 2002 01:55:53 -0700 (PDT) Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5EC2B43E91 for ; Mon, 7 Oct 2002 01:55:52 -0700 (PDT) (envelope-from brandt@fokus.gmd.de) Received: from beagle (beagle [193.175.132.100]) by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id g978tfe09828; Mon, 7 Oct 2002 10:55:41 +0200 (MEST) Date: Mon, 7 Oct 2002 10:55:41 +0200 (CEST) From: Harti Brandt To: Craig Rodrigues Cc: freebsd-net@FreeBSD.ORG Subject: Re: Netgraph and fxp0 interface? In-Reply-To: <20021006200245.A4829@attbi.com> Message-ID: <20021007105510.C73304-100000@beagle.fokus.gmd.de> 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 Sun, 6 Oct 2002, Craig Rodrigues wrote: CR>There are 2 total nodes: CR> Name: ngctl3796 Type: socket ID: 0000001d Num hooks: 0 CR> Name: fatm0 Type: atm ID: 0000000a Num hooks: 0 CR> CR>The fatm0 is from Harti Brandt's Netgraph ATM system which I am trying out. CR>( http://www.fokus.fhg.de/research/cc/cats/employees/hartmut.brandt/ngatm/ ) CR> CR>Can someone tell me why doing an nghook on fxp0: is not working? You must kldload ng_ether. harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.gmd.de, brandt@fokus.fhg.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 7 2: 4:17 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2376437B401 for ; Mon, 7 Oct 2002 02:04:16 -0700 (PDT) Received: from smtp.cwnt.com (smtp.cwnt.com [192.116.246.129]) by mx1.FreeBSD.org (Postfix) with ESMTP id DE8C743EA3 for ; Mon, 7 Oct 2002 02:04:14 -0700 (PDT) (envelope-from ido@cwnt.com) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Help with net.inet.ip.intr_queue_maxlen Date: Mon, 7 Oct 2002 11:04:10 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Help with net.inet.ip.intr_queue_maxlen Thread-Index: AcJtW09/GkXbnfR1RKGiggpt653IcAAggoYg From: "Ido Barnea" To: "Rogier R. Mulhuijzen" , 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 > -----Original Message----- > From: Rogier R. Mulhuijzen [mailto:drwilco@drwilco.net] > Sent: Sunday, October 06, 2002 8:15 PM > To: Ido Barnea; freebsd-net@freebsd.org > Subject: RE: Help with net.inet.ip.intr_queue_maxlen >=20 >=20 > Is there a write-up anywhere about what variables are=20 > tuneable, where to=20 > look to see if they need tuning and what the=20 > downsides/ramifications are? Here's a few links you can look at: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/configtuning-ke= rnel-limits.html http://httpd.apache.org/docs/misc/perf-bsd44.html http://www.daemonnews.org/200204/answerman.html Hope they are helpfull. >=20 > I already discovered kern.ipc.maxsockbuf needs to be raised=20 > to accommodate=20 > raising the various send and recv spaces. =3D) >=20 That's true if most of your data goes to a single socket. > Greets, >=20 > DocWilco >=20 >=20 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 7 2: 4:29 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 06A2037B404 for ; Mon, 7 Oct 2002 02:04:29 -0700 (PDT) Received: from hotmail.com (f68.law9.hotmail.com [64.4.9.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id A021B43ED4 for ; Mon, 7 Oct 2002 02:04:28 -0700 (PDT) (envelope-from soheil_h_y@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 7 Oct 2002 02:04:28 -0700 Received: from 62.217.112.191 by lw9fd.law9.hotmail.msn.com with HTTP; Mon, 07 Oct 2002 09:04:28 GMT X-Originating-IP: [62.217.112.191] From: "soheil hassas yeganeh" To: freebsd-net@FreeBSD.ORG Subject: Var. s accessible by sysctl Date: Mon, 07 Oct 2002 12:34:28 +0330 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 07 Oct 2002 09:04:28.0379 (UTC) FILETIME=[8A83CAB0:01C26DE0] 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 list How can i create a variable in kernel source codes ( for network layer - ip) that i can access it by sysctl command like other variables. Thanx S.h.y _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 7 2:31:13 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7C8ED37B401 for ; Mon, 7 Oct 2002 02:31:12 -0700 (PDT) Received: from smtp.cwnt.com (smtp.cwnt.com [192.116.246.129]) by mx1.FreeBSD.org (Postfix) with ESMTP id 46D5F43E65 for ; Mon, 7 Oct 2002 02:31:11 -0700 (PDT) (envelope-from ido@cwnt.com) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Var. s accessible by sysctl Date: Mon, 7 Oct 2002 11:31:09 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Var. s accessible by sysctl Thread-Index: AcJt4I62VXhXI+4RRWyZgpfTWlORIQAAyiMA From: "Ido Barnea" To: "soheil hassas yeganeh" , 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 something like this: static int my_variable =3D 0; SYSCTL_INT(_net_inet_ip, OID_AUTO, my_sysctl_name, CTLFLAG_RW, &my_variable, 0, "Description of my variable"); Now you can access my_variable in kernel code, and configure it using: sysctl -w net.inet.ip.my_sysctl_name =3D new_value look in sys/netinet/ip_input.c for more details > -----Original Message----- > From: soheil hassas yeganeh [mailto:soheil_h_y@hotmail.com] > Sent: Monday, October 07, 2002 11:04 AM > To: freebsd-net@FreeBSD.ORG > Subject: Var. s accessible by sysctl >=20 >=20 >=20 >=20 > Hi list > How can i create a variable in kernel source codes ( for=20 > network layer - ip)=20 > that i can access it by sysctl command like other variables. > Thanx > S.h.y >=20 > _________________________________________________________________ > MSN Photos is the easiest way to share and print your photos:=20 > http://photos.msn.com/support/worldwide.aspx >=20 >=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 Mon Oct 7 4:20:25 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A5C1737B401 for ; Mon, 7 Oct 2002 04:20:24 -0700 (PDT) Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4B05143E91 for ; Mon, 7 Oct 2002 04:20:21 -0700 (PDT) (envelope-from julian@elischer.org) 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 <20021007112020.XKHB27763.sccrmhc02.attbi.com@InterJet.elischer.org>; Mon, 7 Oct 2002 11:20:20 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id EAA33236; Mon, 7 Oct 2002 04:05:40 -0700 (PDT) Date: Mon, 7 Oct 2002 04:05:38 -0700 (PDT) From: Julian Elischer To: Harti Brandt Cc: Craig Rodrigues , freebsd-net@FreeBSD.ORG Subject: Re: Netgraph and fxp0 interface? In-Reply-To: <20021007105510.C73304-100000@beagle.fokus.gmd.de> 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, 7 Oct 2002, Harti Brandt wrote: > On Sun, 6 Oct 2002, Craig Rodrigues wrote: > > CR>There are 2 total nodes: > CR> Name: ngctl3796 Type: socket ID: 0000001d Num hooks: 0 > CR> Name: fatm0 Type: atm ID: 0000000a Num hooks: 0 > CR> > CR>The fatm0 is from Harti Brandt's Netgraph ATM system which I am trying out. > CR>( http://www.fokus.fhg.de/research/cc/cats/employees/hartmut.brandt/ngatm/ ) > CR> > CR>Can someone tell me why doing an nghook on fxp0: is not working? > > You must kldload ng_ether. or add option NETGRAPH_ETHER to your kernel config. > > harti > -- > harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private > brandt@fokus.gmd.de, brandt@fokus.fhg.de > > > 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 Mon Oct 7 5:29:54 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9A17437B401 for ; Mon, 7 Oct 2002 05:29:53 -0700 (PDT) Received: from almso2.proxy.att.com (almso2.att.com [192.128.166.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6890D43E65 for ; Mon, 7 Oct 2002 05:29:52 -0700 (PDT) (envelope-from jwb@hera.homer.att.com) Received: from ulysses.homer.att.com ([135.205.193.8]) by almso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id g97CToIQ000366 for ; Mon, 7 Oct 2002 08:29:51 -0400 (EDT) Received: from hera.homer.att.com (hera.homer.att.com [135.205.193.102]) by ulysses.homer.att.com (8.9.3/8.9.3) with ESMTP id IAA14049 for ; Mon, 7 Oct 2002 08:29:50 -0400 (EDT) Received: from hera.homer.att.com (localhost [127.0.0.1]) by hera.homer.att.com (8.9.3/8.9.3) with ESMTP id IAA26471 for ; Mon, 7 Oct 2002 08:29:50 -0400 (EDT) Message-Id: <200210071229.IAA26471@hera.homer.att.com> X-Mailer: exmh version 2.5-CVS 08/22/2002 with nmh-1.0.4 To: freebsd-net@FreeBSD.ORG Subject: isp and spoofed network address Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 07 Oct 2002 08:29:50 -0400 From: "J. W. Ballantine" 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, My isp, RCN, issues dynamic addresses via DHCP and for some strange, unknown reason issues a gateway address on a different "network" than the machine address. Windows works fine with the arrangement, but, as I would expect, FreeBSD doesn't. In the past, I've called and be able to get this fixed, but with the latest tweak, I'm getting the royal run around of: Well, we only support windows and everyone I've talked to here has no idea of how to change it... Anyway, does is there someway to get FreeBSD working with this wacky arrangement? (my thoughts are not but I'm not a networking guru) And/Or does anyone have any thoughts on what to tells these tech reps on what to do to fix this problem? thanks for any and all input Jim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 7 6:32:25 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7529837B401 for ; Mon, 7 Oct 2002 06:32:23 -0700 (PDT) Received: from almso2.proxy.att.com (almso2.att.com [192.128.166.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE0FC43E3B for ; Mon, 7 Oct 2002 06:32:22 -0700 (PDT) (envelope-from jwb@hera.homer.att.com) Received: from ulysses.homer.att.com ([135.205.193.8]) by almso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id g97DWKIQ000131; Mon, 7 Oct 2002 09:32:20 -0400 (EDT) Received: from hera.homer.att.com (hera.homer.att.com [135.205.193.102]) by ulysses.homer.att.com (8.9.3/8.9.3) with ESMTP id JAA15191; Mon, 7 Oct 2002 09:32:19 -0400 (EDT) Received: from hera.homer.att.com (localhost [127.0.0.1]) by hera.homer.att.com (8.9.3/8.9.3) with ESMTP id JAA00523; Mon, 7 Oct 2002 09:32:19 -0400 (EDT) Message-Id: <200210071332.JAA00523@hera.homer.att.com> X-Mailer: exmh version 2.5-CVS 08/22/2002 with nmh-1.0.4 To: Damian Gerow Cc: freebsd-net@FreeBSD.ORG Subject: Re: isp and spoofed network address In-reply-to: Your message of "Mon, 07 Oct 2002 09:21:12 EDT." <127308839748.20021007092112@sentex.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 07 Oct 2002 09:32:19 -0400 From: "J. W. Ballantine" 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, it's a cable modem service. I did try to explain to them that I wasn't looking for system support support, only that the provide me with a standard network configuration. The response was "I don't know how to change it and the three resources I talked to don't either." ---------- In Response to your message ------------- > Date: Mon, 7 Oct 2002 09:21:12 -0400 > To: "J. W. Ballantine" > From: Damian Gerow > Subject: Re: isp and spoofed network address > > Spake J. W. Ballantine on 07/10/2002, 08:29:50 -0400: > > My isp, RCN, issues dynamic addresses via DHCP and for some strange, unkno wn > > reason issues a gateway address on a different "network" than the machine > > address. Windows works fine with the arrangement, but, as I would expect, > > FreeBSD doesn't. In the past, I've called and be able to get this fixed, > > but with the latest tweak, I'm getting the royal run around of: > > Well, we only support windows and everyone I've talked to here has no id ea > > of how to change it... > > > Anyway, does is there someway to get FreeBSD working with this wacky > > arrangement? (my thoughts are not but I'm not a networking guru) > > And/Or does anyone have any thoughts on what to tells these tech reps on > > what to do to fix this problem? > > Which interface does your FreeBSD box use? If it's a ppp or tun > interface, there's no real reason why this won't work -- I've had it > working for my ISP (er... I work for them, actually) for the past > year without any problems. (Yes, I know DHCP isn't PPP, just trying > to cover all bases.) > > What are the IP addresses they give you? What kind of connection is > it? PPPoE? PPPoA? Cable? Dialup? > > Side note, when you call up for explanation, don't mention that you're > running FreeBSD. And if you have to, say, "I'm *not* looking for > FreeBSD support. I don't want it. I know what I'm doing. What I'm > looking for is *network* support -- why do I have a gateway on a > separate LAN than my machine?" That usually shuts up the tech support > -- drill it into their (er... our) heads that you're not looking for > OS-specific support, rather, you're looking for network configuration > support. > > - Damian > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 7 7:22:19 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2A92E37B401 for ; Mon, 7 Oct 2002 07:22:18 -0700 (PDT) Received: from relay1.macomnet.ru (relay1.macomnet.ru [195.128.64.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id D809E43E6A for ; Mon, 7 Oct 2002 07:22:15 -0700 (PDT) (envelope-from maxim@macomnet.ru) Received: from news1.macomnet.ru (news1.macomnet.ru [195.128.64.14]) by relay1.macomnet.ru (8.11.6/8.11.6) with ESMTP id g97EMDC493953 for ; Mon, 7 Oct 2002 18:22:13 +0400 (MSD) Date: Mon, 7 Oct 2002 18:22:13 +0400 (MSD) From: Maxim Konovalov X-X-Sender: Maxim Konovalov To: freebsd-net@freebsd.org Subject: patch for review, misc/42121, incorrect IPOPT_TS processing Message-ID: <20021007181752.B1993-100000@news1.macomnet.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello -net, misc/42121 has a detailed problem description, fix is obvious. Here is a patch: Index: ip_input.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_input.c,v retrieving revision 1.210 diff -u -r1.210 ip_input.c --- ip_input.c 28 Sep 2002 17:15:25 -0000 1.210 +++ ip_input.c 7 Oct 2002 14:04:06 -0000 @@ -1405,6 +1405,7 @@ (void)memcpy(sin, &IA_SIN(ia)->sin_addr, sizeof(struct in_addr)); cp[IPOPT_OFFSET] += sizeof(struct in_addr); + off += sizeof(struct in_addr); break; case IPOPT_TS_PRESPEC: @@ -1418,6 +1419,7 @@ if (ifa_ifwithaddr((SA)&ipaddr) == 0) continue; cp[IPOPT_OFFSET] += sizeof(struct in_addr); + off += sizeof(struct in_addr); break; default: %%% Any objections? -- Maxim Konovalov, MAcomnet, Internet Dept., system engineer phone: +7 (095) 796-9079, mailto:maxim@macomnet.ru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 7 7:26:18 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A20A137B401 for ; Mon, 7 Oct 2002 07:26:16 -0700 (PDT) Received: from almso2.proxy.att.com (almso2.att.com [192.128.166.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id F3CF343E77 for ; Mon, 7 Oct 2002 07:26:15 -0700 (PDT) (envelope-from jwb@hera.homer.att.com) Received: from ulysses.homer.att.com ([135.205.193.8]) by almso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id g97EQEIQ001855; Mon, 7 Oct 2002 10:26:14 -0400 (EDT) Received: from hera.homer.att.com (hera.homer.att.com [135.205.193.102]) by ulysses.homer.att.com (8.9.3/8.9.3) with ESMTP id KAA16576; Mon, 7 Oct 2002 10:26:14 -0400 (EDT) Received: from hera.homer.att.com (localhost [127.0.0.1]) by hera.homer.att.com (8.9.3/8.9.3) with ESMTP id KAA05547; Mon, 7 Oct 2002 10:26:13 -0400 (EDT) Message-Id: <200210071426.KAA05547@hera.homer.att.com> X-Mailer: exmh version 2.5-CVS 08/22/2002 with nmh-1.0.4 To: Damian Gerow Cc: freebsd-net@FreeBSD.ORG Subject: Re: isp and spoofed network address In-reply-to: Your message of "Mon, 07 Oct 2002 09:55:41 EDT." <171310909063.20021007095541@sentex.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 07 Oct 2002 10:26:13 -0400 From: "J. W. Ballantine" 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 tried the customer-is-always-right routine, and it ends up back at the same place, lets bounce your system... I'll try the route add when I get home and let you know if it works. Thanks Jim ---------- In Response to your message ------------- > Date: Mon, 7 Oct 2002 09:55:41 -0400 > To: "J. W. Ballantine" > From: Damian Gerow > Subject: Re: isp and spoofed network address > > Spake J. W. Ballantine on 07/10/2002, 09:32:19 -0400: > > Sorry, it's a cable modem service. I did try to explain to them that I > > wasn't looking for system support support, only that the provide me > > with a standard network configuration. The response was "I don't know > > how to change it and the three resources I talked to don't either." > > You can always try the customer-is-always-right routine -- "Hi, I > can't get my cable connection to work. It looks like my gateway is on > a different logical LAN than the IP address you guys give me via > DHCP." And leave it at that. Don't explain the problem to them, let > them figure it out on their own. > > As for technical configuration -- you can always add a static route > entry for your gateway. Where you are 10.0.0.1, your external > interface is fxp0, and your gateway is 172.16.0.1: > > # route add -host 172.16.0.1 10.0.0.1 -interface fxp0 > > (I haven't used this in some time -- not sure if it'll work or not.) > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 7 9:24:55 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0223237B401; Mon, 7 Oct 2002 09:24:54 -0700 (PDT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8873C43E42; Mon, 7 Oct 2002 09:24:53 -0700 (PDT) (envelope-from sam@errno.com) Received: from melange (melange.errno.com [66.127.85.82]) (authenticated bits=0) by ebb.errno.com (8.12.5/8.12.1) with ESMTP id g97GOn1H003251 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 7 Oct 2002 09:24:50 -0700 (PDT)?g (envelope-from sam@errno.com)œ X-Authentication-Warning: ebb.errno.com: Host melange.errno.com [66.127.85.82] claimed to be melange Message-ID: <150501c26e1e$0f5702b0$52557f42@errno.com> From: "Sam Leffler" To: "Julian Elischer" Cc: , References: Subject: Re: CFR: m_tag patch Date: Mon, 7 Oct 2002 09:24:49 -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 > What is the relationship between these changes and the KAME > code? In particular, are they goign to take these > changes back into Kame? Can you outline the compatibility > issues, both with KAME, and with NetBSD and OpenBSD, as I know you have > been looking at OpenBSD? > I've looked at many systems: openbsd, netbsd, linux (freeswan), bsd/os and of course I'm very familiar with commercial systems like irix and solaris. The m_tag code comes from openbsd. netbsd use aux mbuf's. Not sure what KAME compatibility means as they do not have an IPsec implementation in openbsd. The changes I proposed are intended to have the minimum impact to their source code. In fact these changes should be good for them under freebsd as it allows some obscure code to be simplified and performance to improve. Looking forward, having m_tag support (or something like it) is worthwhile for improving various bits of freebsd by replacing ad hoc mechanisms such as those used by dummynet and ipfw. It also is important to me for my IPsec implementation that uses h/w crypto and for taking advantage of future developments such as offloading IPsec calculations to NIC's. I considered a lot of different options and decided the m_tag stuff was a good way to go. It appears to do what's needed for now and the immediate future. I'm also keen to promote compatiblity across *bsd systems. Sam To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 7 9:32:18 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4833037B401; Mon, 7 Oct 2002 09:32:17 -0700 (PDT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id C863343E42; Mon, 7 Oct 2002 09:32:16 -0700 (PDT) (envelope-from sam@errno.com) Received: from melange (melange.errno.com [66.127.85.82]) (authenticated bits=0) by ebb.errno.com (8.12.5/8.12.1) with ESMTP id g97GWF1H003280 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 7 Oct 2002 09:32:16 -0700 (PDT)?g (envelope-from sam@errno.com)œ X-Authentication-Warning: ebb.errno.com: Host melange.errno.com [66.127.85.82] claimed to be melange Message-ID: <150d01c26e1f$192baf10$52557f42@errno.com> From: "Sam Leffler" To: "Terry Lambert" Cc: "Nate Lawson" , , References: <142f01c26dc1$6c4fa5b0$52557f42@errno.com> <3DA12517.6D1B4EC2@mindspring.com> Subject: Re: CFR: m_tag patch Date: Mon, 7 Oct 2002 09:32:15 -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 > Actually, the integration into IPv4 strikes me as little more than > an afterthought: the KAME code handles it in IPv6 without the extra > overhead for the non-IPSEC sockets, and the IPv4 support is more of > a bolt-on than something designed in. I'd almost want to see the > IPSEC stuff treated as a separate encapsulation layer, on its own. > IPsec integration is done the same for IPv4 and IPv6. Specifically, the socket parameter is passed through the aux mbuf rather than as a function param. I've changed both ip_output and ip6_output to pass the socket as an additional parameter to eliminate this practice. > Adding a aparameter for it specifically adds more cruft on the cruft > that's already there, and makes the IPSEC *not* an encapsulation, in > any way. 8-(. > Adding an extra param to ip*_output is a pragmatic approach chosen to minimize impact to the code and reduce overhead. FWIW this approach is also found in openbsd, irix and bsd/os. > Is there another way to do this? A general extension mechanism for > attributin mbufs seems to be a good idea. People have wanted this > before, for credentials (e.g. Robert suggested something like this > before). > m_tag's are a general extension mechanism for attributing mbuf chains (i.e. packets). If deemed worthwhile they could be promoted from the pkthdr to the base mbuf. For now I've tried to make the change that has least impact as we're (supposedly) close a freeze for DP2. Also, the change I've made permits MFC'ing to -stable w/ binary compatibility since the SLIST of m_tag's requires only a single pointer so this can replace the point to the aux mbuf list. Sam To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 7 9:47: 5 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DA53437B401; Mon, 7 Oct 2002 09:47:00 -0700 (PDT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 44ACA43E6E; Mon, 7 Oct 2002 09:47:00 -0700 (PDT) (envelope-from sam@errno.com) Received: from melange (melange.errno.com [66.127.85.82]) (authenticated bits=0) by ebb.errno.com (8.12.5/8.12.1) with ESMTP id g97Gks1H003331 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 7 Oct 2002 09:46:58 -0700 (PDT)?g (envelope-from sam@errno.com)œ X-Authentication-Warning: ebb.errno.com: Host melange.errno.com [66.127.85.82] claimed to be melange Message-ID: <151b01c26e21$26adb690$52557f42@errno.com> From: "Sam Leffler" To: "Julian Elischer" Cc: "Nate Lawson" , , References: Subject: Re: CFR: m_tag patch Date: Mon, 7 Oct 2002 09:46:53 -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 > On Sun, 6 Oct 2002, Sam Leffler wrote: > > > > 1. Is ordering important or is an SLIST sufficient for all cases? > > > > Order is not important. > > I do similar in Netgraph but could move to whatever scheme becomes > standard in the rest of the system. However I have some serious > comments. > > In netgraph I have a separate structure for the packet that contains > a pointer to the mbuf chain as well a pointer to a malloc'd memory > buffer that can contain metadata such as is kept here. > the metadata is of the form [header][field][field][field].... > > where each field was defined as: > struct meta_field_header { > u_long cookie; /* cookie for the field. Skip fields you don't > * know about (same cookie as in messgaes) */ > u_short type; /* field ID within this cookie scheme */ > u_short len; /* total len of this field including extra > * data */ > char data[0]; /* data starts here */ > }; > > the header for metadata is: > struct ng_meta { > char priority; /* -ve is less priority, 0 is default */ > char discardability; /* higher is less valuable.. discard first */ > u_short allocated_len; /* amount malloc'd */ > u_short used_len; /* sum of all fields, options etc. */ > u_short flags; /* see below.. generic flags */ > struct meta_field_header options[0]; /* add as (if) needed */ > }; > > /* Flags for meta-data */ > #define NGMF_TEST 0x01 /* discard at the last moment before sending */ > #define NGMF_TRACE 0x02 /* trace when handing this data to a node */ > > One metadata collection is associated with each packet. similar to what > you do except that in 4.x Ipass it as an arguent and in 5.0 > I have a packet header that is passed around that identifies both > data and metadata. ( I need the header for other reasons anyway) > > I show this only to show that I have tackled the same problem with a > similar but different scheme. My thought was that a packet usually only > has at most a couple of tags, and the tags are usually short, so that it > was ok to malloc a bigger chunk and using the length fields walk them. > If you didn't have room you could malloc a bigger one and copy the > intitial fields, and then add your new ones at the end. It would > probably almost never happen.. > I'm not sure I follow exactly how the above works, but the tag data structures are very simple and would appear to accomodate your data structures. An m_tag is simply a variable-length malloc'd block of memory that has a type field (and linked list pointer). What you store in the space that follows the fixed-length struct m_tag header is up to you. The type field is used simply to locate tags once attached to a packet. You can certainly allocate a tag with larger chunk of memory than you initially need and store the bookkeeping info in the tag data block. This would appear to permit implementation of the above within the m_tag framework. > I did however find a need to delete a tag once the packet passed out of > the scope of the module in question. (the "cookie" represents a > particular "ABI" the "type" is only valid withing the ABI. > If you do not support a particular cookie type you cannot interpret the > contents aof that field) Protocols and such have their own cookies. > Yes, this is exactly what the m_tag_id item is for in the m_tag data structure (what I called a type field above). > I point this out as a feature because the TAG values need to only be > defined within their own ABI/API include files. > > If a module that supports a particular cookie passes a packet out to > the rest of the world, it probably should invalidate some fields that > are set with that particular cookie, in case that packet should in some > way be redirected back towards a module that does support it, and that > might cause unexpected results. For this reason I needed to 'remove' > fields. I ended leaving them in place and setting the cookie to a > special "invalid" cookie value that no-one would match. In a similar > vein, I can imagine wanting to remove one of the 'tags' in your lists. > You can either remove tags from the chain attached to an mbuf or invalidate them as you described--by setting the m_tag_id field to something "invalid". > Each module has a cookie field that is pretty much guaranteed > to be unique (time since epoch when written) so in your terms, > the IP code would only know and recognise TAGS prepended > with the IP cookie and would handle other tags as opaque data. > Similarly IPSEC code would only see into tags with the IPSEC cookie > prepended.. I don't think you should be > defining the TAG values in a global file, but rather > each module should identify its own tags and ignode others. > If two modules need to share data, a .h file can contain the > defineitions for that API and the cookie that identifies such tags, > and both modules would include that shared include. That way > the base code need not know about future improvements, which > has always been "difficult" :-) > Changing the way m_tag_id definitions are done is fine with me. It's done statically in mbuf.h for compatibility with code I've bringing over from openbsd. > > > > > 2. Is it possible to attach the aux argument to the mbuf chain instead of > > > adding it as a new parameter to ip_output? > > > > > > > The "aux argument" _was_ originally attached to the mbuf chain. The change > > to add an extra arg to ip*_output was done to eliminate one of the biggest > > uses of the aux mbuf; the socket to use to get IPsec policy. This is a > > performance win and worth doing independent of the aux->m_tag switch. > > > > One could split the ip_output change out but doing it together avoids > > converting code that would just eventually be eliminated (unless you did the > > ip_output change first and then the m_tag switch). > > I'm not sure but it's possible m_aux was invented so that ip_output() > would not change interfaces to match with was defined in some interface > method table. I think NetBSD added entries in their > interface method tables with varargs (yech) to get around some of this.. > > > So in summary: > is it worth making it a linked list? > how many tags do you see on packets, and how large are they? > CAn you use a sche,e suc as that outlined so that each module can > define its own tags privatly? > You can certainly use a scheme as you suggest. I don't believe doing something like that is precluded by what I've offered, you'd just layer the additional logic on top w/o any changes--I think. Tags tend to be very small (e.g. a pointer or two ints) and there tend to be only 1 or 2 when there are any. In my performance tuning work with IPsec their manipulation has never shown up as significant in kernel profiles. Sam To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 7 9:55:18 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C599237B401 for ; Mon, 7 Oct 2002 09:55:16 -0700 (PDT) Received: from hotmail.com (f39.law14.hotmail.com [64.4.21.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 85EBF43E75 for ; Mon, 7 Oct 2002 09:55:16 -0700 (PDT) (envelope-from floating_in_space_@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 7 Oct 2002 09:55:16 -0700 Received: from 132.216.48.34 by lw14fd.law14.hotmail.msn.com with HTTP; Mon, 07 Oct 2002 16:55:16 GMT X-Originating-IP: [132.216.48.34] From: "alexis georges" To: freebsd-net@FreeBSD.org Subject: Sympatico ADSL connection through a hub Date: Mon, 07 Oct 2002 16:55:16 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 07 Oct 2002 16:55:16.0480 (UTC) FILETIME=[4FB1F000:01C26E22] 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, This is my first message posted to the list..hehehe anyways, i used to have a simple cable connection, which would be automatically comfigured by FreeBSD upon installation..I just moved and now we have an ADSL connection (from Sympatico).. The connection is not configured automatically..so i looked on the web for a solution. I found a few pages explaining that i had to recompile my kernel with a few lines such as 'options NETGRAPH'..and that i had to write some info into the ppp.conf file..i did those things but apparently it doesn't work..I am not sure how to work this out..cuz all the solutions i found were the same.. So i will explain exactly how i am connected to the internet.. 1. I have an ethernet card connected to a hub. 2. This hub is itself connected to the actual modem that we received from Sympatico. On Windowsl, the conection wont work unless the connection type is set to 10Mb Half-Duplex..so i am guessing it should be the same on FreeBSD.. also, the address is supposed to be obtained dynamically..(on windows it says the address has been obtrained by DHCP, however, during FreeBSD installation, it fails to find the parameter for the connection)does that mean that instead of the 10.0.0.1 address teh solution form the web gave me, i should put the address that i am using on windows (even though it shouild be a dynamic address?) Anyways, i would really like to be able to fix this..if anyone could help, that would be great..i wanna get rid of windows Thank You Alexis _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 7 10:58:52 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2007E37B401 for ; Mon, 7 Oct 2002 10:58:51 -0700 (PDT) Received: from stewart.chicago.il.us (user166.64.47.24.dsli.com [64.47.24.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1B0E343E6E for ; Mon, 7 Oct 2002 10:58:50 -0700 (PDT) (envelope-from randall@stewart.chicago.il.us) Received: from stewart.chicago.il.us (stewlap [10.1.1.5]) by stewart.chicago.il.us (8.11.1/8.11.1) with ESMTP id g97HwgH33127 for ; Mon, 7 Oct 2002 12:58:43 -0500 (CDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3DA1CB52.9080302@stewart.chicago.il.us> Date: Mon, 07 Oct 2002 12:58:42 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: inetd issue 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: While attempting to make inetd work with SCTP (the one distrbituted with the KAME stack now).. I ran in to a little issue.. It appears when inetd opens its socket it does: " if ((sep->se_fd = socket(sep->se_family, sep->se_socktype, 0)) < 0) { if (debug) warn("socket failed on %s/%s", sep->se_service, sep->se_proto); syslog(LOG_ERR, "%s/%s: socket: %m", sep->se_service, sep->se_proto); return; } This of course causes a problem with a SCTP TCP-Style symantic which also uses SOCK_STREAM... Should not this really be: " struct protoent *p; int proto_num; p = getprotobyname(sep->se_proto); if(p){ proto_num = p->p_proto; }else{ proto_num = 0; } if ((sep->se_fd = socket(sep->se_family, sep->se_socktype, proto_num)) < 0) { if (debug) warn("socket failed on %s/%s", sep->se_service, sep->se_proto); syslog(LOG_ERR, "%s/%s: socket: %m", sep->se_service, sep->se_proto); return; } " Thanks R -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 7 11:52:18 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E666737B401 for ; Mon, 7 Oct 2002 11:52:16 -0700 (PDT) Received: from isilon.com (isilon.com [65.101.129.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id 02A3643E4A for ; Mon, 7 Oct 2002 11:52:16 -0700 (PDT) (envelope-from bbaumann@isilon.com) Received: from localhost (localhost [127.0.0.1]) by isilon.com (8.12.2/8.11.1) with ESMTP id g97IqF23056011 for ; Mon, 7 Oct 2002 11:52:15 -0700 (PDT) (envelope-from bbaumann@isilon.com) Date: Mon, 7 Oct 2002 11:52:15 -0700 (PDT) From: Bill Baumann To: freebsd-net@FreeBSD.ORG Subject: Re: Help with net.inet.ip.intr_queue_maxlen In-Reply-To: <3D9F8002.70500@expertcity.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 My thought is that the net.inet.ip.intr_queue_maxlen should be set to the maximum receive queue length of your NIC. Depending upon traffic (bursty short packets being the worst), other kernel operations being slow, and NIC interrupt coalesce or polling times, your NIC's rx buffer can fill significantly before the NIC's receive queue is be processed. Thats why we have large queues at this level! Unfortuantely, the default for net.inet.ip.intr_queue_maxlen is not nearly large enough to to accomidate but small percentage of the NICs rx queue. The default is 50, but should be more like 500. I think the bge driver's rx queue can handle 512 1500MTU plus 256 9000MTU frames. So the NIC can receive 768 before dropping frames, but the IP stack can only handle the first 50. As far as I know none of the drivers know to do anything about this problem. Due to the above, I can image scenarios where you would experience significant packet loss with a low CPU utilization. You may also want to consider decreasing interrupt coalescing parameters in the NIC or polling times. This will lower the latencies, but increase the CPU overhead attributed to the NIC. Good luck! On Sat, 5 Oct 2002, Steve Francis wrote: > Can someone help me with net.inet.ip.intr_queue_maxlen tuning? > > Firstly, its the "size of the IP input queue", per the source. > > So does that mean after the NIC has received the packet, the interupt > from the NIC has been processed and the packet retrieved from the NIC, > then the packet is placed in this queue, before the IP stack looks at it? > i.e. its unrelated to interupt coalescing or polling, or NIC > performance, as they have already occurred in order to put the packet > into the queue. Yes? > > I am getting incrementing net.inet.ip.intr_queue_drops at around 8,000 > pps (increasing drops at rate of 10 or so per second.) > Yet, if my statement above about what the queue is, is correct, then it > just means that the system was busy doing stuff before it had a chance > to process the incoming packets, so there was no room for new ones to > enter the queue. But as the system was only 50% busy, then if I increase > the input queue, I should be able to avoid these drops, correct? At > least until the system gets a lot busier. > > Is there a sane upper recommended limit to the queue length? > > Or am I way off base here? > Thanks > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 7 13:30: 0 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B6CFB37B401 for ; Mon, 7 Oct 2002 13:29:59 -0700 (PDT) Received: from lion.com.ua (lion.com.ua [213.133.161.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 360C143E6E for ; Mon, 7 Oct 2002 13:29:56 -0700 (PDT) (envelope-from sa@simon.org.ua) Received: from localhost (localhost [127.0.0.1]) by lion.com.ua (8.12.5/8.12.5) with ESMTP id g97KTovI091750 for ; Mon, 7 Oct 2002 23:29:53 +0300 (EEST) (envelope-from sa@simon.org.ua) Date: Mon, 7 Oct 2002 23:29:50 +0300 (EEST) From: Andrey Simonenko X-X-Sender: sa@lion.com.ua To: freebsd-net@freebsd.org Subject: Q about sbin/ip6fw/ip6fw.c:list() Message-ID: <20021007222647.B91626-100000@lion.com.ua> 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, Why is it not allowed to get more that 65536 ip6fw rules from the kernel in the ip6fw.c:list() function? Here is some lines from ip6fw.c: maxbytes = 65536 * sizeof *rules; while (bytes >= nalloc) { nalloc = nalloc * 2 + 200; bytes = nalloc; if ((rules = realloc(rules, bytes)) == NULL) err(EX_OSERR, "realloc"); i = getsockopt(s, IPPROTO_IPV6, IPV6_FW_GET, rules, &bytes); if ((i < 0 && errno != EINVAL) || nalloc > maxbytes) err(EX_OSERR, "getsockopt(IPV6_FW_GET)"); } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 7 14:40:17 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F3AE137B404; Mon, 7 Oct 2002 14:40:12 -0700 (PDT) Received: from sccrmhc03.attbi.com (sccrmhc03.attbi.com [204.127.202.63]) by mx1.FreeBSD.org (Postfix) with ESMTP id 426E943E77; Mon, 7 Oct 2002 14:40:12 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by sccrmhc03.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20021007214011.LSTQ22381.sccrmhc03.attbi.com@InterJet.elischer.org>; Mon, 7 Oct 2002 21:40:11 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id OAA35699; Mon, 7 Oct 2002 14:21:15 -0700 (PDT) Date: Mon, 7 Oct 2002 14:21:14 -0700 (PDT) From: Julian Elischer To: Sam Leffler Cc: freebsd-arch@freebsd.org, freebsd-net@freebsd.org Subject: Re: CFR: m_tag patch In-Reply-To: <13e901c26dbb$63059f60$52557f42@errno.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 If we make this a 'standard' method of adding metadata to a packet, then I'd like to move netgraph to use it to. it's always better to use a standard method if it will do than to roll your own. however, there are some thiongs that would proclude me from doing so at tth moment. Thes are not major issues but they do give a little feeling of "banging a square peg into a round hole" if I try use what you have for replacing the netgraph metadata system. Issues: Firstlty, each netgraph module type is ignorant of all other types (except in some special cases). Each 'type' labels its structures, control messages, and in fact special metadata that it keeps on a packet, using a special maginc number. Each 'type' of netgraph node (e.g. ppp node, or frame-relay-mux node) defines a different 32 bit magic number (traditionally in netgraph it's just the 32 bit time since the epoch when the module was written). Metadata that is associated with a packet may only have meaning to a subset of the modules that touch that packet. so in effect teh maginc number is an API/ABI indicator. It specifies which API defines this metadata. (or in netgraph, this control message). A particular set of modules may want to know about a common API which includes some metadata thet they share. In tehis case it is permissable for them to agree about a common magic number to identify these things, stored in an include file special to that API interface. All modules that do not know about that maginc number (do not include that API include file) must ignore that metadata. In this way 3rd party modes can define their own metadata types, assuming that they do not have a magic-number collision with some other node type (pretty damned unlikely). Once they have seen that teh metadata belongs to an API they understand then, and only then will they look firther to try understand the type of the metadata. There is enough data (e.g. size info) to allow ignorant nodes to free or bypass unknown metadata. Your tags have a single 16 bit tag ID field. This is insufficient for my needs. I need to be able to store the API cookie which is a 32 bit unsigned number, and on top of that, I also need a 16 bit type field that specifies what the data is within teh given API and a 16 bit length to allow opaque handling. your stucture is: /* * Packet tags structure. */ struct m_tag { SLIST_ENTRY(m_tag) m_tag_link; /* List of packet tags */ u_int16_t m_tag_id; /* Tag ID */ u_int16_t m_tag_len; /* Length of data */ }; and mine is: struct meta_field_header { u_long cookie; /* cookie for the field. Skip fields you don't * know about (same cookie as in messages) */ u_short type; /* field ID */ u_short len; /* total len of this field including extra * data */ char data[0]; /* data starts here */ }; Basically I'd need to add a 32 bit API identifier to the metadata to allow me to use it. Since (for example) both ppp and frame relay could define a metadata of type "1". Since neither ppp nor frame realy knows of the other they can not co-operate on selecting command and metadata IDs. However we DO send ppp packets over frame relay links, so the chance that a packet has to pass through both node types is very real. I would define a 'global' API that defines a few characteristics that would be useful for all modules to know about. e.g. packet priority. (frame relay needs this to work right for example, but it needs to be understood at the physical layer so that hi-pri packets can bypass low-pri packets) Your TAG IDS are centrally allocated. e.g. in mbuf.h: /* Packet tag types -- first ones are from NetBSD */ #define PACKET_TAG_NONE 0 /* Nadda */ #define PACKET_TAG_IPSEC_IN_DONE 1 /* IPsec applied, in */ #define PACKET_TAG_IPSEC_OUT_DONE 2 /* IPsec applied, out */ #define PACKET_TAG_IPSEC_IN_CRYPTO_DONE 3 /* NIC IPsec crypto done */ #define PACKET_TAG_IPSEC_OUT_CRYPTO_NEEDED 4 /* NIC IPsec crypto req'ed */ #define PACKET_TAG_IPSEC_IN_COULD_DO_CRYPTO 5 /* NIC notifies IPsec */ #define PACKET_TAG_IPSEC_PENDING_TDB 6 /* Reminder to do IPsec */ #define PACKET_TAG_BRIDGE 7 /* Bridge processing done */ #define PACKET_TAG_GIF 8 /* GIF processing done */ #define PACKET_TAG_GRE 9 /* GRE processing done */ [etc.] If you allocated your API definitions corectly using my scheme, you might allocate a API number of 1034025045 for example to the IPSEC-CRYPTO interface. and that API would define it's own IDS for metadata. This would not be able to accidentally match with the Priority metadata used for frame relay (if you sent Ipsec over frame relay) because (for example) teh frame relay API number is 872148478 /usr/include/netgraph/ng_frame_relay.h line 48 #define NGM_FRAMERELAY_COOKIE 872148478 You wouldn't have to know about frame relay and frame relay doesn't need to know about IPSEC, but it does know how to free the metadata if it needs to discard the packet. (this is a contrived example because priority is a "BASE API" metadata type in netgraph, and the base API doesn't have a magic number at the moment but probably should have one. (certainly would in this case) As I mentionned before, it is also not clear to me that the metadata needs to be in linked list form, but I could live with it. julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 7 15:36:52 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8C4AD37B401; Mon, 7 Oct 2002 15:36:49 -0700 (PDT) Received: from swan.mail.pas.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A8D943E65; Mon, 7 Oct 2002 15:36:49 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0113.cvx22-bradley.dialup.earthlink.net ([209.179.198.113] helo=mindspring.com) by swan.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17ygUR-0007mN-00; Mon, 07 Oct 2002 15:36:39 -0700 Message-ID: <3DA20C1C.A4B863B7@mindspring.com> Date: Mon, 07 Oct 2002 15:35:08 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: Sam Leffler , freebsd-arch@freebsd.org, freebsd-net@freebsd.org Subject: Re: CFR: m_tag patch References: 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 Julian Elischer wrote: > Firstlty, each netgraph module type is ignorant of > all other types (except in some special cases). Each 'type' > labels its structures, control messages, and in fact special metadata > that it keeps on a packet, using a special maginc number. Each 'type' > of netgraph node (e.g. ppp node, or frame-relay-mux node) > defines a different 32 bit magic number (traditionally in netgraph > it's just the 32 bit time since the epoch when the module was written). I think the biggest problem is that mbuf lists are not the same thing as packets, and they may not even contain *whole* packets, depending on where in the process you are examining them. Therefore the idea of "packet attributes" is broken to begin with -- particularly, since if the attribute results in TCP options being set on all frags for the packet in question, you will change the amount of real data being sent in the frag. If you are going to treat it as an attribute, then the abstract thing you need to be passing around is a packet, not an mbuf chain. This is probably not a good idea, in general, even if it would let you do nifty things. One obvious application here is to communicate flow information from a front end router to a back end server and/or load balancer, in order to permit it to make better decisions. Such information would be tunnelled in option data on the payload packets between the router and the other end. > Your tags have a single 16 bit tag ID field. > This is insufficient for my needs. > I need to be able to store the API cookie which is a 32 bit > unsigned number, and on top of that, I also need a 16 bit type field > that specifies what the data is within teh given API and a 16 bit > length to allow opaque handling. This is insufficient for Alpha and other 64 bit architectures. I think what you are asking for is really a 'void *'. The other issue here is that your idea of an opaque API/ABI indicator is in conflict, unless you say that this is a pointer, and then format the initial information pointed to by the pointer. Otherwise, you will need a small indirection structure that's pointed to the pointer, AND which contains the API/ABI identifier (i.e. you will need two, not one piece of information for that -- which is what you show, but not what you describe in your text). [ ... ] > If you allocated your API definitions corectly > using my scheme, you might allocate a API number of > 1034025045 for example to the IPSEC-CRYPTO interface. > and that API would define it's own IDS for metadata. > This would not be able to accidentally match with the Priority > metadata used for frame relay (if you sent Ipsec over frame relay) > because (for example) teh frame relay API number is 872148478 > /usr/include/netgraph/ng_frame_relay.h line 48 > > #define NGM_FRAMERELAY_COOKIE 872148478 This is moderately bogus. Specifically, ig you are going to register in new types without an assigned numbers authority (e.g. if I have a vendor private extension, which I wish to implement, yet not have collide with someone else's vendor private extension or a future FreeBSD "standard extension"), then you need to implement a registration interface for named registration, and use *that*. The easiest way to do this would be to ensure that you use the *runtime* kernel address as your identifier, which guarantees that it will be unique in any given system. Yes, I realize that this means that a switch statement may not be used internally to dispatch. In theory, this metadata is an exceptional condition, rather than a common condition (otherwise, the overhead becomes prohibitive, I think, and you might as well put it inline). I think the value of a unique identifier is more important than the ability to switch. If it comes down to it, something which does not conflict is more useful than something which would be faster if it didn't conflict, but doesn't run at all because it doesn't get the chance. > You wouldn't have to know about frame relay and frame relay doesn't need > to know about IPSEC, but it does know how to free the metadata if it > needs to discard the packet. Yes. This implies that metadata ownership indicates a permetadata destructor type; for example, a reference to an object that will no longer be referenced, should the packet be discarded. > As I mentionned before, it is also not clear to me that the metadata > needs to be in linked list form, but I could live with it. I think it has to. The reason he has this is pretty clear from his crypto work, and the reason for the linked list is to, in the limit, allow a linear traversal of the list elements to find data that's relevent to you. It's kind of ugly, but "anything that works is better than anything that doesn't"... it at least guarantees that it *can* work. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 7 15:52:57 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7029537B401; Mon, 7 Oct 2002 15:52:53 -0700 (PDT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id D304D43E3B; Mon, 7 Oct 2002 15:52:52 -0700 (PDT) (envelope-from sam@errno.com) Received: from melange (melange.errno.com [66.127.85.82]) (authenticated bits=0) by ebb.errno.com (8.12.5/8.12.1) with ESMTP id g97Mqo1H005527 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 7 Oct 2002 15:52:50 -0700 (PDT)?g (envelope-from sam@errno.com)œ X-Authentication-Warning: ebb.errno.com: Host melange.errno.com [66.127.85.82] claimed to be melange Message-ID: <185201c26e54$43339f40$52557f42@errno.com> From: "Sam Leffler" To: "Julian Elischer" Cc: , References: Subject: Re: CFR: m_tag patch Date: Mon, 7 Oct 2002 15:52:49 -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 > If we make this a 'standard' method of adding metadata to a packet, then > I'd like to move netgraph to use it to. it's always better > to use a standard method if it will do than to roll your own. > > however, there are some thiongs that would proclude me from doing so at > tth moment. Thes are not major issues but they do give a little feeling > of "banging a square peg into a round hole" if I try use what you have > for replacing the netgraph metadata system. > > Issues: > > Firstlty, each netgraph module type is ignorant of > all other types (except in some special cases). Each 'type' > labels its structures, control messages, and in fact special metadata > that it keeps on a packet, using a special maginc number. Each 'type' > of netgraph node (e.g. ppp node, or frame-relay-mux node) > defines a different 32 bit magic number (traditionally in netgraph > it's just the 32 bit time since the epoch when the module was written). > > Metadata that is associated with a packet may only have meaning > to a subset of the modules that touch that packet. so in effect > teh maginc number is an API/ABI indicator. It specifies which API > defines this metadata. (or in netgraph, this control message). > A particular set of modules may want to know about a common API which > includes some metadata thet they share. In tehis case it is permissable > for them to agree about a common magic number to identify these > things, stored in an include file special to that API interface. > > All modules that do not know about that maginc number (do not include > that API include file) must ignore that metadata. In this way > 3rd party modes can define their own metadata > types, assuming that they do not have a magic-number collision with some > other node type (pretty damned unlikely). Once they have seen that > teh metadata belongs to an API they understand then, and only then will > they look firther to try understand the type of the metadata. > There is enough data (e.g. size info) to allow ignorant nodes to free or > bypass > unknown metadata. > > > Your tags have a single 16 bit tag ID field. > This is insufficient for my needs. > I need to be able to store the API cookie which is a 32 bit > unsigned number, and on top of that, I also need a 16 bit type field > that specifies what the data is within teh given API and a 16 bit > length to allow opaque handling. > > your stucture is: > /* > * Packet tags structure. > */ > struct m_tag { > SLIST_ENTRY(m_tag) m_tag_link; /* List of packet tags */ > u_int16_t m_tag_id; /* Tag ID */ > u_int16_t m_tag_len; /* Length of data */ > }; > > > and mine is: > > struct meta_field_header { > u_long cookie; /* cookie for the field. Skip fields you don't > * know about (same cookie as in messages) */ > u_short type; /* field ID */ > u_short len; /* total len of this field including extra > * data */ > char data[0]; /* data starts here */ > }; > > Basically I'd need to add a 32 bit API identifier > to the metadata to allow me to use it. Since (for example) > both ppp and frame relay could define a metadata of type "1". > > Since neither ppp nor frame realy knows of the other they can not > co-operate on selecting command and metadata IDs. However > we DO send ppp packets over frame relay links, so the chance that > a packet has to pass through both node types is very real. > > I would define a 'global' API that defines a few characteristics that > would be useful for all modules to know about. > e.g. packet priority. (frame relay needs this to work right > for example, but it needs to be understood at the physical > layer so that hi-pri packets can bypass low-pri packets) > So all this is to say that you want m_tag_id to be u_int32_t. Having another 16-bit field is immaterial to anything I've thought of but given that switching to a 32-bit tag_id will require allocating an additional 32-bit item you can have that for free since there's little point in having a 32-bit length. The obvious downside is that m_tag structs now go from 8 bytes to 12, but this is still a darn sight better than allocating a 256 byte mbuf. > Your TAG IDS are centrally allocated. > e.g. in mbuf.h: > /* Packet tag types -- first ones are from NetBSD */ > > #define PACKET_TAG_NONE 0 /* Nadda */ > #define PACKET_TAG_IPSEC_IN_DONE 1 /* IPsec applied, in */ > #define PACKET_TAG_IPSEC_OUT_DONE 2 /* IPsec applied, out */ > #define PACKET_TAG_IPSEC_IN_CRYPTO_DONE 3 /* NIC IPsec crypto done */ > #define PACKET_TAG_IPSEC_OUT_CRYPTO_NEEDED 4 /* NIC IPsec crypto req'ed */ > #define PACKET_TAG_IPSEC_IN_COULD_DO_CRYPTO 5 /* NIC notifies IPsec */ > #define PACKET_TAG_IPSEC_PENDING_TDB 6 /* Reminder to do IPsec */ > #define PACKET_TAG_BRIDGE 7 /* Bridge processing done */ > #define PACKET_TAG_GIF 8 /* GIF processing done */ > #define PACKET_TAG_GRE 9 /* GRE processing done */ > [etc.] > > If you allocated your API definitions corectly > using my scheme, you might allocate a API number of > 1034025045 for example to the IPSEC-CRYPTO interface. > and that API would define it's own IDS for metadata. > This would not be able to accidentally match with the Priority > metadata used for frame relay (if you sent Ipsec over frame relay) > because (for example) teh frame relay API number is 872148478 > /usr/include/netgraph/ng_frame_relay.h line 48 > > #define NGM_FRAMERELAY_COOKIE 872148478 > > You wouldn't have to know about frame relay and frame relay doesn't need > to know about IPSEC, but it does know how to free the metadata if it > needs to discard the packet. > If you allocate tag id's using your 32-bit time scheme then the fixed values above would never be hit since they are all for impossible times and so there'd be no conflict. > > (this is a contrived example because priority is a "BASE API" metadata > type in netgraph, and the base API doesn't have a magic number at the > moment but probably should have one. (certainly would in this case) > > > As I mentionned before, it is also not clear to me that the metadata > needs to be in linked list form, but I could live with it. > Sounds to me like the real issue for you is insuring unique m_tag_id values. We're certainly less likely to have collisions with a 32-bit value than a 16-bit value and expanding this way gives you your "field ID" too. I guess the question I have is whether the existing API's that search only by "cookie" are sufficient for your needs. If so then I'm ok with changing things. Otherwise we have an API incompatibility with openbsd that I'd like to avoid. Sam To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 7 16:20:12 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 121FA37B401; Mon, 7 Oct 2002 16:20:09 -0700 (PDT) Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id A3B5643E6A; Mon, 7 Oct 2002 16:20:08 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20021007232007.OMXC18767.rwcrmhc53.attbi.com@InterJet.elischer.org>; Mon, 7 Oct 2002 23:20:07 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id QAA36302; Mon, 7 Oct 2002 16:11:13 -0700 (PDT) Date: Mon, 7 Oct 2002 16:11:12 -0700 (PDT) From: Julian Elischer To: Terry Lambert Cc: Sam Leffler , freebsd-arch@freebsd.org, freebsd-net@freebsd.org Subject: Re: CFR: m_tag patch In-Reply-To: <3DA20C1C.A4B863B7@mindspring.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 Mon, 7 Oct 2002, Terry Lambert wrote: > > > > Your tags have a single 16 bit tag ID field. > > This is insufficient for my needs. > > I need to be able to store the API cookie which is a 32 bit > > unsigned number, and on top of that, I also need a 16 bit type field > > that specifies what the data is within teh given API and a 16 bit > > length to allow opaque handling. > > This is insufficient for Alpha and other 64 bit architectures. I > think what you are asking for is really a 'void *'. IT IS NOT A POINTER! it is a 32 bit unsigned number. > > The other issue here is that your idea of an opaque API/ABI indicator > is in conflict, unless you say that this is a pointer, and then format > the initial information pointed to by the pointer. Otherwise, you > will need a small indirection structure that's pointed to the pointer, > AND which contains the API/ABI identifier (i.e. you will need two, not > one piece of information for that -- which is what you show, but not > what you describe in your text). it is not used to look up anything.. it is used to verify only. it is just working on the principal that there is not going to be a collision in the 32 bit space. Especially when we create them from "time since the epoch", and when teh various authors can see each other's choices of value. > This is moderately bogus. no it is not. I estimate that the chance of having a collision given all the factors is 1:2^50 or so ASSUMING THAT 1000000 PEOPLE DEVELOP THEIR OWN MODULES AND DO NOT CHECK THEM IN BUT DO ALL SHARE THEM WITH EACH OTHER. > > Specifically, if you are going to register in new types without an > assigned numbers authority (e.g. if I have a vendor private extension, > which I wish to implement, yet not have collide with someone else's > vendor private extension or a future FreeBSD "standard extension"), > then you need to implement a registration interface for named > registration, and use *that*. Terry if you like your chances of developing a module within the next 100 years in exactly the same moment to the second that someone else does so, and neither of you checks in that module, and your modules have to co-exist, and you don't TALK to each other, then I have some used lottery tickets I an sell you.. > The easiest way to do this would be to ensure that you use the > *runtime* kernel address as your identifier, which guarantees that > it will be unique in any given system. Terry I am NOT going to do that.. end of argument. > I think it has to. The reason he has this is pretty clear from > his crypto work, and the reason for the linked list is to, in the > limit, allow a linear traversal of the list elements to find data > that's relevent to you. Read what he said Terry.. for gods sake. He said that there are usually < 2 metadata elements each being a few bytes long.. > > It's kind of ugly, but "anything that works is better than anything > that doesn't"... it at least guarantees that it *can* work. there is more than one way to skin a cat. the fact that it is a linked list doesn't mean it has to be a linked list. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 7 16:31: 6 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5023337B401; Mon, 7 Oct 2002 16:31:05 -0700 (PDT) Received: from carp.icir.org (carp.icir.org [192.150.187.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id EE83B43E91; Mon, 7 Oct 2002 16:31:04 -0700 (PDT) (envelope-from rizzo@carp.icir.org) Received: from carp.icir.org (localhost [127.0.0.1]) by carp.icir.org (8.12.3/8.12.3) with ESMTP id g97NV1O2028018; Mon, 7 Oct 2002 16:31:01 -0700 (PDT) (envelope-from rizzo@carp.icir.org) Received: (from rizzo@localhost) by carp.icir.org (8.12.3/8.12.3/Submit) id g97NV1Gn028017; Mon, 7 Oct 2002 16:31:01 -0700 (PDT) (envelope-from rizzo) Date: Mon, 7 Oct 2002 16:31:01 -0700 From: Luigi Rizzo To: Sam Leffler Cc: Julian Elischer , freebsd-arch@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: CFR: m_tag patch Message-ID: <20021007163101.A27463@carp.icir.org> References: <185201c26e54$43339f40$52557f42@errno.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: <185201c26e54$43339f40$52557f42@errno.com>; from sam@errno.com on Mon, Oct 07, 2002 at 03:52:49PM -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 the 16 vs. 32 bit On Mon, Oct 07, 2002 at 03:52:49PM -0700, Sam Leffler wrote: ... > Sounds to me like the real issue for you is insuring unique m_tag_id values. > We're certainly less likely to have collisions with a 32-bit value than a > 16-bit value and expanding this way gives you your "field ID" too. I guess > the question I have is whether the existing API's that search only by > "cookie" are sufficient for your needs. If so then I'm ok with changing > things. Otherwise we have an API incompatibility with openbsd that I'd like > to avoid. i wonder what do we gain by moving to 32 bit m_tag_id -- because there is is still no strict guarantee that we have no conflicts if people randomly choose "cookies", and also, using the same reasoning for allocations one could argue that having the cookie chosen as the number of _days_ since the epoch, will still give low conflict probability while still fitting in 16 bits. Also, those modules that require one or a very small number of different annotations (e.g. all the ones currently using m_tags) would just need the "cookie", whereas others with a large set of subfields could as well consider the field_id as part of the opaque data. cheers luigi ----------------------------------+----------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone: (510) 666 2988 ----------------------------------+----------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 7 16:40:11 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C852F37B401; Mon, 7 Oct 2002 16:40:08 -0700 (PDT) Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 372BE43E42; Mon, 7 Oct 2002 16:40:08 -0700 (PDT) (envelope-from julian@elischer.org) 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 <20021007234007.RWGE27763.sccrmhc02.attbi.com@InterJet.elischer.org>; Mon, 7 Oct 2002 23:40:07 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id QAA36379; Mon, 7 Oct 2002 16:23:02 -0700 (PDT) Date: Mon, 7 Oct 2002 16:23:00 -0700 (PDT) From: Julian Elischer To: Sam Leffler Cc: freebsd-arch@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: CFR: m_tag patch In-Reply-To: <185201c26e54$43339f40$52557f42@errno.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 Mon, 7 Oct 2002, Sam Leffler wrote: > > So all this is to say that you want m_tag_id to be u_int32_t. Having > another 16-bit field is immaterial to anything I've thought of but given > that switching to a 32-bit tag_id will require allocating an additional > 32-bit item you can have that for free since there's little point in having > a 32-bit length. The obvious downside is that m_tag structs now go from 8 > bytes to 12, but this is still a darn sight better than allocating a 256 > byte mbuf. sure... "an extra 4 bytes please sir" :-) > > If you allocate tag id's using your 32-bit time scheme then the fixed values > above would never be hit since they are all for impossible times and so > there'd be no conflict. Just make them all IDs in a single "Legacy" API > > > > > (this is a contrived example because priority is a "BASE API" metadata > > type in netgraph, and the base API doesn't have a magic number at the > > moment but probably should have one. (certainly would in this case) > > > > > > As I mentionned before, it is also not clear to me that the metadata > > needs to be in linked list form, but I could live with it. > > > > Sounds to me like the real issue for you is insuring unique m_tag_id values. > We're certainly less likely to have collisions with a 32-bit value than a > 16-bit value and expanding this way gives you your "field ID" too. I guess > the question I have is whether the existing API's that search only by > "cookie" are sufficient for your needs. If so then I'm ok with changing > things. Otherwise we have an API incompatibility with openbsd that I'd like > to avoid. You could "mis-use" the API identifier as you suggest, or you could just keep them in theID and have "Legacy" API identifier of 1034032666 (the output of date -u +'%s' for right now.. the suggested method of deriving an API ID.) I'd rather not pollute the namespace of other modules, but it's up to you. first check if it's an API you understand. if not skip to next if it is, go to some switch table to identify more exactly.. heck take API identifier #0 :-) I have actually had code with 2 version sof the same API. Being able to just assign a different API ID was good. I could support both sorts of input. Julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 7 17: 0:14 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1372F37B406; Mon, 7 Oct 2002 17:00:11 -0700 (PDT) Received: from sccrmhc01.attbi.com (sccrmhc01.attbi.com [204.127.202.61]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7066A43E75; Mon, 7 Oct 2002 17:00:10 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by sccrmhc01.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20021008000009.VNMZ6431.sccrmhc01.attbi.com@InterJet.elischer.org>; Tue, 8 Oct 2002 00:00:09 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id QAA36501; Mon, 7 Oct 2002 16:55:43 -0700 (PDT) Date: Mon, 7 Oct 2002 16:55:42 -0700 (PDT) From: Julian Elischer To: Luigi Rizzo Cc: Sam Leffler , freebsd-arch@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: CFR: m_tag patch In-Reply-To: <20021007163101.A27463@carp.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 Mon, 7 Oct 2002, Luigi Rizzo wrote: > the 16 vs. 32 bit > On Mon, Oct 07, 2002 at 03:52:49PM -0700, Sam Leffler wrote: > ... > > Sounds to me like the real issue for you is insuring unique m_tag_id values. > > We're certainly less likely to have collisions with a 32-bit value than a > > 16-bit value and expanding this way gives you your "field ID" too. I guess > > the question I have is whether the existing API's that search only by > > "cookie" are sufficient for your needs. If so then I'm ok with changing > > things. Otherwise we have an API incompatibility with openbsd that I'd like > > to avoid. > > i wonder what do we gain by moving to 32 bit m_tag_id -- because there is > is still no strict guarantee that we have no conflicts > if people randomly choose "cookies", and also, using the same reasoning > for allocations one could argue that having the cookie chosen as the number > of _days_ since the epoch, will still give low conflict probability while > still fitting in 16 bits. > Also, those modules that require one or a very small number of different > annotations (e.g. all the ones currently using m_tags) would just need > the "cookie", whereas others with a large set of subfields could as well > consider the field_id as part of the opaque data. In my usage, the API id also includes other parts of the API, not just packet metadata. I use teh same cookie to define control command messags within netgraph. In fact the control messages currently FAR exceed the metadata types. At this moment there are about 37 APIS defined in netgraph and they implement about 150 different control messages there are only 2 metadata types in use. (priority and "dropability") To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 7 17: 6:31 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 82D2B37B401; Mon, 7 Oct 2002 17:06:29 -0700 (PDT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 19F2243E77; Mon, 7 Oct 2002 17:06:29 -0700 (PDT) (envelope-from sam@errno.com) Received: from melange (melange.errno.com [66.127.85.82]) (authenticated bits=0) by ebb.errno.com (8.12.5/8.12.1) with ESMTP id g9806P1H005894 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 7 Oct 2002 17:06:26 -0700 (PDT)?g (envelope-from sam@errno.com)œ X-Authentication-Warning: ebb.errno.com: Host melange.errno.com [66.127.85.82] claimed to be melange Message-ID: <18d301c26e5e$8b5c7a30$52557f42@errno.com> From: "Sam Leffler" To: "Julian Elischer" Cc: , References: Subject: Re: CFR: m_tag patch Date: Mon, 7 Oct 2002 17:06:25 -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 > On Mon, 7 Oct 2002, Sam Leffler wrote: > > > > If you allocate tag id's using your 32-bit time scheme then the fixed values > > above would never be hit since they are all for impossible times and so > > there'd be no conflict. > > Just make them all IDs in a single "Legacy" API > Good idea; I see the way out. Try this: struct m_tag { SLIST_ENTRY(m_tag) m_tag_link; /* List of packet tags */ u_int16_t m_tag_id; /* Tag ID */ u_int16_t m_tag_len; /* Length of data */ u_int32_t m_tag_cookie; /* Module/ABI */ }; Then define the "Legacy ABI" to be zero (or whatever you want). Then all the m_tag_* routines that I specified work only for the Legacy ABI. (Whether this is done with shims or whatever doesn't matter.) This gives me the compatiblity I want with openbsd and gives you the functionality you need for netgraph. For new work we can specify users should avoid the Legacy ABI. Cost is basically 4 bytes per tag and an extra compare when walking the tags. Happy? Sam To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 7 17:20:15 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B0D0037B408; Mon, 7 Oct 2002 17:20:10 -0700 (PDT) Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 00BAD43E75; Mon, 7 Oct 2002 17:20:10 -0700 (PDT) (envelope-from julian@elischer.org) 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 <20021008002009.TEYW27763.sccrmhc02.attbi.com@InterJet.elischer.org>; Tue, 8 Oct 2002 00:20:09 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id RAA36612; Mon, 7 Oct 2002 17:10:43 -0700 (PDT) Date: Mon, 7 Oct 2002 17:10:42 -0700 (PDT) From: Julian Elischer To: Sam Leffler Cc: freebsd-arch@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: CFR: m_tag patch In-Reply-To: <18d301c26e5e$8b5c7a30$52557f42@errno.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 Mon, 7 Oct 2002, Sam Leffler wrote: > > On Mon, 7 Oct 2002, Sam Leffler wrote: > > > > > > If you allocate tag id's using your 32-bit time scheme then the fixed > values > > > above would never be hit since they are all for impossible times and so > > > there'd be no conflict. > > > > Just make them all IDs in a single "Legacy" API > > > > Good idea; I see the way out. Try this: > > struct m_tag { > SLIST_ENTRY(m_tag) m_tag_link; /* List of packet tags */ > u_int16_t m_tag_id; /* Tag ID */ > u_int16_t m_tag_len; /* Length of data */ > u_int32_t m_tag_cookie; /* Module/ABI */ > }; > > Then define the "Legacy ABI" to be zero (or whatever you want). Then all > the m_tag_* routines that I specified work only for the Legacy ABI. > (Whether this is done with shims or whatever doesn't matter.) This gives me > the compatiblity I want with openbsd and gives you the functionality you > need for netgraph. For new work we can specify users should avoid the > Legacy ABI. > > Cost is basically 4 bytes per tag and an extra compare when walking the > tags. Happy? > definitly. Each API authout gets to polute his own namespace as much as he wants.. :-) > Sam > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 7 17:20:21 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5800B37B401; Mon, 7 Oct 2002 17:20:19 -0700 (PDT) Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6D7A143E3B; Mon, 7 Oct 2002 17:20:18 -0700 (PDT) (envelope-from julian@elischer.org) 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 <20021008002017.TFCJ27763.sccrmhc02.attbi.com@InterJet.elischer.org>; Tue, 8 Oct 2002 00:20: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 RAA36615; Mon, 7 Oct 2002 17:14:29 -0700 (PDT) Date: Mon, 7 Oct 2002 17:14:29 -0700 (PDT) From: Julian Elischer To: Luigi Rizzo Cc: Sam Leffler , freebsd-arch@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: CFR: m_tag patch 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, 7 Oct 2002, Julian Elischer wrote: > > > On Mon, 7 Oct 2002, Luigi Rizzo wrote: > > > the 16 vs. 32 bit > > On Mon, Oct 07, 2002 at 03:52:49PM -0700, Sam Leffler wrote: > > ... > > > Sounds to me like the real issue for you is insuring unique m_tag_id values. > > > We're certainly less likely to have collisions with a 32-bit value than a > > > 16-bit value and expanding this way gives you your "field ID" too. I guess > > > the question I have is whether the existing API's that search only by > > > "cookie" are sufficient for your needs. If so then I'm ok with changing > > > things. Otherwise we have an API incompatibility with openbsd that I'd like > > > to avoid. > > > > i wonder what do we gain by moving to 32 bit m_tag_id -- because there is > > is still no strict guarantee that we have no conflicts > > if people randomly choose "cookies", and also, using the same reasoning > > for allocations one could argue that having the cookie chosen as the number > > of _days_ since the epoch, will still give low conflict probability while > > still fitting in 16 bits. > > Also, those modules that require one or a very small number of different > > annotations (e.g. all the ones currently using m_tags) would just need > > the "cookie", whereas others with a large set of subfields could as well > > consider the field_id as part of the opaque data. > > > In my usage, the API id also includes other parts of the API, not just > packet metadata. > I use teh same cookie to define control command messags within > netgraph. In fact the control messages currently FAR exceed the > metadata types. > > At this moment there are about 37 APIS defined in netgraph and > they implement about 150 different control messages > > there are only 2 metadata types in use. > > (priority and "dropability") I lie.. there is a bandwidteh manager written in netgraph that uses metadata to hold the queueing and packet category info. so there are maybe 2 more types defined in their own API. > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" 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 Mon Oct 7 17:34:34 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2E49337B401; Mon, 7 Oct 2002 17:34:32 -0700 (PDT) Received: from pintail.mail.pas.earthlink.net (pintail.mail.pas.earthlink.net [207.217.120.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id B9A1C43E6E; Mon, 7 Oct 2002 17:34:31 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0113.cvx22-bradley.dialup.earthlink.net ([209.179.198.113] helo=mindspring.com) by pintail.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17yiKN-00065C-00; Mon, 07 Oct 2002 17:34:24 -0700 Message-ID: <3DA2278A.A1A33A02@mindspring.com> Date: Mon, 07 Oct 2002 17:32:10 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: Sam Leffler , freebsd-arch@freebsd.org, freebsd-net@freebsd.org Subject: Re: CFR: m_tag patch References: 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 Julian Elischer wrote: > > This is insufficient for Alpha and other 64 bit architectures. I > > think what you are asking for is really a 'void *'. > > IT IS NOT A POINTER! > > it is a 32 bit unsigned number. OK, I give up. Why is 2^32 possibilities better than 2^16th possibilities? You have > 65536 different chunks of metadata you need to deal with? > > The other issue here is that your idea of an opaque API/ABI indicator > > is in conflict, unless you say that this is a pointer, and then format > > the initial information pointed to by the pointer. Otherwise, you > > will need a small indirection structure that's pointed to the pointer, > > AND which contains the API/ABI identifier (i.e. you will need two, not > > one piece of information for that -- which is what you show, but not > > what you describe in your text). > > it is not used to look up anything.. > it is used to verify only. > > it is just working on the principal that there is not going to be > a collision in the 32 bit space. Especially when we create them from > "time since the epoch", and when teh various authors can see each > other's choices of value. I don't buy this. At this point, you are arguing statistical protection, and you are talking about a difference in collision probability, not collision avoidance. If 16 is bad, and 32 is good, then 64 is better. If 64 is "way too big", then 16 vs. 32 is just a matter of opinion, nothing else. > > This is moderately bogus. > > no it is not. > > I estimate that the chance of having a collision given all the > factors is 1:2^50 or so ASSUMING THAT 1000000 PEOPLE DEVELOP THEIR OWN > MODULES AND DO NOT CHECK THEM IN BUT DO ALL SHARE THEM WITH EACH OTHER. That assumes that the numbers people pick are actually random; they won't be. The way to handle this is to ask the kernel for a unique number for use in the registration process. > > Specifically, if you are going to register in new types without an > > assigned numbers authority (e.g. if I have a vendor private extension, > > which I wish to implement, yet not have collide with someone else's > > vendor private extension or a future FreeBSD "standard extension"), > > then you need to implement a registration interface for named > > registration, and use *that*. > > Terry if you like your chances of developing a module within the next > 100 years in exactly the same moment to the second that someone else > does so, and neither of you checks in that module, and your modules > have to co-exist, and you don't TALK to each other, then I have some > used lottery tickets I an sell you.. So it's a timestamp? You didn't say that it was a 32 bit time counter, so that simultaneuity was a requirement for a collision. > > I think it has to. The reason he has this is pretty clear from > > his crypto work, and the reason for the linked list is to, in the > > limit, allow a linear traversal of the list elements to find data > > that's relevent to you. > > Read what he said Terry.. for gods sake. He said that there are usually > < 2 metadata elements each being a few bytes long.. You keep avoiding his reason for the linked list, Julian. > > It's kind of ugly, but "anything that works is better than anything > > that doesn't"... it at least guarantees that it *can* work. > > there is more than one way to skin a cat. the fact that it is a linked > list doesn't mean it has to be a linked list. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 7 17:40: 8 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AA4F537B401; Mon, 7 Oct 2002 17:40:07 -0700 (PDT) Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F27C43E4A; Mon, 7 Oct 2002 17:40:07 -0700 (PDT) (envelope-from julian@elischer.org) 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 <20021008004007.IDKW17535.rwcrmhc51.attbi.com@InterJet.elischer.org>; Tue, 8 Oct 2002 00:40:07 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id RAA36685; Mon, 7 Oct 2002 17:24:15 -0700 (PDT) Date: Mon, 7 Oct 2002 17:24:14 -0700 (PDT) From: Julian Elischer To: Sam Leffler Cc: freebsd-arch@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: CFR: m_tag patch 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, 7 Oct 2002, Julian Elischer wrote: > definitly. > Each API authout gets to polute his own namespace as much as he author > wants.. :-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 7 17:50:31 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9DFA137B401; Mon, 7 Oct 2002 17:50:29 -0700 (PDT) Received: from harrier.mail.pas.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3442B43E6A; Mon, 7 Oct 2002 17:50:29 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0113.cvx22-bradley.dialup.earthlink.net ([209.179.198.113] helo=mindspring.com) by harrier.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17yiZs-000018-00; Mon, 07 Oct 2002 17:50:24 -0700 Message-ID: <3DA22B42.FBB6ECBF@mindspring.com> Date: Mon, 07 Oct 2002 17:48:02 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Luigi Rizzo Cc: Sam Leffler , Julian Elischer , freebsd-arch@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: CFR: m_tag patch References: <185201c26e54$43339f40$52557f42@errno.com> <20021007163101.A27463@carp.icir.org> 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 Luigi Rizzo wrote: > i wonder what do we gain by moving to 32 bit m_tag_id -- because there is > is still no strict guarantee that we have no conflicts > if people randomly choose "cookies", and also, using the same reasoning > for allocations one could argue that having the cookie chosen as the number > of _days_ since the epoch, will still give low conflict probability while > still fitting in 16 bits. Julian wants to use "32 bit seconds since epoch" as the "random" value, and then rely on statistical protection. This wasn't clear to me, either. It depends on knowing netgraph developement well enough, and following the recommended approach well enough that you use the seconds-since-epoch method of obtaining interface IDs. > Also, those modules that require one or a very small number of different > annotations (e.g. all the ones currently using m_tags) would just need > the "cookie", whereas others with a large set of subfields could as well > consider the field_id as part of the opaque data. That's why I suggested a void *, and that it would not be good enough for 64 bit machines. If everyone followed the seconds-since-epoch assignment methodology, though, Julian's approach would provide statistical protection (I worry about "the birthday paradox" making the likelihood much higher; for example, I'd expect the space to be smaller almost instantly, due to time zones...). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 7 18:19:16 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E09B237B401 for ; Mon, 7 Oct 2002 18:19:14 -0700 (PDT) Received: from tomts8-srv.bellnexxia.net (tomts8.bellnexxia.net [209.226.175.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id D738543E86 for ; Mon, 7 Oct 2002 18:19:13 -0700 (PDT) (envelope-from j.telford@sympatico.ca) Received: from johnny2k ([64.229.244.42]) by tomts8-srv.bellnexxia.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with SMTP id <20021008011913.CFTK9131.tomts8-srv.bellnexxia.net@johnny2k>; Mon, 7 Oct 2002 21:19:13 -0400 Message-ID: <000801c26e69$3b88d5c0$0a00000a@johnny2k> From: "John" To: "alexis georges" , References: Subject: Re: Sympatico ADSL connection through a hub Date: Mon, 7 Oct 2002 21:22:56 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.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 Try these links: http://free.mine.nu/~squirrel/PPPoE/FreeBSD%20PPPoE%20Howto.htm http://www.freebsddiary.org/pppoe.php http://renaud.waldura.com/doc/freebsd/pppoe/ JT. ----- Original Message ----- From: "alexis georges" To: Sent: Monday, October 07, 2002 12:55 PM Subject: Sympatico ADSL connection through a hub > Hello, > This is my first message posted to the list..hehehe > anyways, i used to have a simple cable connection, which would be > automatically comfigured by FreeBSD upon installation..I just moved and now > we have an ADSL connection (from Sympatico).. The connection is not > configured automatically..so i looked on the web for a solution. I found a > few pages explaining that i had to recompile my kernel with a few lines such > as 'options NETGRAPH'..and that i had to write some info into the ppp.conf > file..i did those things but apparently it doesn't work..I am not sure how > to work this out..cuz all the solutions i found were the same.. > So i will explain exactly how i am connected to the internet.. > > 1. I have an ethernet card connected to a hub. > 2. This hub is itself connected to the actual modem that we received from > Sympatico. > > On Windowsl, the conection wont work unless the connection type is set to > 10Mb Half-Duplex..so i am guessing it should be the same on FreeBSD.. > also, the address is supposed to be obtained dynamically..(on windows it > says the address has been obtrained by DHCP, however, during FreeBSD > installation, it fails to find the parameter for the connection)does that > mean that instead of the 10.0.0.1 address teh solution form the web gave me, > i should put the address that i am using on windows (even though it shouild > be a dynamic address?) > Anyways, i would really like to be able to fix this..if anyone could help, > that would be great..i wanna get rid of windows > > Thank You > Alexis > > _________________________________________________________________ > Chat with friends online, try MSN Messenger: http://messenger.msn.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 Mon Oct 7 22:43: 7 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 43FD937B404 for ; Mon, 7 Oct 2002 22:43:05 -0700 (PDT) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id AA46843E8A for ; Mon, 7 Oct 2002 22:43:04 -0700 (PDT) (envelope-from nate@rootlabs.com) Received: (qmail 9484 invoked by uid 1000); 8 Oct 2002 05:43:06 -0000 Date: Mon, 7 Oct 2002 22:43:06 -0700 (PDT) From: Nate Lawson To: Julian Elischer Cc: Terry Lambert , Sam Leffler , freebsd-arch@freebsd.org, freebsd-net@freebsd.org Subject: Re: CFR: m_tag patch 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, 7 Oct 2002, Julian Elischer wrote: > On Mon, 7 Oct 2002, Terry Lambert wrote: > > On Mon, 7 Oct 2002, Julian Elischer wrote: > > > Your tags have a single 16 bit tag ID field. > > > This is insufficient for my needs. > > > I need to be able to store the API cookie which is a 32 bit > > > unsigned number, and on top of that, I also need a 16 bit type field > > > that specifies what the data is within teh given API and a 16 bit > > > length to allow opaque handling. > > > > This is insufficient for Alpha and other 64 bit architectures. I > > think what you are asking for is really a 'void *'. > > IT IS NOT A POINTER! > > it is a 32 bit unsigned number. Ok. > > The other issue here is that your idea of an opaque API/ABI indicator > > is in conflict, unless you say that this is a pointer, and then format > > the initial information pointed to by the pointer. Otherwise, you > > will need a small indirection structure that's pointed to the pointer, > > AND which contains the API/ABI identifier (i.e. you will need two, not > > one piece of information for that -- which is what you show, but not > > what you describe in your text). > > it is not used to look up anything.. > it is used to verify only. > > it is just working on the principal that there is not going to be > a collision in the 32 bit space. Especially when we create them from > "time since the epoch", and when teh various authors can see each > other's choices of value. There are deterministic ways to generate them. 1. A counter -- gettag() { return tag++; } 2. A LCRG -- gettag() { return (A * tag) % n; } 3. A global registry -- "Hey, gimme a major" There are non-deterministic ways as well, i.e. hash functions and PRNGs. And if code can run faster than a given time source, the output of that source or permutation thereof can produce collisions. What leads you towards the time-based option vs. the others, especially the deterministic ones? > > This is moderately bogus. > > no it is not. > > I estimate that the chance of having a collision given all the > factors is 1:2^50 or so ASSUMING THAT 1000000 PEOPLE DEVELOP THEIR OWN > MODULES AND DO NOT CHECK THEM IN BUT DO ALL SHARE THEM WITH EACH OTHER. Hmmm, if they choose them at random, the chance of a collision is sqrt(n) or 1/(2^16). If they choose them perfectly coordinated, the chance is 1/(2^32). Much less than 2^50. -Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 7 23: 7:17 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 19AEF37B401; Mon, 7 Oct 2002 23:07:16 -0700 (PDT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 99E4B43E6E; Mon, 7 Oct 2002 23:07:15 -0700 (PDT) (envelope-from dl-freebsd@catspoiler.org) Received: from mousie.catspoiler.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.5/8.12.5) with ESMTP id g9866OvU034411; Mon, 7 Oct 2002 23:06:28 -0700 (PDT) (envelope-from dl-freebsd@catspoiler.org) Message-Id: <200210080606.g9866OvU034411@gw.catspoiler.org> Date: Mon, 7 Oct 2002 23:06:24 -0700 (PDT) From: Don Lewis Subject: Re: CFR: m_tag patch To: nate@root.org Cc: julian@elischer.org, tlambert2@mindspring.com, sam@errno.com, freebsd-arch@FreeBSD.ORG, freebsd-net@FreeBSD.ORG In-Reply-To: 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 7 Oct, Nate Lawson wrote: > On Mon, 7 Oct 2002, Julian Elischer wrote: >> it is just working on the principal that there is not going to be >> a collision in the 32 bit space. Especially when we create them from >> "time since the epoch", and when teh various authors can see each >> other's choices of value. > > There are deterministic ways to generate them. > 1. A counter -- gettag() { return tag++; } > 2. A LCRG -- gettag() { return (A * tag) % n; } > 3. A global registry -- "Hey, gimme a major" > > There are non-deterministic ways as well, i.e. hash functions and > PRNGs. And if code can run faster than a given time source, the output of > that source or permutation thereof can produce collisions. > > What leads you towards the time-based option vs. the others, especially > the deterministic ones? Why not name them? At boot or module load time stuff the name in a table and use the table index as the 16 bit ID. Is there any reason the ID has to be the same each time the system is booted? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 7 23:40:12 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AAD8437B401; Mon, 7 Oct 2002 23:40:09 -0700 (PDT) Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 48E6343E75; Mon, 7 Oct 2002 23:40:09 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20021008064008.CZCQ18767.rwcrmhc53.attbi.com@InterJet.elischer.org>; Tue, 8 Oct 2002 06:40: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 XAA38152; Mon, 7 Oct 2002 23:28:30 -0700 (PDT) Date: Mon, 7 Oct 2002 23:28:29 -0700 (PDT) From: Julian Elischer To: Nate Lawson Cc: Terry Lambert , Sam Leffler , freebsd-arch@freebsd.org, freebsd-net@freebsd.org Subject: Re: CFR: m_tag patch 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, 7 Oct 2002, Nate Lawson wrote: > On Mon, 7 Oct 2002, Julian Elischer wrote: > > On Mon, 7 Oct 2002, Terry Lambert wrote: > > > On Mon, 7 Oct 2002, Julian Elischer wrote: > > > > Your tags have a single 16 bit tag ID field. > > > > This is insufficient for my needs. > > > > I need to be able to store the API cookie which is a 32 bit > > > > unsigned number, and on top of that, I also need a 16 bit type field > > > > that specifies what the data is within teh given API and a 16 bit > > > > length to allow opaque handling. > > > > > > This is insufficient for Alpha and other 64 bit architectures. I > > > think what you are asking for is really a 'void *'. > > > > IT IS NOT A POINTER! > > > > it is a 32 bit unsigned number. > > Ok. > > > > The other issue here is that your idea of an opaque API/ABI indicator > > > is in conflict, unless you say that this is a pointer, and then format > > > the initial information pointed to by the pointer. Otherwise, you > > > will need a small indirection structure that's pointed to the pointer, > > > AND which contains the API/ABI identifier (i.e. you will need two, not > > > one piece of information for that -- which is what you show, but not > > > what you describe in your text). > > > > it is not used to look up anything.. > > it is used to verify only. > > > > it is just working on the principal that there is not going to be > > a collision in the 32 bit space. Especially when we create them from > > "time since the epoch", and when teh various authors can see each > > other's choices of value. > > There are deterministic ways to generate them. > 1. A counter -- gettag() { return tag++; } > 2. A LCRG -- gettag() { return (A * tag) % n; } > 3. A global registry -- "Hey, gimme a major" > > There are non-deterministic ways as well, i.e. hash functions and > PRNGs. And if code can run faster than a given time source, the output of > that source or permutation thereof can produce collisions. > > What leads you towards the time-based option vs. the others, especially > the deterministic ones? > > > > This is moderately bogus. > > > > no it is not. > > > > I estimate that the chance of having a collision given all the > > factors is 1:2^50 or so ASSUMING THAT 1000000 PEOPLE DEVELOP THEIR OWN > > MODULES AND DO NOT CHECK THEM IN BUT DO ALL SHARE THEM WITH EACH OTHER. > > Hmmm, if they choose them at random, the chance of a collision is > sqrt(n) or 1/(2^16). If they choose them perfectly coordinated, the > chance is 1/(2^32). Much less than 2^50. Nate, what is the chance you will load 1 million netgraph node types? If you load 3, what is the chance they were all non-checked in nodes and the authors weren't communicating, and you are the first person to ever combine them? now multiply That by 2^32 down 2 > > -Nate > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" 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 Mon Oct 7 23:40:22 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2E7BA37B407; Mon, 7 Oct 2002 23:40:20 -0700 (PDT) Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD31E43E42; Mon, 7 Oct 2002 23:40:19 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20021008064019.CZES18767.rwcrmhc53.attbi.com@InterJet.elischer.org>; Tue, 8 Oct 2002 06:40: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 XAA38161; Mon, 7 Oct 2002 23:33:21 -0700 (PDT) Date: Mon, 7 Oct 2002 23:33:20 -0700 (PDT) From: Julian Elischer To: Don Lewis Cc: nate@root.org, tlambert2@mindspring.com, sam@errno.com, freebsd-arch@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: CFR: m_tag patch In-Reply-To: <200210080606.g9866OvU034411@gw.catspoiler.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 Mon, 7 Oct 2002, Don Lewis wrote: > On 7 Oct, Nate Lawson wrote: > > On Mon, 7 Oct 2002, Julian Elischer wrote: > > >> it is just working on the principal that there is not going to be > >> a collision in the 32 bit space. Especially when we create them from > >> "time since the epoch", and when teh various authors can see each > >> other's choices of value. > > > > There are deterministic ways to generate them. > > 1. A counter -- gettag() { return tag++; } > > 2. A LCRG -- gettag() { return (A * tag) % n; } > > 3. A global registry -- "Hey, gimme a major" > > > > There are non-deterministic ways as well, i.e. hash functions and > > PRNGs. And if code can run faster than a given time source, the output of > > that source or permutation thereof can produce collisions. > > > > What leads you towards the time-based option vs. the others, especially > > the deterministic ones? > > Why not name them? At boot or module load time stuff the name in a > table and use the table index as the 16 bit ID. Is there any reason the > ID has to be the same each time the system is booted? I want to be able to specify an OLD API and the NEW version if I can only get a particular node in object form, and I knowi uses the old version, and some other code I have uses the new version, and I need them to co-exist. one binary sync driver and one opensource drive,, running 2 sync cards, both feeding into the "framerealy" code. All the "perfect" methods are more work than this really requires sonce I'm pretty sure that a collision will not occur in the lifetime of this civilisation. > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 8 0: 0:23 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A767537B404 for ; Tue, 8 Oct 2002 00:00:18 -0700 (PDT) Received: from jive.SoftHome.net (jive.SoftHome.net [66.54.152.27]) by mx1.FreeBSD.org (Postfix) with SMTP id 2B75543E65 for ; Tue, 8 Oct 2002 00:00:18 -0700 (PDT) (envelope-from ertank@softhome.net) Received: (qmail 20256 invoked by uid 417); 8 Oct 2002 07:00:12 -0000 Received: from slide-.softhome.net (HELO softhome.net) (172.16.2.21) by shunt-smtp-out-0 with SMTP; 8 Oct 2002 07:00:12 -0000 Received: from localhost (localhost [127.0.0.1]) (uid 417) by softhome.net with local; Tue, 08 Oct 2002 01:00:12 -0600 From: ertank@softhome.net To: freebsd-net@freebsd.org Subject: xl driver Date: Tue, 08 Oct 2002 01:00:12 -0600 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Sender: ertank@softhome.net X-Originating-IP: [212.252.6.206] Message-ID: 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 problem with xl driver under FreeBSD 4.6-STABLE system. I have 3com905b ethernet cards, one 3com980 server ethernet card. But, I see that they serve better under Windows systems. After I dig it deeper. I found that during transfers there are a lot of bad chksum messages. Here is a sample output from tcpdump (this is dump of an ftp upload): 15:45:04.988831 ozlerplastik.com.telnet > ertank.3831: P [bad tcp cksum 11f3!] 1553949763:1553949790(27) ack 98368834 win 65535 (DF) [tos 0x10] (ttl 64, id 49509, len 67, bad cksum 0!) 15:45:05.123889 ertank.3831 > ozlerplastik.com.telnet: . [tcp sum ok] 1:1(0) ack 27 win 64879 (DF) (ttl 128, id 33512, len 40) 15:45:06.626997 arp who-has ozlerplastik.com tell ertank 15:45:06.627057 arp reply ozlerplastik.com is-at 0:10:5a:66:a5:d1 15:45:06.627198 ertank.4978 > ozlerplastik.com.ftp: S [tcp sum ok] 102004865:102004865(0) win 65535 (DF) (ttl 128, id 33768, len 48) 15:45:06.627353 ozlerplastik.com.ftp > ertank.4978: S [bad tcp cksum 6fa1!] 2992942906:2992942906(0) ack 102004866 win 65535 (ttl 64, id 49515, len 44, bad cksum 0!) 15:45:06.627494 ertank.4978 > ozlerplastik.com.ftp: . [tcp sum ok] 1:1(0) ack 1 win 65535 (DF) (ttl 128, id 34024, len 40) 15:45:06.661066 ozlerplastik.com.ftp > ertank.4978: P 1:52(51) ack 1 win 65535 (DF) (ttl 64, id 49516, len 91, bad cksum 0!) 15:45:06.858553 ertank.4978 > ozlerplastik.com.ftp: . [tcp sum ok] 1:1(0) ack 52 win 65484 (DF) (ttl 128, id 34280, len 40) 15:45:07.213749 4c574182.00:50:8b:8b:9f:f3.9001 > 0.ff:ff:ff:ff:ff:ff.9001: ipx-#9001 43 15:45:08.075575 ertank.4978 > ozlerplastik.com.ftp: P [tcp sum ok] 1:11(10) ack 52 win 65484 (DF) (ttl 128, id 34536, len 50) 15:45:08.076087 ozlerplastik.com.ftp > ertank.4978: P [bad tcp cksum 8671!] 52:86(34) ack 11 win 65535 (DF) (ttl 64, id 49522, len 74, bad cksum 0!) 15:45:08.182450 ertank.4978 > ozlerplastik.com.ftp: . [tcp sum ok] 11:11(0) ack 86 win 65450 (DF) (ttl 128, id 34792, len 40) 15:45:08.806742 11aec257.00:50:8b:8b:9f:f3.9001 > 0.ff:ff:ff:ff:ff:ff.9001: ipx-#9001 43 I have a Novell server, AS/400 server and a FreBSD server network. ipx packets are because of Novell Netware 4.11. After I change xl with a 10mbit traditional ne2000 compatible card these bad chksum messages are gone. I tried my card with another main board the problem same. With different cabling, with different FreeBSD version nothing changes. Performance is not as it should be. So, I bought an intel pro/100 card. There is no errors with this card. It seems that card is performing OK during ftp downloads (sometimes 6.5mb/sec). It is very bad during ftp uploads (about 45kb/sec). Although ftp downloads are fast. There is bad chksum messages during downloads, too. All I think is a driver problem now. What can I do to test and give more information to you? Best Regards, -- Ertan Küçükoglu ertank@softhome.net P.S. If this is not the correct list please inform. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 8 0:43:50 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A446E37B401; Tue, 8 Oct 2002 00:43:49 -0700 (PDT) Received: from avocet.mail.pas.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id B5F8343E8A; Tue, 8 Oct 2002 00:43:45 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0058.cvx21-bradley.dialup.earthlink.net ([209.179.192.58] helo=mindspring.com) by avocet.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17yp1o-0004mR-00; Tue, 08 Oct 2002 00:43:40 -0700 Message-ID: <3DA28C65.DEA3E379@mindspring.com> Date: Tue, 08 Oct 2002 00:42:29 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Don Lewis Cc: nate@root.org, julian@elischer.org, sam@errno.com, freebsd-arch@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: CFR: m_tag patch References: <200210080606.g9866OvU034411@gw.catspoiler.org> 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 Don Lewis wrote: > Why not name them? At boot or module load time stuff the name in a > table and use the table index as the 16 bit ID. Is there any reason the > ID has to be the same each time the system is booted? That was my suggestion. I stopped short of calling it XInternAtom()... -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 8 0:55: 8 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 288C237B401; Tue, 8 Oct 2002 00:55:05 -0700 (PDT) Received: from gull.mail.pas.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id B6EF443E77; Tue, 8 Oct 2002 00:55:04 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0058.cvx21-bradley.dialup.earthlink.net ([209.179.192.58] helo=mindspring.com) by gull.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17ypCi-0004Yb-00; Tue, 08 Oct 2002 00:54:56 -0700 Message-ID: <3DA28F08.658274C3@mindspring.com> Date: Tue, 08 Oct 2002 00:53:44 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: Don Lewis , nate@root.org, sam@errno.com, freebsd-arch@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: CFR: m_tag patch References: 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 Julian Elischer wrote: > > Why not name them? At boot or module load time stuff the name in a > > table and use the table index as the 16 bit ID. Is there any reason the > > ID has to be the same each time the system is booted? > > I want to be able to specify an OLD API and the NEW version > if I can only get a particular node in object form, and I knowi uses the > old version, and some other code I have uses the new version, > and I need them to co-exist. > > one binary sync driver and one opensource drive,, running 2 sync cards, > both feeding into the "framerealy" code. > > All the "perfect" methods are more work than this really requires sonce > I'm pretty sure that a collision will not occur in the lifetime of this > civilisation. I've often thought that an interning process for atoms was actually a good idea for the kernel. The place I first thought of using this approach is for FS ID's. As things currently sit, there are header files that need to be hacked to add new members to (theoretically) anonymous classes of objects. One of the most egregious files in this regard is vnode.h, for the enumerated type values in 'vtype' and in 'vtagtype'. As an example, copy the NULLFS code to "FOOFS" instead, do all the name replacement in it, and see what breaks and/or wht gets accounted incorrectly. 8-(. Among other things, if you could intern them, and then enumerate them, based on defined classes, you could get rid of things like the socket protocol family crap, and most of the places where you end up pushing strings in API's across the user/kernel boundary. IMO, most strings you push across should be considered const members of range restricted sets. This is happy, in that it would work for the netgraph API ID code, as well (you look up a value by looking up the atom in a class table to get an ID, and then pass the ID around. I think the ID should be opaque, but you could call it a 16 or 32 bit calue, if you wanted to insist that it not be a pointer. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 8 1:20:17 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B72D837B401; Tue, 8 Oct 2002 01:20:15 -0700 (PDT) Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 49CA943E4A; Tue, 8 Oct 2002 01:20:14 -0700 (PDT) (envelope-from brandt@fokus.gmd.de) Received: from beagle (beagle [193.175.132.100]) by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id g988Jqe07033; Tue, 8 Oct 2002 10:19:52 +0200 (MEST) Date: Tue, 8 Oct 2002 10:19:52 +0200 (CEST) From: Harti Brandt To: Don Lewis Cc: nate@root.org, , , , , Subject: Re: CFR: m_tag patch In-Reply-To: <200210080606.g9866OvU034411@gw.catspoiler.org> Message-ID: <20021008100826.H77302-100000@beagle.fokus.gmd.de> 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, 7 Oct 2002, Don Lewis wrote: DL>On 7 Oct, Nate Lawson wrote: DL>> On Mon, 7 Oct 2002, Julian Elischer wrote: DL> DL>>> it is just working on the principal that there is not going to be DL>>> a collision in the 32 bit space. Especially when we create them from DL>>> "time since the epoch", and when teh various authors can see each DL>>> other's choices of value. DL>> DL>> There are deterministic ways to generate them. DL>> 1. A counter -- gettag() { return tag++; } DL>> 2. A LCRG -- gettag() { return (A * tag) % n; } DL>> 3. A global registry -- "Hey, gimme a major" DL>> DL>> There are non-deterministic ways as well, i.e. hash functions and DL>> PRNGs. And if code can run faster than a given time source, the output of DL>> that source or permutation thereof can produce collisions. DL>> DL>> What leads you towards the time-based option vs. the others, especially DL>> the deterministic ones? DL> DL>Why not name them? At boot or module load time stuff the name in a DL>table and use the table index as the 16 bit ID. Is there any reason the DL>ID has to be the same each time the system is booted? Well, the point is that you need a common name between netgraph nodes and their controling application. As it is now this common name is the 32-bit cookie generated by issuing "date -u +'%s'" (so no timezone problem here). I have, for example, an user space ILMI daemon for ATM. This daemon needs to talk to the call control netgraph node. To do this the header file for the call control node contains #define NGM_CCATM_COOKIE 984046139 both, the netgraph node and the daemon include this file and the daemon addresses messages to the node by filling in the cookie into the appropriate field in the message. The node filters out the messages by compare the cookie field with the above cookie. If you use a dynamically generated cookie (be it a ++tags or a hash over a string or the address of a kernel structure) both the user space application and the node would need to call the code that generates these cookies with just another cookie (for example a string). So what you would do is to replace the 32-bit cookie with, for example, a string cookie. The question is, would a string cookie reduce the probability of conflicts on cookies? This question is rather hard to answer, because on one hand strings may contain more bits, but people would try to use descriptive and short cookie. I see a very high probability of two people that develop a ppp node to use the same string "ppp". This would be bad, because the actual API they implement would for sure be different. With the above method to choose the 32-bit cookie, this wouldn't happen. Given that the netgraph-hype is not of the dimensions of the Java-hype two people starting to develop netgraph node at the same moment of UTC is rather improbable. The only option that would make sense would be a assigned numbers authority, but again, given the dimensions of the netgraph-hype - is it worth the effort? harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.gmd.de, brandt@fokus.fhg.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 8 7:53:51 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9816B37B401 for ; Tue, 8 Oct 2002 07:53:47 -0700 (PDT) Received: from hotmail.com (oe20.law14.hotmail.com [64.4.20.124]) by mx1.FreeBSD.org (Postfix) with ESMTP id 361DC43E4A for ; Tue, 8 Oct 2002 07:53:47 -0700 (PDT) (envelope-from floating_in_space_@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 8 Oct 2002 07:53:46 -0700 X-Originating-IP: [65.92.205.16] From: "Alexis Georges" To: "Damian Gerow" , References: <128392217879.20021008083050@sentex.net> Subject: Re: Sympatico ADSL connection through a hub Date: Tue, 8 Oct 2002 07:53:18 -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 Message-ID: X-OriginalArrivalTime: 08 Oct 2002 14:53:46.0934 (UTC) FILETIME=[81333D60:01C26EDA] 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 for helping damian..i did everything you gave me but it still doesn't seem to work.. here is what i have after doing everything, and typing ifconfig dc0: flags:88c3 mtu 1500 inet6 fe80::2a0:ccff::fee1: 8be5%dc0 prefixlen 64 scopeid 0x1 inet 10.0.1 netmask 0xfffffffc broadcast 10.0.0.3 ether 00:a0:cc:e1:8be5 media: Ethernet 10baseT/UTP status: active tun0: flags=8051 mtu 1500 inet6 fe80:2a0:ccff:fee1: 8be5%tun0 prefixlen 64 scopeid 0x7 opened by PID 54 thats all i get..shouldn't i have an IP address somewhere other than the 10.0.0.1..on windows i used to have 192.168.0.110(it will change since its dynamic) , but it only shows the 10.0.0.1 one..on another computer in the same home network, i got this info: netmask = 255.255.255.0 default gateway = 192.168.0.1 DNS server = 198.235.216.114 and 207.236.176.12 to see if it had worked i tried pinging an address of another computer on the network and it just froze at the first "ping
blahblah 56" (something like taht).. what wrong? thanks again alexis ----- Original Message ----- From: "Damian Gerow" To: "alexis georges" Sent: Tuesday, October 08, 2002 5:30 AM Subject: Re: Sympatico ADSL connection through a hub > Spake alexis georges on 07/10/2002, 16:55:16 +0000: > > This is my first message posted to the list..hehehe > > anyways, i used to have a simple cable connection, which would be > > automatically comfigured by FreeBSD upon installation..I just moved and now > > we have an ADSL connection (from Sympatico).. The connection is not > > configured automatically..so i looked on the web for a solution. I found a > > few pages explaining that i had to recompile my kernel with a few lines such > > as 'options NETGRAPH'..and that i had to write some info into the ppp.conf > > file..i did those things but apparently it doesn't work..I am not sure how > > to work this out..cuz all the solutions i found were the same.. > > So i will explain exactly how i am connected to the internet.. > > > 1. I have an ethernet card connected to a hub. > > 2. This hub is itself connected to the actual modem that we received from > > Sympatico. > > > On Windowsl, the conection wont work unless the connection type is set to > > 10Mb Half-Duplex..so i am guessing it should be the same on FreeBSD.. > > also, the address is supposed to be obtained dynamically..(on windows it > > says the address has been obtrained by DHCP, however, during FreeBSD > > installation, it fails to find the parameter for the connection)does that > > mean that instead of the 10.0.0.1 address teh solution form the web gave me, > > i should put the address that i am using on windows (even though it shouild > > be a dynamic address?) > > Anyways, i would really like to be able to fix this..if anyone could help, > > that would be great..i wanna get rid of windows > > I work for a small ISP in Ontario, and while we don't offer service in > Quebec, and are in competition with Sympatico , here's what I've > done to get my machine up and running on an ADSL link: > > 1) Make sure these are in the kernel: > > pseudo-device tun > options NETGRAPH > options NETGRAPH_ASYNC > options NETGRAPH_ETHER > options NETGRAPH_IFACE > options NETGRAPH_KSOCKET > options NETGRAPH_PPPOE > options NETGRAPH_SOCKET > pseudo-device bpf # (I'm not sure this is needed, but > # it's nice to have.) > > As well as your normal networking code -- LIBMCHAIN if you want it, > RANDOM_IP_ID (really good idea to put in), and your devices. > > 2) Update your sources, build a new world and kernel. Install, > reboot. > 3) In /etc/ppp/ppp.conf, add a new section called 'pppoe' or 'adsl': > > pppoe: > set device PPPoE:rl0: > set speed sync > enable lqr > set lqrperiod 3 > set cd 5 > set dial > set login > set timeout 0 > set authname @sympatico.ca > set authkey > set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0 > add default HISADDR > disable dns > disable vjcomp > disable ipv6cp > > Note that with Sympatico, you *must* have 'disable vjcomp' in there. > You may want to disable lqr, as it sometimes causes problems with me. > Leave it on initially, see what happens. > > 4) Set the following in /etc/rc.conf: > > # (the -arp is not needed, and your media type may be different -- most > # modems use 10baseT for talking, so I've set mine to that. Looks > # like yours is the same way. > ifconfig_="inet 10.0.0.1 netmask 255.255.255.252 -arp media 10baseT/UTP up" > > ppp_enable="YES" > ppp_mode="ddial" > ppp_profile="pppoe" > ppp_nat="NO" > > And you're good to go. Make sure you reboot, and the link should come > up right away. > > The commandline to bring it up is: 'ppp -quiet -ddial pppoe'. This > will bring up a tun0 interface, that is connected to the internet. > Note that it's the *logical* *tun0* interface that is your gateway to > Sympatico (and the world!), *not* your physical external interface. > > As for the DHCP stuff -- your IP address is dynamically assigned via > PPP, not DHCP. You're talking PPPoE (PPP over Ethernet), not straight > Ethernet, to Sympatico, so DHCP won't work at all. > > Hope this helps... > > - Damian > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 8 10:12: 0 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9AD9337B404 for ; Tue, 8 Oct 2002 10:11:59 -0700 (PDT) Received: from tp.databus.com (p70-227.acedsl.com [66.114.70.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 10B5443E6A for ; Tue, 8 Oct 2002 10:11:59 -0700 (PDT) (envelope-from barney@tp.databus.com) Received: from tp.databus.com (localhost.databus.com [127.0.0.1]) by tp.databus.com (8.12.6/8.12.6) with ESMTP id g98HBu5S072349; Tue, 8 Oct 2002 13:11:56 -0400 (EDT) (envelope-from barney@tp.databus.com) Received: (from barney@localhost) by tp.databus.com (8.12.6/8.12.6/Submit) id g98HBtRA072348; Tue, 8 Oct 2002 13:11:55 -0400 (EDT) Date: Tue, 8 Oct 2002 13:11:55 -0400 From: Barney Wolff To: ertank@softhome.net Cc: freebsd-net@FreeBSD.ORG Subject: Re: xl driver Message-ID: <20021008171155.GA72292@tp.databus.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Scanned-By: MIMEDefang 2.21 (www . roaringpenguin . com / mimedefang) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org The "bad checksum" that you see in the tcpdump is not an error and has nothing to do with whatever problems you're having. The xl driver and cards have the ability to compute the checksum on the card, after tcpdump sees the packet. You'll notice that all of those messages are on packets you're sending, not receiving. Seriously asymmetric performance is often caused by duplex mismatch. Try forcing the card to half or full duplex with ifconfig, or in whatever switch you're using, and see if the problem goes away. -- Barney Wolff I'm available by contract or FT, in the NYC metro area or via the 'Net. http://www.databus.com/bwresume.pdf To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 8 11:25:46 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9842137B404 for ; Tue, 8 Oct 2002 11:25:44 -0700 (PDT) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id A1DBD43E9C for ; Tue, 8 Oct 2002 11:25:40 -0700 (PDT) (envelope-from nate@rootlabs.com) Received: (qmail 11393 invoked by uid 1000); 8 Oct 2002 18:25:41 -0000 Date: Tue, 8 Oct 2002 11:25:41 -0700 (PDT) From: Nate Lawson To: Terry Lambert Cc: freebsd-arch@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: CFR: m_tag patch In-Reply-To: <3DA28F08.658274C3@mindspring.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 Tue, 8 Oct 2002, Terry Lambert wrote: > I've often thought that an interning process for atoms was actually > a good idea for the kernel. > > The place I first thought of using this approach is for FS ID's. As > things currently sit, there are header files that need to be hacked > to add new members to (theoretically) anonymous classes of objects. > One of the most egregious files in this regard is vnode.h, for the > enumerated type values in 'vtype' and in 'vtagtype'. Well, I killed vtagtype in -current. > As an example, copy the NULLFS code to "FOOFS" instead, do all the > name replacement in it, and see what breaks and/or wht gets accounted > incorrectly. 8-(. > > Among other things, if you could intern them, and then enumerate them, > based on defined classes, you could get rid of things like the > socket protocol family crap, and most of the places where you end > up pushing strings in API's across the user/kernel boundary. IMO, > most strings you push across should be considered const members of > range restricted sets. > > This is happy, in that it would work for the netgraph API ID code, > as well (you look up a value by looking up the atom in a class > table to get an ID, and then pass the ID around. > > I think the ID should be opaque, but you could call it a 16 or 32 > bit calue, if you wanted to insist that it not be a pointer. I am really against using an extremely large space (32 bits) in a sparse manner just because the algorithm is non-deterministic. The only exception is when the system may be attacked (i.e. a cryptographic hash function). In this situation, all players are cooperating but may make mistakes or be lazy if the system is difficult. Whatever system is chosen, there is no reason to make the algorithm non-deterministic. -Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 8 12:17:12 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6ED6937B401 for ; Tue, 8 Oct 2002 12:17:10 -0700 (PDT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE1DB43E6E for ; Tue, 8 Oct 2002 12:17:09 -0700 (PDT) (envelope-from dl-freebsd@catspoiler.org) Received: from mousie.catspoiler.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.5/8.12.5) with ESMTP id g98JG2vU036242; Tue, 8 Oct 2002 12:16:07 -0700 (PDT) (envelope-from dl-freebsd@catspoiler.org) Message-Id: <200210081916.g98JG2vU036242@gw.catspoiler.org> Date: Tue, 8 Oct 2002 12:16:02 -0700 (PDT) From: Don Lewis Subject: Re: CFR: m_tag patch To: brandt@fokus.gmd.de Cc: nate@root.org, julian@elischer.org, tlambert2@mindspring.com, sam@errno.com, freebsd-arch@FreeBSD.ORG, freebsd-net@FreeBSD.ORG In-Reply-To: <20021008100826.H77302-100000@beagle.fokus.gmd.de> 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 8 Oct, Harti Brandt wrote: > On Mon, 7 Oct 2002, Don Lewis wrote: > DL>Why not name them? At boot or module load time stuff the name in a > DL>table and use the table index as the 16 bit ID. Is there any reason the > DL>ID has to be the same each time the system is booted? > > Well, the point is that you need a common name between netgraph nodes and > their controling application. As it is now this common name is the 32-bit > cookie generated by issuing "date -u +'%s'" (so no timezone problem here). > > I have, for example, an user space ILMI daemon for ATM. This daemon needs > to talk to the call control netgraph node. To do this the header file for > the call control node contains > > #define NGM_CCATM_COOKIE 984046139 > > both, the netgraph node and the daemon include this file and the daemon > addresses messages to the node by filling in the cookie into the > appropriate field in the message. The node filters out the messages by > compare the cookie field with the above cookie. In this implementation you also have to worry about collisions in the include file name, possibly the #define name, as well as the actual cookie. > If you use a dynamically generated cookie (be it a ++tags or a hash over a > string or the address of a kernel structure) both the user space > application and the node would need to call the code that generates these > cookies with just another cookie (for example a string). So what you would > do is to replace the 32-bit cookie with, for example, a string cookie. > > The question is, would a string cookie reduce the probability of conflicts > on cookies? This question is rather hard to answer, because on one hand > strings may contain more bits, but people would try to use descriptive and > short cookie. I see a very high probability of two people that develop a > ppp node to use the same string "ppp". This would be bad, because the > actual API they implement would for sure be different. With the above > method to choose the 32-bit cookie, this wouldn't happen. Given that the > netgraph-hype is not of the dimensions of the Java-hype two people > starting to develop netgraph node at the same moment of UTC is rather > improbable. Pick a convention for generating the string cookies: *printf(..., "netgraphid_%08x", 32bitnetgraphid) netgraph_brandt_ccatm_v1.234 netgraph_brandt_ccatm_`date -u` All of these allow different versions to simultaneously coexist. In the latter two examples if the API is rich enough and the proper naming convention is chosen, a client could even look to see if a "close enough" version is already installed. I see the problem of arranging the rendezvous between the user and kernel parts as totally separate from the tag that finally gets tacked onto each packet. The latter only has to be unique for the system uptime. > The only option that would make sense would be a assigned numbers > authority, but again, given the dimensions of the netgraph-hype - is it > worth the effort? If the proper naming convention is chosen, each author can have his own name space to play in, so no central authority is needed other than to allocate author names. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 8 13:12:17 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 66E4C37B401 for ; Tue, 8 Oct 2002 13:12:16 -0700 (PDT) Received: from dsf.dynas.se (dsf.dynas.se [192.71.43.66]) by mx1.FreeBSD.org (Postfix) with SMTP id 0CF7543E4A for ; Tue, 8 Oct 2002 13:12:15 -0700 (PDT) (envelope-from micke@dynas.se) Received: (qmail 98354 invoked from network); 8 Oct 2002 20:12:13 -0000 Received: from spirit.sto.dynas.se (HELO spirit.dynas.se) (172.16.1.10) by dsf.dynas.se with SMTP; 8 Oct 2002 20:12:13 -0000 Received: (qmail 26674 invoked by uid 1101); 8 Oct 2002 20:12:12 -0000 Date: Tue, 8 Oct 2002 22:12:12 +0200 (MET DST) From: Mikael Hybsch To: Subject: Problem with mpd / pptp link between FreeBSD and win98 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 I have a problem with mpd/ng_mppc. I'm trying to run a pptp link to secure the wireless traffic between my FreeBSD server/firewall and a win98 machine. I'm using 2 D-Link 520. The D-Link in the FreeBSD server is running in Host-AP mode. The wireless link itself works fine. The problem is that whenever I download a file to the win98 machine the pptp connection randomly freezes after a few megabytes and I get the message below in /var/log/messages. The number is always around 4000. After this I have to reconnect to continue. I have tried 40 and 128 bit encryption with the same result. Oct 7 21:30:56 snaps /kernel: ng_mppc_decompress: insane jump 4083 Does someone have any idea about this? === I just had a quick look at the code and some more debugging shows that the new sequence number is less than the current. Does this mean that mppc got fed an old packet? /kernel: ng_mppc_decompress: insane jump 4089: (1690-1697) & 0xfff On a related issue, there is a new l2tp netgraph module. Is there any work in progress to, for example, extend mpd to be able to act as a l2tp server? -- Mikael Hubsch Email: Mikael.Hubsch@tfstech.com TFS Technology AB Phone: +46-8-7259730 Box 10020 Fax: +46-8-6494970 S-121 26 STOCKHOLM, SWEDEN To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 8 18:26:24 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 29E9737B401; Tue, 8 Oct 2002 18:26:23 -0700 (PDT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id B189143E75; Tue, 8 Oct 2002 18:26:22 -0700 (PDT) (envelope-from sam@errno.com) Received: from melange (melange.errno.com [66.127.85.82]) (authenticated bits=0) by ebb.errno.com (8.12.5/8.12.1) with ESMTP id g991QC1H012001 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 8 Oct 2002 18:26:13 -0700 (PDT)?g (envelope-from sam@errno.com)œ X-Authentication-Warning: ebb.errno.com: Host melange.errno.com [66.127.85.82] claimed to be melange Message-ID: <1f3601c26f32$daf85170$52557f42@errno.com> From: "Sam Leffler" To: "SUZUKI Shinsuke" Cc: "Julian Elischer" , , , References: <13e901c26dbb$63059f60$52557f42@errno.com> Subject: Re: CFR: m_tag patch Date: Tue, 8 Oct 2002 18:26:12 -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 > But from the KAME maintenance point of view I request only one thing > regarding this. > > Please keep the m_tag design same as OpenBSD (i.e. I'd like to > avoid changes such as change of member name in m_tag > structure, behavior-change etc, to prevent inessential merging > effort among *BSDs) > > If this condition is accepted, then we have no problem in adopting > m_tag in FreeBSD-KAME. > (as far as I looked though, there is no necessity of such change in > m_tag architecture, but if you have some difficulties, please let me > know.) > It will be compatible at the source level. That was the intention from the start. Sam To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 8 18:29:13 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A1D3937B401 for ; Tue, 8 Oct 2002 18:29:08 -0700 (PDT) Received: from tomts22-srv.bellnexxia.net (tomts22.bellnexxia.net [209.226.175.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id 901F043E3B for ; Tue, 8 Oct 2002 18:29:07 -0700 (PDT) (envelope-from matt@gsicomp.on.ca) Received: from xena.gsicomp.on.ca ([65.95.181.173]) by tomts22-srv.bellnexxia.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with ESMTP id <20021009012757.MNYJ21742.tomts22-srv.bellnexxia.net@xena.gsicomp.on.ca>; Tue, 8 Oct 2002 21:27:57 -0400 Received: from hermes (hermes.gsicomp.on.ca [192.168.0.18]) by xena.gsicomp.on.ca (8.11.3/8.11.3) with SMTP id g9907vp33167; Tue, 8 Oct 2002 20:07:57 -0400 (EDT) (envelope-from matt@gsicomp.on.ca) Message-ID: <007a01c26f33$191a3b80$1200a8c0@gsicomp.on.ca> From: "Matthew Emmerton" To: "Alexis Georges" , References: <128392217879.20021008083050@sentex.net> Subject: Re: Sympatico ADSL connection through a hub Date: Tue, 8 Oct 2002 21:27:56 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In your /etc/rc.conf, are you setting an IP address for the dc0 interface? If you are, then PPPoE won't work properly since the interface is already up and running. Check for a line that looks like this: ifconfig_dc0="inet 10.0.0.1 netmask 0xfffffffc" If a line like this exists, comment it out (put a # sign in front of it) and then reboot. -- Matt ----- Original Message ----- From: "Alexis Georges" To: "Damian Gerow" ; Sent: Tuesday, October 08, 2002 10:53 AM Subject: Re: Sympatico ADSL connection through a hub > thanks for helping damian..i did everything you gave me but it still doesn't > seem to work.. > here is what i have after doing everything, and typing ifconfig > > dc0: flags:88c3 mtu 1500 > inet6 fe80::2a0:ccff::fee1: 8be5%dc0 prefixlen 64 scopeid 0x1 > inet 10.0.1 netmask 0xfffffffc broadcast 10.0.0.3 > ether 00:a0:cc:e1:8be5 > media: Ethernet 10baseT/UTP > status: active > tun0: flags=8051 mtu 1500 > inet6 fe80:2a0:ccff:fee1: 8be5%tun0 prefixlen 64 scopeid 0x7 > opened by PID 54 > > thats all i get..shouldn't i have an IP address somewhere other than the > 10.0.0.1..on windows i used to have 192.168.0.110(it will change since its > dynamic) , but it only shows the 10.0.0.1 one..on another computer in the > same home network, i got this info: > > netmask = 255.255.255.0 > default gateway = 192.168.0.1 > DNS server = 198.235.216.114 and 207.236.176.12 > > to see if it had worked i tried pinging an address of another computer on > the network and it just froze at the first "ping
blahblah 56" > (something like taht).. > what wrong? > thanks again > > alexis > ----- Original Message ----- > From: "Damian Gerow" > To: "alexis georges" > Sent: Tuesday, October 08, 2002 5:30 AM > Subject: Re: Sympatico ADSL connection through a hub > > > > Spake alexis georges on 07/10/2002, 16:55:16 +0000: > > > This is my first message posted to the list..hehehe > > > anyways, i used to have a simple cable connection, which would be > > > automatically comfigured by FreeBSD upon installation..I just moved and > now > > > we have an ADSL connection (from Sympatico).. The connection is not > > > configured automatically..so i looked on the web for a solution. I found > a > > > few pages explaining that i had to recompile my kernel with a few lines > such > > > as 'options NETGRAPH'..and that i had to write some info into the > ppp.conf > > > file..i did those things but apparently it doesn't work..I am not sure > how > > > to work this out..cuz all the solutions i found were the same.. > > > So i will explain exactly how i am connected to the internet.. > > > > > 1. I have an ethernet card connected to a hub. > > > 2. This hub is itself connected to the actual modem that we received > from > > > Sympatico. > > > > > On Windowsl, the conection wont work unless the connection type is set > to > > > 10Mb Half-Duplex..so i am guessing it should be the same on FreeBSD.. > > > also, the address is supposed to be obtained dynamically..(on windows it > > > says the address has been obtrained by DHCP, however, during FreeBSD > > > installation, it fails to find the parameter for the connection)does > that > > > mean that instead of the 10.0.0.1 address teh solution form the web gave > me, > > > i should put the address that i am using on windows (even though it > shouild > > > be a dynamic address?) > > > Anyways, i would really like to be able to fix this..if anyone could > help, > > > that would be great..i wanna get rid of windows > > > > I work for a small ISP in Ontario, and while we don't offer service in > > Quebec, and are in competition with Sympatico , here's what I've > > done to get my machine up and running on an ADSL link: > > > > 1) Make sure these are in the kernel: > > > > pseudo-device tun > > options NETGRAPH > > options NETGRAPH_ASYNC > > options NETGRAPH_ETHER > > options NETGRAPH_IFACE > > options NETGRAPH_KSOCKET > > options NETGRAPH_PPPOE > > options NETGRAPH_SOCKET > > pseudo-device bpf # (I'm not sure this is needed, but > > # it's nice to have.) > > > > As well as your normal networking code -- LIBMCHAIN if you want it, > > RANDOM_IP_ID (really good idea to put in), and your devices. > > > > 2) Update your sources, build a new world and kernel. Install, > > reboot. > > 3) In /etc/ppp/ppp.conf, add a new section called 'pppoe' or 'adsl': > > > > pppoe: > > set device PPPoE:rl0: > > set speed sync > > enable lqr > > set lqrperiod 3 > > set cd 5 > > set dial > > set login > > set timeout 0 > > set authname @sympatico.ca > > set authkey > > set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0 > > add default HISADDR > > disable dns > > disable vjcomp > > disable ipv6cp > > > > Note that with Sympatico, you *must* have 'disable vjcomp' in there. > > You may want to disable lqr, as it sometimes causes problems with me. > > Leave it on initially, see what happens. > > > > 4) Set the following in /etc/rc.conf: > > > > # (the -arp is not needed, and your media type may be different -- most > > # modems use 10baseT for talking, so I've set mine to that. Looks > > # like yours is the same way. > > ifconfig_="inet 10.0.0.1 netmask 255.255.255.252 -arp media > 10baseT/UTP up" > > > > ppp_enable="YES" > > ppp_mode="ddial" > > ppp_profile="pppoe" > > ppp_nat="NO" > > > > And you're good to go. Make sure you reboot, and the link should come > > up right away. > > > > The commandline to bring it up is: 'ppp -quiet -ddial pppoe'. This > > will bring up a tun0 interface, that is connected to the internet. > > Note that it's the *logical* *tun0* interface that is your gateway to > > Sympatico (and the world!), *not* your physical external interface. > > > > As for the DHCP stuff -- your IP address is dynamically assigned via > > PPP, not DHCP. You're talking PPPoE (PPP over Ethernet), not straight > > Ethernet, to Sympatico, so DHCP won't work at all. > > > > Hope this helps... > > > > - Damian > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 8 20:41:51 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D4C0A37B401; Tue, 8 Oct 2002 20:41:49 -0700 (PDT) Received: from bunyip.cc.uq.edu.au (bunyip.cc.uq.edu.au [130.102.2.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A96543E6A; Tue, 8 Oct 2002 20:41:48 -0700 (PDT) (envelope-from csmith@its.uq.edu.au) Received: from [130.102.152.68] (tobermory.its.uq.edu.au [130.102.152.68]) by bunyip.cc.uq.edu.au (8.9.3/8.9.3) with ESMTP id NAA31226; Wed, 9 Oct 2002 13:41:47 +1000 (GMT+1000) User-Agent: Microsoft-Entourage/10.0.0.1309 Date: Wed, 09 Oct 2002 13:41:38 +1000 Subject: High interrupt load on firewalls From: Christopher Smith To: Cc: , Message-ID: 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 two firewalls sitting on gigabit links. Each has 2 Netgear GA620 (ti driver) fibre cards with about 7 vlans spread across them. Both these machines run at *very* high interrupt loads (95 - 100% during business hours (mostly 100%), 80 - 90 % during off hours). They are 1GHz P3 machines (Dell 1550s) with 256MB of RAM. They're actually dual machines, but enabling the second CPU doesn't help in terms of load, it just halves the numbers top reports. Obviously, these machines process a lot of traffic. However, the interrupt load seems to me to be very, very high and the main reason we are seeing such high rates of packet loss (up to 10%, constantly) through these machines - is there any way it can be lessened, either with a better driver, different network cards, or some other way ? We are currently testing with a dual 2.4GHz P4 (Dell 2650) using the same network cards, and are peaking at around 40% (really 80%). However, that doesn't seem to leave much room to grow, and it's a very expensive way to ease the load. Will FreeBSD 5.0 be able to spread the interrupts across both CPUs ? Is this high interrupt load a problem with the driver, the hardware, FreeBSD itself, or is it something that is normal ? What hardware are other people using to firewall high-volume gigabit links ? -- +- Christopher Smith, Systems Administrator ------------------------------+ | Server & Security Group, Information Technology Services | | The University of Queensland, Brisbane, Australia, 4072 | +- Ph +61 7 3365 4046 | email csmith@its.uq.edu.au | Fax +61 7 3365 4065 -+ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 8 21:46:55 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 75D3137B401; Tue, 8 Oct 2002 21:46:51 -0700 (PDT) Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id 16C5743E77; Tue, 8 Oct 2002 21:46:50 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: from panzer.kdm.org (localhost [127.0.0.1]) by panzer.kdm.org (8.12.5/8.12.5) with ESMTP id g994knKD039737; Tue, 8 Oct 2002 22:46:49 -0600 (MDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.12.5/8.12.5/Submit) id g994knCv039736; Tue, 8 Oct 2002 22:46:49 -0600 (MDT) (envelope-from ken) Date: Tue, 8 Oct 2002 22:46:49 -0600 From: "Kenneth D. Merry" To: Christopher Smith Cc: hardware@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: High interrupt load on firewalls Message-ID: <20021008224649.A39689@panzer.kdm.org> References: <20021008224313.A39509@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: <20021008224313.A39509@panzer.kdm.org>; from ken@kdm.org on Tue, Oct 08, 2002 at 10:43:13PM -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 [ taking -questions out of the CC list, please don't send things to more than 2 lists, the mail servers don't usually allow it in any case. ] On Wed, Oct 09, 2002 at 13:41:38 +1000, Christopher Smith wrote: > We have two firewalls sitting on gigabit links. Each has 2 Netgear GA620 > (ti driver) fibre cards with about 7 vlans spread across them. Both these > machines run at *very* high interrupt loads (95 - 100% during business hours > (mostly 100%), 80 - 90 % during off hours). They are 1GHz P3 machines (Dell > 1550s) with 256MB of RAM. They're actually dual machines, but enabling the > second CPU doesn't help in terms of load, it just halves the numbers top > reports. > > Obviously, these machines process a lot of traffic. However, the interrupt > load seems to me to be very, very high and the main reason we are seeing > such high rates of packet loss (up to 10%, constantly) through these > machines - is there any way it can be lessened, either with a better driver, > different network cards, or some other way ? We are currently testing with > a dual 2.4GHz P4 (Dell 2650) using the same network cards, and are peaking > at around 40% (really 80%). However, that doesn't seem to leave much room > to grow, and it's a very expensive way to ease the load. The Tigon II boards have a number of parameters you can tweak to change the intererupt coalescing parameters. It may be that you can tweak the parameters and decrease your load somewhat, but it will require some experimentation. In -stable, you'll have to recompile your kernel with the new values. In -current, there's an ioctl interface, and I can give you a program (I think I still have it) that lets you tweak the parameters on the fly. The parameters you want to tweak are in ti_attach() (src/sys/pci/if_ti.c): /* Set default tuneable values. */ sc->ti_stat_ticks = 2 * TI_TICKS_PER_SEC; sc->ti_rx_coal_ticks = TI_TICKS_PER_SEC / 5000; sc->ti_tx_coal_ticks = TI_TICKS_PER_SEC / 500; sc->ti_rx_max_coal_bds = 64; sc->ti_tx_max_coal_bds = 128; sc->ti_tx_buf_ratio = 21; ti_stat_ticks is the card statistics update interval. I wouldn't recommend bothering with it. ti_{rx,tx}_coal_ticks is the number of clock ticks (on the card) that have to go by before you get interrupted for a send or receive. ti_{rx,tx}_coal_bds is the number of buffers that have to accumulate before you get interrupted for a send or receive. The time and number of buffer limits are a logical or operation. i.e. when the timeout or the buffer threshold is reached, an interrupt is generated. The ti_tx_buf_ratio variable controls the ratio of space allocated to send buffers on the card versus receive buffers. It is in 1/64th increments. So with the default setting of 21, 21/64 of the available buffer space, or 32.8%, is allocated to transmit buffers. The remaining space is allocated to receive buffers. My suggestion is to increase the number of ticks, and the number of buffers coalesced some, and see if you can decrease your interrupt load. I assume you're using 1500 byte packets. If so, beware that the Tigon II boards aren't as efficient with 1500 byte packets as some other boards. They're great with jumbo frames, but with 1500 byte packets you'll probably be pretty hard pressed to get really high throughput. > Will FreeBSD 5.0 be able to spread the interrupts across both CPUs ? Is > this high interrupt load a problem with the driver, the hardware, FreeBSD > itself, or is it something that is normal ? In theory it will, assuming the locks are pushed down on the network stack. At the moment I think you'll find the performance will likely be worse than -stable. > What hardware are other people using to firewall high-volume gigabit links ? Most of my work has been with jumbo frames, and I have a couple of GA620T boards. This isn't firewall work though, but rather geared towards maximum bandwidth. You might want to try out some of the Intel gigabit boards. At least we've got an engineer from Intel who maintains the driver. I haven't tried them out, though, so I can't comment on the boards or the driver. Other folks seem to have good things to say about them, though. 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 Oct 8 22: 2:58 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7369437B401; Tue, 8 Oct 2002 22:02:57 -0700 (PDT) Received: from out6.mx.nwbl.wi.voyager.net (out6.mx.nwbl.wi.voyager.net [169.207.3.77]) by mx1.FreeBSD.org (Postfix) with ESMTP id 08BFA43E4A; Tue, 8 Oct 2002 22:02:57 -0700 (PDT) (envelope-from silby@silby.com) Received: from pop0.nwbl.wi.voyager.net (pop0.nwbl.wi.voyager.net [169.207.1.115]) by out6.mx.nwbl.wi.voyager.net (Postfix) with ESMTP id E5BE4DAD6F; Wed, 9 Oct 2002 00:02:55 -0500 (CDT) Received: from [10.1.1.6] (d165.as29.nwbl0.wi.voyager.net [169.207.73.167]) by pop0.nwbl.wi.voyager.net (8.10.2/8.10.2) with ESMTP id g9952qj88537; Wed, 9 Oct 2002 00:02:52 -0500 (CDT) Date: Wed, 9 Oct 2002 00:07:11 -0500 (CDT) From: Mike Silbersack To: Christopher Smith Cc: hardware@freebsd.org, Subject: Re: High interrupt load on firewalls In-Reply-To: Message-ID: <20021009000519.J2019-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 Wed, 9 Oct 2002, Christopher Smith wrote: > We have two firewalls sitting on gigabit links. Each has 2 Netgear GA620 > (ti driver) fibre cards with about 7 vlans spread across them. Both these > machines run at *very* high interrupt loads (95 - 100% during business hours > (mostly 100%), 80 - 90 % during off hours). They are 1GHz P3 machines (Dell > 1550s) with 256MB of RAM. They're actually dual machines, but enabling the > second CPU doesn't help in terms of load, it just halves the numbers top > reports. I'm not sure if system vs interrupt accounting is entirely accurate, so I'm going to postulate that the firewall itself could actually be the dominant consumer of CPU time. Are you using ipfw? If so, have you tried out Luigi's new IPFW2? It was MFC'd to 4.6-stable, and is supposed to be more efficient. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 8 22:23:29 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E0A7837B401; Tue, 8 Oct 2002 22:23:27 -0700 (PDT) Received: from bunyip.cc.uq.edu.au (bunyip.cc.uq.edu.au [130.102.2.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id C3E6143E65; Tue, 8 Oct 2002 22:23:26 -0700 (PDT) (envelope-from csmith@its.uq.edu.au) Received: from [130.102.152.68] (tobermory.its.uq.edu.au [130.102.152.68]) by bunyip.cc.uq.edu.au (8.9.3/8.9.3) with ESMTP id PAA03221; Wed, 9 Oct 2002 15:23:14 +1000 (GMT+1000) User-Agent: Microsoft-Entourage/10.0.0.1309 Date: Wed, 09 Oct 2002 15:23:02 +1000 Subject: Re: High interrupt load on firewalls From: Christopher Smith To: Mike Silbersack Cc: , Message-ID: In-Reply-To: <20021009000519.J2019-100000@patrocles.silby.com> 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 9/10/02 3:07 PM, "Mike Silbersack" wrote: > > > On Wed, 9 Oct 2002, Christopher Smith wrote: > >> We have two firewalls sitting on gigabit links. Each has 2 Netgear GA620 >> (ti driver) fibre cards with about 7 vlans spread across them. Both these >> machines run at *very* high interrupt loads (95 - 100% during business hours >> (mostly 100%), 80 - 90 % during off hours). They are 1GHz P3 machines (Dell >> 1550s) with 256MB of RAM. They're actually dual machines, but enabling the >> second CPU doesn't help in terms of load, it just halves the numbers top >> reports. > > I'm not sure if system vs interrupt accounting is entirely accurate, so > I'm going to postulate that the firewall itself could actually be the > dominant consumer of CPU time. Are you using ipfw? If so, have you tried > out Luigi's new IPFW2? It was MFC'd to 4.6-stable, and is supposed to be > more efficient. No, we use IPFilter (and that definitely isn't going to change any time soon). The ruleset has about 1600 rules and does employ groups. I am (slowly) in the process of trimming some of the fat (though not primarily for performance reasons, there's just crap in there that needs to be removed). The rule processing can't be done on the other CPU, can it ? Am I right in saying that at this point in time, buying a dual CPU (vs single CPU) machine for firewalling with FreeBSD is just a waste of money ? -- +- Christopher Smith, Systems Administrator ------------------------------+ | Server & Security Group, Information Technology Services | | The University of Queensland, Brisbane, Australia, 4072 | +- Ph +61 7 3365 4046 | email csmith@its.uq.edu.au | Fax +61 7 3365 4065 -+ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 8 22:40:15 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5A0DE37B401; Tue, 8 Oct 2002 22:40:13 -0700 (PDT) Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id B869243E4A; Tue, 8 Oct 2002 22:40:12 -0700 (PDT) (envelope-from julian@elischer.org) 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 <20021009054012.RAGB6765.sccrmhc02.attbi.com@InterJet.elischer.org>; Wed, 9 Oct 2002 05:40:12 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id WAA43724; Tue, 8 Oct 2002 22:30:18 -0700 (PDT) Date: Tue, 8 Oct 2002 22:30:16 -0700 (PDT) From: Julian Elischer To: Christopher Smith Cc: Mike Silbersack , hardware@freebsd.org, net@freebsd.org Subject: Re: High interrupt load on firewalls 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 Wed, 9 Oct 2002, Christopher Smith wrote: > On 9/10/02 3:07 PM, "Mike Silbersack" wrote: > > > > > > > On Wed, 9 Oct 2002, Christopher Smith wrote: > > > >> We have two firewalls sitting on gigabit links. Each has 2 Netgear GA620 > >> (ti driver) fibre cards with about 7 vlans spread across them. Both these > >> machines run at *very* high interrupt loads (95 - 100% during business hours > >> (mostly 100%), 80 - 90 % during off hours). They are 1GHz P3 machines (Dell > >> 1550s) with 256MB of RAM. They're actually dual machines, but enabling the > >> second CPU doesn't help in terms of load, it just halves the numbers top > >> reports. > > > > I'm not sure if system vs interrupt accounting is entirely accurate, so > > I'm going to postulate that the firewall itself could actually be the > > dominant consumer of CPU time. Are you using ipfw? If so, have you tried > > out Luigi's new IPFW2? It was MFC'd to 4.6-stable, and is supposed to be > > more efficient. > > No, we use IPFilter (and that definitely isn't going to change any time > soon). > > The ruleset has about 1600 rules and does employ groups. I am (slowly) in > the process of trimming some of the fat (though not primarily for > performance reasons, there's just crap in there that needs to be removed). > > The rule processing can't be done on the other CPU, can it ? Am I right in > saying that at this point in time, buying a dual CPU (vs single CPU) machine > for firewalling with FreeBSD is just a waste of money ? not necessarily.. ip firewalling is done by the netisr processing which COULD be done sometimes on the other processor from the hardware interrupt it may not happen at teh moment but it is theoretically possible to make it happen. > > -- > +- Christopher Smith, Systems Administrator ------------------------------+ > | Server & Security Group, Information Technology Services | > | The University of Queensland, Brisbane, Australia, 4072 | > +- Ph +61 7 3365 4046 | email csmith@its.uq.edu.au | Fax +61 7 3365 4065 -+ > > > > 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 Oct 9 1:20:21 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2367437B411 for ; Wed, 9 Oct 2002 01:20:15 -0700 (PDT) Received: from scribble.fsn.hu (scribble.fsn.hu [193.224.40.95]) by mx1.FreeBSD.org (Postfix) with SMTP id 31E3643E6A for ; Wed, 9 Oct 2002 01:20:13 -0700 (PDT) (envelope-from bra@fsn.hu) Received: (qmail 4942 invoked by uid 1000); 9 Oct 2002 08:20:14 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 9 Oct 2002 08:20:14 -0000 Date: Wed, 9 Oct 2002 10:20:14 +0200 (CEST) From: Attila Nagy To: "Kenneth D. Merry" Cc: Christopher Smith , , Subject: Re: High interrupt load on firewalls In-Reply-To: <20021008224649.A39689@panzer.kdm.org> Message-ID: References: <20021008224313.A39509@panzer.kdm.org> <20021008224649.A39689@panzer.kdm.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 Hello, > You might want to try out some of the Intel gigabit boards. At least > we've got an engineer from Intel who maintains the driver. I'm far from being a FreeBSD expert, but Luigi Rizzo's polling patch helped me a lot in similar cases to get better performance. From POLLING(4): DESCRIPTION "Device polling" (polling for brevity) refers to a technique to handle devices that does not rely on the latter to generate interrupts when they need attention, but rather lets the CPU poll devices to service their needs. This might seem inefficient and counterintuitive, but when done properly, polling gives more control to the operating system on when and how to handle devices, with a number of advantages in terms of system responsivity and performance. AFAIK there are only two problems about that: SUPPORTED DEVICES Polling requires explicit modifications to the device drivers. As of this writing, the dc, fxp, rl and sis devices are supported, with other in the works. (no Gigabit cards) and sys/kern/kern_poll.c: [...] #ifdef SMP #include "opt_lint.h" #ifndef COMPILING_LINT #error DEVICE_POLLING is not compatible with SMP #endif #endif [...] (no SMP support) As stated above, I'm not an expert, but my opinion is that polling would be the best on the Gigabit cards (due to their capacity) and not the Fast Ethernet ones. Maybe we could start sending GE hardware to Luigi :) ----------[ Free Software ISOs - http://www.fsn.hu/?f=download ]---------- Attila Nagy e-mail: Attila.Nagy@fsn.hu Free Software Network (FSN.HU) phone @work: +361 210 1415 (194) cell.: +3630 306 6758 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Oct 9 1:30:49 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 82EAD37B401; Wed, 9 Oct 2002 01:30:48 -0700 (PDT) Received: from out7.mx.nwbl.wi.voyager.net (out7.mx.nwbl.wi.voyager.net [169.207.3.125]) by mx1.FreeBSD.org (Postfix) with ESMTP id 069EF43E42; Wed, 9 Oct 2002 01:30:48 -0700 (PDT) (envelope-from silby@silby.com) Received: from pop0.nwbl.wi.voyager.net (pop0.nwbl.wi.voyager.net [169.207.1.115]) by out7.mx.nwbl.wi.voyager.net (Postfix) with ESMTP id 3D1DC936C3; Wed, 9 Oct 2002 02:49:25 -0500 (CDT) Received: from [10.1.1.6] (d104.as12.nwbl0.wi.voyager.net [169.207.135.104]) by pop0.nwbl.wi.voyager.net (8.10.2/8.10.2) with ESMTP id g997nOj21464; Wed, 9 Oct 2002 02:49:24 -0500 (CDT) Date: Wed, 9 Oct 2002 02:53:43 -0500 (CDT) From: Mike Silbersack To: Christopher Smith Cc: hardware@freebsd.org, Subject: Re: High interrupt load on firewalls In-Reply-To: Message-ID: <20021009024946.D2682-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 Wed, 9 Oct 2002, Christopher Smith wrote: > No, we use IPFilter (and that definitely isn't going to change any time > soon). Oh. Hm, maybe IPFilter 4.0 will be faster. What you might consider doing is profiling the kernel on your test system to see where the majority of the cpu time is going. > The rule processing can't be done on the other CPU, can it ? Am I right in > saying that at this point in time, buying a dual CPU (vs single CPU) machine > for firewalling with FreeBSD is just a waste of money ? Even if it could be done, I doubt that would be the most cost effectively solution to the problem. Try out different NICs, then move on to kernel profiling if it's still a problem. Luigi can probably comment more on this, but one thing which comes to mind is that the if_ti driver might not be updated to use the new m_getcl function Luigi added. Luigi claimed a 10% increase in forwarding speed for drivers using it, I believe. :) 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 Oct 9 3:56:17 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6969137B406 for ; Wed, 9 Oct 2002 03:56:16 -0700 (PDT) Received: from chicken.orbitel.bg (chicken100.orbitel.bg [195.24.32.21]) by mx1.FreeBSD.org (Postfix) with SMTP id 3B9E143E3B for ; Wed, 9 Oct 2002 03:56:14 -0700 (PDT) (envelope-from i.tanusheff@procreditbank.com) Received: (qmail 23396 invoked from network); 9 Oct 2002 10:56:12 -0000 Received: from unknown (HELO procreditbank.com) (212.95.179.198) by chicken.orbitel.bg with SMTP; 9 Oct 2002 10:56:12 -0000 Received: from itaush [172.16.248.250] by Proxy+; Wed, 09 Oct 2002 13:49:52 +0300 for multiple recipients From: "Ivailo Tanusheff" To: "FreeBSD Questions" , "FreeBSD Net" , "FreeBSD Security" Subject: VPN Tunneling Date: Wed, 9 Oct 2002 13:49:51 +0300 Message-ID: <01d901c26f81$984bbd40$faf810ac@sof.procreditbank.bg> 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, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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 Hello, I'm trying to make a VPN tunnel between a FreeBSD machine and a Win2K Machine. My configuration is: {Net1} <---> <--...--> <---> {Net2} Win2k machine has dynamically assigned IP address as it's connecting to public ISP. Can you help me build the tunnel? Regards, Ivailo Tanusheff To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Oct 9 4: 4:39 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4B6A937B401 for ; Wed, 9 Oct 2002 04:04:37 -0700 (PDT) Received: from south.nanolink.com (south.nanolink.com [217.75.134.10]) by mx1.FreeBSD.org (Postfix) with SMTP id DFE3143E4A for ; Wed, 9 Oct 2002 04:04:34 -0700 (PDT) (envelope-from roam@ringlet.net) Received: (qmail 31777 invoked by uid 85); 9 Oct 2002 11:15:13 -0000 Received: from office.sbnd.net (HELO straylight.ringlet.net) (217.75.140.130) by south.nanolink.com with SMTP; 9 Oct 2002 11:15:10 -0000 Received: (qmail 57730 invoked by uid 1000); 9 Oct 2002 11:04:26 -0000 Date: Wed, 9 Oct 2002 14:04:26 +0300 From: Peter Pentchev To: Ivailo Tanusheff Cc: FreeBSD Questions , FreeBSD Net , FreeBSD Security Subject: Re: VPN Tunneling Message-ID: <20021009110426.GP376@straylight.oblivion.bg> Mail-Followup-To: Ivailo Tanusheff , FreeBSD Questions , FreeBSD Net , FreeBSD Security References: <01d901c26f81$984bbd40$faf810ac@sof.procreditbank.bg> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="x38akuY2VS0PywU3" Content-Disposition: inline In-Reply-To: <01d901c26f81$984bbd40$faf810ac@sof.procreditbank.bg> User-Agent: Mutt/1.5.1i X-Virus-Scanned: by Nik's Monitoring Daemon (AMaViS perl-11d ) 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 --x38akuY2VS0PywU3 Content-Type: text/plain; charset=windows-1251 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 09, 2002 at 01:49:51PM +0300, Ivailo Tanusheff wrote: > Hello, >=20 > I'm trying to make a VPN tunnel between a FreeBSD machine and a Win2K > Machine. My configuration is: >=20 > {Net1} <---> <--...--> <---> {Net2} >=20 > Win2k machine has dynamically assigned IP address as it's connecting to > public ISP. Can you help me build the tunnel? Take a look at the net/mpd port; it needs Netgraph either built into the kernel, or loaded as a KLD. Then, on the Win2K side, use the PPTP VPN connections ('Connect to a private network through the Internet'). Things are *very* easy to set up, actually :) Drop me a private mail if you need some help, or we just might meet on IRC :) G'luck, Peter --=20 Peter Pentchev roam@ringlet.net roam@FreeBSD.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This sentence contains exactly threee erors. --x38akuY2VS0PywU3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (FreeBSD) iD8DBQE9pA057Ri2jRYZRVMRAr3HAJ9dSgRYovMYXHT2otrg2RIw6dSrPACgo/Dq rn+gbK+QFb89Aaq/XxyQrQE= =N0PG -----END PGP SIGNATURE----- --x38akuY2VS0PywU3-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Oct 9 6:27:25 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9C0E137B447 for ; Wed, 9 Oct 2002 06:27:23 -0700 (PDT) Received: from obsidian.sentex.ca (obsidian.sentex.ca [64.7.128.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id D94D743E4A for ; Wed, 9 Oct 2002 06:27:22 -0700 (PDT) (envelope-from damian@sentex.net) Received: from pegmatite (pyroxene.sentex.ca [199.212.134.18]) (authenticated bits=0) by obsidian.sentex.ca (8.12.6/8.12.6) with ESMTP id g99DRK8f018273 for ; Wed, 9 Oct 2002 09:27:20 -0400 (EDT) (envelope-from damian@sentex.net) Date: Wed, 9 Oct 2002 09:26:32 -0400 From: Damian Gerow X-Mailer: The Bat! (v1.61) Organization: Sentex Data Communications X-Priority: 3 (Normal) Message-ID: <137481960272.20021009092632@sentex.net> To: freebsd-net@FreeBSD.ORG Subject: Re: Sympatico ADSL connection through a hub In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: By Sentex Communications (obsidian/20020517) X-Spam-Status: No, hits=-7.8 required=5.0 tests=IN_REP_TO,NOSPAM_INC,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT_THEBAT version=2.41 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org For archival purposes... He has a DLink router, which was handling the PPPoE itself, and using DHCP for the LAN behind it. We took out the PPP configuration, put in DHCP (ifconfig_dc0="DHCP"), and it's all up and running. - Damian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Oct 9 6:42:57 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1514D37B401 for ; Wed, 9 Oct 2002 06:42:56 -0700 (PDT) Received: from web40903.mail.yahoo.com (web40903.mail.yahoo.com [66.218.78.200]) by mx1.FreeBSD.org (Postfix) with SMTP id A3B8443E65 for ; Wed, 9 Oct 2002 06:42:55 -0700 (PDT) (envelope-from yat_33@yahoo.com) Message-ID: <20021009134255.53626.qmail@web40903.mail.yahoo.com> Received: from [65.207.163.130] by web40903.mail.yahoo.com via HTTP; Wed, 09 Oct 2002 06:42:55 PDT Date: Wed, 9 Oct 2002 06:42:55 -0700 (PDT) From: yatin chalke Subject: How to get hardware address of a machine using ARP/Sysctl/Routing sockets?? 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 Hi, I want to get hardware address of any machine on a subnet using sysctl and routing sockets. I can search arp cache and return the hardware address if it is there. But if the hardware address is not in ARP cache then I cant retrieve it. Is there any way to get hardware address of any machine using any Arp structure/routing sockets /sysctl?? I tried using IOCTL but it doesnt work with freebsd 4.4. Any help will be appreciated. Thanks, --Yatin __________________________________________________ Do you Yahoo!? Faith Hill - Exclusive Performances, Videos & More http://faith.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Oct 9 7:37:37 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1019C37B401; Wed, 9 Oct 2002 07:37:35 -0700 (PDT) Received: from wso-h001.wsonline.net (12-254-8-189.client.attbi.com [12.254.8.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id 69F5D43E3B; Wed, 9 Oct 2002 07:37:34 -0700 (PDT) (envelope-from seahorse51@attbi.com) Received: from seahorse.attbi.com (trilluser@seahorse [192.168.1.101]) by wso-h001.wsonline.net (8.12.5/8.12.5) with ESMTP id g99EbVxl013524; Wed, 9 Oct 2002 08:37:33 -0600 (MDT) (envelope-from seahorse51@attbi.com) Message-Id: <5.1.1.6.0.20021009083403.01c88f88@mail.seahorse.wsonline.net> X-Sender: seahorse@mail.seahorse.wsonline.net X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Wed, 09 Oct 2002 08:37:30 -0600 To: Peter Pentchev , Ivailo Tanusheff From: Andy Subject: Re: VPN Tunneling Cc: FreeBSD Questions , FreeBSD Net , FreeBSD Security In-Reply-To: <20021009110426.GP376@straylight.oblivion.bg> References: <01d901c26f81$984bbd40$faf810ac@sof.procreditbank.bg> <01d901c26f81$984bbd40$faf810ac@sof.procreditbank.bg> 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 >On Wed, Oct 09, 2002 at 01:49:51PM +0300, Ivailo Tanusheff wrote: >Hello, > >I'm trying to make a VPN tunnel between a FreeBSD machine and a Win2K >Machine. My configuration is: > >{Net1} <---> <--...--> <---> {Net2} > >Win2k machine has dynamically assigned IP address as it's connecting to >public ISP. Can you help me build the tunnel? At 05:04 10/09/2002, Peter Pentchev wrote: >Take a look at the net/mpd port; it needs Netgraph either built into the >kernel, or loaded as a KLD. Then, on the Win2K side, use the PPTP VPN >connections ('Connect to a private network through the Internet'). >Things are *very* easy to set up, actually :) > >Drop me a private mail if you need some help, or we just might meet on >IRC :) > >G'luck, >Peter Will this method permit incoming connections from the out side Internet and then forward them to a box with an internal IP address on net1? Where the FreeBSD box is acting as a gateway/natd for the net1 internal network. Andy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Oct 9 8: 9:17 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 152C737B401 for ; Wed, 9 Oct 2002 08:09:15 -0700 (PDT) Received: from south.nanolink.com (south.nanolink.com [217.75.134.10]) by mx1.FreeBSD.org (Postfix) with SMTP id 714D843E88 for ; Wed, 9 Oct 2002 08:09:13 -0700 (PDT) (envelope-from roam@ringlet.net) Received: (qmail 32953 invoked by uid 85); 9 Oct 2002 15:19:51 -0000 Received: from office.sbnd.net (HELO straylight.ringlet.net) (217.75.140.130) by south.nanolink.com with SMTP; 9 Oct 2002 15:19:48 -0000 Received: (qmail 82038 invoked by uid 1000); 9 Oct 2002 15:09:03 -0000 Date: Wed, 9 Oct 2002 18:09:02 +0300 From: Peter Pentchev To: Andy Cc: Ivailo Tanusheff , FreeBSD Questions , FreeBSD Net , FreeBSD Security Subject: Re: VPN Tunneling Message-ID: <20021009150902.GV376@straylight.oblivion.bg> Mail-Followup-To: Andy , Ivailo Tanusheff , FreeBSD Questions , FreeBSD Net , FreeBSD Security References: <01d901c26f81$984bbd40$faf810ac@sof.procreditbank.bg> <01d901c26f81$984bbd40$faf810ac@sof.procreditbank.bg> <5.1.1.6.0.20021009083403.01c88f88@mail.seahorse.wsonline.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xe2geHXJg22At20M" Content-Disposition: inline In-Reply-To: <5.1.1.6.0.20021009083403.01c88f88@mail.seahorse.wsonline.net> User-Agent: Mutt/1.5.1i X-Virus-Scanned: by Nik's Monitoring Daemon (AMaViS perl-11d ) 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 --xe2geHXJg22At20M Content-Type: text/plain; charset=windows-1251 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 09, 2002 at 08:37:30AM -0600, Andy wrote: >=20 > >On Wed, Oct 09, 2002 at 01:49:51PM +0300, Ivailo Tanusheff wrote: > >Hello, > > > >I'm trying to make a VPN tunnel between a FreeBSD machine and a Win2K > >Machine. My configuration is: > > > >{Net1} <---> <--...--> <---> {Net2} > > > >Win2k machine has dynamically assigned IP address as it's connecting to > >public ISP. Can you help me build the tunnel? >=20 > At 05:04 10/09/2002, Peter Pentchev wrote: >=20 > >Take a look at the net/mpd port; it needs Netgraph either built into the > >kernel, or loaded as a KLD. Then, on the Win2K side, use the PPTP VPN > >connections ('Connect to a private network through the Internet'). > >Things are *very* easy to set up, actually :) > > > >Drop me a private mail if you need some help, or we just might meet on > >IRC :) > > > >G'luck, > >Peter >=20 > Will this method permit incoming connections from the out side Internet a= nd=20 > then forward them to a box with an internal IP address on net1? Where th= e=20 > FreeBSD box is acting as a gateway/natd for the net1 internal network. In this case, the FreeBSD box does not act as a gateway, merely as a tunnel endpoint. It may be otherwise configured to act as a NAT gateway, but this is independend: this allows another FreeBSD or Win2K or maybe even Linux box to establish a PPTP VPN tunnel, and perform direct routing between net1 and net2. Any machine within net1 will be abel to reach net2 directly, and vice versa. To let machines from the outside Internet -- not the other side of the tunnel -- reach the inside boxes, you will need to set up some other NAT mechanism, but, once again, this is entirely independent of mpd - mpd will provide the VPN functionality regardless of whether the FreeBSD box is also acting as a NAT gateway. G'luck, Peter --=20 Peter Pentchev roam@ringlet.net roam@FreeBSD.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 I am not the subject of this sentence. --xe2geHXJg22At20M Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (FreeBSD) iD8DBQE9pEaO7Ri2jRYZRVMRAnxTAJsE5UmtoHy0CGL5G+A/h2QD8kN5HQCeNEc7 DEcwpPcTKKYbXAsW+8Yrc38= =kaSl -----END PGP SIGNATURE----- --xe2geHXJg22At20M-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Oct 9 9: 3:46 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E203137B401; Wed, 9 Oct 2002 09:03:44 -0700 (PDT) Received: from carp.icir.org (carp.icir.org [192.150.187.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C98343E6E; Wed, 9 Oct 2002 09:03:44 -0700 (PDT) (envelope-from rizzo@carp.icir.org) Received: from carp.icir.org (localhost [127.0.0.1]) by carp.icir.org (8.12.3/8.12.3) with ESMTP id g99FoZO2050706; Wed, 9 Oct 2002 08:50:35 -0700 (PDT) (envelope-from rizzo@carp.icir.org) Received: (from rizzo@localhost) by carp.icir.org (8.12.3/8.12.3/Submit) id g99FoYLA050705; Wed, 9 Oct 2002 08:50:34 -0700 (PDT) (envelope-from rizzo) Date: Wed, 9 Oct 2002 08:50:34 -0700 From: Luigi Rizzo To: Mike Silbersack Cc: Christopher Smith , hardware@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: High interrupt load on firewalls Message-ID: <20021009085034.E48709@carp.icir.org> References: <20021009024946.D2682-100000@patrocles.silby.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: <20021009024946.D2682-100000@patrocles.silby.com>; from silby@silby.com on Wed, Oct 09, 2002 at 02:53:43AM -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 my general attitude is that when you are hitting 100% cpu utilization, small performance improvements such as those deriving from m_getcl() are not relevant, and you might want to restructure your sw in order to get substantial performance improvements. In the specific case, at least reading from the comments, it seems that firewall processing is really the main cpu consumer, so they should revise their ruleset more than move to a different board, or use polling (i have polling patches for the intel gigabit adapter) What are the actual packet rates at which you are seeing problems ? cheers luigi On Wed, Oct 09, 2002 at 02:53:43AM -0500, Mike Silbersack wrote: > > On Wed, 9 Oct 2002, Christopher Smith wrote: > > > No, we use IPFilter (and that definitely isn't going to change any time > > soon). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Oct 9 10: 2:37 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8EA6C37B401 for ; Wed, 9 Oct 2002 10:02:34 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id CBC5F43E6E for ; Wed, 9 Oct 2002 10:02:33 -0700 (PDT) (envelope-from larse@ISI.EDU) Received: from isi.edu (nik.isi.edu [128.9.168.58]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g99H2WC22610; Wed, 9 Oct 2002 10:02:32 -0700 (PDT) Message-ID: <3DA46127.8070301@isi.edu> Date: Wed, 09 Oct 2002 10:02:31 -0700 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: yatin chalke Cc: freebsd-net@freebsd.org Subject: Re: How to get hardware address of a machine using ARP/Sysctl/Routing sockets?? References: <20021009134255.53626.qmail@web40903.mail.yahoo.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020906030808050902030808" 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. --------------ms020906030808050902030808 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit yatin chalke wrote: > > I want to get hardware address of any machine on a > subnet using sysctl and routing sockets. > I can search arp cache and return the hardware address > if it is there. I'm not 100% sure I understand what you want to do, but using nmap (or similar) to scan the subnet should get you the list. MAC addresses will then be either in your cache, or use net/arping from ports to get them. Lars -- Lars Eggert USC Information Sciences Institute --------------ms020906030808050902030808 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJtjCC AzgwggKhoAMCAQICEGZFcrfMdPXPY3ZFhNAukQEwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vydmlj ZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkG CSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAw MDBaFw0wNDA4MjcyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2Vy dGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAw LjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZ gpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqd knWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYALQmJ7JRr6aFp AgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTI5NzAS BgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQAxsUtH XfkBceX1U2xdedY9mMAmE2KBIqcS+CKV6BtJtyd7BDm6/ObyJOuR+r3sDSo491BVqGz3Da1M G7wD9LXrokefbKIMWI0xQgkRbLAaadErErJAXWr5edDqLiXdiuT82w0fnQLzWtvKPPZE6iZp h39Ins6ln+eE2MliYq0FxjCCAzkwggKioAMCAQICAwglQTANBgkqhkiG9w0BAQQFADCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMB4XDTAyMDgyNDE4NTMzOVoX DTAzMDgyNDE4NTMzOVowVDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYD VQQDEwtMYXJzIEVnZ2VydDEcMBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBANI2Rrt4ggaQ/IrOsDeOm2H4/R5FRIL6JjDY3StE aogp1r23WKniQ1Vj98Nu5WxlaZ3Iam3Jen5T66H8u7rtMNpK4qAeAGoBsVeyVr1+CTFeuv+m xCh7BvBJwhLdm0zDaoDT05YKYZaqtsT+F286FWJQg31Xtf+vTKLVVrHcsafnteyal2NEt7Ac yZZfjsVLwxp2Lq3cwYfRQRoo7/yCVzS7HsgM6jmbO4taEMo4yC2rpnUbWEUCDTaCYgpAXzAl oiNk7GDh0wz2s5ZSnHRvNSBMAjCmpNtSYHfXFI1ANwrrrHIJ7Ei83+XN32PWY4OPzO3iown9 VR+vM+8lNx9OX28CAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIBBAQTTDJ1TXlmZkJO VWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEEBQADgYEAXcrIlKmPLM/r8r3oz2ZLPLaT1AyMjYTZY2qq/R7SUtFa9BNlTIFh DG78QKfJ9lo2LMzTPQqMZgNLmj95GbNPI8P8OIq2K6MeCZWz08ROackqTFP6xWbIFIfXcBVR 1dZnDDyDKBBh05KkvyTPawSQyOBUeNBfQUyO4TE+3o58U8UwggM5MIICoqADAgECAgMIJUEw DQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MDAeFw0wMjA4MjQxODUzMzlaFw0wMzA4MjQxODUzMzlaMFQxDzANBgNVBAQTBkVnZ2VydDEN MAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkqhkiG9w0BCQEWDWxh cnNlQGlzaS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDSNka7eIIGkPyK zrA3jpth+P0eRUSC+iYw2N0rRGqIKda9t1ip4kNVY/fDbuVsZWmdyGptyXp+U+uh/Lu67TDa SuKgHgBqAbFXsla9fgkxXrr/psQoewbwScIS3ZtMw2qA09OWCmGWqrbE/hdvOhViUIN9V7X/ r0yi1Vax3LGn57XsmpdjRLewHMmWX47FS8Madi6t3MGH0UEaKO/8glc0ux7IDOo5mzuLWhDK OMgtq6Z1G1hFAg02gmIKQF8wJaIjZOxg4dMM9rOWUpx0bzUgTAIwpqTbUmB31xSNQDcK66xy CexIvN/lzd9j1mODj8zt4qMJ/VUfrzPvJTcfTl9vAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIB ADAaMBgCAQQEE0wydU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVk dTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAF3KyJSpjyzP6/K96M9mSzy2k9QM jI2E2WNqqv0e0lLRWvQTZUyBYQxu/ECnyfZaNizM0z0KjGYDS5o/eRmzTyPD/DiKtiujHgmV s9PETmnJKkxT+sVmyBSH13AVUdXWZww8gygQYdOSpL8kz2sEkMjgVHjQX0FMjuExPt6OfFPF MYIDJzCCAyMCAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MAIDCCVBMAkGBSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTAyMTAwOTE3MDIzMVowIwYJKoZIhvcNAQkEMRYEFEi8GQT316Qnbg8bex/o Y5WjlHogMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0BCRACCzGB naCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJ Q2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZp Y2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMIJUEwDQYJ KoZIhvcNAQEBBQAEggEAm/odyE7xe626RxI7fSNNS2ddU5JPy75k2Uwbb9mBva9gBwQgQFzD Q9aIpeRtVYy47pbMcWlGMGEFWSegGJOT10iBiHR6aZQC4LfCyKRE8xegkG9UlOYeOdPqXaCj fxW6iM2tE/r3JWfwYIynmqIMgP4WHm4qjN0SH6GEftGSrA94zzp8YbVXQ8hBNt6Ix2fKwWCO zzVhiniWny5CyFdlP7KRcxr+P3mGsylpdQIWi06PaR0ohDeEi4qp7hG5dzP7Il3U6bJyaKYp UqSFKbjuUaUMcbkMbVSjBqeEa7F7PsWsjOCzunhLdISPw1ywBdwBpzQVqtcMnvQDEwulUE32 6AAAAAAAAA== --------------ms020906030808050902030808-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Oct 9 10: 4: 2 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E30EE37B401; Wed, 9 Oct 2002 10:03:59 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5D89343E42; Wed, 9 Oct 2002 10:03:59 -0700 (PDT) (envelope-from larse@ISI.EDU) Received: from isi.edu (nik.isi.edu [128.9.168.58]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g99H3sC23947; Wed, 9 Oct 2002 10:03:54 -0700 (PDT) Message-ID: <3DA4617A.5010606@isi.edu> Date: Wed, 09 Oct 2002 10:03:54 -0700 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: Luigi Rizzo Cc: Mike Silbersack , Christopher Smith , hardware@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: High interrupt load on firewalls References: <20021009024946.D2682-100000@patrocles.silby.com> <20021009085034.E48709@carp.icir.org> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030207060104080105060406" 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. --------------ms030207060104080105060406 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Luigi Rizzo wrote: > than move to a different board, or use polling (i have polling > patches for the intel gigabit adapter) If you mean em(4) - I'd love to test them :-) Lars -- Lars Eggert USC Information Sciences Institute --------------ms030207060104080105060406 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJtjCC AzgwggKhoAMCAQICEGZFcrfMdPXPY3ZFhNAukQEwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vydmlj ZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkG CSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAw MDBaFw0wNDA4MjcyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2Vy dGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAw LjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZ gpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqd knWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYALQmJ7JRr6aFp AgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTI5NzAS BgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQAxsUtH XfkBceX1U2xdedY9mMAmE2KBIqcS+CKV6BtJtyd7BDm6/ObyJOuR+r3sDSo491BVqGz3Da1M G7wD9LXrokefbKIMWI0xQgkRbLAaadErErJAXWr5edDqLiXdiuT82w0fnQLzWtvKPPZE6iZp h39Ins6ln+eE2MliYq0FxjCCAzkwggKioAMCAQICAwglQTANBgkqhkiG9w0BAQQFADCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMB4XDTAyMDgyNDE4NTMzOVoX DTAzMDgyNDE4NTMzOVowVDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYD VQQDEwtMYXJzIEVnZ2VydDEcMBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBANI2Rrt4ggaQ/IrOsDeOm2H4/R5FRIL6JjDY3StE aogp1r23WKniQ1Vj98Nu5WxlaZ3Iam3Jen5T66H8u7rtMNpK4qAeAGoBsVeyVr1+CTFeuv+m xCh7BvBJwhLdm0zDaoDT05YKYZaqtsT+F286FWJQg31Xtf+vTKLVVrHcsafnteyal2NEt7Ac yZZfjsVLwxp2Lq3cwYfRQRoo7/yCVzS7HsgM6jmbO4taEMo4yC2rpnUbWEUCDTaCYgpAXzAl oiNk7GDh0wz2s5ZSnHRvNSBMAjCmpNtSYHfXFI1ANwrrrHIJ7Ei83+XN32PWY4OPzO3iown9 VR+vM+8lNx9OX28CAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIBBAQTTDJ1TXlmZkJO VWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEEBQADgYEAXcrIlKmPLM/r8r3oz2ZLPLaT1AyMjYTZY2qq/R7SUtFa9BNlTIFh DG78QKfJ9lo2LMzTPQqMZgNLmj95GbNPI8P8OIq2K6MeCZWz08ROackqTFP6xWbIFIfXcBVR 1dZnDDyDKBBh05KkvyTPawSQyOBUeNBfQUyO4TE+3o58U8UwggM5MIICoqADAgECAgMIJUEw DQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MDAeFw0wMjA4MjQxODUzMzlaFw0wMzA4MjQxODUzMzlaMFQxDzANBgNVBAQTBkVnZ2VydDEN MAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkqhkiG9w0BCQEWDWxh cnNlQGlzaS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDSNka7eIIGkPyK zrA3jpth+P0eRUSC+iYw2N0rRGqIKda9t1ip4kNVY/fDbuVsZWmdyGptyXp+U+uh/Lu67TDa SuKgHgBqAbFXsla9fgkxXrr/psQoewbwScIS3ZtMw2qA09OWCmGWqrbE/hdvOhViUIN9V7X/ r0yi1Vax3LGn57XsmpdjRLewHMmWX47FS8Madi6t3MGH0UEaKO/8glc0ux7IDOo5mzuLWhDK OMgtq6Z1G1hFAg02gmIKQF8wJaIjZOxg4dMM9rOWUpx0bzUgTAIwpqTbUmB31xSNQDcK66xy CexIvN/lzd9j1mODj8zt4qMJ/VUfrzPvJTcfTl9vAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIB ADAaMBgCAQQEE0wydU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVk dTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAF3KyJSpjyzP6/K96M9mSzy2k9QM jI2E2WNqqv0e0lLRWvQTZUyBYQxu/ECnyfZaNizM0z0KjGYDS5o/eRmzTyPD/DiKtiujHgmV s9PETmnJKkxT+sVmyBSH13AVUdXWZww8gygQYdOSpL8kz2sEkMjgVHjQX0FMjuExPt6OfFPF MYIDJzCCAyMCAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MAIDCCVBMAkGBSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTAyMTAwOTE3MDM1NFowIwYJKoZIhvcNAQkEMRYEFHpQ1t2cLv4jAGOX50yN jUlVSBWRMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0BCRACCzGB naCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJ Q2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZp Y2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMIJUEwDQYJ KoZIhvcNAQEBBQAEggEAXP5HUXMkQFjlJgUKsEVgZBOpm/p63A0SJNScZI/A1n2W9/O85txG vKYxryp3q1gLEJ7byQAxZodPZvkYUmwLjtIrrNNNYNtHVLRns8gKIMomG6jxF+FFnqcC9VNf 31li2+inAgEIAEC7/GEv1Jq5PNIkhdP0FAEapYAVcVJG55pgatYq51Q3c5RhIfsG1jfSkyUS KcRnxaHD7Sdj+AADw1S37wXlQb4aPw53hNKzQJK37zAKKIKDLiKDoDbEBE0ehHdGfbCVcajg 9ZJaooOSfL4AWQI95AjYFNfXDZgnfSg+K+poptFi2MTp1IndZ5Xih6pSEzMnr/225xmdg/4S NAAAAAAAAA== --------------ms030207060104080105060406-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Oct 9 10:13:36 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4F5B337B401 for ; Wed, 9 Oct 2002 10:13:34 -0700 (PDT) Received: from goof.com (pcp02305702pcs.longhl01.md.comcast.net [68.52.164.8]) by mx1.FreeBSD.org (Postfix) with SMTP id 4832C43E7B for ; Wed, 9 Oct 2002 10:13:33 -0700 (PDT) (envelope-from jlido@goof.com) Received: (qmail 77969 invoked by uid 15016); 9 Oct 2002 17:13:32 -0000 Date: Wed, 9 Oct 2002 13:13:32 -0400 From: Jon-Erik Lido To: freebsd-net@freebsd.org Subject: Routing from an Interface to an Alias Message-ID: <20021009131332.C77051@goof.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 I'm trying to something a little bizarre with routing, so I suppose it bears some explanation. I recently purchased one of those all-in-one firewall/NAT/ethernet switch/801.11b access point boxes for my home use. 802.11b security being what it is (useless), I'm planning on setting up IPSec for my WLAN for authentication and encryption. However, I haven't gotten that far yet. I've set up two subnets behind my firewall. One is 10.10.10.0/24 and is for the wired LAN. The other is 10.0.0.0/24 and is for the wireless LAN. I've got a FreeBSD box with a single NIC ethernetted to one of the ports on the firewall's switch. I'm planning to use it as my 10.0.0.0/24 to 10.10.10.0/24 gateway. Two subnets on one segment. rc.conf (excerpt) looks like this: defaultrouter="10.10.10.254" gateway_enable="YES" firewall_enable="YES" firewall_type="open" ifconfig_ed0="inet 10.10.10.1 netmask 255.255.255.0" ifconfig_ed0_alias0="inet 10.10.10.10 netmask 255.255.255.255" ifconfig_ed0_alias1="inet 10.0.0.1 netmask 255.255.255.0" 10.10.10.10 is simply an alias I'm using since I'm running dnscache on 10.10.10.1 and tinydns on 10.10.10.10. The kernel was compiled with options IPFIREWALL options IPDIVERT With my wireless laptop set to 10.0.0.50 using the 10.0.0.1 gateway as its default route I am able to ping 10.0.0.1, 10.10.10.1, but no other hosts on or off the LAN. traceroute from the laptop reveals a hop to 10.0.0.1 and then the packets are simply lost. 10.10.10.1's routing table looks like this: Destination Gateway Flags Refs Use Netif Expire default 10.10.10.254 UGSc 16 31 ed0 10/24 link#1 UC 1 0 ed0 10.0.0.50 00:02:2d:6b:9f:ec UHLW 1 159 ed0 1180 10.10.10/24 link#1 UC 3 0 ed0 10.10.10.1 00:4f:49:0a:1e:85 UHLW 1 831 lo0 10.10.10.2 00:4f:4e:04:3b:35 UHLW 2 3415 ed0 1075 10.10.10.10 00:4f:49:0a:1e:85 UHLW 1 101 lo0 => 10.10.10.10/32 link#1 UC 1 0 ed0 10.10.10.254 00:30:f1:18:84:3c UHLW 17 25 ed0 1078 127.0.0.1 127.0.0.1 UH 0 0 lo0 Notice that the 10/24 subnet is listed, but not the 10.0.0.1 IP number. The Routing section of the FreeBSD Handbook alludes to being able to do this, so I assume it's possible. I just don't know what's wrong. Help!? -Jon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Oct 9 12:26:36 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 190EF37B401 for ; Wed, 9 Oct 2002 12:26:35 -0700 (PDT) Received: from carp.icir.org (carp.icir.org [192.150.187.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id BCBBB43E6E for ; Wed, 9 Oct 2002 12:26:34 -0700 (PDT) (envelope-from rizzo@carp.icir.org) Received: from carp.icir.org (localhost [127.0.0.1]) by carp.icir.org (8.12.3/8.12.3) with ESMTP id g99JQXO2052419; Wed, 9 Oct 2002 12:26:33 -0700 (PDT) (envelope-from rizzo@carp.icir.org) Received: (from rizzo@localhost) by carp.icir.org (8.12.3/8.12.3/Submit) id g99JQW73052418; Wed, 9 Oct 2002 12:26:32 -0700 (PDT) (envelope-from rizzo) Date: Wed, 9 Oct 2002 12:26:32 -0700 From: Luigi Rizzo To: Andrey Simonenko Cc: freebsd-net@FreeBSD.ORG Subject: Re: Q about sbin/ip6fw/ip6fw.c:list() Message-ID: <20021009122632.A52391@carp.icir.org> References: <20021007222647.B91626-100000@lion.com.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20021007222647.B91626-100000@lion.com.ua>; from simon@simon.org.ua on Mon, Oct 07, 2002 at 11:29:50PM +0300 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, Oct 07, 2002 at 11:29:50PM +0300, Andrey Simonenko wrote: > Hello, > > Why is it not allowed to get more that 65536 ip6fw rules from the kernel > in the ip6fw.c:list() function? i think it is just an oversight -- perhaps the author though that each rule had to have its own number. luigi > Here is some lines from ip6fw.c: > > maxbytes = 65536 * sizeof *rules; > while (bytes >= nalloc) { > nalloc = nalloc * 2 + 200; > bytes = nalloc; > if ((rules = realloc(rules, bytes)) == NULL) > err(EX_OSERR, "realloc"); > i = getsockopt(s, IPPROTO_IPV6, IPV6_FW_GET, rules, &bytes); > if ((i < 0 && errno != EINVAL) || nalloc > maxbytes) > err(EX_OSERR, "getsockopt(IPV6_FW_GET)"); > } > > > 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 Oct 9 15:40:38 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 19DBC37B406; Wed, 9 Oct 2002 15:40:37 -0700 (PDT) Received: from bunyip.cc.uq.edu.au (bunyip.cc.uq.edu.au [130.102.2.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id E01F043E65; Wed, 9 Oct 2002 15:40:34 -0700 (PDT) (envelope-from csmith@its.uq.edu.au) Received: from [130.102.152.71] (tomsk.its.uq.edu.au [130.102.152.71]) by bunyip.cc.uq.edu.au (8.9.3/8.9.3) with ESMTP id IAA24684; Thu, 10 Oct 2002 08:40:29 +1000 (GMT+1000) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Wed, 09 Oct 2002 20:44:03 +1000 Subject: Re: High interrupt load on firewalls From: Christopher Smith To: Attila Nagy Cc: , Message-ID: In-Reply-To: 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 9/10/2002 6:20 PM, "Attila Nagy" wrote: > Hello, [chomp] > and > sys/kern/kern_poll.c: > [...] > #ifdef SMP > #include "opt_lint.h" > #ifndef COMPILING_LINT > #error DEVICE_POLLING is not compatible with SMP > #endif > #endif > [...] > > (no SMP support) This I can live with, as it appears having multiple CPUs does SFA anyway when it comes to firewalling (at least with FreeBSD <5.0). Certainly we have no discernable improvement on our dual 1GHz P3s between a UMP and SMP kernel. > As stated above, I'm not an expert, but my opinion is that polling would > be the best on the Gigabit cards (due to their capacity) and not the Fast > Ethernet ones. > > Maybe we could start sending GE hardware to Luigi :) I could probably swing a remote login to a machine with a NetGear GA620 (ti) fibre card and an Intel (em) copper card (it's a Dell 1650) if it would help speed development. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Oct 9 16:27:10 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 46F2237B404 for ; Wed, 9 Oct 2002 16:27:09 -0700 (PDT) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with SMTP id 6E9BD43E42 for ; Wed, 9 Oct 2002 16:27:07 -0700 (PDT) (envelope-from oppermann@tix.ch) Received: (qmail 38794 invoked from network); 9 Oct 2002 23:24:09 -0000 Received: from unknown (HELO tix.ch) ([62.48.0.54]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 9 Oct 2002 23:24:09 -0000 Message-ID: <3DA4BB08.D7759E02@tix.ch> Date: Thu, 10 Oct 2002 01:26:00 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Luigi Rizzo Cc: Mike Silbersack , Christopher Smith , hardware@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: High interrupt load on firewalls References: <20021009024946.D2682-100000@patrocles.silby.com> <20021009085034.E48709@carp.icir.org> 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 Luigi Rizzo wrote: > > my general attitude is that when you are hitting 100% cpu > utilization, small performance improvements such as those > deriving from m_getcl() are not relevant, and you might > want to restructure your sw in order to get substantial > performance improvements. > > In the specific case, at least reading from the comments, > it seems that firewall processing is really the main > cpu consumer, so they should revise their ruleset more > than move to a different board, or use polling (i have polling > patches for the intel gigabit adapter) > > What are the actual packet rates at which you are seeing problems ? He probably can't tell because of the 32bit ifstats counters. They wrap every other minute on a well loaded Gigabit card. -- Andre > cheers > luigi > > On Wed, Oct 09, 2002 at 02:53:43AM -0500, Mike Silbersack wrote: > > > > On Wed, 9 Oct 2002, Christopher Smith wrote: > > > > > No, we use IPFilter (and that definitely isn't going to change any time > > > soon). > > 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 Oct 9 16:41:35 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 22DD837B401; Wed, 9 Oct 2002 16:41:34 -0700 (PDT) Received: from bunyip.cc.uq.edu.au (bunyip.cc.uq.edu.au [130.102.2.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id ED69E43E42; Wed, 9 Oct 2002 16:41:32 -0700 (PDT) (envelope-from csmith@its.uq.edu.au) Received: from [130.102.152.68] (tobermory.its.uq.edu.au [130.102.152.68]) by bunyip.cc.uq.edu.au (8.9.3/8.9.3) with ESMTP id JAA26291; Thu, 10 Oct 2002 09:41:21 +1000 (GMT+1000) User-Agent: Microsoft-Entourage/10.0.0.1309 Date: Thu, 10 Oct 2002 09:41:12 +1000 Subject: Re: High interrupt load on firewalls From: Christopher Smith To: Andre Oppermann Cc: Mike Silbersack , , Message-ID: In-Reply-To: <3DA4BB08.D7759E02@tix.ch> 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 10/10/02 9:26 AM, "Andre Oppermann" wrote: [chomp] > He probably can't tell because of the 32bit ifstats counters. They > wrap every other minute on a well loaded Gigabit card. A 'systat -ip 1' shows rates ranging from 120kpps to 250kpps, averaging around the 150 - 180 range. Is this a reasonable way to be measuring ? -- +- Christopher Smith, Systems Administrator ------------------------------+ | Server & Security Group, Information Technology Services | | The University of Queensland, Brisbane, Australia, 4072 | +- Ph +61 7 3365 4046 | email csmith@its.uq.edu.au | Fax +61 7 3365 4065 -+ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Oct 9 18:18:45 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C287337B401 for ; Wed, 9 Oct 2002 18:18:42 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4A95A43E6E for ; Wed, 9 Oct 2002 18:18:42 -0700 (PDT) (envelope-from larse@ISI.EDU) Received: from isi.edu (nik.isi.edu [128.9.168.58]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g9A1IfC08384 for ; Wed, 9 Oct 2002 18:18:41 -0700 (PDT) Message-ID: <3DA4D571.2080207@isi.edu> Date: Wed, 09 Oct 2002 18:18:41 -0700 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: net Subject: in-kernel traffic generator? Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030202060300020306050305" 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. --------------ms030202060300020306050305 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, anyone know of an in-kernel traffic generator similar to UDPgen (http://www.fokus.gmd.de/research/cc/glone/employees/sebastian.zander/private/udpgen/) for Linux? Userland traffic generators have high overheads with small packets at Gigabit speeds. (If not, netgraph should allow an easy way to build one, no?) Thanks, Lars -- Lars Eggert USC Information Sciences Institute --------------ms030202060300020306050305 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJtjCC AzgwggKhoAMCAQICEGZFcrfMdPXPY3ZFhNAukQEwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vydmlj ZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkG CSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAw MDBaFw0wNDA4MjcyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2Vy dGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAw LjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZ gpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqd knWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYALQmJ7JRr6aFp AgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTI5NzAS BgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQAxsUtH XfkBceX1U2xdedY9mMAmE2KBIqcS+CKV6BtJtyd7BDm6/ObyJOuR+r3sDSo491BVqGz3Da1M G7wD9LXrokefbKIMWI0xQgkRbLAaadErErJAXWr5edDqLiXdiuT82w0fnQLzWtvKPPZE6iZp h39Ins6ln+eE2MliYq0FxjCCAzkwggKioAMCAQICAwglQTANBgkqhkiG9w0BAQQFADCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMB4XDTAyMDgyNDE4NTMzOVoX DTAzMDgyNDE4NTMzOVowVDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYD VQQDEwtMYXJzIEVnZ2VydDEcMBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBANI2Rrt4ggaQ/IrOsDeOm2H4/R5FRIL6JjDY3StE aogp1r23WKniQ1Vj98Nu5WxlaZ3Iam3Jen5T66H8u7rtMNpK4qAeAGoBsVeyVr1+CTFeuv+m xCh7BvBJwhLdm0zDaoDT05YKYZaqtsT+F286FWJQg31Xtf+vTKLVVrHcsafnteyal2NEt7Ac yZZfjsVLwxp2Lq3cwYfRQRoo7/yCVzS7HsgM6jmbO4taEMo4yC2rpnUbWEUCDTaCYgpAXzAl oiNk7GDh0wz2s5ZSnHRvNSBMAjCmpNtSYHfXFI1ANwrrrHIJ7Ei83+XN32PWY4OPzO3iown9 VR+vM+8lNx9OX28CAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIBBAQTTDJ1TXlmZkJO VWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEEBQADgYEAXcrIlKmPLM/r8r3oz2ZLPLaT1AyMjYTZY2qq/R7SUtFa9BNlTIFh DG78QKfJ9lo2LMzTPQqMZgNLmj95GbNPI8P8OIq2K6MeCZWz08ROackqTFP6xWbIFIfXcBVR 1dZnDDyDKBBh05KkvyTPawSQyOBUeNBfQUyO4TE+3o58U8UwggM5MIICoqADAgECAgMIJUEw DQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MDAeFw0wMjA4MjQxODUzMzlaFw0wMzA4MjQxODUzMzlaMFQxDzANBgNVBAQTBkVnZ2VydDEN MAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkqhkiG9w0BCQEWDWxh cnNlQGlzaS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDSNka7eIIGkPyK zrA3jpth+P0eRUSC+iYw2N0rRGqIKda9t1ip4kNVY/fDbuVsZWmdyGptyXp+U+uh/Lu67TDa SuKgHgBqAbFXsla9fgkxXrr/psQoewbwScIS3ZtMw2qA09OWCmGWqrbE/hdvOhViUIN9V7X/ r0yi1Vax3LGn57XsmpdjRLewHMmWX47FS8Madi6t3MGH0UEaKO/8glc0ux7IDOo5mzuLWhDK OMgtq6Z1G1hFAg02gmIKQF8wJaIjZOxg4dMM9rOWUpx0bzUgTAIwpqTbUmB31xSNQDcK66xy CexIvN/lzd9j1mODj8zt4qMJ/VUfrzPvJTcfTl9vAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIB ADAaMBgCAQQEE0wydU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVk dTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAF3KyJSpjyzP6/K96M9mSzy2k9QM jI2E2WNqqv0e0lLRWvQTZUyBYQxu/ECnyfZaNizM0z0KjGYDS5o/eRmzTyPD/DiKtiujHgmV s9PETmnJKkxT+sVmyBSH13AVUdXWZww8gygQYdOSpL8kz2sEkMjgVHjQX0FMjuExPt6OfFPF MYIDJzCCAyMCAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MAIDCCVBMAkGBSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTAyMTAxMDAxMTg0MVowIwYJKoZIhvcNAQkEMRYEFBjb8cZps6cQeo6Qv/nj qfbItth8MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0BCRACCzGB naCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJ Q2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZp Y2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMIJUEwDQYJ KoZIhvcNAQEBBQAEggEANvl5yX7yBpspdgPMNM/QouYwE0M4A5QzDG65k+ardhsrY4CGCISK 8F5QZXTHYZcV39IC+eMMRn3Md8UiRtis9kRg1Vpv8W0oCC4FCCyVd8pkEcZROZdjor0juuPG LcLHqqdZz9ICtf4EIm/FjbOkk7gZMYHmsY1n2aVwQAF+A6DSQ50dBTZG/It956S47JepdqTm 5BHvs/wFS/FnCF0dM9I+dMe7hCx2armY6JB2Ti1ClTvDjNAKmtUp1NWuhwujFmauLujWFdfh geCF0whTuvtiZIZbOvRwKmM8vu1niGd1mVTxsk/j2pKq3saoTqQbUHZSsFmYlpf3SkKPmzTP xgAAAAAAAA== --------------ms030202060300020306050305-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Oct 9 18:19: 3 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2C57637B401; Wed, 9 Oct 2002 18:19:00 -0700 (PDT) Received: from bunyip.cc.uq.edu.au (bunyip.cc.uq.edu.au [130.102.2.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C98A43E42; Wed, 9 Oct 2002 18:18:59 -0700 (PDT) (envelope-from csmith@its.uq.edu.au) Received: from [130.102.152.68] (tobermory.its.uq.edu.au [130.102.152.68]) by bunyip.cc.uq.edu.au (8.9.3/8.9.3) with ESMTP id LAA06621; Thu, 10 Oct 2002 11:18:51 +1000 (GMT+1000) User-Agent: Microsoft-Entourage/10.0.0.1309 Date: Thu, 10 Oct 2002 11:18:42 +1000 Subject: Re: High interrupt load on firewalls From: Christopher Smith To: Luigi Rizzo Cc: , Message-ID: In-Reply-To: <20021009170002.A54675@carp.icir.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On 10/10/02 10:00 AM, "Luigi Rizzo" wrote: > On Thu, Oct 10, 2002 at 09:38:40AM +1000, Christopher Smith wrote: > ... >> With the 2.4GHz 2650 we have currently, er, "borrowed" to do some testing >> with, the load is down to 35% or so (highest I've seen it is 40%) and the >> packet loss is less than 1 packet every 5 or 10 minutes. > > quite reasonable then, i wouldn't spend too much time in trying to > improve things, engineer's time is way more expensive than a new > box -- it adds up easily. True. We need to redo the whole ruleset though, simply for manageability reasons. May as well do some performance optimising at the same time. >> The existing firewall ruleset is not particularly optimised at all, and >> rewriting the whole thing is an ongoing project of mine. I might up the >> priority of this, given your comments. I get the impression that what >> appears from top to be a high interrupt load may simply be a high "system" >> load from ipfilter processing the packets. Is this correct ? Is there any >> (reasonably easy) way of checking ? > > you might have both problems -- the network stack operates as a soft > interrupt, whether this is accounted as intr or system activity i > am not sure. I tried a quick and dirty way by just dropping the whole ruleset for ~10 seconds. The interrupt load (in top) was about a third of "normal" for that time period. So, it appears the problem is definitely in the ruleset. >> What tools do you you use to test and measure performance for things like >> this ? > > nothing special, i have a trivial c program which loops around a sendto() > trying to push udp packets out as fast as possible, i disable icmp replies > with > net.inet.udp.blackhole=1 Ok, so any of the network benching products that can spit out a stream of UDP traffic should suffice ? > and then measure the card stats with > > ns -i -w 1 -d > > (ns is picobsd's version of netstat, in /usr/src/release/picobsd/tinyware/ns) > Be warned that some cards update the stats everi 1 or 2 seconds, so you might > have to up the refresh time from 1 second ('-w 1' above) to 2 or more seconds > ( -w 2 ...) Ok. Will normal netstat do ? I tried it on one of our machines and got these results: mr2fw2# netstat -w1 -i -d input (Total) output packets errs bytes packets errs bytes colls drops 39518 0 14415117 39509 0 28791210 0 0 50231 0 18969196 50117 0 37782558 0 0 50494 0 17912692 50212 0 35471676 0 0 53685 0 20592345 53547 0 40987500 0 0 44862 0 17009437 44897 0 33974566 0 0 mr2fw2# netstat -w10 -i -d input (Total) output packets errs bytes packets errs bytes colls drops 346558 0 112637886 346876 0 224797074 0 0 392474 0 132204783 392437 0 263929848 0 0 431339 0 139024315 431086 0 277224060 0 0 428132 0 135837843 427895 0 271022908 0 0 390021 0 131117003 389502 0 261278610 0 0 This only seems to indicate ca. 80kpps, which doesn't seem to agree with the numbers I see in 'systat -ip'. Is there a counter rolling over somewhere ? >> Also, are there any cards/chipsets you would recommend for firewalling high >> speed links like this ? > > no idea, i have only tried the intel pro/1000 which seems to work > reasonably well for what i have done so far (which is very little, > basically speed testing and porting the polling support to it), > but i have not tried any other GigE card. Ok then. Apparently there's a machine coming in soon with a Broadcom 5700-based 3Com card in it. Might try and purloin that for a day or two to do some experimenting on. -- +- Christopher Smith, Systems Administrator ------------------------------+ | Server & Security Group, Information Technology Services | | The University of Queensland, Brisbane, Australia, 4072 | +- Ph +61 7 3365 4046 | email csmith@its.uq.edu.au | Fax +61 7 3365 4065 -+ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Oct 9 18:22:20 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3BCE737B401 for ; Wed, 9 Oct 2002 18:22:19 -0700 (PDT) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 99E0543E3B for ; Wed, 9 Oct 2002 18:22:18 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: from khavrinen.lcs.mit.edu (localhost [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.3/8.12.5) with ESMTP id g9A1MHgQ059095 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 9 Oct 2002 21:22:18 -0400 (EDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.3/8.12.5/Submit) id g9A1MHhW059092; Wed, 9 Oct 2002 21:22:17 -0400 (EDT) (envelope-from wollman) Date: Wed, 9 Oct 2002 21:22:17 -0400 (EDT) From: Garrett Wollman Message-Id: <200210100122.g9A1MHhW059092@khavrinen.lcs.mit.edu> To: Lars Eggert Cc: net Subject: in-kernel traffic generator? In-Reply-To: <3DA4D571.2080207@isi.edu> References: <3DA4D571.2080207@isi.edu> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org < said: > anyone know of an in-kernel traffic generator similar to UDPgen > (http://www.fokus.gmd.de/research/cc/glone/employees/sebastian.zander/private/udpgen/) > for Linux? Userland traffic generators have high overheads with small > packets at Gigabit speeds. I wrote one a long time ago for John Wroclawski (back when 100 Mbit/s was still considered a high speed). I don't think I have the source any more, and even if I did it would require a lot of hacking to make it work (it was fairly intimate with the IP stack in 2.2.5). -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Oct 9 18:26:32 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D4F3237B404 for ; Wed, 9 Oct 2002 18:26:29 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6593E43E65 for ; Wed, 9 Oct 2002 18:26:29 -0700 (PDT) (envelope-from larse@ISI.EDU) Received: from isi.edu (nik.isi.edu [128.9.168.58]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g9A1QRC12716; Wed, 9 Oct 2002 18:26:27 -0700 (PDT) Message-ID: <3DA4D743.3050502@isi.edu> Date: Wed, 09 Oct 2002 18:26:27 -0700 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: Garrett Wollman Cc: net Subject: Re: in-kernel traffic generator? References: <3DA4D571.2080207@isi.edu> <200210100122.g9A1MHhW059092@khavrinen.lcs.mit.edu> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080004020805060402080401" 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. --------------ms080004020805060402080401 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Garrett Wollman wrote: > < said: > >>anyone know of an in-kernel traffic generator similar to UDPgen >>(http://www.fokus.gmd.de/research/cc/glone/employees/sebastian.zander/private/udpgen/) >>for Linux? Userland traffic generators have high overheads with small >>packets at Gigabit speeds. > > I wrote one a long time ago for John Wroclawski (back when 100 Mbit/s > was still considered a high speed). I don't think I have the source > any more, and even if I did it would require a lot of hacking to make > it work (it was fairly intimate with the IP stack in 2.2.5). I was just about to send email to John about it, after finding the PC-router page on Google... Was it part of the CAIRN tree? If so, I probably have it somewhere. Lars -- Lars Eggert USC Information Sciences Institute --------------ms080004020805060402080401 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJtjCC AzgwggKhoAMCAQICEGZFcrfMdPXPY3ZFhNAukQEwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vydmlj ZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkG CSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAw MDBaFw0wNDA4MjcyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2Vy dGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAw LjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZ gpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqd knWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYALQmJ7JRr6aFp AgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTI5NzAS BgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQAxsUtH XfkBceX1U2xdedY9mMAmE2KBIqcS+CKV6BtJtyd7BDm6/ObyJOuR+r3sDSo491BVqGz3Da1M G7wD9LXrokefbKIMWI0xQgkRbLAaadErErJAXWr5edDqLiXdiuT82w0fnQLzWtvKPPZE6iZp h39Ins6ln+eE2MliYq0FxjCCAzkwggKioAMCAQICAwglQTANBgkqhkiG9w0BAQQFADCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMB4XDTAyMDgyNDE4NTMzOVoX DTAzMDgyNDE4NTMzOVowVDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYD VQQDEwtMYXJzIEVnZ2VydDEcMBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBANI2Rrt4ggaQ/IrOsDeOm2H4/R5FRIL6JjDY3StE aogp1r23WKniQ1Vj98Nu5WxlaZ3Iam3Jen5T66H8u7rtMNpK4qAeAGoBsVeyVr1+CTFeuv+m xCh7BvBJwhLdm0zDaoDT05YKYZaqtsT+F286FWJQg31Xtf+vTKLVVrHcsafnteyal2NEt7Ac yZZfjsVLwxp2Lq3cwYfRQRoo7/yCVzS7HsgM6jmbO4taEMo4yC2rpnUbWEUCDTaCYgpAXzAl oiNk7GDh0wz2s5ZSnHRvNSBMAjCmpNtSYHfXFI1ANwrrrHIJ7Ei83+XN32PWY4OPzO3iown9 VR+vM+8lNx9OX28CAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIBBAQTTDJ1TXlmZkJO VWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEEBQADgYEAXcrIlKmPLM/r8r3oz2ZLPLaT1AyMjYTZY2qq/R7SUtFa9BNlTIFh DG78QKfJ9lo2LMzTPQqMZgNLmj95GbNPI8P8OIq2K6MeCZWz08ROackqTFP6xWbIFIfXcBVR 1dZnDDyDKBBh05KkvyTPawSQyOBUeNBfQUyO4TE+3o58U8UwggM5MIICoqADAgECAgMIJUEw DQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MDAeFw0wMjA4MjQxODUzMzlaFw0wMzA4MjQxODUzMzlaMFQxDzANBgNVBAQTBkVnZ2VydDEN MAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkqhkiG9w0BCQEWDWxh cnNlQGlzaS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDSNka7eIIGkPyK zrA3jpth+P0eRUSC+iYw2N0rRGqIKda9t1ip4kNVY/fDbuVsZWmdyGptyXp+U+uh/Lu67TDa SuKgHgBqAbFXsla9fgkxXrr/psQoewbwScIS3ZtMw2qA09OWCmGWqrbE/hdvOhViUIN9V7X/ r0yi1Vax3LGn57XsmpdjRLewHMmWX47FS8Madi6t3MGH0UEaKO/8glc0ux7IDOo5mzuLWhDK OMgtq6Z1G1hFAg02gmIKQF8wJaIjZOxg4dMM9rOWUpx0bzUgTAIwpqTbUmB31xSNQDcK66xy CexIvN/lzd9j1mODj8zt4qMJ/VUfrzPvJTcfTl9vAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIB ADAaMBgCAQQEE0wydU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVk dTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAF3KyJSpjyzP6/K96M9mSzy2k9QM jI2E2WNqqv0e0lLRWvQTZUyBYQxu/ECnyfZaNizM0z0KjGYDS5o/eRmzTyPD/DiKtiujHgmV s9PETmnJKkxT+sVmyBSH13AVUdXWZww8gygQYdOSpL8kz2sEkMjgVHjQX0FMjuExPt6OfFPF MYIDJzCCAyMCAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MAIDCCVBMAkGBSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTAyMTAxMDAxMjYyN1owIwYJKoZIhvcNAQkEMRYEFIbE/HuecjwKE1Z/2A+0 ApMrS8tkMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0BCRACCzGB naCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJ Q2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZp Y2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMIJUEwDQYJ KoZIhvcNAQEBBQAEggEAzhgMChyDcXEYgHY2fFFso9mOfirnpbvXAbwwLxGTo8NstMqb33q0 hNvhPTKe2F/8PiRiXGETabmdeqUy2N0NhXiskfLWCTtj0IS/7Q6ABVEYaqSryUValPSc+wF9 tR0JtXQA/KX8XbCqPmWVKxsw6mWXEHAU3tPLJ9Z1Cg+4nK4mHAA4t+Xi85H/+B0AIY0UObC+ AJGt1rVXKuJXy/tsLJZ1AjousigZ4ijSW//qoTtnKKWEuB/CvrX8WI0MoTzrscunyTpkFF5u 5gw53OpoTF93DWwplOmRlz8jSRYYwsQtAORdy3g93Ca8iXc2G9nIIk9mDBTjOVRd+2M9F/Uh ugAAAAAAAA== --------------ms080004020805060402080401-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Oct 9 18:51: 4 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0CB5E37B401; Wed, 9 Oct 2002 18:51:03 -0700 (PDT) Received: from carp.icir.org (carp.icir.org [192.150.187.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id B322143E3B; Wed, 9 Oct 2002 18:51:02 -0700 (PDT) (envelope-from rizzo@carp.icir.org) Received: from carp.icir.org (localhost [127.0.0.1]) by carp.icir.org (8.12.3/8.12.3) with ESMTP id g9A1p2O2055508; Wed, 9 Oct 2002 18:51:02 -0700 (PDT) (envelope-from rizzo@carp.icir.org) Received: (from rizzo@localhost) by carp.icir.org (8.12.3/8.12.3/Submit) id g9A1p2Gn055507; Wed, 9 Oct 2002 18:51:02 -0700 (PDT) (envelope-from rizzo) Date: Wed, 9 Oct 2002 18:51:02 -0700 From: Luigi Rizzo To: Christopher Smith Cc: hardware@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: High interrupt load on firewalls Message-ID: <20021009185102.A55432@carp.icir.org> References: <20021009170002.A54675@carp.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 csmith@its.uq.edu.au on Thu, Oct 10, 2002 at 11:18:42AM +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 Thu, Oct 10, 2002 at 11:18:42AM +1000, Christopher Smith wrote: ... > Ok, so any of the network benching products that can spit out a stream of > UDP traffic should suffice ? i presume so, yes. I have some tweaks in the kernel to duplicate packets in the kernel and get higher peak rates, but the patches for that are broken at the moment. > Ok. Will normal netstat do ? I tried it on one of our machines and got yes, the only advantage of "ns" is that it shows multiple interfaces and does not scroll the screen. > This only seems to indicate ca. 80kpps, which doesn't seem to agree with the > numbers I see in 'systat -ip'. Is there a counter rolling over somewhere ? no idea. BTW it seems that you are adding in and out traffic. when i said 260kpps i meant that the box was receiving 260kpps (actually more) and transmitting 260kpps. On the other hand i had basically no firewall work, so that is in line with your numbers. 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 Oct 9 19:20:22 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EFD5537B401 for ; Wed, 9 Oct 2002 19:20:20 -0700 (PDT) Received: from sccrmhc01.attbi.com (sccrmhc01.attbi.com [204.127.202.61]) by mx1.FreeBSD.org (Postfix) with ESMTP id 778EA43E42 for ; Wed, 9 Oct 2002 19:20:20 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by sccrmhc01.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20021010022019.WTOE29655.sccrmhc01.attbi.com@InterJet.elischer.org>; Thu, 10 Oct 2002 02:20: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 TAA48892; Wed, 9 Oct 2002 19:12:29 -0700 (PDT) Date: Wed, 9 Oct 2002 19:12:29 -0700 (PDT) From: Julian Elischer To: Lars Eggert Cc: net Subject: Re: in-kernel traffic generator? In-Reply-To: <3DA4D571.2080207@isi.edu> 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, 9 Oct 2002, Lars Eggert wrote: > Hi, > > anyone know of an in-kernel traffic generator similar to UDPgen > (http://www.fokus.gmd.de/research/cc/glone/employees/sebastian.zander/private/udpgen/) > for Linux? Userland traffic generators have high overheads with small > packets at Gigabit speeds. > > (If not, netgraph should allow an easy way to build one, no?) it will need somethign to activate it (clock?), but yes > > Thanks, > Lars > -- > Lars Eggert USC Information Sciences Institute > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Oct 9 19:52:58 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EFA3937B401; Wed, 9 Oct 2002 19:52:56 -0700 (PDT) Received: from nuit.iteration.net (nuit.iteration.net [198.92.249.80]) by mx1.FreeBSD.org (Postfix) with ESMTP id AF75743E65; Wed, 9 Oct 2002 19:52:56 -0700 (PDT) (envelope-from keichii@nuit.iteration.net) Received: by nuit.iteration.net (Postfix, from userid 1001) id 30F9A11B641; Wed, 9 Oct 2002 19:47:30 -0700 (PDT) Date: Wed, 9 Oct 2002 19:47:30 -0700 From: "Michael C. Wu" To: luigi@freebsd.org, darrenr@freebsd.org Cc: freebsd-net@freebsd.org Subject: DAWG for IPFW2/IPF Message-ID: <20021010024730.GA25358@nuit.iteration.net> Reply-To: "Michael C. Wu" Mail-Followup-To: "Michael C. Wu" , luigi@freebsd.org, darrenr@freebsd.org, freebsd-net@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-PGP-Fingerprint: 5025 F691 F943 8128 48A8 5025 77CE 29C5 8FA1 2E20 X-PGP-Key-ID: 0x8FA12E20 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 Luigi and Darren, Regarding IPFW2 and IPF, do you have plans on implementing a DAWG algorithm for the pattern matching? (Directed Acyclic Word Graphs) http://citeseer.nj.nec.com/crochemore99fast.html It is a new algorithm that does super fast multiple stream/pattern matching in a given n-length string within O(n) . The traditional fastest Knuth algorithm only does two streams, while DAWG's do multiple streams. We use it in Bioinformatics research to match DNA sequences. However, I know for a fact that applying DAWG's to router/firewall situations would be very appropriate. Forgive my not knowing about our regex(3) implementation, what algorithm exactly does our regex(3) do/use? I was thinking that we may possibly add kernel/userland libraries for a DAWG regex. And I am willing to do the work. What do you think? Does anyone else have thoughts about this? Thanks, Michael To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Oct 9 20:37:53 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 23A4837B411; Wed, 9 Oct 2002 20:37:50 -0700 (PDT) Received: from carp.icir.org (carp.icir.org [192.150.187.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id 933BE43E4A; Wed, 9 Oct 2002 20:37:50 -0700 (PDT) (envelope-from rizzo@carp.icir.org) Received: from carp.icir.org (localhost [127.0.0.1]) by carp.icir.org (8.12.3/8.12.3) with ESMTP id g9A3boO2056145; Wed, 9 Oct 2002 20:37:50 -0700 (PDT) (envelope-from rizzo@carp.icir.org) Received: (from rizzo@localhost) by carp.icir.org (8.12.3/8.12.3/Submit) id g9A3bo8k056144; Wed, 9 Oct 2002 20:37:50 -0700 (PDT) (envelope-from rizzo) Date: Wed, 9 Oct 2002 20:37:50 -0700 From: Luigi Rizzo To: "Michael C. Wu" Cc: darrenr@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: DAWG for IPFW2/IPF Message-ID: <20021009203750.A55843@carp.icir.org> References: <20021010024730.GA25358@nuit.iteration.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20021010024730.GA25358@nuit.iteration.net>; from keichii@iteration.net on Wed, Oct 09, 2002 at 07:47:30PM -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, Oct 09, 2002 at 07:47:30PM -0700, Michael C. Wu wrote: > Hi Luigi and Darren, > > Regarding IPFW2 and IPF, do you have plans on implementing a DAWG algorithm > for the pattern matching? (Directed Acyclic Word Graphs) my quick answer is no -- it might be interesting stuff, but have too much stuff on my plate... cheers luigi > http://citeseer.nj.nec.com/crochemore99fast.html > > It is a new algorithm that does super fast multiple stream/pattern > matching in a given n-length string within O(n) . > The traditional fastest Knuth algorithm only does > two streams, while DAWG's do multiple streams. We use it in > Bioinformatics research to match DNA sequences. However, I know > for a fact that applying DAWG's to router/firewall situations > would be very appropriate. > > Forgive my not knowing about our regex(3) implementation, > what algorithm exactly does our regex(3) do/use? > > I was thinking that we may possibly add kernel/userland libraries > for a DAWG regex. And I am willing to do the work. > > What do you think? Does anyone else have thoughts about this? > > Thanks, > Michael > > 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 Thu Oct 10 11: 4:55 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7463037B401 for ; Thu, 10 Oct 2002 11:04:54 -0700 (PDT) Received: from kali.avantgo.com (shadow.avantgo.com [64.157.226.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 33DF443EAC for ; Thu, 10 Oct 2002 11:04:54 -0700 (PDT) (envelope-from scott@avantgo.com) Received: from river.avantgo.com ([10.11.30.114]) by kali.avantgo.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 10 Oct 2002 11:04:54 -0700 Date: Thu, 10 Oct 2002 11:04:49 -0700 (PDT) From: Scott Hess To: freebsd-net@freebsd.org Subject: net.inet.tcp.inflight_enable and dynamic mbuf caps. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 10 Oct 2002 18:04:54.0131 (UTC) FILETIME=[89022430:01C27087] 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 4.7 release notes have: "The tcp(4) protocol now has the ability to dynamically limit the send-side window to maximize bandwidth and minimize round trip times. The feature can be enabled via the net.inet.tcp.inflight_enable sysctl." I recall being interested in this back when it was being discussed on the lists. We have a set of intelligent proxies which mediate between connections from the wild and the server cluster. One issue we had was that we wanted big send buffers, because the kernel should be able to manage the buffering much better than userland. Unfortunately, we also have to limit the send buffer size to reduce DoS issues. What would be nice is if the send buffer size could be dynamically tuned to cause the overall mbuf usage asymptotically approach some conf value. For instance, if 75% of the mbuf space is used, then the maximum send buffer could be scaled to 25% of the normal size. [I'm not certain how to derive better numbers, so that's a guess.] Basically, what I'm suggesting is that until, say, 25% of the mbufs are used, each connection can get 100% of the configured send buffers, then from 25%-50% used they can only get 75%, then from 50%-75% used they can only get 50%, and so on. You never _quite_ get to the point where you can't make new connections due to mbuf starvation, but you might end up with very constricted pipe. [It would be slicker to do that in a per-host or per-network way, but that would probably be significantly more complex.] Thanks, scott To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Oct 10 12:15:13 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2614937B401 for ; Thu, 10 Oct 2002 12:15:12 -0700 (PDT) Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9601343E9E for ; Thu, 10 Oct 2002 12:15:11 -0700 (PDT) (envelope-from archie@dellroad.org) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id MAA70656; Thu, 10 Oct 2002 12:09:10 -0700 (PDT) Received: from arch20m.dellroad.org (localhost [127.0.0.1]) by arch20m.dellroad.org (8.12.6/8.12.6) with ESMTP id g9AJ82ON013075; Thu, 10 Oct 2002 12:08:02 -0700 (PDT) (envelope-from archie@arch20m.dellroad.org) Received: (from archie@localhost) by arch20m.dellroad.org (8.12.6/8.12.6/Submit) id g9AJ81Bs013074; Thu, 10 Oct 2002 12:08:01 -0700 (PDT) From: Archie Cobbs Message-Id: <200210101908.g9AJ81Bs013074@arch20m.dellroad.org> Subject: Re: Netgraph and fxp0 interface? In-Reply-To: <20021006221340.A7583@attbi.com> "from Craig Rodrigues at Oct 6, 2002 10:13:40 pm" To: Craig Rodrigues Date: Thu, 10 Oct 2002 12:08:01 -0700 (PDT) Cc: freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Craig Rodrigues writes: > > you can probably get it by: > > kldload ng_ether > > Ah, OK, if I did kldload ng_ether and then did > nghook -a fxp0: divert > > it then worked. > > This wasn't clear from the daemonnews.org tutorial. When that tutorial was written, ng_ether.ko did not exist, so you got it with options NETGRAPH. Since then it's been split into a separate options NETGRAPH_ETHER and KLD. -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 Oct 10 12:15:14 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D67D437B404; Thu, 10 Oct 2002 12:15:12 -0700 (PDT) Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 46D3E43E9E; Thu, 10 Oct 2002 12:15:12 -0700 (PDT) (envelope-from archie@dellroad.org) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id MAA70665; Thu, 10 Oct 2002 12:11:31 -0700 (PDT) Received: from arch20m.dellroad.org (localhost [127.0.0.1]) by arch20m.dellroad.org (8.12.6/8.12.6) with ESMTP id g9AJAMON013105; Thu, 10 Oct 2002 12:10:23 -0700 (PDT) (envelope-from archie@arch20m.dellroad.org) Received: (from archie@localhost) by arch20m.dellroad.org (8.12.6/8.12.6/Submit) id g9AJAMQj013104; Thu, 10 Oct 2002 12:10:22 -0700 (PDT) From: Archie Cobbs Message-Id: <200210101910.g9AJAMQj013104@arch20m.dellroad.org> Subject: Re: Parsing route dump received using sysctl In-Reply-To: <20021004162657.GB91159@sunbay.com> "from Ruslan Ermilov at Oct 4, 2002 07:26:57 pm" To: Ruslan Ermilov Date: Thu, 10 Oct 2002 12:10:22 -0700 (PDT) Cc: yatin chalke , freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Ruslan Ermilov writes: > > I am currently trying to get a route dump in > > freebsd4.4 using sysctl with NET_RT_DUMP. > > > > I am running into problems while parsing the returned > > rt_msghdr structures. > > Look at the route(8) code, you're probably missing the > necessary alignments (with the ROUNDUP() macro). Alternately, use the uroute(3) routines in the devel/libpdel port.. http://www.dellroad.org/manpage?page=uroute -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 Oct 10 12:30:12 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3804637B401 for ; Thu, 10 Oct 2002 12:30:10 -0700 (PDT) Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 72F4043E4A for ; Thu, 10 Oct 2002 12:30:09 -0700 (PDT) (envelope-from archie@dellroad.org) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id MAA70757; Thu, 10 Oct 2002 12:15:25 -0700 (PDT) Received: from arch20m.dellroad.org (localhost [127.0.0.1]) by arch20m.dellroad.org (8.12.6/8.12.6) with ESMTP id g9AJEGON013111; Thu, 10 Oct 2002 12:14:16 -0700 (PDT) (envelope-from archie@arch20m.dellroad.org) Received: (from archie@localhost) by arch20m.dellroad.org (8.12.6/8.12.6/Submit) id g9AJEGFn013110; Thu, 10 Oct 2002 12:14:16 -0700 (PDT) From: Archie Cobbs Message-Id: <200210101914.g9AJEGFn013110@arch20m.dellroad.org> Subject: Re: Problem with mpd / pptp link between FreeBSD and win98 In-Reply-To: "from Mikael Hybsch at Oct 8, 2002 10:12:12 pm" To: Mikael Hybsch Date: Thu, 10 Oct 2002 12:14:16 -0700 (PDT) Cc: freebsd-net@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Mikael Hybsch writes: > I'm trying to run a pptp link to secure the wireless traffic between > my FreeBSD server/firewall and a win98 machine. I'm using 2 D-Link 520. > The D-Link in the FreeBSD server is running in Host-AP mode. > The wireless link itself works fine. > > The problem is that whenever I download a file to the win98 machine the > pptp connection randomly freezes after a few megabytes and I get the > message below in /var/log/messages. The number is always around 4000. > After this I have to reconnect to continue. > I have tried 40 and 128 bit encryption with the same result. > > Oct 7 21:30:56 snaps /kernel: ng_mppc_decompress: insane jump 4083 > > Does someone have any idea about this? > > === > > I just had a quick look at the code and some more debugging shows > that the new sequence number is less than the current. Does this mean that > mppc got fed an old packet? > > /kernel: ng_mppc_decompress: insane jump 4089: (1690-1697) & 0xfff Yes. PPP relies on packets not being re-ordered, and the PPTP/GRE implementation assures this. So something is broken somewhere, either in FreeBSD or the Windows machine. Try updating your Win98 with the latest MSDUN1.2 update or whatever. > On a related issue, there is a new l2tp netgraph module. Is there any > work in progress to, for example, extend mpd to be able to act as a l2tp > server? I'm planning to do this eventually but not soon. Anyone else of course is free to start hacking on mpd, ppp(8), etc. as well. -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 Oct 10 13: 9:19 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9044B37B401 for ; Thu, 10 Oct 2002 13:09:18 -0700 (PDT) Received: from obsidian.sentex.ca (obsidian.sentex.ca [64.7.128.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id F083643EAC for ; Thu, 10 Oct 2002 13:09:17 -0700 (PDT) (envelope-from damian@sentex.net) Received: from pegmatite (pyroxene.sentex.ca [199.212.134.18]) (authenticated bits=0) by obsidian.sentex.ca (8.12.6/8.12.6) with ESMTP id g9AK9FBE095259 for ; Thu, 10 Oct 2002 16:09:16 -0400 (EDT) (envelope-from damian@sentex.net) Date: Thu, 10 Oct 2002 16:08:26 -0400 From: Damian Gerow X-Mailer: The Bat! (v1.61) Organization: Sentex Data Communications X-Priority: 3 (Normal) Message-ID: <64592473972.20021010160826@sentex.net> To: freebsd-net@freebsd.org Subject: DHCP and media selection on bootup MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: By Sentex Communications (obsidian/20020517) X-Spam-Status: No, hits=-2.5 required=5.0 tests=NOSPAM_INC,SPAM_PHRASE_00_01,USER_AGENT_THEBAT version=2.41 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 haven't seen anything on this, but have just run into it when trying to set up a machine. We have a FreeBSD workstation that retrieves its IP address via DHCP. Normally this works all fine and dandy, but if the card autoselects the media to the wrong type, then there's no DHCP. The only way I've found around this is to create a script in /usr/local/etc/rc.d that does the ifconfig and dhclient itself. I've tried setting to ifconfig_fxp0 lines in /etc/rc.conf, the first for the media selection and the second for the DHCP instruction, but that didn't work -- the card stayed in autoselect. The only thing I haven't tried is "DHCP media mediaopt ", but I'm not sure this will work. Is there any way to manually set the NIC media, while retreiving the IP address via DHCP? - Damian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Oct 10 13:11:30 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C8DF637B401 for ; Thu, 10 Oct 2002 13:11:29 -0700 (PDT) Received: from obsidian.sentex.ca (obsidian.sentex.ca [64.7.128.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 27CCF43EB3 for ; Thu, 10 Oct 2002 13:11:29 -0700 (PDT) (envelope-from damian@sentex.net) Received: from pegmatite (pyroxene.sentex.ca [199.212.134.18]) (authenticated bits=0) by obsidian.sentex.ca (8.12.6/8.12.6) with ESMTP id g9AKBRBE095343 for ; Thu, 10 Oct 2002 16:11:27 -0400 (EDT) (envelope-from damian@sentex.net) Date: Thu, 10 Oct 2002 16:10:38 -0400 From: Damian Gerow X-Mailer: The Bat! (v1.61) Organization: Sentex Data Communications X-Priority: 3 (Normal) Message-ID: <130592605782.20021010161038@sentex.net> To: freebsd-net@FreeBSD.ORG Subject: Re: DHCP and media selection on bootup In-Reply-To: <64592473972.20021010160826@sentex.net> References: <64592473972.20021010160826@sentex.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: By Sentex Communications (obsidian/20020517) X-Spam-Status: No, hits=-11.3 required=5.0 tests=IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT_THEBAT version=2.41 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 Spake Damian Gerow on 10/10/2002, 16:08:26 -0400: > I've tried setting to ifconfig_fxp0 lines in /etc/rc.conf, the first (Ack -- s/to/two/. Sorry.) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Oct 10 13:42:20 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 24ED737B401 for ; Thu, 10 Oct 2002 13:42:19 -0700 (PDT) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with SMTP id AE29043EC2 for ; Thu, 10 Oct 2002 13:42:17 -0700 (PDT) (envelope-from oppermann@pipeline.ch) Received: (qmail 47423 invoked from network); 10 Oct 2002 20:39:19 -0000 Received: from unknown (HELO pipeline.ch) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 10 Oct 2002 20:39:19 -0000 Message-ID: <3DA5E5E5.D613444E@pipeline.ch> Date: Thu, 10 Oct 2002 22:41:09 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Scott Hess Cc: freebsd-net@freebsd.org Subject: Re: net.inet.tcp.inflight_enable and dynamic mbuf caps. References: 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 Scott Hess wrote: > > The 4.7 release notes have: > > "The tcp(4) protocol now has the ability to dynamically limit the > send-side window to maximize bandwidth and minimize round trip times. The > feature can be enabled via the net.inet.tcp.inflight_enable sysctl." > > I recall being interested in this back when it was being discussed on the > lists. We have a set of intelligent proxies which mediate between > connections from the wild and the server cluster. One issue we had was > that we wanted big send buffers, because the kernel should be able to > manage the buffering much better than userland. > > Unfortunately, we also have to limit the send buffer size to reduce DoS > issues. What would be nice is if the send buffer size could be > dynamically tuned to cause the overall mbuf usage asymptotically approach > some conf value. For instance, if 75% of the mbuf space is used, then the > maximum send buffer could be scaled to 25% of the normal size. [I'm not > certain how to derive better numbers, so that's a guess.] > > Basically, what I'm suggesting is that until, say, 25% of the mbufs are > used, each connection can get 100% of the configured send buffers, then > from 25%-50% used they can only get 75%, then from 50%-75% used they can > only get 50%, and so on. You never _quite_ get to the point where you > can't make new connections due to mbuf starvation, but you might end up > with very constricted pipe. Have a look at this: http://www.psc.edu/networking/auto.html This is paper describing such autotuning socket buffers together with a fair-share algorithm. Once we (Claudio and I) are done with the natd, tcphostcache and routing table reworkings we might takle this. But if anyone wants to start earlier please feel free to do so :-) -- Andre > [It would be slicker to do that in a per-host or per-network way, but that > would probably be significantly more complex.] > > Thanks, > scott > > 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 Thu Oct 10 18:42:27 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 969D737B401 for ; Thu, 10 Oct 2002 18:42:25 -0700 (PDT) Received: from nwd2mime2.analog.com (nwd2mime2.analog.com [137.71.25.114]) by mx1.FreeBSD.org (Postfix) with ESMTP id 03DA343EAA for ; Thu, 10 Oct 2002 18:42:25 -0700 (PDT) (envelope-from rafiq.shaikh@analog.com) Received: from nwd2gtw1 (unverified) by nwd2mime2.analog.com (Content Technologies SMTPRS 4.2.10) with SMTP id for ; Thu, 10 Oct 2002 21:42:16 -0400 Received: from nwd2mhb1 ([137.71.5.12]) by nwd2gtw1; Thu, 10 Oct 2002 21:42:15 -0400 (EDT) Received: from golf.cpgdesign.analog.com ([137.71.139.100]) by nwd2mhb1.analog.com with ESMTP (8.9.3 (PHNE_18979)/8.7.1) id VAA05619 for ; Thu, 10 Oct 2002 21:42:14 -0400 (EDT) Received: from analog.com ([137.71.139.128]) by golf.cpgdesign.analog.com (8.9.1/8.9.1) with ESMTP id SAA02120 for ; Thu, 10 Oct 2002 18:42:13 -0700 (PDT) Message-ID: <3DA62BFF.9038DD41@analog.com> Date: Thu, 10 Oct 2002 18:40:15 -0700 From: Rafiq Shaikh X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: new member 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 this is test mail please ignore. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Oct 10 19:33:23 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E9AC937B401; Thu, 10 Oct 2002 19:33:21 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by mx1.FreeBSD.org (Postfix) with ESMTP id A1BD943E8A; Thu, 10 Oct 2002 19:33:20 -0700 (PDT) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from localhost ([3ffe:501:4819:2000:200:39ff:fe10:85d7]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g9B2XAt31374; Fri, 11 Oct 2002 11:33:10 +0900 (JST) Date: Fri, 11 Oct 2002 11:33:52 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Sam Leffler" Cc: "Julian Elischer" , , Subject: Re: CFR: m_tag patch In-Reply-To: <18d301c26e5e$8b5c7a30$52557f42@errno.com> References: <18d301c26e5e$8b5c7a30$52557f42@errno.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 42 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, 7 Oct 2002 17:06:25 -0700, >>>>> "Sam Leffler" said: >> > If you allocate tag id's using your 32-bit time scheme then the fixed > values >> > above would never be hit since they are all for impossible times and so >> > there'd be no conflict. >> >> Just make them all IDs in a single "Legacy" API >> > Good idea; I see the way out. Try this: > struct m_tag { > SLIST_ENTRY(m_tag) m_tag_link; /* List of packet tags */ > u_int16_t m_tag_id; /* Tag ID */ > u_int16_t m_tag_len; /* Length of data */ > u_int32_t m_tag_cookie; /* Module/ABI */ > }; > Then define the "Legacy ABI" to be zero (or whatever you want). Then all > the m_tag_* routines that I specified work only for the Legacy ABI. > (Whether this is done with shims or whatever doesn't matter.) This gives me > the compatiblity I want with openbsd and gives you the functionality you > need for netgraph. For new work we can specify users should avoid the > Legacy ABI. > Cost is basically 4 bytes per tag and an extra compare when walking the > tags. Happy? Sorry for interrupting, but please let me make it sure. Do you intend to hide the additional member from other modules than the m_tag internal? I'm afraid a story that (e.g.) some code fragments in the network layer directly refers to m_tag_cookie, which will break source level compatibility with other BSDs (when the code fragments are shared with others). As suz said before, we (KAME) are very much afraid of this kind of story. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 11 0: 6: 6 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C45B437B404 for ; Fri, 11 Oct 2002 00:06:05 -0700 (PDT) Received: from cs.rice.edu (cs.rice.edu [128.42.1.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC37F43EAF for ; Fri, 11 Oct 2002 00:06:04 -0700 (PDT) (envelope-from hykim@cs.rice.edu) Received: from localhost (localhost [127.0.0.1]) by cs.rice.edu (Postfix) with ESMTP id 28B684AAB4 for ; Fri, 11 Oct 2002 02:06:04 -0500 (CDT) Received: from frosty.cs.rice.edu (frosty.cs.rice.edu [128.42.1.20]) by cs.rice.edu (Postfix) with ESMTP id 900BB4AAAE for ; Fri, 11 Oct 2002 02:06:03 -0500 (CDT) Received: from localhost (hykim@localhost) by frosty.cs.rice.edu (8.9.3+Sun/8.9.0) with ESMTP id CAA06696 for ; Fri, 11 Oct 2002 02:06:01 -0500 (CDT) X-Authentication-Warning: frosty.cs.rice.edu: hykim owned process doing -bs Date: Fri, 11 Oct 2002 02:06:01 -0500 (CDT) From: Hyong-Youb Kim To: Subject: Tigon 3 bad checksums on TCP packets Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS snapshot-20020300 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 been recently testing 3C996B-T board in an Athlon system. The system has TigerMP board and a single Athlon 2000+ and runs FreeBSD 4.7-RC. With bge driver, every thing works fine except that the NIC piles up bad checksums on TCP receive packets. For instance, netperf TCP_STREAM from another machine would pile up bad checksums. What is most amazing to me is that NIC works fine with UDP receive packets. As far as I have experienced, TCP/UDP checksumming in NIC should have little or no difference. Too bad that the firmware is under NDA. I am wondering if any one had this problem. Any help will be greatly appreciated. John To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 11 4:27:41 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C525837B401 for ; Fri, 11 Oct 2002 04:27:40 -0700 (PDT) Received: from hotmail.com (f83.law9.hotmail.com [64.4.9.83]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C93643E75 for ; Fri, 11 Oct 2002 04:27:40 -0700 (PDT) (envelope-from soheil_h_y@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 11 Oct 2002 04:27:40 -0700 Received: from 213.217.52.214 by lw9fd.law9.hotmail.msn.com with HTTP; Fri, 11 Oct 2002 11:27:40 GMT X-Originating-IP: [213.217.52.214] From: "soheil hassas yeganeh" To: freebsd-net@FreeBSD.ORG Subject: IP bad cksum (0!) Date: Fri, 11 Oct 2002 14:57:40 +0330 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 11 Oct 2002 11:27:40.0404 (UTC) FILETIME=[3569C340:01C27119] 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 list to recompute the checksum of the ip packets i wrote this lines in the ip_input.c files : ip->ip_sum =0 ; if(hlen == sizeof(struct ip)) ip->ip_sum = in_cksum_hdr(ip); else ip->ip_sum = in_cksum(m,hlen); When i make a dump it says that it has bad cksum 0! 12:25:11.858759 62.217.112.165 > 66.201.71.98: icmp: echo reply (ttl 42, id 17879, len 84, bad cksum 0!) I don't know why this doesn't work ?????? THANX _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 11 4:42:17 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 00D2E37B401 for ; Fri, 11 Oct 2002 04:42:17 -0700 (PDT) Received: from zelax.ru (rosa.zelax.ru [212.188.91.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id 187B943EAF for ; Fri, 11 Oct 2002 04:41:58 -0700 (PDT) (envelope-from wr@zelax.ru) Received: (from root@localhost) by zelax.ru (8.9.3/8.9.3) id PAA58201 for freebsd-net@FreeBSD.ORG.KAV; Fri, 11 Oct 2002 15:41:32 +0400 (MSD) (envelope-from wr@zelax.ru) Received: from zelax.ru (slava.local [192.168.11.152]) by zelax.ru (8.9.3/8.9.3) with ESMTP id PAA58185; Fri, 11 Oct 2002 15:41:31 +0400 (MSD) (envelope-from wr@zelax.ru) Message-ID: <3DA71B2D.9010702@zelax.ru> Date: Fri, 11 Oct 2002 14:40:45 -0400 From: "Vyacheslav V. Burdjanadze" Organization: ZELAX User-Agent: Mozilla/5.0 (compatible; MSIE5.5; Windows 98; X-Accept-Language: ru, en MIME-Version: 1.0 To: soheil hassas yeganeh Cc: freebsd-net@FreeBSD.ORG Subject: Re: IP bad cksum (0!) References: Content-Type: text/plain; charset=KOI8-R; 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 > 12:25:11.858759 62.217.112.165 > 66.201.71.98: icmp: echo reply (ttl 42, > id 17879, len 84, bad cksum 0!) > > I don't know why this doesn't work ?????? Not sure if this is an IP sum error. Seems to be bad ICMP checksum. -- - " Why do you call this software 'beta' ? " - " Cuz it beta than nothin' ! " To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 11 5:50: 2 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 773D737B401 for ; Fri, 11 Oct 2002 05:50:01 -0700 (PDT) Received: from ares.cs.Virginia.EDU (ares.cs.Virginia.EDU [128.143.137.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id B8ED543EA3 for ; Fri, 11 Oct 2002 05:50:00 -0700 (PDT) (envelope-from nicolas@cs.virginia.edu) Received: from arachnion.cs.Virginia.EDU (arachnion.cs.Virginia.EDU [128.143.136.20]) by ares.cs.Virginia.EDU (8.9.3+Sun/8.9.2/UVACS-2000040300) with ESMTP id IAA24623 for ; Fri, 11 Oct 2002 08:49:59 -0400 (EDT) Received: from localhost (nc2y@localhost) by arachnion.cs.Virginia.EDU (8.9.2/8.9.2) with ESMTP id IAA03738 for ; Fri, 11 Oct 2002 08:49:59 -0400 (EDT) X-Authentication-Warning: arachnion.cs.Virginia.EDU: nc2y owned process doing -bs Date: Fri, 11 Oct 2002 08:49:59 -0400 (EDT) From: Nicolas Christin X-X-Sender: nc2y@arachnion.cs.Virginia.EDU To: freebsd-net@FreeBSD.ORG Subject: Re: IP bad cksum (0!) In-Reply-To: Message-ID: Organization: University of Virginia - CS Dept. 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 Fri, 11 Oct 2002, soheil hassas yeganeh wrote: > ip->ip_sum = in_cksum(m,hlen); > > When i make a dump it says that it has bad cksum 0! > > 12:25:11.858759 62.217.112.165 > 66.201.71.98: icmp: echo reply (ttl 42, id > 17879, len 84, bad cksum 0!) I'm not that familiar with the code, but I'd be surprised if ICMP packets were handled by IP functions. (ICMP is not IP.) Not sure where your checksum problem comes from. -- Nicolas Christin Ph.D. Candidate, University of Virginia, Computer Science http://www.cs.virginia.edu/~nicolas To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 11 10:55:55 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BF0E237B401 for ; Fri, 11 Oct 2002 10:55:54 -0700 (PDT) Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 50F7843E97 for ; Fri, 11 Oct 2002 10:55:54 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.5/8.12.5) with ESMTP id g9BHtnj1096271; Fri, 11 Oct 2002 11:55:49 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.5/8.12.5/Submit) id g9BHtn0F096270; Fri, 11 Oct 2002 11:55:49 -0600 (MDT) (envelope-from rousskov) Date: Fri, 11 Oct 2002 11:55:49 -0600 (MDT) From: Alex Rousskov To: Damian Gerow Cc: freebsd-net@FreeBSD.ORG Subject: Re: DHCP and media selection on bootup In-Reply-To: <64592473972.20021010160826@sentex.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 On Thu, 10 Oct 2002, Damian Gerow wrote: > I've tried setting to ifconfig_fxp0 lines in /etc/rc.conf, the first > for the media selection and the second for the DHCP instruction, but > that didn't work -- the card stayed in autoselect. > > Is there any way to manually set the NIC media, while retreiving the > IP address via DHCP? You may want to put the media-changing ifconfig command into /etc/start_if.fxp0. You see, /etc/start_if.* scripts are executed by rc before ifconfig_fxp0 settings in rc.conf are acted on. The trick works for me; I have to change MAC address, not media options, but it probably does not matter. HTH, Alex. -- | HTTP performance - Web Polygraph benchmark www.measurement-factory.com | HTTP compliance+ - Co-Advisor test suite | all of the above - PolyBox appliance To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 11 11:12: 8 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 52CE137B401; Fri, 11 Oct 2002 11:12:06 -0700 (PDT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id B395343EA3; Fri, 11 Oct 2002 11:12:05 -0700 (PDT) (envelope-from sam@errno.com) Received: from melange (melange.errno.com [66.127.85.82]) (authenticated bits=0) by ebb.errno.com (8.12.5/8.12.1) with ESMTP id g9BIC21I029236 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 11 Oct 2002 11:12:02 -0700 (PDT)?g (envelope-from sam@errno.com)œ X-Authentication-Warning: ebb.errno.com: Host melange.errno.com [66.127.85.82] claimed to be melange Message-ID: <080101c27151$b2e92a30$52557f42@errno.com> From: "Sam Leffler" To: Cc: "Julian Elischer" , , References: <18d301c26e5e$8b5c7a30$52557f42@errno.com> Subject: Re: CFR: m_tag patch Date: Fri, 11 Oct 2002 11:12:02 -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 > >>>>> On Mon, 7 Oct 2002 17:06:25 -0700, > >>>>> "Sam Leffler" said: > > >> > If you allocate tag id's using your 32-bit time scheme then the fixed > > values > >> > above would never be hit since they are all for impossible times and so > >> > there'd be no conflict. > >> > >> Just make them all IDs in a single "Legacy" API > >> > > > Good idea; I see the way out. Try this: > > > struct m_tag { > > SLIST_ENTRY(m_tag) m_tag_link; /* List of packet tags */ > > u_int16_t m_tag_id; /* Tag ID */ > > u_int16_t m_tag_len; /* Length of data */ > > u_int32_t m_tag_cookie; /* Module/ABI */ > > }; > > > Then define the "Legacy ABI" to be zero (or whatever you want). Then all > > the m_tag_* routines that I specified work only for the Legacy ABI. > > (Whether this is done with shims or whatever doesn't matter.) This gives me > > the compatiblity I want with openbsd and gives you the functionality you > > need for netgraph. For new work we can specify users should avoid the > > Legacy ABI. > > > Cost is basically 4 bytes per tag and an extra compare when walking the > > tags. Happy? > > Sorry for interrupting, but please let me make it sure. Do you intend > to hide the additional member from other modules than the m_tag > internal? I'm afraid a story that (e.g.) some code fragments in the > network layer directly refers to m_tag_cookie, which will break source > level compatibility with other BSDs (when the code fragments are > shared with others). As suz said before, we (KAME) are very much > afraid of this kind of story. > The changes I'm proposing for KAME code make no references to m_tag_cookie. Things should be clear when you have a patch to look at. I'm working on getting that to you. Sam To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 11 14:35:27 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3466237B401 for ; Fri, 11 Oct 2002 14:35:26 -0700 (PDT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8B8AB43E8A for ; Fri, 11 Oct 2002 14:35:25 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) 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 RAA02339; Fri, 11 Oct 2002 17:35:25 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id g9BLYsE46944; Fri, 11 Oct 2002 17:34:54 -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: <15783.17406.914045.132169@grasshopper.cs.duke.edu> Date: Fri, 11 Oct 2002 17:34:54 -0400 (EDT) To: Hyong-Youb Kim Cc: Subject: Re: Tigon 3 bad checksums on TCP packets In-Reply-To: References: 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 Hyong-Youb Kim writes: > > I have been recently testing 3C996B-T board in an Athlon system. > The system has TigerMP board and a single Athlon 2000+ and runs FreeBSD > 4.7-RC. With bge driver, every thing works fine except that the NIC piles > up bad checksums on TCP receive packets. For instance, > netperf TCP_STREAM from another machine would pile up bad checksums. > What is most amazing to me is that NIC works fine with UDP receive > packets. As far as I have experienced, TCP/UDP checksumming in NIC should > have little or no difference. Too bad that the firmware is under NDA. > Which RC? Try updating to -stable (or 4.7-release) and then try applying the patch in rev 1.21 (disable memory write invalidate). http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/bge/if_bge.c.diff?r1=1.20&r2=1.21 Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 11 15:25:59 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 50B4537B401 for ; Fri, 11 Oct 2002 15:25:58 -0700 (PDT) Received: from cs.rice.edu (cs.rice.edu [128.42.1.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id E54E743EA3 for ; Fri, 11 Oct 2002 15:25:57 -0700 (PDT) (envelope-from hykim@cs.rice.edu) Received: from localhost (localhost [127.0.0.1]) by cs.rice.edu (Postfix) with ESMTP id 747784AA24; Fri, 11 Oct 2002 17:25:57 -0500 (CDT) Received: from frosty.cs.rice.edu (frosty.cs.rice.edu [128.42.1.20]) by cs.rice.edu (Postfix) with ESMTP id D35354A9D6; Fri, 11 Oct 2002 17:25:56 -0500 (CDT) Received: from localhost (hykim@localhost) by frosty.cs.rice.edu (8.9.3+Sun/8.9.0) with ESMTP id RAA11138; Fri, 11 Oct 2002 17:25:55 -0500 (CDT) X-Authentication-Warning: frosty.cs.rice.edu: hykim owned process doing -bs Date: Fri, 11 Oct 2002 17:25:55 -0500 (CDT) From: Hyong-Youb Kim To: Andrew Gallatin Cc: Subject: Re: Tigon 3 bad checksums on TCP packets In-Reply-To: <15783.17406.914045.132169@grasshopper.cs.duke.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS snapshot-20020300 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. I resolved the issue by forcing BGE_PCI_WRITE_BNDRY_16BYTES in BGE_PCI_DMA_RW_CTL register. The linux driver apparently has a DMA test code and sets this value depending on the test results. I have no clue as to why this configuration messes up TCP receive packets and not UDP packets. John On Fri, 11 Oct 2002, Andrew Gallatin wrote: > > Hyong-Youb Kim writes: > > > > I have been recently testing 3C996B-T board in an Athlon system. > > The system has TigerMP board and a single Athlon 2000+ and runs FreeBSD > > 4.7-RC. With bge driver, every thing works fine except that the NIC piles > > up bad checksums on TCP receive packets. For instance, > > netperf TCP_STREAM from another machine would pile up bad checksums. > > What is most amazing to me is that NIC works fine with UDP receive > > packets. As far as I have experienced, TCP/UDP checksumming in NIC should > > have little or no difference. Too bad that the firmware is under NDA. > > > > Which RC? Try updating to -stable (or 4.7-release) and then > try applying the patch in rev 1.21 (disable memory write invalidate). > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/bge/if_bge.c.diff?r1=1.20&r2=1.21 > > > Drew > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 11 15:29:24 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B71FD37B401 for ; Fri, 11 Oct 2002 15:29:22 -0700 (PDT) Received: from dibbler.ne.client2.attbi.com (dibbler.ne.client2.attbi.com [24.61.41.247]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2799E43E65 for ; Fri, 11 Oct 2002 15:29:22 -0700 (PDT) (envelope-from rodrigc@attbi.com) Received: from dibbler.ne.client2.attbi.com (localhost.ne.attbi.com [127.0.0.1]) by dibbler.ne.client2.attbi.com (8.12.6/8.12.5) with ESMTP id g9BMU3CK019113; Fri, 11 Oct 2002 18:30:03 -0400 (EDT) (envelope-from rodrigc@dibbler.ne.client2.attbi.com) Received: (from rodrigc@localhost) by dibbler.ne.client2.attbi.com (8.12.6/8.12.6/Submit) id g9BMU23Z019112; Fri, 11 Oct 2002 18:30:02 -0400 (EDT) Date: Fri, 11 Oct 2002 18:30:02 -0400 From: Craig Rodrigues To: Archie Cobbs Cc: freebsd-net@FreeBSD.ORG Subject: Re: Netgraph and fxp0 interface? Message-ID: <20021011183002.A19093@attbi.com> References: <20021006221340.A7583@attbi.com> <200210101908.g9AJ81Bs013074@arch20m.dellroad.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: <200210101908.g9AJ81Bs013074@arch20m.dellroad.org>; from archie@dellroad.org on Thu, Oct 10, 2002 at 12:08:01PM -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 Thu, Oct 10, 2002 at 12:08:01PM -0700, Archie Cobbs wrote: > When that tutorial was written, ng_ether.ko did not exist, > so you got it with options NETGRAPH. Since then it's been > split into a separate options NETGRAPH_ETHER and KLD. Do you have that tutorial in a form where it can be updated? I wouldn't mind submitting updates, since I am new to netgraph, and fiddling and learning with it as I go. The tutorial is indispensable. -- Craig Rodrigues http://www.gis.net/~craigr rodrigc@attbi.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 11 16:30:10 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 70A2937B401 for ; Fri, 11 Oct 2002 16:30:09 -0700 (PDT) Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id D2FD243E97 for ; Fri, 11 Oct 2002 16:30:08 -0700 (PDT) (envelope-from archie@dellroad.org) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id QAA87017; Fri, 11 Oct 2002 16:26:50 -0700 (PDT) Received: from arch20m.dellroad.org (localhost [127.0.0.1]) by arch20m.dellroad.org (8.12.6/8.12.6) with ESMTP id g9BNPdON058488; Fri, 11 Oct 2002 16:25:39 -0700 (PDT) (envelope-from archie@arch20m.dellroad.org) Received: (from archie@localhost) by arch20m.dellroad.org (8.12.6/8.12.6/Submit) id g9BNPdus058487; Fri, 11 Oct 2002 16:25:39 -0700 (PDT) From: Archie Cobbs Message-Id: <200210112325.g9BNPdus058487@arch20m.dellroad.org> Subject: Re: Netgraph and fxp0 interface? In-Reply-To: <20021011183002.A19093@attbi.com> "from Craig Rodrigues at Oct 11, 2002 06:30:02 pm" To: Craig Rodrigues Date: Fri, 11 Oct 2002 16:25:39 -0700 (PDT) Cc: freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Craig Rodrigues writes: > On Thu, Oct 10, 2002 at 12:08:01PM -0700, Archie Cobbs wrote: > > When that tutorial was written, ng_ether.ko did not exist, > > so you got it with options NETGRAPH. Since then it's been > > split into a separate options NETGRAPH_ETHER and KLD. > > Do you have that tutorial in a form where it can be updated? > I wouldn't mind submitting updates, since I am new to netgraph, > and fiddling and learning with it as I go. The tutorial is > indispensable. No.. but the daemonnews.org folks might be able to help.. -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 Fri Oct 11 17:17:54 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D639237B404; Fri, 11 Oct 2002 17:17:49 -0700 (PDT) Received: from gull.mail.pas.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 303C643E9C; Fri, 11 Oct 2002 17:17:49 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0285.cvx40-bradley.dialup.earthlink.net ([216.244.43.30] helo=mindspring.com) by gull.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1809yS-0003T8-00; Fri, 11 Oct 2002 17:17:44 -0700 Message-ID: <3DA769DC.58E6BBF0@mindspring.com> Date: Fri, 11 Oct 2002 17:16:28 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: silby@silby.com Cc: csmith@its.uq.edu.au, hardware@freebsd.org, net@freebsd.org Subject: [PATCH: if_ti] Re: High interrupt load on firewalls Content-Type: multipart/mixed; boundary="------------0C5A8C380344382790784831" 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 multi-part message in MIME format. --------------0C5A8C380344382790784831 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mike Silbersack wrote: > On Wed, 9 Oct 2002, Christopher Smith wrote: > > The rule processing can't be done on the other CPU, can it ? Am I right in > > saying that at this point in time, buying a dual CPU (vs single CPU) machine > > for firewalling with FreeBSD is just a waste of money ? > > Even if it could be done, I doubt that would be the most cost effectively > solution to the problem. Try out different NICs, then move on to kernel > profiling if it's still a problem. > > Luigi can probably comment more on this, but one thing which comes to mind > is that the if_ti driver might not be updated to use the new m_getcl > function Luigi added. Luigi claimed a 10% increase in forwarding speed > for drivers using it, I believe. :) Please find attached a patch for the if_ti to support DEVICE_POLLING (the patch is against -current). -- Terry --------------0C5A8C380344382790784831 Content-Type: text/plain; charset=us-ascii; name="tipoll.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="tipoll.diff" Index: if_ti.c =================================================================== RCS file: /cvs/src/sys/pci/if_ti.c,v retrieving revision 1.63 diff -c -r1.63 if_ti.c *** if_ti.c 24 Aug 2002 00:02:03 -0000 1.63 --- if_ti.c 11 Oct 2002 20:09:48 -0000 *************** *** 2520,2525 **** --- 2520,2533 ---- u_int16_t vlan_tag = 0; int have_tag = 0; + #ifdef DEVICE_POLLING + if (ifp->if_flags & IFF_POLLING) { + if (sc->rxcycles <= 0) + break; + sc->rxcycles--; + } + #endif /* DEVICE_POLLING */ + cur_rx = &sc->ti_rdata->ti_rx_return_ring[sc->ti_rx_saved_considx]; rxidx = cur_rx->ti_idx; *************** *** 2678,2683 **** --- 2686,2731 ---- return; } + #ifdef DEVICE_POLLING + static poll_handler_t ti_poll; + + static void + ti_poll(struct ifnet *ifp, enum poll_cmd cmd, int count) + { + struct ti_softc *sc = ifp->if_softc; + + TI_LOCK(sc); + if (cmd == POLL_DEREGISTER) { /* final call, enable interrupts */ + CSR_WRITE_4(sc, TI_MB_HOSTINTR, 0); + goto done; + } + + /* + * Before returning to intr mode we must make sure that all + * possible pending sources of interrupts have been served. + * In practice this means run to completion the *eof routines, + * and then call the interrupt routine + */ + sc->rxcycles = count; + if (ifp->if_snd.ifq_head != NULL) + ti_start(ifp); + + if (sc->rxcycles > 0 || cmd == POLL_AND_CHECK_STATUS) { + if (ifp->if_flags & IFF_RUNNING) { + /* Check RX return ring producer/consumer */ + ti_rxeof(sc); + + /* Check TX ring producer/consumer */ + ti_txeof(sc); + } + ti_handle_events(sc); + } + done: + TI_UNLOCK(sc); + return; + } + #endif /* DEVICE_POLLING */ + static void ti_intr(xsc) void *xsc; *************** *** 2688,2693 **** --- 2736,2749 ---- sc = xsc; TI_LOCK(sc); ifp = &sc->arpcom.ac_if; + #ifdef DEVICE_POLLING + if (ifp->if_flags & IFF_POLLING) + goto done; + if (ether_poll_register(ti_poll, ifp)) { /* ok, disable interrupts */ + CSR_WRITE_4(sc, TI_MB_HOSTINTR, 1); + goto done; + } + #endif /* DEVICE_POLLING */ /*#ifdef notdef*/ /* Avoid this for now -- checking this register is expensive. */ *************** *** 2716,2722 **** if (ifp->if_flags & IFF_RUNNING && ifp->if_snd.ifq_head != NULL) ti_start(ifp); ! TI_UNLOCK(sc); return; --- 2772,2780 ---- if (ifp->if_flags & IFF_RUNNING && ifp->if_snd.ifq_head != NULL) ti_start(ifp); ! #ifdef DEVICE_POLLING ! done: ! #endif /* DEVICE_POLLING */ TI_UNLOCK(sc); return; *************** *** 2999,3004 **** --- 3057,3071 ---- TI_DO_CMD(TI_CMD_HOST_STATE, TI_CMD_CODE_STACK_UP, 0); /* Enable host interrupts. */ + #ifdef DEVICE_POLLING + /* + * ... only enable interrupts if we are not polling, make sure + * they are off otherwise. + */ + if (ifp->if_flags & IFF_POLLING) + CSR_WRITE_4(sc, TI_MB_HOSTINTR, 1); + else + #endif /* DEVICE_POLLING */ CSR_WRITE_4(sc, TI_MB_HOSTINTR, 0); ifp->if_flags |= IFF_RUNNING; *************** *** 3613,3618 **** --- 3680,3688 ---- TI_LOCK(sc); ifp = &sc->arpcom.ac_if; + #ifdef DEVICE_POLLING + ether_poll_deregister(ifp); + #endif /* Disable host interrupts. */ CSR_WRITE_4(sc, TI_MB_HOSTINTR, 1); Index: if_tireg.h =================================================================== RCS file: /cvs/src/sys/pci/if_tireg.h,v retrieving revision 1.25 diff -c -r1.25 if_tireg.h *** if_tireg.h 26 Jun 2002 03:34:52 -0000 1.25 --- if_tireg.h 11 Oct 2002 19:25:04 -0000 *************** *** 1026,1031 **** --- 1026,1034 ---- struct mtx ti_mtx; ti_flag_vals ti_flags; dev_t dev; + #ifdef DEVICE_POLLING + int rxcycles; + #endif }; #define TI_LOCK(_sc) mtx_lock(&(_sc)->ti_mtx) --------------0C5A8C380344382790784831-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 11 18: 0:18 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 55BCA37B406 for ; Fri, 11 Oct 2002 18:00:16 -0700 (PDT) Received: from sccrmhc03.attbi.com (sccrmhc03.attbi.com [204.127.202.63]) by mx1.FreeBSD.org (Postfix) with ESMTP id C2A5C43E97 for ; Fri, 11 Oct 2002 18:00:15 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by sccrmhc03.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20021012010015.UVJO24958.sccrmhc03.attbi.com@InterJet.elischer.org>; Sat, 12 Oct 2002 01:00:15 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id RAA60256; Fri, 11 Oct 2002 17:55:09 -0700 (PDT) Date: Fri, 11 Oct 2002 17:55:09 -0700 (PDT) From: Julian Elischer To: Archie Cobbs Cc: Craig Rodrigues , freebsd-net@FreeBSD.ORG Subject: Re: Netgraph and fxp0 interface? In-Reply-To: <200210112325.g9BNPdus058487@arch20m.dellroad.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 yes that artlcleis a bit out of date.. I'd like to get it updated. On Fri, 11 Oct 2002, Archie Cobbs wrote: > Craig Rodrigues writes: > > On Thu, Oct 10, 2002 at 12:08:01PM -0700, Archie Cobbs wrote: > > > When that tutorial was written, ng_ether.ko did not exist, > > > so you got it with options NETGRAPH. Since then it's been > > > split into a separate options NETGRAPH_ETHER and KLD. > > > > Do you have that tutorial in a form where it can be updated? > > I wouldn't mind submitting updates, since I am new to netgraph, > > and fiddling and learning with it as I go. The tutorial is > > indispensable. > > No.. but the daemonnews.org folks might be able to help.. > > -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 > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 11 18:39:30 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7280037B401 for ; Fri, 11 Oct 2002 18:39:29 -0700 (PDT) Received: from dibbler.ne.client2.attbi.com (dibbler.ne.client2.attbi.com [24.61.41.247]) by mx1.FreeBSD.org (Postfix) with ESMTP id D459D43E6E for ; Fri, 11 Oct 2002 18:39:28 -0700 (PDT) (envelope-from rodrigc@attbi.com) Received: from dibbler.ne.client2.attbi.com (localhost.ne.attbi.com [127.0.0.1]) by dibbler.ne.client2.attbi.com (8.12.6/8.12.5) with ESMTP id g9C1eCCK019960 for ; Fri, 11 Oct 2002 21:40:12 -0400 (EDT) (envelope-from rodrigc@dibbler.ne.client2.attbi.com) Received: (from rodrigc@localhost) by dibbler.ne.client2.attbi.com (8.12.6/8.12.6/Submit) id g9C1eCUn019959 for freebsd-net@freebsd.org; Fri, 11 Oct 2002 21:40:12 -0400 (EDT) Date: Fri, 11 Oct 2002 21:40:11 -0400 From: Craig Rodrigues To: freebsd-net@freebsd.org Subject: kqueue + Netgraph? Message-ID: <20021011214011.A19877@attbi.com> 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 playing with Harti Brandt's Netgraph ATM driver for my Fore PCA-200E card, and wrote my first netgraph program with libnetgraph. Using NgRecvMsg(), I can detect when the ATM card loses carrier. So when I pull out the cable from my card, my little program gets notified. I thought this was fun. :) I have a few questions: (1) Is it possible to combine user-space netgraph notifications with kqueue()? Does anyone have sample code illustrating this? I started playing with kqueue and thought it was really cool. (2) Would it be useful to have some function in libnetgraph for hooking two nodes together? It seems like it would be useful to have. Right now I just copied the source code of nghook and put it into my little program. Thanks. -- Craig Rodrigues http://www.gis.net/~craigr rodrigc@attbi.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 11 19: 0:14 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6550F37B406 for ; Fri, 11 Oct 2002 19:00:12 -0700 (PDT) Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id CF6E643E7B for ; Fri, 11 Oct 2002 19:00:11 -0700 (PDT) (envelope-from archie@dellroad.org) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id SAA88386; Fri, 11 Oct 2002 18:45:34 -0700 (PDT) Received: from arch20m.dellroad.org (localhost [127.0.0.1]) by arch20m.dellroad.org (8.12.6/8.12.6) with ESMTP id g9C1iMON059380; Fri, 11 Oct 2002 18:44:22 -0700 (PDT) (envelope-from archie@arch20m.dellroad.org) Received: (from archie@localhost) by arch20m.dellroad.org (8.12.6/8.12.6/Submit) id g9C1iM09059379; Fri, 11 Oct 2002 18:44:22 -0700 (PDT) From: Archie Cobbs Message-Id: <200210120144.g9C1iM09059379@arch20m.dellroad.org> Subject: Re: kqueue + Netgraph? In-Reply-To: <20021011214011.A19877@attbi.com> "from Craig Rodrigues at Oct 11, 2002 09:40:11 pm" To: Craig Rodrigues Date: Fri, 11 Oct 2002 18:44:22 -0700 (PDT) Cc: freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Craig Rodrigues writes: > (1) Is it possible to combine user-space netgraph notifications with > kqueue()? Sure. kqueue() works with any file descriptors, including netgraph sockets. > (2) Would it be useful to have some function in libnetgraph > for hooking two nodes together? It seems like it would be useful > to have. Right now I just copied the source code of nghook > and put it into my little program. It's such a small amount of code it doesn't really warrant adding a new function IMHO. Cheers, -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 Fri Oct 11 22:48:53 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 677DE37B401 for ; Fri, 11 Oct 2002 22:48:51 -0700 (PDT) Received: from cs.rice.edu (cs.rice.edu [128.42.1.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0753B43E4A for ; Fri, 11 Oct 2002 22:48:51 -0700 (PDT) (envelope-from hykim@cs.rice.edu) Received: from localhost (localhost [127.0.0.1]) by cs.rice.edu (Postfix) with ESMTP id 853AC4A9C0; Sat, 12 Oct 2002 00:48:50 -0500 (CDT) Received: from frosty.cs.rice.edu (frosty.cs.rice.edu [128.42.1.20]) by cs.rice.edu (Postfix) with ESMTP id E876B4A9B9; Sat, 12 Oct 2002 00:48:49 -0500 (CDT) Received: from localhost (hykim@localhost) by frosty.cs.rice.edu (8.9.3+Sun/8.9.0) with ESMTP id AAA12484; Sat, 12 Oct 2002 00:48:46 -0500 (CDT) X-Authentication-Warning: frosty.cs.rice.edu: hykim owned process doing -bs Date: Sat, 12 Oct 2002 00:48:46 -0500 (CDT) From: Hyong-Youb Kim To: Andrew Gallatin Cc: Subject: Re: Tigon 3 bad checksums on TCP packets In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS snapshot-20020300 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, setting BGE_PCI_WRITE_BNDRY_16BYTES limits receive throughput to 540Mb/s. So it is not a solution. I really like to find out what this config does. John On Fri, 11 Oct 2002, Hyong-Youb Kim wrote: > > Thanks. I resolved the issue by forcing BGE_PCI_WRITE_BNDRY_16BYTES > in BGE_PCI_DMA_RW_CTL register. The linux driver apparently has a DMA test > code and sets this value depending on the test results. I have no clue as > to why this configuration messes up TCP receive packets and not UDP > packets. > > > John > > On Fri, 11 Oct 2002, Andrew Gallatin wrote: > > > > > Hyong-Youb Kim writes: > > > > > > I have been recently testing 3C996B-T board in an Athlon system. > > > The system has TigerMP board and a single Athlon 2000+ and runs FreeBSD > > > 4.7-RC. With bge driver, every thing works fine except that the NIC piles > > > up bad checksums on TCP receive packets. For instance, > > > netperf TCP_STREAM from another machine would pile up bad checksums. > > > What is most amazing to me is that NIC works fine with UDP receive > > > packets. As far as I have experienced, TCP/UDP checksumming in NIC should > > > have little or no difference. Too bad that the firmware is under NDA. > > > > > > > Which RC? Try updating to -stable (or 4.7-release) and then > > try applying the patch in rev 1.21 (disable memory write invalidate). > > > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/bge/if_bge.c.diff?r1=1.20&r2=1.21 > > > > > > Drew > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 11 23: 1: 8 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 29B3A37B401 for ; Fri, 11 Oct 2002 23:01:08 -0700 (PDT) Received: from cygnus.theblackmoor.net (theblackmoor.net [63.170.133.254]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7FFCE43E42 for ; Fri, 11 Oct 2002 23:01:07 -0700 (PDT) (envelope-from drogoh@necessary-evil.org) Received: from localhost (drogoh@[208.137.160.3]) by cygnus.theblackmoor.net (8.12.1/8.12.1) with SMTP id g9C614C9022753 for ; Sat, 12 Oct 2002 02:01:06 -0400 Date: Sat, 12 Oct 2002 01:01:03 -0500 From: drogoh To: freebsd-net@freebsd.org Subject: IPv6 tunnel with PPPoE Message-Id: <20021012010103.649ada4a.drogoh@necessary-evil.org> X-Mailer: Sylpheed version 0.8.5 (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 Hello, I am wondering if anyone has used an IPv6 tunnel with something like freenet6 using PPPoE with userland PPP. I've tried to use one myself, but my problem APPEARS to be with PPP, because in the ppp.log I see lines like this: IPV6CP: deflink: State change Closed --> Req-Sent and Phase: deflink: IPV6CP protocol reject closes IPV6CP ! However, if this is not the reason for not being able to get a route with PPPoE, I'd appreciate any help to get it working. Thanks. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Oct 12 16:19: 7 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 964F637B401 for ; Sat, 12 Oct 2002 16:19:06 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 11D1943EBE for ; Sat, 12 Oct 2002 16:19:06 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.3/8.12.3) with ESMTP id g9CNJ5pk009342 for ; Sat, 12 Oct 2002 17:19:05 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 12 Oct 2002 17:18:09 -0600 (MDT) Message-Id: <20021012.171809.93306957.imp@bsdimp.com> To: net@freebsd.org Subject: Comments Please From: "M. Warner Losh" X-Mailer: Mew version 2.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org OK. I'm not a network wonk, so I thought I'd run this by people here. What do people think. Warner --- //depot/user/imp/freebsd-imp/sys/net/if_ethersubr.c 2002/10/06 21:18:24 +++ //depot/user/imp/newcard/net/if_ethersubr.c 2002/10/11 22:58:57 @@ -124,7 +124,8 @@ static int ether_resolvemulti(struct ifnet *, struct sockaddr **, struct sockaddr *); -u_char etherbroadcastaddr[6] = { 0xff, 0xff, 0xff, 0xff, 0xff, 0xff }; +u_char etherbroadcastaddr[ETHER_ADDR_LEN] = + { 0xff, 0xff, 0xff, 0xff, 0xff, 0xff }; #define senderr(e) do { error = (e); goto bad;} while (0) #define IFP2AC(IFP) ((struct arpcom *)IFP) @@ -149,7 +150,7 @@ { short type; int error = 0, hdrcmplt = 0; - u_char esrc[6], edst[6]; + u_char esrc[ETHER_ADDR_LEN], edst[ETHER_ADDR_LEN]; register struct rtentry *rt; register struct ether_header *eh; int loop_copy = 0; @@ -859,8 +860,8 @@ register struct sockaddr_dl *sdl; ifp->if_type = IFT_ETHER; - ifp->if_addrlen = 6; - ifp->if_hdrlen = 14; + ifp->if_addrlen = ETHER_ADDR_LEN; + ifp->if_hdrlen = ETHER_HDR_LEN; if_attach(ifp); ifp->if_mtu = ETHERMTU; ifp->if_resolvemulti = ether_resolvemulti; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Oct 12 17:13:55 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5E8BA37B40B for ; Sat, 12 Oct 2002 17:13:50 -0700 (PDT) Received: from carp.icir.org (carp.icir.org [192.150.187.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id EC49E43E97 for ; Sat, 12 Oct 2002 17:13:49 -0700 (PDT) (envelope-from rizzo@carp.icir.org) Received: from carp.icir.org (localhost [127.0.0.1]) by carp.icir.org (8.12.3/8.12.3) with ESMTP id g9D0DepJ092837; Sat, 12 Oct 2002 17:13:40 -0700 (PDT) (envelope-from rizzo@carp.icir.org) Received: (from rizzo@localhost) by carp.icir.org (8.12.3/8.12.3/Submit) id g9D0DeGG092836; Sat, 12 Oct 2002 17:13:40 -0700 (PDT) (envelope-from rizzo) Date: Sat, 12 Oct 2002 17:13:39 -0700 From: Luigi Rizzo To: "M. Warner Losh" Cc: net@FreeBSD.ORG Subject: Re: Comments Please Message-ID: <20021012171339.A92744@carp.icir.org> References: <20021012.171809.93306957.imp@bsdimp.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: <20021012.171809.93306957.imp@bsdimp.com>; from imp@bsdimp.com on Sat, Oct 12, 2002 at 05:18:09PM -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 Sat, Oct 12, 2002 at 05:18:09PM -0600, M. Warner Losh wrote: > OK. I'm not a network wonk, so I thought I'd run this by people > here. What do people think. sounds ok -- removing explicit constants is always good. On passing: * While you are at it, grep etherbroadcastaddr sys/net*/* reveals the use of an explicit constant (6) in net/if_arp.h and netinet/if_ether.c; there is more of the same in net/bridge.c (my fault), net/if_atmsubr.c, netinet/if_ether.c, netncp/ncp_subr.c * there is no real reason to have etherbroadcastaddr as a variable. net/bridge.c has a macro, IS_ETHER_BROADCAST, which is much faster to evaluate on i386, and could be moved e.g. in net/ethernet.h and be used to check for ethernet broadcast addresses in net/if_ethersubr.c net/if_iso88025subr.c netatalk/aarp.c net/if_fddisubr.c This only leaves some usages of etherbroadcastaddr is in netinet/if_ether.c to set the address for outgoing broadcast packets. cheers luigi > Warner > > --- //depot/user/imp/freebsd-imp/sys/net/if_ethersubr.c 2002/10/06 21:18:24 > +++ //depot/user/imp/newcard/net/if_ethersubr.c 2002/10/11 22:58:57 > @@ -124,7 +124,8 @@ > > static int ether_resolvemulti(struct ifnet *, struct sockaddr **, > struct sockaddr *); > -u_char etherbroadcastaddr[6] = { 0xff, 0xff, 0xff, 0xff, 0xff, 0xff }; > +u_char etherbroadcastaddr[ETHER_ADDR_LEN] = > + { 0xff, 0xff, 0xff, 0xff, 0xff, 0xff }; > #define senderr(e) do { error = (e); goto bad;} while (0) > #define IFP2AC(IFP) ((struct arpcom *)IFP) > > @@ -149,7 +150,7 @@ > { > short type; > int error = 0, hdrcmplt = 0; > - u_char esrc[6], edst[6]; > + u_char esrc[ETHER_ADDR_LEN], edst[ETHER_ADDR_LEN]; > register struct rtentry *rt; > register struct ether_header *eh; > int loop_copy = 0; > @@ -859,8 +860,8 @@ > register struct sockaddr_dl *sdl; > > ifp->if_type = IFT_ETHER; > - ifp->if_addrlen = 6; > - ifp->if_hdrlen = 14; > + ifp->if_addrlen = ETHER_ADDR_LEN; > + ifp->if_hdrlen = ETHER_HDR_LEN; > if_attach(ifp); > ifp->if_mtu = ETHERMTU; > ifp->if_resolvemulti = ether_resolvemulti; > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Oct 12 19: 8: 9 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 264EE37B401 for ; Sat, 12 Oct 2002 19:08:08 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5AAE543E97 for ; Sat, 12 Oct 2002 19:08:06 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.3/8.12.3) with ESMTP id g9D285pk009973; Sat, 12 Oct 2002 20:08:05 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 12 Oct 2002 20:07:47 -0600 (MDT) Message-Id: <20021012.200747.59843102.imp@bsdimp.com> To: rizzo@icir.org Cc: net@FreeBSD.ORG Subject: Re: Comments Please From: "M. Warner Losh" In-Reply-To: <20021012171339.A92744@carp.icir.org> References: <20021012.171809.93306957.imp@bsdimp.com> <20021012171339.A92744@carp.icir.org> X-Mailer: Mew version 2.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In message: <20021012171339.A92744@carp.icir.org> Luigi Rizzo writes: : On Sat, Oct 12, 2002 at 05:18:09PM -0600, M. Warner Losh wrote: : > OK. I'm not a network wonk, so I thought I'd run this by people : > here. What do people think. : : sounds ok -- removing explicit constants is always good. : On passing: : : * While you are at it, : grep etherbroadcastaddr sys/net*/* : reveals the use of an explicit constant (6) in net/if_arp.h and : netinet/if_ether.c; there is more of the same in net/bridge.c : (my fault), net/if_atmsubr.c, netinet/if_ether.c, netncp/ncp_subr.c atmsubr? Doesn't ATM have its own constants? : * there is no real reason to have etherbroadcastaddr as a : variable. net/bridge.c has a macro, IS_ETHER_BROADCAST, : which is much faster to evaluate on i386, and : could be moved e.g. in net/ethernet.h and be used : to check for ethernet broadcast addresses in : net/if_ethersubr.c : net/if_iso88025subr.c : netatalk/aarp.c : net/if_fddisubr.c : This only leaves some usages of etherbroadcastaddr is in : netinet/if_ether.c to set the address for outgoing broadcast : packets. I'll let others deal with that. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Oct 12 19:17:15 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9E6E537B401 for ; Sat, 12 Oct 2002 19:17:14 -0700 (PDT) Received: from carp.icir.org (carp.icir.org [192.150.187.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F80343E91 for ; Sat, 12 Oct 2002 19:17:14 -0700 (PDT) (envelope-from rizzo@carp.icir.org) Received: from carp.icir.org (localhost [127.0.0.1]) by carp.icir.org (8.12.3/8.12.3) with ESMTP id g9D2H9pJ093827; Sat, 12 Oct 2002 19:17:09 -0700 (PDT) (envelope-from rizzo@carp.icir.org) Received: (from rizzo@localhost) by carp.icir.org (8.12.3/8.12.3/Submit) id g9D2H9su093826; Sat, 12 Oct 2002 19:17:09 -0700 (PDT) (envelope-from rizzo) Date: Sat, 12 Oct 2002 19:17:09 -0700 From: Luigi Rizzo To: "M. Warner Losh" Cc: net@FreeBSD.ORG Subject: Re: Comments Please Message-ID: <20021012191709.B93684@carp.icir.org> References: <20021012.171809.93306957.imp@bsdimp.com> <20021012171339.A92744@carp.icir.org> <20021012.200747.59843102.imp@bsdimp.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: <20021012.200747.59843102.imp@bsdimp.com>; from imp@bsdimp.com on Sat, Oct 12, 2002 at 08:07:47PM -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 Sat, Oct 12, 2002 at 08:07:47PM -0600, M. Warner Losh wrote: ... > : reveals the use of an explicit constant (6) in net/if_arp.h and > : netinet/if_ether.c; there is more of the same in net/bridge.c > : (my fault), net/if_atmsubr.c, netinet/if_ether.c, netncp/ncp_subr.c > > atmsubr? Doesn't ATM have its own constants? eh, that's the problem with explicit constants, you can never tell whether "6" is english, german or italian... in any case the relevant piece of code is: net/if_atmsubr.c: if (bcmp(alc, ATMLLC_HDR, 6)) { I have no idea if it has any relation with ethernet header sizes. cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Oct 12 19:22:27 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CE00037B401 for ; Sat, 12 Oct 2002 19:22:26 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 416D743E9E for ; Sat, 12 Oct 2002 19:22:26 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.3/8.12.3) with ESMTP id g9D2MPpk010016; Sat, 12 Oct 2002 20:22:25 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 12 Oct 2002 20:22:03 -0600 (MDT) Message-Id: <20021012.202203.58451922.imp@bsdimp.com> To: rizzo@icir.org Cc: net@FreeBSD.ORG Subject: Re: Comments Please From: "M. Warner Losh" In-Reply-To: <20021012191709.B93684@carp.icir.org> References: <20021012171339.A92744@carp.icir.org> <20021012.200747.59843102.imp@bsdimp.com> <20021012191709.B93684@carp.icir.org> X-Mailer: Mew version 2.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In message: <20021012191709.B93684@carp.icir.org> Luigi Rizzo writes: : On Sat, Oct 12, 2002 at 08:07:47PM -0600, M. Warner Losh wrote: : ... : > : reveals the use of an explicit constant (6) in net/if_arp.h and : > : netinet/if_ether.c; there is more of the same in net/bridge.c : > : (my fault), net/if_atmsubr.c, netinet/if_ether.c, netncp/ncp_subr.c : > : > atmsubr? Doesn't ATM have its own constants? : : eh, that's the problem with explicit constants, you can never tell : whether "6" is english, german or italian... in any case the : relevant piece of code is: : : net/if_atmsubr.c: if (bcmp(alc, ATMLLC_HDR, 6)) { : : I have no idea if it has any relation with ethernet header sizes. Looks like that one should be something else, since it is an atm llc header. Of course the atm code should be using if_llc.h to get this stuff, but that's another story... Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message