batman-adv: Do not add multicast MAC addresses to translation table

  The current translation table mechanism is not suitable for multicast
addresses and we are currently flooding such frames anyway.

Therefore this patch prevents multicast MAC addresses being added to the
translation table.

Signed-off-by: Linus Lüssing <linus.luessing@web.de>
---
 soft-interface.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
  

On Wed, Oct 17, 2012 at 03:07:35PM +0200, Linus Lüssing wrote:
> The current translation table mechanism is not suitable for multicast
> addresses and we are currently flooding such frames anyway.
> 
> Therefore this patch prevents multicast MAC addresses being added to the
> translation table.
> 
> Signed-off-by: Linus Lüssing <linus.luessing@web.de>
> ---
>  soft-interface.c |    3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/soft-interface.c b/soft-interface.c
> index 2d1f895..9955319 100644
> --- a/soft-interface.c
> +++ b/soft-interface.c
> @@ -180,7 +180,8 @@ static int batadv_interface_tx(struct sk_buff *skb,
>  		goto dropped;
>  
>  	/* Register the client MAC in the transtable */
> -	batadv_tt_local_add(soft_iface, ethhdr->h_source, skb->skb_iif);
> +	if (!is_multicast_ether_addr(ethhdr->h_source))
> +		batadv_tt_local_add(soft_iface, ethhdr->h_source, skb->skb_iif);

How can the source address be multicast? Usually multicast addresses are found
in the destination field...

Is there any scenario where this is possible? I am wondering whether we should
directly drop packet having mcast address as source..

Cheers,
  

> Gesendet: Mittwoch, 17. Oktober 2012 um 15:36 Uhr
> Von: "Antonio Quartulli" <ordex@autistici.org>
> An: "The list for a Better Approach To Mobile Ad-hoc Networking" <b.a.t.m.a.n@lists.open-mesh.org>
> Betreff: Re: [B.A.T.M.A.N.] [PATCH] batman-adv: Do not add multicast MAC addresses to translation table
>
> On Wed, Oct 17, 2012 at 03:07:35PM +0200, Linus Lüssing wrote:
> > The current translation table mechanism is not suitable for multicast
> > addresses and we are currently flooding such frames anyway.
> > 
> > Therefore this patch prevents multicast MAC addresses being added to the
> > translation table.
> > 
> > Signed-off-by: Linus Lüssing <linus.luessing@web.de>
> > ---
> >  soft-interface.c |    3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/soft-interface.c b/soft-interface.c
> > index 2d1f895..9955319 100644
> > --- a/soft-interface.c
> > +++ b/soft-interface.c
> > @@ -180,7 +180,8 @@ static int batadv_interface_tx(struct sk_buff *skb,
> >  		goto dropped;
> >  
> >  	/* Register the client MAC in the transtable */
> > -	batadv_tt_local_add(soft_iface, ethhdr->h_source, skb->skb_iif);
> > +	if (!is_multicast_ether_addr(ethhdr->h_source))
> > +		batadv_tt_local_add(soft_iface, ethhdr->h_source, skb->skb_iif);
> 
> How can the source address be multicast? Usually multicast addresses are found
> in the destination field...
> 
> Is there any scenario where this is possible? I am wondering whether we should
> directly drop packet having mcast address as source..

Hm, no, I do not have a specific scenario in mind. I only accidentally noticed such an FF:FF:FF:FF:FF:FF mac address in our vis graph here when I made a typo with the tool 'mausezahn'.

I don't know of any RFC or so which would generally forbid using a multicast source MAC for every ether type (although for sane IPv4/v6 stacks I haven't seen something like this before either and yes, I bet it's not allowed there).

The Linux bridge I had on top of bat0 was happily forwarding such frames into batman-adv. So I thought doing it like the bridge code - forwarding but with no learning - might be the right way?

Cheers

> 
> Cheers,
> 
> 
> -- 
> Antonio Quartulli
> 
> ..each of us alone is worth nothing..
> Ernesto "Che" Guevara
>
  

On Wed, Oct 17, 2012 at 08:43:05PM +0200, "Linus Lüssing" wrote:
> 
> 
> > Gesendet: Mittwoch, 17. Oktober 2012 um 15:36 Uhr
> > Von: "Antonio Quartulli" <ordex@autistici.org>
> > An: "The list for a Better Approach To Mobile Ad-hoc Networking" <b.a.t.m.a.n@lists.open-mesh.org>
> > Betreff: Re: [B.A.T.M.A.N.] [PATCH] batman-adv: Do not add multicast MAC addresses to translation table
> >
> > On Wed, Oct 17, 2012 at 03:07:35PM +0200, Linus Lüssing wrote:
> > > The current translation table mechanism is not suitable for multicast
> > > addresses and we are currently flooding such frames anyway.
> > > 
> > > Therefore this patch prevents multicast MAC addresses being added to the
> > > translation table.
> > > 
> > > Signed-off-by: Linus Lüssing <linus.luessing@web.de>
> > > ---
> > >  soft-interface.c |    3 ++-
> > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/soft-interface.c b/soft-interface.c
> > > index 2d1f895..9955319 100644
> > > --- a/soft-interface.c
> > > +++ b/soft-interface.c
> > > @@ -180,7 +180,8 @@ static int batadv_interface_tx(struct sk_buff *skb,
> > >  		goto dropped;
> > >  
> > >  	/* Register the client MAC in the transtable */
> > > -	batadv_tt_local_add(soft_iface, ethhdr->h_source, skb->skb_iif);
> > > +	if (!is_multicast_ether_addr(ethhdr->h_source))
> > > +		batadv_tt_local_add(soft_iface, ethhdr->h_source, skb->skb_iif);
> > 
> > How can the source address be multicast? Usually multicast addresses are found
> > in the destination field...
> > 
> > Is there any scenario where this is possible? I am wondering whether we should
> > directly drop packet having mcast address as source..
> 
> Hm, no, I do not have a specific scenario in mind. I only accidentally noticed such an FF:FF:FF:FF:FF:FF mac address in our vis graph here when I made a typo with the tool 'mausezahn'.
> 
> I don't know of any RFC or so which would generally forbid using a multicast source MAC for every ether type (although for sane IPv4/v6 stacks I haven't seen something like this before either and yes, I bet it's not allowed there).
> 
> The Linux bridge I had on top of bat0 was happily forwarding such frames into batman-adv. So I thought doing it like the bridge code - forwarding but with no learning - might be the right way?

I think you are right. We should not care about the payload logic. If that is
not allowed for the upper layer, then that layer will drop the packet once
received.


So we should keep forwarding such packets and yes, we should prevent learning
from them. Therefore:

Acked-by: Antonio Quartulli <ordex@autistici.org>

Thanks a lot Linüs.
Cheers,
  

On Thursday, October 18, 2012 02:48:39 Antonio Quartulli wrote:
> > Hm, no, I do not have a specific scenario in mind. I only accidentally
> > noticed such an FF:FF:FF:FF:FF:FF mac address in our vis graph here when
> > I made a typo with the tool 'mausezahn'.
> >
> > 
> >
> > I don't know of any RFC or so which would generally forbid using a
> > multicast source MAC for every ether type (although for sane IPv4/v6
> > stacks I haven't seen something like this before either and yes, I bet
> > it's not allowed there).
> >
> > 
> >
> > The Linux bridge I had on top of bat0 was happily forwarding such frames
> > into batman-adv. So I thought doing it like the bridge code - forwarding
> > but with no learning - might be the right way?
> 
> I think you are right. We should not care about the payload logic. If that
> is not allowed for the upper layer, then that layer will drop the packet
> once received.
> 
> 
> So we should keep forwarding such packets and yes, we should prevent
> learning from them. Therefore:
> 
> Acked-by: Antonio Quartulli <ordex@autistici.org>

Applied in revision 9868989.

Thanks,
Marek