Balazs Scheidler <balazs.scheidler@xxxxxxxxxxx> wrote:
> I've noticed that our set of keywords in nftables is pretty rich and
> this can cause conflicts in the grammar when a keyword is also used
> as a symbol.
> For instance, we do have a "redirect" expression and "redirect" as
> a word is also used as an ICMP message type.
>
> # here is the redirect expression in action, which works:
> $ nft add rule tcp dport 80 redirect to 8080
>
> # here's an ICMP rule that works
> $ nft add rule filter input icmp type echo-request accept
>
> # here's an ICMP rule that should work, but it doesn't
> $ nft add rule filter input icmp type redirect accept
>
> The root cause is that "redirect" is now recognized as a token, whereas the
> icmp type is expecting a STRING token.
While we're at it, there are other issues, f.e.:
ct label saddr
ct label == saddr
won't work since saddr is considered to be the SADDR token.
Similar issues for other places where we accept arbitrary symbol names.
I think the above might be fixable via
| CT ct_key error
{
yychar = STRING;
...
But of course that won't fix up all cases, e.g.
ct label == saddr would still not work since we encounter
the error (unexpected token) after a relational expression.
Does anyone have better ideas other than plastering parser with error
handlers...?
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
