From: Phil Sutter <phil@nwl.cc>
To: Florian Westphal <fw@strlen.de>
Cc: Martin Gignac <martin.gignac@gmail.com>,
netfilter@vger.kernel.org,
netfilter-devel <netfilter-devel@vger.kernel.org>
Subject: Re: Unable to create a chain called "trace"
Date: Wed, 17 Feb 2021 20:59:37 +0100 [thread overview]
Message-ID: <20210217195937.GA22016@orbyte.nwl.cc> (raw)
In-Reply-To: <20210212122007.GE2766@breakpoint.cc>
Hi,
On Fri, Feb 12, 2021 at 01:20:07PM +0100, Florian Westphal wrote:
> Phil Sutter <phil@nwl.cc> wrote:
> > I didn't find a better way to conditionally parse two following args as
> > strings instead of just a single one. Basically I miss an explicit end
> > condition from which to call BEGIN(0).
>
> Yes, thats part of the problem.
>
> > > Seems we need allow "{" for "*" and then count the {} nests so
> > > we can pop off a scanner state stack once we make it back to the
> > > same } level that we had at the last state switch.
> >
> > What is the problem?
>
> Detect when we need to exit the current start condition.
I explored my approach further but ended up in an ugly situation due to
the use of 'set' keyword in rules: My code is not context-aware, so upon
recognizing 'set' keyword it switches to spec-condition. I can't simply
detect preceding command-keywords due to them being implicit in nested
notation.
> We may not even be able to do BEGIN(0) if we have multiple, nested
> start conditionals. flex supports start condition stacks, but that
> still leaves the exit/closure issue.
>
> Example:
>
> table chain {
> chain bla { /* should start to recognize rules, but
> we did not see 'rule' keyword */
My code worked with this after enabling detection of '{' in all
conditions and making it call BEGIN(0) (regardless of nspec value).
> ip saddr { ... } /* can't exit rule start condition on } ... */
Maybe we could track nesting block depth in a simple counter?
> ip daddr { ... }
> } /* should disable rule keywords again */
>
> chain dynamic { /* so 'dynamic' is a string here ... */
> }
> }
>
> I don't see a solution, perhaps add dummy bison rule(s)
> to explicitly signal closure of e.g. a rule context?
We can't influence start conditions from within bison (if that's what
you had in mind). All we can do is try make flex aware of the current
input context. For instance, detect 'table' followed by '{' to open
"table definition context" and start tracking braces to detect its end.
Though after all I think your assessment of all this being "fragile" is
appropriate. :/
Cheers, Phil
next prev parent reply other threads:[~2021-02-17 20:00 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-08 15:37 Unable to create a chain called "trace" Martin Gignac
2021-02-08 15:49 ` Florian Westphal
2021-02-08 16:47 ` Phil Sutter
2021-02-08 17:14 ` Florian Westphal
2021-02-09 13:56 ` Phil Sutter
2021-02-12 0:05 ` Florian Westphal
2021-02-12 11:40 ` Phil Sutter
2021-02-12 12:20 ` Florian Westphal
2021-02-12 17:09 ` Pablo Neira Ayuso
2021-02-12 17:32 ` Phil Sutter
2021-02-12 17:54 ` Pablo Neira Ayuso
2021-02-12 21:07 ` Phil Sutter
2021-02-12 18:02 ` Balazs Scheidler
2021-02-17 19:59 ` Phil Sutter [this message]
2021-02-17 20:16 ` Florian Westphal
2021-02-12 12:29 ` Florian Westphal
2021-02-12 12:48 ` Phil Sutter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210217195937.GA22016@orbyte.nwl.cc \
--to=phil@nwl.cc \
--cc=fw@strlen.de \
--cc=martin.gignac@gmail.com \
--cc=netfilter-devel@vger.kernel.org \
--cc=netfilter@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.