Patrick McHardy wrote: > Pablo Neira Ayuso wrote: >> Patrick McHardy wrote: >>> Jozsef Kadlecsik wrote: >>>> On Tue, 10 Feb 2009, Patrick McHardy wrote: >>>> >>>>> Yes, I know, I'm just wondering why you're using TCP at all for >>>>> synchronizing. Its not for traffic from the Internet I assume >>>>> since the node it ends up on is unknown to the outside anyways. >>>> No, that's not the syncronizing traffic, but the "normal" TCP traffic >>>> to be filtered by the firewalls, which have got multicast MAC >>>> addresses on their interfaces. >>> Multicast traffic is accepted for forwarding just fine, its just >>> local TCP delivery thats refusing it. So it can't be forwarded >>> traffic. >> >> You usually have some administration facility (like ssh) that would >> break. Please, think that this can be also used to replace CLUSTERIP (to >> be used in back-end servers, not only stateful firewalls). > > I see. Still, this module has only one purpose, which is to circumvent > valid checks to make a different hack (although a nicer one) work. > Perhaps simply move it into the cluster match (yes yes, I know). That > way we can also avoid a bit of the new-module overhead. Then, the cluster match would become the target match, since skbuff cannot be modified from matches (they are passed as const). Becoming a target means less flexibility :( -- "Los honestos son inadaptados sociales" -- Les Luthiers -- 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
