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 <pablo@xxxxxxxxxxxxx> > 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
