[Bug 835] protocol without option is failing

[bugzilla-daemon at netfilter.org]

https://bugzilla.netfilter.org/show_bug.cgi?id=835

--- Comment #4 from Eric Leblond <eric at regit.org> 2013-08-15 00:01:08 CEST ---
(In reply to comment #3)
> The original commit which added this feature does not mesh with your
> understanding:
> 
> commit 6c3eec6ad009d7ed8a219291b98886a80b26b8e4
> Author: Patrick McHardy <kaber at trash.net>
> Date:   Wed Dec 5 19:39:00 2012 +0100
> 
>     parser: fix parsing protocol names for protocols which are also keywords
> 
>     "ip protocol tcp" will currently produce a syntax error since tcp is also a
> keyword
>     which is expected ot be followed by a tcp header field. Allow to use
> protocol names
>     that are also keywords and allocate a constant expression for them.

OK, you are right on this. I misunderstood the grammar.

> Aside from that, I think it wouldn't fit with the existing language to have
> protocols listed by themselves.  When you want to choose a specific feature of
> the ip header, you need to use "ip <header> <foo>".  So "ip protocol tcp" is
> consistent with "ip saddr x.x.x.x".  In general, the parser seems more
> consistent the way it is currently operating.  
> 
> And finally, even iptables requires "-p" before specifying a protocol.

I don't agree on this point. In iptables "-p" was just needed to imply the
context (and load the corresponding module). In nftables, we can use "tcp dport
80" without specifying "ip protocol". So this is really tempting for the user
to use only "tcp". So, not a bug but an enahncement in P5 seems ok ;)

-- 
Configure bugmail: https://bugzilla.netfilter.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.