From owner-freebsd-pf@FreeBSD.ORG Sun Oct 2 18:52:25 2005 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6F09A16A41F for ; Sun, 2 Oct 2005 18:52:25 +0000 (GMT) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id C95B943D45 for ; Sun, 2 Oct 2005 18:52:24 +0000 (GMT) (envelope-from max@love2party.net) Received: from p54A3E18B.dip.t-dialin.net [84.163.225.139] (helo=donor.laier.local) by mrelayeu.kundenserver.de with ESMTP (Nemesis), id 0ML2ov-1EM8wY2uqC-0003zy; Sun, 02 Oct 2005 20:52:14 +0200 From: Max Laier To: freebsd-pf@freebsd.org Date: Sun, 2 Oct 2005 20:51:57 +0200 User-Agent: KMail/1.8.2 References: <20051002151642.GC76606@comp.chem.msu.su> In-Reply-To: <20051002151642.GC76606@comp.chem.msu.su> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1712844.fdpqWnkfRp"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200510022052.08240.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: Subject: Re: pf kernel module(s) X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Oct 2005 18:52:25 -0000 --nextPart1712844.fdpqWnkfRp Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Yar, On Sunday 02 October 2005 17:16, Yar Tikhiy wrote: > While making an rc.d script for pfsync as I had promised here, I > noticed that pf.ko didn't include support for pfsync. Closer study > revealed that it would be better to split pf.ko in separate modules > for pf itself, pflog, and pfsync. The reason is as follows. > > As MODULES_WITH_WORLD are about to depart for /dev/null soon, modules > should not rely on the opt_*.h files they create with their Makefiles > now: The configuration is to be obtained from the opt_*.h files in > the kernel build directory. Therefore it will not be possible to > include pflog or pfsync functionality in pf.ko unless it is in the > main kernel file, too, which is ridiculous. OTOH, having separate > pflog.ko and pfsync.ko would allow for the modules to be built > irrespective of the current kernel configuration. > > If the separation is not possible now, the pf.ko module should > include all the functionality irrespective of the DEV_PF, DEV_PFLOG, > or DEV_PFSYNC values found in opt_pf.h. As a matter of fact, a > modern FreeBSD device driver should rarely use DEV_FOO values in > its code because the inclusion of the driver source files in the > build process is the major sign of the driver being enabled, and > device instances should be created dynamically. Alas, OpenBSD > code doesn't seem to follow this trend, so I'd consider setting > NPFLOG and NPFSYNC to 1 statically if possible. There is one big issue with PFSYNC as a module. pfsync needs to register a= =20 kernel level multicast protocol. This is not (yet) possible at runtime, bu= t=20 needs to happen statically. So in order to use pfsync you need a pfsync=20 enabled kernel - and can just build in pfsync alltogether. All this makes = a=20 pfsync.ko pretty useless. The story for pflog is simply me reasoning that people don't usually want a= =20 firewall without logging. And if we know whether or not we have to log at= =20 compile time we can save (at least) one pointer deref per packet (and a lot= =20 of hook-in/hook-out logic as well). I am open to any improvement of the situation, just wanted to get out the=20 reasoning so you don't have to find out the hard way. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart1712844.fdpqWnkfRp Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBDQCxYXyyEoT62BG0RAuJ+AJ9GzcWJ50saYTYXrl2AoQlrIN40iwCeP4vC 46jnNe1aiL9oulO3vfPsiB4= =TFJr -----END PGP SIGNATURE----- --nextPart1712844.fdpqWnkfRp--