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

[Pablo Neira Ayuso <pablo@netfilter.org>]

Patrick McHardy wrote:
> 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.

Hm, I forgot another point that is the fact that the PKTTYPE target is
not always required. Actually, if the switch can flood the same packets
to a set of nodes that are part of the cluster via "port mirroring" or
if the switch interprets the VRRP reserved MAC address range correctly
(I did not find any yet), the nodes in the cluster would not need to use
with a multicast MAC address, in that case, the PKTTYPE target would not
be required.

Well, I'll do the hackish solution if that relieves the possible extra
bloat of one target that indeed only has this purpose ;). I'll send you
a new version of the patch asap.

-- 
"Los honestos son inadaptados sociales" -- Les Luthiers