[B.A.T.M.A.N.] [PATCH] batman-adv: Do not add multicast MAC addresses to translation table
17 Oct
2012
17 Oct
'12
1:07 p.m.
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);
/* don't accept stp packets. STP does not help in meshes.
* better use the bridge loop avoidance ...
--
1.7.10.4
17 Oct
17 Oct
1:36 p.m.
New subject: [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..
Cheers,
--
Antonio Quartulli
..each of us alone is worth nothing..
Ernesto "Che" Guevara
6:43 p.m.
New subject: [B.A.T.M.A.N.] [PATCH] batman-adv: Do not add multicast MAC addresses to translation table
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"
<b.a.t.m.a.n(a)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:
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
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..
Cheers,
--
Antonio Quartulli
..each of us alone is worth nothing..
Ernesto "Che" Guevara
6:48 p.m.
New subject: [B.A.T.M.A.N.] [PATCH] batman-adv: Do not add multicast MAC addresses to translation table
On Wed, Oct 17, 2012 at 08:43:05PM +0200, "Linus Lüssing" wrote:
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(a)autistici.org>
Thanks a lot Linüs.
Cheers,
--
Antonio Quartulli
..each of us alone is worth nothing..
Ernesto "Che" Guevara
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"
<b.a.t.m.a.n(a)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:
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? 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.. 
13 Nov
13 Nov
10:04 a.m.
On Thursday, October 18, 2012 02:48:39 Antonio Quartulli wrote:
Applied in revision 9868989.
Thanks,
Marek
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(a)autistici.org>
3851
days inactive
3878
days old
b.a.t.m.a.n@lists.open-mesh.org
4 comments
4 participants
participants (4)
-
"Linus Lüssing" -
Antonio Quartulli -
Linus Lüssing
-
Marek Lindner