From owner-freebsd-net@FreeBSD.ORG Sun Apr 18 17:37:44 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CDD2416A4CE for ; Sun, 18 Apr 2004 17:37:44 -0700 (PDT) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id DE22B43D41 for ; Sun, 18 Apr 2004 17:37:43 -0700 (PDT) (envelope-from glebius@cell.sick.ru) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.9/8.12.8) with ESMTP id i3J0bfQE056484 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 19 Apr 2004 04:37:41 +0400 (MSD) (envelope-from glebius@cell.sick.ru) Received: (from glebius@localhost) by cell.sick.ru (8.12.9/8.12.6/Submit) id i3J0be9n056483 for freebsd-net@freebsd.org; Mon, 19 Apr 2004 04:37:41 +0400 (MSD) Date: Mon, 19 Apr 2004 04:37:40 +0400 From: Gleb Smirnoff To: freebsd-net@freebsd.org Message-ID: <20040419003740.GB56442@cell.sick.ru> Mail-Followup-To: Gleb Smirnoff , freebsd-net@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline User-Agent: Mutt/1.5.6i Subject: route into netgraph? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2004 00:37:44 -0000 Dear networkers, does anyone can give me a hint? I want to inject some traffic with a specific destination to netgraph. For example I want to route all traffic with dst 10.0.0.0/8 to my netgraph node, whereever it came from - came on interface or generated locally. I see only one way to do this - divert it with ipfw to ng_ksocket. But, it'll be nice to use smth like: route add 10.0.0.0/8 -iface ng0 and receive packets on ng0's inet hook. Any other ideas? -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Sun Apr 18 19:04:27 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B44EC16A4CF for ; Sun, 18 Apr 2004 19:04:27 -0700 (PDT) Received: from smtp.omnis.com (smtp.omnis.com [216.239.128.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1BCA743D3F for ; Sun, 18 Apr 2004 19:04:27 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from softweyr.homeunix.net (24-161-166-146.san.rr.com [24.161.166.146]) by smtp-relay.omnis.com (Postfix) with ESMTP id 2E9FC100572; Sun, 18 Apr 2004 19:04:26 -0700 (PDT) From: Wes Peters Organization: Softweyr.COM To: freebsd-net@freebsd.org Date: Sat, 10 Apr 2004 14:06:27 -0700 User-Agent: KMail/1.6.1 References: <20040408011945.S40836@ganymede.hub.org> In-Reply-To: <20040408011945.S40836@ganymede.hub.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200404101406.27758.wes@softweyr.com> Subject: Re: Stupid question about managed switches X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2004 02:04:27 -0000 On Wednesday 07 April 2004 21:23, Marc G. Fournier wrote: > Please excuse this, but my experience with them is zilch ... am going > with the HP Procurve 2826(?) Layer2/Layer3 switch, as was suggested, but > I'm curious as to how they work ... > > For instance, I know when I setup a router, I have an IN IP and an OUT IP > configured ... but, with a managed switch, what do I have? > > For instance, right now, I have a default gateway on the providers switch > of 200.46.204.1 ... and my servers are .2, .3, .4 and .5 ... if I put a > managed switch, vs the unmanaged we have now, between the providers > switch and the servers, does my default route then change to be the > switch itself? Or is the 'login part' of the switch thought of the same > way as adding just another server to the network, for connectivity > purposes? > > As I said, stupid question, but for someone whose never played with a > managed switch before ... :( There are managed switches, and then there are routing switches. Managed simply means there is a processor on the box that can manage some aspect of the switch; in some cases this is as simple as being able to turn ports on and off and reset the switch. Routing switches employ virtual routers to route between the VLANs managed by the switch. The usual way to do this is to assign an IP address to the virtual router in the "normal" IP address range of each VLAN. The router then routes between these virtual interfaces in the normal manner. I can't speak to the insides of the HP equipment, but Xylan/Alcatel used a modified version of the Net/2 TCP/IP stack running on VxWorks in the management processor. -- Where am I, and what am I doing in this handbasket? Wes Peters wes@softweyr.com From owner-freebsd-net@FreeBSD.ORG Sun Apr 18 20:26:31 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9E8B416A4CE; Sun, 18 Apr 2004 20:26:31 -0700 (PDT) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F64243D2D; Sun, 18 Apr 2004 20:26:30 -0700 (PDT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (localhost [127.0.0.1]) (authenticated bits=0) by cain.gsoft.com.au (8.12.11/8.12.10) with ESMTP id i3J3QQAf053444; Mon, 19 Apr 2004 12:56:27 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-net@freebsd.org Date: Mon, 19 Apr 2004 12:56:24 +0930 User-Agent: KMail/1.6.1 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200404191256.24225.doconnor@gsoft.com.au> X-Spam-Score: -2.3 () CARRIAGE_RETURNS,SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_KMAIL X-Scanned-By: MIMEDefang 2.16 (www . roaringpenguin . com / mimedefang) Subject: Netgraph and non-ethernet nodes? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2004 03:26:31 -0000 The recent emails about the bridge code from NetBSD made me interested in using netgraph to run snort on the combined traffic rather than having to run 2 copies (since we tunnel our class C using gif over IP over ethernet), however I can't see how to hook netgraph into a non-ethernet node :( Does anyone know if/how you can do it? (Specifically for gif) Thanks. PS please CC me as I am not on -net. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 From owner-freebsd-net@FreeBSD.ORG Sun Apr 18 20:39:49 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DAEC416A4CE for ; Sun, 18 Apr 2004 20:39:49 -0700 (PDT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id B4FAB43D1F for ; Sun, 18 Apr 2004 20:39:49 -0700 (PDT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (IDENT:brdavis@localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.12.10/8.12.3) with ESMTP id i3J3dnjU031044; Sun, 18 Apr 2004 20:39:49 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.10/8.12.3/Submit) id i3J3dn6N031043; Sun, 18 Apr 2004 20:39:49 -0700 Date: Sun, 18 Apr 2004 20:39:49 -0700 From: Brooks Davis To: "Daniel O'Connor" Message-ID: <20040419033948.GA30320@Odin.AC.HMC.Edu> References: <200404191256.24225.doconnor@gsoft.com.au> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OXfL5xGRrasGEqWY" Content-Disposition: inline In-Reply-To: <200404191256.24225.doconnor@gsoft.com.au> User-Agent: Mutt/1.5.4i cc: freebsd-net@freebsd.org Subject: Re: Netgraph and non-ethernet nodes? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2004 03:39:50 -0000 --OXfL5xGRrasGEqWY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 19, 2004 at 12:56:24PM +0930, Daniel O'Connor wrote: > The recent emails about the bridge code from NetBSD made me interested in= =20 > using netgraph to run snort on the combined traffic rather than having to= run=20 > 2 copies (since we tunnel our class C using gif over IP over ethernet),= =20 > however I can't see how to hook netgraph into a non-ethernet node :( >=20 > Does anyone know if/how you can do it? (Specifically for gif) How about nf_gif(4)? -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --OXfL5xGRrasGEqWY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFAg0oEXY6L6fI4GtQRApe0AJ4uueuVee0oyrk2aBUaIhmpFCYMUACgzTZU fPHx0nFfyFVGm6Kr0YrjDwQ= =fhMO -----END PGP SIGNATURE----- --OXfL5xGRrasGEqWY-- From owner-freebsd-net@FreeBSD.ORG Sun Apr 18 20:46:52 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5C28516A4CE for ; Sun, 18 Apr 2004 20:46:52 -0700 (PDT) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 88C3E43D46 for ; Sun, 18 Apr 2004 20:46:51 -0700 (PDT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (localhost [127.0.0.1]) (authenticated bits=0) by cain.gsoft.com.au (8.12.11/8.12.10) with ESMTP id i3J3kmfH053773; Mon, 19 Apr 2004 13:16:48 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: Brooks Davis Date: Mon, 19 Apr 2004 13:16:46 +0930 User-Agent: KMail/1.6.1 References: <200404191256.24225.doconnor@gsoft.com.au> <20040419033948.GA30320@Odin.AC.HMC.Edu> In-Reply-To: <20040419033948.GA30320@Odin.AC.HMC.Edu> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200404191316.46089.doconnor@gsoft.com.au> X-Spam-Score: -4.4 () CARRIAGE_RETURNS,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_KMAIL X-Scanned-By: MIMEDefang 2.16 (www . roaringpenguin . com / mimedefang) cc: freebsd-net@freebsd.org Subject: Re: Netgraph and non-ethernet nodes? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2004 03:46:52 -0000 On Mon, 19 Apr 2004 13:09, Brooks Davis wrote: > On Mon, Apr 19, 2004 at 12:56:24PM +0930, Daniel O'Connor wrote: > > The recent emails about the bridge code from NetBSD made me interested in > > using netgraph to run snort on the combined traffic rather than having to > > run 2 copies (since we tunnel our class C using gif over IP over > > ethernet), however I can't see how to hook netgraph into a non-ethernet > > node :( > > > > Does anyone know if/how you can do it? (Specifically for gif) > > How about nf_gif(4)? Hmm, I see the man page, but no module.. Ahh, it doesn't appear to be built by default.. And it's not on my -stable box, guess I should do a manual merge :) Thanks for the hint :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 From owner-freebsd-net@FreeBSD.ORG Mon Apr 19 00:37:47 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 964F616A4CE for ; Mon, 19 Apr 2004 00:37:47 -0700 (PDT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id C9FAF43D31 for ; Mon, 19 Apr 2004 00:37:46 -0700 (PDT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i3J7frrP006416 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Apr 2004 10:41:55 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.12.11/8.12.11) id i3J7bcxF040571; Mon, 19 Apr 2004 10:37:38 +0300 (EEST) (envelope-from ru) Date: Mon, 19 Apr 2004 10:37:38 +0300 From: Ruslan Ermilov To: Gleb Smirnoff , freebsd-net@freebsd.org Message-ID: <20040419073738.GD39799@ip.net.ua> References: <20040419003740.GB56442@cell.sick.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="x4pBfXISqBoDm8sr" Content-Disposition: inline In-Reply-To: <20040419003740.GB56442@cell.sick.ru> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Subject: Re: route into netgraph? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2004 07:37:47 -0000 --x4pBfXISqBoDm8sr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 19, 2004 at 04:37:40AM +0400, Gleb Smirnoff wrote: > Dear networkers, >=20 > does anyone can give me a hint? I want to inject some traffic with > a specific destination to netgraph. > For example I want to route all traffic with dst 10.0.0.0/8 to my > netgraph node, whereever it came from - came on interface or > generated locally. >=20 > I see only one way to do this - divert it with ipfw to ng_ksocket. >=20 > But, it'll be nice to use smth like: >=20 > route add 10.0.0.0/8 -iface ng0 >=20 > and receive packets on ng0's inet hook. >=20 > Any other ideas? >=20 So? The above should just work, what's the problem? # route add 10.0.0.0/8 -iface ng0 # ifconfig ng0 up # ping -c1 10.0.0.1 # nghook -a ng0: inet 0000: 45 00 00 54 07 d5 00 00 40 01 68 d4 00 00 00 00 E..T....@.h..... 0010: 0a 00 00 01 08 00 d9 8f 61 9e 00 00 c7 80 83 40 ........a......@ 0020: 79 0d 0e 00 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 y............... 0030: 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 ............ !"# 0040: 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 $%&'()*+,-./0123 0050: 34 35 36 37 4567 Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --x4pBfXISqBoDm8sr Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAg4HCUkv4P6juNwoRAsaXAKCGJ3Z2T0WxWLTrlytCAkzC19tFlgCfQbHg HA2KyXPgCwL5gJF1vZYwJZA= =3xsi -----END PGP SIGNATURE----- --x4pBfXISqBoDm8sr-- From owner-freebsd-net@FreeBSD.ORG Mon Apr 19 01:02:36 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5129016A4CE for ; Mon, 19 Apr 2004 01:02:36 -0700 (PDT) Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1022943D1F for ; Mon, 19 Apr 2004 01:02:36 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (rwcrmhc11) with ESMTP id <2004041908023501300fdd9be>; Mon, 19 Apr 2004 08:02:35 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id BAA97315; Mon, 19 Apr 2004 01:02:33 -0700 (PDT) Date: Mon, 19 Apr 2004 01:02:31 -0700 (PDT) From: Julian Elischer To: "Daniel O'Connor" In-Reply-To: <200404191316.46089.doconnor@gsoft.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org Subject: Re: Netgraph and non-ethernet nodes? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2004 08:02:36 -0000 On Mon, 19 Apr 2004, Daniel O'Connor wrote: > On Mon, 19 Apr 2004 13:09, Brooks Davis wrote: > > On Mon, Apr 19, 2004 at 12:56:24PM +0930, Daniel O'Connor wrote: > > > The recent emails about the bridge code from NetBSD made me interested in > > > using netgraph to run snort on the combined traffic rather than having to > > > run 2 copies (since we tunnel our class C using gif over IP over > > > ethernet), however I can't see how to hook netgraph into a non-ethernet > > > node :( > > > > > > Does anyone know if/how you can do it? (Specifically for gif) > > > > How about nf_gif(4)? > > Hmm, I see the man page, but no module.. Ahh, it doesn't appear to be built by > default.. > > And it's not on my -stable box, guess I should do a manual merge :) > there are some basic differences between netgraph nodes in -current and in 4.x check out the differences in a few nodes (e.g. ng_sample.c) to see what they are. in particular... in 4.x and earlier, the mbuf and metadaa are handled separatly as arguments to things but in 5.x they are both held in (well a pointer is in..) a struct item. which is passed around... the item structure needs to be freed if you destroy it and there are macros to extract the mbuf and metadata from the item. This is because in 5.x we often need to queue teh packet including metadata and the 'item' is what is queued. > Thanks for the hint :) > > -- > Daniel O'Connor software and network engineer > for Genesis Software - http://www.gsoft.com.au > "The nice thing about standards is that there > are so many of them to choose from." > -- Andrew Tanenbaum > GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Mon Apr 19 01:08:32 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3F29516A4CE for ; Mon, 19 Apr 2004 01:08:32 -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 7731D43D41 for ; Mon, 19 Apr 2004 01:08:31 -0700 (PDT) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from ocean.jinmei.org (unknown [3ffe:501:100f:1010:a5ff:aefb:fee7:dff3]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 5B37415210; Mon, 19 Apr 2004 17:08:25 +0900 (JST) Date: Mon, 19 Apr 2004 17:08:28 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: =?ISO-2022-JP?B?Ik0bJEIidRsoQm5pY2EgRG9taW5ndWVzIg==?= In-Reply-To: References: User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable cc: freebsd-net@freebsd.org Subject: Re: pim6sd configuration X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2004 08:08:32 -0000 >>>>> On Thu, 15 Apr 2004 12:35:03 +0000,=20 >>>>> "M=F3nica Domingues" said: > I'am configuring a SSM multicast router, for that I'am using pim6sd. > So, I'am FreeBSD with kame snap kit and I had install pim6sd. > At the moment, Itrying to configure the routing daemon and I'am having > some difficulties... First, I'd suggest you to ask questions specific to KAME snaps at a KAME mailing list. snap-users@kame.net would be the best place. > So, in file /etc/rc.conf I have: > mroute6d_enable =3D"YES" > mroute6d_program=3D"usr/local/v6/sbin/pim6sd" > In file /etc/pim6sd.conf I have: > phyint xl1 mld_version 2; > When I open pim6sd.log I don't have any log, is this normal? > I'am I doing this the right way? This is not so surprising since you seem not to have specified a log level. Please try to add the following in your pim6sd.conf: log all; (though this should be quite noisy). JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp From owner-freebsd-net@FreeBSD.ORG Mon Apr 19 01:12:36 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 357AE16A4CE for ; Mon, 19 Apr 2004 01:12:36 -0700 (PDT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5977843D2F for ; Mon, 19 Apr 2004 01:12:35 -0700 (PDT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i3J8GfGI010529 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Apr 2004 11:16:43 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.12.11/8.12.11) id i3J8CPjC040987; Mon, 19 Apr 2004 11:12:25 +0300 (EEST) (envelope-from ru) Date: Mon, 19 Apr 2004 11:12:25 +0300 From: Ruslan Ermilov To: Julian Elischer Message-ID: <20040419081225.GG39799@ip.net.ua> References: <200404191316.46089.doconnor@gsoft.com.au> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EDJsL2R9iCFAt7IV" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: Daniel O'Connor cc: freebsd-net@freebsd.org Subject: Re: Netgraph and non-ethernet nodes? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2004 08:12:36 -0000 --EDJsL2R9iCFAt7IV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 19, 2004 at 01:02:31AM -0700, Julian Elischer wrote: >=20 >=20 > On Mon, 19 Apr 2004, Daniel O'Connor wrote: >=20 > > On Mon, 19 Apr 2004 13:09, Brooks Davis wrote: > > > On Mon, Apr 19, 2004 at 12:56:24PM +0930, Daniel O'Connor wrote: > > > > The recent emails about the bridge code from NetBSD made me interes= ted in > > > > using netgraph to run snort on the combined traffic rather than hav= ing to > > > > run 2 copies (since we tunnel our class C using gif over IP over > > > > ethernet), however I can't see how to hook netgraph into a non-ethe= rnet > > > > node :( > > > > > > > > Does anyone know if/how you can do it? (Specifically for gif) > > > > > > How about nf_gif(4)? > >=20 > > Hmm, I see the man page, but no module.. Ahh, it doesn't appear to be b= uilt by=20 > > default.. > >=20 > > And it's not on my -stable box, guess I should do a manual merge :) > >=20 >=20 > there are some basic differences between netgraph nodes in -current and= =20 > in 4.x > check out the differences in a few nodes (e.g. ng_sample.c)=20 >=20 > to see what they are. >=20 > in particular... in 4.x and earlier, the mbuf and metadaa are handled > separatly as arguments to things but in 5.x > they are both held in (well a pointer is in..) a struct item. >=20 > which is passed around... the item structure needs to be freed if you > destroy it and there are macros to extract the mbuf and metadata > from the item. This is because in 5.x we often need to queue teh packet > including metadata and the 'item' is what is queued. >=20 While we're on this topic, I wonder if you have plans to get rid of non-funcional diffs for ng_sample.[ch] between RELENG_4 and HEAD? If not, I could do it, and send you a patch (for RELENG_4) for review. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --EDJsL2R9iCFAt7IV Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAg4npUkv4P6juNwoRAte5AJ4k+85uEeVcK5pjwe3NE64RYldjOACfSkzR 1FqD0CORVurqxO0Oga3rKYA= =Angx -----END PGP SIGNATURE----- --EDJsL2R9iCFAt7IV-- From owner-freebsd-net@FreeBSD.ORG Mon Apr 19 02:28:05 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6910A16A4CF; Mon, 19 Apr 2004 02:28:05 -0700 (PDT) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8DF9E43D2F; Mon, 19 Apr 2004 02:28:04 -0700 (PDT) (envelope-from glebius@cell.sick.ru) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.9/8.12.8) with ESMTP id i3J9S2QE058201 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Apr 2004 13:28:02 +0400 (MSD) (envelope-from glebius@cell.sick.ru) Received: (from glebius@localhost) by cell.sick.ru (8.12.9/8.12.6/Submit) id i3J9S1aj058200; Mon, 19 Apr 2004 13:28:01 +0400 (MSD) Date: Mon, 19 Apr 2004 13:28:01 +0400 From: Gleb Smirnoff To: Ruslan Ermilov Message-ID: <20040419092801.GB58113@cell.sick.ru> Mail-Followup-To: Gleb Smirnoff , Ruslan Ermilov , freebsd-net@freebsd.org References: <20040419003740.GB56442@cell.sick.ru> <20040419073738.GD39799@ip.net.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20040419073738.GD39799@ip.net.ua> User-Agent: Mutt/1.5.6i cc: freebsd-net@freebsd.org Subject: Re: route into netgraph? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2004 09:28:05 -0000 On Mon, Apr 19, 2004 at 10:37:38AM +0300, Ruslan Ermilov wrote: R> > does anyone can give me a hint? I want to inject some traffic with R> > a specific destination to netgraph. R> > For example I want to route all traffic with dst 10.0.0.0/8 to my R> > netgraph node, whereever it came from - came on interface or R> > generated locally. R> > R> > I see only one way to do this - divert it with ipfw to ng_ksocket. R> > R> > But, it'll be nice to use smth like: R> > R> > route add 10.0.0.0/8 -iface ng0 R> > R> > and receive packets on ng0's inet hook. R> > R> > Any other ideas? R> > R> So? The above should just work, what's the problem? R> R> # route add 10.0.0.0/8 -iface ng0 R> # ifconfig ng0 up R> # ping -c1 10.0.0.1 R> R> # nghook -a ng0: inet R> 0000: 45 00 00 54 07 d5 00 00 40 01 68 d4 00 00 00 00 E..T....@.h..... R> 0010: 0a 00 00 01 08 00 d9 8f 61 9e 00 00 c7 80 83 40 ........a......@ R> 0020: 79 0d 0e 00 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 y............... R> 0030: 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 ............ !"# R> 0040: 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 $%&'()*+,-./0123 R> 0050: 34 35 36 37 4567 Ah, yes. May be yesterday I was on smth. Surely it works. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Mon Apr 19 04:40:46 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6D72E16A4CE for ; Mon, 19 Apr 2004 04:40:46 -0700 (PDT) Received: from mta1-msx.wanglobal.net (mta1-msx.wanglobal.net [80.86.128.210]) by mx1.FreeBSD.org (Postfix) with SMTP id 25ACB43D45 for ; Mon, 19 Apr 2004 04:40:45 -0700 (PDT) (envelope-from sten.daniel.sorsdal@wan.no) Received: (qmail 17663 invoked by uid 1006); 19 Apr 2004 11:41:52 -0000 Received: from sten.daniel.sorsdal@wan.no by mta1-msx.wanglobal.net by uid 1002 with qmail-scanner-1.21 (clamscan: 0.70-rc. Clear:RC:1(10.30.1.52):. Processed in 0.689118 secs); 19 Apr 2004 11:41:52 -0000 Received: from unknown (HELO exchange.wan.no) (10.30.1.52) by mta1-msx.wanglobal.net with SMTP; 19 Apr 2004 11:41:51 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Mon, 19 Apr 2004 13:40:15 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NetBSD/OpenBSD's bridging code - anyone looked at porting it? Thread-Index: AcQmAxUJW2XTkRQNTJe4J9d7EJIg6Q== From: =?iso-8859-1?Q?Sten_Daniel_S=F8rsdal?= To: Subject: NetBSD/OpenBSD's bridging code - anyone looked at porting it? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2004 11:40:46 -0000 Has anyone looked at porting NetBSD/OpenBSD's bridging code? It is my opinion that it is superior in features and standards=20 compliancy to FreeBSD's current bridging methods. _// Sten Daniel S=F8rsdal From owner-freebsd-net@FreeBSD.ORG Mon Apr 19 04:44:11 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C926B16A4CE for ; Mon, 19 Apr 2004 04:44:11 -0700 (PDT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id B419643D48 for ; Mon, 19 Apr 2004 04:44:11 -0700 (PDT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.9p1/8.12.8) with ESMTP id i3JBi9gd027032; Mon, 19 Apr 2004 04:44:09 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.9p1/8.12.3/Submit) id i3JBi9b1027031; Mon, 19 Apr 2004 04:44:09 -0700 (PDT) (envelope-from rizzo) Date: Mon, 19 Apr 2004 04:44:09 -0700 From: Luigi Rizzo To: =?iso-8859-1?Q?Sten_Daniel_S=F8rsdal?= Message-ID: <20040419044409.A22635@xorpc.icir.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from sten.daniel.sorsdal@wan.no on Mon, Apr 19, 2004 at 01:40:15PM +0200 cc: freebsd-net@freebsd.org Subject: Re: NetBSD/OpenBSD's bridging code - anyone looked at porting it? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2004 11:44:11 -0000 On Mon, Apr 19, 2004 at 01:40:15PM +0200, Sten Daniel Sørsdal wrote: > > Has anyone looked at porting NetBSD/OpenBSD's bridging code? a port was submitted a couple of days ago and we are considering its inclusion luigi > It is my opinion that it is superior in features and standards > compliancy to FreeBSD's current bridging methods. > > _// Sten Daniel Sørsdal > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Mon Apr 19 09:28:54 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4E2E716A4CF for ; Mon, 19 Apr 2004 09:28:54 -0700 (PDT) Received: from aphrodite.gwi.net (aphrodite.gwi.net [207.5.128.164]) by mx1.FreeBSD.org (Postfix) with ESMTP id D7BB443D46 for ; Mon, 19 Apr 2004 09:28:51 -0700 (PDT) (envelope-from peter@easytree.net) Received: from easytree.net (bb-66-63-68-98.gwi.net [66.63.68.98]) by aphrodite.gwi.net (8.12.9p2/8.12.9) with ESMTP id i3JGSotl043557 for ; Mon, 19 Apr 2004 12:28:51 -0400 (EDT) (envelope-from peter@easytree.net) Message-ID: <4083FE42.C5950C95@easytree.net> Date: Mon, 19 Apr 2004 12:28:50 -0400 From: Peter Serwe X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Dlink DWL-650 RevP support? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2004 16:28:54 -0000 Pardon me if this is well covered ground, but I've tried some targeted archive searching, and not found it. I have a DLink DWL-650 card, I believe it's a PRISM3 chipset card. It's the currently available bone-stock, plain 16-bit 11Mbps card running @ 5V. My primary purpose for this card was to use it for wireless security work. I've enabled wi support in my 4.9-STABLE kernel, just cvsup'd and done a make buildworld, buildkernel, installkernel, installworld in single user after rebuilding the kernel last night. I run into the following problem when I insert the card. "pccard[54]: No card in database for "D-Link"("DWL-650 Wireless PC Card RevP") Is there anything I can do, short of writing a driver, which is beyond my capability, to get this card working? If not, can anyone suggest a cheap alternative for a card that will do 11,22, or 54Mbps? Thanks, Peter -- Peter Serwe Cheaper, Faster, Better, pick any two. From owner-freebsd-net@FreeBSD.ORG Mon Apr 19 09:44:28 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E8AE016A4CE for ; Mon, 19 Apr 2004 09:44:28 -0700 (PDT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id F29E843D41 for ; Mon, 19 Apr 2004 09:44:26 -0700 (PDT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i3JGmZox074542 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Apr 2004 19:48:36 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.12.11/8.12.11) id i3JGiHkR043388; Mon, 19 Apr 2004 19:44:17 +0300 (EEST) (envelope-from ru) Date: Mon, 19 Apr 2004 19:44:16 +0300 From: Ruslan Ermilov To: Peter Serwe Message-ID: <20040419164416.GA43338@ip.net.ua> References: <4083FE42.C5950C95@easytree.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2oS5YaxWCcQjTEyO" Content-Disposition: inline In-Reply-To: <4083FE42.C5950C95@easytree.net> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: freebsd-net@freebsd.org Subject: Re: Dlink DWL-650 RevP support? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2004 16:44:29 -0000 --2oS5YaxWCcQjTEyO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 19, 2004 at 12:28:50PM -0400, Peter Serwe wrote: > Pardon me if this is well covered ground, but I've tried > some targeted archive searching, and not found it. >=20 > I have a DLink DWL-650 card, I believe it's a PRISM3 > chipset card. It's the currently available bone-stock, plain > 16-bit 11Mbps card running @ 5V. My primary purpose > for this card was to use it for wireless security work. >=20 > I've enabled wi support in my 4.9-STABLE kernel, just > cvsup'd and done a make buildworld, buildkernel, > installkernel, installworld in single user after rebuilding > the kernel last night. >=20 > I run into the following problem when I insert the card. >=20 > "pccard[54]: No card in database for "D-Link"("DWL-650 Wireless PC Card > RevP") >=20 > Is there anything I can do, short of writing a driver, which > is beyond my capability, to get this card working? If not, > can anyone suggest a cheap alternative for a card that > will do 11,22, or 54Mbps? >=20 No, it's not PRISM. You'd need the NDISulator and 5.2-CURRENT to run it, using native Windows drivers (I've only recently verified it works). Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --2oS5YaxWCcQjTEyO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAhAHgUkv4P6juNwoRAtyWAJ9fctpk/ZS3ZYYFEHw+DTKczZxUeQCfQwsm SHXvS3Ro2rFEN9Shj0knS/k= =jlDh -----END PGP SIGNATURE----- --2oS5YaxWCcQjTEyO-- From owner-freebsd-net@FreeBSD.ORG Mon Apr 19 11:01:36 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6E88E16A4E5 for ; Mon, 19 Apr 2004 11:01:36 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C05C43D49 for ; Mon, 19 Apr 2004 11:01:36 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.10/8.12.10) with ESMTP id i3JI1Zbv042843 for ; Mon, 19 Apr 2004 11:01:35 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.10/8.12.10/Submit) id i3JI1Z9T042826 for freebsd-net@freebsd.org; Mon, 19 Apr 2004 11:01:35 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 19 Apr 2004 11:01:35 -0700 (PDT) Message-Id: <200404191801.i3JI1Z9T042826@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Subject: Current problem reports assigned to you X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2004 18:01:36 -0000 Current FreeBSD problem reports Critical problems Serious problems Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2003/07/11] kern/54383 net NFS root configurations without dynamic p 1 problem total. From owner-freebsd-net@FreeBSD.ORG Mon Apr 19 11:09:14 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 656DF16A4CE; Mon, 19 Apr 2004 11:09:14 -0700 (PDT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5583043D41; Mon, 19 Apr 2004 11:09:14 -0700 (PDT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.9p1/8.12.8) with ESMTP id i3JI9Cgd071974; Mon, 19 Apr 2004 11:09:12 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.9p1/8.12.3/Submit) id i3JI9CCh071973; Mon, 19 Apr 2004 11:09:12 -0700 (PDT) (envelope-from rizzo) Date: Mon, 19 Apr 2004 11:09:12 -0700 From: Luigi Rizzo To: net@freebsd.org, jlemon@freebsd.org Message-ID: <20040419110912.A71274@xorpc.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Subject: what is the story on if_index allocation ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2004 18:09:14 -0000 I am a bit unclear -- how do we allocate if_index values for network interfaces ? I thought the strategy was allocate them sequentially, and only reuse numbers at the top of the allocated range. But then i see if_findindex() is quite complicated, and seems to look for hints using resource_string_value() and resource_find_dev() to possibly recycle old indexes below if_index. Can someone explain what is the goal ? Reuse a number if an interface has the same name of a previously existing one and the index is free ? And does it make sense, anyways, or we could just simplify that code and just reuse the first available entry in ifindex_table[] ? Even the current allocation strategy does not guarantee that indexes reflect the order of creation of interfaces, if that is what we care about. cheers luigi From owner-freebsd-net@FreeBSD.ORG Mon Apr 19 11:33:17 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A6A6716A4CE; Mon, 19 Apr 2004 11:33:17 -0700 (PDT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8CF6643D1F; Mon, 19 Apr 2004 11:33:17 -0700 (PDT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (IDENT:brdavis@localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.12.10/8.12.3) with ESMTP id i3JIXHjU017558; Mon, 19 Apr 2004 11:33:17 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.10/8.12.3/Submit) id i3JIXH4V017555; Mon, 19 Apr 2004 11:33:17 -0700 Date: Mon, 19 Apr 2004 11:33:17 -0700 From: Brooks Davis To: Luigi Rizzo Message-ID: <20040419183316.GE8967@Odin.AC.HMC.Edu> References: <20040419110912.A71274@xorpc.icir.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pQhZXvAqiZgbeUkD" Content-Disposition: inline In-Reply-To: <20040419110912.A71274@xorpc.icir.org> User-Agent: Mutt/1.5.4i cc: net@freebsd.org Subject: Re: what is the story on if_index allocation ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2004 18:33:17 -0000 --pQhZXvAqiZgbeUkD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 19, 2004 at 11:09:12AM -0700, Luigi Rizzo wrote: >=20 > I am a bit unclear -- how do we allocate if_index values for > network interfaces ? > I thought the strategy was allocate them sequentially, and > only reuse numbers at the top of the allocated range. > But then i see if_findindex() is quite complicated, and > seems to look for hints using resource_string_value() and > resource_find_dev() to possibly recycle old indexes below > if_index. >=20 > Can someone explain what is the goal ? Reuse a number if an > interface has the same name of a previously existing one and > the index is free ? And does it make sense, anyways, or > we could just simplify that code and just reuse the first > available entry in ifindex_table[] ? > Even the current allocation strategy does not guarantee that > indexes reflect the order of creation of interfaces, if that > is what we care about. harti recently mentioned that the SNMP RFC requires that interfaces keep the same index across various events including loading and unloading the driver. I suspect this code is an attempt to handle that case. Keying off of lladdrs is probably as close as you're going to get to obeying that requirement in the kernel. I'm not convinced we should worry about it in the kernel. The whole concept of the "same interface" is rather dependent on the particular application context. For instance, when dealing with virtual interfaces on a tunnel server, interfaces could be created and destroyed on demand and if you wanted to do accounting via SNMP indexs should be consistant for each account. I'm tempted to push the whole problem off to userland where appropriate application dependent policies can be implemented. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --pQhZXvAqiZgbeUkD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFAhBtsXY6L6fI4GtQRArXyAJ9fbT/XEK+6ygu4A2E4yyx0XE0w1ACeNzIX 0gTVURU9MZuC8iAy0jA/PI4= =JMWr -----END PGP SIGNATURE----- --pQhZXvAqiZgbeUkD-- From owner-freebsd-net@FreeBSD.ORG Mon Apr 19 11:57:26 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2652516A4CE; Mon, 19 Apr 2004 11:57:26 -0700 (PDT) Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by mx1.FreeBSD.org (Postfix) with ESMTP id AB39E43D46; Mon, 19 Apr 2004 11:57:23 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (sccrmhc13) with ESMTP id <20040419185722016003q2sfe>; Mon, 19 Apr 2004 18:57:22 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA03944; Mon, 19 Apr 2004 11:57:20 -0700 (PDT) Date: Mon, 19 Apr 2004 11:57:19 -0700 (PDT) From: Julian Elischer To: Ruslan Ermilov In-Reply-To: <20040419081225.GG39799@ip.net.ua> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Daniel O'Connor cc: freebsd-net@freebsd.org Subject: Re: Netgraph and non-ethernet nodes? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2004 18:57:26 -0000 On Mon, 19 Apr 2004, Ruslan Ermilov wrote: > On Mon, Apr 19, 2004 at 01:02:31AM -0700, Julian Elischer wrote: > > > > > > On Mon, 19 Apr 2004, Daniel O'Connor wrote: > > > > > On Mon, 19 Apr 2004 13:09, Brooks Davis wrote: > > > > On Mon, Apr 19, 2004 at 12:56:24PM +0930, Daniel O'Connor wrote: > > > > > The recent emails about the bridge code from NetBSD made me interested in > > > > > using netgraph to run snort on the combined traffic rather than having to > > > > > run 2 copies (since we tunnel our class C using gif over IP over > > > > > ethernet), however I can't see how to hook netgraph into a non-ethernet > > > > > node :( > > > > > > > > > > Does anyone know if/how you can do it? (Specifically for gif) > > > > > > > > How about nf_gif(4)? > > > > > > Hmm, I see the man page, but no module.. Ahh, it doesn't appear to be built by > > > default.. > > > > > > And it's not on my -stable box, guess I should do a manual merge :) > > > > > > > there are some basic differences between netgraph nodes in -current and > > in 4.x > > check out the differences in a few nodes (e.g. ng_sample.c) > > > > to see what they are. > > > > in particular... in 4.x and earlier, the mbuf and metadaa are handled > > separatly as arguments to things but in 5.x > > they are both held in (well a pointer is in..) a struct item. > > > > which is passed around... the item structure needs to be freed if you > > destroy it and there are macros to extract the mbuf and metadata > > from the item. This is because in 5.x we often need to queue teh packet > > including metadata and the 'item' is what is queued. > > > While we're on this topic, I wonder if you have plans to get rid > of non-funcional diffs for ng_sample.[ch] between RELENG_4 and > HEAD? If not, I could do it, and send you a patch (for RELENG_4) > for review. let me see what you propose. > > > Cheers, > -- > Ruslan Ermilov > ru@FreeBSD.org > FreeBSD committer > From owner-freebsd-net@FreeBSD.ORG Mon Apr 19 12:28:26 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8373A16A4CF; Mon, 19 Apr 2004 12:28:26 -0700 (PDT) Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6FE8C43D39; Mon, 19 Apr 2004 12:28:26 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (rwcrmhc12) with ESMTP id <2004041919282501400ri643e>; Mon, 19 Apr 2004 19:28:26 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA04222; Mon, 19 Apr 2004 12:28:24 -0700 (PDT) Date: Mon, 19 Apr 2004 12:28:23 -0700 (PDT) From: Julian Elischer To: Luigi Rizzo In-Reply-To: <20040419110912.A71274@xorpc.icir.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: net@freebsd.org Subject: Re: what is the story on if_index allocation ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2004 19:28:26 -0000 >From memory, It's completely un-needed except that some standards want to access interfaces by index for statitics purposes. On Mon, 19 Apr 2004, Luigi Rizzo wrote: > > I am a bit unclear -- how do we allocate if_index values for > network interfaces ? > I thought the strategy was allocate them sequentially, and > only reuse numbers at the top of the allocated range. > But then i see if_findindex() is quite complicated, and > seems to look for hints using resource_string_value() and > resource_find_dev() to possibly recycle old indexes below > if_index. > > Can someone explain what is the goal ? Reuse a number if an > interface has the same name of a previously existing one and > the index is free ? And does it make sense, anyways, or > we could just simplify that code and just reuse the first > available entry in ifindex_table[] ? > Even the current allocation strategy does not guarantee that > indexes reflect the order of creation of interfaces, if that > is what we care about. > > cheers > luigi > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Mon Apr 19 15:43:30 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B0D2416A4CE for ; Mon, 19 Apr 2004 15:43:30 -0700 (PDT) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9330243D39 for ; Mon, 19 Apr 2004 15:43:30 -0700 (PDT) (envelope-from billf@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1098) id 8CE3F5C7F9; Mon, 19 Apr 2004 15:43:30 -0700 (PDT) Date: Mon, 19 Apr 2004 15:43:30 -0700 From: Bill Fumerola To: Julian Elischer Message-ID: <20040419224330.GN17862@elvis.mu.org> References: <20040419110912.A71274@xorpc.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 4.10-MUORG-20040412 i386 X-PGP-Key: 1024D/7F868268 X-PGP-Fingerprint: 5B2D 908E 4C2B F253 DAEB FC01 8436 B70B 7F86 8268 cc: Luigi Rizzo cc: net@freebsd.org Subject: Re: what is the story on if_index allocation ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2004 22:43:30 -0000 On Mon, Apr 19, 2004 at 12:28:23PM -0700, Julian Elischer wrote: > It's completely un-needed except that some standards want to access > interfaces by index for statitics purposes. they're "un-needed" in much the same way that statically assigning disk numbers is "un-needed". sure, the disks don't light on fire without it, but some consistancy and persistance does make things nice. for comparison: vendor C has a default-to-off option for this (''snmp ifindex persist'') which pre-allocates numbers loosely based on max_modules * max_ports_in_modules and dumps this mapping into the filesystem. vendor J allocates dynamically and won't reuse ifIndex numbers over the life of a router. a way of keeping indexes consistant for a given named interface (even across creation/destruction via cloning, kld, etc) is most certainly a desirable feature. the more persistant this can be made (life of the module all the way up to life of device) the better. i disagree that this logic belongs outside the kernel in the snmp agent. an inconsistant if_index makes it difficult and error prone for using the index in multiple utilities whose data may be combined/joined/scaled with information from the snmp agent's IF-MIB/ifXTable tables. -- - bill fumerola / fumerola@yahoo-inc.com / billf@FreeBSD.org From owner-freebsd-net@FreeBSD.ORG Mon Apr 19 22:09:13 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 13DDB16A4CE; Mon, 19 Apr 2004 22:09:13 -0700 (PDT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id C7FB043D4C; Mon, 19 Apr 2004 22:09:12 -0700 (PDT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.9p1/8.12.8) with ESMTP id i3K59Bgd023835; Mon, 19 Apr 2004 22:09:11 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.9p1/8.12.3/Submit) id i3K59AVB023834; Mon, 19 Apr 2004 22:09:10 -0700 (PDT) (envelope-from rizzo) Date: Mon, 19 Apr 2004 22:09:10 -0700 From: Luigi Rizzo To: Bill Fumerola Message-ID: <20040419220910.A23186@xorpc.icir.org> References: <20040419110912.A71274@xorpc.icir.org> <20040419224330.GN17862@elvis.mu.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: <20040419224330.GN17862@elvis.mu.org>; from billf@freebsd.org on Mon, Apr 19, 2004 at 03:43:30PM -0700 cc: Julian Elischer cc: net@freebsd.org Subject: Re: what is the story on if_index allocation ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2004 05:09:13 -0000 On Mon, Apr 19, 2004 at 03:43:30PM -0700, Bill Fumerola wrote: ... > > they're "un-needed" in much the same way that statically assigning disk > numbers is "un-needed". sure, the disks don't light on fire without it, > but some consistancy and persistance does make things nice. ... > i disagree that this logic belongs outside the kernel in the snmp agent. "outside the kernel" just means it can be in a library so consistency is preserved. After all if_nametoindex() is already a library. In any case my point is that in the kernel we do need an identifier associated to existing interfaces that can be used to quickly lookup information associated to the interface and that for various reasons (historical, locking, modularity) could be split in different data structures. If if_index does not have that semantics fine, then we just need something else. cheers luigi > an inconsistant if_index makes it difficult and error prone for using > the index in multiple utilities whose data may be combined/joined/scaled > with information from the snmp agent's IF-MIB/ifXTable tables. > > -- > - bill fumerola / fumerola@yahoo-inc.com / billf@FreeBSD.org > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Tue Apr 20 00:23:44 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1387C16A4D0 for ; Tue, 20 Apr 2004 00:23:44 -0700 (PDT) Received: from v6.hitachi.co.jp (galilei.v6.hitachi.co.jp [133.145.167.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id A54D243D3F for ; Tue, 20 Apr 2004 00:23:42 -0700 (PDT) (envelope-from suz@crl.hitachi.co.jp) Received: from s30.uki-uki.net (galilei.v6.hitachi.co.jp [IPv6:2001:200:165::1]) by v6.hitachi.co.jp (8.12.11/8.11.6) with ESMTP id i3K7Nd1w079935; Tue, 20 Apr 2004 16:23:41 +0900 (JST) (envelope-from suz@crl.hitachi.co.jp) Date: Tue, 20 Apr 2004 16:23:38 +0900 Message-ID: From: SUZUKI Shinsuke To: monicadomingues@hotmail.com X-cite: xcite 1.33 In-Reply-To: References: User-Agent: User-Agent: Wanderlust/2.11.26 (Wonderwall) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Network Systems Research Dept., Central Research Laboratory, Hitachi, Ltd, Japan MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable cc: freebsd-net@freebsd.org Subject: Re: pim6sd configuration X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2004 07:23:44 -0000 Hi, >>>>> On Thu, 15 Apr 2004 12:35:03 +0000 >>>>> monicadomingues@hotmail.com("M=F3nica Domingues") said: (snip) > In file /etc/pim6sd.conf I have: > phyint xl1 mld_version 2; > > When I open pim6sd.log I don't have any log, is this normal? > I'am I doing this the right way? Seems like pim6sd does not start because of the following reasons. Could you please check these point? - typo in rc.conf: you said mroute6d_program is "usr/local/v6/sbin/pim6sd", but IMHO, it has to be specified in absolute path. - network configuration error: pim6sd needs more than one IPv6 interfaces to do multicast routing, but I'm not sure if you are really configuring IPv6 on interfaces other than xl1. - some other reason: By default, pim6sd logs severe error info in /var/log/pim6sd.log. So you should raed this file to know what happens. Thanks, ---- SUZUKI, Shinsuke @ Hitachi / KAME Project =09 =09 From owner-freebsd-net@FreeBSD.ORG Tue Apr 20 00:28:59 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C9FAB16A4CE for ; Tue, 20 Apr 2004 00:28:59 -0700 (PDT) Received: from spooky.eis.net.au (spooky.eis.net.au [203.12.171.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2A77943D53 for ; Tue, 20 Apr 2004 00:28:59 -0700 (PDT) (envelope-from ernie@spooky.eis.net.au) Received: (from ernie@localhost) by spooky.eis.net.au (8.12.11/8.12.11) id i3K7Sshp025316 for freebsd-net@freebsd.org; Tue, 20 Apr 2004 17:28:54 +1000 (EST) (envelope-from ernie) From: User Ernie Message-Id: <200404200728.i3K7Sshp025316@spooky.eis.net.au> To: freebsd-net@freebsd.org Date: Tue, 20 Apr 2004 17:28:54 +1000 (EST) X-Mailer: ELM [version 2.4ME+ PL99b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Subject: AODV X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2004 07:28:59 -0000 Anyone know of an AODV port to FreeBSD or any other mesh routing protocol that would suit a community wireless adhoc network? - Ernie. From owner-freebsd-net@FreeBSD.ORG Tue Apr 20 00:50:16 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C41B616A4CE for ; Tue, 20 Apr 2004 00:50:16 -0700 (PDT) Received: from mail.cs.tu-berlin.de (mail.cs.tu-berlin.de [130.149.17.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id E558243D45 for ; Tue, 20 Apr 2004 00:50:15 -0700 (PDT) (envelope-from novo@cs.tu-berlin.de) Received: from 130-149-145-34.dialup.cs.tu-berlin.de (130-149-145-34.dialup.cs.tu-berlin.de [130.149.145.34]) by mail.cs.tu-berlin.de (8.9.3p2/8.9.3) with ESMTP id JAA18888; Tue, 20 Apr 2004 09:48:12 +0200 (MET DST) Date: Tue, 20 Apr 2004 09:48:46 +0200 (CEST) From: Harti Brandt X-X-Sender: novo@130-149-145-34.dialup.cs.tu-berlin.de To: Brooks Davis In-Reply-To: <20040419183316.GE8967@Odin.AC.HMC.Edu> Message-ID: <20040420093254.V613@130-149-145-114.dialup.cs.tu-berlin.de> References: <20040419110912.A71274@xorpc.icir.org> <20040419183316.GE8967@Odin.AC.HMC.Edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Luigi Rizzo cc: net@FreeBSD.ORG Subject: Re: what is the story on if_index allocation ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: harti@FreeBSD.ORG List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2004 07:50:16 -0000 On Mon, 19 Apr 2004, Brooks Davis wrote: > On Mon, Apr 19, 2004 at 11:09:12AM -0700, Luigi Rizzo wrote: > > > > I am a bit unclear -- how do we allocate if_index values for > > network interfaces ? > > I thought the strategy was allocate them sequentially, and > > only reuse numbers at the top of the allocated range. > > But then i see if_findindex() is quite complicated, and > > seems to look for hints using resource_string_value() and > > resource_find_dev() to possibly recycle old indexes below > > if_index. > > > > Can someone explain what is the goal ? Reuse a number if an > > interface has the same name of a previously existing one and > > the index is free ? And does it make sense, anyways, or > > we could just simplify that code and just reuse the first > > available entry in ifindex_table[] ? > > Even the current allocation strategy does not guarantee that > > indexes reflect the order of creation of interfaces, if that > > is what we care about. > > harti recently mentioned that the SNMP RFC requires that interfaces > keep the same index across various events including loading and > unloading the driver. I suspect this code is an attempt to handle that > case. Keying off of lladdrs is probably as close as you're going to get > to obeying that requirement in the kernel. I'm not convinced we should > worry about it in the kernel. The whole concept of the "same interface" > is rather dependent on the particular application context. For > instance, when dealing with virtual interfaces on a tunnel server, > interfaces could be created and destroyed on demand and if you wanted to > do accounting via SNMP indexs should be consistant for each account. > I'm tempted to push the whole problem off to userland where appropriate > application dependent policies can be implemented. After some thinking about the issue I think that the concept of 'the same interface' isn't valid anymore - it comes from times, where you had only hardware interfaces that you could change only by opening the computer. Nowadays with hot-plugable and several kinds of virtual interfaces that becomes very moot. Even with normal interfaces the whole thing is questionable. If you have, for example, a router that has xl0 to the outer world and xl1 to you local network and you swap these two interfaces, then you probably want (from the management point of view) xl0 now to become the 'same' as xl1 was - just the connection to the local network. It would be extremly hard to implement this in the kernel or even in a general purpose SNMP daemon. Given the complexity of that stuff, I think I throw it out of the SNMP daemon in the next release. harti From owner-freebsd-net@FreeBSD.ORG Tue Apr 20 01:05:36 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CEF9D16A4CE; Tue, 20 Apr 2004 01:05:36 -0700 (PDT) Received: from mail.cs.tu-berlin.de (mail.cs.tu-berlin.de [130.149.17.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id D0CB343D31; Tue, 20 Apr 2004 01:05:35 -0700 (PDT) (envelope-from novo@cs.tu-berlin.de) Received: from 130-149-145-34.dialup.cs.tu-berlin.de (130-149-145-34.dialup.cs.tu-berlin.de [130.149.145.34]) by mail.cs.tu-berlin.de (8.9.3p2/8.9.3) with ESMTP id KAA21046; Tue, 20 Apr 2004 10:00:29 +0200 (MET DST) Date: Tue, 20 Apr 2004 10:01:03 +0200 (CEST) From: Harti Brandt X-X-Sender: novo@130-149-145-34.dialup.cs.tu-berlin.de To: Bill Fumerola In-Reply-To: <20040419224330.GN17862@elvis.mu.org> Message-ID: <20040420095454.S728@130-149-145-34.dialup.cs.tu-berlin.de> References: <20040419110912.A71274@xorpc.icir.org> <20040419224330.GN17862@elvis.mu.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Luigi Rizzo cc: Julian Elischer cc: net@FreeBSD.ORG Subject: Re: what is the story on if_index allocation ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: harti@FreeBSD.ORG List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2004 08:05:36 -0000 On Mon, 19 Apr 2004, Bill Fumerola wrote: > i disagree that this logic belongs outside the kernel in the snmp agent. > an inconsistant if_index makes it difficult and error prone for using > the index in multiple utilities whose data may be combined/joined/scaled > with information from the snmp agent's IF-MIB/ifXTable tables. The question is based on what do you decide to give an interface the same index? Same hardware name? Same PCI slot? Same MAC address (what about interfaces without MAC addresses and virtual interfaces)? Same IP address (what about interfaces without IP address)? In the bSNMP daemon currently I have two classes of interfaces: real ones and 'dynamic' ones. For real ones I remember their name through the uptime of the daemon and assign them the same index when they re-appear (by loading/unloading the driver) with the same name. Actually I think that an application (statistics or others) should look at the timestamp of the last change of an interface and assume that the interface is another one even if it has the same index if the timestamp changed. harti From owner-freebsd-net@FreeBSD.ORG Tue Apr 20 03:29:13 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1EBF616A4CE for ; Tue, 20 Apr 2004 03:29:13 -0700 (PDT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8A60843D54 for ; Tue, 20 Apr 2004 03:29:12 -0700 (PDT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id D8F996543B; Tue, 20 Apr 2004 11:29:10 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 07537-04-7; Tue, 20 Apr 2004 11:29:10 +0100 (BST) Received: from empiric.dek.spc.org (82-147-17-88.dsl.uk.rapidplay.com [82.147.17.88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id A7B4C6543E; Tue, 20 Apr 2004 11:29:09 +0100 (BST) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id 5A3926135; Tue, 20 Apr 2004 11:29:07 +0100 (BST) Date: Tue, 20 Apr 2004 11:29:07 +0100 From: Bruce M Simpson To: User Ernie Message-ID: <20040420102907.GA17879@empiric.dek.spc.org> Mail-Followup-To: User Ernie , freebsd-net@freebsd.org References: <200404200728.i3K7Sshp025316@spooky.eis.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200404200728.i3K7Sshp025316@spooky.eis.net.au> cc: freebsd-net@freebsd.org Subject: Re: AODV X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2004 10:29:13 -0000 On Tue, Apr 20, 2004 at 05:28:54PM +1000, User Ernie wrote: > Anyone know of an AODV port to FreeBSD or any other mesh routing protocol > that would suit a community wireless adhoc network? My work is unfinished at this time due to lack of funding, but can be found in Perforce at //depot/user/bms/aodv/aodvd/... Regards, BMS From owner-freebsd-net@FreeBSD.ORG Tue Apr 20 03:58:54 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 49E7B16A4CE for ; Tue, 20 Apr 2004 03:58:54 -0700 (PDT) Received: from hermes.ccf.auth.gr (hermes.ccf.auth.gr [155.207.1.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id F1A5D43D31 for ; Tue, 20 Apr 2004 03:58:52 -0700 (PDT) (envelope-from gedimitr@auth.gr) Received: from a93 (a93.ee.auth.gr [155.207.19.93]) by hermes.ccf.auth.gr (8.12.10/8.12.10) with SMTP id i3KAwloi001833; Tue, 20 Apr 2004 13:58:47 +0300 (EEST) Message-ID: <004401c426c6$7468c5a0$5d13cf9b@ee.auth.gr> From: "Gerasimos Dimitriadis" To: "User Ernie" References: <200404200728.i3K7Sshp025316@spooky.eis.net.au> Date: Tue, 20 Apr 2004 13:58:46 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Virus-Scanned: by helios.ccf.auth.gr X-Virus-Scanned: clamd / ClamAV version devel-20040419, clamav-milter version 0.70k cc: freebsd-net@freebsd.org Subject: Re: AODV X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2004 10:58:54 -0000 > Anyone know of an AODV port to FreeBSD or any other mesh routing protocol > that would suit a community wireless adhoc network? You can try my GSR implementation for netgraph (unfortunately, still only for 5.x) available at: http://newton.ee.auth.gr/ng_daphne/ng_daphne-1.0.tar.gz Bst regards, Gerasimos From owner-freebsd-net@FreeBSD.ORG Tue Apr 20 05:53:04 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AD26816A4CE for ; Tue, 20 Apr 2004 05:53:04 -0700 (PDT) Received: from ioskeha.hittite.isp.9tel.net (ioskeha.hittite.isp.9tel.net [62.62.156.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2B41243D1D for ; Tue, 20 Apr 2004 05:53:04 -0700 (PDT) (envelope-from clefevre-lists@9online.fr) Received: from pc2k (unknown [81.185.56.92]) by ioskeha.hittite.isp.9tel.net (Postfix) with SMTP id 40D3817B4D4 for ; Tue, 20 Apr 2004 14:53:33 +0200 (CEST) Message-ID: <01cc01c426d6$6a9d5850$7890a8c0@dyndns.org> From: "Cyrille Lefevre" To: Date: Tue, 20 Apr 2004 14:52:45 +0200 Organization: ACME MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Subject: apm and network cards X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2004 12:53:04 -0000 Hi, is there a way to not suspend network cards when apm is enabled whether in automatic mode or manually through zzz ? for instance, the only way I've found is to emit zzz manually (to sleep my ata disks which I don't use), then wake-up through the keyboard, then apm -e disable. if I don't disable apm, I'm enable to remote connect to my machine (after zzz, or after some time). thanks in advance. Cyrille Lefevre. -- mailto:clefevre-lists@9online.fr From owner-freebsd-net@FreeBSD.ORG Tue Apr 20 07:10:19 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 02C8216A4D1; Tue, 20 Apr 2004 07:10:19 -0700 (PDT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 52D3743D5D; Tue, 20 Apr 2004 07:10:18 -0700 (PDT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 5174F65371; Tue, 20 Apr 2004 15:10:16 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 10357-03; Tue, 20 Apr 2004 15:10:15 +0100 (BST) Received: from empiric.dek.spc.org (82-147-17-88.dsl.uk.rapidplay.com [82.147.17.88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id 7D96D652FE; Tue, 20 Apr 2004 15:10:10 +0100 (BST) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id DA21D6132; Tue, 20 Apr 2004 15:10:11 +0100 (BST) Date: Tue, 20 Apr 2004 15:10:11 +0100 From: Bruce M Simpson To: Bill Fumerola Message-ID: <20040420141011.GB18177@empiric.dek.spc.org> References: <20040419110912.A71274@xorpc.icir.org> <20040419224330.GN17862@elvis.mu.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="MGYHOYXEY6WxJCY8" Content-Disposition: inline In-Reply-To: <20040419224330.GN17862@elvis.mu.org> cc: Luigi Rizzo cc: Julian Elischer cc: net@freebsd.org Subject: Re: what is the story on if_index allocation ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2004 14:10:19 -0000 --MGYHOYXEY6WxJCY8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 19, 2004 at 03:43:30PM -0700, Bill Fumerola wrote: > On Mon, Apr 19, 2004 at 12:28:23PM -0700, Julian Elischer wrote: > > It's completely un-needed except that some standards want to access=20 > > interfaces by index for statitics purposes. >=20 > they're "un-needed" in much the same way that statically assigning disk > numbers is "un-needed". sure, the disks don't light on fire without it, > but some consistancy and persistance does make things nice. My very own AODV routing daemon uses the if_index to track interfaces going away and coming back... BMS --MGYHOYXEY6WxJCY8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Comment: '' iD8DBQFAhS9DueUpAYYNtTsRAjDOAJ0UW3jyQKNR9pOJgUGkJsnp7E/YmACfaoNJ DbKir+ueeMooM3fjpYK/6cM= =/4lQ -----END PGP SIGNATURE----- --MGYHOYXEY6WxJCY8-- From owner-freebsd-net@FreeBSD.ORG Tue Apr 20 10:15:40 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DFD2916A4CE for ; Tue, 20 Apr 2004 10:15:40 -0700 (PDT) Received: from hotmail.com (bay14-f31.bay14.hotmail.com [64.4.49.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id BD86143D5A for ; Tue, 20 Apr 2004 10:15:40 -0700 (PDT) (envelope-from monicadomingues@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 20 Apr 2004 10:15:40 -0700 Received: from 193.137.232.15 by by14fd.bay14.hotmail.msn.com with HTTP; Tue, 20 Apr 2004 17:15:40 GMT X-Originating-IP: [193.137.232.15] X-Originating-Email: [monicadomingues@hotmail.com] X-Sender: monicadomingues@hotmail.com From: "Mónica Domingues" To: freebsd-net@freebsd.org Date: Tue, 20 Apr 2004 17:15:40 +0000 Message-ID: X-OriginalArrivalTime: 20 Apr 2004 17:15:40.0635 (UTC) FILETIME=[1B16EAB0:01C426FB] MIME-Version: 1.0 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: web cam usb X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2004 17:15:41 -0000 Hello, I need help to install a usb web cam in FreeBSD 4.9. I'am using a Creative camera. I already put in file /etc/rc.conf usbd_enable="YES" Thank's for the attention, Mónica Domingues _________________________________________________________________ Add photos to your e-mail with [1]MSN 8. Get 2 months FREE*. References 1. http://g.msn.com/8HMAEN/2746??PS= From owner-freebsd-net@FreeBSD.ORG Tue Apr 20 10:28:13 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4114F16A4CE for ; Tue, 20 Apr 2004 10:28:13 -0700 (PDT) Received: from home.bluegrass.sk (home.bluegrass.sk [195.168.129.26]) by mx1.FreeBSD.org (Postfix) with SMTP id A19FE43D1F for ; Tue, 20 Apr 2004 10:28:11 -0700 (PDT) (envelope-from milan.obuch@bluegrass.sk) Received: (qmail 29532 invoked from network); 20 Apr 2004 17:28:50 -0000 Received: from tmp.bluegrass.sk (HELO localhost.invalid) (195.168.129.28) by bsd.bluegrass.sk with SMTP; 20 Apr 2004 17:28:50 -0000 From: Milan Obuch To: freebsd-net@freebsd.org Date: Tue, 20 Apr 2004 19:28:10 +0200 User-Agent: KMail/1.6 References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <200404201928.10836.milan.obuch@bluegrass.sk> Subject: Re: web cam usb X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2004 17:28:13 -0000 On Tuesday 20 April 2004 19:15, M=F3nica Domingues wrote: > Hello, > > I need help to install a usb web cam in FreeBSD 4.9. > I'am using a Creative camera. > I already put in file /etc/rc.conf > usbd_enable=3D"YES" > > Thank's for the attention, > M=F3nica Domingues > Look at http://www2.starcat.ne.jp/~takam/bsd/NetBSD.html, it could help you. Milan From owner-freebsd-net@FreeBSD.ORG Tue Apr 20 21:24:54 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 08FF116A4CE for ; Tue, 20 Apr 2004 21:24:54 -0700 (PDT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id AB9F543D4C for ; Tue, 20 Apr 2004 21:24:53 -0700 (PDT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (IDENT:brdavis@localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.12.10/8.12.3) with ESMTP id i3L4OrjU011807 for ; Tue, 20 Apr 2004 21:24:53 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.10/8.12.3/Submit) id i3L4Or3L011806 for net@freebsd.org; Tue, 20 Apr 2004 21:24:53 -0700 Date: Tue, 20 Apr 2004 21:24:53 -0700 From: Brooks Davis To: net@freebsd.org Message-ID: <20040421042453.GA8866@Odin.AC.HMC.Edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="opJtzjQTFsWo+cga" Content-Disposition: inline User-Agent: Mutt/1.5.4i Subject: RFC: if_clone overhaul X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2004 04:24:54 -0000 --opJtzjQTFsWo+cga Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Please test/review the following patch to the network interface cloneing code. This code is a major overhaul of the cloning infrastructure. The significant include: - Split the code out into if_clone.[ch]. - Locked struct if_clone. Derived from work by Maurycy Pawlowski-Wieronski - Add a per-cloner match function rather then simply matching names of the form and . - Use the match function to allow creation of . vlan interfaces. The old way is preserved unchanged! - Also the match function to allow creation of stf(4) interfaces named stf0, stf, or 6to4. This is the only major user visiable change in that "ifconfig stf" creates the interface stf rather then stf0 and does not print "stf0" to stdout. - Allow destroy functions to fail so they can refuse to delete interfaces. Currently, we forbid the deletion of interfaces which were created in the init function, particularly lo0, pflog0, and pfsync0. In the case of lo0 this was a panic implemenation so it does not count as a user visiable change. :-) - Since most interfaces do not need the new functionality, an family of wrapper functions, ifc_simple_*(), were created to wrap old style cloner functions. - The IF_CLONE_INITIALIZER macro is replaced with a new incompatable IFC_CLONE_INITALIZER and ifc_simple consumers use IFC_SIMPLE_DECLARE instead. TODO: - Integrate vlan changes into /etc/rc* (add support for interfaces with '.' in their name). - Document new vlan syntax in vlan(4). Patch also available at: http://people.freebsd.org/~brooks/patches/ifclone.diff -- Brooks Changed files: sys/conf/files sys/net/if_var.h sys/net/if.c sys/net/if_disc.c sys/net/if_faith.c sys/net/if_gif.c sys/net/if_gre.c sys/net/if_loop.c sys/net/if_ppp.c sys/net/if_stf.c sys/net/if_vlan.c sys/contrib/pf/net/if_pflog.c sys/contrib/pf/net/if_pfsync.c Added files: sys/net/if_clone.h sys/net/if_clone.c --- ../cleanup/sys/conf/files Tue Apr 20 19:16:42 2004 +++ sys/conf/files Tue Apr 20 19:21:52 2004 @@ -1200,6 +1200,7 @@ net/if.c standard net/if_arcsubr.c optional arcnet net/if_atmsubr.c optional atm +net/if_clone.c standard net/if_disc.c optional disc net/if_ef.c optional ef net/if_ethersubr.c optional ether --- ../cleanup/sys/net/if_var.h Sun Apr 18 17:26:34 2004 +++ sys/net/if_var.h Sun Apr 18 17:30:02 2004 @@ -299,9 +299,6 @@ /* interface departure event */ typedef void (*ifnet_departure_event_handler_t)(void *, struct ifnet *); EVENTHANDLER_DECLARE(ifnet_departure_event, ifnet_departure_event_handler_= t); -/* interface clone event */ -typedef void (*if_clone_event_handler_t)(void *, struct if_clone *); -EVENTHANDLER_DECLARE(if_clone_event, if_clone_event_handler_t); =20 #define IF_AFDATA_LOCK_INIT(ifp) \ mtx_init(&(ifp)->if_afdata_mtx, "if_afdata", NULL, MTX_DEF) @@ -486,12 +483,6 @@ =20 struct ifmultiaddr *ifmaof_ifpforaddr(struct sockaddr *, struct ifnet *); int if_simloop(struct ifnet *ifp, struct mbuf *m, int af, int hlen); - -void if_clone_attach(struct if_clone *); -void if_clone_detach(struct if_clone *); - -int if_clone_create(char *, int); -int if_clone_destroy(const char *); =20 #define IF_LLADDR(ifp) \ LLADDR((struct sockaddr_dl *) ifaddr_byindex((ifp)->if_index)->ifa_add= r) --- ../cleanup/sys/net/if.c Tue Apr 20 19:16:42 2004 +++ sys/net/if.c Tue Apr 20 19:21:53 2004 @@ -56,6 +56,7 @@ =20 #include #include +#include #include #include #include @@ -88,8 +89,6 @@ static void if_unroute(struct ifnet *, int flag, int fam); static void link_rtrequest(int, struct rtentry *, struct rt_addrinfo *); static int if_rtdel(struct radix_node *, void *); -static struct if_clone *if_clone_lookup(const char *, int *); -static int if_clone_list(struct if_clonereq *); static int ifhwioctl(u_long, struct ifnet *, caddr_t, struct thread *); #ifdef INET6 /* @@ -104,8 +103,6 @@ int ifqmaxlen =3D IFQ_MAXLEN; struct ifnethead ifnet; /* depend on static init XXX */ struct mtx ifnet_lock; -static int if_cloners_count; -LIST_HEAD(, if_clone) if_cloners =3D LIST_HEAD_INITIALIZER(if_cloners); =20 static int if_indexlim =3D 8; static struct klist ifklist; @@ -124,7 +121,6 @@ =20 MALLOC_DEFINE(M_IFADDR, "ifaddr", "interface address"); MALLOC_DEFINE(M_IFMADDR, "ether_multi", "link-level multicast address"); -MALLOC_DEFINE(M_CLONE, "clone", "interface cloning framework"); =20 static d_open_t netopen; static d_close_t netclose; @@ -261,6 +257,7 @@ if_grow(); /* create initial table */ ifdev_byindex(0) =3D make_dev(&net_cdevsw, 0, UID_ROOT, GID_WHEEL, 0600, "network"); + if_clone_init(); } =20 static void @@ -653,243 +650,6 @@ } =20 return (0); -} - -/* - * Create a clone network interface. - */ -int -if_clone_create(char *name, int len) -{ - struct if_clone *ifc; - char *dp; - int wildcard, bytoff, bitoff; - int unit; - int err; - - ifc =3D if_clone_lookup(name, &unit); - if (ifc =3D=3D NULL) - return (EINVAL); - - if (ifunit(name) !=3D NULL) - return (EEXIST); - - bytoff =3D bitoff =3D 0; - wildcard =3D (unit < 0); - /* - * Find a free unit if none was given. - */ - if (wildcard) { - while ((bytoff < ifc->ifc_bmlen) - && (ifc->ifc_units[bytoff] =3D=3D 0xff)) - bytoff++; - if (bytoff >=3D ifc->ifc_bmlen) - return (ENOSPC); - while ((ifc->ifc_units[bytoff] & (1 << bitoff)) !=3D 0) - bitoff++; - unit =3D (bytoff << 3) + bitoff; - } - - if (unit > ifc->ifc_maxunit) - return (ENXIO); - - err =3D (*ifc->ifc_create)(ifc, unit); - if (err !=3D 0) - return (err); - - if (!wildcard) { - bytoff =3D unit >> 3; - bitoff =3D unit - (bytoff << 3); - } - - /* - * Allocate the unit in the bitmap. - */ - KASSERT((ifc->ifc_units[bytoff] & (1 << bitoff)) =3D=3D 0, - ("%s: bit is already set", __func__)); - ifc->ifc_units[bytoff] |=3D (1 << bitoff); - - /* In the wildcard case, we need to update the name. */ - if (wildcard) { - for (dp =3D name; *dp !=3D '\0'; dp++); - if (snprintf(dp, len - (dp-name), "%d", unit) > - len - (dp-name) - 1) { - /* - * This can only be a programmer error and - * there's no straightforward way to recover if - * it happens. - */ - panic("if_clone_create(): interface name too long"); - } - - } - - return (0); -} - -/* - * Destroy a clone network interface. - */ -int -if_clone_destroy(const char *name) -{ - struct if_clone *ifc; - struct ifnet *ifp; - int bytoff, bitoff; - int unit; - - ifp =3D ifunit(name); - if (ifp =3D=3D NULL) - return (ENXIO); - - unit =3D ifp->if_dunit; - - ifc =3D if_clone_lookup(ifp->if_dname, NULL); - if (ifc =3D=3D NULL) - return (EINVAL); - - if (ifc->ifc_destroy =3D=3D NULL) - return (EOPNOTSUPP); - - (*ifc->ifc_destroy)(ifp); - - /* - * Compute offset in the bitmap and deallocate the unit. - */ - bytoff =3D unit >> 3; - bitoff =3D unit - (bytoff << 3); - KASSERT((ifc->ifc_units[bytoff] & (1 << bitoff)) !=3D 0, - ("%s: bit is already cleared", __func__)); - ifc->ifc_units[bytoff] &=3D ~(1 << bitoff); - return (0); -} - -/* - * Look up a network interface cloner. - */ -static struct if_clone * -if_clone_lookup(const char *name, int *unitp) -{ - struct if_clone *ifc; - const char *cp; - int i; - - for (ifc =3D LIST_FIRST(&if_cloners); ifc !=3D NULL;) { - for (cp =3D name, i =3D 0; i < ifc->ifc_namelen; i++, cp++) { - if (ifc->ifc_name[i] !=3D *cp) - goto next_ifc; - } - goto found_name; - next_ifc: - ifc =3D LIST_NEXT(ifc, ifc_list); - } - - /* No match. */ - return ((struct if_clone *)NULL); - - found_name: - if (*cp =3D=3D '\0') { - i =3D -1; - } else { - for (i =3D 0; *cp !=3D '\0'; cp++) { - if (*cp < '0' || *cp > '9') { - /* Bogus unit number. */ - return (NULL); - } - i =3D (i * 10) + (*cp - '0'); - } - } - - if (unitp !=3D NULL) - *unitp =3D i; - return (ifc); -} - -/* - * Register a network interface cloner. - */ -void -if_clone_attach(struct if_clone *ifc) -{ - int bytoff, bitoff; - int err; - int len, maxclone; - int unit; - - KASSERT(ifc->ifc_minifs - 1 <=3D ifc->ifc_maxunit, - ("%s: %s requested more units then allowed (%d > %d)", - __func__, ifc->ifc_name, ifc->ifc_minifs, - ifc->ifc_maxunit + 1)); - /* - * Compute bitmap size and allocate it. - */ - maxclone =3D ifc->ifc_maxunit + 1; - len =3D maxclone >> 3; - if ((len << 3) < maxclone) - len++; - ifc->ifc_units =3D malloc(len, M_CLONE, M_WAITOK | M_ZERO); - ifc->ifc_bmlen =3D len; - - LIST_INSERT_HEAD(&if_cloners, ifc, ifc_list); - if_cloners_count++; - - for (unit =3D 0; unit < ifc->ifc_minifs; unit++) { - err =3D (*ifc->ifc_create)(ifc, unit); - KASSERT(err =3D=3D 0, - ("%s: failed to create required interface %s%d", - __func__, ifc->ifc_name, unit)); - - /* Allocate the unit in the bitmap. */ - bytoff =3D unit >> 3; - bitoff =3D unit - (bytoff << 3); - ifc->ifc_units[bytoff] |=3D (1 << bitoff); - } - EVENTHANDLER_INVOKE(if_clone_event, ifc); -} - -/* - * Unregister a network interface cloner. - */ -void -if_clone_detach(struct if_clone *ifc) -{ - - LIST_REMOVE(ifc, ifc_list); - free(ifc->ifc_units, M_CLONE); - if_cloners_count--; -} - -/* - * Provide list of interface cloners to userspace. - */ -static int -if_clone_list(struct if_clonereq *ifcr) -{ - char outbuf[IFNAMSIZ], *dst; - struct if_clone *ifc; - int count, error =3D 0; - - ifcr->ifcr_total =3D if_cloners_count; - if ((dst =3D ifcr->ifcr_buffer) =3D=3D NULL) { - /* Just asking how many there are. */ - return (0); - } - - if (ifcr->ifcr_count < 0) - return (EINVAL); - - count =3D (if_cloners_count < ifcr->ifcr_count) ? - if_cloners_count : ifcr->ifcr_count; - - for (ifc =3D LIST_FIRST(&if_cloners); ifc !=3D NULL && count !=3D 0; - ifc =3D LIST_NEXT(ifc, ifc_list), count--, dst +=3D IFNAMSIZ) { - strlcpy(outbuf, ifc->ifc_name, IFNAMSIZ); - error =3D copyout(outbuf, dst, IFNAMSIZ); - if (error) - break; - } - - return (error); } =20 #define equal(a1, a2) (bcmp((a1), (a2), ((a1))->sa_len) =3D=3D 0) --- /dev/null Tue Apr 20 21:00:01 2004 +++ sys/net/if_clone.h Mon Apr 19 14:27:11 2004 @@ -0,0 +1,116 @@ +/* + * Copyright (c) 1982, 1986, 1989, 1993 + * The Regents of the University of California. All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * 3. All advertising materials mentioning features or use of this software + * must display the following acknowledgement: + * This product includes software developed by the University of + * California, Berkeley and its contributors. + * 4. Neither the name of the University nor the names of its contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURP= OSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENT= IAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STR= ICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY W= AY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + * From: @(#)if.h 8.1 (Berkeley) 6/10/93 + * $FreeBSD$ + */ + +#ifndef _NET_IF_CLONE_H_ +#define _NET_IF_CLONE_H_ + +#ifdef _KERNEL + +#define IFC_CLONE_INITIALIZER(name, data, maxunit, \ + attach, match, create, destroy) \ + { { 0 }, name, maxunit, NULL, 0, data, attach, match, create, destroy } + +/* + * Structure describing a `cloning' interface. + * + * List of locks + * (c) const until freeing + * (d) driver specific data, may need external protection. + * (e) locked by if_cloners_mtx + * (i) locked by ifc_mtx mtx + */ +struct if_clone { + LIST_ENTRY(if_clone) ifc_list; /* (e) On list of cloners */ + const char *ifc_name; /* (c) Name of device, e.g. `gif' */ + int ifc_maxunit; /* (c) Maximum unit number */ + unsigned char *ifc_units; /* (i) Bitmap to handle units. */ + /* Considered private, access */ + /* via ifc_(alloc|free)_unit(). */ + int ifc_bmlen; /* (c) Bitmap length. */ + void *ifc_data; /* (*) Data for ifc_* functions. */ + long ifc_refcnt; /* (i) Refrence count. */ + struct mtx ifc_mtx; /* Muted to protect members. */ + + /* (c) Driver specific cloning functions. Called with no locks held. */ + void (*ifc_attach)(struct if_clone *); + int (*ifc_match)(struct if_clone *, const char *); + int (*ifc_create)(struct if_clone *, char *, size_t); + int (*ifc_destroy)(struct if_clone *, struct ifnet *); +}; + +void if_clone_init(void); +void if_clone_attach(struct if_clone *); +void if_clone_detach(struct if_clone *); + +int if_clone_create(char *, size_t); +int if_clone_destroy(const char *); +int if_clone_list(struct if_clonereq *); + +int ifc_name2unit(const char *name, int *unit); +int ifc_alloc_unit(struct if_clone *, int *); +void ifc_free_unit(struct if_clone *, int); + +/* + * The ifc_simple functions, structures, and macros implement basic + * cloning as in 5.[012]. + */ + +struct ifc_simple_data { + int ifcs_minifs; /* minimum number of interfaces */ + + int (*ifcs_create)(struct if_clone *, int); + void (*ifcs_destroy)(struct ifnet *); +}; + +/* interface clone event */ +typedef void (*if_clone_event_handler_t)(void *, struct if_clone *); +EVENTHANDLER_DECLARE(if_clone_event, if_clone_event_handler_t); + +#define IFC_SIMPLE_DECLARE(name, minifs) \ +struct ifc_simple_data name##_cloner_data =3D \ + {minifs, name##_clone_create, name##_clone_destroy}; \ +struct if_clone name##_cloner =3D \ + IFC_CLONE_INITIALIZER(#name, &name##_cloner_data, IF_MAXUNIT, \ + ifc_simple_attach, ifc_simple_match, ifc_simple_create, ifc_simple_des= troy) + +void ifc_simple_attach(struct if_clone *); +int ifc_simple_match(struct if_clone *, const char *); +int ifc_simple_create(struct if_clone *, char *, size_t); +int ifc_simple_destroy(struct if_clone *, struct ifnet *); + +#endif /* _KERNEL */ + +#endif /* !_NET_IF_CLONE_H_ */ --- /dev/null Tue Apr 20 21:00:01 2004 +++ sys/net/if_clone.c Mon Apr 19 13:30:17 2004 @@ -0,0 +1,474 @@ +/* + * Copyright (c) 1980, 1986, 1993 + * The Regents of the University of California. All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * 3. All advertising materials mentioning features or use of this software + * must display the following acknowledgement: + * This product includes software developed by the University of + * California, Berkeley and its contributors. + * 4. Neither the name of the University nor the names of its contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURP= OSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENT= IAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STR= ICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY W= AY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + * @(#)if.c 8.5 (Berkeley) 1/9/95 + * $FreeBSD$ + */ + +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#if 0 +#include +#endif +#include +#include +#include +#include + +static void if_clone_free(struct if_clone *ifc); + +static struct mtx if_cloners_mtx; +static int if_cloners_count; +LIST_HEAD(, if_clone) if_cloners =3D LIST_HEAD_INITIALIZER(if_cloners); + +#define IF_CLONERS_LOCK_INIT() \ + mtx_init(&if_cloners_mtx, "if_cloners lock", NULL, MTX_DEF) +#define IF_CLONERS_LOCK_ASSERT() mtx_assert(&if_cloners_mtx, MA_OWNED) +#define IF_CLONERS_LOCK() mtx_lock(&if_cloners_mtx) +#define IF_CLONERS_UNLOCK() mtx_unlock(&if_cloners_mtx) + +#define IF_CLONE_LOCK_INIT(ifc) \ + mtx_init(&(ifc)->ifc_mtx, "if_clone lock", NULL, MTX_DEF) +#define IF_CLONE_LOCK_DESTROY(ifc) mtx_destroy(&(ifc)->ifc_mtx) +#define IF_CLONE_LOCK_ASSERT(ifc) mtx_assert(&(ifc)->ifc_mtx, MA_OWNED) +#define IF_CLONE_LOCK(ifc) mtx_lock(&(ifc)->ifc_mtx) +#define IF_CLONE_UNLOCK(ifc) mtx_unlock(&(ifc)->ifc_mtx) + +#define IF_CLONE_ADDREF(ifc) \ + do { \ + IF_CLONE_LOCK(ifc); \ + IF_CLONE_ADDREF_LOCKED(ifc); \ + IF_CLONE_UNLOCK(ifc); \ + } while (0) +#define IF_CLONE_ADDREF_LOCKED(ifc) \ + do { \ + IF_CLONE_LOCK_ASSERT(ifc); \ + KASSERT((ifc)->ifc_refcnt >=3D 0, \ + ("negative refcnt %ld", (ifc)->ifc_refcnt)); \ + (ifc)->ifc_refcnt++; \ + } while (0) +#define IF_CLONE_REMREF(ifc) \ + do { \ + IF_CLONE_LOCK(ifc); \ + IF_CLONE_REMREF_LOCKED(ifc); \ + } while (0) +#define IF_CLONE_REMREF_LOCKED(ifc) \ + do { \ + IF_CLONE_LOCK_ASSERT(ifc); \ + KASSERT((ifc)->ifc_refcnt > 0, \ + ("bogus refcnt %ld", (ifc)->ifc_refcnt)); \ + if (--(ifc)->ifc_refcnt =3D=3D 0) { \ + IF_CLONE_UNLOCK(ifc); \ + if_clone_free(ifc); \ + } \ + /* silently free the lock */ \ + IF_CLONE_UNLOCK(ifc); \ + } while (0) + +MALLOC_DEFINE(M_CLONE, "clone", "interface cloning framework"); + +void +if_clone_init(void) +{ + IF_CLONERS_LOCK_INIT(); +} + +/* + * Create a clone network interface. + */ +int +if_clone_create(char *name, size_t len) +{ + int err; + struct if_clone *ifc; + + if (ifunit(name) !=3D NULL) + return (EEXIST); + + /* Try to find an applicable cloner for this request */ + IF_CLONERS_LOCK(); + LIST_FOREACH(ifc, &if_cloners, ifc_list) { + if (ifc->ifc_match(ifc, name)) { + IF_CLONE_ADDREF(ifc); + break; + } + } + IF_CLONERS_UNLOCK(); + + if (ifc =3D=3D NULL) + return (EINVAL); + + err =3D (*ifc->ifc_create)(ifc, name, len); + IF_CLONE_REMREF(ifc); + return (err); +} + +/* + * Destroy a clone network interface. + */ +int +if_clone_destroy(const char *name) +{ + int err; + struct if_clone *ifc; + struct ifnet *ifp; + + ifp =3D ifunit(name); + if (ifp =3D=3D NULL) + return (ENXIO); + + /* Find the cloner for this interface */ + IF_CLONERS_LOCK(); + LIST_FOREACH(ifc, &if_cloners, ifc_list) { + if (strcmp(ifc->ifc_name, ifp->if_dname) =3D=3D 0) { + IF_CLONE_ADDREF(ifc); + break; + } + } + IF_CLONERS_UNLOCK(); + if (ifc =3D=3D NULL) + return (EINVAL); + + if (ifc->ifc_destroy =3D=3D NULL) { + err =3D EOPNOTSUPP; + goto done; + } + + err =3D (*ifc->ifc_destroy)(ifc, ifp); + +done: + IF_CLONE_REMREF(ifc); + return (err); +} + +/* + * Register a network interface cloner. + */ +void +if_clone_attach(struct if_clone *ifc) +{ + int len, maxclone; + + /* + * Compute bitmap size and allocate it. + */ + maxclone =3D ifc->ifc_maxunit + 1; + len =3D maxclone >> 3; + if ((len << 3) < maxclone) + len++; + ifc->ifc_units =3D malloc(len, M_CLONE, M_WAITOK | M_ZERO); + ifc->ifc_bmlen =3D len; + IF_CLONE_LOCK_INIT(ifc); + IF_CLONE_ADDREF(ifc); + + IF_CLONERS_LOCK(); + LIST_INSERT_HEAD(&if_cloners, ifc, ifc_list); + if_cloners_count++; + IF_CLONERS_UNLOCK(); + + if (ifc->ifc_attach !=3D NULL) + (*ifc->ifc_attach)(ifc); + EVENTHANDLER_INVOKE(if_clone_event, ifc); +} + +/* + * Unregister a network interface cloner. + */ +void +if_clone_detach(struct if_clone *ifc) +{ + + IF_CLONERS_LOCK(); + LIST_REMOVE(ifc, ifc_list); + if_cloners_count--; + IF_CLONERS_UNLOCK(); + + IF_CLONE_REMREF(ifc); +} + +static void +if_clone_free(struct if_clone *ifc) +{ + + IF_CLONE_LOCK_DESTROY(ifc); + free(ifc->ifc_units, M_CLONE); +} + +/* + * Provide list of interface cloners to userspace. + */ +int +if_clone_list(struct if_clonereq *ifcr) +{ + char outbuf[IFNAMSIZ], *dst; + struct if_clone *ifc; + int count, err =3D 0; + + IF_CLONERS_LOCK(); + + ifcr->ifcr_total =3D if_cloners_count; + if ((dst =3D ifcr->ifcr_buffer) =3D=3D NULL) { + /* Just asking how many there are. */ + goto done; + } + + if (ifcr->ifcr_count < 0) { + err =3D EINVAL; + goto done; + } + + count =3D (if_cloners_count < ifcr->ifcr_count) ? + if_cloners_count : ifcr->ifcr_count; + + for (ifc =3D LIST_FIRST(&if_cloners); ifc !=3D NULL && count !=3D 0; + ifc =3D LIST_NEXT(ifc, ifc_list), count--, dst +=3D IFNAMSIZ) { + strlcpy(outbuf, ifc->ifc_name, IFNAMSIZ); + err =3D copyout(outbuf, dst, IFNAMSIZ); + if (err) + break; + } + +done: + IF_CLONERS_UNLOCK(); + return (err); +} + +/* + * A utility function to extract unit numbers from interface names of + * the form name###. + * + * Returns 0 on success and an error on failure. + */ +int +ifc_name2unit(const char *name, int *unit) +{ + const char *cp; + + for (cp =3D name; *cp !=3D '\0' && (*cp < '0' || *cp > '9'); cp++); + if (*cp =3D=3D '\0') { + *unit =3D -1; + } else { + for (*unit =3D 0; *cp !=3D '\0'; cp++) { + if (*cp < '0' || *cp > '9') { + /* Bogus unit number. */ + return (EINVAL); + } + *unit =3D (*unit * 10) + (*cp - '0'); + } + } + + return (0); +} + +int +ifc_alloc_unit(struct if_clone *ifc, int *unit) +{ + int wildcard, bytoff, bitoff; + int err =3D 0; + + IF_CLONE_LOCK(ifc); + + bytoff =3D bitoff =3D 0; + wildcard =3D (*unit < 0); + /* + * Find a free unit if none was given. + */ + if (wildcard) { + while ((bytoff < ifc->ifc_bmlen) + && (ifc->ifc_units[bytoff] =3D=3D 0xff)) + bytoff++; + if (bytoff >=3D ifc->ifc_bmlen) { + err =3D ENOSPC; + goto done; + } + while ((ifc->ifc_units[bytoff] & (1 << bitoff)) !=3D 0) + bitoff++; + *unit =3D (bytoff << 3) + bitoff; + } + + if (*unit > ifc->ifc_maxunit) { + err =3D ENOSPC; + goto done; + } + + if (!wildcard) { + bytoff =3D *unit >> 3; + bitoff =3D *unit - (bytoff << 3); + } + + if((ifc->ifc_units[bytoff] & (1 << bitoff)) !=3D 0) { + err =3D EEXIST; + goto done; + } + /* + * Allocate the unit in the bitmap. + */ + ifc->ifc_units[bytoff] |=3D (1 << bitoff); + +done: + IF_CLONE_UNLOCK(ifc); + return (err); +} + +void +ifc_free_unit(struct if_clone *ifc, int unit) +{ + int bytoff, bitoff; + + + /* + * Compute offset in the bitmap and deallocate the unit. + */ + bytoff =3D unit >> 3; + bitoff =3D unit - (bytoff << 3); + + IF_CLONE_LOCK(ifc); + KASSERT((ifc->ifc_units[bytoff] & (1 << bitoff)) !=3D 0, + ("%s: bit is already cleared", __func__)); + ifc->ifc_units[bytoff] &=3D ~(1 << bitoff); + IF_CLONE_UNLOCK(ifc); +} + +void +ifc_simple_attach(struct if_clone *ifc) +{ + int err; + int unit; + char name[IFNAMSIZ]; + struct ifc_simple_data *ifcs =3D ifc->ifc_data; + + KASSERT(ifcs->ifcs_minifs - 1 <=3D ifc->ifc_maxunit, + ("%s: %s requested more units then allowed (%d > %d)", + __func__, ifc->ifc_name, ifcs->ifcs_minifs, + ifc->ifc_maxunit + 1)); + + for (unit =3D 0; unit < ifcs->ifcs_minifs; unit++) { + snprintf(name, IFNAMSIZ, "%s%d", ifc->ifc_name, unit); + err =3D (*ifc->ifc_create)(ifc, name, IFNAMSIZ); + KASSERT(err =3D=3D 0, + ("%s: failed to create required interface %s", + __func__, name)); + } +} + +int +ifc_simple_match(struct if_clone *ifc, const char *name) +{ + const char *cp; + int i; +=09 + IF_CLONE_LOCK_ASSERT(ifc); + + /* Match the name */ + for (cp =3D name, i =3D 0; i < strlen(ifc->ifc_name); i++, cp++) { + if (ifc->ifc_name[i] !=3D *cp) + return (0); + } + + /* Make sure there's a unit number or nothing after the name */ + for (; *cp !=3D '\0'; cp++) { + if (*cp < '0' || *cp > '9') + return (0); + } + + return (1); +} + +int +ifc_simple_create(struct if_clone *ifc, char *name, size_t len) +{ + char *dp; + int wildcard; + int unit; + int err; + struct ifc_simple_data *ifcs =3D ifc->ifc_data; + + err =3D ifc_name2unit(name, &unit); + if (err !=3D 0) + return (err); + + wildcard =3D (unit < 0); + + err =3D ifc_alloc_unit(ifc, &unit); + if (err !=3D 0) + return (err); + + err =3D ifcs->ifcs_create(ifc, unit); + if (err !=3D 0) { + ifc_free_unit(ifc, unit); + return (err); + } + + /* In the wildcard case, we need to update the name. */ + if (wildcard) { + for (dp =3D name; *dp !=3D '\0'; dp++); + if (snprintf(dp, len - (dp-name), "%d", unit) > + len - (dp-name) - 1) { + /* + * This can only be a programmer error and + * there's no straightforward way to recover if + * it happens. + */ + panic("if_clone_create(): interface name too long"); + } + + } + + return (0); +} + +int +ifc_simple_destroy(struct if_clone *ifc, struct ifnet *ifp) +{ + int unit; + struct ifc_simple_data *ifcs =3D ifc->ifc_data; + + unit =3D ifp->if_dunit; + + if (unit < ifcs->ifcs_minifs)=20 + return (EINVAL); + + ifcs->ifcs_destroy(ifp); + + ifc_free_unit(ifc, unit); + + return (0); +} --- ../cleanup/sys/net/if_disc.c Fri Apr 9 13:38:47 2004 +++ sys/net/if_disc.c Mon Apr 19 13:00:37 2004 @@ -45,6 +45,7 @@ #include =20 #include +#include #include #include #include @@ -75,8 +76,8 @@ static struct mtx disc_mtx; static MALLOC_DEFINE(M_DISC, DISCNAME, "Discard interface"); static LIST_HEAD(, disc_softc) disc_softc_list; -static struct if_clone disc_cloner =3D IF_CLONE_INITIALIZER(DISCNAME, - disc_clone_create, disc_clone_destroy, 0, IF_MAXUNIT); + +IFC_SIMPLE_DECLARE(disc, 0); =20 static int disc_clone_create(struct if_clone *ifc, int unit) --- ../cleanup/sys/net/if_faith.c Tue Apr 13 18:44:01 2004 +++ sys/net/if_faith.c Mon Apr 19 13:00:37 2004 @@ -55,6 +55,7 @@ #include =20 #include +#include #include #include #include @@ -103,8 +104,7 @@ static void faith_clone_destroy(struct ifnet *); static void faith_destroy(struct faith_softc *); =20 -struct if_clone faith_cloner =3D IF_CLONE_INITIALIZER(FAITHNAME, - faith_clone_create, faith_clone_destroy, 0, IF_MAXUNIT); +IFC_SIMPLE_DECLARE(faith, 0); =20 #define FAITHMTU 1500 =20 --- ../cleanup/sys/net/if_gif.c Tue Apr 13 18:44:01 2004 +++ sys/net/if_gif.c Mon Apr 19 13:00:37 2004 @@ -51,6 +51,7 @@ #include =20 #include +#include #include #include #include @@ -99,8 +100,7 @@ static int gif_clone_create(struct if_clone *, int); static void gif_clone_destroy(struct ifnet *); =20 -struct if_clone gif_cloner =3D IF_CLONE_INITIALIZER("gif", - gif_clone_create, gif_clone_destroy, 0, IF_MAXUNIT); +IFC_SIMPLE_DECLARE(gif, 0); =20 static int gifmodevent(module_t, int, void *); =20 --- ../cleanup/sys/net/if_gre.c Tue Mar 23 15:48:13 2004 +++ sys/net/if_gre.c Mon Apr 19 13:00:37 2004 @@ -62,6 +62,7 @@ =20 #include #include +#include #include #include =20 @@ -106,8 +107,7 @@ static int gre_output(struct ifnet *, struct mbuf *, struct sockaddr *, struct rtentry *rt); =20 -static struct if_clone gre_cloner =3D - IF_CLONE_INITIALIZER("gre", gre_clone_create, gre_clone_destroy, 0, IF= _MAXUNIT); +IFC_SIMPLE_DECLARE(gre, 0); =20 static int gre_compute_route(struct gre_softc *sc); =20 --- ../cleanup/sys/net/if_loop.c Tue Apr 13 18:44:01 2004 +++ sys/net/if_loop.c Mon Apr 19 13:00:37 2004 @@ -54,6 +54,7 @@ #include =20 #include +#include #include #include #include @@ -112,8 +113,7 @@ static struct mtx lo_mtx; static LIST_HEAD(lo_list, lo_softc) lo_list; =20 -struct if_clone lo_cloner =3D IF_CLONE_INITIALIZER(LONAME, - lo_clone_create, lo_clone_destroy, 1, IF_MAXUNIT); +IFC_SIMPLE_DECLARE(lo, 1); =20 static void lo_clone_destroy(ifp) --- ../cleanup/sys/net/if_ppp.c Sun Apr 18 22:18:25 2004 +++ sys/net/if_ppp.c Mon Apr 19 13:00:37 2004 @@ -97,6 +97,7 @@ #include =20 #include +#include #include #include #include @@ -157,8 +158,7 @@ static int ppp_clone_create(struct if_clone *, int); static void ppp_clone_destroy(struct ifnet *); =20 -static struct if_clone ppp_cloner =3D IF_CLONE_INITIALIZER(PPPNAME, - ppp_clone_create, ppp_clone_destroy, 0, IF_MAXUNIT); +IFC_SIMPLE_DECLARE(ppp, 0); =20 /* * Some useful mbuf macros not in mbuf.h. --- ../cleanup/sys/net/if_stf.c Sun Apr 18 22:18:25 2004 +++ sys/net/if_stf.c Sun Apr 18 22:19:33 2004 @@ -93,6 +93,7 @@ #include =20 #include +#include #include #include #include @@ -118,6 +119,7 @@ #include =20 #define STFNAME "stf" +#define STFUNIT 0 =20 #define IN6_IS_ADDR_6TO4(x) (ntohs((x)->s6_addr16[0]) =3D=3D 0x2002) =20 @@ -159,6 +161,8 @@ &rip_usrreqs }; =20 +static char *stfnames[] =3D {"stf0", "stf", "6to4", NULL}; + static int stfmodevent(module_t, int, void *); static int stf_encapcheck(const struct mbuf *, int, int, void *); static struct in6_ifaddr *stf_getsrcifa6(struct ifnet *); @@ -172,30 +176,58 @@ static void stf_rtrequest(int, struct rtentry *, struct rt_addrinfo *); static int stf_ioctl(struct ifnet *, u_long, caddr_t); =20 -static int stf_clone_create(struct if_clone *, int); -static void stf_clone_destroy(struct ifnet *); +static int stf_clone_match(struct if_clone *, const char *); +static int stf_clone_create(struct if_clone *, char *, size_t); +static int stf_clone_destroy(struct if_clone *, struct ifnet *); +struct if_clone stf_cloner =3D IFC_CLONE_INITIALIZER(STFNAME, NULL, 0, + NULL, stf_clone_match, stf_clone_create, stf_clone_destroy); + +static int +stf_clone_match(struct if_clone *ifc, const char *name) +{ + int i; =20 -/* only one clone is currently allowed */ -struct if_clone stf_cloner =3D - IF_CLONE_INITIALIZER(STFNAME, stf_clone_create, stf_clone_destroy, 0, = 0); + for(i =3D 0; stfnames[i] !=3D NULL; i++) { + if (strcmp(stfnames[i], name) =3D=3D 0) + return (1); + } + + return (0); +} =20 static int -stf_clone_create(ifc, unit) - struct if_clone *ifc; - int unit; +stf_clone_create(struct if_clone *ifc, char *name, size_t len) { + int err, unit; struct stf_softc *sc; struct ifnet *ifp; =20 + /* + * We can only have one unit, but since unit allocation is + * already locked, we use it to keep from allocating extra + * interfaces. + */ + unit =3D STFUNIT; + err =3D ifc_alloc_unit(ifc, &unit); + if (err !=3D 0) + return (err); + sc =3D malloc(sizeof(struct stf_softc), M_STF, M_WAITOK | M_ZERO); ifp =3D &sc->sc_if; - if_initname(ifp, ifc->ifc_name, unit); + /* + * Set the name manually rather then using if_initname because + * we don't conform to the default naming convention for interfaces. + */ + strlcpy(ifp->if_xname, name, IFNAMSIZ); + ifp->if_dname =3D ifc->ifc_name; + ifp->if_dunit =3D IF_DUNIT_NONE; =20 sc->encap_cookie =3D encap_attach_func(AF_INET, IPPROTO_IPV6, stf_encapcheck, &in_stf_protosw, sc); if (sc->encap_cookie =3D=3D NULL) { if_printf(ifp, "attach failed\n"); free(sc, M_STF); + ifc_free_unit(ifc, unit); return (ENOMEM); } =20 @@ -225,9 +257,8 @@ free(sc, M_STF); } =20 -static void -stf_clone_destroy(ifp) - struct ifnet *ifp; +static int +stf_clone_destroy(struct if_clone *ifc, struct ifnet *ifp) { struct stf_softc *sc =3D (void *) ifp; =20 @@ -236,6 +267,9 @@ mtx_unlock(&stf_mtx); =20 stf_destroy(sc); + ifc_free_unit(ifc, STFUNIT); + + return (0); } =20 static int --- ../cleanup/sys/net/if_vlan.c Fri Jan 23 10:08:55 2004 +++ sys/net/if_vlan.c Tue Apr 13 18:27:20 2004 @@ -57,6 +57,7 @@ #include #include #include +#include #include #include #include @@ -116,8 +117,6 @@ #define VLAN_LOCK() mtx_lock(&ifv_mtx) #define VLAN_UNLOCK() mtx_unlock(&ifv_mtx) =20 -static int vlan_clone_create(struct if_clone *, int); -static void vlan_clone_destroy(struct ifnet *); static void vlan_start(struct ifnet *ifp); static void vlan_ifinit(void *foo); static void vlan_input(struct ifnet *ifp, struct mbuf *m); @@ -125,9 +124,16 @@ static int vlan_setmulti(struct ifnet *ifp); static int vlan_unconfig(struct ifnet *ifp); static int vlan_config(struct ifvlan *ifv, struct ifnet *p); +static int vlan_set_promisc(struct ifnet *ifp); =20 -struct if_clone vlan_cloner =3D IF_CLONE_INITIALIZER(VLANNAME, - vlan_clone_create, vlan_clone_destroy, 0, IF_MAXUNIT); +static struct ifnet *vlan_clone_match_ethertag(struct if_clone *, + const char *, int *); +static int vlan_clone_match(struct if_clone *, const char *); +static int vlan_clone_create(struct if_clone *, char *, size_t); +static int vlan_clone_destroy(struct if_clone *, struct ifnet *); + +struct if_clone vlan_cloner =3D IFC_CLONE_INITIALIZER(VLANNAME, NULL, IF_M= AXUNIT, + NULL, vlan_clone_match, vlan_clone_create, vlan_clone_destroy); =20 /* * Program our multicast filter. What we're actually doing is @@ -224,7 +230,8 @@ if_clone_detach(&vlan_cloner); vlan_input_p =3D NULL; while (!LIST_EMPTY(&ifv_list)) - vlan_clone_destroy(&LIST_FIRST(&ifv_list)->ifv_if); + vlan_clone_destroy(&vlan_cloner, + &LIST_FIRST(&ifv_list)->ifv_if); VLAN_LOCK_DESTROY(); break; }=20 @@ -239,18 +246,117 @@ =20 DECLARE_MODULE(if_vlan, vlan_mod, SI_SUB_PSEUDO, SI_ORDER_ANY); =20 +static struct ifnet * +vlan_clone_match_ethertag(struct if_clone *ifc, const char *name, int *tag) +{ + int t; + const char *cp; + struct ifnet *ifp; + + t =3D 0; + + /* Check for . style interface names. */ + IFNET_RLOCK(); + TAILQ_FOREACH(ifp, &ifnet, if_link) { + if (ifp->if_type !=3D IFT_ETHER) + continue; + if (strncmp(ifp->if_xname, name, strlen(ifp->if_xname)) !=3D 0) + continue; + cp =3D name + strlen(ifp->if_xname); + if (*cp !=3D '.') + continue; + for(; *cp !=3D '\0'; cp++) { + if (*cp < '0' || *cp > '9') + continue; + t =3D (t * 10) + (*cp - '0'); + } + if (tag !=3D NULL) + *tag =3D t; + break; + } + IFNET_RUNLOCK(); + + return ifp; +} + +static int +vlan_clone_match(struct if_clone *ifc, const char *name) +{ + const char *cp; + + if (vlan_clone_match_ethertag(ifc, name, NULL) !=3D NULL) + return (1); + + if (strncmp(VLANNAME, name, strlen(VLANNAME)) !=3D 0) + return (0); + for (cp =3D name + 4; *cp !=3D '\0'; cp++) { + if (*cp < '0' || *cp > '9') + return (0); + } + + return (1); +} + static int -vlan_clone_create(struct if_clone *ifc, int unit) +vlan_clone_create(struct if_clone *ifc, char *name, size_t len) { + char *dp; + int wildcard; + int unit; + int error; + int tag; + int ethertag; struct ifvlan *ifv; struct ifnet *ifp; + struct ifnet *p; + + if ((p =3D vlan_clone_match_ethertag(ifc, name, &tag)) !=3D NULL) { + ethertag =3D 1; + unit =3D -1; + wildcard =3D 0; + + /* + * Don't let the caller set up a VLAN tag with + * anything except VLID bits. + */ + if (tag & ~EVL_VLID_MASK) { + return (EINVAL); + } + } else { + ethertag =3D 0; + + error =3D ifc_name2unit(name, &unit); + if (error !=3D 0) + return (error); + + wildcard =3D (unit < 0); + } + + error =3D ifc_alloc_unit(ifc, &unit); + if (error !=3D 0) + return (error); + + /* In the wildcard case, we need to update the name. */ + if (wildcard) { + for (dp =3D name; *dp !=3D '\0'; dp++); + if (snprintf(dp, len - (dp-name), "%d", unit) > + len - (dp-name) - 1) { + panic("%s: interface name too long", __func__); + } + } =20 ifv =3D malloc(sizeof(struct ifvlan), M_VLAN, M_WAITOK | M_ZERO); ifp =3D &ifv->ifv_if; SLIST_INIT(&ifv->vlan_mc_listhead); =20 ifp->if_softc =3D ifv; - if_initname(ifp, ifc->ifc_name, unit); + /* + * Set the name manually rather then using if_initname because + * we don't conform to the default naming convention for interfaces. + */ + strlcpy(ifp->if_xname, name, IFNAMSIZ); + ifp->if_dname =3D ifc->ifc_name; + ifp->if_dunit =3D unit; /* NB: flags are not set here */ ifp->if_linkmib =3D &ifv->ifv_mib; ifp->if_linkmiblen =3D sizeof ifv->ifv_mib; @@ -270,11 +376,36 @@ LIST_INSERT_HEAD(&ifv_list, ifv, ifv_list); VLAN_UNLOCK(); =20 + if (ethertag) { + VLAN_LOCK(); + error =3D vlan_config(ifv, p); + if (error !=3D 0) { + /* + * Since we've partialy failed, we need to back + * out all the way, otherwise userland could get + * confused. Thus, we destroy the interface. + */ + LIST_REMOVE(ifv, ifv_list); + vlan_unconfig(ifp); + VLAN_UNLOCK(); + ether_ifdetach(ifp); + free(ifv, M_VLAN); + + return (error); + } + ifv->ifv_tag =3D tag; + ifp->if_flags |=3D IFF_RUNNING; + VLAN_UNLOCK(); + + /* Update promiscuous mode, if necessary. */ + vlan_set_promisc(ifp); + } + return (0); } =20 -static void -vlan_clone_destroy(struct ifnet *ifp) +static int +vlan_clone_destroy(struct if_clone *ifc, struct ifnet *ifp) { struct ifvlan *ifv =3D ifp->if_softc; =20 @@ -286,6 +417,8 @@ ether_ifdetach(ifp); =20 free(ifv, M_VLAN); + + return (0); } =20 static void --- ../cleanup/sys/contrib/pf/net/if_pflog.c Tue Apr 13 18:44:01 2004 +++ sys/contrib/pf/net/if_pflog.c Mon Apr 19 13:00:37 2004 @@ -62,6 +62,9 @@ #endif =20 #include +#if defined(__FreeBSD__) +#include +#endif #include #include #include @@ -122,8 +125,7 @@ #ifdef __FreeBSD__ static MALLOC_DEFINE(M_PFLOG, PFLOGNAME, "Packet Filter Logging Interface"= ); static LIST_HEAD(pflog_list, pflog_softc) pflog_list; -struct if_clone pflog_cloner =3D IF_CLONE_INITIALIZER(PFLOGNAME, - pflog_clone_create, pflog_clone_destroy, 1, IF_MAXUNIT); +IFC_SIMPLE_DECLARE(pflog, 1); =20 static void pflog_clone_destroy(struct ifnet *ifp) --- ../cleanup/sys/contrib/pf/net/if_pfsync.c Tue Apr 13 18:44:01 2004 +++ sys/contrib/pf/net/if_pfsync.c Mon Apr 19 13:00:37 2004 @@ -57,6 +57,9 @@ #endif =20 #include +#if defined(__FreeBSD__) +#include +#endif #include #include #include @@ -117,8 +120,7 @@ #ifdef __FreeBSD__ static MALLOC_DEFINE(M_PFSYNC, PFSYNCNAME, "Packet Filter State Sync. Inte= rface"); static LIST_HEAD(pfsync_list, pfsync_softc) pfsync_list; -struct if_clone pfsync_cloner =3D IF_CLONE_INITIALIZER(PFSYNCNAME, - pfsync_clone_create, pfsync_clone_destroy, 1, IF_MAXUNIT); +IFC_SIMPLE_DECLARE(pfsync, 1); =20 static void pfsync_clone_destroy(struct ifnet *ifp) --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --opJtzjQTFsWo+cga Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFAhfeUXY6L6fI4GtQRAkcpAJ41Nm5lHIdtnuMhefv2sYs+z4814QCgz6up VfL/NGiVaXjDe+44jrSzrMY= =UEwl -----END PGP SIGNATURE----- --opJtzjQTFsWo+cga-- From owner-freebsd-net@FreeBSD.ORG Tue Apr 20 23:26:06 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2958E16A4CE; Tue, 20 Apr 2004 23:26:06 -0700 (PDT) Received: from rms04.rommon.net (rms04.rommon.net [212.54.2.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0059943D31; Tue, 20 Apr 2004 23:26:04 -0700 (PDT) (envelope-from pete@he.iki.fi) Received: from he.iki.fi (h91.vuokselantie10.fi [193.64.42.145]) by rms04.rommon.net (8.12.10/8.12.9) with ESMTP id i3L6Q4mo073138; Wed, 21 Apr 2004 09:26:05 +0300 (EEST) (envelope-from pete@he.iki.fi) Message-ID: <408613F7.1090806@he.iki.fi> Date: Wed, 21 Apr 2004 09:25:59 +0300 From: Petri Helenius User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Luigi Rizzo References: <20040419110912.A71274@xorpc.icir.org> In-Reply-To: <20040419110912.A71274@xorpc.icir.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: net@freebsd.org Subject: Re: what is the story on if_index allocation ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2004 06:26:06 -0000 Luigi Rizzo wrote: >Can someone explain what is the goal ? Reuse a number if an >interface has the same name of a previously existing one and >the index is free ? And does it make sense, anyways, or >we could just simplify that code and just reuse the first >available entry in ifindex_table[] ? > > The optimal course of action (from management software point of view) is to retain as static ifName to ifIndex mapping. If the index changes for the same interface, you're supposed to have lower sysUpTime than on previous query. Pete From owner-freebsd-net@FreeBSD.ORG Tue Apr 20 23:38:19 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 06F8316A4CE for ; Tue, 20 Apr 2004 23:38:19 -0700 (PDT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id C054D43D2F for ; Tue, 20 Apr 2004 23:38:18 -0700 (PDT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.9p1/8.12.8) with ESMTP id i3L6cIgd047011; Tue, 20 Apr 2004 23:38:18 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.9p1/8.12.3/Submit) id i3L6cIjG047010; Tue, 20 Apr 2004 23:38:18 -0700 (PDT) (envelope-from rizzo) Date: Tue, 20 Apr 2004 23:38:18 -0700 From: Luigi Rizzo To: Petri Helenius Message-ID: <20040420233818.B43347@xorpc.icir.org> References: <20040419110912.A71274@xorpc.icir.org> <408613F7.1090806@he.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <408613F7.1090806@he.iki.fi>; from pete@he.iki.fi on Wed, Apr 21, 2004 at 09:25:59AM +0300 cc: net@freebsd.org Subject: Re: what is the story on if_index allocation ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2004 06:38:19 -0000 On Wed, Apr 21, 2004 at 09:25:59AM +0300, Petri Helenius wrote: > Luigi Rizzo wrote: > > >Can someone explain what is the goal ? Reuse a number if an > >interface has the same name of a previously existing one and > >the index is free ? And does it make sense, anyways, or > >we could just simplify that code and just reuse the first > >available entry in ifindex_table[] ? > > > > > The optimal course of action (from management software point of view) is > to retain as static ifName to ifIndex mapping. If the index changes for I do not think the current code supports this, as any free index at the top of the array is reused. So if you had 'vlan12' there and it went away, the next interface that comes in will grab that index and vlan12 will get a new one. On top of this you can rename interfaces without changing the index, you can change MAC and IP addresses, in the already mentioned case of a tunnel server there is basically no relation between successive creations on the same interface. My feeling is that there is not even a sensible way to specify how one would like to retain the mapping of indexes, let alone the fact that the specification changes depending on whom you ask. When this happens, it is a good hint to move the issue outside the kernel. cheers luigi From owner-freebsd-net@FreeBSD.ORG Tue Apr 20 23:53:42 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6C5E916A4CE for ; Tue, 20 Apr 2004 23:53:42 -0700 (PDT) Received: from rms04.rommon.net (rms04.rommon.net [212.54.2.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id A733D43D31 for ; Tue, 20 Apr 2004 23:53:41 -0700 (PDT) (envelope-from pete@he.iki.fi) Received: from he.iki.fi (h91.vuokselantie10.fi [193.64.42.145]) by rms04.rommon.net (8.12.10/8.12.9) with ESMTP id i3L6rgmo073202; Wed, 21 Apr 2004 09:53:42 +0300 (EEST) (envelope-from pete@he.iki.fi) Message-ID: <40861A71.1020502@he.iki.fi> Date: Wed, 21 Apr 2004 09:53:37 +0300 From: Petri Helenius User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Luigi Rizzo References: <20040419110912.A71274@xorpc.icir.org> <408613F7.1090806@he.iki.fi> <20040420233818.B43347@xorpc.icir.org> In-Reply-To: <20040420233818.B43347@xorpc.icir.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: net@freebsd.org Subject: Re: what is the story on if_index allocation ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2004 06:53:42 -0000 Luigi Rizzo wrote: > >I do not think the current code supports this, as any free >index at the top of the array is reused. So if you had 'vlan12' there >and it went away, the next interface that comes in will grab that >index and vlan12 will get a new one. On top of this you can rename >interfaces without changing the index, you can change MAC and IP >addresses, in the already mentioned case of a tunnel server >there is basically no relation between successive creations on >the same interface. > >My feeling is that there is not even a sensible way to specify >how one would like to retain the mapping of indexes, let alone >the fact that the specification changes depending on whom you >ask. When this happens, it is a good hint to move the issue >outside the kernel. > > > Relevant quote from the RFC: The requirement for constancy (between re-initializations) of an interface's ifIndex value is met by requiring that after an interface is dynamically removed, its ifIndex value is not re-used by a *different* dynamically added interface until after the following re-initialization of the network management system. This avoids the need for assignment (in advance) of ifIndex values for all possible interfaces that might be added dynamically. The exact meaning of a "different" interface is hard to define, and there will be gray areas. Any firm definition in this document would likely turn out to be inadequate. Instead, implementors must choose what it means in their particular situation, subject to the following rules: McCloghrie & Kastenholz Standards Track [Page 11] ^L RFC 2863 The Interfaces Group MIB June 2000 (1) a previously-unused value of ifIndex must be assigned to a dynamically added interface if an agent has no knowledge of whether the interface is the "same" or "different" to a previously incarnated interface. (2) a management station, not noticing that an interface has gone away and another has come into existence, must not be confused when calculating the difference between the counter values retrieved on successive polls for a particular ifIndex value. When the new interface is the same as an old interface, but a discontinuity in the value of the interface's counters cannot be avoided, the ifTable has (until now) required that a new ifIndex value be assigned to the returning interface. That is, either all counter values have had to be retained during the absence of an interface in order to use the same ifIndex value on that interface's return, or else a new ifIndex value has had to be assigned to the returning interface. Both alternatives have proved to be burdensome to some implementations: (1) maintaining the counter values may not be possible (e.g., if they are maintained on removable hardware), (2) using a new ifIndex value presents extra work for management applications. While the potential need for such extra work is unavoidable on agent re-initializations, it is desirable to avoid it between re-initializations. Pete From owner-freebsd-net@FreeBSD.ORG Tue Apr 20 23:58:58 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 98EBC16A4CE for ; Tue, 20 Apr 2004 23:58:58 -0700 (PDT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8528243D5E for ; Tue, 20 Apr 2004 23:58:58 -0700 (PDT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.9p1/8.12.8) with ESMTP id i3L6wwgd049269; Tue, 20 Apr 2004 23:58:58 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.9p1/8.12.3/Submit) id i3L6wwQt049268; Tue, 20 Apr 2004 23:58:58 -0700 (PDT) (envelope-from rizzo) Date: Tue, 20 Apr 2004 23:58:58 -0700 From: Luigi Rizzo To: Petri Helenius Message-ID: <20040420235858.B47612@xorpc.icir.org> References: <20040419110912.A71274@xorpc.icir.org> <408613F7.1090806@he.iki.fi> <20040420233818.B43347@xorpc.icir.org> <40861A71.1020502@he.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <40861A71.1020502@he.iki.fi>; from pete@he.iki.fi on Wed, Apr 21, 2004 at 09:53:37AM +0300 cc: net@freebsd.org Subject: Re: what is the story on if_index allocation ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2004 06:58:58 -0000 On Wed, Apr 21, 2004 at 09:53:37AM +0300, Petri Helenius wrote: ... > Relevant quote from the RFC: a very appropriate one indeed, which seems to substantiate my point. > interfaces that might be added dynamically. The exact meaning of a > "different" interface is hard to define, and there will be gray > areas. Any firm definition in this document would likely turn out to > be inadequate. Instead, implementors must choose what it means in > their particular situation, subject to the following rules: so if there are gray areas in defining 'different' the same applies to defining 'same' :) cheers luigi From owner-freebsd-net@FreeBSD.ORG Wed Apr 21 00:13:44 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CE4B016A4CE for ; Wed, 21 Apr 2004 00:13:44 -0700 (PDT) Received: from home.bluegrass.sk (home.bluegrass.sk [195.168.129.26]) by mx1.FreeBSD.org (Postfix) with SMTP id EF9A943D5C for ; Wed, 21 Apr 2004 00:13:42 -0700 (PDT) (envelope-from milan.obuch@bluegrass.sk) Received: (qmail 35203 invoked from network); 21 Apr 2004 07:13:41 -0000 Received: from tmp.bluegrass.sk (HELO localhost.invalid) (195.168.129.28) by bsd.bluegrass.sk with SMTP; 21 Apr 2004 07:13:41 -0000 From: Milan Obuch To: freebsd-net@freebsd.org Date: Wed, 21 Apr 2004 09:13:40 +0200 User-Agent: KMail/1.6 References: <20040419110912.A71274@xorpc.icir.org> <40861A71.1020502@he.iki.fi> <20040420235858.B47612@xorpc.icir.org> In-Reply-To: <20040420235858.B47612@xorpc.icir.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200404210913.40513.milan.obuch@bluegrass.sk> Subject: Re: what is the story on if_index allocation ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2004 07:13:44 -0000 On Wednesday 21 April 2004 08:58, Luigi Rizzo wrote: > On Wed, Apr 21, 2004 at 09:53:37AM +0300, Petri Helenius wrote: > ... > > > Relevant quote from the RFC: > > a very appropriate one indeed, which seems to substantiate my point. > > > interfaces that might be added dynamically. The exact meaning of a > > "different" interface is hard to define, and there will be gray > > areas. Any firm definition in this document would likely turn out to > > be inadequate. Instead, implementors must choose what it means in > > their particular situation, subject to the following rules: > > so if there are gray areas in defining 'different' the same applies > to defining 'same' :) > > cheers > luigi > I would say the easiest way is to take any new interface as 'different' in relation to any once existed but deleted in past interface and let the management station define what does it mean to be 'the same' interface. We would have sparsely allocated ifindex values after some interface creation/deletion, which is not a big issue to me. I would not think there is one-to-one mapping even for one network management solution, it depends on actual needs. Regards, Milan From owner-freebsd-net@FreeBSD.ORG Wed Apr 21 02:47:55 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D8AFA16A4CE for ; Wed, 21 Apr 2004 02:47:55 -0700 (PDT) Received: from mail.cs.tu-berlin.de (mail.cs.tu-berlin.de [130.149.17.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1992643D1F for ; Wed, 21 Apr 2004 02:47:55 -0700 (PDT) (envelope-from novo@cs.tu-berlin.de) Received: from 130-149-145-64.dialup.cs.tu-berlin.de (130-149-145-64.dialup.cs.tu-berlin.de [130.149.145.64]) by mail.cs.tu-berlin.de (8.9.3p2/8.9.3) with ESMTP id LAA18751; Wed, 21 Apr 2004 11:45:01 +0200 (MET DST) Date: Wed, 21 Apr 2004 11:45:36 +0200 (CEST) From: Harti Brandt X-X-Sender: novo@130-149-145-64.dialup.cs.tu-berlin.de To: Petri Helenius In-Reply-To: <408613F7.1090806@he.iki.fi> Message-ID: <20040421114416.F640@130-149-145-64.dialup.cs.tu-berlin.de> References: <20040419110912.A71274@xorpc.icir.org> <408613F7.1090806@he.iki.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Luigi Rizzo cc: net@FreeBSD.ORG Subject: Re: what is the story on if_index allocation ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: harti@FreeBSD.ORG List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2004 09:47:56 -0000 On Wed, 21 Apr 2004, Petri Helenius wrote: > Luigi Rizzo wrote: > > >Can someone explain what is the goal ? Reuse a number if an > >interface has the same name of a previously existing one and > >the index is free ? And does it make sense, anyways, or > >we could just simplify that code and just reuse the first > >available entry in ifindex_table[] ? > > > > > The optimal course of action (from management software point of view) is > to retain as static ifName to ifIndex mapping. If the index changes for > the same interface, you're supposed to have lower sysUpTime than on > previous query. That mapping certainly has problems with interface renaming. Currently there is no way of getting at the driver's name of the interface. harti From owner-freebsd-net@FreeBSD.ORG Wed Apr 21 03:58:50 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3A67516A4CE for ; Wed, 21 Apr 2004 03:58:50 -0700 (PDT) Received: from wdscexbhcl01.sc.wdc.com (wdscexbhcl01.sc.wdc.com [129.253.202.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0E28443D5F for ; Wed, 21 Apr 2004 03:58:50 -0700 (PDT) (envelope-from leong.khah.loon@wdc.com) Received: from wdmyexch02.my.asia.wdc.com ([129.253.105.23]) by wdscexbhcl01.sc.wdc.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 21 Apr 2004 03:58:49 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 21 Apr 2004 18:58:36 +0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PPP+freeRadius problem. Thread-Index: AcQnkAjovqo+ciNhTL6bq+yVPO36cQ== From: "Leong Khah Loon" To: X-OriginalArrivalTime: 21 Apr 2004 10:58:49.0755 (UTC) FILETIME=[A05E2EB0:01C4278F] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.1 cc: Khah_loon@hotmail.com Subject: PPP+freeRadius problem. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2004 10:58:50 -0000 Hi, My problem is the radius server only auth 1 user. In the user file user1 Auth-Type :=3D Local, User-Password =3D=3D "user1" Service-Type =3D Framed-User, Framed-Protocol =3D PPP, Framed-IP-Address =3D 192.168.61.110, Framed-IP-Netmask =3D 255.255.255.0, Framed-Routing =3D Broadcast-Listen, Framed-Filter-Id =3D "std.ppp", Framed-MTU =3D 1500, Framed-Compression =3D Van-Jacobsen-TCP-IP user2 Auth-Type :=3D Local, User-Password =3D=3D "user2" Service-Type =3D Framed-User, Framed-Protocol =3D PPP, Framed-IP-Address =3D 192.168.61.111, Framed-IP-Netmask =3D 255.255.255.0, Framed-Routing =3D Broadcast-Listen, Framed-Filter-Id =3D "std.ppp", Framed-MTU =3D 1500, Framed-Compression =3D Van-Jacobsen-TCP-IP When I login as user1 only is work find and I get all the Framed-IP at = the user Computer my problem is when user1 is login to the server and user2 login. the = radius server seem like running find but the user2 computer didn't get the framed-IP while running the radius in debug mode it show all the framed-IP on the screen and waiting for next request but the user2 didn't get reply. Logout user1 the login user2 it work find. Need your help Khah Loon Western Digital From owner-freebsd-net@FreeBSD.ORG Wed Apr 21 08:10:53 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E828A16A4CE for ; Wed, 21 Apr 2004 08:10:53 -0700 (PDT) Received: from kogut3.o2.pl (kogut3.go2.pl [212.126.20.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id C414643D41 for ; Wed, 21 Apr 2004 08:10:52 -0700 (PDT) (envelope-from knockefreebsd@o2.pl) Received: from ALFA (rekin7.go2.pl [212.126.20.19]) by kogut3.o2.pl (Postfix) with ESMTP id 6AF1877EBA for ; Wed, 21 Apr 2004 17:10:49 +0200 (CEST) Message-ID: <004301c427b2$d4fa6c60$df5561d9@ALFA> From: "Heinz Knocke" To: Date: Wed, 21 Apr 2004 17:10:47 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: How do turn on TCPDEBUG in CURRENT?? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2004 15:10:54 -0000 Hi! I asked the same questions once - but no one replied so I try once again = - I've experienced problem with TCPDEBUG kernel compilation option - it = doesn't work under 5.2 - C even thou the kernel is 200% TCPDEBUG = compiled. The system is quite special - is't a small kernel with a = little of modules for the diskless bootstrap/=20 So my qestions are: - is there a sysctl option that needs to be turned on for tracking? - is the TCP debuging some module depended, that may not be included in = the compilation I have.=20 I'm tracking system sources parallelly (which is quite difficult since = I'm quite new in kernel debug) so if there's anything somebody could = help me with - I'll be more than gratefull.=20 hk From owner-freebsd-net@FreeBSD.ORG Wed Apr 21 09:37:00 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BC8B816A4CE for ; Wed, 21 Apr 2004 09:37:00 -0700 (PDT) Received: from caliban.dreamscope.com (mail.dreamscope.com [69.55.225.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9AD7F43D54 for ; Wed, 21 Apr 2004 09:37:00 -0700 (PDT) (envelope-from chance@dreamscope.com) Received: by caliban.dreamscope.com (Postfix, from userid 1001) id 2486D4CDD2; Wed, 21 Apr 2004 09:36:46 -0700 (PDT) Date: Wed, 21 Apr 2004 09:36:45 -0700 (PDT) From: Chance Whaley To: freebsd-net@freebsd.org Message-ID: <20040421092402.B16278@caliban.dreamscope.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Opinions on "best" NIC for high-touch applications X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2004 16:37:00 -0000 All, I have an application where I am doing quite a bit of high-touch packet fiddling and I am looking for opinions on which "standard" Gb NIC has the best driver support in 5.2 or CURRENT. In my dream world I am looking for something that supports: - IRQ mitigation / polling (absolute must) - PCI-X (absolute must) - HW checksumming - Scatter / Gather - IPsec - Jumbo frames - VLANs Thoughts?? .chance From owner-freebsd-net@FreeBSD.ORG Wed Apr 21 11:34:52 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3011E16A4CE for ; Wed, 21 Apr 2004 11:34:52 -0700 (PDT) Received: from jchurch.neville-neil.com (jchurch.neville-neil.com [209.157.133.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0AA5843D54 for ; Wed, 21 Apr 2004 11:34:50 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from jchurch.neville-neil.com.neville-neil.com (localhost.neville-neil.com [127.0.0.1])i3LIaARb079815; Wed, 21 Apr 2004 11:36:10 -0700 (PDT) (envelope-from gnn@neville-neil.com) Date: Wed, 21 Apr 2004 11:36:10 -0700 Message-ID: <8765bt18md.wl@jchurch.neville-neil.com.neville-neil.com> From: "George V. Neville-Neil" To: Chance Whaley In-Reply-To: <20040421092402.B16278@caliban.dreamscope.com> References: <20040421092402.B16278@caliban.dreamscope.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3 (i386--freebsd) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII cc: net@freebsd.org Subject: Re: Opinions on "best" NIC for high-touch applications X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2004 18:34:52 -0000 At Wed, 21 Apr 2004 09:36:45 -0700 (PDT), Chance Whaley wrote: > I have an application where I am doing quite a bit of high-touch packet > fiddling and I am looking for opinions on which "standard" Gb NIC > has the best driver support in 5.2 or CURRENT. > > In my dream world I am looking for something that supports: > - IRQ mitigation / polling (absolute must) > - PCI-X (absolute must) > - HW checksumming > - Scatter / Gather > - IPsec > - Jumbo frames > - VLANs > > Thoughts?? > I think you want the Netear Copper Gigiabit Adapter (GA302T) which is well supported in 5.x. I don't know if it supports all that you want, but you should check it out at least. The driver is if_bge.c. Later, George From owner-freebsd-net@FreeBSD.ORG Wed Apr 21 22:39:20 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D897C16A4CE for ; Wed, 21 Apr 2004 22:39:20 -0700 (PDT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id B9EDF43D60 for ; Wed, 21 Apr 2004 22:39:20 -0700 (PDT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (IDENT:brdavis@localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.12.10/8.12.3) with ESMTP id i3M5dIjU020430 for ; Wed, 21 Apr 2004 22:39:18 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.10/8.12.3/Submit) id i3M5dIYg020425 for net@freebsd.org; Wed, 21 Apr 2004 22:39:18 -0700 Date: Wed, 21 Apr 2004 22:39:18 -0700 From: Brooks Davis To: net@freebsd.org Message-ID: <20040422053916.GA11221@Odin.AC.HMC.Edu> References: <20040421042453.GA8866@Odin.AC.HMC.Edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="82I3+IH0IqGh5yIs" Content-Disposition: inline In-Reply-To: <20040421042453.GA8866@Odin.AC.HMC.Edu> User-Agent: Mutt/1.5.4i Subject: Re: RFC: if_clone overhaul X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2004 05:39:21 -0000 --82I3+IH0IqGh5yIs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 20, 2004 at 09:24:53PM -0700, Brooks Davis wrote: > Please test/review the following patch to the network interface cloneing > code. This code is a major overhaul of the cloning infrastructure. Repeat after me, always test your "trivial" last minute changes. You need to apply the following patch after applying the previous patch if you want the code to compile. -- Brooks Change 51546 by brooks@brooks_minya on 2004/04/21 22:29:18 Unreorder struct if_clone so initalizer works. Should probably switch to C99 sparc initalizers.. Affected files ... =2E. //depot/user/brooks/xname/sys/net/if_clone.h#11 edit Differences ... =3D=3D=3D=3D //depot/user/brooks/xname/sys/net/if_clone.h#11 (text+ko) =3D= =3D=3D=3D @@ -61,14 +61,15 @@ /* via ifc_(alloc|free)_unit(). */ int ifc_bmlen; /* (c) Bitmap length. */ void *ifc_data; /* (*) Data for ifc_* functions. */ - long ifc_refcnt; /* (i) Refrence count. */ - struct mtx ifc_mtx; /* Muted to protect members. */ =20 /* (c) Driver specific cloning functions. Called with no locks held. */ void (*ifc_attach)(struct if_clone *); int (*ifc_match)(struct if_clone *, const char *); int (*ifc_create)(struct if_clone *, char *, size_t); int (*ifc_destroy)(struct if_clone *, struct ifnet *); + + long ifc_refcnt; /* (i) Refrence count. */ + struct mtx ifc_mtx; /* Muted to protect members. */ }; =20 void if_clone_init(void); --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --82I3+IH0IqGh5yIs Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFAh1pyXY6L6fI4GtQRApczAJ4ye4D1Srdo7YHZBVCLMFSfKhkVyACgmzA4 lwnSU8vee80r4G4cgeeW6zI= =AKIr -----END PGP SIGNATURE----- --82I3+IH0IqGh5yIs-- From owner-freebsd-net@FreeBSD.ORG Thu Apr 22 02:13:59 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CFA2216A4CE for ; Thu, 22 Apr 2004 02:13:59 -0700 (PDT) Received: from trueband.net (director.trueband.net [216.163.120.8]) by mx1.FreeBSD.org (Postfix) with SMTP id 1E96243D2D for ; Thu, 22 Apr 2004 02:13:59 -0700 (PDT) (envelope-from jhall@vandaliamo.net) Received: (qmail 13463 invoked by uid 1006); 22 Apr 2004 09:13:59 -0000 Received: from jhall@vandaliamo.net by rs0 by uid 1003 with qmail-scanner-1.16 (spamassassin: 2.44. Clear:SA:0(-4.9/100.0):. Processed in 0.91342 secs); 22 Apr 2004 09:13:59 -0000 X-Spam-Status: No, hits=-4.9 required=100.0 X-Spam-Level: Received: from unknown (HELO trueband.net) (127.0.0.1) by -v with SMTP; 22 Apr 2004 09:13:58 -0000 Received: (qmail 13430 invoked from network); 22 Apr 2004 09:13:57 -0000 Received: from unknown (HELO vandaliamo.net) (12.170.206.13) by -v with SMTP; 22 Apr 2004 09:13:57 -0000 Message-ID: <40878D56.9030300@vandaliamo.net> Date: Thu, 22 Apr 2004 04:16:06 -0500 From: Jay Hall User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Assigning a specific IP address and Interface with MPD X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2004 09:13:59 -0000 I have setup a VPN for the company I work for in which all of the remote offices connect to the Headquarters office using MPD. And this works great until I have to re-establish the connections. What I am trying to do, and maybe there is a better way, is to control what ng interface a client connects on so mpd can add routes for me based on the set iface route statement. For example in my mpd.conf configuration file on the server I have the lines pptp0: ..... new -i ng0 pptp0 pptp0 set ipcp 10.129.10.40/32 10.129.10.100/32 set iface route 10.128.10.0/24 ... pptp1: ...... new -i ng1 pptp1 pptp1 set ipcp 10.129.10.40/32 10.129.10.101/32 set iface route 10.129.10.0/24 ..... On the client side (all are identical with the exception of the first ipcp address) ........ new -i ng0 vpn vpn set ipcp 10.129.10.100/32 10.129.10.40/32 set iface route 10.129.10.0/24 ......... In mpd.secret on the server I have (usernames and passwords have been changed) user1 "user1" 10.129.10.100 user2 "user2: 10.129.10.101 I am seeing the correct IP addresses assigned as each user logs in, but they are not on the interface I would expect them to be on. Is it possible to do this? Or should I work on trying to add the routes as the interfaces come up based on the IP address they are assigned? Thanks in advance for your assistance. Jay From owner-freebsd-net@FreeBSD.ORG Thu Apr 22 02:27:25 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9043616A4CE for ; Thu, 22 Apr 2004 02:27:25 -0700 (PDT) Received: from mail.a-quadrat.at (mail.a-quadrat.at [81.223.141.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0CF3A43D4C for ; Thu, 22 Apr 2004 02:27:25 -0700 (PDT) (envelope-from mbretter@a-quadrat.at) Received: from localhost (localhost.a-quadrat.at [127.0.0.1]) by mail.a-quadrat.at (Postfix) with ESMTP id 38BA05CFAA for ; Thu, 22 Apr 2004 11:27:23 +0200 (CEST) Received: from mail.a-quadrat.at ([127.0.0.1]) by localhost (files.a-quadrat.at [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 99575-09 for ; Thu, 22 Apr 2004 11:27:22 +0200 (CEST) Received: from a-quadrat.at (brutus.a-quadrat.at [192.168.90.60]) by mail.a-quadrat.at (Postfix) with ESMTP id 1ACBF5CF94 for ; Thu, 22 Apr 2004 11:27:22 +0200 (CEST) Message-ID: <40878FF6.1070109@a-quadrat.at> Date: Thu, 22 Apr 2004 11:27:18 +0200 From: Michael Bretterklieber User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-AT; rv:1.6) Gecko/20040113 X-Accept-Language: de-at, de, en-us, en MIME-Version: 1.0 To: net@freebsd.org References: <40878D56.9030300@vandaliamo.net> In-Reply-To: <40878D56.9030300@vandaliamo.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at a-quadrat.at Subject: Re: Assigning a specific IP address and Interface with MPD X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2004 09:27:25 -0000 Hi, Jay Hall schrieb: > > Is it possible to do this? Or should I work on trying to add the routes > as the interfaces come up based on the IP address they are assigned? > 2 possibilities: a) use RADIUS or b) use an iface-up/down script where you add/remove your routes. bye, -- ------------------------------- ---------------------------------- Michael Bretterklieber - http://www.bretterklieber.com A-Quadrat Automation GmbH - http://www.a-quadrat.at Tel: ++43-(0)3172-41679 - GSM: ++43-(0)699 12861847 ------------------------------- ---------------------------------- "...the number of UNIX installations has grown to 10, with more expected..." - Dennis Ritchie and Ken Thompson, June 1972 From owner-freebsd-net@FreeBSD.ORG Thu Apr 22 06:07:05 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 354D516A4CE for ; Thu, 22 Apr 2004 06:07:05 -0700 (PDT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0CC6E43D48 for ; Thu, 22 Apr 2004 06:07:04 -0700 (PDT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 82D6765371; Thu, 22 Apr 2004 14:07:01 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 39063-04-20; Thu, 22 Apr 2004 14:07:01 +0100 (BST) Received: from empiric.dek.spc.org (82-147-17-88.dsl.uk.rapidplay.com [82.147.17.88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id 12BB565339; Thu, 22 Apr 2004 14:07:00 +0100 (BST) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id 17A4160EE; Thu, 22 Apr 2004 14:06:59 +0100 (BST) Date: Thu, 22 Apr 2004 14:06:59 +0100 From: Bruce M Simpson To: freebsd-net@FreeBSD.org Message-ID: <20040422130659.GG722@empiric.dek.spc.org> Mail-Followup-To: freebsd-net@FreeBSD.org, mike@sentex.net Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yRA+Bmk8aPhU85Qt" Content-Disposition: inline cc: mike@sentex.net Subject: [PATCH] First part of TCP-MD5 inbound verification X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2004 13:07:05 -0000 --yRA+Bmk8aPhU85Qt Content-Type: multipart/mixed; boundary="OZkY3AIuv2LYvjdk" Content-Disposition: inline --OZkY3AIuv2LYvjdk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hey guys, I'm really pressed for time at the moment and people are demanding a lot of other things from me. So I'd like to float this patch set against HEAD which does inbound TCP-MD5 verification, so far for SYNs only. I took a decision to use sysctls rather than enlarge struct tcpstat to avoid ABI breakage, as I know Luigi and Brooks amongst others are busy hacking in netinet land. I suspect the SYN validation can probably move into syncache_add() so as to avoid code duplication in tcp_input(). Inlining it probably won't have any real benefit. The check is essentially the same in both cases (non-SYN for established connection, and SYN) but outcomes like 'goto drop', etc may be different. This appears to do the right thing with my existing test rig (Cisco 2501 running IOS 12.0(27)T). Regards, BMS --OZkY3AIuv2LYvjdk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="2385-inbound.diff" Content-Transfer-Encoding: quoted-printable Index: tcp_input.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/src/sys/netinet/tcp_input.c,v retrieving revision 1.233 diff -u -r1.233 tcp_input.c --- tcp_input.c 7 Apr 2004 20:46:13 -0000 1.233 +++ tcp_input.c 20 Apr 2004 19:36:05 -0000 @@ -154,6 +154,26 @@ &tcp_reass_overflows, 0, "Global number of TCP Segment Reassembly Queue Overflows"); =20 +#ifdef TCP_SIGNATURE +SYSCTL_NODE(_net_inet_tcp, OID_AUTO, rfc2385, CTLFLAG_RW, 0, + "TCP-MD5 RFC2385 Verification"); + +static int tcp_checksigs =3D 0; +SYSCTL_INT(_net_inet_tcp_rfc2385, OID_AUTO, verify_input, CTLFLAG_RW, + &tcp_checksigs, 0, + "Verify RFC2385 digests on inbound traffic"); + +static int tcp_rcvgoodsig =3D 0; +SYSCTL_INT(_net_inet_tcp_rfc2385, OID_AUTO, goodsegments, CTLFLAG_RD, + &tcp_rcvgoodsig, 0, + "Number of TCP segments with good RFC2385 digests"); + +static int tcp_rcvbadsig =3D 0; +SYSCTL_INT(_net_inet_tcp_rfc2385, OID_AUTO, badsegments, CTLFLAG_RD, + &tcp_rcvbadsig, 0, + "Number of TCP segments with bad RFC2385 digests"); +#endif + struct inpcbhead tcb; #define tcb6 tcb /* for KAME src sync over BSD*'s */ struct inpcbinfo tcbinfo; @@ -414,7 +434,7 @@ register struct inpcb *inp =3D NULL; u_char *optp =3D NULL; int optlen =3D 0; - int len, tlen, off; + int len, tlen, off; /* XXX set len to 0 to shutup gcc? */ int drop_hdrlen; register struct tcpcb *tp =3D 0; register int thflags; @@ -935,6 +955,57 @@ (void *)tcp_saveipgen, &tcp_savetcp, 0); #endif tcp_dooptions(&to, optp, optlen, 1); +#ifdef TCP_SIGNATURE + /* + * XXX Check should only happen if TCP_MD5SIG + * socket option is present, right now we do it + * regardless. + * i.e. && tp->t_flags & TF_SIGNATURE + * Header fields need to be in network byte order; + * restore this temporarily. Kludgy. + * XXX Move this to syncache? + */ +#ifdef INET6 + if (!isipv6) +#endif + if (tcp_checksigs && (to.to_flags & TOF_SIGNATURE)) { + char tmpdigest[TCP_SIGLEN]; + +#ifdef TCPDEBUG + printf("TCP_SIGNATURE: tcpcb=3D%p, tlen=3D%d\n", + tp, tlen); +#endif + /* + * Header fields need to be restored to + * network byte order for MD5. Kludge. + */ + th->th_seq =3D htonl(th->th_seq); + th->th_ack =3D htonl(th->th_ack); + th->th_win =3D htons(th->th_win); + th->th_urp =3D htons(th->th_urp); + + tcp_signature_compute(m, off0, tlen, optlen, + &tmpdigest[0], IPSEC_DIR_INBOUND); + if (bcmp(to.to_digest, &tmpdigest[0], + TCP_SIGLEN) !=3D 0) { +#ifdef TCPDEBUG + printf("dropped SYN due to bad " + "RFC2385 digest\n"); +#endif + tcp_rcvbadsig++; + goto drop; + } + tcp_rcvgoodsig++; + + /* + * Restore pessimized host-byte-order fields. + */ + th->th_seq =3D ntohl(th->th_seq); + th->th_ack =3D ntohl(th->th_ack); + th->th_win =3D ntohs(th->th_win); + th->th_urp =3D ntohs(th->th_urp); + } +#endif /* TCP_SIGNATURE */ if (!syncache_add(&inc, &to, th, &so, m)) goto drop; if (so =3D=3D NULL) { @@ -2597,13 +2668,25 @@ * TCP_SIGNATURE option in its initial SYN, we have to * record the fact that the option was observed here * for the syncache code to perform the correct response. + * + * For inbound verification, we also need to keep a copy + * of the digest itself, as this is discarded once the + * options are stripped out from the mbuf chain. */ case TCPOPT_SIGNATURE: - if (optlen !=3D TCPOLEN_SIGNATURE) + if (optlen !=3D TCPOLEN_SIGNATURE) { +#ifdef TCPDEBUG + printf("%s: TCPOPT_SIGNATURE: optlen %d !=3D %d", + __func__, optlen, TCPOLEN_SIGNATURE); +#endif + tcp_rcvbadsig++; continue; - to->to_flags |=3D (TOF_SIGNATURE | TOF_SIGLEN); + } + to->to_flags |=3D TOF_SIGNATURE; + bcopy((char *)cp + 2, (char *)&to->to_digest, + TCP_SIGLEN); break; -#endif +#endif /* TCP_SIGNATURE */ default: continue; } Index: tcp_var.h =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/src/sys/netinet/tcp_var.h,v retrieving revision 1.103 diff -u -r1.103 tcp_var.h --- tcp_var.h 20 Apr 2004 06:33:39 -0000 1.103 +++ tcp_var.h 20 Apr 2004 19:06:56 -0000 @@ -214,8 +214,7 @@ #define TOF_CCECHO 0x0008 #define TOF_MSS 0x0010 #define TOF_SCALE 0x0020 -#define TOF_SIGNATURE 0x0040 /* signature option present */ -#define TOF_SIGLEN 0x0080 /* sigature length valid (RFC2385) */ +#define TOF_SIGNATURE 0x0040 /* digest option present (RFC2385) */ u_int32_t to_tsval; u_int32_t to_tsecr; tcp_cc to_cc; /* holds CC or CCnew */ @@ -223,6 +222,9 @@ u_int16_t to_mss; u_int8_t to_requested_s_scale; u_int8_t to_pad; +#ifdef TCP_SIGNATURE + u_int8_t to_digest[TCP_SIGLEN]; /* RFC2385 digest if present */ +#endif }; =20 #ifdef _NETINET_IN_PCB_H_ --OZkY3AIuv2LYvjdk-- --yRA+Bmk8aPhU85Qt Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Comment: '' iD8DBQFAh8NyueUpAYYNtTsRAkF2AKCkGxdlcSZqBfoqpuR8se70801ucQCfeHiv 8lbVLwKzNJb/6qNVy4Sfyus= =7Q8n -----END PGP SIGNATURE----- --yRA+Bmk8aPhU85Qt-- From owner-freebsd-net@FreeBSD.ORG Thu Apr 22 07:13:42 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CFAFA16A4CE for ; Thu, 22 Apr 2004 07:13:42 -0700 (PDT) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id E56D843D1D for ; Thu, 22 Apr 2004 07:13:41 -0700 (PDT) (envelope-from andre@freebsd.org) Received: (qmail 72681 invoked from network); 22 Apr 2004 14:13:41 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 22 Apr 2004 14:13:41 -0000 Message-ID: <4087D314.F5ED2344@freebsd.org> Date: Thu, 22 Apr 2004 16:13:40 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Brooks Davis References: <20040421042453.GA8866@Odin.AC.HMC.Edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: net@freebsd.org Subject: Re: RFC: if_clone overhaul X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2004 14:13:42 -0000 Brooks Davis wrote: > > Please test/review the following patch to the network interface cloneing > code. This code is a major overhaul of the cloning infrastructure. > > The significant include: > - Split the code out into if_clone.[ch]. > - Locked struct if_clone. Derived from work by Maurycy > Pawlowski-Wieronski > - Add a per-cloner match function rather then simply matching names of > the form and . > - Use the match function to allow creation of . > vlan interfaces. The old way is preserved unchanged! > - Also the match function to allow creation of stf(4) interfaces named > stf0, stf, or 6to4. This is the only major user visiable change in > that "ifconfig stf" creates the interface stf rather then stf0 and > does not print "stf0" to stdout. > - Allow destroy functions to fail so they can refuse to delete > interfaces. Currently, we forbid the deletion of interfaces which > were created in the init function, particularly lo0, pflog0, and > pfsync0. In the case of lo0 this was a panic implemenation so it > does not count as a user visiable change. :-) > - Since most interfaces do not need the new functionality, an family of > wrapper functions, ifc_simple_*(), were created to wrap old style > cloner functions. > - The IF_CLONE_INITIALIZER macro is replaced with a new incompatable > IFC_CLONE_INITALIZER and ifc_simple consumers use IFC_SIMPLE_DECLARE > instead. > > TODO: > - Integrate vlan changes into /etc/rc* (add support for interfaces with > '.' in their name). > - Document new vlan syntax in vlan(4). Looks good and I like it! ;-) Some comments: o in net/if_clone.h you can remove the 3rd Regents copyright clause. o in net/if_clone.h, is ## really a legal character in variables? Looks strange for sure! o in net/if_clone.c you can remove the 3rd Regents copyright clause. o how far does the cloning code scale? I'm asking because with the work on the l2tp stuff you'll get machines with possibly 10'000 or more ppp over l2tp connections acting as LAC. o I haven't run the code or applied the patch because I have too many modifications in my tree which I need to get committed first. :-) Good work! -- Andre From owner-freebsd-net@FreeBSD.ORG Thu Apr 22 07:26:33 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CDE0016A4CE for ; Thu, 22 Apr 2004 07:26:33 -0700 (PDT) Received: from kogut3.o2.pl (kogut3.go2.pl [212.126.20.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8B59F43D53 for ; Thu, 22 Apr 2004 07:26:32 -0700 (PDT) (envelope-from knockefreebsd@o2.pl) Received: from ALFA (rekin7.go2.pl [212.126.20.19]) by kogut3.o2.pl (Postfix) with ESMTP id 1098578294 for ; Thu, 22 Apr 2004 16:26:26 +0200 (CEST) Message-ID: <003301c42875$ccd62f10$df5561d9@ALFA> From: "Heinz Knocke" To: Date: Thu, 22 Apr 2004 16:26:26 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: simulating an LFN over 1Gb LAN Ethernet? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2004 14:26:33 -0000 Hi! I'd like to simulate an LFN over LAN - my idea is to install testing = software on 2 hosts, traffic between them would be routed by the 3rd one = - a FreeBSD based router. To simulate long RTT the router would have to = delay packet forwarding in at least one direction - does anyone know how = to do it? Is it at all possible withou some changes in kernel source = code?=20 hk From owner-freebsd-net@FreeBSD.ORG Thu Apr 22 07:29:21 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A587B16A4CE for ; Thu, 22 Apr 2004 07:29:21 -0700 (PDT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 735F943D62 for ; Thu, 22 Apr 2004 07:29:21 -0700 (PDT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.9p1/8.12.8) with ESMTP id i3METKgd026451; Thu, 22 Apr 2004 07:29:20 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.9p1/8.12.3/Submit) id i3METK08026450; Thu, 22 Apr 2004 07:29:20 -0700 (PDT) (envelope-from rizzo) Date: Thu, 22 Apr 2004 07:29:20 -0700 From: Luigi Rizzo To: Heinz Knocke Message-ID: <20040422072920.A26354@xorpc.icir.org> References: <003301c42875$ccd62f10$df5561d9@ALFA> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <003301c42875$ccd62f10$df5561d9@ALFA>; from knockefreebsd@o2.pl on Thu, Apr 22, 2004 at 04:26:26PM +0200 cc: net@freebsd.org Subject: Re: simulating an LFN over 1Gb LAN Ethernet? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2004 14:29:21 -0000 On Thu, Apr 22, 2004 at 04:26:26PM +0200, Heinz Knocke wrote: > Hi! > > I'd like to simulate an LFN over LAN - my idea is to install testing software on 2 hosts, traffic between them would be routed by the 3rd one - a FreeBSD based router. To simulate long RTT the router would have to delay packet forwarding in at least one direction - does anyone know how to do it? Is it at all possible withou some changes in kernel source code? http://info.iet.unipi.it/~luigi/ip_dummynet/ luigi From owner-freebsd-net@FreeBSD.ORG Thu Apr 22 07:30:47 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 831C016A4CE for ; Thu, 22 Apr 2004 07:30:47 -0700 (PDT) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id EFC8543D48 for ; Thu, 22 Apr 2004 07:30:46 -0700 (PDT) (envelope-from andre@freebsd.org) Received: (qmail 76191 invoked from network); 22 Apr 2004 14:30:46 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 22 Apr 2004 14:30:46 -0000 Message-ID: <4087D715.AD1C0F51@freebsd.org> Date: Thu, 22 Apr 2004 16:30:45 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Heinz Knocke References: <003301c42875$ccd62f10$df5561d9@ALFA> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: net@freebsd.org Subject: Re: simulating an LFN over 1Gb LAN Ethernet? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2004 14:30:47 -0000 Heinz Knocke wrote: > > Hi! > > I'd like to simulate an LFN over LAN - my idea is to install testing software > on 2 hosts, traffic between them would be routed by the 3rd one - a FreeBSD > based router. To simulate long RTT the router would have to delay packet > forwarding in at least one direction - does anyone know how to do it? Is > it at all possible withou some changes in kernel source code? yes, do man dummynet(4), ipfw(8). -- Andre From owner-freebsd-net@FreeBSD.ORG Thu Apr 22 08:44:53 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AA5B716A4D6; Thu, 22 Apr 2004 08:44:53 -0700 (PDT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8B27743D3F; Thu, 22 Apr 2004 08:44:53 -0700 (PDT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (IDENT:brdavis@localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.12.10/8.12.3) with ESMTP id i3MFipjU008955; Thu, 22 Apr 2004 08:44:51 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.10/8.12.3/Submit) id i3MFipDC008954; Thu, 22 Apr 2004 08:44:51 -0700 Date: Thu, 22 Apr 2004 08:44:51 -0700 From: Brooks Davis To: Andre Oppermann Message-ID: <20040422154450.GA2695@Odin.AC.HMC.Edu> References: <20040421042453.GA8866@Odin.AC.HMC.Edu> <4087D314.F5ED2344@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jRHKVT23PllUwdXP" Content-Disposition: inline In-Reply-To: <4087D314.F5ED2344@freebsd.org> User-Agent: Mutt/1.5.4i cc: net@freebsd.org Subject: Re: RFC: if_clone overhaul X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2004 15:44:54 -0000 --jRHKVT23PllUwdXP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 22, 2004 at 04:13:40PM +0200, Andre Oppermann wrote: > Brooks Davis wrote: > >=20 > > Please test/review the following patch to the network interface cloneing > > code. This code is a major overhaul of the cloning infrastructure. > >=20 > > The significant include: > > - Split the code out into if_clone.[ch]. > > - Locked struct if_clone. Derived from work by Maurycy > > Pawlowski-Wieronski > > - Add a per-cloner match function rather then simply matching names of > > the form and . > > - Use the match function to allow creation of . > > vlan interfaces. The old way is preserved unchanged! > > - Also the match function to allow creation of stf(4) interfaces named > > stf0, stf, or 6to4. This is the only major user visiable change in > > that "ifconfig stf" creates the interface stf rather then stf0 and > > does not print "stf0" to stdout. > > - Allow destroy functions to fail so they can refuse to delete > > interfaces. Currently, we forbid the deletion of interfaces which > > were created in the init function, particularly lo0, pflog0, and > > pfsync0. In the case of lo0 this was a panic implemenation so it > > does not count as a user visiable change. :-) > > - Since most interfaces do not need the new functionality, an family of > > wrapper functions, ifc_simple_*(), were created to wrap old style > > cloner functions. > > - The IF_CLONE_INITIALIZER macro is replaced with a new incompatable > > IFC_CLONE_INITALIZER and ifc_simple consumers use IFC_SIMPLE_DECLARE > > instead. > >=20 > > TODO: > > - Integrate vlan changes into /etc/rc* (add support for interfaces with > > '.' in their name). > > - Document new vlan syntax in vlan(4). >=20 > Looks good and I like it! ;-) >=20 > Some comments: >=20 > o in net/if_clone.h you can remove the 3rd Regents copyright clause. > o in net/if_clone.c you can remove the 3rd Regents copyright clause. Done in perforce. > o in net/if_clone.h, is ## really a legal character in variables? > Looks strange for sure! That's the concatenation operator for cpp macros. While it's not stricly necessicary to use a unique variable name per driver since the variable is static, it's still a good idea in general. This lets me do that (it's also why the input is unquoted). >=20 > o how far does the cloning code scale? I'm asking because with the > work on the l2tp stuff you'll get machines with possibly 10'000 > or more ppp over l2tp connections acting as LAC. The only scaling issue I can think of is that it uses a linearly scanned bitmap of units to handle unit allocation. You could presumably optimize this into some sort of a tree if you had poor performance and sparce allocation. You could also obtain some optimization benefits by using longs (native word size ints) instead of chars. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --jRHKVT23PllUwdXP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFAh+hyXY6L6fI4GtQRAqoWAKCa8VGpdT/BOErglqPlTCQSmPT9cwCgh4/r 7P9mVfBBX6YkUTYQvyJcblE= =ytzh -----END PGP SIGNATURE----- --jRHKVT23PllUwdXP-- From owner-freebsd-net@FreeBSD.ORG Thu Apr 22 08:50:29 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 85F6416A5CA; Thu, 22 Apr 2004 08:50:29 -0700 (PDT) Received: from ftp.ccrle.nec.de (ftp.netlab.nec.de [195.37.70.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3ECEC43D31; Thu, 22 Apr 2004 08:50:28 -0700 (PDT) (envelope-from lars.eggert@netlab.nec.de) Received: from netlab.nec.de (scout.netlab.nec.de [195.37.70.100]) by ftp.ccrle.nec.de (Postfix) with ESMTP id 3A891F674; Thu, 22 Apr 2004 17:55:28 +0200 (CEST) Message-ID: <4087E9C1.1010907@netlab.nec.de> Date: Thu, 22 Apr 2004 17:50:25 +0200 From: Lars Eggert Organization: NEC Network Laboratories User-Agent: Mozilla Thunderbird 0.6+ (Macintosh/20040420) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Luigi Rizzo References: <003301c42875$ccd62f10$df5561d9@ALFA> <20040422072920.A26354@xorpc.icir.org> In-Reply-To: <20040422072920.A26354@xorpc.icir.org> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010204030507040308060501" cc: andre@freebsd.org cc: Heinz Knocke cc: net@freebsd.org Subject: Re: simulating an LFN over 1Gb LAN Ethernet? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2004 15:50:29 -0000 This is a cryptographically signed message in MIME format. --------------ms010204030507040308060501 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Luigi Rizzo wrote: > On Thu, Apr 22, 2004 at 04:26:26PM +0200, Heinz Knocke wrote: >> >> I'd like to simulate an LFN over LAN - my idea is to install >> testing software on 2 hosts, traffic between them would be routed >> by the 3rd one - a FreeBSD based router. To simulate long RTT the >> router would have to delay packet forwarding in at least one >> direction - does anyone know how to do it? Is it at all possible >> withou some changes in kernel source code? > > http://info.iet.unipi.it/~luigi/ip_dummynet/ Dummynet is great, but at Gigabit speeds it has issues with regard to preservation of packet inter-arrival spacing. That may or may not be a problem for what you are trying to simulate however. Lars -- Lars Eggert NEC Network Laboratories --------------ms010204030507040308060501 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ/zCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNaMIICw6ADAgECAgMLU6IwDQYJKoZIhvcNAQEE BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTAz MTIxNTEyMzEyOFoXDTA0MTIxNDEyMzEyOFowgYQxDzANBgNVBAQTBkVnZ2VydDENMAsGA1UE KhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxKDAmBgkqhkiG9w0BCQEWGWxhcnMuZWdn ZXJ0QG5ldGxhYi5uZWMuZGUxIjAgBgkqhkiG9w0BCQEWE2xhcnMuZWdnZXJ0QGdteC5uZXQw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDWps58Zq8Buu2DKDl9crbvzSo6zWsZ TkQLr5zOTqUMs/eU7Mcohv64O4IxWWYGLfYsjDRxUlmdHdJUbyTtUh2lH452DUDJByXidlLm RDgohG0AVwztedqy1+hE3VnCdpMhUGks+6ntrr3dKSxMgLM0AM1kPWsH9lWX6IOPdxOC30gM PiQ65zH9PR70befQLgFPKcAv0wP8210l05n8ekwYAcq2cm3/j+nuDu0HEh5pgsnY7cVELeNJ ODvr4IiE1t3c2w4+0Nc/WJrqGCMl+gZ8c+7FtzjoyDeEsCjNFDeA2ymNd+10O6kjwvPHlzPr 3rW73RDRPAjMJ49HXlueiuoNAgMBAAGjdzB1MCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy dU15ZmZCTlViTkpKY2RaMnMwOQYDVR0RBDIwMIEZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5k ZYETbGFycy5lZ2dlcnRAZ214Lm5ldDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GB AHgrv3SQFD4AS4lY4oKcI3iTHcclEHbYfg3UUb8zzCUsl+OJoz0nmebGmOL+tvNj5GvCrWnN H4LvVLh8ZBhFXms7eKJ1YiHgbKwTRK23P8Y5NDit5ico0ZjpFWeenUWj3ajEbN6n4K8dNp+C 0b2apnSrlFVWY6BucZFIYqQ1Lf91MIIDWjCCAsOgAwIBAgIDC1OiMA0GCSqGSIb3DQEBBAUA MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wMzEy MTUxMjMxMjhaFw0wNDEyMTQxMjMxMjhaMIGEMQ8wDQYDVQQEEwZFZ2dlcnQxDTALBgNVBCoT BExhcnMxFDASBgNVBAMTC0xhcnMgRWdnZXJ0MSgwJgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2Vy dEBuZXRsYWIubmVjLmRlMSIwIAYJKoZIhvcNAQkBFhNsYXJzLmVnZ2VydEBnbXgubmV0MIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1qbOfGavAbrtgyg5fXK2780qOs1rGU5E C6+czk6lDLP3lOzHKIb+uDuCMVlmBi32LIw0cVJZnR3SVG8k7VIdpR+Odg1AyQcl4nZS5kQ4 KIRtAFcM7XnastfoRN1ZwnaTIVBpLPup7a693SksTICzNADNZD1rB/ZVl+iDj3cTgt9IDD4k Oucx/T0e9G3n0C4BTynAL9MD/NtdJdOZ/HpMGAHKtnJt/4/p7g7tBxIeaYLJ2O3FRC3jSTg7 6+CIhNbd3NsOPtDXP1ia6hgjJfoGfHPuxbc46Mg3hLAozRQ3gNspjXftdDupI8Lzx5cz6961 u90Q0TwIzCePR15bnorqDQIDAQABo3cwdTAqBgUrZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVN eWZmQk5VYk5KSmNkWjJzMDkGA1UdEQQyMDCBGWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMuZGWB E2xhcnMuZWdnZXJ0QGdteC5uZXQwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQB4 K790kBQ+AEuJWOKCnCN4kx3HJRB22H4N1FG/M8wlLJfjiaM9J5nmxpji/rbzY+Rrwq1pzR+C 71S4fGQYRV5rO3iidWIh4GysE0Sttz/GOTQ4reYnKNGY6RVnnp1Fo92oxGzep+CvHTafgtG9 mqZ0q5RVVmOgbnGRSGKkNS3/dTGCAzswggM3AgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMLU6IwCQYFKw4DAhoFAKCCAacwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQwNDIyMTU1MDI1WjAjBgkqhkiG 9w0BCQQxFgQUZ3FMoZKq2VtDBJ2qnxKPkRWYqQgwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG 9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN AwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3Rl IENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECAwtTojB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMLU6IwDQYJKoZIhvcNAQEBBQAEggEA X8DiCAyvHHLYduaTKJQscgqKbhoy2h7UvIcqMemzc9PKI3Env+HdewgQKd+aS5go1cHSzSsO xMyW6wNuPrECGSScvaqKK2FiQDcKRRNjzFoYW8JpXXpEmspIAy29V7jwR4lInFRCkMKHm2oq PUJJ3igou4S9MMr+Tg8sYYwC+cZ2YxP237N6Ae3Adv2Fq4+hVa62YDDLY+4z0010fHwyAJSD jSIuJxKN8zekn3YfSl0OuRVn9Ft9kmjUG6XIJrWHfVswY1A99zNfZT/plkFH8KA4y40HTZo8 O+9GPskFVb+iEpk4S9J6+zzyfcvSfvl/peg9njJb8pluXvMEjuTq/QAAAAAAAA== --------------ms010204030507040308060501-- From owner-freebsd-net@FreeBSD.ORG Thu Apr 22 09:03:56 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 61C5616A4CE for ; Thu, 22 Apr 2004 09:03:56 -0700 (PDT) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8721A43D2F for ; Thu, 22 Apr 2004 09:03:55 -0700 (PDT) (envelope-from andre@freebsd.org) Received: (qmail 89804 invoked from network); 22 Apr 2004 16:03:54 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 22 Apr 2004 16:03:54 -0000 Message-ID: <4087ECE9.E74B7EF3@freebsd.org> Date: Thu, 22 Apr 2004 18:03:54 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: current@freebsd.org, net@freebsd.org, security@freebsd.org Content-Type: multipart/mixed; boundary="------------408A56302E1216CAA90B06A1" Subject: [Fwd: NetBSD Security Advisory 2004-006: TCP protocol andimplementation vulnerability] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2004 16:03:56 -0000 This is a multi-part message in MIME format. --------------408A56302E1216CAA90B06A1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit FYI --------------408A56302E1216CAA90B06A1 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Mozilla-Status2: 00000000 Message-ID: <4087C5B4.D80833B1@freebsd.org> Date: Thu, 22 Apr 2004 15:16:36 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: bugtraq@securityfocus.com Subject: Re: NetBSD Security Advisory 2004-006: TCP protocol and implementation vulnerability References: <20040421181435.GR8091@mail> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The additional implementation flaw of BSD based TCP/IP stacks has been fixed in FreeBSD in revision 1.81 of tcp_input.c in 1998 for FreeBSD 2.2 and 3.0 and all releases since about six years ago. -- Andre NetBSD Security-Officer wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > NetBSD Security Advisory 2004-006 > ================================= > > Topic: TCP protocol and implementation vulnerability > > Severity: Serious (TCP disconnected by malicious party, unwanted data > injected into TCP stream) > > Abstract > ======== > > The longstanding TCP protocol specification has several weaknesses. > (RFC793): > > - - fabricated RST packets from a malicious third party can tear down a > TCP session > - - fabricated SYN packets from a malicious third party can tear down a > TCP session > - - a malicious third party can inject data to TCP session without much > difficulty > > NetBSD also had an additional implementation flaw, which made these > attacks easier. --------------408A56302E1216CAA90B06A1-- From owner-freebsd-net@FreeBSD.ORG Thu Apr 22 09:11:46 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CCF8316A4CE for ; Thu, 22 Apr 2004 09:11:46 -0700 (PDT) Received: from pit.databus.com (p70-227.acedsl.com [66.114.70.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1B75F43D45 for ; Thu, 22 Apr 2004 09:11:46 -0700 (PDT) (envelope-from barney@pit.databus.com) Received: from pit.databus.com (localhost [127.0.0.1]) by pit.databus.com (8.12.11/8.12.11) with ESMTP id i3MGBjXS048616 for ; Thu, 22 Apr 2004 12:11:45 -0400 (EDT) (envelope-from barney@pit.databus.com) Received: (from barney@localhost) by pit.databus.com (8.12.11/8.12.11/Submit) id i3MGBjVW048615 for freebsd-net@FreeBSD.org; Thu, 22 Apr 2004 12:11:45 -0400 (EDT) (envelope-from barney) Date: Thu, 22 Apr 2004 12:11:45 -0400 From: Barney Wolff To: freebsd-net@FreeBSD.org Message-ID: <20040422161145.GA48173@pit.databus.com> References: <20040422130659.GG722@empiric.dek.spc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040422130659.GG722@empiric.dek.spc.org> User-Agent: Mutt/1.5.6i X-Scanned-By: MIMEDefang 2.39 Subject: Re: [PATCH] First part of TCP-MD5 inbound verification X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2004 16:11:46 -0000 Just a note that, as discussion on nanog shows, it's very important to only do the md5 check if the incoming packet is going to be accepted and processed, rather than the intuitive order of checking the sig first. That's because checking first allows an easy DoS, since checking is cpu-intensive. Barney -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. From owner-freebsd-net@FreeBSD.ORG Fri Apr 23 10:35:14 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 557E516A4D0; Fri, 23 Apr 2004 10:35:14 -0700 (PDT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 85C8043D31; Fri, 23 Apr 2004 10:35:13 -0700 (PDT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i3NHdvLh099042 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Apr 2004 20:39:59 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.12.11/8.12.11) id i3NHZIJo003269; Fri, 23 Apr 2004 20:35:18 +0300 (EEST) (envelope-from ru) Date: Fri, 23 Apr 2004 20:35:18 +0300 From: Ruslan Ermilov To: David Yeske Message-ID: <20040423173518.GC2922@ip.net.ua> References: <20040423005057.15006.qmail@web13504.mail.yahoo.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lCAWRPmW1mITcIfM" Content-Disposition: inline In-Reply-To: <20040423005057.15006.qmail@web13504.mail.yahoo.com> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: Archie Cobbs cc: net@FreeBSD.org Subject: Re: netgraph ability X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2004 17:35:14 -0000 --lCAWRPmW1mITcIfM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [ Redirected to -net ] On Thu, Apr 22, 2004 at 05:50:57PM -0700, David Yeske wrote: > I'm in a situation where I need to emulate multiple ethernet devices with > different mac addresses. I have gotten far enough to have this. >=20 > I ran ngctl and then ran > "mkpeer . eiface hook ether" >=20 > I then ran > ifconfig ngeth0 link '00:bd:03:11:21:11' > ifconfig ngeth0 192.168.20.5 > ifconfig sis0 192.168.23.45 >=20 > So basically I want to be able to ping / connect to=20 > 192.168.20.5 from another box on the 192.168.23.0/24 network, and have it= see > the mac address that I have set rather than the mac address of my sis0 de= vice. > I know I can do this with vmware, but I am trying to avoid that. >=20 > Anyone know if this is possible? Is there a way to do this with the tap = device > and or arpd? >=20 Using Netgraph, you can emulate any number of Ethernet interfaces on one physical interface. Here's my recipe for you: 1. Load the ng_ether(4) module. 2. Create the required number of ng_eiface(4) nodes. 3. Connect "lower" and "upper" of sis0: and all ngethX: ng_ether(4) nodes to one ng_bridge(4). 4. Make sure to "ngctl msg : setautosrc 0" to all ng_ether(4) nodes. 5. Optionally set net.link.ether.inet.log_arp_wrong_iface=3D0. Here's my test (I've omitted obvious configuration steps): # ifconfig dc0 ether dc0: flags=3D8843 mtu 1500 options=3D48 ether 00:10:a4:c0:c0:45 # ifconfig ngeth0 ngeth0: flags=3D8843 mtu 1500 ether 00:00:00:01:02:03 # ngctl show bridge: Name: bridge Type: bridge ID: 0000000b Num hooks: 4 Local hook Peer name Peer type Peer ID Peer hook ---------- --------- --------- ------- --------- link4 ngeth0 ether 00000007 lower link3 ngeth0 ether 00000007 upper link2 dc0 ether 00000002 lower link1 dc0 ether 00000002 upper # ifconfig ngeth0 1.2.3.4 # tcpdump -lenx -i dc0 ether host 0:0:0:1:2:3 tcpdump: listening on dc0 20:29:05.571179 0:0:0:1:2:3 ff:ff:ff:ff:ff:ff 0806 42: arp who-has 1.2.3.4 = tell 1.2.3.4 0001 0800 0604 0001 0000 0001 0203 0102 0304 0000 0000 0000 0102 0304 Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --lCAWRPmW1mITcIfM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAiVPWUkv4P6juNwoRAm9cAJ408iFmsjqyt7BsbUCLLdBghhM7YACfcYJv qqwP5OCSr4gezalcnT0WFIg= =fYNN -----END PGP SIGNATURE----- --lCAWRPmW1mITcIfM-- From owner-freebsd-net@FreeBSD.ORG Fri Apr 23 20:34:01 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 43F3116A4CF for ; Fri, 23 Apr 2004 20:34:01 -0700 (PDT) Received: from mx3.mra.co.id (mx3.mra.co.id [202.138.254.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF36D43D2D for ; Fri, 23 Apr 2004 20:33:58 -0700 (PDT) (envelope-from reza@it.mra.co.id) Received: from localhost (unknown [127.0.0.1]) by mx3.mra.co.id (Postfix) with ESMTP id 386652E0C8 for ; Sat, 24 Apr 2004 10:47:12 +0700 (WIT) Received: from mx3.mra.co.id ([127.0.0.1]) by localhost (mx3.mra.co.id [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 77927-27 for ; Sat, 24 Apr 2004 10:45:57 +0700 (WIT) Received: from suse.sisfo.net (unknown [202.155.147.74]) by mx3.mra.co.id (Postfix) with ESMTP id CDF042E0BA for ; Sat, 24 Apr 2004 10:45:53 +0700 (WIT) From: Muhammad Reza To: freebsd-net@freebsd.org Date: Sat, 24 Apr 2004 17:38:15 +0700 User-Agent: KMail/1.5.4 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200404241738.15433.reza@it.mra.co.id> X-Virus-Scanned: by amavisd-new at mra.co.id Subject: multiple provider X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Apr 2004 03:34:01 -0000 Dear BSD'ers Can freebsd routing kernel do multiple provider ? without BGP ? Now I have a (new ) ADSL, and T1 connection to different provider, my LAN is nat-ing behind freebsd router, I want some people in my network to connect to internet via ADSL and some people via T1, based on their IP. They said , i can do that with linux iproute tools, but i dont want to replace my FreeBSD-4.9Stable router with Linux. Please help me, any suggestion is appriciate. regards reza From owner-freebsd-net@FreeBSD.ORG Sat Apr 24 00:24:09 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4C8EA16A4CF for ; Sat, 24 Apr 2004 00:24:09 -0700 (PDT) Received: from mail013.syd.optusnet.com.au (mail013.syd.optusnet.com.au [211.29.132.67]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1FC1443D2F for ; Sat, 24 Apr 2004 00:24:08 -0700 (PDT) (envelope-from david.burns@dugeem.net) Received: from dugeem.net (c211-30-248-50.carlnfd2.nsw.optusnet.com.au [211.30.248.50])i3O7O5w22940 for ; Sat, 24 Apr 2004 17:24:06 +1000 Message-ID: <408A160F.4090703@dugeem.net> Date: Sat, 24 Apr 2004 17:23:59 +1000 From: David Burns User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, en-us MIME-Version: 1.0 To: net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: fast ethernet driver MII phy serial clock rates X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Apr 2004 07:24:09 -0000 Hello all, It appears that quite a few of the "el cheapo" hardware Fast Ethernet drivers (at least rl, sis, ste, vr, wb - these are just the ones I found in /usr/src/sys/pci) have added DELAY(1) statements around MII serial clock ops which will result in a max Management Data Clock (MDC) frequency of 500kHz for the serial management interface. Which means that a mii_readreg (or writereg) operation will take a minimum of 128?s (64?s for mii_sync + 64?s for data read/write). During which time the driver is locked. NB this assumes that a DELAY(1) is really a delay of 1?s! Which I don't think it is ... :-( However many Fast Ethernet (ie 100Mb/s) PHYs appear to specify a maximum MDC rate of 2.5MHz. Whilst at first this appears harmless - the mii_readreg & mii_writereg routines are periodically called by MII bus functions every second: - With autoneg on there are around 7 mii register ops (0.9ms total) - With autoneg off there are around 3 mii register ops (0.4ms total) The serial management access bits are set/cleared via various macros (eg. CLRBIT/SETBIT). Generally a clock bit operation consists of a CSR_READ & CSR_WRITE which are of course PCI read & write operations with minimum clock times of 4 cycles and 3 cycles respectively - or 210 nanoseconds per half cycle (@33MHz) which is a bit slower than 2.5MHz! Of course this assumes PCI 33MHz - which is all this hardware will work with. So I'd like to propose that these DELAY() statements be removed if testing results are okay. I believe this has already been done with the xl driver some time ago... For verification I made this change on the ste v1.58 driver and it worked fine - and has resulted in 5-10% network performance improvements. Next up I will test the vr driver. If needs be I can open a PR for this but wanted some feedback first from others who may have previously worked on the driver MII code. David From owner-freebsd-net@FreeBSD.ORG Sat Apr 24 07:45:35 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7148916A4D0 for ; Sat, 24 Apr 2004 07:45:35 -0700 (PDT) Received: from web80106.mail.yahoo.com (web80106.mail.yahoo.com [66.163.169.79]) by mx1.FreeBSD.org (Postfix) with SMTP id 55CC643D31 for ; Sat, 24 Apr 2004 07:45:35 -0700 (PDT) (envelope-from evans.alan@sbcglobal.net) Message-ID: <20040424144535.81824.qmail@web80106.mail.yahoo.com> Received: from [66.124.150.213] by web80106.mail.yahoo.com via HTTP; Sat, 24 Apr 2004 07:45:35 PDT Date: Sat, 24 Apr 2004 07:45:35 -0700 (PDT) From: Alan Evans To: net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: TCP vulnrability X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Apr 2004 14:45:35 -0000 I'm sure FreeBSD is vulnerable. http://www.us-cert.gov/cas/techalerts/TA04-111A.html There's a draft that (sort of) addresses this. Should we adopt it? draft-ietf-tcpm-tcpsecure-00.txt Alan. From owner-freebsd-net@FreeBSD.ORG Sat Apr 24 08:01:08 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B579316A4CE for ; Sat, 24 Apr 2004 08:01:08 -0700 (PDT) Received: from out008.verizon.net (out008pub.verizon.net [206.46.170.108]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4EA4043D39 for ; Sat, 24 Apr 2004 08:01:08 -0700 (PDT) (envelope-from cswiger@mac.com) Received: from mac.com ([68.160.247.127]) by out008.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <20040424150107.WGQU27801.out008.verizon.net@mac.com>; Sat, 24 Apr 2004 10:01:07 -0500 Message-ID: <408A8127.6010908@mac.com> Date: Sat, 24 Apr 2004 11:00:55 -0400 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alan Evans References: <20040424144535.81824.qmail@web80106.mail.yahoo.com> In-Reply-To: <20040424144535.81824.qmail@web80106.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at out008.verizon.net from [68.160.247.127] at Sat, 24 Apr 2004 10:01:07 -0500 cc: net@freebsd.org Subject: Re: TCP vulnerability X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Apr 2004 15:01:08 -0000 Alan Evans wrote: > I'm sure FreeBSD is vulnerable. > > http://www.us-cert.gov/cas/techalerts/TA04-111A.html > > There's a draft that (sort of) addresses this. Should > we adopt it? This issue is being discussed on freebsd-security now, and Mike Silbersack has some patches available for review and testing. -- -Chuck From owner-freebsd-net@FreeBSD.ORG Sat Apr 24 08:22:42 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 01A5B16A4CE for ; Sat, 24 Apr 2004 08:22:42 -0700 (PDT) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 047E343D5E for ; Sat, 24 Apr 2004 08:22:40 -0700 (PDT) (envelope-from andre@freebsd.org) Received: (qmail 14491 invoked from network); 24 Apr 2004 15:22:38 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.54]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 24 Apr 2004 15:22:38 -0000 Message-ID: <408A863E.B6E60792@freebsd.org> Date: Sat, 24 Apr 2004 17:22:38 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Chuck Swiger References: <20040424144535.81824.qmail@web80106.mail.yahoo.com> <408A8127.6010908@mac.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: Alan Evans cc: net@freebsd.org Subject: Re: TCP vulnerability X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Apr 2004 15:22:42 -0000 Chuck Swiger wrote: > > Alan Evans wrote: > > I'm sure FreeBSD is vulnerable. > > > > http://www.us-cert.gov/cas/techalerts/TA04-111A.html > > > > There's a draft that (sort of) addresses this. Should > > we adopt it? > > This issue is being discussed on freebsd-security now, and Mike Silbersack > has some patches available for review and testing. There has been an additional problem in some BSD stacks with RST's which has been fixed in FreeBSD about six years ago. The remaining things which are addressed in that paper are hardening measures to reduce the chances of a brute force blind attack. There *no* vulner- ablility in the sense of "send packet x" and everything breaks. -- Andre From owner-freebsd-net@FreeBSD.ORG Sat Apr 24 08:43:28 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BD5C416A4CE for ; Sat, 24 Apr 2004 08:43:28 -0700 (PDT) Received: from web80105.mail.yahoo.com (web80105.mail.yahoo.com [66.163.169.78]) by mx1.FreeBSD.org (Postfix) with SMTP id 94FE243D5D for ; Sat, 24 Apr 2004 08:43:28 -0700 (PDT) (envelope-from evans.alan@sbcglobal.net) Message-ID: <20040424154328.24028.qmail@web80105.mail.yahoo.com> Received: from [66.124.150.213] by web80105.mail.yahoo.com via HTTP; Sat, 24 Apr 2004 08:43:28 PDT Date: Sat, 24 Apr 2004 08:43:28 -0700 (PDT) From: Alan Evans To: Andre Oppermann , Chuck Swiger In-Reply-To: <408A863E.B6E60792@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: Alan Evans cc: net@freebsd.org Subject: Re: TCP vulnerability X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Apr 2004 15:43:28 -0000 I agree, but what's most important is to maintain backward compatibility. If one breaks it, it's a DoS is some sense. I also saw some postings on NetBSD which does ratelimiting of ACKs (in response to SYNs), and ACKs RST. IMHO, the latter is bogus - why ACK a RST? And, the former may impose an artificial limit of some sort. Alan Evans --- Andre Oppermann wrote: > Chuck Swiger wrote: > > > > Alan Evans wrote: > > > I'm sure FreeBSD is vulnerable. > > > > > > > http://www.us-cert.gov/cas/techalerts/TA04-111A.html > > > > > > There's a draft that (sort of) addresses this. > Should > > > we adopt it? > > > > This issue is being discussed on freebsd-security > now, and Mike Silbersack > > has some patches available for > review and testing. > > There has been an additional problem in some BSD > stacks with RST's > which has been fixed in FreeBSD about six years ago. > The remaining > things which are addressed in that paper are > hardening measures to > reduce the chances of a brute force blind attack. > There *no* vulner- > ablility in the sense of "send packet x" and > everything breaks. > > -- > Andre From owner-freebsd-net@FreeBSD.ORG Sat Apr 24 09:05:48 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4A2C416A4CF for ; Sat, 24 Apr 2004 09:05:48 -0700 (PDT) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 491B643D1D for ; Sat, 24 Apr 2004 09:05:47 -0700 (PDT) (envelope-from andre@freebsd.org) Received: (qmail 16574 invoked from network); 24 Apr 2004 16:05:46 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.54]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 24 Apr 2004 16:05:46 -0000 Message-ID: <408A9059.B31E720A@freebsd.org> Date: Sat, 24 Apr 2004 18:05:45 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Alan Evans References: <20040424154328.24028.qmail@web80105.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: net@freebsd.org Subject: Re: TCP vulnerability X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Apr 2004 16:05:48 -0000 Alan Evans wrote: > > I agree, but what's most important is to maintain > backward compatibility. If one breaks it, it's a DoS > is some sense. I also saw some postings on NetBSD > which does ratelimiting of ACKs (in response to SYNs), > and ACKs RST. IMHO, the latter is bogus - why ACK a > RST? And, the former may impose an artificial limit > of some sort. Dunno about the rate limiting. The ACK of the RST is recommended in the paper you have referenced but only when sequence number of the segment with the RST is not the next expected but within the window. Makes sense to reduce the chances of an successful blind reset from 2^32/win to 2^32. With large windows definitely a win by an order of an magnitude. -- Andre From owner-freebsd-net@FreeBSD.ORG Sat Apr 24 09:11:43 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1773416A4CE for ; Sat, 24 Apr 2004 09:11:43 -0700 (PDT) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4CE8843D39 for ; Sat, 24 Apr 2004 09:11:42 -0700 (PDT) (envelope-from andre@freebsd.org) Received: (qmail 16892 invoked from network); 24 Apr 2004 16:11:41 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.54]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 24 Apr 2004 16:11:41 -0000 Message-ID: <408A91BC.46A0D95F@freebsd.org> Date: Sat, 24 Apr 2004 18:11:40 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: David Burns References: <408A160F.4090703@dugeem.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: net@freebsd.org Subject: Re: fast ethernet driver MII phy serial clock rates X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Apr 2004 16:11:43 -0000 David Burns wrote: > > Hello all, > > It appears that quite a few of the "el cheapo" hardware Fast Ethernet > drivers (at least rl, sis, ste, vr, wb - these are just the ones I found > in /usr/src/sys/pci) have added DELAY(1) statements around MII serial > clock ops which will result in a max Management Data Clock (MDC) > frequency of 500kHz for the serial management interface. Which means > that a mii_readreg (or writereg) operation will take a minimum of 128?s > (64?s for mii_sync + 64?s for data read/write). During which time the > driver is locked. > > NB this assumes that a DELAY(1) is really a delay of 1?s! Which I don't > think it is ... :-( > > However many Fast Ethernet (ie 100Mb/s) PHYs appear to specify a maximum > MDC rate of 2.5MHz. > > Whilst at first this appears harmless - the mii_readreg & mii_writereg > routines are periodically called by MII bus functions every second: > - With autoneg on there are around 7 mii register ops (0.9ms total) > - With autoneg off there are around 3 mii register ops (0.4ms total) > > The serial management access bits are set/cleared via various macros > (eg. CLRBIT/SETBIT). Generally a clock bit operation consists of a > CSR_READ & CSR_WRITE which are of course PCI read & write operations > with minimum clock times of 4 cycles and 3 cycles respectively - or 210 > nanoseconds per half cycle (@33MHz) which is a bit slower than 2.5MHz! > Of course this assumes PCI 33MHz - which is all this hardware will work > with. > > So I'd like to propose that these DELAY() statements be removed if > testing results are okay. I believe this has already been done with the > xl driver some time ago... > > For verification I made this change on the ste v1.58 driver and it > worked fine - and has resulted in 5-10% network performance > improvements. Next up I will test the vr driver. > > If needs be I can open a PR for this but wanted some feedback first from > others who may have previously worked on the driver MII code. This is a very interesting observation. I've just worked my way through the MII code to add link state notification to the routing socket and had to remove a couple of return(0) when the link is up to break so the later status function can read the MII and announce the state change if neccessary. Based on your explanation this seems to be a regression and I will look at how to work around this. Do you have any idea how to make the MII access faster or to get some sort of async notification from the hardware when the link state changes so we don't have to poll every second? -- Andre From owner-freebsd-net@FreeBSD.ORG Sat Apr 24 12:02:54 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 33DF716A4CE for ; Sat, 24 Apr 2004 12:02:54 -0700 (PDT) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id A9EF443D58 for ; Sat, 24 Apr 2004 12:02:53 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 1263 invoked from network); 24 Apr 2004 19:02:52 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 24 Apr 2004 19:02:52 -0000 X-pair-Authenticated: 209.68.2.70 Date: Sat, 24 Apr 2004 14:04:14 -0500 (CDT) From: Mike Silbersack To: David Burns In-Reply-To: <408A160F.4090703@dugeem.net> Message-ID: <20040424140143.S5713@odysseus.silby.com> References: <408A160F.4090703@dugeem.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: net@freebsd.org Subject: Re: fast ethernet driver MII phy serial clock rates X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Apr 2004 19:02:54 -0000 On Sat, 24 Apr 2004, David Burns wrote: > Hello all, > > It appears that quite a few of the "el cheapo" hardware Fast Ethernet > drivers (at least rl, sis, ste, vr, wb - these are just the ones I found > in /usr/src/sys/pci) have added DELAY(1) statements around MII serial > clock ops which will result in a max Management Data Clock (MDC) > frequency of 500kHz for the serial management interface. Which means > that a mii_readreg (or writereg) operation will take a minimum of 128?s > (64?s for mii_sync + 64?s for data read/write). During which time the > driver is locked. This is an old problem, most of us leave it alone because hardware can break in strange ways. :) > NB this assumes that a DELAY(1) is really a delay of 1?s! Which I don't > think it is ... :-( Correct, DELAY takes far longer than it should. If you're really interested in fixing the problem and not inadvertantly breaking older cards, what you should do is implement a nanodelay function that actually delays for the time it's supposed to and then delay the rated amount. Removing all delays will probably break something somewhere. Mike "Silby" Silbersack