From owner-freebsd-net Wed Jan 1 4:45: 7 2003 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BEA4137B401 for ; Wed, 1 Jan 2003 04:45:06 -0800 (PST) Received: from web14804.mail.yahoo.com (web14804.mail.yahoo.com [216.136.224.220]) by mx1.FreeBSD.org (Postfix) with SMTP id 33F0C43EC2 for ; Wed, 1 Jan 2003 04:45:06 -0800 (PST) (envelope-from rosti_bsd@yahoo.com) Message-ID: <20030101124506.56518.qmail@web14804.mail.yahoo.com> Received: from [192.117.108.59] by web14804.mail.yahoo.com via HTTP; Wed, 01 Jan 2003 04:45:06 PST Date: Wed, 1 Jan 2003 04:45:06 -0800 (PST) From: Rostislav Krasny Subject: Re: PPPoE and troubles with TCP To: Eli Dart Cc: freeBSD-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I make few further testings... According to http://uptime.netcraft.net/up/graph?site=www.ssh.com the host www.ssh.com uses NetBSD or OpenBSD operating system. When my box is configured according to the following expression: net.inet.tcp.rfc1323 == 1 (that is the default for FreeBSD 4.7-RELEASE), I have the same trouble with www.netbsd.org like the trouble that I have with www.ssh.com. According to http://uptime.netcraft.net/up/graph?site=www.openbsd.org the host www.openbsd.com uses Solaris operating system. This is why I have no problem with http://www.openbsd.org/ So, the problem with www.ssh.com looks like a bug in NetBSD's or/and OpenBSD's implementation of the TCP protocol. And also, one of the following configurations of my box: MRU == MTU == 1484 (or smaller) or net.inet.tcp.rfc1323 == 0 solves the problem with http://www.netbsd.org/ too. I think that cooperation with NetBSD or/and OpenBSD team(s) would be helpful and efficient for localization of the problem. __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jan 1 20: 3: 3 2003 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E80ED37B401 for ; Wed, 1 Jan 2003 20:03:01 -0800 (PST) Received: from neo.tamu.edu (scarran.tamu.edu [165.91.252.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id 45E8143EB2 for ; Wed, 1 Jan 2003 20:03:01 -0800 (PST) (envelope-from daved@tamu.edu) Received: from tamu.edu (dyna-0058.vpn.tamu.edu [172.16.32.58]) by neo.tamu.edu (Switch-2.2.4/Switch-2.2.4) with ESMTP id h0242wh09370; Wed, 1 Jan 2003 22:02:59 -0600 (CST) Date: Wed, 1 Jan 2003 22:02:28 -0600 Subject: Re: Redundant NIC/Connections Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-3-895925799" Mime-Version: 1.0 (Apple Message framework v551) Cc: Mitch Collinsworth , freebsd-net@FreeBSD.ORG To: Steve Francis From: David J Duchscher In-Reply-To: <3E1244CA.60702@expertcity.com> Message-Id: <02B3D733-1E07-11D7-9808-0003930B3DA4@tamu.edu> Content-Transfer-Encoding: 7bit X-Pgp-Agent: GPGMail 0.5.4 (v22 Jaguar) X-Mailer: Apple Mail (2.551) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --Apple-Mail-3-895925799 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On Tuesday, December 31, 2002, at 07:30 PM, Steve Francis wrote: > Mitch Collinsworth wrote: > >> On Mon, 2 Dec 2002, David J Duchscher wrote: >> >> >> >I was wondering how people are handling redundant connections? We >> >would like to have dual NICs in the FreeBSD box with each NIC >> connected >> >to a different switch. Both switches are in the same broadcast >> domain. >> >In pointers, hints on this may done would be greatly appreciated. >> >> >> Hmm... no responses posted to date. > > I think one of my colleagues responded directly to the poster. We do > it by a daemon he wrote that monitors interface link status, and also > pingability of default gateways, and reconfigures interfaces in event > of a failure, based on the normal configuration file settings > (/etc/rc.conf) > > Instantly in event of link loss; after a few seconds of retrying in > event of router loss (we use HSRP addresses for routers.) Yes, I got a few responses including the one mentioned above. Lack of time and changing priorities has prevented me from following up on them. Anshuman Kanwar did mentioned he might release his solution as open source if there was interest. I am at least interested in reviewing it. I just need to find the time. DaveD --Apple-Mail-3-895925799 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-disposition: inline content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (Darwin) iQCVAwUBPhO52PsJYFdBGj/VAQIIfQQA1XU46hin8BIpKxD8j0yR8MSWrWX2/Ego IHnJsIPaF/5rcbPxgHcytfWVzPC9mO8u1t6cx8V+Vqbk20RVFq02KhxqLpDXuTUK TuUA8Gl6AnYWAT85Ug+D+Zg0U+GneyQvJHZDchc63LMq52NJVUcdAIcs/1CF85Cb VWNE5S3T5bo= =faVk -----END PGP SIGNATURE----- --Apple-Mail-3-895925799-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jan 2 4:20:44 2003 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F401B37B401 for ; Thu, 2 Jan 2003 04:20:42 -0800 (PST) Received: from pasiphae.parad.net (pcp991894pcs.nchrls01.sc.comcast.net [68.59.35.253]) by mx1.FreeBSD.org (Postfix) with ESMTP id E21CE43EC5 for ; Thu, 2 Jan 2003 04:20:41 -0800 (PST) (envelope-from jdisher@parad.net) Received: from localhost (jdisher@localhost) by pasiphae.parad.net (8.10.2/8.10.2) with ESMTP id h02CKea20855 for ; Thu, 2 Jan 2003 07:20:41 -0500 Date: Thu, 2 Jan 2003 07:20:40 -0500 (EST) From: Jonathan Disher X-X-Sender: jdisher@pasiphae To: freebsd-net@FreeBSD.ORG Subject: Re: Redundant NIC/Connections In-Reply-To: <02B3D733-1E07-11D7-9808-0003930B3DA4@tamu.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, 1 Jan 2003, David J Duchscher wrote: > >> >I was wondering how people are handling redundant connections? We > >> >would like to have dual NICs in the FreeBSD box with each NIC > >> connected > >> >to a different switch. Both switches are in the same broadcast > >> domain. > >> >In pointers, hints on this may done would be greatly appreciated. > > > > I think one of my colleagues responded directly to the poster. We do > > it by a daemon he wrote that monitors interface link status, and also > > pingability of default gateways, and reconfigures interfaces in event > > of a failure, based on the normal configuration file settings > > (/etc/rc.conf) > > > > Instantly in event of link loss; after a few seconds of retrying in > > event of router loss (we use HSRP addresses for routers.) > > Yes, I got a few responses including the one mentioned above. Lack of > time and changing priorities has prevented me from following up on > them. Anshuman Kanwar did mentioned he might release his solution as > open source if there was interest. I am at least interested in > reviewing it. I just need to find the time. I would also be very interested in this. We could write our own, but I'd much rather burn that time working on other projects ;-). Did Anshuman happen to mention what it's written in? Perl? C? other? -j To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jan 2 6: 6:51 2003 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B432437B401 for ; Thu, 2 Jan 2003 06:06:49 -0800 (PST) Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by mx1.FreeBSD.org (Postfix) with ESMTP id C38D343F28 for ; Thu, 2 Jan 2003 06:06:48 -0800 (PST) (envelope-from pekka.nikander@nomadiclab.com) Received: from nomadiclab.com (polle.local.nikander.com [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 69FF11C for ; Thu, 2 Jan 2003 16:15:03 +0200 (EET) Message-ID: <3E144753.7020905@nomadiclab.com> Date: Thu, 02 Jan 2003 16:06:11 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.3b) Gecko/20021230 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@FreeBSD.ORG Subject: IPsec / ipfw interaction in 4.7-STABLE: a proposed change Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org A fairly recent change in 4.7-STABLE modified the way IPsec ESP tunneled packets are handled by the ipfw code. There was a brief thread on this at the freebsd-stable mailing list in the end of November, see for example http://docs.freebsd.org/cgi/getmsg.cgi?fetch=270433+0+archive/2002/freebsd-stable/20021201.freebsd-stable Earlier on packets received from an ESP tunnel were passed directly up; now they are processed again by ipfw. An example of worked fine before: # ipfw show 00100 allow esp from XX.XX.XX.XX to MY.IP.ADD.RRS in recv xl0 00110 allow esp from MY.IP.ADD.RRS to XX.XX.XX.XX out xmit xl0 00200 deny ip from 192.168.0.0/24 to 192.168.0.0/24 via xl0 # setkey -DP 192.168.0.192/29 192.168.0.0/24 any in ipsec esp/tunnel/XX.XX.XX.XX-MY.IP.ADD.RRS/require 192.168.0.0/24 192.168.0.192/29 any out ipsec esp/tunnel/MY.IP.ADD.RRS-XX.XX.XX.XX/require Under the old behaviour the ipfw rule 200 explicitly forbid unprotected traffic using the tunneled addresses from getting out or in via the external interface, xl0. This rule can't be used any more, since now it blocks incoming traffic, and it must be replaced by something that allows incoming traffic from the tunnel. Thus, the change has the undesired side effect that it is now impossible to use ipfw to protect the tunnel end-point from traffic that looks like coming from the tunnel but does not come after all. From the security point of view this does not matter so much, since the IPsec code is taking care of the protection and dropping those packets. However, in the case where the IPsec policies get screwed up (e.g. due to racoon failure...) security may be somewhat weaker than before. At the stable -list someone suggested for a fix where the packets coming from the ESP tunnel would be changed so that they look like coming grom another interface. A proper fix would probably require a real "esp" pseudo-interface, but that should be carefully considered and tested to see that routing etc. would work fine. Now, as a small step to that direction I made the following small hack to netinet6/esp_input.c It changes the ESP tunneled packets to look like they were coming from the loopback interface. And it works like charm. However, this is not a proper fix, and a better one might be to increment NLOOP and use loif[1] instead of loif[0]. Opinions? --Pekka Nikander --- esp_input.c.orig Mon Aug 26 03:09:03 2002 +++ esp_input.c Thu Jan 2 15:40:25 2003 @@ -404,6 +404,9 @@ splx(s); goto bad; } + /* XXX: Interface hack by pnr */ + m->m_pkthdr.rcvif = loif; + /* XXX: End of interface hack by pnr */ IF_ENQUEUE(&ipintrq, m); m = NULL; schednetisr(NETISR_IP); /* can be skipped but to make sure */ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jan 2 7: 5:39 2003 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 44C0D37B401 for ; Thu, 2 Jan 2003 07:05:38 -0800 (PST) Received: from relay2.mecon.ar (relay2.mecon.ar [168.101.16.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id 99A8943EC2 for ; Thu, 2 Jan 2003 07:05:36 -0800 (PST) (envelope-from fernando@mecon.gov.ar) Received: from raimundo.mecon.ar (raimundo.mecon.ar [168.101.128.100]) by relay2.mecon.ar (8.12.6/8.12.6) with ESMTP id h02F5ZN6095333 for ; Thu, 2 Jan 2003 12:05:35 -0300 (ART) (envelope-from fernando@mecon.gov.ar) Received: from bal740r0.mecon.gov.ar (ramses.mecon.ar [172.26.128.11]) by raimundo.mecon.ar (8.11.3/8.8.5) with ESMTP id h02F5TZ50591 for ; Thu, 2 Jan 2003 12:05:29 -0300 (ART) Received: from bal740r0.mecon.gov.ar (localhost [127.0.0.1]) by bal740r0.mecon.gov.ar (8.12.6/8.12.6) with ESMTP id h02EnBvQ000752; Thu, 2 Jan 2003 11:49:11 -0300 (ART) (envelope-from fernando@mecon.gov.ar) Received: (from fpscha@localhost) by bal740r0.mecon.gov.ar (8.12.6/8.12.6/Submit) id h02EnBNi000751; Thu, 2 Jan 2003 11:49:11 -0300 (ART) (envelope-from fernando@mecon.gov.ar) X-Authentication-Warning: bal740r0.mecon.gov.ar: fpscha set sender to fernando@mecon.gov.ar using -f Date: Thu, 2 Jan 2003 11:49:11 -0300 From: Fernando Schapachnik To: freebsd-net@freebsd.org Subject: Routing and Zebra Message-ID: <20030102144911.GG250@bal740r0.mecon.gov.ar> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-OS: FreeBSD 4.7 - http://www.freebsd.org Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, First of all, forgive me if my question is off-topic. I could have tried -questions but was afraid that is was kind of very specific. To the point: Two machines running 4.7, A and B, connected to the same switch. Both running zebra. When A is turned off, B receives A's traffic (which is normal as the switch needs to flood packets after a while): TCPdump on B: Source MAC: a router's MAC (on the same LAN) Dest. MAC: A's MAC Source IP: someplace in the net Dest. IP: A's IP To my surprise B tries to forwards the packet to A, which AFAIK shouldn't because it doesn't have the right destination MAC. Of course there is no VRRP or anything else. Is this a known behavior? Would it be Zebra? Thanks in advance for any help! Fernando. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jan 2 7:21:33 2003 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5D55237B401 for ; Thu, 2 Jan 2003 07:21:31 -0800 (PST) Received: from snowflake.hexanet.fr (snowflake.hexanet.fr [81.23.32.32]) by mx1.FreeBSD.org (Postfix) with ESMTP id 404FB43EA9 for ; Thu, 2 Jan 2003 07:21:30 -0800 (PST) (envelope-from y.grossel@hexanet.fr) Received: from snowflake (snowflake [127.0.0.1]) by snowflake.hexanet.fr (Postfix) with SMTP id 6A36111E9; Thu, 2 Jan 2003 16:21:29 +0100 (CET) Date: Thu, 2 Jan 2003 16:21:29 +0100 From: =?ISO-8859-1?Q?=E9=E9?= Yann GROSSEL =?ISO-8859-1?Q?=E9=E9=E9?= To: Fernando Schapachnik Cc: freebsd-net@freebsd.org Subject: Re: Routing and Zebra Message-Id: <20030102162129.3fd99449.y.grossel@hexanet.fr> In-Reply-To: <20030102144911.GG250@bal740r0.mecon.gov.ar> References: <20030102144911.GG250@bal740r0.mecon.gov.ar> Organization: Hexanet X-Mailer: Sylpheed version 0.8.8 (GTK+ 1.2.10; i386-debian-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, 2 Jan 2003 11:49:11 -0300 Fernando Schapachnik wrote: > Hi, > First of all, forgive me if my question is off-topic. I could have > tried -questions but was afraid that is was kind of very specific. > > To the point: Two machines running 4.7, A and B, connected to the > same > switch. Both running zebra. When A is turned off, B receives A's traffic > (which is normal as the switch needs to flood packets after a while): > > TCPdump on B: > > Source MAC: a router's MAC (on the same LAN) > Dest. MAC: A's MAC > Source IP: someplace in the net > Dest. IP: A's IP > > To my surprise B tries to forwards the packet to A, which AFAIK > shouldn't because it doesn't have the right destination MAC. Of course > there is no VRRP or anything else. > > Is this a known behavior? Would it be Zebra? > > Thanks in advance for any help! Hi, I posted a few hours ago in freebsd-questions a problem that seems very similar to yours ("promiscuous mode / strange ethernet packets duplication problem"). I too have Zebra running on my machines. Have you checked that the ethernet interface of your B machine is not in promiscuous mode for an unknown reason ? We have several FreeBSD 4.7 boxes that automatically put all their interfaces into promiscuous mode during the boot process. Does anybody knows how to prevent that from happening ? Regards Yann -- Yann GROSSEL Email: y.grossel@hexanet.fr HEXANET NOC URL: http://www.hexanet.fr/ Tel: +33 (0)3 26 79 30 05 Fax: +33 (0)3 26 79 30 06 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jan 2 7:26:20 2003 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C5DB537B401 for ; Thu, 2 Jan 2003 07:26:17 -0800 (PST) Received: from vbook.express.ru (asplinux.ru [195.133.213.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id B4B8043EA9 for ; Thu, 2 Jan 2003 07:26:16 -0800 (PST) (envelope-from vova@sw.ru) Received: from vova by vbook.express.ru with local (Exim 4.10) id 18U7Eb-0000tS-00; Thu, 02 Jan 2003 18:26:13 +0300 Subject: Re: Routing and Zebra From: "Vladimir B. " Grebenschikov To: Fernando Schapachnik Cc: freebsd-net@freebsd.org In-Reply-To: <20030102144911.GG250@bal740r0.mecon.gov.ar> References: <20030102144911.GG250@bal740r0.mecon.gov.ar> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Organization: TSB "Russian Express" Message-Id: <1041521170.2104.2.camel@vbook.fbsd.ru> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 02 Jan 2003 18:26:12 +0300 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org =F7 Thu, 02.01.2003, =D7 17:49, Fernando Schapachnik =CE=C1=D0=C9=D3=C1=CC: > Hi, > First of all, forgive me if my question is off-topic. I could have > tried -questions but was afraid that is was kind of very specific. >=20 > To the point: Two machines running 4.7, A and B, connected to the same > switch. Both running zebra. When A is turned off, B receives A's traffic > (which is normal as the switch needs to flood packets after a while): >=20 > TCPdump on B: >=20 > Source MAC: a router's MAC (on the same LAN) > Dest. MAC: A's MAC > Source IP: someplace in the net > Dest. IP: A's IP >=20 > To my surprise B tries to forwards the packet to A, which AFAIK > shouldn't because it doesn't have the right destination MAC. Of course th= ere is > no VRRP or anything else. >=20 > Is this a known behavior? Would it be Zebra? >=20 > Thanks in advance for any help! There was bug in zebra, it allows promosq. mode on interface so host begin catch all traffic as its own.=20 (You can check this by ifconfig) This was fixed 2002/10/07. > Fernando. >=20 > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message --=20 Vladimir B. Grebenschikov TSB "Russian Express" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jan 2 7:42: 4 2003 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EA71237B401 for ; Thu, 2 Jan 2003 07:42:03 -0800 (PST) Received: from brisefer.cediti.be (porquepix.cediti.be [213.189.188.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id B5F6943E4A for ; Thu, 2 Jan 2003 07:42:02 -0800 (PST) (envelope-from Olivier.Cherrier@cediti.be) Received: by brisefer.nat.cediti.be with Internet Mail Service (5.5.2653.19) id ; Thu, 2 Jan 2003 16:40:32 +0100 Message-ID: From: Olivier Cherrier To: freebsd-net@FreeBSD.ORG Subject: ipfw man page Date: Thu, 2 Jan 2003 16:40:31 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello, In the ipfw man page, we can read: "To ease configuration, rules can be put into a file which is processed using ipfw as shown in the first synopsis line." Shouldn't be the 'last synopsis line' ? Thanks. oc To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jan 2 8:42:15 2003 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7B44737B401 for ; Thu, 2 Jan 2003 08:42:14 -0800 (PST) Received: from mail.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4897343ED8 for ; Thu, 2 Jan 2003 08:42:10 -0800 (PST) (envelope-from don@sandvine.com) Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19) id ; Thu, 2 Jan 2003 11:42:09 -0500 Message-ID: From: Don Bowman To: freebsd-net@FreeBSD.ORG Subject: RE: Redundant NIC/Connections Date: Thu, 2 Jan 2003 11:42:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > From: Jonathan Disher [mailto:jdisher@parad.net] > On Wed, 1 Jan 2003, David J Duchscher wrote: > > > >> >I was wondering how people are handling redundant > connections? We > > >> >would like to have dual NICs in the FreeBSD box with each NIC > > >> connected > > >> >to a different switch. Both switches are in the same broadcast > > >> domain. > > >> >In pointers, hints on this may done would be greatly > appreciated. > > > > > > I think one of my colleagues responded directly to the > poster. We do > > > it by a daemon he wrote that monitors interface link > status, and also > > > pingability of default gateways, and reconfigures > interfaces in event > > > of a failure, based on the normal configuration file settings > > > (/etc/rc.conf) > > > > > > Instantly in event of link loss; after a few seconds of > retrying in > > > event of router loss (we use HSRP addresses for routers.) > > > > Yes, I got a few responses including the one mentioned > above. Lack of > > time and changing priorities has prevented me from following up on > > them. Anshuman Kanwar did mentioned he might release his > solution as > > open source if there was interest. I am at least interested in > > reviewing it. I just need to find the time. > > I would also be very interested in this. We could write our > own, but I'd > much rather burn that time working on other projects ;-). > > Did Anshuman happen to mention what it's written in? Perl? C? other? I wonder if the VRRP (http://www.bsdshell.net/hut_fvrrpd.html) can help here. its available as a port. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jan 2 9:35:22 2003 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3F46837B401 for ; Thu, 2 Jan 2003 09:35:21 -0800 (PST) Received: from musique.teaser.net (musique.teaser.net [213.91.2.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id ECF2C43EA9 for ; Thu, 2 Jan 2003 09:35:19 -0800 (PST) (envelope-from e-masson@kisoft-services.com) Received: from notbsdems.nantes.kisoft-services.com (nantes.kisoft-services.com [193.56.60.243]) by musique.teaser.net (Postfix) with ESMTP id CF9C7725C8 for ; Thu, 2 Jan 2003 18:35:08 +0100 (CET) Received: by notbsdems.nantes.kisoft-services.com (Postfix, from userid 1001) id 7884F5A7A8; Thu, 2 Jan 2003 18:34:56 +0100 (CET) To: Mailing List FreeBSD Network Subject: Re: mpd only let outbound packets flowing From: Eric Masson In-Reply-To: <868yy56drm.fsf@notbsdems.nantes.kisoft-services.com> (Eric Masson's message of "Tue, 31 Dec 2002 23:10:21 +0100") References: <86hect6g0w.fsf@notbsdems.nantes.kisoft-services.com> <868yy56drm.fsf@notbsdems.nantes.kisoft-services.com> X-Operating-System: FreeBSD 4.7-STABLE i386 Date: Thu, 02 Jan 2003 18:34:56 +0100 Message-ID: <86ptrf1mm7.fsf@notbsdems.nantes.kisoft-services.com> User-Agent: Gnus/5.090008 (Oort Gnus v0.08) XEmacs/21.4 (Common Lisp, i386--freebsd) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >>>>> "Emss" == Eric Masson writes: Emss> Followup to myself, sorry Once more, Braino on my side, ipnat configuration file hasn't been updated to the new interface, sorry for the noise. Eric Masson PS: mpd works damn fine here, thanks to Archie & Julian -- Lu sur linux.wine.users : > I have a bottle of Haut Medoc from 1971 and wondered if anyone on this BB > could advise as to possible value and drinkability. -+- PB in Guide du linuxien pervers - "Important ça, la drinkability !" -+- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jan 2 10:34:23 2003 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6D95237B426 for ; Thu, 2 Jan 2003 10:34:21 -0800 (PST) Received: from relay2.mecon.ar (relay2.mecon.ar [168.101.16.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id E1D3A43EB2 for ; Thu, 2 Jan 2003 10:34:17 -0800 (PST) (envelope-from fernando@mecon.gov.ar) Received: from racing.mecon.ar (racing.mecon.ar [168.101.133.15]) by relay2.mecon.ar (8.12.6/8.12.6) with ESMTP id h02IYGN6017060 for ; Thu, 2 Jan 2003 15:34:16 -0300 (ART) (envelope-from fernando@mecon.gov.ar) Received: from racing.mecon.ar (meyosp.mecon.gov.ar [10.11.0.149]) by racing.mecon.ar (8.11.1/8.8.5) with ESMTP id h02IYBF19460 for ; Thu, 2 Jan 2003 15:34:11 -0300 (ART) Received: from bal740r0.mecon.gov.ar (bal740r0.mecon.ar [10.11.1.11]) by racing.mecon.ar (8.11.1/8.8.5) with ESMTP id h02IYAS19446 for ; Thu, 2 Jan 2003 15:34:10 -0300 (ART) Received: from bal740r0.mecon.gov.ar (localhost [127.0.0.1]) by bal740r0.mecon.gov.ar (8.12.6/8.12.6) with ESMTP id h02FY1AV001110; Thu, 2 Jan 2003 12:34:01 -0300 (ART) (envelope-from fernando@mecon.gov.ar) Received: (from fpscha@localhost) by bal740r0.mecon.gov.ar (8.12.6/8.12.6/Submit) id h02FY1kn001109; Thu, 2 Jan 2003 12:34:01 -0300 (ART) (envelope-from fernando@mecon.gov.ar) X-Authentication-Warning: bal740r0.mecon.gov.ar: fpscha set sender to fernando@mecon.gov.ar using -f Date: Thu, 2 Jan 2003 12:34:00 -0300 From: Fernando Schapachnik To: "Vladimir B. Grebenschikov" Cc: freebsd-net@freebsd.org Subject: Re: Routing and Zebra Message-ID: <20030102153400.GL250@bal740r0.mecon.gov.ar> References: <20030102144911.GG250@bal740r0.mecon.gov.ar> <1041521170.2104.2.camel@vbook.fbsd.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1041521170.2104.2.camel@vbook.fbsd.ru> User-Agent: Mutt/1.4i X-OS: FreeBSD 4.7 - http://www.freebsd.org Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org En un mensaje anterior, Vladimir B. Grebenschikov escribió: > There was bug in zebra, it allows promosq. mode on interface > so host begin catch all traffic as its own. > (You can check this by ifconfig) > > > This was fixed 2002/10/07. Thanks! I've just posted saying it was not in promiscuous mode, but I misread the ifconfig flags! That's it. Thank you. Regards. Fernando. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jan 2 10:34:25 2003 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8B04F37B4F6 for ; Thu, 2 Jan 2003 10:34:21 -0800 (PST) Received: from relay2.mecon.ar (relay2.mecon.ar [168.101.16.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id E1B9B43EA9 for ; Thu, 2 Jan 2003 10:34:17 -0800 (PST) (envelope-from fernando@mecon.gov.ar) Received: from racing.mecon.ar (racing.mecon.ar [168.101.133.15]) by relay2.mecon.ar (8.12.6/8.12.6) with ESMTP id h02IYGN6017062 for ; Thu, 2 Jan 2003 15:34:16 -0300 (ART) (envelope-from fernando@mecon.gov.ar) Received: from racing.mecon.ar (meyosp.mecon.gov.ar [10.11.0.149]) by racing.mecon.ar (8.11.1/8.8.5) with ESMTP id h02IYBF19479 for ; Thu, 2 Jan 2003 15:34:11 -0300 (ART) Received: from bal740r0.mecon.gov.ar (bal740r0.mecon.ar [10.11.1.11]) by racing.mecon.ar (8.11.1/8.8.5) with ESMTP id h02IYBS19455 for ; Thu, 2 Jan 2003 15:34:11 -0300 (ART) Received: from bal740r0.mecon.gov.ar (localhost [127.0.0.1]) by bal740r0.mecon.gov.ar (8.12.6/8.12.6) with ESMTP id h02FVpAV001099; Thu, 2 Jan 2003 12:31:51 -0300 (ART) (envelope-from fernando@mecon.gov.ar) Received: (from fpscha@localhost) by bal740r0.mecon.gov.ar (8.12.6/8.12.6/Submit) id h02FVphP001098; Thu, 2 Jan 2003 12:31:51 -0300 (ART) (envelope-from fernando@mecon.gov.ar) X-Authentication-Warning: bal740r0.mecon.gov.ar: fpscha set sender to fernando@mecon.gov.ar using -f Date: Thu, 2 Jan 2003 12:31:51 -0300 From: Fernando Schapachnik To: =?iso-8859-1?B?6ekgWWFubiBHUk9TU0VMIOnp6Q==?= Cc: freebsd-net@freebsd.org Subject: Re: Routing and Zebra Message-ID: <20030102153151.GK250@bal740r0.mecon.gov.ar> References: <20030102144911.GG250@bal740r0.mecon.gov.ar> <20030102162129.3fd99449.y.grossel@hexanet.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20030102162129.3fd99449.y.grossel@hexanet.fr> User-Agent: Mutt/1.4i X-OS: FreeBSD 4.7 - http://www.freebsd.org Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org En un mensaje anterior, éé Yann GROSSEL ééé escribió: > Have you checked that the ethernet interface of your B machine is not > in promiscuous mode for an unknown reason ? No, B doesn't go into promiscuous mode, at least from what ifconfig and messages tell. > > > We have several FreeBSD 4.7 boxes that automatically put all their > interfaces into promiscuous mode during the boot process. Does anybody > knows how to prevent that from happening ? Mmmm... Seems like a trojan that acts on boot. Is that possible? Thanks & regards. Fernando. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jan 2 12:22:51 2003 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C769E37B401 for ; Thu, 2 Jan 2003 12:22:49 -0800 (PST) Received: from musique.teaser.net (musique.teaser.net [213.91.2.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7164743ED1 for ; Thu, 2 Jan 2003 12:22:48 -0800 (PST) (envelope-from e-masson@kisoft-services.com) Received: from notbsdems.nantes.kisoft-services.com (nantes.kisoft-services.com [193.56.60.243]) by musique.teaser.net (Postfix) with ESMTP id 23FE1725E6; Thu, 2 Jan 2003 21:22:42 +0100 (CET) Received: by notbsdems.nantes.kisoft-services.com (Postfix, from userid 1001) id 639BD5A7C7; Thu, 2 Jan 2003 21:22:27 +0100 (CET) To: Pekka Nikander Cc: freebsd-net@FreeBSD.ORG Subject: Re: IPsec / ipfw interaction in 4.7-STABLE: a proposed change From: Eric Masson In-Reply-To: <3E144753.7020905@nomadiclab.com> (Pekka Nikander's message of "Thu, 02 Jan 2003 16:06:11 +0200") References: <3E144753.7020905@nomadiclab.com> X-Operating-System: FreeBSD 4.7-STABLE i386 Date: Thu, 02 Jan 2003 21:22:26 +0100 Message-ID: <86k7hnz4hp.fsf@notbsdems.nantes.kisoft-services.com> User-Agent: Gnus/5.090008 (Oort Gnus v0.08) XEmacs/21.4 (Common Lisp, i386--freebsd) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >>>>> "Pekka" == Pekka Nikander writes: Pekka> Now, as a small step to that direction I made the following Pekka> small hack to netinet6/esp_input.c It changes the ESP tunneled Pekka> packets to look like they were coming from the loopback Pekka> interface. And it works like charm. However, this is not a Pekka> proper fix, and a better one might be to increment NLOOP and use Pekka> loif[1] instead of loif[0]. Opinions? Seems pretty close to what OpenBSD has implemented, except they don't use the stock loopback interface. Their enc(4) driver is a software loopback interface : http://www.openbsd.org/cgi-bin/man.cgi?query=enc&sektion=4&arch=i386&apropos=0&manpath=OpenBSD+Current It's used in src/sys/netinet/ipsec_input.c to impersonate the incoming interface just as you did in your patch. I'd like to know whether there would be any interest in associating a different interface to each incoming SPD entry or just use only one interface for all incoming SPD entries ? Regards Eric Masson -- «Comme annoncé dans fr.usenet.forums.annonces récemment, le vote pour la destruction/remplacement du groupe fr.comp.os.linux a reussi et est donc detruit.» -+- Control in Guide du linuxien pervers - "BSD a encore frappé" -+- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jan 2 12:29:54 2003 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B954937B401 for ; Thu, 2 Jan 2003 12:29:52 -0800 (PST) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 449C243EC5 for ; Thu, 2 Jan 2003 12:29:52 -0800 (PST) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (IDENT:brdavis@localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.12.3/8.12.3) with ESMTP id h02KTg8r028006; Thu, 2 Jan 2003 12:29:42 -0800 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.3/8.12.3/Submit) id h02KTfC3028005; Thu, 2 Jan 2003 12:29:41 -0800 Date: Thu, 2 Jan 2003 12:29:41 -0800 From: Brooks Davis To: Pekka Nikander Cc: freebsd-net@FreeBSD.ORG Subject: Re: IPsec / ipfw interaction in 4.7-STABLE: a proposed change Message-ID: <20030102122941.A27618@Odin.AC.HMC.Edu> References: <3E144753.7020905@nomadiclab.com> <86k7hnz4hp.fsf@notbsdems.nantes.kisoft-services.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="8t9RHnE3ZwKMSgU+" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <86k7hnz4hp.fsf@notbsdems.nantes.kisoft-services.com>; from e-masson@kisoft-services.com on Thu, Jan 02, 2003 at 09:22:26PM +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) on odin.ac.hmc.edu Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --8t9RHnE3ZwKMSgU+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [Sorry to reply to the wrong message, but I missed this earlier.] On Thu, Jan 02, 2003 at 09:22:26PM +0100, Eric Masson wrote: > >>>>> "Pekka" =3D=3D Pekka Nikander write= s: >=20 > Pekka> Now, as a small step to that direction I made the following > Pekka> small hack to netinet6/esp_input.c It changes the ESP tunneled > Pekka> packets to look like they were coming from the loopback > Pekka> interface. And it works like charm. However, this is not a > Pekka> proper fix, and a better one might be to increment NLOOP and use > Pekka> loif[1] instead of loif[0]. Opinions? loif[] is evil and its use should not be extended. In any case, NLOOP no longer exists in current since loopback interfaces are clonable. If you didn't want to adopt OpenBSD's enc interface, an alternate solution might be to set up an ioctl to allow you to register the interface you want to have these packets come from. -- 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 --8t9RHnE3ZwKMSgU+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE+FKE1XY6L6fI4GtQRAryQAKDWd6qp2gftEPCDoq1XjKDSOYrPIQCguWcP snQ9MD3kDF4Uim2forTvTn4= =CgJI -----END PGP SIGNATURE----- --8t9RHnE3ZwKMSgU+-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jan 2 12:33:59 2003 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BE17E37B401 for ; Thu, 2 Jan 2003 12:33:56 -0800 (PST) Received: from 66-162-33-178.gen.twtelecom.net (66-162-33-178.gen.twtelecom.net [66.162.33.178]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4448E43EC5 for ; Thu, 2 Jan 2003 12:33:56 -0800 (PST) (envelope-from jeff@expertcity.com) Received: from [10.4.1.134] (helo=expertcity.com) by 66-162-33-178.gen.twtelecom.net with esmtp (Exim 3.22 #4) id 18UC2H-0006dd-00; Thu, 02 Jan 2003 12:33:49 -0800 Message-ID: <3E14A22B.5070203@expertcity.com> Date: Thu, 02 Jan 2003 12:33:47 -0800 From: Jeff Behl User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mike Silbersack Cc: freebsd-net Subject: Re: when are mbuf clusters released? References: <3E108C31.9060403@expertcity.com> <20021230132145.N22880-100000@patrocles.silby.com> In-Reply-To: <20021230132145.N22880-100000@patrocles.silby.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Thanks for the info. Could you explain how mbuf clusters and mbufs are related? i'd like to better understand how we can run out of one and not the other. also, is there an upper value for mbuf clusters that we should be wary of? again, the tuning page is quite vague on this. 64000 seems to not do the trick so i was thinking of 2X this. we have plenty of memory (1GB and the machine only runs apache). for those interested, we think we've found why we're getting lots of connections in FIN_WAIT_1 state...it appears to be some sort of odd/bad interaction between IE and flash (we think). these machines serve popup adds (sorry!), and we're guessing that when a user with a slower connection gets one of these pop-ups and kills the window before the flash file is done downloading, IE leaves the socket open...sorta, and here's where it gets interesting. it leaves it open, but closes the window (sets it to 0)...or is the plugin doing this? apache is done sending data and considers the conenction closed, so its client timeout feature never comes into play. but there is still data in the sendq, including the FIN, we believe. BSD obeys the spec (unfortunately) and keeps probing to see if the window has opened so it can transmit the last of the data. this goes on indefinitely! so we get gobs connections stuck in fin_wait_1. interestingly, we have a solaris machine serving the same purpose and it does not have the problem. it seems to not folluw the rfc and silently closes the conenction after a number of tries when a socket is in fin_wait_1. these seems more reasonable to me. this seems (as i've read from other posts as well) quite an opportunity for a DoS attack....just keep advertising a window of 0. a single client could easily tie everything up in fin_wait_1... anyone think of a workaround (besides not serving pop-ups :) jeff Mike Silbersack wrote: > On Mon, 30 Dec 2002, Jeff Behl wrote: > > >>5066/52544/256000 mbufs in use (current/peak/max): >>5031/50612/64000 mbuf clusters in use (current/peak/max) >> >>is there some strange interaction going on between apace2 and bsd? >>killing apache caused the mbuf clusters to start draining, but only >>slowly. will clusters still be allocated in FIN_WAIT_? states? TIME_WAIT? > > > Before I answer your question, let me explain how clusters are allocated. > The first number above shows how many are in use at the moment. The > second number shows how many have been used, and are currently allocated. > The third is the limit you have set. > > What this means is that once an mbuf (or cluster) has been allocated, it > is never truly freed, only returned to the free list. As a result, after > your spike in mbuf usage, you never really get the memory back. However, > this may be OK if you have plenty of ram. > > >>This maching was serving a couple hundred connections a second...which >>doesn't seem like it should have taxed it much (p3 1.2 gHz). CPU util >>was low. >> >>Any help appreciated. >> >>Jeff > > > Now, on to why the value spiked. Yes, connections in FIN_WAIT* states > still hang on to mbuf clusters relating to the data they have been asked > to send. There was a DoS script going around which intentionally stuck > many sockets on a server in the FIN_WAIT_2 state until enough had been > stuck to cause mbuf cluster exhaustion. To determine if this is the case, > just run netstat -n and look at the sendq value; if you see high sendq > values on a lot of sockets, this may be your answer. > > The other possibility is that you're being hit with lots of IP > fragments... currently, the IP reassembly code allows too many unassembled > packets to sit around. There's no way to inspect the IP reassembly queue > actively, but you could use netstat -s to see "fragments received" - if > the number is high, then it's likely something is up. > > Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jan 2 12:50:45 2003 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B3F4337B401 for ; Thu, 2 Jan 2003 12:50:44 -0800 (PST) Received: from mail.utcorp.com (mail.utcorp.com [146.145.135.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0417743EC2 for ; Thu, 2 Jan 2003 12:50:43 -0800 (PST) (envelope-from kseel@utcorp.com) Received: from utcorp.com (shorty30.khome.utcorp.net [10.200.1.30]) by mail.utcorp.com (8.12.6/8.11.6) with ESMTP id h02LOK9k094532 for ; Thu, 2 Jan 2003 21:24:21 GMT (envelope-from kseel@utcorp.com) Message-ID: <3E14A60D.9000704@utcorp.com> Date: Thu, 02 Jan 2003 15:50:21 -0500 From: kseel User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20020906 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Quad ethernet question Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Anyone using one of these? http://www.corpsys.com/store/prodinfo.asp?number=ANA6944&variation=&aitem=60&mitem=62 If so, is the performance good? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jan 2 14:36:17 2003 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D251F37B401; Thu, 2 Jan 2003 14:36:16 -0800 (PST) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 322AA43EA9; Thu, 2 Jan 2003 14:36:16 -0800 (PST) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.12.6/8.12.6) with ESMTP id h02MaFro029301 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 2 Jan 2003 17:36:15 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id h02MaAh48780; Thu, 2 Jan 2003 17:36:10 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15892.48858.553808.84435@grasshopper.cs.duke.edu> Date: Thu, 2 Jan 2003 17:36:10 -0500 (EST) To: freebsd-smp@freebsd.org Cc: freebsd-net@freebsd.org Subject: SMP status of networking subsystem? X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Just a quick question.. Where do we stand on bringing the networking subsystem out from under Giant? The mbuf system is soon to be safe, thanks to Alan Cox, so this allows INTR_MPSAFE drivers. However, swi:net is still under Giant, as are many of the important socket functions (sendto(), recvfrom(), etc). Thanks, Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jan 2 16:11:58 2003 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 66A7937B401; Thu, 2 Jan 2003 16:11:57 -0800 (PST) Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 06DCD43E4A; Thu, 2 Jan 2003 16:11:57 -0800 (PST) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by rwcrmhc53.attbi.com (rwcrmhc53) with ESMTP id <2003010300115605300k6r7ne>; Fri, 3 Jan 2003 00:11:56 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id QAA68846; Thu, 2 Jan 2003 16:11:55 -0800 (PST) Date: Thu, 2 Jan 2003 16:11:54 -0800 (PST) From: Julian Elischer To: Andrew Gallatin Cc: freebsd-smp@freebsd.org, freebsd-net@freebsd.org Subject: Re: SMP status of networking subsystem? In-Reply-To: <15892.48858.553808.84435@grasshopper.cs.duke.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, 2 Jan 2003, Andrew Gallatin wrote: > > Just a quick question.. Where do we stand on bringing the networking > subsystem out from under Giant? > > The mbuf system is soon to be safe, thanks to Alan Cox, so this allows > INTR_MPSAFE drivers. However, swi:net is still under Giant, as are > many of the important socket functions (sendto(), recvfrom(), etc). netgraph has been partly done for a while but I need to do some more to complete it.. I need to add an 'MP-safe' timer/callback fascility (that can be used instead of nodes rolling hteir own and I need a fascility to assit hardware-triggered events queue data to the netgraph part of themselves, (i.e. move under the netgraph umbrella). > > Thanks, > > Drew > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jan 2 22: 7:41 2003 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5175637B405 for ; Thu, 2 Jan 2003 22:07:37 -0800 (PST) Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F78B43ED8 for ; Thu, 2 Jan 2003 22:07:36 -0800 (PST) (envelope-from higgsr@rpi.edu) Received: from webmail.rpi.edu (webmail.rpi.edu [128.113.26.21]) by mail.rpi.edu (8.12.1/8.12.1) with ESMTP id h0367Uut214646; Fri, 3 Jan 2003 01:07:30 -0500 Message-Id: <200301030607.h0367Uut214646@mail.rpi.edu> Content-Type: text/plain Content-Disposition: inline To: freebsd-net@FreeBSD.org From: higgsr@rpi.edu Cc: jeff@expertcity.com X-Originating-Ip: 24.195.1.76 Mime-Version: 1.0 Reply-To: higgsr@rpi.edu Date: Fri, 03 Jan 2003 1:07:29 EST X-Mailer: EMUmail 4.00 Subject: Re: when are mbuf clusters released? X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Mbufs are data structures in the kernel. They contain information relating to data to be sent/received. Mbufs on my stable system are 256 bytes and mbuf clusters are 2048 bytes. I believe that there are 4 different types of mbufs and they are usually chained together, depending on the amount of data. The different mbufs 1.) internal data, packet header 2.) internal data, no packet header 3.) external data (mbuf cluster), packet header 4.) external data (mbuf cluster), no packet header All mbufs have an mbuf header (20 bytes) that occupies the first portion of the mbuf. This mbuf header describes the type of mbuf, has pointers to link mbufs together and to link mbuf chains together, etc. All mbuf chains have a packet header (24 bytes) in the first mbuf of the chain. Mbuf 1 would have an mbuf header, a packet header and then room for the data in transit (20 + 24 + 212 = 256 bytes). Mbuf 2 would have an mbuf header and then room for data in transit (20 + 236 = 256 bytes). Mbuf 3 would have an mbuf header, a packet header, an extended structure and unused space (20 + 24 + 16 + 196 = 256 bytes). Mbuf 4 would have an mbuf header, some wasted space, an extended structure and more wasted space (20 + 24 + 16 + 196 = 256 bytes). The gap (some wasted space) is because of the unions in the mbuf structure. When the data in transit is small (less than MINCLSIZE = 213), a single mbuf is used.**** When the data in transit is larger (>= MINCLSIZE = 213) mbufs of type 3 and 4 are used. The extended structure in the mbufs identifies the mbuf cluster holding the data in transit. So if you are send a lot of large messages, your system will use lots of mbuf clusters. I do not know why your mbuf clusters are not being returned to the free list. In the case of fragmentation, the IP code should be returning the mbufs and mbuf clusters to the free lists. When the datagram cannot be fully reconstructed, its fragment list should be dropped. I know I haven't answered all of your questions, but maybe I have given you more insight. Ray ****Not necessarily a single mbuf. For example, as the the mbuf gets passed down the the stack, a new mbuf is added in front of this one to in order to prepend the headers from the other layers (i.e. ethernet header, ip header, udp header, etc.) On Thu, 02 Jan 2003 12:33:47 -0800 Jeff Behl wrote: > Thanks for the info. Could you explain how mbuf clusters and mbufs are > related? i'd like to better understand how we can run out of one and > not the other. also, is there an upper value for mbuf clusters that we > should be wary of? again, the tuning page is quite vague on this. > 64000 seems to not do the trick so i was thinking of 2X this. we have > plenty of memory (1GB and the machine only runs apache). > > for those interested, we think we've found why we're getting lots of > connections in FIN_WAIT_1 state...it appears to be some sort of odd/bad > interaction between IE and flash (we think). these machines serve popup > adds (sorry!), and we're guessing that when a user with a slower > connection gets one of these pop-ups and kills the window before the > flash file is done downloading, IE leaves the socket open...sorta, and > here's where it gets interesting. it leaves it open, but closes the > window (sets it to 0)...or is the plugin doing this? apache is done > sending data and considers the conenction closed, so its client timeout > feature never comes into play. but there is still data in the sendq, > including the FIN, we believe. BSD obeys the spec (unfortunately) and > keeps probing to see if the window has opened so it can transmit the > last of the data. this goes on indefinitely! so we get gobs > connections stuck in fin_wait_1. interestingly, we have a solaris > machine serving the same purpose and it does not have the problem. it > seems to not folluw the rfc and silently closes the conenction after a > number of tries when a socket is in fin_wait_1. these seems more > reasonable to me. this seems (as i've read from other posts as well) > quite an opportunity for a DoS attack....just keep advertising a window > of 0. a single client could easily tie everything up in fin_wait_1... > > anyone think of a workaround (besides not serving pop-ups :) > > jeff > > > Mike Silbersack wrote: > > On Mon, 30 Dec 2002, Jeff Behl wrote: > > > > > >>5066/52544/256000 mbufs in use (current/peak/max): > >>5031/50612/64000 mbuf clusters in use (current/peak/max) > >> > >>is there some strange interaction going on between apace2 and bsd? > >>killing apache caused the mbuf clusters to start draining, but only > >>slowly. will clusters still be allocated in FIN_WAIT_? states? > TIME_WAIT? > > > > > > Before I answer your question, let me explain how clusters are > allocated. > > The first number above shows how many are in use at the moment. The > > second number shows how many have been used, and are currently > allocated. > > The third is the limit you have set. > > > > What this means is that once an mbuf (or cluster) has been allocated, > it > > is never truly freed, only returned to the free list. As a result, > after > > your spike in mbuf usage, you never really get the memory back. > However, > > this may be OK if you have plenty of ram. > > > > > >>This maching was serving a couple hundred connections a second...which > >>doesn't seem like it should have taxed it much (p3 1.2 gHz). CPU util > >>was low. > >> > >>Any help appreciated. > >> > >>Jeff > > > > > > Now, on to why the value spiked. Yes, connections in FIN_WAIT* states > > still hang on to mbuf clusters relating to the data they have been > asked > > to send. There was a DoS script going around which intentionally stuck > > many sockets on a server in the FIN_WAIT_2 state until enough had been > > stuck to cause mbuf cluster exhaustion. To determine if this is the > case, > > just run netstat -n and look at the sendq value; if you see high sendq > > values on a lot of sockets, this may be your answer. > > > > The other possibility is that you're being hit with lots of IP > > fragments... currently, the IP reassembly code allows too many > unassembled > > packets to sit around. There's no way to inspect the IP reassembly > queue > > actively, but you could use netstat -s to see "fragments received" - if > > the number is high, then it's likely something is up. > > > > Mike "Silby" Silbersack > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jan 3 1:13:43 2003 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0899837B401 for ; Fri, 3 Jan 2003 01:13:42 -0800 (PST) Received: from mx1.dev.itouchnet.net (devco.net [196.15.188.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 841A743EA9 for ; Fri, 3 Jan 2003 01:13:39 -0800 (PST) (envelope-from bvi@itouchlabs.com) Received: from nobody by mx1.dev.itouchnet.net with scanned_ok (Exim 3.35 #1) id 18UNwe-0006Hg-00 for freebsd-net@freebsd.org; Fri, 03 Jan 2003 11:16:48 +0200 X-TLS: TLSv1:RC4-MD5:128 devco.net -> mx1.dev.itouchnet.net Received: from devco.net ([196.15.188.2] helo=Beastie) by mx1.dev.itouchnet.net with esmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 18UNwd-0006HO-00; Fri, 03 Jan 2003 11:16:47 +0200 Message-ID: <014901c2b308$1be778a0$0b01a8c0@Beastie> From: "Barry Irwin" To: "kseel" , References: <3E14A60D.9000704@utcorp.com> Subject: Re: Quad ethernet question Date: Fri, 3 Jan 2003 11:11:32 +0200 Organization: iTouch Labs MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Checked: This message has been scanned for any virusses and unauthorized attachments. X-iScan-ID: 24154-1041585408-78802@unconfigured version $Name: REL_2_0_4 $ Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I have a similar card ( also adaptec 4 port) in a number of firewalls. FreeBSD uses the sf driver. Been running these for about 18 months with no hastles. Barry -- Barry Irwin bvi@itouchlabs.com Tel: +27214875178 Systems Administrator: Networks And Security iTouch TAS http://www.itouchlabs.com Mobile: +27824457210 ----- Original Message ----- From: "kseel" To: Sent: Thursday, January 02, 2003 10:50 PM Subject: Quad ethernet question > > Anyone using one of these? > http://www.corpsys.com/store/prodinfo.asp?number=ANA6944&variation=&aitem=60 &mitem=62 > If so, is the performance good? > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jan 3 1:46: 4 2003 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DFD4037B406 for ; Fri, 3 Jan 2003 01:46:02 -0800 (PST) Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9869543EC5 for ; Fri, 3 Jan 2003 01:46:01 -0800 (PST) (envelope-from pekka.nikander@nomadiclab.com) Received: from nomadiclab.com (polle.local.nikander.com [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 2B5D923; Fri, 3 Jan 2003 11:54:16 +0200 (EET) Message-ID: <3E155BB5.4000706@nomadiclab.com> Date: Fri, 03 Jan 2003 11:45:25 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.3b) Gecko/20021230 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brooks Davis Cc: freebsd-net@FreeBSD.ORG Subject: Re: IPsec / ipfw interaction in 4.7-STABLE: a proposed change References: <3E144753.7020905@nomadiclab.com> <86k7hnz4hp.fsf@notbsdems.nantes.kisoft-services.com> <20030102122941.A27618@Odin.AC.HMC.Edu> In-Reply-To: <20030102122941.A27618@Odin.AC.HMC.Edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Brooks Davis wrote: > loif[] is evil and its use should not be extended. In any case, NLOOP > no longer exists in current since loopback interfaces are clonable. If > you didn't want to adopt OpenBSD's enc interface, an alternate solution > might be to set up an ioctl to allow you to register the interface you > want to have these packets come from. OpenBSD enc sounds like the right choice, but I'm a bit worried about the amount of work involved in porting it. Handling incoming packets seems to be easy enough, but implementing the possibility of snooping outgoing packets may not be that easy... Now, out of curiosity, why do you consider loif[] evil? --Pekka Nikander To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jan 3 2: 5:27 2003 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5593737B401 for ; Fri, 3 Jan 2003 02:05:25 -0800 (PST) Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by mx1.FreeBSD.org (Postfix) with ESMTP id C2EA043EC2 for ; Fri, 3 Jan 2003 02:05:24 -0800 (PST) (envelope-from pekka.nikander@nomadiclab.com) Received: from nomadiclab.com (polle.local.nikander.com [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id BE37423; Fri, 3 Jan 2003 12:13:49 +0200 (EET) Message-ID: <3E15604B.3040505@nomadiclab.com> Date: Fri, 03 Jan 2003 12:04:59 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.3b) Gecko/20021230 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Masson Cc: freebsd-net@FreeBSD.ORG Subject: Re: IPsec / ipfw interaction in 4.7-STABLE: a proposed change References: <3E144753.7020905@nomadiclab.com> <86k7hnz4hp.fsf@notbsdems.nantes.kisoft-services.com> In-Reply-To: <86k7hnz4hp.fsf@notbsdems.nantes.kisoft-services.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Eric Masson wrote: > Seems pretty close to what OpenBSD has implemented, except they don't > use the stock loopback interface. > > Their enc(4) driver is a software loopback interface : > http://www.openbsd.org/cgi-bin/man.cgi?query=enc&sektion=4&arch=i386&apropos=0&manpath=OpenBSD+Current Thanks for the pointer! > It's used in src/sys/netinet/ipsec_input.c to impersonate the incoming > interface just as you did in your patch. > > I'd like to know whether there would be any interest in associating a > different interface to each incoming SPD entry or just use only one > interface for all incoming SPD entries ? Well, IMHO the best way would be to have a separate interface for each tunnel end point. That would allow most fine grained control, and would be easiest to understand. Perhaps something like the following: ifconfig enc0 up ifconfig enc0 192.168.0.129 netmask 255.255.255.0 ifconfig xl1 192.168.0.130 netmask 255.255.255.128 setkey -c << EOF spdadd 192.168.0.0/24 192.168.0.128/25 any -P in ipsec esp/tunnel/XXX-YYY/require; spdadd 192.168.0.128/25 192.168.0.0/24 any -P out ipsec ESP/tunnel/YYY-XXX/require; EOF Even better would be if you could use just on IP address instead of having a separate address at the tunnel interface and another one at the internal network interface, but I'm not sure if that would work. When IPsec is not used or properly configured, the enc interface could be just a black hole, discarding any packets that are not processed and tunneled by IPsec. With the received packets, the IPsec code would need to go through the configured enc interfaces, and find one where the source address would match... Now, all this has one not-so-good design aspect: in a way you need to configure the tunnel twice: once the enc interface, IP addresses and routing etc, and a second time set up the proper IPsec SPD entries. Perhaps the enc interface could be even more intelligent, and set up default SPD entries based on routing tables??? --Pekka Nikander To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jan 3 3:24:47 2003 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 606E337B401 for ; Fri, 3 Jan 2003 03:24:44 -0800 (PST) Received: from pop3.psconsult.nl (ps226.psconsult.nl [193.67.147.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9C7D443ED4 for ; Fri, 3 Jan 2003 03:24:40 -0800 (PST) (envelope-from paul@pop3.psconsult.nl) Received: (from paul@localhost) by pop3.psconsult.nl (8.9.2/8.9.2) id MAA17192; Fri, 3 Jan 2003 12:24:34 +0100 (CET) (envelope-from paul) Date: Fri, 3 Jan 2003 12:24:34 +0100 From: Paul Schenkeveld To: Pekka Nikander Cc: freebsd-net@FreeBSD.ORG Subject: Re: IPsec / ipfw interaction in 4.7-STABLE: a proposed change Message-ID: <20030103122434.A16996@psconsult.nl> References: <3E144753.7020905@nomadiclab.com> <86k7hnz4hp.fsf@notbsdems.nantes.kisoft-services.com> <3E15604B.3040505@nomadiclab.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <3E15604B.3040505@nomadiclab.com>; from pekka.nikander@nomadiclab.com on Fri, Jan 03, 2003 at 12:04:59PM +0200 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, Jan 03, 2003 at 12:04:59PM +0200, Pekka Nikander wrote: > Eric Masson wrote: > > Seems pretty close to what OpenBSD has implemented, except they don't > > use the stock loopback interface. > > > > Their enc(4) driver is a software loopback interface : > > http://www.openbsd.org/cgi-bin/man.cgi?query=enc&sektion=4&arch=i386&apropos=0&manpath=OpenBSD+Current > > Thanks for the pointer! > > > It's used in src/sys/netinet/ipsec_input.c to impersonate the incoming > > interface just as you did in your patch. > > > > I'd like to know whether there would be any interest in associating a > > different interface to each incoming SPD entry or just use only one > > interface for all incoming SPD entries ? > > Well, IMHO the best way would be to have a separate interface > for each tunnel end point. That would allow most fine grained > control, and would be easiest to understand. > > Perhaps something like the following: > > ifconfig enc0 up > ifconfig enc0 192.168.0.129 netmask 255.255.255.0 > ifconfig xl1 192.168.0.130 netmask 255.255.255.128 > > setkey -c << EOF > spdadd 192.168.0.0/24 192.168.0.128/25 any -P in > ipsec esp/tunnel/XXX-YYY/require; > spdadd 192.168.0.128/25 192.168.0.0/24 any -P out > ipsec ESP/tunnel/YYY-XXX/require; > EOF > > Even better would be if you could use just on IP address > instead of having a separate address at the tunnel > interface and another one at the internal network interface, > but I'm not sure if that would work. Because of the way IPsec and ipfw/ipfilter interact, I've moved to the following workaround: ifconfig fxp0 $my_internal netmask $my_internal_netmask ifconfig gif0 create \ tunnel $my_external $peer_external \ $my_internal $peer_external Now I use transport mode instead of tunnel mode between the two external IP addresses: setkey -c << EOF add $my_external $peer_external ah spi1 -A hmac-md5 key1; add $peer_external $my_external ah spi2 -A hmac-md5 key2; add $my_external $peer_external esp spi3 -E blowfish-cbc key3; add $peer_external $my_external esp spi4 -E blowfish-cbc key4; spdadd $my_external $peer_external ipencap -P out ipsec esp/transport/$my_external-$peer_external/require ah/transport/$my_external-$peer_external/require; spdadd $peer_external $my_external ipencap -P in ipsec esp/transport/$peer_external-$my_external/require ah/transport/$peer_external-$my_external/require; EOF The 'ipencap' in the spadd lines causes only traffic in the gif tunnel to be affected by IPsec, you could also use 'any' here to encrypt/sign all traffic. Now all tunnel traffic (in and out) passed gif0 where I can use ipfw and/or ipfilter. Although this is not the solution to your problem, it shows a behaviour close to what you want I think. I'd love to see ipsec evolve in a way that I don't need gif tunnels anymore so I like the enc0 interface concept but then I'd suggest that IPsec automagically create route entries from the spadd lines such that also outbound traffic passes enc0. > When IPsec is not used or properly configured, the enc > interface could be just a black hole, discarding any > packets that are not processed and tunneled by IPsec. > > With the received packets, the IPsec code would need to > go through the configured enc interfaces, and find one > where the source address would match... > > Now, all this has one not-so-good design aspect: in a way > you need to configure the tunnel twice: once the enc > interface, IP addresses and routing etc, and a second time > set up the proper IPsec SPD entries. Perhaps the enc > interface could be even more intelligent, and set up default > SPD entries based on routing tables??? > > --Pekka Nikander -- Paul Schenkeveld, Consultant PSconsult ICT Services BV To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jan 3 3:37: 3 2003 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7136937B401 for ; Fri, 3 Jan 2003 03:37:02 -0800 (PST) Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by mx1.FreeBSD.org (Postfix) with ESMTP id 91ECF43EDC for ; Fri, 3 Jan 2003 03:37:01 -0800 (PST) (envelope-from pekka.nikander@nomadiclab.com) Received: from nomadiclab.com (polle.local.nikander.com [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 141AB23; Fri, 3 Jan 2003 13:45:22 +0200 (EET) Message-ID: <3E1575BC.6000001@nomadiclab.com> Date: Fri, 03 Jan 2003 13:36:28 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.3b) Gecko/20021230 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Schenkeveld Cc: freebsd-net@FreeBSD.ORG Subject: Re: IPsec / ipfw interaction in 4.7-STABLE: a proposed change References: <3E144753.7020905@nomadiclab.com> <86k7hnz4hp.fsf@notbsdems.nantes.kisoft-services.com> <3E15604B.3040505@nomadiclab.com> <20030103122434.A16996@psconsult.nl> In-Reply-To: <20030103122434.A16996@psconsult.nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Paul Schenkeveld wrote: > Because of the way IPsec and ipfw/ipfilter interact, I've > moved to the following workaround: ... > Now I use transport mode instead of tunnel mode between the two > external IP addresses: ... > Although this is not the solution to your problem, it shows a > behaviour close to what you want I think. Thanks for the suggestion, but I'm afraid that it won't work for me. Namely, my ISP has a NAT box between my home server and the rest of the internet. Fortunately I do have a permanent one-to-one mapping at the NAT box so that I can run ESP over it, and with manually set up tunnel ESP it works. Not nice, but it works. I'm afraid transport mode wouldn't work, but maybe I should try it. > I'd love to see ipsec evolve in a way that I don't need gif tunnels > anymore so I like the enc0 interface concept but then I'd suggest > that IPsec automagically create route entries from the spadd lines > such that also outbound traffic passes enc0. I think that generating routing table entries from SPD is probably a better idea than my original idea of doing it the other way around. I think that it would be even possible to do that in the user land, having some process listening to a PFKEY socket and adding and deleting routes as it sees tunnel mode SPD entries coming and going. --Pekka Nikander To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jan 3 4: 0:59 2003 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DF5E437B401 for ; Fri, 3 Jan 2003 04:00:57 -0800 (PST) Received: from ares.cs.Virginia.EDU (ares.cs.Virginia.EDU [128.143.137.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0680D43EDC for ; Fri, 3 Jan 2003 04:00:57 -0800 (PST) (envelope-from nicolas@cs.virginia.edu) Received: from arachnion.cs.Virginia.EDU (arachnion.cs.Virginia.EDU [128.143.136.20]) by ares.cs.Virginia.EDU (8.9.3+Sun/8.9.2/UVACS-2000040300) with ESMTP id HAA10946; Fri, 3 Jan 2003 07:00:55 -0500 (EST) Received: from localhost (nc2y@localhost) by arachnion.cs.Virginia.EDU (8.9.2/8.9.2) with ESMTP id HAA01236; Fri, 3 Jan 2003 07:00:54 -0500 (EST) X-Authentication-Warning: arachnion.cs.Virginia.EDU: nc2y owned process doing -bs Date: Fri, 3 Jan 2003 07:00:54 -0500 (EST) From: Nicolas Christin X-X-Sender: nc2y@arachnion.cs.Virginia.EDU To: Barry Irwin Cc: kseel , Subject: Re: Quad ethernet question In-Reply-To: <014901c2b308$1be778a0$0b01a8c0@Beastie> Message-ID: Organization: University of Virginia - CS Dept. MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, 3 Jan 2003, Barry Irwin wrote: > kseel wrote: > > > Anyone using one of these? > > > > http://www.corpsys.com/store/prodinfo.asp?number=ANA6944&variation=&aitem=60&mitem=62 > > If so, is the performance good? > > > I have a similar card ( also adaptec 4 port) in a number of firewalls. > FreeBSD uses the sf driver. Been running these for about 18 months with no > hastles. Well, I have had problems with it. I can't remember the exact wording of the error message I was getting, but under a very high load (all four ports spitting out about 90 Mbps), the card would frequently complain that some buffer was full and it couldn't send anymore. The only way to get the card back was to do an ifconfig down up on all four ports... It looked very much like mbuf exahustion except that mbuf's were still available according to what I was seeing. I guess there is a small problem in the sf driver, but I didn't get around to trying to fix it. (Device driver tweaking is not really my area of expertise...) If there is interest I can try to dig up the old email in which I was describing the problem... I don't think I posted it to this list at the time, it's more likely I sent a private email to the driver's author. Then again, these problems occured under 4.3 and 4.5, can't tell if this was fixed in more recent revisions of the driver. Best, -- Nicolas Christin Ph.D. Candidate, University of Virginia, Computer Science http://www.cs.virginia.edu/~nicolas To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jan 3 4:17:50 2003 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 35E4237B401 for ; Fri, 3 Jan 2003 04:17:49 -0800 (PST) Received: from ares.cs.Virginia.EDU (ares.cs.Virginia.EDU [128.143.137.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4FEC843F13 for ; Fri, 3 Jan 2003 04:17:48 -0800 (PST) (envelope-from nicolas@cs.virginia.edu) Received: from arachnion.cs.Virginia.EDU (arachnion.cs.Virginia.EDU [128.143.136.20]) by ares.cs.Virginia.EDU (8.9.3+Sun/8.9.2/UVACS-2000040300) with ESMTP id HAA11623 for ; Fri, 3 Jan 2003 07:17:47 -0500 (EST) Received: from localhost (nc2y@localhost) by arachnion.cs.Virginia.EDU (8.9.2/8.9.2) with ESMTP id HAA01268 for ; Fri, 3 Jan 2003 07:17:47 -0500 (EST) X-Authentication-Warning: arachnion.cs.Virginia.EDU: nc2y owned process doing -bs Date: Fri, 3 Jan 2003 07:17:47 -0500 (EST) From: Nicolas Christin X-X-Sender: nc2y@arachnion.cs.Virginia.EDU To: freebsd-net@FreeBSD.ORG Subject: Re: Quad ethernet question In-Reply-To: Message-ID: Organization: University of Virginia - CS Dept. MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, 3 Jan 2003, Nicolas Christin wrote: > If there is interest I can try to dig up the old email in which I was > describing the problem... Following is a more accurate description of the problem I saw with the card mentioned in this thread. I don't seem to have a printout of the available mbuf's at hand, but I distinctly remember that everything looked fine on that front. --Nicolas I am experiencing some problems with the sf driver, which I use on the following quad card: Adaptec ANA-62044 SGLQuartet 64 10/100Base TX The driver works just fine most of the time, I can transmit/receive data on all four ports. However, when the link governed by the sf driver gets overloaded, I sometimes get the following error: nc2y@tin $ ping 10.0.4.2 PING 10.0.4.2 (10.0.4.2): 56 data bytes ping: sendto: No buffer space available where sf0 is configured as follows: nc2y@tin $ ifconfig sf0 sf0: flags=8843 mtu 1500 inet 10.0.4.1 netmask 0xffffff00 broadcast 10.0.4.255 inet6 fe80::200:d1ff:feee:3ff1%sf0 prefixlen 64 scopeid 0x3 ether 00:00:d1:ee:3f:f1 media: 100baseTX status: active supported media: autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none Interestingly enough, when pinging 10.0.4.1 from 10.0.4.2, I do not get any error, and ICMP replies actually manage to make it. This experiment was run on an Intel Pentium III running FreeBSD 4.3. (I don't think there are any changes to the sf driver in FreeBSD 4.4.) [Note: the same problem is present in 4.5.] -- Nicolas Christin Ph.D. Candidate, University of Virginia, Computer Science http://www.cs.virginia.edu/~nicolas To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jan 3 6:21:51 2003 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 32FA237B401 for ; Fri, 3 Jan 2003 06:21:50 -0800 (PST) Received: from pop3.psconsult.nl (ps226.psconsult.nl [193.67.147.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id D5B4643EB2 for ; Fri, 3 Jan 2003 06:21:45 -0800 (PST) (envelope-from paul@pop3.psconsult.nl) Received: (from paul@localhost) by pop3.psconsult.nl (8.9.2/8.9.2) id PAA19477; Fri, 3 Jan 2003 15:21:41 +0100 (CET) (envelope-from paul) Date: Fri, 3 Jan 2003 15:21:40 +0100 From: Paul Schenkeveld To: Pekka Nikander Cc: freebsd-net@FreeBSD.ORG Subject: Re: IPsec / ipfw interaction in 4.7-STABLE: a proposed change Message-ID: <20030103152140.A19350@psconsult.nl> References: <3E144753.7020905@nomadiclab.com> <86k7hnz4hp.fsf@notbsdems.nantes.kisoft-services.com> <3E15604B.3040505@nomadiclab.com> <20030103122434.A16996@psconsult.nl> <3E1575BC.6000001@nomadiclab.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <3E1575BC.6000001@nomadiclab.com>; from pekka.nikander@nomadiclab.com on Fri, Jan 03, 2003 at 01:36:28PM +0200 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, Jan 03, 2003 at 01:36:28PM +0200, Pekka Nikander wrote: > Paul Schenkeveld wrote: > > Because of the way IPsec and ipfw/ipfilter interact, I've > > moved to the following workaround: > ... > > Now I use transport mode instead of tunnel mode between the two > > external IP addresses: > ... > > Although this is not the solution to your problem, it shows a > > behaviour close to what you want I think. > > Thanks for the suggestion, but I'm afraid that it won't work > for me. Namely, my ISP has a NAT box between my home server > and the rest of the internet. Fortunately I do have a permanent > one-to-one mapping at the NAT box so that I can run ESP over it, > and with manually set up tunnel ESP it works. Not nice, but it > works. I'm afraid transport mode wouldn't work, but maybe > I should try it. If ESP in tunnel mode works for you I think ESP in transport mode should also work. Note that in my example, the transport mode is not configured between the internal addresses but between the external addresses of the two tunnel endpoints. I chose to only ESP gif packets (the ipencap keyword) but you could alse ESP all packets by replacing ipencap by any. > > I'd love to see ipsec evolve in a way that I don't need gif tunnels > > anymore so I like the enc0 interface concept but then I'd suggest > > that IPsec automagically create route entries from the spadd lines > > such that also outbound traffic passes enc0. > > I think that generating routing table entries from SPD is > probably a better idea than my original idea of doing > it the other way around. I think that it would be even possible > to do that in the user land, having some process listening to > a PFKEY socket and adding and deleting routes as it sees > tunnel mode SPD entries coming and going. I forgot to mention that this enc0 kind of interface should allow to specify the interface name per tunnel. If you have multiple tunnels (like I do) configuring ipfw/ipf would be a nightmare if the enc* interface is assigned randomly. > --Pekka Nikander -- Paul Schenkeveld, Consultant PSconsult ICT Services BV To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jan 3 7:42: 8 2003 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4520A37B401 for ; Fri, 3 Jan 2003 07:42:05 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id C8AEF43E4A for ; Fri, 3 Jan 2003 07:42:04 -0800 (PST) (envelope-from larse@ISI.EDU) Received: from isi.edu (c-24-130-112-121.we.client2.attbi.com [24.130.112.121]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id h03FfnC29924; Fri, 3 Jan 2003 07:41:49 -0800 (PST) Message-ID: <3E15AF3C.5020105@isi.edu> Date: Fri, 03 Jan 2003 07:41:48 -0800 From: Lars Eggert Organization: USC Information Sciences Institute User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Nikander Cc: Eric Masson , freebsd-net@FreeBSD.ORG Subject: Re: IPsec / ipfw interaction in 4.7-STABLE: a proposed change References: <3E144753.7020905@nomadiclab.com> <86k7hnz4hp.fsf@notbsdems.nantes.kisoft-services.com> <3E15604B.3040505@nomadiclab.com> In-Reply-To: <3E15604B.3040505@nomadiclab.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080309020704020200050101" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a cryptographically signed message in MIME format. --------------ms080309020704020200050101 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit On 1/3/2003 2:04 AM, Pekka Nikander wrote: > > Well, IMHO the best way would be to have a separate interface > for each tunnel end point. That would allow most fine grained > control, and would be easiest to understand. Take a look at the draft-touch-ipsec-vpn-04.txt ID ; if you can use the approach we describe there (IPIP tunnels + IPsec transport mode), you get this functionality free, because rcvif will be the IPIP tunnel a packet came in on. Lars -- Lars Eggert USC Information Sciences Institute --------------ms080309020704020200050101 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJtjCC AzgwggKhoAMCAQICEGZFcrfMdPXPY3ZFhNAukQEwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vydmlj ZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkG CSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAw MDBaFw0wNDA4MjcyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2Vy dGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAw LjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZ gpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqd knWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYALQmJ7JRr6aFp AgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTI5NzAS BgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQAxsUtH XfkBceX1U2xdedY9mMAmE2KBIqcS+CKV6BtJtyd7BDm6/ObyJOuR+r3sDSo491BVqGz3Da1M G7wD9LXrokefbKIMWI0xQgkRbLAaadErErJAXWr5edDqLiXdiuT82w0fnQLzWtvKPPZE6iZp h39Ins6ln+eE2MliYq0FxjCCAzkwggKioAMCAQICAwglQTANBgkqhkiG9w0BAQQFADCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMB4XDTAyMDgyNDE4NTMzOVoX DTAzMDgyNDE4NTMzOVowVDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYD VQQDEwtMYXJzIEVnZ2VydDEcMBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBANI2Rrt4ggaQ/IrOsDeOm2H4/R5FRIL6JjDY3StE aogp1r23WKniQ1Vj98Nu5WxlaZ3Iam3Jen5T66H8u7rtMNpK4qAeAGoBsVeyVr1+CTFeuv+m xCh7BvBJwhLdm0zDaoDT05YKYZaqtsT+F286FWJQg31Xtf+vTKLVVrHcsafnteyal2NEt7Ac yZZfjsVLwxp2Lq3cwYfRQRoo7/yCVzS7HsgM6jmbO4taEMo4yC2rpnUbWEUCDTaCYgpAXzAl oiNk7GDh0wz2s5ZSnHRvNSBMAjCmpNtSYHfXFI1ANwrrrHIJ7Ei83+XN32PWY4OPzO3iown9 VR+vM+8lNx9OX28CAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIBBAQTTDJ1TXlmZkJO VWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEEBQADgYEAXcrIlKmPLM/r8r3oz2ZLPLaT1AyMjYTZY2qq/R7SUtFa9BNlTIFh DG78QKfJ9lo2LMzTPQqMZgNLmj95GbNPI8P8OIq2K6MeCZWz08ROackqTFP6xWbIFIfXcBVR 1dZnDDyDKBBh05KkvyTPawSQyOBUeNBfQUyO4TE+3o58U8UwggM5MIICoqADAgECAgMIJUEw DQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MDAeFw0wMjA4MjQxODUzMzlaFw0wMzA4MjQxODUzMzlaMFQxDzANBgNVBAQTBkVnZ2VydDEN MAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkqhkiG9w0BCQEWDWxh cnNlQGlzaS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDSNka7eIIGkPyK zrA3jpth+P0eRUSC+iYw2N0rRGqIKda9t1ip4kNVY/fDbuVsZWmdyGptyXp+U+uh/Lu67TDa SuKgHgBqAbFXsla9fgkxXrr/psQoewbwScIS3ZtMw2qA09OWCmGWqrbE/hdvOhViUIN9V7X/ r0yi1Vax3LGn57XsmpdjRLewHMmWX47FS8Madi6t3MGH0UEaKO/8glc0ux7IDOo5mzuLWhDK OMgtq6Z1G1hFAg02gmIKQF8wJaIjZOxg4dMM9rOWUpx0bzUgTAIwpqTbUmB31xSNQDcK66xy CexIvN/lzd9j1mODj8zt4qMJ/VUfrzPvJTcfTl9vAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIB ADAaMBgCAQQEE0wydU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVk dTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAF3KyJSpjyzP6/K96M9mSzy2k9QM jI2E2WNqqv0e0lLRWvQTZUyBYQxu/ECnyfZaNizM0z0KjGYDS5o/eRmzTyPD/DiKtiujHgmV s9PETmnJKkxT+sVmyBSH13AVUdXWZww8gygQYdOSpL8kz2sEkMjgVHjQX0FMjuExPt6OfFPF MYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MAIDCCVBMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTAzMDEwMzE1NDE0OFowIwYJKoZIhvcNAQkEMRYEFFd1sXTLfpcz1hmYtW5C yjXuLuFFMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3EAQxgZ0w gZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNh cGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNl czEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCCVBMIGtBgsq hkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2Fw ZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRp ZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44 LjMwAgMIJUEwDQYJKoZIhvcNAQEBBQAEggEAhoGELJ3SRqRQr0Jn72eq0xI4247MBKnc7XEb SAC+TYFjyAa22fXNiTwZfHIgpgp1tD3svUP547FuOVZ69yXjj9EUIZ9NX+da19gEQXedxyUv yGHhKpK3Qv1YYp7jLboLav6Koro8Yf6O6Kk9jiaX7tI0o42+xmosULyWpG2kgIHvAhbBRljr WpaVmOLu2fnlksOV/K9uPTEl35YZLHrk9QTXq+h/GTezZedRovuJiLDfeaJsqXquVt62Cfq5 9aJtp9HK40EpL2G7UiCS3UIWr1+yjTfffa7IHN28XFAvL8eMRvUuFufc017WtdZiMtslJjiw Iir7Uo1QtZvcnuKsigAAAAAAAA== --------------ms080309020704020200050101-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jan 3 8:13:12 2003 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5808D37B401; Fri, 3 Jan 2003 08:13:11 -0800 (PST) Received: from mel-rto6.wanadoo.fr (smtp-out-6.wanadoo.fr [193.252.19.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6B5EE43EC2; Fri, 3 Jan 2003 08:13:10 -0800 (PST) (envelope-from vjardin@wanadoo.fr) Received: from mel-rta7.wanadoo.fr (193.252.19.61) by mel-rto6.wanadoo.fr (6.7.015) id 3E0C343F003230D7; Fri, 3 Jan 2003 17:13:09 +0100 Received: from there (80.11.204.219) by mel-rta7.wanadoo.fr (6.7.015) id 3E075B1B003E24DE; Fri, 3 Jan 2003 17:13:09 +0100 Message-ID: <3E075B1B003E24DE@mel-rta7.wanadoo.fr> (added by postmaster@wanadoo.fr) Content-Type: text/plain; charset="iso-8859-15" From: Vincent Jardin To: freebsd-atm@freebsd.org Subject: New OC3 ATM driver Date: Fri, 3 Jan 2003 17:32:10 +0100 X-Mailer: KMail [version 1.3.2] Cc: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Prosum just releases an ATM driver for FreeBSD 3.x and 4.x It has some nice features: - CBR support - VBR support It supports the HARP stack. The last release of the driver is available on their web site: http://www.prosum.fr/atm155_E.html It works very well with the Prosum's OC3 board ;-) Regards, Vincent To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jan 3 8:59: 4 2003 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9C8BA37B401 for ; Fri, 3 Jan 2003 08:59:02 -0800 (PST) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2249143EB2 for ; Fri, 3 Jan 2003 08:59:02 -0800 (PST) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (IDENT:brdavis@localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.12.3/8.12.3) with ESMTP id h03Gwt8r009554; Fri, 3 Jan 2003 08:58:55 -0800 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.3/8.12.3/Submit) id h03GwtjR009553; Fri, 3 Jan 2003 08:58:55 -0800 Date: Fri, 3 Jan 2003 08:58:55 -0800 From: Brooks Davis To: Pekka Nikander Cc: Brooks Davis , freebsd-net@FreeBSD.ORG Subject: Re: IPsec / ipfw interaction in 4.7-STABLE: a proposed change Message-ID: <20030103085855.A8517@Odin.AC.HMC.Edu> References: <3E144753.7020905@nomadiclab.com> <86k7hnz4hp.fsf@notbsdems.nantes.kisoft-services.com> <20030102122941.A27618@Odin.AC.HMC.Edu> <3E155BB5.4000706@nomadiclab.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="AqsLC8rIMeq19msA" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3E155BB5.4000706@nomadiclab.com>; from pekka.nikander@nomadiclab.com on Fri, Jan 03, 2003 at 11:45:25AM +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) on odin.ac.hmc.edu Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --AqsLC8rIMeq19msA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 03, 2003 at 11:45:25AM +0200, Pekka Nikander wrote: > Brooks Davis wrote: > > loif[] is evil and its use should not be extended. In any case, NLOOP > > no longer exists in current since loopback interfaces are clonable. If > > you didn't want to adopt OpenBSD's enc interface, an alternate solution > > might be to set up an ioctl to allow you to register the interface you > > want to have these packets come from. >=20 > Now, out of curiosity, why do you consider loif[] evil? The problem is that it makes lo0 a magic interface. In general, things like magic interfaces are to be avoided because they don't act like other objects of the same type. In the case of the loopback interface, it means you can't unload the lo(4) module without causing a panic. In reality, especialy when talking about loif, this is more likely a matter of principle then something we're actually going to fix, but the principle still holds. FYI, in current loif[] became *loif and we register an interface when if_lo is loaded. I suspect your system will in fact panic fairly quickly if it isn't loaded at startup though. Modularity was added when I added cloning, but mostly because it was easy to do. -- 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 --AqsLC8rIMeq19msA Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE+FcFIXY6L6fI4GtQRAj6ZAJ4vxRiKaJY8mmNf0C6yOU1Ozp3JLgCeIdU0 TAX4gOAPmurNQd8afUMvwCE= =yfYx -----END PGP SIGNATURE----- --AqsLC8rIMeq19msA-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jan 3 9:21:39 2003 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 451C137B401 for ; Fri, 3 Jan 2003 09:21:38 -0800 (PST) Received: from math.teaser.net (math.teaser.net [213.91.2.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1EFB843EC5 for ; Fri, 3 Jan 2003 09:21:37 -0800 (PST) (envelope-from e-masson@kisoft-services.com) Received: from notbsdems.nantes.kisoft-services.com (nantes.kisoft-services.com [193.56.60.243]) by math.teaser.net (Postfix) with ESMTP id BE6F96C80B; Fri, 3 Jan 2003 18:21:30 +0100 (CET) Received: by notbsdems.nantes.kisoft-services.com (Postfix, from userid 1001) id 4B50059422; Fri, 3 Jan 2003 18:21:32 +0100 (CET) To: Pekka Nikander Cc: freebsd-net@FreeBSD.ORG Subject: Re: IPsec / ipfw interaction in 4.7-STABLE: a proposed change From: Eric Masson In-Reply-To: <3E15604B.3040505@nomadiclab.com> (Pekka Nikander's message of "Fri, 03 Jan 2003 12:04:59 +0200") References: <3E144753.7020905@nomadiclab.com> <86k7hnz4hp.fsf@notbsdems.nantes.kisoft-services.com> <3E15604B.3040505@nomadiclab.com> X-Operating-System: FreeBSD 4.7-STABLE i386 Date: Fri, 03 Jan 2003 18:21:31 +0100 Message-ID: <86fzsa87z8.fsf@notbsdems.nantes.kisoft-services.com> User-Agent: Gnus/5.090008 (Oort Gnus v0.08) XEmacs/21.4 (Common Lisp, i386--freebsd) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >>>>> "Pekka" == Pekka Nikander writes: Pekka> Well, IMHO the best way would be to have a separate interface Pekka> for each tunnel end point. That would allow most fine grained Pekka> control, and would be easiest to understand. I was thinking of a virtual interface pour each incoming tunnel endpoint, nothing more. The problem, as pointed in another post, would be the numbering of these interfaces (from a filtering point of view). From a previous discussion in -security, a tunnel can be used in odd ways, and mixing with routing isn't a good idea : http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=fa.llg8ghv.1l0skqv%40ifi.uio.no Eric Masson -- 70% de frjv sont des newbies ? Et une fois qu'ils ne le sont plus que font-ils ? Ils quittent frjv parce que c'est trop à chier ? Parce que s'ils y restent et gardent leur comportement, ça devient des neuneux. -+- XB in: - Tu seras un neuneu mon fils -+- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jan 3 15: 1:57 2003 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9DCA737B405 for ; Fri, 3 Jan 2003 15:01:56 -0800 (PST) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 4774443EDC for ; Fri, 3 Jan 2003 15:01:52 -0800 (PST) (envelope-from nate@rootlabs.com) Received: (qmail 99935 invoked by uid 1000); 3 Jan 2003 23:01:53 -0000 Date: Fri, 3 Jan 2003 15:01:53 -0800 (PST) From: Nate Lawson To: current@freebsd.org Cc: net@freebsd.org Subject: Proper -current if_attach locking? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I was looking into some "could sleep messages" and found some bogus locking in the attach routine of many drivers. Several init a mtx in their softc and then lock/unlock it in their attach routine. This, of course, does nothing to provide exclusive access to a device. I assume there is going to be a global IF_LOCK or something to be used in attach routines. Can someone fill me in on the intended design? -Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jan 3 16:30: 9 2003 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 82DE237B401 for ; Fri, 3 Jan 2003 16:30:08 -0800 (PST) Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id D044843EC5 for ; Fri, 3 Jan 2003 16:30:07 -0800 (PST) (envelope-from archie@dellroad.org) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id QAA37764; Fri, 3 Jan 2003 16:21:14 -0800 (PST) Received: from arch20m.dellroad.org (localhost [127.0.0.1]) by arch20m.dellroad.org (8.12.6/8.12.6) with ESMTP id h040K9fi078159; Fri, 3 Jan 2003 16:20:09 -0800 (PST) (envelope-from archie@arch20m.dellroad.org) Received: (from archie@localhost) by arch20m.dellroad.org (8.12.6/8.12.6/Submit) id h040K6w0078158; Fri, 3 Jan 2003 16:20:06 -0800 (PST) From: Archie Cobbs Message-Id: <200301040020.h040K6w0078158@arch20m.dellroad.org> Subject: Re: Multilink server In-Reply-To: <5.1.0.14.2.20021220131618.0199bb90@mail.lorcavirtual.com> To: =?ISO-8859-1?Q?Jes=FAs_Mart=EDnez_Mateo?= Date: Fri, 3 Jan 2003 16:20:06 -0800 (PST) Cc: freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL99b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UNKNOWN-8BIT Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Jesús Martínez Mateo wrote: > I'm looking for a Multilink server to work with Linux, but I haven't found > nothing. Could you help me about that? Do you know if mpd works with Linux? Mpd does not work with Linux. It requires netgraph, which Linux doesn't have. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jan 4 3:39: 4 2003 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CF8D037B401 for ; Sat, 4 Jan 2003 03:39:02 -0800 (PST) Received: from shell.dragondata.com (shell.dragondata.com [66.250.147.249]) by mx1.FreeBSD.org (Postfix) with ESMTP id 14F2043EB2 for ; Sat, 4 Jan 2003 03:39:02 -0800 (PST) (envelope-from toasty@shell.dragondata.com) Received: (from root@localhost) by shell.dragondata.com (8.11.4/8.11.3) id h04Bd0782966; Sat, 4 Jan 2003 05:39:00 -0600 (CST) (envelope-from toasty) From: Kevin Day Received: (from toasty@localhost) by shell.dragondata.com (8.11.4/8.11.3av) id h04Bcwe82722; Sat, 4 Jan 2003 05:38:58 -0600 (CST) (envelope-from toasty) Message-Id: <200301041138.h04Bcwe82722@shell.dragondata.com> Subject: Traceroute through specific gateway/interface To: freebsd-net@freebsd.org Date: Sat, 4 Jan 2003 05:38:58 -0600 (CST) X-Mailer: ELM [version 2.5 PL5] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by dragondata.com virus scanner Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Has anyone ever created a patch for traceroute that lets you force it to go through a specific interface, or use a certain gateway even if the routing table says otherwise? I know I can use source routing, but a good percentage of the routers on the internet drop source routed packets now. Here's my situation... I have a FreeBSD system running as a router to multi-home us between three uplinks, with us running Zebra for BGP. It'd be nice to occasionally take a look at a traceroute through one of the other uplinks. (other than the one that Zebra has added a route for) +-----------------------+ | | ISP-A | bge0 10.1.0.2/30 +----------> 10.1.0.1 | | | | ISP-B | bge1 10.2.0.2/30 +----------> 10.2.0.1 | | | | ISP-C | bge2 10.3.0.2/30 +----------> 10.3.0.1 | | LAN | | <-------+ bge3 10.9.0.254/24 | +-----------------------+ If Zebra has decided that the route to 192.168.0.1 is shortest through ISP-A, doing a regular traceroute to 192.168.0.1 goes through ISP-A easily. If I want to traceroute to that IP through ISP-B, I use the -s traceroute option to set the source IP address to 10.2.0.2 (to ensure the return path goes through ISP-B, since only ISP-B is announcing that /30's space). If I use the -g option to source route the traceroute through 10.2.0.1, it mostly works, except that if I use source routing, I can't trace route through two of my uplinks since they disable source routing. Even through the one that doesn't, I usually hit a router somewhere along the way that has it disabled. Any ideas? -- Kevin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jan 4 14:38:51 2003 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 53F7C37B401 for ; Sat, 4 Jan 2003 14:38:44 -0800 (PST) Received: from jawa.at (inforum.at [213.229.17.146]) by mx1.FreeBSD.org (Postfix) with ESMTP id E5DF243EA9 for ; Sat, 4 Jan 2003 14:38:42 -0800 (PST) (envelope-from mbretter@jawa.at) Received: from jawa.at (worf.jawa.at [192.168.201.12]) by jawa.at (8.12.6/8.12.6) with ESMTP id h04Mca7K005226 for ; Sat, 4 Jan 2003 23:38:37 +0100 (CET) (envelope-from mbretter@jawa.at) Message-ID: <3E176232.8070809@jawa.at> Date: Sat, 04 Jan 2003 23:37:38 +0100 From: Michael Bretterklieber User-Agent: Mozilla/5.0 (X11; U; Linux i386; de-AT; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: enhancements for libradius v2 - commiter searched Content-Type: multipart/mixed; boundary="------------080509080801040604000306" X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Spam-Status: No, hits=-0.5 required=5.0 tests=SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MOZILLA_UA, X_ACCEPT_LANG version=2.43 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a multi-part message in MIME format. --------------080509080801040604000306 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, I made the radius integration for mpd. During this work I missed some functions in libradius. I revised my old patches and resolved also a minor issue. Here is a short changelog: - added rad_demangle for demangling user-passwords (needed for MS-CHAPv1 MPPE-keys). - added rad_demangle_mppe_key for demangling mppe-keys (needed for MS-CHAPv2 MPPE-keys). - added some typecasts to avoid compilation warnings - if the programmer has not called rad_create_request() but rad_put_*, then a weird error message was returned => fixed. The rad_demangle_mppe_key function was taken from userland ppp. I hope that someone can review and commit this patch soon. I also opened a pr: http://www.freebsd.org/cgi/query-pr.cgi?pr=46555 bye, -- ------------------------------- ------------------------------------- Michael Bretterklieber - Michael.Bretterklieber@jawa.at JAWA Management Software GmbH - http://www.jawa.at Liebenauer Hauptstr. 200 -------------- privat --------------- A-8041 GRAZ GSM: ++43-(0)676-93 96 698 Tel: ++43-(0)316-403274-12 E-mail: michael@bretterklieber.com Fax: ++43-(0)316-403274-10 http://www.bretterklieber.com ------------------------------- ------------------------------------- "...the number of UNIX installations has grown to 10, with more expected..." - Dennis Ritchie and Ken Thompson, June 1972 --------------080509080801040604000306 Content-Type: text/plain; name="libradius.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="libradius.diff" diff -u libradius/Makefile libradius_new/Makefile --- libradius/Makefile Mon Dec 23 16:07:51 2002 +++ libradius_new/Makefile Sat Jan 4 23:25:13 2003 @@ -31,7 +31,7 @@ DPADD+= ${LIBMD} LDADD+= -lmd SHLIB_MAJOR= 1 -SHLIB_MINOR= 0 +SHLIB_MINOR= 1 MAN= libradius.3 radius.conf.5 .include diff -u libradius/radlib.c libradius_new/radlib.c --- libradius/radlib.c Sat Jan 4 23:26:58 2003 +++ libradius_new/radlib.c Sat Jan 4 23:24:46 2003 @@ -31,6 +31,7 @@ #include #include #include +#include #include #include @@ -243,7 +244,7 @@ sizeof srvp->addr.sin_addr); } if (port != 0) - srvp->addr.sin_port = htons(port); + srvp->addr.sin_port = htons((u_short)port); else { struct servent *sent; @@ -513,11 +514,12 @@ for (i = 0; i < LEN_AUTH; i += 2) { long r; r = random(); - h->request[POS_AUTH+i] = r; - h->request[POS_AUTH+i+1] = r >> 8; + h->request[POS_AUTH+i] = (u_char)r; + h->request[POS_AUTH+i+1] = (u_char)(r >> 8); } h->req_len = POS_ATTRS; clear_password(h); + h->request_created = 1; return 0; } @@ -569,7 +571,7 @@ } type = h->response[h->resp_pos++]; *len = h->response[h->resp_pos++] - 2; - if (h->resp_pos + *len > h->resp_len) { + if (h->resp_pos + (int)*len > h->resp_len) { generr(h, "Malformed attribute in response"); return -1; } @@ -671,6 +673,7 @@ h->pass_pos = 0; h->chap_pass = 0; h->type = RADIUS_AUTH; + h->request_created = 0; } return h; } @@ -703,6 +706,11 @@ { int result; + if (!h->request_created) { + generr(h, "Please call rad_create_request()"); + return -1; + } + if (type == RAD_USER_PASSWORD) result = put_password_attr(h, type, value, len); else { @@ -892,6 +900,11 @@ struct vendor_attribute *attr; int res; + if (!h->request_created) { + generr(h, "Please call rad_create_request()"); + return -1; + } + if ((attr = malloc(len + 6)) == NULL) { generr(h, "malloc failure (%d bytes)", len + 6); return -1; @@ -945,3 +958,122 @@ return (h->servers[h->srv].secret); } +int +rad_demangle(struct rad_handle *h, const void *mangled, size_t mlen, u_char *demangled) +{ + char R[LEN_AUTH]; + const char *S; + int i, Ppos; + MD5_CTX Context; + u_char b[16], *C; + + if ((mlen % 16 != 0) || (mlen > 128)) { + generr(h, "Cannot interpret mangled data of length %ld", (u_long)mlen); + return -1; + } + + C = (u_char *)mangled; + + /* We need the shared secret as Salt */ + S = rad_server_secret(h); + + /* We need the request authenticator */ + if (rad_request_authenticator(h, R, sizeof R) != LEN_AUTH) { + generr(h, "Cannot obtain the RADIUS request authenticator"); + return -1; + } + + MD5Init(&Context); + MD5Update(&Context, S, strlen(S)); + MD5Update(&Context, R, LEN_AUTH); + MD5Final(b, &Context); + Ppos = 0; + while (mlen) { + + mlen -= 16; + for (i = 0; i < 16; i++) + demangled[Ppos++] = C[i] ^ b[i]; + + if (mlen) { + MD5Init(&Context); + MD5Update(&Context, S, strlen(S)); + MD5Update(&Context, C, 16); + MD5Final(b, &Context); + } + + C += 16; + } + + return 0; +} + +int +rad_demangle_mppe_key(struct rad_handle *h, const void *mangled, size_t mlen, u_char *demangled, size_t *len) +{ + char R[LEN_AUTH]; /* variable names as per rfc2548 */ + const char *S; + u_char b[16]; + const u_char *A, *C; + MD5_CTX Context; + int Slen, i, Clen, Ppos; + u_char *P; + + if (mlen % 16 != SALT_LEN) { + generr(h, "Cannot interpret mangled data of length %ld", (u_long)mlen); + return -1; + } + + /* We need the RADIUS Request-Authenticator */ + if (rad_request_authenticator(h, R, sizeof R) != LEN_AUTH) { + generr(h, "Cannot obtain the RADIUS request authenticator"); + return -1; + } + + A = (const u_char *)mangled; /* Salt comes first */ + C = (const u_char *)mangled + SALT_LEN; /* Then the ciphertext */ + Clen = mlen - SALT_LEN; + S = rad_server_secret(h); /* We need the RADIUS secret */ + Slen = strlen(S); + P = alloca(Clen); /* We derive our plaintext */ + + MD5Init(&Context); + MD5Update(&Context, S, Slen); + MD5Update(&Context, R, LEN_AUTH); + MD5Update(&Context, A, SALT_LEN); + MD5Final(b, &Context); + Ppos = 0; + + while (Clen) { + Clen -= 16; + + for (i = 0; i < 16; i++) + P[Ppos++] = C[i] ^ b[i]; + + if (Clen) { + MD5Init(&Context); + MD5Update(&Context, S, Slen); + MD5Update(&Context, C, 16); + MD5Final(b, &Context); + } + + C += 16; + } + + /* + * The resulting plain text consists of a one-byte length, the text and + * maybe some padding. + */ + *len = *P; + if (*len > mlen - 1) { + generr(h, "Mangled data seems to be garbage %d %d", *len, mlen-1); + return -1; + } + + if (*len > MPPE_KEY_LEN) { + generr(h, "Key to long (%d) for me max. %d", *len, MPPE_KEY_LEN); + return -1; + } + + memcpy(demangled, P + 1, *len); + return 0; +} diff -u libradius/radlib.h libradius_new/radlib.h --- libradius/radlib.h Mon Dec 23 10:48:59 2002 +++ libradius_new/radlib.h Sat Jan 4 23:22:42 2003 @@ -195,6 +195,9 @@ int rad_send_request(struct rad_handle *); const char *rad_server_secret(struct rad_handle *); const char *rad_strerror(struct rad_handle *); +int rad_demangle(struct rad_handle *, + const void *, size_t, u_char *); + __END_DECLS #endif /* _RADLIB_H_ */ diff -u libradius/radlib_private.h libradius_new/radlib_private.h --- libradius/radlib_private.h Mon Sep 9 18:36:48 2002 +++ libradius_new/radlib_private.h Sat Jan 4 23:15:41 2003 @@ -76,6 +76,7 @@ int ident; /* Current identifier value */ char errmsg[ERRSIZE]; /* Most recent error message */ unsigned char request[MSGSIZE]; /* Request to send */ + char request_created; /* rad_create_request() called? */ int req_len; /* Length of request */ char pass[PASSSIZE]; /* Cleartext password */ int pass_len; /* Length of cleartext password */ diff -u libradius/radlib_vs.h libradius_new/radlib_vs.h --- libradius/radlib_vs.h Mon Dec 23 16:09:07 2002 +++ libradius_new/radlib_vs.h Mon Dec 23 16:02:02 2002 @@ -66,6 +66,8 @@ #define RAD_MICROSOFT_MS_SECONDARY_NBNS_SERVER 31 #define RAD_MICROSOFT_MS_ARAP_CHALLENGE 33 +#define SALT_LEN 2 + struct rad_handle; __BEGIN_DECLS @@ -75,6 +77,7 @@ size_t); int rad_put_vendor_int(struct rad_handle *, int, int, u_int32_t); int rad_put_vendor_string(struct rad_handle *, int, int, const char *); +int rad_demangle_mppe_key(struct rad_handle *, const void *, size_t, u_char *, size_t *); __END_DECLS #endif /* _RADLIB_VS_H_ */ --------------080509080801040604000306-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jan 4 15:41:11 2003 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 57DC937B401 for ; Sat, 4 Jan 2003 15:41:10 -0800 (PST) Received: from ada.snu.ac.kr (ada.snu.ac.kr [147.46.106.49]) by mx1.FreeBSD.org (Postfix) with ESMTP id 952CF43EA9 for ; Sat, 4 Jan 2003 15:41:09 -0800 (PST) (envelope-from redjade@ada.snu.ac.kr) Received: from ada.snu.ac.kr (ada.snu.ac.kr [147.46.106.49]) by ada.snu.ac.kr (8.12.6/8.12.6) with ESMTP id h04Nf7jC008070; Sun, 5 Jan 2003 08:41:07 +0900 (KST) (envelope-from redjade@ada.snu.ac.kr) Received: (from redjade@localhost) by ada.snu.ac.kr (8.12.6/8.12.6/Submit) id h04Nf7g3008069; Sun, 5 Jan 2003 08:41:07 +0900 (KST) Date: Sun, 5 Jan 2003 08:41:07 +0900 From: Kyunghwan Kim To: freebsd-net@FreeBSD.ORG Subject: What to do to make NIC driver mpsafe? Message-ID: <20030104234107.GA8041@ada.snu.ac.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=euc-kr Content-Disposition: inline User-Agent: Mutt/1.4i X-My-Present-Organization: Innuworks, Inc. Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Thanks to Alan Cox, kmem_malloc() is out from under Giant now. Then what should be done to make each NIC device drivers mpsafe? Can driver be mp-safe after adding if_dc style per-device data locking? -- Kyunghwan Kim redjade@ada.snu.ac.kr To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jan 4 16:10:59 2003 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7521837B401 for ; Sat, 4 Jan 2003 16:10:58 -0800 (PST) Received: from mailsrv.otenet.gr (mailsrv.otenet.gr [195.170.0.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5122C43EB2 for ; Sat, 4 Jan 2003 16:10:57 -0800 (PST) (envelope-from keramida@freebsd.org) Received: from gothmog.gr (patr530-a103.otenet.gr [212.205.215.103]) by mailsrv.otenet.gr (8.12.6/8.12.6) with ESMTP id h050Ag4V014170; Sun, 5 Jan 2003 02:10:45 +0200 (EET) Received: from gothmog.gr (gothmog [127.0.0.1]) by gothmog.gr (8.12.6/8.12.6) with ESMTP id h050Afnr000848; Sun, 5 Jan 2003 02:10:41 +0200 (EET) (envelope-from keramida@freebsd.org) Received: (from giorgos@localhost) by gothmog.gr (8.12.6/8.12.6/Submit) id h050AcfQ000847; Sun, 5 Jan 2003 02:10:38 +0200 (EET) (envelope-from keramida@freebsd.org) Date: Sun, 5 Jan 2003 02:10:38 +0200 From: Giorgos Keramidas To: Olivier Cherrier Cc: freebsd-net@freebsd.org Subject: Re: ipfw man page Message-ID: <20030105001038.GA587@gothmog.gr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On 2003-01-02 16:40, Olivier Cherrier wrote: > In the ipfw man page, we can read: > "To ease configuration, rules can be put into a file which is processed > using ipfw as shown in the first synopsis line." > > Shouldn't be the 'last synopsis line' ? You're right of course. I just fixed this in 5.0-CURRENT and will merge the change to STABLE in a while. Thanks! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message