On Sunday 2008-12-07 06:32, Florian Weimer wrote:
>
>> This does not look right at all. The kernel returns a binary blob
>> structured exactly like ipt_connlimit_info -- you can't just go and
>> change the way userspace interprets that blob.
>>
>> What problem are you trying to fix here, anyway?
>
>The kernel blob changed from 2.6.18 to 2.6.24. With my patch, it
>works on 2.6.24 (but not on 2.6.18, I guess). Without it, it doesn't.
The kernel blob never changed, because xt_connlimit was first
introduced into the kernel in version 2.6.23. *ipt*_connlimit (from
patch-o-matic) never found its way into the mainline kernel.
So this is not an upstream bug.
POM has had severe quality problems with its code, one of which
you are just experiencing.
32 64 Alignment overview
------------------------------------
Offset struct ipt_connlimit_info {
0 0 int limit;
4 4 int inverse;
8 8 u_int32_t mask;
12 16 struct ipt_connlimit_data *data;
};
16 24
Because the struct has different sizes on different bit-nesses, you
will inevidently run into problems. There is no way to make this work
for all combinations of 32u-32k, 32u-64k and 64u-64k simultaneously.
But that just aside.
Kernels >= 2.6.23 return a struct xt_connlimit blob, while Debian's
patched iptables-1.3.6 interprets that as a struct ipt_connlimit.
(This actually happens because modules exchange data by module name,
"connlimit", and this name has not changed between ipt_connlimit and
xt_connlimit.)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
