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@xxxxxx> > > > --- > > > 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.
