Troex Nevelin wrote:
>That is OK as I don't have xt_connlimit.ko module in this kernel, so
>there is no bug, right?
But you do have ipt_connlimit, in, most likely,
net/ipv4/netfilter/ipt_connlimit.ko. Both ipt_connlimit and xt_connlimit
use same ID (“connlimit.0”), which is why this 'bug' did
Hello,
I have similar problem here with two boxes both running etch.
I'm trying to load next firewall rules:
iptables -A INPUT -p tcp --dport 80 -m connlimit --connlimit-above 16
--connlimit-mask 24 -j REJECT
box1:
linux-image-2.6.18-4-686 (2.6.18.dfsg.1-12etch2)
iptables 1.3.6.0debian1-5
#
On Sunday 2008-12-07 14:05, Florian Weimer wrote:
>>>
>>>It just confused me a bit because I was specifically reporting a bug in
>>>a Debian-modified iptables/kernel combiniation.
>>
>> Right. In your specific case, the only thing you can do is
>> upgrade to a newer iptables from either upstream
On Sun, Dec 7, 2008 at 7:34 AM, Jan Engelhardt <[EMAIL PROTECTED]> wrote:
> Debian happened to patch in ipt_connlimit into their
> iptables 1.3.6 and kernel 2.6.18. And they (logically) did
> not do so for 2.6.24, because xt_connlimit is included since
> then.
Debian's iptables included various p
* Jan Engelhardt:
> On Sunday 2008-12-07 13:49, Florian Weimer wrote:
>>
>>It just confused me a bit because I was specifically reporting a bug in
>>a Debian-modified iptables/kernel combiniation.
>
> Right. In your specific case, the only thing you can do is
> upgrade to a newer iptables from ei
On Sunday 2008-12-07 13:49, Florian Weimer wrote:
>
>It just confused me a bit because I was specifically reporting a bug in
>a Debian-modified iptables/kernel combiniation.
Right. In your specific case, the only thing you can do is
upgrade to a newer iptables from either upstream or Debian.
Bec
* Jan Engelhardt:
> On Sunday 2008-12-07 13:20, Florian Weimer wrote:
>>>
>>> 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
On Sunday 2008-12-07 13:20, Florian Weimer wrote:
>>
>> 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.
>
>I'm not
* Jan Engelhardt:
> 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 t
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?
* Jan Engelhardt:
> 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 t
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?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject o
Package: iptables
Version: 1.3.6.0debian1-5
Something like the following patch is required due to the xt_*
reorganization in the kernel.
---
iptables-1.3.6.0debian1.orig/iptables/include/linux/netfilter_ipv4/ipt_connlimit.h
+++
iptables-1.3.6.0debian1/iptables/include/linux/netfilter_ipv4/ipt_c
13 matches
Mail list logo
