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
