Date: Tue, 14 Dec 2004 07:51:03 -0800 From: Luigi Rizzo <rizzo@icir.org> To: Andre Oppermann <andre@freebsd.org>, freebsd-net@freebsd.org Subject: Re: per-interface packet filters, design approach Message-ID: <20041214075103.C78388@xorpc.icir.org> In-Reply-To: <20041214150520.GD684@empiric.icir.org>; from bms@spc.org on Tue, Dec 14, 2004 at 07:05:20AM -0800 References: <41BEF2AF.470F9079@freebsd.org> <20041214062010.A77933@xorpc.icir.org> <20041214150520.GD684@empiric.icir.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Dec 14, 2004 at 07:05:20AM -0800, Bruce M Simpson wrote: ... > Are there any nicer ways of telling IPFW v1 and v2 apart both at compile > time and run-time? Right now I do something like this:- With very high accuracy, at compile time you can say that ipfw2 is available from 4.7 and higher, and ipfw1 is _not_ available in 5.0 and above. At runtime, the easiest way is try issue an ipfw2 command and see if it returns an error or not. Note however that ipfw2 features increase over time. Atomic 'set' support was introduced in 4.9/5.2, and opcodes of minor importance came later. cheers luigi > %%% > AC_MSG_CHECKING(for an IPFW firewall build environment) > AC_LANG_SAVE > AC_LANG_C > AC_TRY_COMPILE([ > #include <stdlib.h> > #include <errno.h> > #include <sys/types.h> > #include <sys/socket.h> > #include <net/if.h> > #include <netinet/in.h> > #include <netinet/ip_fw.h> > ], > [ > int mysockopt = IP_FW_ADD; > #ifdef IPFW2 > #error IPFW2 defined (should not be defined for IPFW). Test failed. > #endif > ], > [AC_DEFINE(HAVE_FIREWALL_IPFW, 1, > [Define to 1 if you have an IPFW build environment]) > AC_MSG_RESULT(yes)], > [AC_MSG_RESULT(no)]) > AC_LANG_RESTORE > %%% > > The above test is for IPFW1. The equivalent test for IPFW2 simply flips > the sense of the #ifdef inside. This is not ideal because > <netinet/ip_fw.h> can exist in both flavours in the same system (albeit in > the case of FreeBSD 4.11, it will include the IPFW2 header instead if > IPFW2 is defined). > > No doubt the present IPFW documentation can be improved. What will soon > exist in XORP is something approximating an IPFW API. I may not have time > to do anything in this area, but what I'm doing for XORP could certainly > be re-used to some extent. > > Regards, > BMS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041214075103.C78388>