Re: [PATCH 2/3] netfilter: xtables: add PKTTYPE target

[Patrick McHardy <kaber@trash.net>]

Pablo Neira Ayuso wrote:
> 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 :(

Well, a cast should "fix" that :) But feel free to suggest a
better method that doesn't need to expose this as a standalone
feature.