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. :) Cheers, Phil
