Well, I'm sure you hear much more complaining about problems than
appreciation when things go smoothly, so I for one would like to thank you
for your great work on ipfilter.

I cast my vote (not that its worth much) for keeping ipfilter up to date.
Dealing with the changes caused by updating your kernel is what tracking
-current is all about, isn't it?  Couldn't there potentially be the same
problem with any userland program that relies on kernel APIs which aren't
gaurenteed to be backwords compatable?  I'm not sure if its still the case
(does it use procfs now?), but I know ps used to stop working sometimes
after building a new kernel.

Anyway, if a majority of people are of the oppinion that its better NOT to
update ipfilter, then I'll just get in the habit of installing the latest
versions manually myself.

Couldn't ipf be loaded from an lkm so that the lkm and userland could be
easily kept in sync?

Thanks,
	Rick

> In some email I received from Michael Graff, sie wrote:
> > Not to ask the obvious question, but isn't the author of ipfilter a
> > NetBSD developer?  I may be wrong, but I thought maintaining ipfilter
> > was why he was given developer access in the first place...
> >
> > Or am I totally confused here?
>
> I forget but maybe I was and then someone else decided they knew how
> ipfilter should be installed in netbsd and I didn't and that resulted
> in a spat of sorts.
>
> > Rick Byers <rb-netbsd@BigScaryChildren.net> writes:
> >
> > > Is there some reason (other than no-one has stepped forward to do it),
> > > that NetBSD-current hasn't been tracking ipfilter releases?  Atleast that
> > > way we'd never get horribly out of date (new releases would have an
> > > up-to-date ipfilter), and we'd have less work to do to pull up patches to
> > > -release branches.  As it stands right now, -current is using an ipfilter
> > > thats almost a year old.
> > >
> > > If its simply that no-one has volunteered to do the work, then I will
> > > volunteer to take a stab at it and submit patches.
>
> People hate it being upgraded because it means they have to compile the
> various programs (ipf, ipnat, ipfstat, ipmon) and install them at the
> same time as the kernel.  Given that generally these change too, it
> should be no big deal but for whatever reason, it would seem quite a
> few people (mostly developers) run ipfilter enabled kernels that are
> much more recent than their corresponding userland.  So in short, nobody
> (except end users, it seems) wants it updated that often and then the time
> lag involved in the person maintaining it getting around to it often ends
> up with me saying "no wait for the next rev" (for good reason) and we
> go back to the start, again.
>
> Darren
>