Jan Engelhardt <ej@xxxxxxx> wrote:
> >Module registers to NFPROTO_UNSPEC, but it assumes ipv4/ipv6 packet
> >processing. As this is only useful to restrict locally terminating
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >TCP/UDP traffic, reject non-ip families at rule load time.
> >@@ -124,6 +124,14 @@ static int xt_cluster_mt_checkentry(const struct xt_mtchk_param *par)
> > struct xt_cluster_match_info *info = par->matchinfo;
> > int ret;
> >
> >+ switch (par->family) {
> >+ case NFPROTO_IPV4:
> >+ case NFPROTO_IPV6:
> >+ break;
> >+ default:
> >+ return -EAFNOSUPPORT;
> >+ }
>
> I wonder if we could just implement the logic for it.
Whats the use case?
> Like this patch [untested!]:
>
> From d534984879b9b3c4b8cf536cad1044c29b843a2d Mon Sep 17 00:00:00 2001
> From: Jan Engelhardt <jengelh@xxxxxxx>
> Date: Thu, 3 Oct 2024 20:49:02 +0200
> Subject: [PATCH] xt_cluster: add logic for use from NFPROTO_BRIDGE
>
> Signed-off-by: Jan Engelhardt <jengelh@xxxxxxx>
> ---
> net/netfilter/xt_cluster.c | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/net/netfilter/xt_cluster.c b/net/netfilter/xt_cluster.c
> index a047a545371e..cf4a74d68577 100644
> --- a/net/netfilter/xt_cluster.c
> +++ b/net/netfilter/xt_cluster.c
> @@ -68,6 +68,9 @@ xt_cluster_is_multicast_addr(const struct sk_buff *skb, u_int8_t family)
> case NFPROTO_IPV6:
> is_multicast = ipv6_addr_is_multicast(&ipv6_hdr(skb)->daddr);
> break;
> + case NFPROTO_BRIDGE:
> + is_multicast = is_multicast_ether_addr(eth_hdr(skb)->h_dest);
> + break;
AFAIU this is always true: l2 address is always a multicast mac in
xt_cluster setups, we would need to peek into the L3 address to see if
its also multicast or if its the expected l3-unicast-in-l2-mcast.
I don't see a use case for supporting this from a bridge, but maybe I
missed something.
