Re: NPF on 8.1 and pcap-filter expressions
On Fri, Aug 23, 2019 at 09:56:47AM +0200, Frank Kardel wrote: > And what mechanisms does NPF provide to access the broadcast address except > for manually coding it - did I overlook something? Since we can do inet4(),inet6() or ifaddrs() we can probably add ifmask4() or ifmask6(). But we can also "manually" code it if that means to just fill a template by whatever program provides the data (dhcpcd or some other network manager), npf lets you use variables or even tables for that. -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: NPF on 8.1 and pcap-filter expressions
On 08/22/19 17:44, Michael van Elst wrote: 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, But it would allow the npfctl reload strategy after changing things. Though the reload strategy opens a small time frame where installed filter rules do not match the interface configuration. 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. Yes. But we currently have the situation the NPF does not seem to have any means right now to handle netmasks and broadcasts related to interface addresses. As NPF works at the IP level I think supporting netmask/broadcast/network should be part of NPF even if we start out with the static solution in npfctl and supporting a dynamic one later. In many situations it might be easier to just match the list of broadcast addresses without pcap-filter. And what mechanisms does NPF provide to access the broadcast address except for manually coding it - did I overlook something? (I am currently looking in 8.1 as that is productional an try to convert our pf router configuration to NPF with very limited success right now - more on that in another thread). 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 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. Leaving small time windows of inconsistent configurations. I think it depends more on the mechanisms/primitives we can think of for efficient dynamic access to interface properties. 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. Yes, interface descriptions are the right/better thing here. But how do we handle groups for an interface description when these interfaces appear and disappear? Should be compile these groups anyway? How do we handle groups for interface names and interface descriptions - looks like we might have two different groups for one interface - which rule do we run? This needs more thought or just a decision to use either interface names or interface descriptions. Greetings, Greetings Frank
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 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: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: NPF on 8.1 and pcap-filter expressions
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 in order to reduce the configuration spread between interface configuration and NPF configuration. This would be useful 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 NPF configuration. Also partial interface names like tun for tun0...tun could be helpful especially as these interfaces can come and go. Am I dreaming too much ? Frank On 08/22/19 13:22, Michael van Elst wrote: kar...@netbsd.org (Frank Kardel) writes: I just tripped over: pass in final pcap-filter "ip multicast or ip6 multicast" flawlessly compiles ... but: pass in final pcap-filter "ip broadcast" gives in "npf validate" /etc/npf.conf:xx:9: invalid pcap-filter(7) syntax although man 7 pcap-filter says otherwise and tcpdump gladly accepts ip broadcast. from libpcap: case Q_IP: /* * We treat a netmask of PCAP_NETMASK_UNKNOWN (0x) * as an indication that we don't know the netmask, and fail * in that case. */ if (cstate->netmask == PCAP_NETMASK_UNKNOWN) bpf_error(cstate, "netmask not known, so 'ip broadcast' not supported"); npfctl compiles the filter expression with PCAP_NETMASK_UNKNOWN, there is no netmask it could apply.
Re: NPF on 8.1 and pcap-filter expressions
kar...@netbsd.org (Frank Kardel) writes: >I just tripped over: > pass in final pcap-filter "ip multicast or ip6 multicast" >flawlessly compiles ... but: > pass in final pcap-filter "ip broadcast" >gives in "npf validate" >/etc/npf.conf:xx:9: invalid pcap-filter(7) syntax >although man 7 pcap-filter says otherwise and tcpdump gladly accepts ip >broadcast. from libpcap: case Q_IP: /* * We treat a netmask of PCAP_NETMASK_UNKNOWN (0x) * as an indication that we don't know the netmask, and fail * in that case. */ if (cstate->netmask == PCAP_NETMASK_UNKNOWN) bpf_error(cstate, "netmask not known, so 'ip broadcast' not supported"); npfctl compiles the filter expression with PCAP_NETMASK_UNKNOWN, there is no netmask it could apply. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
NPF on 8.1 and pcap-filter expressions
I just tripped over: pass in final pcap-filter "ip multicast or ip6 multicast" flawlessly compiles ... but: pass in final pcap-filter "ip broadcast" gives in "npf validate" /etc/npf.conf:xx:9: invalid pcap-filter(7) syntax although man 7 pcap-filter says otherwise and tcpdump gladly accepts ip broadcast. What needs to be fixed? Frank
