From owner-freebsd-questions@FreeBSD.ORG Sat May 30 03:13:34 2009 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C65F9106564A for ; Sat, 30 May 2009 03:13:34 +0000 (UTC) (envelope-from scs@eecs.berkeley.edu) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by mx1.freebsd.org (Postfix) with ESMTP id ACD1C8FC08 for ; Sat, 30 May 2009 03:13:34 +0000 (UTC) (envelope-from scs@eecs.berkeley.edu) Received: from [192.168.1.13] (adsl-75-18-223-100.dsl.pltn13.sbcglobal.net [75.18.223.100]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.3/8.13.5) with ESMTP id n4U3DW3U024044 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Fri, 29 May 2009 20:13:34 -0700 (PDT) Message-Id: <9DCE53EA-E680-48C3-BF7F-A5AAC656EB6D@eecs.berkeley.edu> From: Steven Schlansker To: freebsd-questions@freebsd.org In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 29 May 2009 20:13:27 -0700 References: <89C182FE-81B9-474E-84EA-FBB6F68C4E75@eecs.berkeley.edu> <200905292001.02072.mel.flynn+fbsd.questions@mailing.thruhere.net> <200905292244.37398.mel.flynn+fbsd.questions@mailing.thruhere.net> X-Mailer: Apple Mail (2.935.3) Subject: Re: pfsync in GENERIC? X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 May 2009 03:13:35 -0000 On May 29, 2009, at 5:29 PM, Michael Powell wrote: > Steven Schlansker wrote: > > [snip] > > A custom kernel can free up a little RAM, and maybe boot a little > sooner, > but it won't produce any earth shattering differences. I think most > do it to > 'shrink' down and eliminate anything which is not required for a > particular > piece of hardware. It decreases the possibility of something unneeded > causing a problem, and enhances problem resolution by making the > list of > potential culprits smaller. Yeah, that's basically how I felt as well. However as to the "something unneeded causing a problem" I must say I've never had a GENERIC kernel fail due to some unneeded device driver, but I've definitely had a custom built kernel fail because of some tunable or driver I misconfigured! > > > >> I'm just thinking that since pf is included in the base distribution, >> there's enough people that use it that it's worth including. It >> seems >> that pfsync would be a negligible addon, and much more attractive due >> to the lack of support for building it as a module. > > IIRC, quite a while back IPFW was the default firewall and was > included in > GENERIC by default. With the advent of IPFILTER and PF we now have 3 > to > choose from. Since theoretically(?) each should be usable as modules > and > user freedom/choice are paramount, I believe it was decided to > remove any > default firewall from the GENERIC kernel to enable a user to simply > load the > module of their choice without needing to do a kernel re-compile > first. In > other words, flexibility. That makes perfect sense and answers my question. I hadn't realized that there were alternatives to pf and that people still actively used them. > > >> Anyway, if I have further questions about pfsync in particular I >> guess >> I'll go ask -pf. I may have some free time coming up; maybe I'll >> even >> try my hand at hacking on the kernel and see if I can't make it build >> as a module... (would that be a semi-reasonable project for someone >> with light familiarity with kernel coding? I've coded up Linux >> kernel >> modules before, but haven't worked in-tree on a "real" OS) >> > > I believe the module situation may be a known entity. Consult the PR > bug > reports for more details. At some point a dev may take care of the > situation > and it will just show up in some future release. There is no PR apparently; I shall file one. > > > Should you desire to "hack" into it yourself and succeed the devs will > welcome the patch/diffs for perusal and testing provided you go > about it the > right way. Advancing the state of FreeBSD is always a plus, and I as > a user > salute all those who strive and work towards making FreeBSD a better > OS. I like to try to be one of the more useful retards on the internet ;) I'm hopeful that getting it to work at least for the unicast setup shouldn't be too hard; granted I haven't perused the code yet...