Hello,
I stumbled across some weired MAC addresses starting with ba:be in the global translation-table when running batman-adv-2017.0.1. I run my setup with bla enabled.
Most of the entries in the global tt of my devices consist of these mac addresses. Looking through the code they come from frames which seem to be used for loop detection. Adding such MAC addresses to the local tt is prevented with the help of the batadv_bla_is_loopdetect_mac function. I wonder why adding these macs to the global tt is not prevented in a simliar way. Would it be possible to add a corresponding check to batadv_tt_global_add to prevent these macs from being added to the global tt? Or is there a specific reason why these mac addresses must occur in the global tt and which I have not understood so far?
Best regards, Andreas
.................................................................. PHOENIX CONTACT ELECTRONICS GmbH
Sitz der Gesellschaft / registered office of the company: 31812 Bad Pyrmont USt-Id-Nr.: DE811742156 Amtsgericht Hannover HRB 100528 / district court Hannover HRB 100528 Geschäftsführer / Executive Board: Ulrich Leidecker, Christoph Leifer __________________________________________________________________ Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren, jegliche anderweitige Verwendung sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. ---------------------------------------------------------------------------------------------------- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure, distribution or other use of the material or parts thereof is strictly forbidden. ___________________________________________________________________
Hi Andreas,
yes, those are loop detection packets. Preventing these entries from the local translation table has been implemented only recently. We can potentially do the same for global addresses as well, it just hasn't been done so far ... at least I don't see a reason prevening us from that. It is probably added by "speedy join" in the first place.
Thanks, Simon
On Wednesday, May 31, 2017 3:18:39 PM CEST Andreas Pape wrote:
Hello,
I stumbled across some weired MAC addresses starting with ba:be in the global translation-table when running batman-adv-2017.0.1. I run my setup with bla enabled.
Most of the entries in the global tt of my devices consist of these mac addresses. Looking through the code they come from frames which seem to be used for loop detection. Adding such MAC addresses to the local tt is prevented with the help of the batadv_bla_is_loopdetect_mac function. I wonder why adding these macs to the global tt is not prevented in a simliar way. Would it be possible to add a corresponding check to batadv_tt_global_add to prevent these macs from being added to the global tt? Or is there a specific reason why these mac addresses must occur in the global tt and which I have not understood so far?
Best regards, Andreas
.................................................................. PHOENIX CONTACT ELECTRONICS GmbH
Sitz der Gesellschaft / registered office of the company: 31812 Bad Pyrmont USt-Id-Nr.: DE811742156 Amtsgericht Hannover HRB 100528 / district court Hannover HRB 100528 Geschäftsführer / Executive Board: Ulrich Leidecker, Christoph Leifer __________________________________________________________________ Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren, jegliche anderweitige Verwendung sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet.
------------------------- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure, distribution or other use of the material or parts thereof is strictly forbidden. ___________________________________________________________________
On Wed, May 31, 2017 at 03:39:23PM +0200, Simon Wunderlich wrote:
Hi Andreas,
yes, those are loop detection packets. Preventing these entries from the local translation table has been implemented only recently. We can potentially do the same for global addresses as well, it just hasn't been done so far ... at least I don't see a reason prevening us from that. It is probably added by "speedy join" in the first place.
This was the case at least for me. Andreas, do yours have the temporary flag set, too?
I'm wondering why these packets end up in the mesh in the first place. (Preventing things as late as in tt_gobal_add() / on mesh receiving nodes seems like a workaround?)
Regards, Linus
On Wednesday, May 31, 2017 4:20:13 PM CEST Linus Lüssing wrote:
On Wed, May 31, 2017 at 03:39:23PM +0200, Simon Wunderlich wrote:
Hi Andreas,
yes, those are loop detection packets. Preventing these entries from the local translation table has been implemented only recently. We can potentially do the same for global addresses as well, it just hasn't been done so far ... at least I don't see a reason prevening us from that. It is probably added by "speedy join" in the first place.
This was the case at least for me. Andreas, do yours have the temporary flag set, too?
I'm wondering why these packets end up in the mesh in the first place. (Preventing things as late as in tt_gobal_add() / on mesh receiving nodes seems like a workaround?)
Hey Linus,
we actually want those frames to pass through the mesh - otherwise we can't find out if "regular" packets would loop through the mesh, so we have handle those special packets like regular ones.
If we don't want to see them, we have to hide them, but we can't remove the packet without hurting the functionality. :)
Cheers, Simon
On Wed, May 31, 2017 at 04:40:56PM +0200, Simon Wunderlich wrote:
we actually want those frames to pass through the mesh - otherwise we can't find out if "regular" packets would loop through the mesh, so we have handle those special packets like regular ones.
Ah, okay, thanks for the clarification! :)
If we don't want to see them, we have to hide them, but we can't remove the packet without hurting the functionality. :)
Yes, then filtering in batadv_tt_global_add() makes sense.
Although, sending these mesh wide sounds like it could create quite some overhead? Is this new to BLA2?
Regards, Linus
On Wednesday, May 31, 2017 5:56:31 PM CEST Linus Lüssing wrote:
On Wed, May 31, 2017 at 04:40:56PM +0200, Simon Wunderlich wrote: Although, sending these mesh wide sounds like it could create quite some overhead? Is this new to BLA2?
Yes, it's new in BLA2. Actually it wasn't in the first BLA2 as well, we merged the patch not so long ago.
The loop detection packet is sent every 60 seconds as a broadcast to the LAN. It will therefore only end up in the mesh if there are other mesh nodes on the same backbone LAN to forward it. Therefore, I think the overhead for community networks at least should be minimal.
Cheers, Simon
Von: Linus Lüssing linus.luessing@c0d3.blue An: The list for a Better Approach To Mobile Ad-hoc Networking b.a.t.m.a.n@lists.open-mesh.org Datum: 31.05.2017 16:20 Betreff: Re: [B.A.T.M.A.N.] MAC addresses of loop detect frames in global translation-table Gesendet von: "B.A.T.M.A.N" b.a.t.m.a.n-bounces@lists.open-mesh.org
On Wed, May 31, 2017 at 03:39:23PM +0200, Simon Wunderlich wrote:
Hi Andreas,
yes, those are loop detection packets. Preventing these entries
from the local
translation table has been implemented only recently. We can
potentially do
the same for global addresses as well, it just hasn't been done so
far ... at
least I don't see a reason prevening us from that. It is probably
added by
"speedy join" in the first place.
This was the case at least for me. Andreas, do yours have the temporary flag set, too?
If I remember it correctly they are shown as "regular" MAC addresses without any special flags set (like any real mac address of existing devices). In the meantime I kick these entries in batadv_tt_global_add. But if you are interested I could revert my firmware and give a more precise answer.
I'm wondering why these packets end up in the mesh in the first place. (Preventing things as late as in tt_gobal_add() / on mesh receiving nodes seems like a workaround?)
Regards, Linus
Best regards, Andreas
.................................................................. PHOENIX CONTACT ELECTRONICS GmbH
Sitz der Gesellschaft / registered office of the company: 31812 Bad Pyrmont USt-Id-Nr.: DE811742156 Amtsgericht Hannover HRB 100528 / district court Hannover HRB 100528 Geschäftsführer / Executive Board: Ulrich Leidecker, Christoph Leifer __________________________________________________________________ Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren, jegliche anderweitige Verwendung sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. ---------------------------------------------------------------------------------------------------- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure, distribution or other use of the material or parts thereof is strictly forbidden. ___________________________________________________________________
On Thursday, June 1, 2017 8:12:51 AM CEST Andreas Pape wrote:
Von: Linus Lüssing linus.luessing@c0d3.blue An: The list for a Better Approach To Mobile Ad-hoc Networking b.a.t.m.a.n@lists.open-mesh.org Datum: 31.05.2017 16:20 Betreff: Re: [B.A.T.M.A.N.] MAC addresses of loop detect frames in global translation-table Gesendet von: "B.A.T.M.A.N" b.a.t.m.a.n-bounces@lists.open-mesh.org
On Wed, May 31, 2017 at 03:39:23PM +0200, Simon Wunderlich wrote:
Hi Andreas,
yes, those are loop detection packets. Preventing these entries
from the local
translation table has been implemented only recently. We can
potentially do
the same for global addresses as well, it just hasn't been done so
far ... at
least I don't see a reason prevening us from that. It is probably
added by
"speedy join" in the first place.
This was the case at least for me. Andreas, do yours have the temporary flag set, too?
If I remember it correctly they are shown as "regular" MAC addresses without any special flags set (like any real mac address of existing devices). In the meantime I kick these entries in batadv_tt_global_add. But if you are interested I could revert my firmware and give a more precise answer.
To me, it would be sufficient to get a patch from your or Linus or anyone else to fix this. :)
Thanks! Simon
b.a.t.m.a.n@lists.open-mesh.org
-
Andreas Pape -
Linus Lüssing -
Simon Wunderlich