Subject: Re: [PATCH v4] netfilter: ipt_CLUSTERIP: remove "no conntrack!"

From: Pablo Neira Ayuso <[email-masked]>
Date: Thu, 13 Jan 2011 17:30:49 +0100

On 13/01/11 15:39, Eric Dumazet wrote:
> Le jeudi 13 janvier 2011 à 15:02 +0100, Jan Engelhardt a écrit :
>> On Thursday 2011-01-13 14:38, Eric Dumazet wrote:
>>
>>> Le jeudi 13 janvier 2011 à 12:54 +0100, Pablo Neira Ayuso a écrit :
>>>
>>>> But printing this does not provide any useful information. The first
>>>> packet that does not belong to the cluster node that has received the
>>>> packet, or the first invalid packet, will trigger this.
>>>>
>>>> Moreover, this confuses users since they can do nothing if they receive
>>>> this message.
>>>>
>>>> Moreover, this target should be supersedes by the cluster match, which
>>>> has been there for quite some time (it's also more flexible).
>>>
>>> Now you mentioned it, cluster match is not as flexible right now,
>>> its hashing is on source_ip only.
>>
>> I think in that case, xt_cluster should be improved rather
>> than an old module.
> 
> Amen
> 
> We should not improve IPv4 support then, I see.
> 
> My customers use this old module, and upgrading to xt_cluster is not an
> option.
> 
> Should we discuss this forever or fix it ?

hey hey, I'm fine with fixing things. Patch v4 is OK.

Acked-by: Pablo Neira Ayuso <[email-masked]>

> In the end, people are forced to add useless iptables rule to DROP
> INVALID packets before entering ipt_CLUSTERIP, after googling or
> eventually asking to experts.
> 
> Last time this was discussed, this went nowhere :
> 
> http://www.spinics.net/lists/netfilter/msg48676.html
> 
> Come on guys, we can do it, dont be afraid.
> 
> A non rate limited printk() in kernel is forbidden, especially in
> network stack.
> 
> Then, cluster match can be improved, I am sure you already have a patch
> for it.

what scenario could benefit from the destination-based hashing?
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to [email-masked]
More majordomo info at  http://vger.kernel.org/majordomo-info.html