From owner-freebsd-net@FreeBSD.ORG Thu Jun 26 18:49:39 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A2AD91065674 for ; Thu, 26 Jun 2008 18:49:39 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from shrew.net (206-223-169-85.beanfield.net [206.223.169.85]) by mx1.freebsd.org (Postfix) with ESMTP id 43DD48FC25 for ; Thu, 26 Jun 2008 18:49:39 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from localhost (wm-ca.hub.org [206.223.169.82]) by shrew.net (Postfix) with ESMTP id CB5AB79E2CA; Thu, 26 Jun 2008 13:49:38 -0500 (CDT) Received: from shrew.net ([206.223.169.85]) by localhost (mx1.hub.org [206.223.169.82]) (amavisd-new, port 10024) with ESMTP id 32416-09; Thu, 26 Jun 2008 18:49:38 +0000 (UTC) Received: from hole.shrew.net (cpe-70-113-206-103.austin.res.rr.com [70.113.206.103]) by shrew.net (Postfix) with ESMTP id 6992179E26A; Thu, 26 Jun 2008 13:49:37 -0500 (CDT) Received: from hole.shrew.net (localhost [127.0.0.1]) by hole.shrew.net (8.14.2/8.14.2) with ESMTP id m5QInYAR055262; Thu, 26 Jun 2008 13:49:34 -0500 (CDT) (envelope-from mgrooms@shrew.net) Received: (from www@localhost) by hole.shrew.net (8.14.2/8.14.2/Submit) id m5QInY1L055261; Thu, 26 Jun 2008 13:49:34 -0500 (CDT) (envelope-from mgrooms@shrew.net) X-Authentication-Warning: hole.shrew.net: www set sender to mgrooms@shrew.net using -f To: brooks@freebsd.org MIME-Version: 1.0 Date: Thu, 26 Jun 2008 13:49:34 -0500 From: mgrooms Organization: Shrew Soft Inc In-Reply-To: <48ca67dd60c19f94b4f21bbe88854da7@localhost> References: <48ca67dd60c19f94b4f21bbe88854da7@localhost> Message-ID: <86c7b60b19e63e9188701611ac0f6f17@localhost> X-Sender: mgrooms@shrew.net User-Agent: RoundCube Webmail/0.1-rc1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD NAT-T patch integration X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mgrooms@shrew.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2008 18:49:39 -0000 > On Wed, Jun 25, 2008 at 04:30:36PM -0400, Scott Ullrich wrote: >> On Wed, Jun 25, 2008 at 4:24 PM, Julian Elischer > wr= > ote: >> > do you have the ability to test this? >>=20 >> Absolutely. Is this the only thing from preventing it being merged > into= > HEAD? > > No. It's a large and complex patch an a subsystem (ipsec) that must not > be broken. We're a bit shorthanded in this area, but people have been > working on this for quite some time and IIRC aren't fully comfortable > with the patch yet. Every time the question of integrating the NAT-T patches is brought up, a post list this is usually where this thread dies. Forgive me for my persistence :) >From this thread and previous threads, its known that FreeBSD + NAT-T is being used in several production environments without issue. I use it myself to perform compatibility testing and have never encountered a problem with later versions of the patch. Not being a FreeBSD kernel developer, I can't comment on the correctness of the patch, only that it works well for me. So very respectfully, what needs to happen for this patch to be committed? FreeBSD is a great operating system with a great developer community. If the patch has been fully reviewed and problems have been found, what are they? If there is enough demand for this patch to be integrated, maybe other kernel developers would lend a hand in resolving the issues if they were made public. Both of the threads I started on this list were answered by developers willing to pitch in. If the patch hasn't been fully reviewed and its a lack of man hours required, again, maybe someone can lend a helping hand in this regard as well. Perhaps a full review with the intent to commit is happening right now but its just not public knowledge. A reply to this effect would silence annoying people like myself :) I'm not suggesting it should be MFCd tomorrow. A kernel source commit log occasionally suggests that a patch is being integrated so that it can receive more testing by the public at large. Maybe committing it to head is the best action to take? Its a compile time option for IPsec and another compile time option for NAT-T. Are we really talking about that much of a risk? I'm not trying to start a flame war here, but the patch has been floating around since before the 5.x days. There just seems to be a dark cloud hanging over it and I, and no doubt many others, really don't know why. Please help us understand these reasons and what can be done to help. Thanks, -Matthew