[iptables PATCH] man: recent: Adjust to changes around ip_pkt_list_tot parameter

[iptables PATCH] man: recent: Adjust to changes around ip_pkt_list_tot parameter

[Phil Sutter]

The parameter became obsolete in kernel commit abc86d0f9924 ("netfilter:
xt_recent: relax ip_pkt_list_tot restrictions").

Reported-by: Fabio <pedretti.fabio@gmail.com>
Closes: https://bugzilla.netfilter.org/show_bug.cgi?id=1745
Cc: Florian Westphal <fw@strlen.de>
Signed-off-by: Phil Sutter <phil@nwl.cc>
---
 extensions/libxt_recent.man | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/extensions/libxt_recent.man b/extensions/libxt_recent.man
index 82537fab9846f..e0305f9857e29 100644
--- a/extensions/libxt_recent.man
+++ b/extensions/libxt_recent.man
@@ -55,9 +55,7 @@ This option must be used in conjunction with one of \fB\-\-rcheck\fP or
 address is in the list and packets had been received greater than or equal to
 the given value. This option may be used along with \fB\-\-seconds\fP to create
 an even narrower match requiring a certain number of hits within a specific
-time frame. The maximum value for the hitcount parameter is given by the
-"ip_pkt_list_tot" parameter of the xt_recent kernel module. Exceeding this
-value on the command line will cause the rule to be rejected.
+time frame.
 .TP
 \fB\-\-rttl\fP
 This option may only be used in conjunction with one of \fB\-\-rcheck\fP or
@@ -93,8 +91,10 @@ to flush the DEFAULT list (remove all entries).
 \fBip_list_tot\fP=\fI100\fP
 Number of addresses remembered per table.
 .TP
-\fBip_pkt_list_tot\fP=\fI20\fP
-Number of packets per address remembered.
+\fBip_pkt_list_tot\fP=\fI0\fP
+Number of packets per address remembered. This parameter is obsolete since
+kernel version 3.19 which started to calculate the table size based on given
+\fB\-\-hitcount\fP parameter.
 .TP
 \fBip_list_hash_size\fP=\fI0\fP
 Hash table size. 0 means to calculate it based on ip_list_tot by rounding it up
-- 
2.43.0

Re: [iptables PATCH] man: recent: Adjust to changes around ip_pkt_list_tot parameter

[Fabio Pedretti]

Hi, thanks.
It looks like there is still a limit of 255 for hitcount (and
ip_pkt_list_tot), right?

Maybe leave:
The maximum value for the hitcount parameter is 255.

Even better, remove the limit? :)
That would improve usefulness of recent, similar to hashlimit which
for example has no restrictions on --hashlimit-above

[root@debian:~]# uname -a
Linux debian 6.7.12-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.7.12-1
(2024-04-24) x86_64 GNU/Linux

[root@debian:~]# iptables -A INPUT -m recent --name badguys --rcheck
--hitcount 255
[root@debian:~]# iptables -A INPUT -m recent --name badguys --rcheck
--hitcount 256
iptables v1.8.10 (nf_tables):  RULE_APPEND failed (Invalid argument):
rule in chain INPUT

And anyway:
[root@debian:~]# modprobe -r xt_recent ; modprobe xt_recent ip_pkt_list_tot=255
[root@debian:~]# modprobe -r xt_recent ; modprobe xt_recent ip_pkt_list_tot=256
modprobe: ERROR: could not insert 'xt_recent': Invalid argument


Il giorno mer 12 giu 2024 alle ore 17:13 Phil Sutter <phil@nwl.cc> ha scritto:
>
> The parameter became obsolete in kernel commit abc86d0f9924 ("netfilter:
> xt_recent: relax ip_pkt_list_tot restrictions").
>
> Reported-by: Fabio <pedretti.fabio@gmail.com>
> Closes: https://bugzilla.netfilter.org/show_bug.cgi?id=1745
> Cc: Florian Westphal <fw@strlen.de>
> Signed-off-by: Phil Sutter <phil@nwl.cc>
> ---
>  extensions/libxt_recent.man | 10 +++++-----
>  1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/extensions/libxt_recent.man b/extensions/libxt_recent.man
> index 82537fab9846f..e0305f9857e29 100644
> --- a/extensions/libxt_recent.man
> +++ b/extensions/libxt_recent.man
> @@ -55,9 +55,7 @@ This option must be used in conjunction with one of \fB\-\-rcheck\fP or
>  address is in the list and packets had been received greater than or equal to
>  the given value. This option may be used along with \fB\-\-seconds\fP to create
>  an even narrower match requiring a certain number of hits within a specific
> -time frame. The maximum value for the hitcount parameter is given by the
> -"ip_pkt_list_tot" parameter of the xt_recent kernel module. Exceeding this
> -value on the command line will cause the rule to be rejected.
> +time frame.
>  .TP
>  \fB\-\-rttl\fP
>  This option may only be used in conjunction with one of \fB\-\-rcheck\fP or
> @@ -93,8 +91,10 @@ to flush the DEFAULT list (remove all entries).
>  \fBip_list_tot\fP=\fI100\fP
>  Number of addresses remembered per table.
>  .TP
> -\fBip_pkt_list_tot\fP=\fI20\fP
> -Number of packets per address remembered.
> +\fBip_pkt_list_tot\fP=\fI0\fP
> +Number of packets per address remembered. This parameter is obsolete since
> +kernel version 3.19 which started to calculate the table size based on given
> +\fB\-\-hitcount\fP parameter.
>  .TP
>  \fBip_list_hash_size\fP=\fI0\fP
>  Hash table size. 0 means to calculate it based on ip_list_tot by rounding it up
> --
> 2.43.0
>

Re: [iptables PATCH] man: recent: Adjust to changes around ip_pkt_list_tot parameter

[Phil Sutter]

On Wed, Jun 12, 2024 at 06:00:54PM +0200, Fabio Pedretti wrote:
> Hi, thanks.
> It looks like there is still a limit of 255 for hitcount (and
> ip_pkt_list_tot), right?

Yeah, that's a kernel limitation, namely XT_RECENT_MAX_NSTAMPS. We may
lift or even drop that, but it will require a separate patch either way.

> Maybe leave:
> The maximum value for the hitcount parameter is 255.
> 
> Even better, remove the limit? :)

I see that struct recent_table::nstamps_max_mask must hold the value of
the next power of two of the given hitcount (minus one) and is currently
a u8. So there will never be no limit, but one could use a u32 in that
place and set XT_RECENT_MAX_NSTAMPS to 0xffffffff.

I'll send a patch so we have something to discuss.

Cheers, Phil

Re: [iptables PATCH] man: recent: Adjust to changes around ip_pkt_list_tot parameter

[Phil Sutter]

On Wed, Jun 12, 2024 at 05:13:28PM +0200, Phil Sutter wrote:
> The parameter became obsolete in kernel commit abc86d0f9924 ("netfilter:
> xt_recent: relax ip_pkt_list_tot restrictions").

Applied this patch despite the discussion about mentioning a (new) max
value as that has changed recently. I we could follow-up once kernel
commit f4ebd03496f6 ("netfilter: xt_recent: Lift restrictions on max
hitcount value") has landed in a release.

Cheers, Phil