Current-Users archive

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

Re: NPF on 8.1 and pcap-filter expressions

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.

                                Michael van Elst
                                "A potential Snark may lurk in every tree."

Home | Main Index | Thread Index | Old Index