tech-net archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: packet filters for NetBSD in the future



At Thu, 19 Feb 2009 10:35:04 -0500, Thor Lancelot Simon wrote:
Subject: Re: packet filters for NetBSD in the future
> 
> On Thu, Feb 19, 2009 at 12:12:19PM -0000, yancm%sdf.lonestar.org@localhost 
> wrote:
> > 
> > Darren occasionally updates the NetBSD version with his base code
> > releases.
> 
> Unfortunately, as far as I can tell this is not so.  That is not to say
> that it would not be a good thing if it were so, nor that Darren has any
> obligation to make it so -- but it's not so.

Well, Darren did do the updates to at least two revisions since IPF was
relegated off to the /usr/src{/sys}/dist area, the most important from
this perspective perhaps also being the most recent:

date: 2008/05/20 07:08:06;  author: darrenr;  state: Exp;  lines: +172 -2
Pullup IPFilter 4.1.29 from the vendor branch to HEAD.
See src/dist/ipf/HISTORY for a list of bug fixes since 4.1.23 (although
a few are already in NetBSD)

date: 1999/12/28 07:40:12;  author: darrenr;  state: Exp;  lines: +11 -0
update ipfilter code to 3.3.6

Darren also did do lots more direct work on IPF directly in the NetBSD
repository prior to IPF being moved into the dist areas thus I think
fully justifying Gene's remarks.


I too vote for IPF being my ongoing favourite firewall component, though
I've some interest in learning at least enough of PF to see if it can do
the kinds of things I need without adding new headaches.  I personally
haven't had any problem using IPF with Altq and vice versa, though
perhaps it could work more efficiently if it didn't have to peek at
packet headers again.  Altq's functionality could fairly easily be
merged into IPF I think.


As for why IPF hasn't been pulled up to the netbsd-4 branch yet is
certainly not something I can figure out.  Perhaps it's as simple as
nobody having made a proper request to the release engineering team yet?

Personally I think _everything_ identified as a "fix", including
upgrades of 3rd party code that don't rely on other new features, should
ALWAYS be merged from -current to _all_ relevant releases in a timely
fashion (eg. N weeks after commit and no new bug reports where N
represents some time representative of the complexity of the change).

-- 
                                                Greg A. Woods

H:+1 416 218-0098 W:+1 416 489-5852   VE3TCP    RoboHack 
<woods%robohack.ca@localhost>
Planix, Inc. <woods%planix.com@localhost>       Secrets of the Weird 
<woods%weird.com@localhost>

Attachment: pgpESoSQmKZAz.pgp
Description: PGP signature



Home | Main Index | Thread Index | Old Index