* [nft PATCH 0/6] A bunch of man page enhancements
@ 2017-08-10 17:29 Phil Sutter
2017-08-10 17:29 ` [nft PATCH 1/6] nft.8: Document operations on ruleset Phil Sutter
` (5 more replies)
0 siblings, 6 replies; 7+ messages in thread
From: Phil Sutter @ 2017-08-10 17:29 UTC (permalink / raw)
To: Pablo Neira Ayuso; +Cc: netfilter-devel
This series should resolve nfbz#1093.
Many thanks to Florian for his patient explanations of base chain types
and hooks.
Phil Sutter (6):
nft.8: Document operations on ruleset
nft.8: Describe conntrack types
nft.8: Review reject statement description
nft.8: Add note about supported hooks for bridge family
nft.8: Describe base chain details
nft.8: Complete short description of arp family
doc/nft.xml | 733 +++++++++++++++++++++++++++++++++++++++++++++++++++++-------
1 file changed, 647 insertions(+), 86 deletions(-)
--
2.13.1
^ permalink raw reply [flat|nested] 7+ messages in thread
* [nft PATCH 1/6] nft.8: Document operations on ruleset
2017-08-10 17:29 [nft PATCH 0/6] A bunch of man page enhancements Phil Sutter
@ 2017-08-10 17:29 ` Phil Sutter
2017-08-10 17:29 ` [nft PATCH 2/6] nft.8: Describe conntrack types Phil Sutter
` (4 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: Phil Sutter @ 2017-08-10 17:29 UTC (permalink / raw)
To: Pablo Neira Ayuso; +Cc: netfilter-devel
People new to nftables and yet unaware of 'list ruleset' and 'flush
ruleset' commands have a hard time. Therefore put description of those
prominently at the top, even before explaining operations on tables and
chains.
Since 'export ruleset' is closely related, document it here as well and
remove it's sparse description from ADDITIONAL COMMANDS section.
Signed-off-by: Phil Sutter <phil@nwl.cc>
---
doc/nft.xml | 87 ++++++++++++++++++++++++++++++++++++++++++++++++++-----------
1 file changed, 72 insertions(+), 15 deletions(-)
diff --git a/doc/nft.xml b/doc/nft.xml
index 4d03a3dbc75bf..91b9bb378c80a 100644
--- a/doc/nft.xml
+++ b/doc/nft.xml
@@ -465,6 +465,78 @@ filter input iif $int_ifs accept
</refsect1>
<refsect1>
+ <title>Ruleset</title>
+ <para>
+ <cmdsynopsis>
+ <group choice="req">
+ <arg>list</arg>
+ <arg>flush</arg>
+ </group>
+ <command>ruleset</command>
+ <arg choice="opt"><replaceable>family</replaceable></arg>
+ </cmdsynopsis>
+ <cmdsynopsis>
+ <arg choice="req">export</arg>
+ <arg choice="opt"><command>ruleset</command></arg>
+ <arg choice="req"><replaceable>format</replaceable></arg>
+ </cmdsynopsis>
+ </para>
+
+ <para>
+ The <command>ruleset</command> keyword is used to identify the whole
+ set of tables, chains, etc. currently in place in kernel. The
+ following <command>ruleset</command> commands exist:
+ </para>
+
+ <variablelist>
+ <varlistentry>
+ <term><option>list</option></term>
+ <listitem>
+ <para>
+ Print the ruleset in human-readable format.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><option>flush</option></term>
+ <listitem>
+ <para>
+ Clear the whole ruleset. Note that unlike iptables, this
+ will remove all tables and whatever they contain,
+ effectively leading to an empty ruleset - no packet
+ filtering will happen anymore, so the kernel accepts any
+ valid packet it receives.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><option>export</option></term>
+ <listitem>
+ <para>
+ Print the ruleset in machine readable format. The
+ mandatory <replaceable>format</replaceable> parameter
+ may be either <literal>xml</literal> or
+ <literal>json</literal>.
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+
+ <para>
+ It is possible to limit <command>list</command> and
+ <command>flush</command> to a specific address family only. For a
+ list of valid family names, see <literal>ADDRESS FAMILIES</literal> above.
+ </para>
+
+ <para>
+ Note that contrary to what one might assume, the output generated
+ by <command>export</command> is not parseable by
+ <command>nft -f</command>. Instead, the output of
+ <command>list</command> command serves well for that purpose.
+ </para>
+ </refsect1>
+
+ <refsect1>
<title>Tables</title>
<para>
<cmdsynopsis>
@@ -4362,21 +4434,6 @@ add rule nat prerouting tcp dport 22 redirect to :2222
These are some additional commands included in nft.
</para>
<refsect2>
- <title>export</title>
- <para>
- Export your current ruleset in XML or JSON format to stdout.
- </para>
- <para>
- Examples:
- <programlisting>
-% nft export xml
-[...]
-% nft export json
-[...]
- </programlisting>
- </para>
- </refsect2>
- <refsect2>
<title>monitor</title>
<para>
The monitor command allows you to listen to Netlink events produced
--
2.13.1
^ permalink raw reply related [flat|nested] 7+ messages in thread
* [nft PATCH 2/6] nft.8: Describe conntrack types
2017-08-10 17:29 [nft PATCH 0/6] A bunch of man page enhancements Phil Sutter
2017-08-10 17:29 ` [nft PATCH 1/6] nft.8: Document operations on ruleset Phil Sutter
@ 2017-08-10 17:29 ` Phil Sutter
2017-08-10 17:29 ` [nft PATCH 3/6] nft.8: Review reject statement description Phil Sutter
` (3 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: Phil Sutter @ 2017-08-10 17:29 UTC (permalink / raw)
To: Pablo Neira Ayuso; +Cc: netfilter-devel
Signed-off-by: Phil Sutter <phil@nwl.cc>
---
doc/nft.xml | 230 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 230 insertions(+)
diff --git a/doc/nft.xml b/doc/nft.xml
index 91b9bb378c80a..3ef88a79efd70 100644
--- a/doc/nft.xml
+++ b/doc/nft.xml
@@ -1921,6 +1921,232 @@ filter output icmpv6 type { echo-request, echo-reply }
</programlisting>
</example>
</refsect2>
+ <refsect2>
+ <title>Conntrack types</title>
+ <para>
+ This is an overview of types used in <command>ct</command>
+ expression and statement:
+ <table frame="all">
+ <tgroup cols="4" align="left" colsep="1" rowsep="1">
+ <colspec colname="c1"/>
+ <colspec colname="c2"/>
+ <colspec colname="c3"/>
+ <colspec colname="c4"/>
+ <thead>
+ <row>
+ <entry>Name</entry>
+ <entry>Keyword</entry>
+ <entry>Size</entry>
+ <entry>Base type</entry>
+ </row>
+ </thead>
+ <tbody>
+ <row>
+ <entry>conntrack state</entry>
+ <entry>ct_state</entry>
+ <entry>4 byte</entry>
+ <entry>bitmask</entry>
+ </row>
+ <row>
+ <entry>conntrack direction</entry>
+ <entry>ct_dir</entry>
+ <entry>8 bit</entry>
+ <entry>integer</entry>
+ </row>
+ <row>
+ <entry>conntrack status</entry>
+ <entry>ct_status</entry>
+ <entry>4 byte</entry>
+ <entry>bitmask</entry>
+ </row>
+ <row>
+ <entry>conntrack event bits</entry>
+ <entry>ct_event</entry>
+ <entry>4 byte</entry>
+ <entry>bitmask</entry>
+ </row>
+ <row>
+ <entry>conntrack label</entry>
+ <entry>ct_label</entry>
+ <entry>128 bit</entry>
+ <entry>bitmask</entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+ </para>
+ <para>
+ For each of the types above, keywords are available for convenience:
+ <table frame="all">
+ <title>conntrack state (ct_state)</title>
+ <tgroup cols="2" align="left" colsep="1" rowsep="1">
+ <colspec colname="c1"/>
+ <colspec colname="c2"/>
+ <thead>
+ <row>
+ <entry>Keyword</entry>
+ <entry>Value</entry>
+ </row>
+ </thead>
+ <tbody>
+ <row>
+ <entry>invalid</entry>
+ <entry>1</entry>
+ </row>
+ <row>
+ <entry>established</entry>
+ <entry>2</entry>
+ </row>
+ <row>
+ <entry>related</entry>
+ <entry>4</entry>
+ </row>
+ <row>
+ <entry>new</entry>
+ <entry>8</entry>
+ </row>
+ <row>
+ <entry>untracked</entry>
+ <entry>64</entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <table frame="all">
+ <title>conntrack direction (ct_dir)</title>
+ <tgroup cols="2" align="left" colsep="1" rowsep="1">
+ <colspec colname="c1"/>
+ <colspec colname="c2"/>
+ <thead>
+ <row>
+ <entry>Keyword</entry>
+ <entry>Value</entry>
+ </row>
+ </thead>
+ <tbody>
+ <row>
+ <entry>original</entry>
+ <entry>0</entry>
+ </row>
+ <row>
+ <entry>reply</entry>
+ <entry>1</entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <table frame="all">
+ <title>conntrack status (ct_status)</title>
+ <tgroup cols="2" align="left" colsep="1" rowsep="1">
+ <colspec colname="c1"/>
+ <colspec colname="c2"/>
+ <thead>
+ <row>
+ <entry>Keyword</entry>
+ <entry>Value</entry>
+ </row>
+ </thead>
+ <tbody>
+ <row>
+ <entry>expected</entry>
+ <entry>1</entry>
+ </row>
+ <row>
+ <entry>seen-reply</entry>
+ <entry>2</entry>
+ </row>
+ <row>
+ <entry>assured</entry>
+ <entry>4</entry>
+ </row>
+ <row>
+ <entry>confirmed</entry>
+ <entry>8</entry>
+ </row>
+ <row>
+ <entry>snat</entry>
+ <entry>16</entry>
+ </row>
+ <row>
+ <entry>dnat</entry>
+ <entry>32</entry>
+ </row>
+ <row>
+ <entry>dying</entry>
+ <entry>512</entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <table frame="all">
+ <title>conntrack event bits (ct_event)</title>
+ <tgroup cols="2" align="left" colsep="1" rowsep="1">
+ <colspec colname="c1"/>
+ <colspec colname="c2"/>
+ <thead>
+ <row>
+ <entry>Keyword</entry>
+ <entry>Value</entry>
+ </row>
+ </thead>
+ <tbody>
+ <row>
+ <entry>new</entry>
+ <entry>1</entry>
+ </row>
+ <row>
+ <entry>related</entry>
+ <entry>2</entry>
+ </row>
+ <row>
+ <entry>destroy</entry>
+ <entry>4</entry>
+ </row>
+ <row>
+ <entry>reply</entry>
+ <entry>8</entry>
+ </row>
+ <row>
+ <entry>assured</entry>
+ <entry>16</entry>
+ </row>
+ <row>
+ <entry>protoinfo</entry>
+ <entry>32</entry>
+ </row>
+ <row>
+ <entry>helper</entry>
+ <entry>64</entry>
+ </row>
+ <row>
+ <entry>mark</entry>
+ <entry>128</entry>
+ </row>
+ <row>
+ <entry>seqadj</entry>
+ <entry>256</entry>
+ </row>
+ <row>
+ <entry>secmark</entry>
+ <entry>512</entry>
+ </row>
+ <row>
+ <entry>label</entry>
+ <entry>1024</entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+ <para>
+ Possible keywords for conntrack label type
+ (<command>ct_label</command>) are read at runtime from
+ <literal>/etc/connlabel.conf</literal>.
+ </para>
+ </para>
+ </refsect2>
</refsect1>
<refsect1>
@@ -3577,6 +3803,10 @@ ip6 filter input frag more-fragments 1 counter
</tgroup>
</table>
</para>
+ <para>
+ A description of conntrack-specific types listed above can be
+ found sub-section <literal>CONNTRACK TYPES</literal> above.
+ </para>
</refsect2>
</refsect1>
--
2.13.1
^ permalink raw reply related [flat|nested] 7+ messages in thread
* [nft PATCH 3/6] nft.8: Review reject statement description
2017-08-10 17:29 [nft PATCH 0/6] A bunch of man page enhancements Phil Sutter
2017-08-10 17:29 ` [nft PATCH 1/6] nft.8: Document operations on ruleset Phil Sutter
2017-08-10 17:29 ` [nft PATCH 2/6] nft.8: Describe conntrack types Phil Sutter
@ 2017-08-10 17:29 ` Phil Sutter
2017-08-10 17:29 ` [nft PATCH 4/6] nft.8: Add note about supported hooks for bridge family Phil Sutter
` (2 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: Phil Sutter @ 2017-08-10 17:29 UTC (permalink / raw)
To: Pablo Neira Ayuso; +Cc: netfilter-devel
- Describe 'type' argument datatypes in DATA TYPES section, then remove
value list from reject statement description and refer to that section
instead.
- Fix synopsis: 'with ...' is optional.
Signed-off-by: Phil Sutter <phil@nwl.cc>
---
doc/nft.xml | 317 ++++++++++++++++++++++++++++++++++++++++++++++++------------
1 file changed, 256 insertions(+), 61 deletions(-)
diff --git a/doc/nft.xml b/doc/nft.xml
index 3ef88a79efd70..bc6b6fb72b6a7 100644
--- a/doc/nft.xml
+++ b/doc/nft.xml
@@ -1790,6 +1790,83 @@ filter output icmp type { echo-request, echo-reply }
</example>
</refsect2>
<refsect2>
+ <title>ICMP Code type</title>
+ <para>
+ <table frame="all">
+ <tgroup cols="4" align="left" colsep="1" rowsep="1">
+ <colspec colname="c1"/>
+ <colspec colname="c2"/>
+ <colspec colname="c3"/>
+ <colspec colname="c4"/>
+ <thead>
+ <row>
+ <entry>Name</entry>
+ <entry>Keyword</entry>
+ <entry>Size</entry>
+ <entry>Base type</entry>
+ </row>
+ </thead>
+ <tbody>
+ <row>
+ <entry>ICMP Code</entry>
+ <entry>icmp_code</entry>
+ <entry>8 bit</entry>
+ <entry>integer</entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+ </para>
+ <para>
+ The ICMP Code type is used to conveniently specify the ICMP header's code field.
+ </para>
+ <para>
+ The following keywords may be used when specifying the ICMP code:
+ <table frame="all">
+ <tgroup cols="2" align="left" colsep="1" rowsep="1">
+ <colspec colname="c1"/>
+ <colspec colname="c2"/>
+ <thead>
+ <row>
+ <entry>Keyword</entry>
+ <entry>Value</entry>
+ </row>
+ </thead>
+ <tbody>
+ <row>
+ <entry>net-unreachable</entry>
+ <entry>0</entry>
+ </row>
+ <row>
+ <entry>host-unreachable</entry>
+ <entry>1</entry>
+ </row>
+ <row>
+ <entry>prot-unreachable</entry>
+ <entry>2</entry>
+ </row>
+ <row>
+ <entry>port-unreachable</entry>
+ <entry>3</entry>
+ </row>
+ <row>
+ <entry>net-prohibited</entry>
+ <entry>9</entry>
+ </row>
+ <row>
+ <entry>host-prohibited</entry>
+ <entry>10</entry>
+ </row>
+ <row>
+ <entry>admin-prohibited</entry>
+ <entry>13</entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+ </para>
+ </refsect2>
+ <refsect2>
<title>ICMPv6 Type type</title>
<para>
<table frame="all">
@@ -1922,6 +1999,146 @@ filter output icmpv6 type { echo-request, echo-reply }
</example>
</refsect2>
<refsect2>
+ <title>ICMPv6 Code type</title>
+ <para>
+ <table frame="all">
+ <tgroup cols="4" align="left" colsep="1" rowsep="1">
+ <colspec colname="c1"/>
+ <colspec colname="c2"/>
+ <colspec colname="c3"/>
+ <colspec colname="c4"/>
+ <thead>
+ <row>
+ <entry>Name</entry>
+ <entry>Keyword</entry>
+ <entry>Size</entry>
+ <entry>Base type</entry>
+ </row>
+ </thead>
+ <tbody>
+ <row>
+ <entry>ICMPv6 Code</entry>
+ <entry>icmpv6_code</entry>
+ <entry>8 bit</entry>
+ <entry>integer</entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+ </para>
+ <para>
+ The ICMPv6 Code type is used to conveniently specify the ICMPv6 header's code field.
+ </para>
+ <para>
+ The following keywords may be used when specifying the ICMPv6 code:
+ <table frame="all">
+ <tgroup cols="2" align="left" colsep="1" rowsep="1">
+ <colspec colname="c1"/>
+ <colspec colname="c2"/>
+ <thead>
+ <row>
+ <entry>Keyword</entry>
+ <entry>Value</entry>
+ </row>
+ </thead>
+ <tbody>
+ <row>
+ <entry>no-route</entry>
+ <entry>0</entry>
+ </row>
+ <row>
+ <entry>admin-prohibited</entry>
+ <entry>1</entry>
+ </row>
+ <row>
+ <entry>addr-unreachable</entry>
+ <entry>3</entry>
+ </row>
+ <row>
+ <entry>port-unreachable</entry>
+ <entry>4</entry>
+ </row>
+ <row>
+ <entry>policy-fail</entry>
+ <entry>5</entry>
+ </row>
+ <row>
+ <entry>reject-route</entry>
+ <entry>6</entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+ </para>
+ </refsect2>
+ <refsect2>
+ <title>ICMPvX Code type</title>
+ <para>
+ <table frame="all">
+ <tgroup cols="4" align="left" colsep="1" rowsep="1">
+ <colspec colname="c1"/>
+ <colspec colname="c2"/>
+ <colspec colname="c3"/>
+ <colspec colname="c4"/>
+ <thead>
+ <row>
+ <entry>Name</entry>
+ <entry>Keyword</entry>
+ <entry>Size</entry>
+ <entry>Base type</entry>
+ </row>
+ </thead>
+ <tbody>
+ <row>
+ <entry>ICMPvX Code</entry>
+ <entry>icmpx_code</entry>
+ <entry>8 bit</entry>
+ <entry>integer</entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+ </para>
+ <para>
+ The ICMPvX Code type abstraction is a set of values which
+ overlap between ICMP and ICMPv6 Code types to be used from the
+ inet family.
+ </para>
+ <para>
+ The following keywords may be used when specifying the ICMPvX code:
+ <table frame="all">
+ <tgroup cols="2" align="left" colsep="1" rowsep="1">
+ <colspec colname="c1"/>
+ <colspec colname="c2"/>
+ <thead>
+ <row>
+ <entry>Keyword</entry>
+ <entry>Value</entry>
+ </row>
+ </thead>
+ <tbody>
+ <row>
+ <entry>no-route</entry>
+ <entry>0</entry>
+ </row>
+ <row>
+ <entry>port-unreachable</entry>
+ <entry>1</entry>
+ </row>
+ <row>
+ <entry>host-unreachable</entry>
+ <entry>2</entry>
+ </row>
+ <row>
+ <entry>admin-prohibited</entry>
+ <entry>3</entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+ </para>
+ </refsect2>
+ <refsect2>
<title>Conntrack types</title>
<para>
This is an overview of types used in <command>ct</command>
@@ -4083,95 +4300,73 @@ ip6 filter output log flags all
<para>
<cmdsynopsis>
<command>reject</command>
- <arg choice="none">with</arg>
- <group choice="req">
- <arg>icmp</arg>
- <arg>icmp6</arg>
- <arg>icmpx</arg>
- </group>
- <arg choice="none">type</arg>
- <group choice="req">
- <arg>icmp_type</arg>
- <arg>icmp6_type</arg>
- <arg>icmpx_type</arg>
- </group>
+ <arg choice="opt">
+ <arg choice="none">with</arg>
+ <group choice="req">
+ <arg>icmp</arg>
+ <arg>icmp6</arg>
+ <arg>icmpx</arg>
+ </group>
+ <arg choice="none">type</arg>
+ <group choice="req">
+ <arg>icmp_type</arg>
+ <arg>icmp6_type</arg>
+ <arg>icmpx_type</arg>
+ </group>
+ </arg>
</cmdsynopsis>
<cmdsynopsis>
<command>reject</command>
- <arg choice="none">with</arg>
- <arg choice="req">tcp</arg>
- <arg choice="req">reset</arg>
+ <arg choice="opt">
+ <arg choice="none">with</arg>
+ <arg choice="req">tcp</arg>
+ <arg choice="req">reset</arg>
+ </arg>
</cmdsynopsis>
</para>
<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.
+ </para>
+ <para>
+ The different ICMP reject variants are meant for use in different table families:
<table frame="all">
- <title>reject statement type (ip)</title>
- <tgroup cols='3' align='left' colsep='1' rowsep='1'>
- <colspec colname='c1'/>
- <colspec colname='c2'/>
- <colspec colname='c3'/>
- <thead>
- <row>
- <entry>Value</entry>
- <entry>Description</entry>
- <entry>Type</entry>
- </row>
- </thead>
- <tbody>
- <row>
- <entry>icmp_type</entry>
- <entry>ICMP type response to be sent to the host</entry>
- <entry>net-unreachable, host-unreachable, prot-unreachable, port-unreachable [default], net-prohibited, host-prohibited, admin-prohibited</entry>
- </row>
- </tbody>
- </tgroup>
- </table>
- <table frame="all">
- <title>reject statement type (ip6)</title>
<tgroup cols='3' align='left' colsep='1' rowsep='1'>
<colspec colname='c1'/>
<colspec colname='c2'/>
<colspec colname='c3'/>
<thead>
<row>
- <entry>Value</entry>
- <entry>Description</entry>
+ <entry>Variant</entry>
+ <entry>Family</entry>
<entry>Type</entry>
</row>
</thead>
<tbody>
<row>
- <entry>icmp6_type</entry>
- <entry>ICMPv6 type response to be sent to the host</entry>
- <entry>no-route, admin-prohibited, addr-unreachable, port-unreachable [default], policy-fail, reject-route</entry>
+ <entry>icmp</entry>
+ <entry>ip</entry>
+ <entry>icmp_code</entry>
</row>
- </tbody>
- </tgroup>
- </table>
- <table frame="all">
- <title>reject statement type (inet)</title>
- <tgroup cols='3' align='left' colsep='1' rowsep='1'>
- <colspec colname='c1'/>
- <colspec colname='c2'/>
- <colspec colname='c3'/>
- <thead>
<row>
- <entry>Value</entry>
- <entry>Description</entry>
- <entry>Type</entry>
+ <entry>icmp6</entry>
+ <entry>ip6</entry>
+ <entry>icmpv6_code</entry>
</row>
- </thead>
- <tbody>
<row>
- <entry>icmpx_type</entry>
- <entry>ICMPvXtype abstraction response to be sent to the host, this is a set of types that overlap in IPv4 and IPv6 to be used from the inet family.</entry>
- <entry>port-unreachable [default], admin-prohibited, no-route, host-unreachable</entry>
+ <entry>icmpx</entry>
+ <entry>inet</entry>
+ <entry>icmpx_code</entry>
</row>
</tbody>
</tgroup>
</table>
</para>
+ <para>
+ For a description of the different types and a list of supported
+ keywords refer to <literal>DATA TYPES</literal> section above.
+ The common default reject value is
+ <command>port-unreachable</command>.
+ </para>
</refsect2>
<refsect2>
<title>Counter statement</title>
--
2.13.1
^ permalink raw reply related [flat|nested] 7+ messages in thread
* [nft PATCH 4/6] nft.8: Add note about supported hooks for bridge family
2017-08-10 17:29 [nft PATCH 0/6] A bunch of man page enhancements Phil Sutter
` (2 preceding siblings ...)
2017-08-10 17:29 ` [nft PATCH 3/6] nft.8: Review reject statement description Phil Sutter
@ 2017-08-10 17:29 ` Phil Sutter
2017-08-10 17:29 ` [nft PATCH 5/6] nft.8: Describe base chain details Phil Sutter
2017-08-10 17:29 ` [nft PATCH 6/6] nft.8: Complete short description of arp family Phil Sutter
5 siblings, 0 replies; 7+ messages in thread
From: Phil Sutter @ 2017-08-10 17:29 UTC (permalink / raw)
To: Pablo Neira Ayuso; +Cc: netfilter-devel
It is the only address family which lacks a table describing supported
hooks. Since that would be identical to the one for ip/ip6/inet
families, just point there.
Signed-off-by: Phil Sutter <phil@nwl.cc>
---
doc/nft.xml | 3 +++
1 file changed, 3 insertions(+)
diff --git a/doc/nft.xml b/doc/nft.xml
index bc6b6fb72b6a7..00095ddafcdad 100644
--- a/doc/nft.xml
+++ b/doc/nft.xml
@@ -429,6 +429,9 @@ filter input iif $int_ifs accept
<para>
The bridge address family handles ethernet packets traversing bridge devices.
</para>
+ <para>
+ The list of supported hooks is identical to IPv4/IPv6/Inet address families above.
+ </para>
</refsect2>
<refsect2>
<title>Netdev address family</title>
--
2.13.1
^ permalink raw reply related [flat|nested] 7+ messages in thread
* [nft PATCH 5/6] nft.8: Describe base chain details
2017-08-10 17:29 [nft PATCH 0/6] A bunch of man page enhancements Phil Sutter
` (3 preceding siblings ...)
2017-08-10 17:29 ` [nft PATCH 4/6] nft.8: Add note about supported hooks for bridge family Phil Sutter
@ 2017-08-10 17:29 ` Phil Sutter
2017-08-10 17:29 ` [nft PATCH 6/6] nft.8: Complete short description of arp family Phil Sutter
5 siblings, 0 replies; 7+ messages in thread
From: Phil Sutter @ 2017-08-10 17:29 UTC (permalink / raw)
To: Pablo Neira Ayuso; +Cc: netfilter-devel
This mostly covers base chain types, but also tries to clarify meaning
of priority values, chain policy and the ominous device parameter.
Command synopsis is adjusted as well to point out which parts of a base
chain definition are optional and which are not.
Signed-off-by: Phil Sutter <phil@nwl.cc>
---
doc/nft.xml | 94 +++++++++++++++++++++++++++++++++++++++++++++++++++++++------
1 file changed, 85 insertions(+), 9 deletions(-)
diff --git a/doc/nft.xml b/doc/nft.xml
index 00095ddafcdad..73ef4d18f462f 100644
--- a/doc/nft.xml
+++ b/doc/nft.xml
@@ -616,20 +616,26 @@ filter input iif $int_ifs accept
<title>Chains</title>
<para>
<cmdsynopsis>
- <arg choice="req">add</arg>
+ <group choice="req">
+ <arg>add</arg>
+ <arg>create</arg>
+ </group>
<command>chain</command>
<arg choice="opt"><replaceable>family</replaceable></arg>
- <arg choice="req"><replaceable>table</replaceable></arg>
- <arg choice="req"><replaceable>chain</replaceable></arg>
- <arg choice="req"><replaceable>hook</replaceable></arg>
- <arg choice="req"><replaceable>priority</replaceable></arg>
- <arg choice="req"><replaceable>policy</replaceable></arg>
- <arg choice="req"><replaceable>device</replaceable></arg>
+ <arg choice="plain"><replaceable>table</replaceable></arg>
+ <arg choice="plain"><replaceable>chain</replaceable></arg>
+ <arg choice="opt">
+ <arg choice="req">
+ <arg choice="req"><replaceable>type</replaceable></arg>
+ <arg choice="req"><replaceable>hook</replaceable></arg>
+ <arg choice="opt"><replaceable>device</replaceable></arg>
+ <arg choice="req"><replaceable>priority</replaceable></arg>
+ </arg>
+ <arg choice="opt"><replaceable>policy</replaceable></arg>
+ </arg>
</cmdsynopsis>
<cmdsynopsis>
<group choice="req">
- <arg>add</arg>
- <arg>create</arg>
<arg>delete</arg>
<arg>list</arg>
<arg>flush</arg>
@@ -710,6 +716,76 @@ filter input iif $int_ifs accept
</listitem>
</varlistentry>
</variablelist>
+
+ <para>
+ For base chains, <command>type</command>, <command>hook</command> and <command>priority</command> parameters are mandatory.
+ </para>
+ <para>
+ <table frame="all">
+ <title>Supported chain types</title>
+ <tgroup cols="4" align="left" colsep="1" rowsep="1">
+ <colspec colname="c1"/>
+ <colspec colname="c2"/>
+ <colspec colname="c3"/>
+ <colspec colname="c4"/>
+ <thead>
+ <row>
+ <entry>Type</entry>
+ <entry>Families</entry>
+ <entry>Hooks</entry>
+ <entry>Description</entry>
+ </row>
+ </thead>
+ <tbody>
+ <row>
+ <entry>filter</entry>
+ <entry>all</entry>
+ <entry>all</entry>
+ <entry>Standard chain type to use in doubt.</entry>
+ </row>
+ <row>
+ <entry>nat</entry>
+ <entry>ip, ip6</entry>
+ <entry>prerouting, input, output, postrouting</entry>
+ <entry>Chains of this type perform Native Address Translation based on conntrack entries. Only the first packet of a connection actually traverses this chain - its rules usually define details of the created conntrack entry (NAT statements for instance).</entry>
+ </row>
+ <row>
+ <entry>route</entry>
+ <entry>ip, ip6</entry>
+ <entry>output</entry>
+ <entry>If a packet has traversed a chain of this
+ type and is about to be accepted, a new route
+ lookup is performed if relevant parts of the IP
+ header have changed. This allows to e.g.
+ implement policy routing selectors in
+ nftables.</entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+ </para>
+ <para>
+ Apart from the special cases illustrated above (e.g. <literal>nat</literal> type not supporting <literal>forward</literal> hook or <literal>route</literal> type only supporting <literal>output</literal> hook), there are two further quirks worth noticing:
+ <itemizedlist>
+ <listitem>
+ <literal>netdev</literal> family supports merely a single
+ combination, namely <literal>filter</literal> type and
+ <literal>ingress</literal> hook. Base chains in this family also require the <literal>device</literal> parameter to be present since they exist per incoming interface only.
+ </listitem>
+ <listitem>
+ <literal>arp</literal> family supports only
+ <literal>input</literal> and <literal>output</literal>
+ hooks, both in chains of type
+ <literal>filter</literal>.
+ </listitem>
+ </itemizedlist>
+ </para>
+ <para>
+ The <literal>priority</literal> parameter accepts a signed integer value which specifies the order in which chains with same <literal>hook</literal> value are traversed. The ordering is ascending, i.e. lower priority values have precedence over higher ones.
+ </para>
+ <para>
+ Base chains also allow to set the chain's <literal>policy</literal>, i.e. what happens to packets not explicitly accepted or refused in contained rules. Supported policy values are <literal>accept</literal> (which is the default) or <literal>drop</literal>.
+ </para>
</refsect1>
<refsect1>
--
2.13.1
^ permalink raw reply related [flat|nested] 7+ messages in thread
* [nft PATCH 6/6] nft.8: Complete short description of arp family
2017-08-10 17:29 [nft PATCH 0/6] A bunch of man page enhancements Phil Sutter
` (4 preceding siblings ...)
2017-08-10 17:29 ` [nft PATCH 5/6] nft.8: Describe base chain details Phil Sutter
@ 2017-08-10 17:29 ` Phil Sutter
5 siblings, 0 replies; 7+ messages in thread
From: Phil Sutter @ 2017-08-10 17:29 UTC (permalink / raw)
To: Pablo Neira Ayuso; +Cc: netfilter-devel
Although not very informational, still better than ending mid-sentence.
Signed-off-by: Phil Sutter <phil@nwl.cc>
---
doc/nft.xml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/nft.xml b/doc/nft.xml
index 73ef4d18f462f..39630ace32b16 100644
--- a/doc/nft.xml
+++ b/doc/nft.xml
@@ -304,7 +304,7 @@ filter input iif $int_ifs accept
<term><option>arp</option></term>
<listitem>
<para>
- ARP address family, handling packets vi
+ ARP address family, handling IPv4 ARP packets.
</para>
</listitem>
</varlistentry>
--
2.13.1
^ permalink raw reply related [flat|nested] 7+ messages in thread
end of thread, other threads:[~2017-08-10 17:30 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-08-10 17:29 [nft PATCH 0/6] A bunch of man page enhancements Phil Sutter
2017-08-10 17:29 ` [nft PATCH 1/6] nft.8: Document operations on ruleset Phil Sutter
2017-08-10 17:29 ` [nft PATCH 2/6] nft.8: Describe conntrack types Phil Sutter
2017-08-10 17:29 ` [nft PATCH 3/6] nft.8: Review reject statement description Phil Sutter
2017-08-10 17:29 ` [nft PATCH 4/6] nft.8: Add note about supported hooks for bridge family Phil Sutter
2017-08-10 17:29 ` [nft PATCH 5/6] nft.8: Describe base chain details Phil Sutter
2017-08-10 17:29 ` [nft PATCH 6/6] nft.8: Complete short description of arp family Phil Sutter
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.