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(a)autistici.org>
> An: "The list for a Better Approach To Mobile Ad-hoc Networking"
> 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(a)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
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
So we should keep forwarding such packets and yes, we should prevent learning
from them. Therefore:
Acked-by: Antonio Quartulli <ordex(a)autistici.org>
Thanks a lot Linüs.
..each of us alone is worth nothing..
Ernesto "Che" Guevara