Re: [PATCH 1/3] netfilter: arptables: add mcmangle target

[Patrick McHardy <kaber@trash.net>]

Pablo Neira Ayuso wrote:
> This patch adds the mcmangle target for arptables which allows
> altering the source hardware address in ARP with a multicast
> hardware address. This target can be used to make a switch flood
> packets to the ports that use the same MAC multicast address. This
> is useful to deploy load-sharing clusters in environments in which
> the switch does not provide a way to flood packets to several
> ports.

Great name. Took me a bit to realize the connection to "multicast" :)

> Since all the nodes receives the same packets, each decides if
> it handles the packet based on hashing approach (See the `cluster'
> iptables match that comes with this patchset).
> 
> Theoretically, the use of the reserved VRRP hardware address should
> be fine for this, however, switches generally treat this hardware
> address space as normal unicast hardware address. Thus, in practise,
> it is not possible to have two nodes with the same VRRP hardware
> address.
> 
> Please, note that this target violates RFC 1812 (section 3.3.2) since
> an ethernet device must not use a multicast link address.
> 
> An example of the use of this target:
> 
> arptables -I OUTPUT -o eth0 -j mcmangle --h-length 6 \
> 	--mc-mangle-mac 01:00:5e:00:01:01 --mc-mangle-dev eth0
> arptables -I INPUT -i eth0 --h-length 6 --destination-mac \
> 	01:00:5e:00:01:01 -j mangle --mangle-mac-d 00:zz:yy:xx:5a:27

Wouldn't it be more generically usable if it was a simple "set
either source or destination mac address to any value" target?
In fact thats what it seems to be (or is there a multicast check?),
so perhaps we should call it S/DNAT for consistency with iptables
and ebtables?

I'm wondering though why the device is needed as a parameter ..
ah I see:

+	if (dev_mc_add(dev, mangle->mc_devaddr, ETH_ALEN, 0) < 0) {
+		printk(KERN_ERR "arpt_mcmangle: cannot set multicast "
+				"address\n");
+		return false;
+	}

Continuing the idea of a generic ARP address mangling target,
this would have to be done in userspace using SIOCADDMULTI.

I would also prefer that approach because the multicast mangling
seems a bit like a hack which only works when the requesting
host accepts a multicast MAC address in the ARP reply.