From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Shivani Bhardwaj <shivanib134@gmail.com>
Cc: netfilter-devel@vger.kernel.org
Subject: Re: [PATCH v2] doc: Complete the documentation of statements
Date: Thu, 12 May 2016 11:44:39 +0200 [thread overview]
Message-ID: <20160512094439.GA1694@salvia> (raw)
In-Reply-To: <20160512080845.GA25231@shivani>
On Thu, May 12, 2016 at 01:38:45PM +0530, Shivani Bhardwaj wrote:
> Add documentation corresponding to LOG STATEMENT, NFLOG STATEMENT,
> REJECT STATEMENT, COUNTER STATEMENT, META STATEMENT, LIMIT STATEMENT,
> NAT STATEMENT and QUEUE STATEMENT.
>
> Signed-off-by: Shivani Bhardwaj <shivanib134@gmail.com>
> ---
> Changes in v2:
> Add more content to the description.
>
> doc/nft.xml | 259 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 258 insertions(+), 1 deletion(-)
>
> diff --git a/doc/nft.xml b/doc/nft.xml
> index e4d227c..be3a713 100644
> --- a/doc/nft.xml
> +++ b/doc/nft.xml
> @@ -2185,37 +2185,294 @@ filter input iif eth0 drop
> </refsect2>
> <refsect2>
> <title>Log statement</title>
> + <cmdsynopsis>
> + <command>log</command>
> + <group choice="req">
> + <arg>prefix</arg>
> + <arg>level</arg>
> + </group>
> +
> + </cmdsynopsis>
> <para>
> + The log statement enables
^^^^^^^^^^
This has accidentally slipped through, right?
> logging of matching packets. When this statement is used from a
> rule, the Linux kernel will print some information on all matching
> packets, such as header fields, via the kernel log (where it can be
> read with dmesg(1) or read in the syslog). This is a non-terminating
> statement, so the rule evaluation continues after the packet is
> logged.
> + <table frame="all">
> + <title>LOG statement</title>
> + <tgroup cols='3' align='left' colsep='1' rowsep='1'>
> + <colspec colname='c1'/>
> + <colspec colname='c2'/>
> + <colspec colname='c3'/>
> + <thead>
> + <row>
> + <entry>Keyword</entry>
> + <entry>Description</entry>
> + <entry>Type</entry>
> + </row>
> + </thead>
> + <tbody>
> + <row>
> + <entry>level</entry>
> + <entry>Level of logging</entry>
> + <entry>unsigned integer (32 bit), emerg, alert, crit, err, warn [default], notice, info, debug</entry>
> + </row>
> + <row>
> + <entry>prefix</entry>
> + <entry>Prefix log messages</entry>
> + <entry>string</entry>
> + </row>
> + </tbody>
> + </tgroup>
> + </table>
> </para>
> </refsect2>
> <refsect2>
> + <title>nflog statement</title>
> + <cmdsynopsis>
> + <command>log</command>
> + <arg opt="req">group</arg>
> + <group choice="req">
> + <arg>prefix</arg>
> + <arg>queue-threshold</arg>
> + <arg>snaplen</arg>
> + </group>
> +
> + </cmdsynopsis>
> + <para>
> + The nflog statement provides logging of matching packets. When this statement is set for a rule, the Linux kernel will pass the packet to the loaded logging backend to log the packet. This is used in combination with nfnetlink_log as logging backend, which will multicast the packet through a netlink socket to the specified multicast group. One or more userspace processes may subscribe to the group to receive the packets. Like log statement, this is a non-terminating statement, i.e. rule traversal continues at the next rule. It is necessary to mention the group [default 0] to consider logging with nflog.
We don't have a nflog statement, actually this is integrated into
'log' itself. So if you indique the group, then it is assumed that you
want to use logging through nflog.
> + <table frame="all">
> + <title>NFLOG statement</title>
> + <tgroup cols='3' align='left' colsep='1' rowsep='1'>
> + <colspec colname='c1'/>
> + <colspec colname='c2'/>
> + <colspec colname='c3'/>
> + <thead>
> + <row>
> + <entry>Keyword</entry>
> + <entry>Description</entry>
> + <entry>Type</entry>
> + </row>
> + </thead>
> + <tbody>
> + <row>
> + <entry>prefix</entry>
> + <entry>Prepend to log messages</entry>
> + <entry>string</entry>
> + </row>
> + <row>
> + <entry>group</entry>
> + <entry>Netlink group to send messages to</entry>
> + <entry>unsigned integer (32 bit)</entry>
> + </row>
> + <row>
> + <entry>snaplen</entry>
> + <entry>Length of payload to include in netlink message</entry>
> + <entry>unsigned integer (32 bit)</entry>
> + </row>
> + <row>
> + <entry>queue-threshold</entry>
> + <entry>Queue threshold value</entry>
> + <entry>unsigned integer (32 bit)</entry>
> + </row>
> + </tbody>
> + </tgroup>
> + </table>
> + </para>
> + </refsect2>
> + <refsect2>
> <title>Reject statement</title>
> <para>
> + A reject statement is used to send back an error packet in response to the matched packet otherwise it is equivalent to drop so it is a terminating statement, ending rule traversal. This statement is only valid in the input, forward and output chains, and user-defined chains which are only called from those chains.
> + <table frame="all">
> + <title>REJECT statement (ipv4)</title>
^^^^^^
No need for upper case, in nftables we don't use upper case notation
anymore as in iptables targets.
> + <tgroup cols='3' align='left' colsep='1' rowsep='1'>
> + <colspec colname='c1'/>
> + <colspec colname='c2'/>
> + <colspec colname='c3'/>
> + <thead>
> + <row>
> + <entry>Keyword</entry>
> + <entry>Description</entry>
> + <entry>Type</entry>
> + </row>
> + </thead>
> + <tbody>
> + <row>
> + <entry>with icmp type</entry>
> + <entry>ICMP response to be sent to the host</entry>
> + <entry>unsigned integer (8 bit), net-unreachable, host-unreachable, prot-unreachable, port-unreachable [default], net-prohibited, host-prohibited, admin-prohibited</entry>
> + </row>
> + <row>
> + <entry>with</entry>
> + <entry>Used on rules which only match the TCP</entry>
> + <entry>tcp reset</entry>
> + </row>
> + </tbody>
> + </tgroup>
> + </table>
> + <table frame="all">
> + <title>REJECT statement (ipv6)</title>
> + <tgroup cols='3' align='left' colsep='1' rowsep='1'>
> + <colspec colname='c1'/>
> + <colspec colname='c2'/>
> + <colspec colname='c3'/>
> + <thead>
> + <row>
> + <entry>Keyword</entry>
> + <entry>Description</entry>
> + <entry>Type</entry>
> + </row>
> + </thead>
> + <tbody>
> + <row>
> + <entry>with icmpv6 type</entry>
> + <entry>ICMP6 response to be sent to the host</entry>
> + <entry>unsigned integer (8 bit), no-route, admin-prohibited, addr-unreachable, port-unreachable [default], policy-fail, reject-route</entry>
> + </row>
> + <row>
> + <entry>with</entry>
> + <entry>Used on rules which only match the TCP</entry>
> + <entry>tcp reset</entry>
> + </row>
> + </tbody>
> + </tgroup>
> + </table>
> </para>
> </refsect2>
> <refsect2>
> <title>Counter statement</title>
> <para>
> + A counter statement sets the hit count of packets along with the number of bytes.
> </para>
> </refsect2>
> <refsect2>
> <title>Meta statement</title>
> <para>
> + A meta statement sets the value of a meta expression.
> + The existing meta fields are: length,
> nfproto, l4proto, protocol, priority, mark, iif, iifname, iiftype,
> oif, oifname, oiftype, skuid, skgid, nftrace, rtclassid, ibriport,
> obriport, pkttype, cpu, iifgroup, oifgroup, cgroup.
We actually support a bunch of this, have a look at:
net/netfilter/nft_meta.c so you know which ones we support ;)
> </para>
> </refsect2>
> <refsect2>
> + <cmdsynopsis>
> + <command>limit</command>
> + <group choice="req">
> + <arg>rate</arg>
> + <arg>burst</arg>
> + </group>
> + </cmdsynopsis>
> +
> <title>Limit statement</title>
> <para>
> + A limit statement is used to set a specified limit attribute.
> + <table frame="all">
> + <title>Limit statement</title>
> + <tgroup cols='3' align='left' colsep='1' rowsep='1'>
> + <colspec colname='c1'/>
> + <colspec colname='c2'/>
> + <colspec colname='c3'/>
> + <thead>
> + <row>
> + <entry>Keyword</entry>
> + <entry>Description</entry>
> + <entry>Type</entry>
> + </row>
> + </thead>
> + <tbody>
> + <row>
> + <entry>rate</entry>
> + <entry>Maximum average matching rate</entry>
> + <entry>size (bytes, kbytes, mbytes)/time (second, minute, hour, day, week)</entry>
> + </row>
> + <row>
> + <entry>burst</entry>
> + <entry>Maximum initial number of packets</entry>
> + <entry>packets, size (bytes, kbytes, mbytes)</entry>
> + </row>
> + </tbody>
> + </tgroup>
> + </table>
> </para>
> </refsect2>
> - <refsect2>
> + <refsect2>
> <title>NAT statement</title>
> + <cmdsynopsis>
> + <group choice="req">
> + <arg>snat</arg>
> + <arg>dnat</arg>
> + </group>
> + <arg choice="req"><replaceable>flags</replaceable></arg>
> + </cmdsynopsis>
> <para>
> + The nat statement is only valid in the nat table.
I'd suggest "... is only valid from nat chain types."
We don't have a nat table anymore, instead we have a nat chain type.
Thanks for following up on this!
next prev parent reply other threads:[~2016-05-12 9:44 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-12 8:08 [PATCH v2] doc: Complete the documentation of statements Shivani Bhardwaj
2016-05-12 9:44 ` Pablo Neira Ayuso [this message]
2016-05-12 10:51 ` Shivani Bhardwaj
2016-05-12 11:05 ` Pablo Neira Ayuso
2016-05-12 11:07 ` Shivani Bhardwaj
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=20160512094439.GA1694@salvia \
--to=pablo@netfilter.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=shivanib134@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).