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@xxxxxxxxx>
> ---
> 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!
--
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
