ipt_account / iptables 1.3.8

ipt_account / iptables 1.3.8

[Thomas Jacob]

[-- Attachment #1: Type: text/plain, Size: 316 bytes --]

Hi List,

It appears that ipt_account has vanished from
iptables 1.3.8 (it was still there in 1.3.7) could
someone please comment on the why?

The changelogs do not mention anything about it, neither
does the source, and also I couldn't find anything
googling thru the mailing list archives.

    T Jacob

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

Re: ipt_account / iptables 1.3.8

[Pascal Hambourg]

Hello,

Thomas Jacob a écrit :
> 
> It appears that ipt_account has vanished from
> iptables 1.3.8 (it was still there in 1.3.7) could
> someone please comment on the why?
> 
> The changelogs do not mention anything about it

They do, in a rather laconic way though :

<quote>
- Remove extensions for unmaintained/obsolete patchlets
</quote>

AFAIK, the concerned extensions are : fuzzy, nth, random (both 
superseded by statistic), ROUTE, account, BALANCE, childlevel, 
connlimit, dstlimit, FTOS, IPMARK, ipv4options, IPV4OPTSSTRIP, mport, 
NETLINK, osf, psd, record_rpc, rpc, TARPIT, TCPLAG, time, TRACE, u32, XOR.

Re: ipt_account / iptables 1.3.8

[David Ford]

Pascal Hambourg wrote:
> [...]
> AFAIK, the concerned extensions are : fuzzy, nth, random (both
> superseded by statistic), ROUTE, account, BALANCE, childlevel,
> connlimit, dstlimit, FTOS, IPMARK, ipv4options, IPV4OPTSSTRIP, mport,
> NETLINK, osf, psd, record_rpc, rpc, TARPIT, TCPLAG, time, TRACE, u32,
> XOR.

Is there something that functionally replaces TARPIT?

Re: ipt_account / iptables 1.3.8

[Jan Engelhardt]

On Jun 27 2007 14:30, David Ford wrote:
>Pascal Hambourg wrote:
>> [...]
>> AFAIK, the concerned extensions are : fuzzy, nth, random (both
>> superseded by statistic), ROUTE, account, BALANCE, childlevel,
>> connlimit, dstlimit, FTOS, IPMARK, ipv4options, IPV4OPTSSTRIP, mport,
>> NETLINK, osf, psd, record_rpc, rpc, TARPIT, TCPLAG, time, TRACE, u32,
>> XOR.
>
>Is there something that functionally replaces TARPIT?
>

Like, xt_DELUDE?



	Jan
-- 

Re: ipt_account / iptables 1.3.8

[Jan Engelhardt]

On Jun 27 2007 14:30, David Ford wrote:
>Pascal Hambourg wrote:
>> <quote>
>> - Remove extensions for unmaintained/obsolete patchlets
>> </quote>
>>
>> AFAIK, the concerned extensions are : fuzzy, nth, random (both
>> superseded by statistic), ROUTE, account, BALANCE, childlevel,
>> connlimit, dstlimit, FTOS, IPMARK, ipv4options, IPV4OPTSSTRIP, mport,
>> NETLINK, osf, psd, record_rpc, rpc, TARPIT, TCPLAG, time, TRACE, u32,
>> XOR.
>
>Is there something that functionally replaces TARPIT?
>
Uhm, please add a reference next time; only by chance I found the thread origin
at the netfilter@ list.

No idea why TARPIT got removed. Maybe it's "unmaintained", but it did not need
a lot of maintenance either. Though, people had to patch their kernel.

There is no replacement for TARPIT - it's solid. (And xt_DELUDE does not
replace it; it is something inbetween REJECT and TARPIT.)


	Jan
-- 

Re: ipt_account / iptables 1.3.8

[Patrick McHardy]

Jan Engelhardt wrote:
> Uhm, please add a reference next time; only by chance I found the thread origin
> at the netfilter@ list.
>
> No idea why TARPIT got removed. Maybe it's "unmaintained", but it did not need
> a lot of maintenance either. Though, people had to patch their kernel.
>
> There is no replacement for TARPIT - it's solid. (And xt_DELUDE does not
> replace it; it is something inbetween REJECT and TARPIT.)


Maintenance is only one aspect, but it is a problem since we can't
even compile test it without patching our kernels. A second problem
with most of these matches and targets is that they usually have a
broken non-64 bit clean ABI and if we decide to merge them someday
we need to fix that and thereby break compatibility before it was
even included in the kernel, which is ridiculous.

They should have never gotten into a release and we fixed that now.
You can still patch your kernel and iptables as you like.

Re: ipt_account / iptables 1.3.8

[Jan Engelhardt]

On Jun 27 2007 21:39, Patrick McHardy wrote:
> Jan Engelhardt wrote:
>> Uhm, please add a reference next time; only by chance I found the thread
>> origin
>> at the netfilter@ list.
>>
>> No idea why TARPIT got removed. Maybe it's "unmaintained", but it did not
>> need
>> a lot of maintenance either. Though, people had to patch their kernel.
>>
>> There is no replacement for TARPIT - it's solid. (And xt_DELUDE does not
>> replace it; it is something inbetween REJECT and TARPIT.)
>
> Maintenance is only one aspect, but it is a problem since we can't
> even compile test it without patching our kernels.

