Bug#504989: connlimit and etchnhalf
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 or Debian. Because once you patch iptables with your proposal, you break connlimit for all users running the 2.6.18 etch kernel. So the sanest solution is to backport xt_connlimit into 2.6.18 and update iptables for etch... Would such a backport run with a 2.6.18 etch kernel, too? That is the idea of backports in general. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#504989: connlimit and etchnhalf
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 pom extensions back then, but the Debian kernels did not support them. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#504989: connlimit and etchnhalf
* 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 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. I'm not sure what you're trying to say. Do you think that etch's iptables works with connlimit in the etchnhalf kernel? It doesn't. When I encountered this bug, I wasn't using any self-compiled software. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#504989: connlimit and etchnhalf
* 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 upstream bug. I'm not sure what you're trying to say. Do you think that etch's iptables works with connlimit in the etchnhalf kernel? It doesn't. When I encountered this bug, I wasn't using any self-compiled software. I am saying that iff your kernel is an unmodified vanilla one [does not matter who compiled it] and your iptables is also vanilla, that is, if they have _not_ been modified by the distribution, you get a working combination. Okay, fair enough, thanks for your analysis. It just confused me a bit because I was specifically reporting a bug in a Debian-modified iptables/kernel combiniation. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#504989: connlimit and etchnhalf
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. Because once you patch iptables with your proposal, you break connlimit for all users running the 2.6.18 etch kernel. So the sanest solution is to backport xt_connlimit into 2.6.18 and update iptables for etch... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#504989: connlimit and etchnhalf
* 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 either upstream or Debian. Because once you patch iptables with your proposal, you break connlimit for all users running the 2.6.18 etch kernel. So the sanest solution is to backport xt_connlimit into 2.6.18 and update iptables for etch... Would such a backport run with a 2.6.18 etch kernel, too? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#504989: connlimit and etchnhalf
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 sure what you're trying to say. Do you think that etch's iptables works with connlimit in the etchnhalf kernel? It doesn't. When I encountered this bug, I wasn't using any self-compiled software. I am saying that iff your kernel is an unmodified vanilla one [does not matter who compiled it] and your iptables is also vanilla, that is, if they have _not_ been modified by the distribution, you get a working combination. I am further implying that yes, iptables-1.3.6 from Debian is incompatible with _any_ kernel = 2.6.23 when you try to use connlimit. 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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
