Re: NPF on 8.1 and pcap-filter expressions

[Michael van Elst <mlelstv%serpens.de@localhost>]

On Thu, Aug 22, 2019 at 04:02:43PM +0200, Frank Kardel wrote:
> I found that in the mean time - thanks for looking.
> 
> That leaves me probably with no generic way in npf to detect/determine
> broadcast addresses.
> 
> NPF does not seem to have PF's :network/:broadcast/:peer mechanism and all
> we
> 
> can access is the IP layer information.
> 
> This looks a bit clumsy.
> 
> Ideally I would like a generic way to determine networks, broadcast
> addresses and maybe peers statically and dynamically

npfctl already reads IP information from interfaces, also reading the
netmask wouldn't be much of a problem. It wouldn't be magic though,
rules aren't necessarily bound to an interface, so pcap-filter() would
need an explicit netmask argument, which makes it obvious that the
filter might not work correctly if applied to an interface with a
different netmask.

In many situations it might be easier to just match the list of broadcast
addresses without pcap-filter.


> for my case where the IP address/network is configured via DHCP and I'd
> rather like to avoid dhcpcd's hooks to rewrite/reload the
> Also partial interface names like tun for tun0...tun<n> could be helpful
> especially as these interfaces can come and go.

That's more a question on how much code should be pushed into the
kernel. I'd rather trigger userland to reload the config.

Using partial interface names doesn't sound like a security feature to
me. Matching the new interface descriptions instead is probably safer
but then descriptions must also be supported by the program that manages
the interfaces.


Greetings,
-- 
                                Michael van Elst
Internet: mlelstv%serpens.de@localhost
                                "A potential Snark may lurk in every tree."