From owner-freebsd-ipfw@FreeBSD.ORG Wed Mar 10 18:48:16 2010 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 975D9106564A for ; Wed, 10 Mar 2010 18:48:16 +0000 (UTC) (envelope-from julian@elischer.org) Received: from out-0.mx.aerioconnect.net (out-0-7.mx.aerioconnect.net [216.240.47.67]) by mx1.freebsd.org (Postfix) with ESMTP id 7B4D58FC0C for ; Wed, 10 Mar 2010 18:48:16 +0000 (UTC) Received: from idiom.com (postfix@mx0.idiom.com [216.240.32.160]) by out-0.mx.aerioconnect.net (8.13.8/8.13.8) with ESMTP id o2AIPODC022136; Wed, 10 Mar 2010 10:25:24 -0800 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id 7A5B32D6011; Wed, 10 Mar 2010 10:25:23 -0800 (PST) Message-ID: <4B97E412.1050506@elischer.org> Date: Wed, 10 Mar 2010 10:25:22 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: n j References: <92bcbda51003100912k25facb5cxc9047105c91a4022@mail.gmail.com> In-Reply-To: <92bcbda51003100912k25facb5cxc9047105c91a4022@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Cc: freebsd-ipfw@freebsd.org, FreeBSD Net Subject: Re: IPFIREWALL_FORWARD X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2010 18:48:16 -0000 n j wrote: > Hello, > > although this has probably been asked before, could anyone point me to > some relevant information about why fwd/forward requires kernel > recompile, i.e. it's not been made a kernel module? This prevents me > from using freebsd-update and forces me to upgrade from source which - > even though we all like and love building from source, ofcourse :) - > is quite more complicated than the binary upgrade. > > Thanks, because when I first committed it I knew that as it broke some expected behaviour and added some instructions to the path for all incoming and outgoing packets, that if I didn't make it an option, I would never be allowed to commit it.. since then the same reasons have continued.. it adds several tests, not all of which are cheap, to the packet path. We could make is dependent on some sysctl or something to take out the most expensive tests.. but we really need to look at the overall picture of 'extensions' and whether there is a general way to handle them.