So would not it be better to add TARPIT to the kernel and have the whole
package work?

> A second problem
> with most of these matches and targets is that they usually have a
> broken non-64 bit clean ABI and if we decide to merge them someday
> we need to fix that and thereby break compatibility before it was
> even included in the kernel, which is ridiculous.

I agree, it should at least be 64 clean.

> They should have never gotten into a release and we fixed that now.
> You can still patch your kernel and iptables as you like.
>

Can I also submit a (hopefully cleaned) e.g. TARPIT?


	Jan
-- 

Re: ipt_account / iptables 1.3.8

[Jozsef Kadlecsik]

On Wed, 27 Jun 2007, Jan Engelhardt wrote:

> Can I also submit a (hopefully cleaned) e.g. TARPIT?

I'd like to see an IPv4/IPv6 compatible TARPIT module in the mainline 
kernel. But please extend the target so that it could be used from the raw 
table and let the reply packets skip conntrack. Thus we could benefit from 
TARPIT even in a full blown conntrack/nat setup as well. (If I recall 
correctly, that is not possible with the original version.)

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
           H-1525 Budapest 114, POB. 49, Hungary

Re: ipt_account / iptables 1.3.8

[Patrick McHardy]

Jozsef Kadlecsik wrote:
> On Wed, 27 Jun 2007, Jan Engelhardt wrote:
> 
>> Can I also submit a (hopefully cleaned) e.g. TARPIT?
> 
> 
> I'd like to see an IPv4/IPv6 compatible TARPIT module in the mainline
> kernel. But please extend the target so that it could be used from the
> raw table and let the reply packets skip conntrack. Thus we could
> benefit from TARPIT even in a full blown conntrack/nat setup as well.
> (If I recall correctly, that is not possible with the original version.)

The easiest way to do this would probably be to optionally attach
a notrack conntrack to new packets. Looking at the version in SVN,
it also needs:

- use generic checks for table and hook validation
- remove impossible skb->dst NULL ptr check
- remove impossible check for PACKET_OTHERHOST
- not abuse xrlim_allow
- resync TCP packet generation code with ipt_REJECT, especially
  properly deal with IPsec, not use ip_direct_send but dst_output
- kill ip_direct_send
- kill obsolete ifdefs

Shouldn't be much work, maybe I'll look into this after finishing
my conntrack hash patches if no one beats me to it.

Re: ipt_account / iptables 1.3.8

[Jan Engelhardt]

On Jun 28 2007 01:44, Patrick McHardy wrote:
>Shouldn't be much work, maybe I'll look into this after finishing
>my conntrack hash patches if no one beats me to it.
>
Since you keep me busy with xt_u32 and xt_connlimit, I'll leave it to you for
now :)



	Jan
-- 

Re: ipt_account / iptables 1.3.8

[Jozsef Kadlecsik]

On Thu, 28 Jun 2007, Patrick McHardy wrote:

>> I'd like to see an IPv4/IPv6 compatible TARPIT module in the mainline
>> kernel. But please extend the target so that it could be used from the
>> raw table and let the reply packets skip conntrack. Thus we could
>> benefit from TARPIT even in a full blown conntrack/nat setup as well.
>> (If I recall correctly, that is not possible with the original version.)
>
> The easiest way to do this would probably be to optionally attach
> a notrack conntrack to new packets.

Yes, exactly.

> Looking at the version in SVN, it also needs:
[...]
> Shouldn't be much work, maybe I'll look into this after finishing
> my conntrack hash patches if no one beats me to it.

The amount of work you have been doing is simply amazing...

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
           H-1525 Budapest 114, POB. 49, Hungary

experiences with ipt_ACCOUNT (was Re: ipt_account / iptables 1.3.8)

[Thomas Jacob]

Oh well, thanks for the info. A pity, as in kernels up to 2.6.18
the module was doing its job nicely, but I've now tried it with 2.6.21.5
and
there it doesn't even compile anymore.

There's an alternative module called ipt_ACCOUNT however, where
the docs say that it does support 2.6.21.

==> http://www.intra2net.com/de/produkte/opensource/ipt_account/

I wonder if anyone would like to share experiences with
that particular module in terms of performance and
stability in a 70-100kpps load scenario.

On Wed, 2007-06-27 at 20:16 +0200, Pascal Hambourg wrote:
> Hello,
> 
> Thomas Jacob a écrit :
> > 
> > It appears that ipt_account has vanished from
> > iptables 1.3.8 (it was still there in 1.3.7) could
> > someone please comment on the why?
> > 
> > The changelogs do not mention anything about it
> 
> They do, in a rather laconic way though :
> 
> <quote>
> - Remove extensions for unmaintained/obsolete patchlets
> </quote>
> 
> AFAIK, the concerned extensions are : fuzzy, nth, random (both 
> superseded by statistic), ROUTE, account, BALANCE, childlevel, 
> connlimit, dstlimit, FTOS, IPMARK, ipv4options, IPV4OPTSSTRIP, mport, 
> NETLINK, osf, psd, record_rpc, rpc, TARPIT, TCPLAG, time, TRACE, u32, XOR.