ipt_recent misuses jiffies? misreports oldest_pkt too

ipt_recent misuses jiffies? misreports oldest_pkt too

[Grant Coady]

Hi there,

Given The LDD says:
"note that the actual clock frequency is almost completely hidden from user
space. The macro HZ always expands to 100 when user-space programs include
param.h, and every counter reported to user space is converted accordingly. 
This applies to clock(3), times(2), and any related function."

Why does ipt_recent expose jiffies to userspace when there seems to be no 
reliable method to determine the jiffies/second rate?  Should not ipt_recent 
report in 10ms increments to match 'official jiffies'? (or why not epoch 
seconds?)  I asked about this on lkml and received no response.  

So I am here looking for answers ;)  So far the most reliable way to 
discover jiffie rate is to look at .config, but this fails if .config 
is not available (user hasn't compiled own kernel), so where else does 
one look for that jiffies rate number?  The /proc/timer_list gives 
conflicting results on different hardware, its jiffies value can be 
somewhat fictional:

fictional:
grant@pooh64:~$ awk 'NR==FNR{up=$1}/^jiff/{print $2/up}' \
	/proc/uptime /proc/timer_list
53109
53109
grant@pooh64:~$ awk '/^CONFIG_HZ=/ {split($1, a, "="); print a[2]}' \
	/lib/modules/$(uname -r)/build/.config
300


reasonable:
grant@deltree:~$ awk 'NR==FNR{up=$1}/^jiff/{print $2/up}' \
	/proc/uptime /proc/timer_list
249.865
grant@deltree:~$ awk '/^CONFIG_HZ=/ {split($1, a, "="); print a[2]}' \
	/lib/modules/$(uname -r)/build/.config
250

There's also another problem with ipt_recent misreporting oldest_pkt -- 
the number given is meaningless as it is not an offset to the oldest 
packet timestamp, nor does it indicate how many packets have been seen.
There seems to be a problem when the table is full, I'm still collecting 
data on this.

Is anyone working on a fix for ipt_recent?  If not I'll have a go, need to 
do a whitespace cleanup first then fix the issues.

I'm using iptables 1.4.1.1 with linux-2.6.26.5 on slackware-11.0.

Thanks,
Grant.

Re: ipt_recent misuses jiffies? misreports oldest_pkt too

[Patrick McHardy]

Grant Coady wrote:
> Hi there,
> 
> Given The LDD says:
> "note that the actual clock frequency is almost completely hidden from user
> space. The macro HZ always expands to 100 when user-space programs include
> param.h, and every counter reported to user space is converted accordingly. 
> This applies to clock(3), times(2), and any related function."
> 
> Why does ipt_recent expose jiffies to userspace when there seems to be no 
> reliable method to determine the jiffies/second rate?  Should not ipt_recent 
> report in 10ms increments to match 'official jiffies'? (or why not epoch 
> seconds?)  I asked about this on lkml and received no response.  

It probably should use USER_HZ units. I just rewrote it, but kept
the old interface as it was for compatibility.

> There's also another problem with ipt_recent misreporting oldest_pkt -- 
> the number given is meaningless as it is not an offset to the oldest 
> packet timestamp, nor does it indicate how many packets have been seen.
> There seems to be a problem when the table is full, I'm still collecting 
> data on this.

Indeed, its completely useless information. Actually I don't see
much use for anything in that proc file, but again, I kept it for 
compatiblity.

> Is anyone working on a fix for ipt_recent?  If not I'll have a go, need to 
> do a whitespace cleanup first then fix the issues.

Please base your patches on

git://git.kernel.org/pub/scm/linux/kernel/git/kaber/nf-next-2.6.git

Re: ipt_recent misuses jiffies? misreports oldest_pkt too

[Grant Coady]

Hi Patrick,

On Thu, 25 Sep 2008 06:46:54 +0200, Patrick McHardy <kaber@trash.net> wrote:

>Grant Coady wrote:
>> Hi there,
>> 
>> Given The LDD says:
>> "note that the actual clock frequency is almost completely hidden from user
>> space. The macro HZ always expands to 100 when user-space programs include
>> param.h, and every counter reported to user space is converted accordingly. 
>> This applies to clock(3), times(2), and any related function."
>> 
>> Why does ipt_recent expose jiffies to userspace when there seems to be no 
>> reliable method to determine the jiffies/second rate?  Should not ipt_recent 
>> report in 10ms increments to match 'official jiffies'? (or why not epoch 
>> seconds?)  I asked about this on lkml and received no response.  
>
>It probably should use USER_HZ units. I just rewrote it, but kept
>the old interface as it was for compatibility.
>
>> There's also another problem with ipt_recent misreporting oldest_pkt -- 
>> the number given is meaningless as it is not an offset to the oldest 
>> packet timestamp, nor does it indicate how many packets have been seen.
>> There seems to be a problem when the table is full, I'm still collecting 
>> data on this.
>
>Indeed, its completely useless information. Actually I don't see
>much use for anything in that proc file, but again, I kept it for 
>compatiblity.

Twice you mention compatibility, should I plan on a replacement so the 
old code can be deprecated over time?  The proc file is useful for 
external timebase process to remove stale IPs or inject IPs for service 
quota limiting.  (At least, I can see a use for it that way).
...
>Please base your patches on
>
>git://git.kernel.org/pub/scm/linux/kernel/git/kaber/nf-next-2.6.git

Yeah, me git-challenged ;) got to figure out how to make two trees 
(this and kernel) play together?  Got the git dribbling in at all of 
3k/s (900k objects). 

Thanks,
Grant.

Re: ipt_recent misuses jiffies? misreports oldest_pkt too

[Patrick McHardy]

Grant Coady wrote:
> On Thu, 25 Sep 2008 06:46:54 +0200, Patrick McHardy <kaber@trash.net> wrote:
> 
>> Indeed, its completely useless information. Actually I don't see
>> much use for anything in that proc file, but again, I kept it for 
>> compatiblity.
> 
> Twice you mention compatibility, should I plan on a replacement so the 
> old code can be deprecated over time?  The proc file is useful for 
> external timebase process to remove stale IPs or inject IPs for service 
> quota limiting.  (At least, I can see a use for it that way).

The tree I pointed to includes a port of ipt_recent to IPv6 and
adds a new proc file for that. So you could just fix it for the
new proc file, that avoids all compatibility issues.

>> Please base your patches on
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/kaber/nf-next-2.6.git
> 
> Yeah, me git-challenged ;) got to figure out how to make two trees 
> (this and kernel) play together?  Got the git dribbling in at all of 
> 3k/s (900k objects). 

Its a full tree, so you can simply compile and boot that one.
Or you can pull it into an existing clone of Linus' tree.