Re: npf in -current amd64 (7 Mar 2018) now cannot use a "ruleset" multiple times

[Frank Kardel <kardel%kardel.name@localhost>]

Hi!

It may be a fix/safeguard for a reload prolem I discussed with rmind@ 
and christos@ in May 2017:

To quote my analysis:
> OK, I got the time to dig into it and found the cause.
>
> Silly me has (now had) a configuration like this:
>
> group "a" on if1 {
>   ruleset "blacklistd"
>   ...
> }
>
> group default {
>   ruleset "blacklistd"
>   ...
> }
>
> This leads to two group entries in the rs_dynamic list refencing the same named dynamic ruleset.
> Dynamic rulesets are matched by name in a first found basis.
> rs_dynamic[0] has the ruleset reference for the default group (last entry in the config file).
> rs_dynamic[1] has the rulesat reference for the interface specific group
> When reloading oldconfig->rs_dynamic[0] will be re-parented correctly to the new first group referencing the rule name "blacklistd".
> For the second new interface specific group the old first group is looked up as parent (first match of old group list). That's when
> the KASSERT fires as these dynamic rules have already been re-parented to the new configuration.
>
> This also explains why I see no effect of the dynamic rules. dynamic rules are added by name and thus to the first matching entry. This is the ruleset reference from the default group - bummer: one name but two instances.
>
> So we have a semantic issue here - following questions arise:
>     1) can groups only reference unique dynamic ruleset names? This needs to be enforced then.
>     2) If dynamic rulesets are to be shared then the parent notion needs to be reworked/redesigned.
>
> Best regards,
>   Frank 

Looks like solition 1) was choosen for now.

Seems you just didn't trip over the underlying issue. I have not closely 
followed NPF lately so I don't know the actual fix status of NPF. As in 
the example above I also had the idea of re-using dynamic rulesets - 
maybe this can be implemented as I still think it is useful. For now my 
workaround was to have several rulesets, but this is just good enough to 
work with blacklistd.

Frank

On 03/07/18 05:46, Geoff Wing wrote:
> Hi,
> npf previously had no issues using a "ruleset" in multiple groups, however
> it now has a problem and fails with
>
> 	npfctl: (re)load failed: some table has a duplicate entry?
>
> The following is a minimal npf.conf to illustrate with it failing due to
> the second ``ruleset "blacklistd"'' causing the issue:
> -----
> 	$if1_if = inet4(vmx0)
> 	$if2_if = inet4(vmx1)
>
> 	alg "icmp"
>
> 	group "foo" on $if1_if {
> 		ruleset "blacklistd"
> 	}
> 	group "bar" on $if2_if {
> 		ruleset "blacklistd"
> 	}
>
> 	group default {
> 		pass final on lo0 all
> 		block all
> 	}
> -----
>
> I haven't investigated further yet.  Ring any bells with anyone?
>
> System is amd64 -current.
>
> Regards,
> Geoff