Message ID | 20170601085804.4756-1-apape@phoenixcontact.com |
---|---|
State | Superseded, archived |
Delegated to: | Simon Wunderlich |
Headers | show |
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
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);
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