From owner-freebsd-net@FreeBSD.ORG Wed Jan 3 08:07:09 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1A94716A403 for ; Wed, 3 Jan 2007 08:07:09 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from smtp.zeninc.net (reverse-25.fdn.fr [80.67.176.25]) by mx1.freebsd.org (Postfix) with ESMTP id D2B6213C455 for ; Wed, 3 Jan 2007 08:07:08 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: by smtp.zeninc.net (smtpd, from userid 1000) id 46C613F17; Wed, 3 Jan 2007 09:07:05 +0100 (CET) Date: Wed, 3 Jan 2007 09:07:05 +0100 From: VANHULLEBUS Yvan To: freebsd-net@freebsd.org Message-ID: <20070103080704.GA486@zen.inc> References: <20070102141351.GA1604@jayce.zen.inc> <369726.48848.qm@web51904.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <369726.48848.qm@web51904.mail.yahoo.com> User-Agent: All mail clients suck. This one just sucks less. Subject: Re: NAT Taversal bug in kernel patch ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jan 2007 08:07:09 -0000 On Tue, Jan 02, 2007 at 08:28:01PM -0800, ashoke saha wrote: > not new. 6/7 months old. Ok, please try with the latest version of the patch, it should be fixed. > Also, quite sometime back 1 yr .... looked like there > are issues in PFKEY interface in scalibility . if you > create more than 300 ipsecpolicy and ipsec SA's PFKEY > used to fail as kernel was using one mbuf cluster (2K > or 4k dont remmember) for each policy or SA. That way > it was running out of mbuf cluster limit for process. Yep. > maybe that is also fixed. There is no public patch afaik. However, I have 2 solutions to fix that: - There is a "bug" in a macro in socket code. basically, some long vars are converted to ints to make some checks, then the result is converted to a long again. I already posted a quick patch here a few monthes ago, I'll send it as a pr as soon as I'll have time to do a complete and clean fix (I don't remember exactly what , but I noticed that some calls to that macro would need to be fixed when the macro is fixed). This solution reduces the problem, but doesn't really fix it (but there is *really* a bug which needs to be fixed here). - The way SPD / SAs are dumped between kernel/userland is ugly, because you use 1 message for each entry. We solved the problem by creating a custom PFKey request: userland sends a buffer address/size to the kernel, and the kernel will fill this buffer with results, then will send ONE message to the userland, with the used size. This works well, but is really not RFC compliant ! Yvan. -- NETASQ http://www.netasq.com