Date: Sat, 31 May 1997 02:36:37 +1000 (EST) From: proff@suburbia.net To: kuku@gilberto.physik.RWTH-Aachen.DE (Christoph Kukulies) Cc: ipfilter@postbox.anu.edu.au Subject: Re: IPFILTER kernel woes (FreeBSD 3.0-current) Message-ID: <19970530163638.5041.qmail@suburbia.net> In-Reply-To: <199705301607.SAA19122@gil.physik.rwth-aachen.de> from Christoph Kukulies at "May 30, 97 06:07:37 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
>
> I'm biting through and having got around one hurdle another one piles up:
>
> My kernel options is IPFILTER (not IPFILTER_LKM - maybe that's
> making things more weird). Anyone I wonder if anyone has gotten
> through compiling a FreeBSD-3.0 of today IPFILTER kernel yet.
>
> This is what I'm getting now:
>
> cc -c -O -Wreturn-type -Wcomment -Wredundant-decls -Wimplicit -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -nostdinc -I- -I. -I../.. -I../../../include -DGUSMAX -DDEVFS -DIPFILTER_LOG -DIPFILTER -DIPDIVERT -DUSER_CONFIG -DCOMPAT_43 -DMSDOSFS -DMFS -DNFS -DFFS -DINET -DKERNEL -include opt_global.h ../../netinet/mln_ipl.c
> ../../netinet/mln_ipl.c: In function `ipl_remove':
> ../../netinet/mln_ipl.c:189: too few arguments to function `VOP_LOCK'
> ../../netinet/mln_ipl.c:197: too few arguments to function `VOP_LOCK'
> ../../netinet/mln_ipl.c:205: too few arguments to function `VOP_LOCK'
> *** Error code 1
>
> Stop.
>
> --
> Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de
This is because VOP_LOCK takes three arguments, starting with
4.4BSD-lite2. I didn't like this use of vnodes to create and remove
/dev/ip{l,nat,state}, each time the module is loaded/unloaded,
which is why I didn't include them when I wrote mlf_ipl.c
(ipfilter-proff-final2.shar etc). It strikes me as needlessly
complex, and crossing domains (i.e it is not proper for network
software to be messing with the file system), and interfering with
user defined policy (tripwiring, write-protecting etc of /dev). If
there is no agreed on assigned major number - and there *is* in
the case of {Net,Free,Open}BSD) - the proper course is to
have a user-level program grovel through kmem, or otherwise examine
the major number resource, and execute a standard mknod, not the
VOP_* horror we currently see.
Cheers,
Julian.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970530163638.5041.qmail>