Hello,
>
> Admins using `once' rules are hopefully aware of this caveat already,
> but now the checksum actually indicates out-of-sync rulesets and does
> no longer present the same checksum for different rulesets.
>
> Feedback? OK?
>
>
OK sashan@
On Mon, Jul 20, 2020 at 05:07:03PM +0200, Klemens Nanni wrote:
> On Mon, Jul 20, 2020 at 01:14:00PM +0200, Alexandr Nedvedicky wrote:
> > I took a closer look at your change and related area. Below is an alternate
> > way to fix the bug you've found.
> Thanks for bringing it up again, I forgot to
On Mon, Jul 20, 2020 at 01:14:00PM +0200, Alexandr Nedvedicky wrote:
> I took a closer look at your change and related area. Below is an alternate
> way to fix the bug you've found.
Thanks for bringing it up again, I forgot to reply earlier.
> there are few details worth to note:
>
> ptr_arr
Hello Klemens.
I took a closer look at your change and related area. Below is an alternate
way to fix the bug you've found.
there are few details worth to note:
ptr_array matters to main ruleset only, because it is the only
ruleset covered by MD5 sum for pfsync.
it looks like we s
Hello Klemens,
> `ptr_array' is allocated momentarily through mallocarray(9) and gets
> filled with the TAILQ entries, the sole user pfsync(4) can then access
> the list of rules by index to simply pick the n-th rule in a ruleset
> during state insertion.
>
> I came here due to the zero size in
Each ruleset's rules are stored in a TAILQ called `ptr' with `rcount'
representing the number of rules in the ruleset; `ptr_array' points to
an array of the same length:
struct pf_ruleset {
struct {
...
struct {
