[B.A.T.M.A.N.] [PATCH] 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(-)
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);
/* don't accept stp packets. STP does not help in meshes. * better use the bridge loop avoidance ...
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
b.a.t.m.a.n@lists.open-mesh.org
-
"Linus Lüssing" -
Antonio Quartulli -
Linus Lüssing
-
Marek Lindner