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)
21/second = 21*3600*24/day = 1814400/day ~= 1815126/day => not far off ;-)
Created attachment 31314 [details] patch against iptables 1.2.2
Created attachment 31315 [details] patch against iptables 1.2.3
It's due to a rather unfortunate rounding of input values.
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.
Created attachment 31316 [details] a different approach
Today I was notified that this last patch has been applied to CVS (netfilter userspace).
Fixed in 1.2.4-1 (rawhide now, errata soon)