[nft PATCH] doc: nft.8: Document lower priority limit for nat type chains

[nft PATCH] doc: nft.8: Document lower priority limit for nat type chains

[Phil Sutter]

Users can't know the magic limit.

Signed-off-by: Phil Sutter <phil@nwl.cc>
---
 doc/nft.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/doc/nft.txt b/doc/nft.txt
index 7de4935b4b375..0d60c7520d31e 100644
--- a/doc/nft.txt
+++ b/doc/nft.txt
@@ -439,6 +439,9 @@ name which specifies the order in which chains with the same *hook* value are
 traversed. The ordering is ascending, i.e. lower priority values have precedence
 over higher ones.
 
+With *nat* type chains, there's a lower excluding limit of -200 for *priority*
+values, because conntrack hooks at this priority and NAT requires it.
+
 Standard priority values can be replaced with easily memorizable names.  Not all
 names make sense in every family with every hook (see the compatibility matrices
 below) but their numerical value can still be used for prioritizing chains.
-- 
2.38.0

Re: [nft PATCH] doc: nft.8: Document lower priority limit for nat type chains

[Pablo Neira Ayuso]

On Thu, Mar 09, 2023 at 02:52:46PM +0100, Phil Sutter wrote:
> Users can't know the magic limit.
>
> Signed-off-by: Phil Sutter <phil@nwl.cc>
> ---
>  doc/nft.txt | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/doc/nft.txt b/doc/nft.txt
> index 7de4935b4b375..0d60c7520d31e 100644
> --- a/doc/nft.txt
> +++ b/doc/nft.txt
> @@ -439,6 +439,9 @@ name which specifies the order in which chains with the same *hook* value are
>  traversed. The ordering is ascending, i.e. lower priority values have precedence
>  over higher ones.
>  
> +With *nat* type chains, there's a lower excluding limit of -200 for *priority*
> +values, because conntrack hooks at this priority and NAT requires it.

prerouting, output 		-200 	NF_IP_PRI_CONNTRACK

this should only apply in these two hooks, it should be possible to
relax this in input and postrouting in the kernel.

> +
>  Standard priority values can be replaced with easily memorizable names.  Not all
>  names make sense in every family with every hook (see the compatibility matrices
>  below) but their numerical value can still be used for prioritizing chains.
> -- 
> 2.38.0
> 

Re: [nft PATCH] doc: nft.8: Document lower priority limit for nat type chains

[Phil Sutter]

On Thu, Mar 09, 2023 at 04:23:25PM +0100, Pablo Neira Ayuso wrote:
> On Thu, Mar 09, 2023 at 02:52:46PM +0100, Phil Sutter wrote:
> > Users can't know the magic limit.
> >
> > Signed-off-by: Phil Sutter <phil@nwl.cc>
> > ---
> >  doc/nft.txt | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/doc/nft.txt b/doc/nft.txt
> > index 7de4935b4b375..0d60c7520d31e 100644
> > --- a/doc/nft.txt
> > +++ b/doc/nft.txt
> > @@ -439,6 +439,9 @@ name which specifies the order in which chains with the same *hook* value are
> >  traversed. The ordering is ascending, i.e. lower priority values have precedence
> >  over higher ones.
> >  
> > +With *nat* type chains, there's a lower excluding limit of -200 for *priority*
> > +values, because conntrack hooks at this priority and NAT requires it.
> 
> prerouting, output 		-200 	NF_IP_PRI_CONNTRACK
> 
> this should only apply in these two hooks, it should be possible to
> relax this in input and postrouting in the kernel.

So far nobody has complained, right? Motivation for my patch came from a
question in IRC, I don't think there was a real need for more priority
"space" in nat type chains. So while we may relax the restriction, I
don't see the motivation to do so. :)

Cheers, Phil

Re: [nft PATCH] doc: nft.8: Document lower priority limit for nat type chains

[Pablo Neira Ayuso]

On Thu, Mar 09, 2023 at 04:32:39PM +0100, Phil Sutter wrote:
> On Thu, Mar 09, 2023 at 04:23:25PM +0100, Pablo Neira Ayuso wrote:
> > On Thu, Mar 09, 2023 at 02:52:46PM +0100, Phil Sutter wrote:
> > > Users can't know the magic limit.
> > >
> > > Signed-off-by: Phil Sutter <phil@nwl.cc>
> > > ---
> > >  doc/nft.txt | 3 +++
> > >  1 file changed, 3 insertions(+)
> > > 
> > > diff --git a/doc/nft.txt b/doc/nft.txt
> > > index 7de4935b4b375..0d60c7520d31e 100644
> > > --- a/doc/nft.txt
> > > +++ b/doc/nft.txt
> > > @@ -439,6 +439,9 @@ name which specifies the order in which chains with the same *hook* value are
> > >  traversed. The ordering is ascending, i.e. lower priority values have precedence
> > >  over higher ones.
> > >  
> > > +With *nat* type chains, there's a lower excluding limit of -200 for *priority*
> > > +values, because conntrack hooks at this priority and NAT requires it.
> > 
> > prerouting, output 		-200 	NF_IP_PRI_CONNTRACK
> > 
> > this should only apply in these two hooks, it should be possible to
> > relax this in input and postrouting in the kernel.
> 
> So far nobody has complained, right? Motivation for my patch came from a
> question in IRC, I don't think there was a real need for more priority
> "space" in nat type chains. So while we may relax the restriction, I
> don't see the motivation to do so. :)

It is fine, this can be updated later. Please push it out because
release is coming.

It should be also possible to warn user via error reporting from
userspace.

Re: [nft PATCH] doc: nft.8: Document lower priority limit for nat type chains

[Phil Sutter]

On Thu, Mar 09, 2023 at 02:52:46PM +0100, Phil Sutter wrote:
> Users can't know the magic limit.
> 
> Signed-off-by: Phil Sutter <phil@nwl.cc>

Patch applied.