On Thu, May 12, 2016 at 3:14 PM, Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: > 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? > Hi Pablo, I was using that for newline but I switched now to <para>, it looks OK now. >> 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. > Yes, I'm sorry for the mistake. >> + <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. > Yes OK. >> + <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 ;) > Should I be adding the ones like prandom, secmark too? nft_meta.c shows it but nftables doesn't seem to have an entry in the parser. Please let me know. >> </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! Thanks for your feedback! -- 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
