batman-adv: prevent adding of loop detection mac addresses to global tt

This patch prevents that entries in the global translation table are generated
for mac addresses used by loop detection frames.

Signed-off-by: Andreas Pape <apape@phoenixcontact.com>
---
 net/batman-adv/translation-table.c |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)

--
1.7.0.4



..................................................................
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

On Thursday, June 1, 2017 10:58:04 AM CEST Andreas Pape wrote:
> This patch prevents that entries in the global translation table are
> generated for mac addresses used by loop detection frames.
> 
> Signed-off-by: Andreas Pape <apape@phoenixcontact.com>
> ---
>  net/batman-adv/translation-table.c |    6 ++++--
>  1 files changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/net/batman-adv/translation-table.c
> b/net/batman-adv/translation-table.c index e75b493..ca1e0f7 100644
> --- a/net/batman-adv/translation-table.c
> +++ b/net/batman-adv/translation-table.c
> @@ -1618,8 +1618,10 @@ static bool batadv_tt_global_add(struct batadv_priv
> *bat_priv, struct batadv_tt_common_entry *common;
>  	u16 local_flags;
> 
> -	/* ignore global entries from backbone nodes */
> -	if (batadv_bla_is_backbone_gw_orig(bat_priv, orig_node->orig, vid))
> +	/* ignore global entries from backbone nodes or
> +	 * adding of entries related to loop detect frames */
> +	if (batadv_bla_is_backbone_gw_orig(bat_priv, orig_node->orig, vid) ||
> +		batadv_bla_is_loopdetect_mac(tt_addr))
>  		return true;
> 
>  	tt_global_entry = batadv_tt_global_hash_find(bat_priv, tt_addr, vid);

Thank you for your patch.

I was thinking, if we implement it like this we may still have problems if an 
older batman-adv version is adding the ba:be mac addresses locally. This could 
create a problem, because the transmitted tt table is not added completely, 
thus the CRC will not match and will lead to a "TT request/response loop".

What do you think? Maybe we should only add it for the speedy join case, but 
accept it if a node really added these mac addresses locally?

Thanks,
      Simon

Hi Simon,

>
> I was thinking, if we implement it like this we may still have problems
if an
> older batman-adv version is adding the ba:be mac addresses locally.
> This could
> create a problem, because the transmitted tt table is not added
completely,
> thus the CRC will not match and will lead to a "TT request/response
loop".
>
> What do you think? Maybe we should only add it for the speedy join case,
but
> accept it if a node really added these mac addresses locally?

I'm afraid I haven't understood the speedy join mechanism / use case good
enough
to make a good proposal here, but I'm volunteering for testing if someone
else
has a better solution then my rough approach ;-)

Kind 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