I tested the diff and while im not qualified to judge the code, it now behaves
like i would expect.
Thanks for working on this,
Regards.
> Klemens Nanni hat am 16. Oktober 2018 um 13:34 geschrieben:
>
>
> On Tue, Oct 16, 2018 at 10:03:01AM +0200, Alexandr Nedvedicky wrote:
> > I also wond
Hello,
> This comment is way too much, imho. How about this:
>
> Unless errors occured, stop iff any rule matched
> within quick anchors.
I'm fine with your proposal. You have my OK to commit
the fix.
thanks and
regards
sashan
On Tue, Oct 16, 2018 at 10:03:01AM +0200, Alexandr Nedvedicky wrote:
> I also wonder if we should apply same change to wildcard anchors here:
They need fixing as well, but I have yet to look into it.
> diff --git a/sys/net/pf.c b/sys/net/pf.c
> index 0bdf90a8d13..5a5c739773a 100644
> --- a/sys
Hello,
>
> In my understanding they do, but you are missing the point. Given the
> following ruleset:
>
> pass
> anchor quick {
> block inet6
> }
> block
>
> With the current fix ruleset-evaluation terminates after the anchor,
> before the last block even *if no ipv6-traffic was encounte
On 18-10-15 23:45:58, Alexandr Nedvedicky wrote:
> Hello,
>
> > That is still different from the original (2006) behaviour which
> > would terminate ruleset-evaluation IFF any rules inside the anchor
> > actually match.
>
> Perhaps I still misunderstand the whole anchor thing.
>
> let m
Hello,
> That is still different from the original (2006) behaviour which
> would terminate ruleset-evaluation IFF any rules inside the anchor
> actually match.
Perhaps I still misunderstand the whole anchor thing.
let me clarify the proposed change by two examples. Ruleset below allows
On 18-10-15 13:38:32, Alexandr Nedvedicky wrote:
> Hello,
>
> I just got back on-line after a week. Thank you all for detailed analysis.
> This particular bug, which Klemens tries to fix is caused by my commit 1.1024:
>
> - percpu anchor stacks
> we actually don't need to pre-allocate p
Hello,
I just got back on-line after a week. Thank you all for detailed analysis.
This particular bug, which Klemens tries to fix is caused by my commit 1.1024:
- percpu anchor stacks
we actually don't need to pre-allocate per_anchor_stack[], if we use
a 'natural' recursion, when
Henning Brauer(hb-openbsdt...@ml.bsws.de) on 2018.10.08 13:56:20 +0200:
> * Sebastian Benoit [2018-10-08 10:50]:
> > The quick in the anchor does not do anything by itself, it should just
> > "behave like all the rules inside the anchor had the quick keyword".
>
> no, that is *not* the intended s
* Sebastian Benoit [2018-10-08 10:50]:
> The quick in the anchor does not do anything by itself, it should just
> "behave like all the rules inside the anchor had the quick keyword".
no, that is *not* the intended semantic.
the intent is that ruleset evaluation is aborted if any rule inside
the a
Klemens Nanni(k...@openbsd.org) on 2018.10.07 19:41:22 +0200:
> On Fri, Oct 05, 2018 at 11:53:08PM +0200, Klemens Nanni wrote:
> > On Fri, Oct 05, 2018 at 10:38:48PM +0200, Fabian Mueller-Knapp wrote:
> > > If i read man correctly it means "evaluate the rules inside and stop if
> > > any rule withi
On Fri, Oct 05, 2018 at 11:53:08PM +0200, Klemens Nanni wrote:
> On Fri, Oct 05, 2018 at 10:38:48PM +0200, Fabian Mueller-Knapp wrote:
> > If i read man correctly it means "evaluate the rules inside and stop if
> > any rule within matched".
> While it's own description is quite clear and unambigiou
On Sat, Oct 06, 2018 at 01:07:33PM +0200, Sebastian Benoit wrote:
> I would find it surprising if an empty anchor matches anything.
> And i find the wording above clear in this regard:
>
> ... ruleset evaluation will terminate when the anchor is exited if
> the packet is matched by any
Klemens Nanni(k...@openbsd.org) on 2018.10.05 23:53:08 +0200:
> On Fri, Oct 05, 2018 at 10:38:48PM +0200, Fabian Mueller-Knapp wrote:
> > If i read man correctly it means "evaluate the rules inside and stop if
> > any rule within matched".
> While it's own description is quite clear and unambigious
Klemens Nanni wrote:
> On Fri, Oct 05, 2018 at 11:53:08PM +0200, Klemens Nanni wrote:
> > While rules within the anchor do not match, the anchor itself does.
> > After all, it is a rule itself just like `pass' or `block', hence your
> > ruleset's second rule `anchor quick' matches every packet an
On Fri, Oct 05, 2018 at 11:53:08PM +0200, Klemens Nanni wrote:
> While rules within the anchor do not match, the anchor itself does.
> After all, it is a rule itself just like `pass' or `block', hence your
> ruleset's second rule `anchor quick' matches every packet and therefore
> stops evaluation.
On Fri, Oct 05, 2018 at 10:38:48PM +0200, Fabian Mueller-Knapp wrote:
> If i read man correctly it means "evaluate the rules inside and stop if
> any rule within matched".
While it's own description is quite clear and unambigious:
quick If a packet matches a rule which has the quick option
Hello,
Sorry for the late reply. I just tested the fix with the latest snapshot
and think the behaviour is still not correct:
On 18-10-04 01:25:09, Klemens Nanni wrote:
> On Sat, Sep 29, 2018 at 10:44:41PM +0200, Klemens Nanni wrote:
>
> `anchor quick' means "evaluate the rules inside but stop a
I just committed the fix, thanks.
Hi Klemens,
> > > Do i misread the manpage somehow?
> > No, this is a bug.
> Allow me a bit of rubber ducking to explain this bug and ease review:
>
> The kernel evaluates the ruleset pretty much like we read it: Down to
> bottom until quick appears or an error occurs in which case we stop
> e
On Sat, Sep 29, 2018 at 10:44:41PM +0200, Klemens Nanni wrote:
> On Sat, Sep 29, 2018 at 06:17:05PM +0200, Fabian Mueller-Knapp wrote:
> > I have the following pf.conf:
> >
> > anchor quick {
> > pass
> > }
> > block
> >
> > # pfctl -sr
> > anchor quick all {
> > pass all flags S/SA
> > }
> >
21 matches
Mail list logo
