Re: NPF and PF

[Hector <technet%netdog.org@localhost>]

* Robert Swindells <rjs%fdy2.co.uk@localhost> wrote, on 2020-12-18 06:41:
>
> Hector <technet%netdog.org@localhost> wrote:
> >* Martin Husemann <martin%duskware.de@localhost> wrote, on 2020-12-18 05:47:
> >> On Fri, Dec 18, 2020 at 05:38:03AM -0600, Hector wrote:
> >> > * <technet%netdog.org@localhost> wrote, on 2020-12-15 22:41:
> >> > > A couple of years ago this bold note was added at the top of pf(4) man page:
> >> > >
> >> > >   The NetBSD version of PF is obsolete, and its use is strongly
> >> > >   discouraged.  Use npf(7) instead.
> >> >
> >> > Why is use of PF strongly discouraged?
> >>
> >> Basically what the note says: the verison of PF in the NetBSD tree is
> >> *ancient* and unmaintained.
> >>
> >> > Are there plans or thoughts to remove it from NetBSD?
> >>
> >> Yes - as soon as npf(7) is considered to be mature enough to cover the
> >> relevant use cases, both ipf and pf will be removed.
> >
> >Should I be concerned about how is decided what is considered relevant
> >use cases?
> >
> >Is it likely that some current PF users (like me) may have use cases
> >which the decision makers conclude are not relevant?
>
> Are you getting anywhere with writing up the problems you found with
> npf(7) ?
>
> Just providing your list of IP addresses to block could be a start.

Here you can download a minimal npf.conf which tries to load a table of
about 52,000 subnets.

http://lab.netdog.org/npf.conf
http://lab.netdog.org/ip-blacklist-52k.gz

On a 4-core machine with 4GB of memory, this command:

 # npfctl reload

chewed in silence for about 7 minutes, and then produced this output:

  npfctl: �8

With a larger table, the run time is longer, and the garbage output is
different, being longer. I'll guess because the random memory being
printed happens to have a longer sequence of non-null bytes before a zero
byte terminates the print.

I'll be interested to hear if this is helpful.