Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 53325

Summary: Errata conversion of iptables .... -m limit ##/sec
Product: [Retired] Red Hat Linux Reporter: Dario Lesca <d.lesca>
Component: iptablesAssignee: Bernhard Rosenkraenzer <bero>
Status: CLOSED ERRATA QA Contact:
Severity: high Docs Contact:
Priority: medium    
Version: 7.1CC: d.lesca
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2001-11-07 14:15:29 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
patch against iptables 1.2.2
none
patch against iptables 1.2.3
none
a different approach none

Description Dario Lesca 2001-09-06 18:25:24 UTC 
Description of Problem:

Errata conversion of -m limit 

Version-Release number of selected component (if applicable):

I also upgrade iptable whit RAW src package:
[root@bl00 RPMS]# rpm -qa |grep iptables
iptables-1.2.2-3
[root@bl00 RPMS]#

How Reproducible:

iptables -I INPUT -p icmp -m limit --limit 21/second -j ACCEPT

Actual Results:

[root@bl00 RPMS]# iptables-save
# Generated by iptables-save v1.2.2 on Thu Sep  6 18:29:53 2001
*filter
:INPUT ACCEPT [35:1900]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [32:2640]
-A INPUT -p icmp -m limit --limit 1815126/day -j ACCEPT
COMMIT
# Completed on Thu Sep  6 18:29:53 2001
	
Dario Lesca (d.lesca) (from Italy)
Comment 1 Michael Schwendt 2001-09-06 18:46:13 UTC 
21/second = 21*3600*24/day = 1814400/day ~= 1815126/day
=> not far off ;-)
Comment 2 Michael Schwendt 2001-09-08 09:46:26 UTC 
Created attachment 31314 [details]
patch against iptables 1.2.2
Comment 3 Michael Schwendt 2001-09-08 09:46:42 UTC 
Created attachment 31315 [details]
patch against iptables 1.2.3
Comment 4 Michael Schwendt 2001-09-08 09:48:17 UTC 
It's due to a rather unfortunate rounding of input values.
Comment 5 Michael Schwendt 2001-09-08 10:06:31 UTC 
Hmmm, with the patch applied, the slower rates become more inaccurate. For
instance, 6000/hour is rounded to 1/sec (= 3600/hour). Not so nice either. I
wonder what is more important. Fine grained rates of x/minute and y/second, or
per hour or per day?

One could probably implement a check that examines the remainder in the
calculation in the old code more closely, trying to determine the best matching
unit. Sort of, not checking the remainder against zero (like the old code does),
but only if the remainder of "rates[i].mult % period" is greater than some
threshold, the unit is found:

        if (period > rates[i].mult
            || rates[i].mult % period > X)
           break;

with X being some percentage of rates[i].mult or so.
Comment 6 Michael Schwendt 2001-09-08 11:01:44 UTC 
Created attachment 31316 [details]
a different approach
Comment 7 Michael Schwendt 2001-10-16 19:43:34 UTC 
Today I was notified that this last patch has been applied to CVS (netfilter
userspace).
Comment 8 Bernhard Rosenkraenzer 2001-10-30 11:46:32 UTC 
Fixed in 1.2.4-1 (rawhide now, errata soon)