netfilter buglog - Mar 2024 - [Bug 1740] New: hashlimit limit: reduction to lowest terms in the output is confusing

https://bugzilla.netfilter.org/show_bug.cgi?id=1740

            Bug ID: 1740
           Summary: hashlimit limit: reduction to lowest terms in the
                    output is confusing
           Product: iptables
           Version: 1.8.x
          Hardware: x86_64
                OS: Debian GNU/Linux
            Status: NEW
          Severity: minor
          Priority: P5
         Component: iptables
          Assignee: netfilter-buglog at lists.netfilter.org
          Reporter: pedretti.fabio at gmail.com
>From the man page:
--hashlimit-above amount[/second|/minute|/hour|/day]
  Match if the rate is above amount/quantum.

This:

iptables -F OUTPUT
iptables -A OUTPUT -m hashlimit --hashlimit-name foo --hashlimit-above 59/m
iptables -A OUTPUT -m hashlimit --hashlimit-name foo --hashlimit-above 60/m
iptables -A OUTPUT -m hashlimit --hashlimit-name foo --hashlimit-above 61/m
iptables -A OUTPUT -m hashlimit --hashlimit-name foo --hashlimit-above 59/h
iptables -A OUTPUT -m hashlimit --hashlimit-name foo --hashlimit-above 60/h
iptables -A OUTPUT -m hashlimit --hashlimit-name foo --hashlimit-above 61/h
iptables -A OUTPUT -m hashlimit --hashlimit-name foo --hashlimit-above 23/d
iptables -A OUTPUT -m hashlimit --hashlimit-name foo --hashlimit-above 24/d
iptables -A OUTPUT -m hashlimit --hashlimit-name foo --hashlimit-above 25/d
iptables -A OUTPUT -m hashlimit --hashlimit-name foo --hashlimit-above 86399/d
iptables -A OUTPUT -m hashlimit --hashlimit-name foo --hashlimit-above 86400/d
iptables -A OUTPUT -m hashlimit --hashlimit-name foo --hashlimit-above 86401/d
iptables -L OUTPUT -v -n

gives:

Chain OUTPUT (policy ACCEPT 3566 packets, 3016K bytes)
 pkts bytes target     prot opt in     out     source               destination 
    0     0            0    --  *      *       0.0.0.0/0            0.0.0.0/0  
         limit: above 59/min burst 5
    0     0            0    --  *      *       0.0.0.0/0            0.0.0.0/0  
         limit: above 1/sec burst 5 htable-expire 60000
    0     0            0    --  *      *       0.0.0.0/0            0.0.0.0/0  
         limit: above 61/min burst 5
    0     0            0    --  *      *       0.0.0.0/0            0.0.0.0/0  
         limit: above 59/hour burst 5
    0     0            0    --  *      *       0.0.0.0/0            0.0.0.0/0  
         limit: above 1/min burst 5 htable-expire 3600000
    0     0            0    --  *      *       0.0.0.0/0            0.0.0.0/0  
         limit: above 61/hour burst 5
    0     0            0    --  *      *       0.0.0.0/0            0.0.0.0/0  
         limit: above 23/day burst 5
    0     0            0    --  *      *       0.0.0.0/0            0.0.0.0/0  
         limit: above 1/hour burst 5 htable-expire 86400000
    0     0            0    --  *      *       0.0.0.0/0            0.0.0.0/0  
         limit: above 25/day burst 5
    0     0            0    --  *      *       0.0.0.0/0            0.0.0.0/0  
         limit: above 86399/day burst 5
    0     0            0    --  *      *       0.0.0.0/0            0.0.0.0/0  
         limit: above 1/sec burst 5 htable-expire 86400000
    0     0            0    --  *      *       0.0.0.0/0            0.0.0.0/0  
         limit: above 86401/day burst 5

It's a bit strange to have a different output when the requested
amount/quantum
can be reduced to lowest terms. This also requires showing the proper
htable-expire time and may be a bit cumbersome to read.

I would expect:
limit: above 1/sec burst 5 htable-expire 60000
would rather be shown as
limit: above 60/min burst 5
as well as the other occurrences.

Thanks.

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20240324/9f9986a5/attachment.html>

https://bugzilla.netfilter.org/show_bug.cgi?id=1740

Phil Sutter <phil at nwl.cc> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |phil at nwl.cc
         Resolution|---                         |WONTFIX

--- Comment #1 from Phil Sutter <phil at nwl.cc> ---
Hi,

Internally the input is converted into a single value for use by the kernel.
When listing the rule, this value is converted back into a human-readable
format using the most appropriate format. Since 60/m reduces to 1/s, the latter
form is automatically chosen. I don't think it's worth carrying extra
data to
retain the user-given unit.

Cheers, Phil

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20240409/99da7ec3/attachment.html>

https://bugzilla.netfilter.org/show_bug.cgi?id=1740

--- Comment #2 from Fabio <pedretti.fabio at gmail.com> ---
Just want to add that it won't need extra data, but it could just check the
htable-expire value:

86400000 -> report it in units/day (and avoid printing the htable-expire)
3600000 -> report it in units/hour (and avoid printing the htable-expire)
60000 -> report it in units/minute (and avoid printing the htable-expire)

Anyway I can agree with you, if it adds complexity (extra data or not) maybe
it's not worth.

Thanks.

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20240409/2372f892/attachment.html>

https://bugzilla.netfilter.org/show_bug.cgi?id=1740

--- Comment #3 from Phil Sutter <phil at nwl.cc> ---
(In reply to Fabio from comment #2)
> Just want to add that it won't need extra data, but it could just check
the
> htable-expire value:
> 
> 86400000 -> report it in units/day (and avoid printing the
htable-expire)
> 3600000 -> report it in units/hour (and avoid printing the
htable-expire)
> 60000 -> report it in units/minute (and avoid printing the
htable-expire)
Yes, htable-expire defaults to the given unit * 1000. Though it may be
specified explicitly, so extra checks are probably needed, at least a test for
"expire == unit * 1000". But this in turn may match by chance and
cause
unexpected formatting of the rate value.
> Anyway I can agree with you, if it adds complexity (extra data or not)
maybe
> it's not worth.
I am against changing this if it's doable given the data the kernel presents
already. Adding a new match revision is the kind of overhead I want to avoid.
So if you see a solution to the above, feel free to reopen this ticket!

Thanks, Phil

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20240409/5ba29113/attachment.html>