B.A.T.M.A.N June 2015

b.a.t.m.a.n@lists.open-mesh.org

16 participants
69 discussions

[B.A.T.M.A.N.] [PATCHv2 maint] batman-adv: protect tt_local_entry from concurrent delete events
by Marek Lindner 17 Jun '15

17 Jun '15

The tt_local_entry deletion performed in batadv_tt_local_remove() was neither protecting against simultaneous deletes nor checking whether the element was still part of the list before calling hlist_del_rcu(). Replacing the hlist_del_rcu() call with batadv_hash_remove() provides adequate protection via hash spinlocks as well as an is-element-still-in-hash check to avoid 'blind' hash removal. Reported-by: alfonsname(a)web.de Signed-off-by: Marek Lindner <mareklindner(a)neomailbox.ch> --- translation-table.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/translation-table.c b/translation-table.c index e95a424..fa90a6a 100644 --- a/translation-table.c +++ b/translation-table.c @@ -1015,6 +1015,7 @@ uint16_t batadv_tt_local_remove(struct batadv_priv *bat_priv, struct batadv_tt_local_entry *tt_local_entry; uint16_t flags, curr_flags = BATADV_NO_FLAGS; struct batadv_softif_vlan *vlan; + void *tt_entry_exists; tt_local_entry = batadv_tt_local_hash_find(bat_priv, addr, vid); if (!tt_local_entry) @@ -1042,7 +1043,15 @@ uint16_t batadv_tt_local_remove(struct batadv_priv *bat_priv, * immediately purge it */ batadv_tt_local_event(bat_priv, tt_local_entry, BATADV_TT_CLIENT_DEL); - hlist_del_rcu(&tt_local_entry->common.hash_entry); + + tt_entry_exists = batadv_hash_remove(bat_priv->tt.local_hash, + batadv_compare_tt, + batadv_choose_tt, + &tt_local_entry->common); + if (!tt_entry_exists) + goto out; + + /* extra call to free the local tt entry */ batadv_tt_local_entry_free_ref(tt_local_entry); /* decrease the reference held for this vlan */ -- 2.1.4

2 1

[B.A.T.M.A.N.] [PATCH] batman-adv: fix kernel crash due to missing NULL checks
by Marek Lindner 17 Jun '15

17 Jun '15

batadv_softif_vlan_get() may return NULL which has to be verified by the caller. Reported-by: Ryan Thompson <ryan(a)eero.com> Signed-off-by: Marek Lindner <mareklindner(a)neomailbox.ch> --- soft-interface.c | 3 +++ translation-table.c | 17 +++++++++++++---- 2 files changed, 16 insertions(+), 4 deletions(-) diff --git a/soft-interface.c b/soft-interface.c index da89336..7841a4b 100644 --- a/soft-interface.c +++ b/soft-interface.c @@ -455,6 +455,9 @@ out: */ void batadv_softif_vlan_free_ref(struct batadv_softif_vlan *vlan) { + if (!vlan) + return; + if (atomic_dec_and_test(&vlan->refcount)) { spin_lock_bh(&vlan->bat_priv->softif_vlan_list_lock); hlist_del_rcu(&vlan->list); diff --git a/translation-table.c b/translation-table.c index e95a424..efbcb59 100644 --- a/translation-table.c +++ b/translation-table.c @@ -575,6 +575,8 @@ bool batadv_tt_local_add(struct net_device *soft_iface, const uint8_t *addr, /* increase the refcounter of the related vlan */ vlan = batadv_softif_vlan_get(bat_priv, vid); + if (!vlan) + goto out; batadv_dbg(BATADV_DBG_TT, bat_priv, "Creating new local tt entry: %pM (vid: %d, ttvn: %d)\n", @@ -1047,6 +1049,9 @@ uint16_t batadv_tt_local_remove(struct batadv_priv *bat_priv, /* decrease the reference held for this vlan */ vlan = batadv_softif_vlan_get(bat_priv, vid); + if (!vlan) + goto out; + batadv_softif_vlan_free_ref(vlan); batadv_softif_vlan_free_ref(vlan); @@ -1147,8 +1152,10 @@ static void batadv_tt_local_table_free(struct batadv_priv *bat_priv) /* decrease the reference held for this vlan */ vlan = batadv_softif_vlan_get(bat_priv, tt_common_entry->vid); - batadv_softif_vlan_free_ref(vlan); - batadv_softif_vlan_free_ref(vlan); + if (vlan) { + batadv_softif_vlan_free_ref(vlan); + batadv_softif_vlan_free_ref(vlan); + } batadv_tt_local_entry_free_ref(tt_local); } @@ -3188,8 +3195,10 @@ static void batadv_tt_local_purge_pending_clients(struct batadv_priv *bat_priv) /* decrease the reference held for this vlan */ vlan = batadv_softif_vlan_get(bat_priv, tt_common->vid); - batadv_softif_vlan_free_ref(vlan); - batadv_softif_vlan_free_ref(vlan); + if (vlan) { + batadv_softif_vlan_free_ref(vlan); + batadv_softif_vlan_free_ref(vlan); + } batadv_tt_local_entry_free_ref(tt_local); } -- 2.1.4

2 1

[B.A.T.M.A.N.] [PATCH] batman-adv: protect tt_local_entry from concurrent delete events
by Marek Lindner 17 Jun '15

17 Jun '15

The tt_local_entry deletion performed batadv_tt_local_remove() was neither protecting against simultaneous deletes nor checking whether the element was still part of the list before calling hlist_del_rcu(). Replacing the hlist_del_rcu() with batadv_hash_remove() provides adequate protection via hash spinlocks as well as a is-element-still-in-hash check. Reported-by: alfonsname(a)web.de Signed-off-by: Marek Lindner <mareklindner(a)neomailbox.ch> --- translation-table.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/translation-table.c b/translation-table.c index e95a424..4afeeb5 100644 --- a/translation-table.c +++ b/translation-table.c @@ -1042,7 +1042,8 @@ uint16_t batadv_tt_local_remove(struct batadv_priv *bat_priv, * immediately purge it */ batadv_tt_local_event(bat_priv, tt_local_entry, BATADV_TT_CLIENT_DEL); - hlist_del_rcu(&tt_local_entry->common.hash_entry); + batadv_hash_remove(bat_priv->tt.local_hash, batadv_compare_tt, + batadv_choose_tt, &tt_local_entry->common); batadv_tt_local_entry_free_ref(tt_local_entry); /* decrease the reference held for this vlan */ -- 2.1.4

2 2

[B.A.T.M.A.N.] [PATCHv4 maint 0/5] Fixes for parallel OGM processing
by Linus Lüssing 17 Jun '15

17 Jun '15

Hi, Here are five fixes which address potential problems with parallel OGM processing. For the multicast subsystem the issues can be quite severe as found and pointed out by Sven here [0]. Cheers, Linus [0]: https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2015-June/013193.html ----- Changelog v4: * [PATCHv4 maint 5/5]: * Shortened if...BUG() to BUG_ON() Changelog v3: * [PATCHv3 maint 5/5]: * added kerneldoc for new mcast_handler_lock in types.h Changelog v2: * Split [PATCH maint 1/2] into [PATCHv2 {1,2,3,4}/5] * [PATCHv2 maint 5/5]: * moved mcast_flags initialization outside of spinlock * added spinlock in batadv_mcast_purge_orig() (not strictly necessary bc. if we are here then the orig-node is out-of-scope as it's going to be kfree'd a few instructions later - but added for style reasons / to avoid future errors) * added hlist_unhashed()+BUG() calls (again, shouldn't be necessary as the checks and new spinlock should avoid this case. But since the safety of hlist_del_rcu() isn't directly obvious, better adding these annotations and to avoid future regressions with kernel panics) PS: Thanks to Marek for the suggestions.

2 10

[B.A.T.M.A.N.] [PATCHv3 maint 0/5] Fixes for parallel OGM processing
by Linus Lüssing 16 Jun '15

16 Jun '15

Hi, Here are five fixes which address potential problems with parallel OGM processing. For the multicast subsystem the issues can be quite severe as found and pointed out by Sven here [0]. Cheers, Linus [0]: https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2015-June/013193.html ----- Changelog v3: * [PATCHv3 maint 5/5]: * added kerneldoc for new mcast_handler_lock in types.h Changelog v2: * Split [PATCH maint 1/2] into [PATCHv2 {1,2,3,4}/5] * [PATCHv2 maint 5/5]: * moved mcast_flags initialization outside of spinlock * added spinlock in batadv_mcast_purge_orig() (not strictly necessary bc. if we are here then the orig-node is out-of-scope as it's going to be kfree'd a few instructions later - but added for style reasons / to avoid future errors) * added hlist_unhashed()+BUG() calls (again, shouldn't be necessary as the checks and new spinlock should avoid this case. But since the safety of hlist_del_rcu() isn't directly obvious, better adding these annotations and to avoid future regressions with kernel panics) PS: Thanks to Marek for the suggestions.

2 7

[B.A.T.M.A.N.] [PATCHv2 maint 0/5] Fixes for parallel OGM processing
by Linus Lüssing 16 Jun '15

16 Jun '15

Hi, Here are five fixes which address potential problems with parallel OGM processing. For the multicast subsystem the issues can be quite severe as found and pointed out by Sven here [0]. Cheers, Linus [0]: https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2015-June/013193.html ----- Changelog v2: * Split [PATCH maint 1/2] into [PATCHv2 {1,2,3,4}/5] * [PATCHv2 maint 5/5]: * moved mcast_flags initialization outside of spinlock * added spinlock in batadv_mcast_purge_orig() (not strictly necessary bc. if we are here then the orig-node is out-of-scope as it's going to be kfree'd a few instructions later - but added for style reasons / to avoid future errors) * added hlist_unhashed()+BUG() calls (again, shouldn't be necessary as the checks and new spinlock should avoid this case. But since the safety of hlist_del_rcu() isn't directly obvious, better adding these annotations and to avoid future regressions with kernel panics) PS: Thanks to Marek for the suggestions.

1 5

[B.A.T.M.A.N.] [PATCH maint 0/2] Fixes for parallel OGM processing
by Linus Lüssing 16 Jun '15

16 Jun '15

Hi, Here are two fixes which address potential problems with parallel OGM processing. For the multicast subsystem the issues can be quite severe as found and pointed out by Sven here [0]. Cheers, Linus [0]: https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2015-June/013193.html

2 4

[B.A.T.M.A.N.] batman-adv: Force line topology
by Carlos Meralto 14 Jun '15

14 Jun '15

Hello, I am developing my thesis on mesh networks. And I'm currently doing some tests with batman-adv. So my question is: I need to create a line topology. For example: A-> B-> C-> D Of all the options I tried, I could not find a solution to do this https://lists.open-mesh.org/pipermail/batman/2012-September/008019.html https://lists.open-mesh.org/pipermail/batman/2011-July/005169.html I can not use the ebtables because I am using the wlan0 interface. And when I try to create a bridge on the interface (wlan0) gives me an error. root@OpenWrt:~# batctl if del adhoc0 root@OpenWrt:~# brctl addbr bridgeWlan root@OpenWrt:~# brctl addif bridgeWlan adhoc0 brctl: bridge bridgeWlan: Operation not supported There is already a way to force a topology in batman-adv? I'm blocked with no solution. Thanks in advance.

3 3

Re: [B.A.T.M.A.N.] Mesh hickups with 2014.3
by Linus Lüssing 14 Jun '15

14 Jun '15

On Fri, Jun 12, 2015 at 05:04:48PM +0200, Bjoern Franke wrote: > Hi Linus, > > > There's a hash_max value for the bridge > > (/sys/class/net/<br>/bridge/hash_max). By default it's rather > > small, just 512 entries / multicast listeners, so it's expected that > > with 500 nodes the bridge multicast snooping will shut down. > > Thanks for your reply, I increased the value now to 4096 on the > gateways. > > > Nevertheless, even if the bridge deactivates its multicast > > snooping that shouldn't cause trouble for ICMPv6. > > > > Which firmware are you using, do you see ICMPv6 packets entering > > bat0 on the gateway and leaving bat0 on the router? > > We are running gluon 2014.4 on the routers. Okay. In Gluon both the batman-adv multicast optimizations and bridge multicast snooping are deactivated by default. So I think it's probably an issue with the bridge on your gateway. Does deactivating the batman-adv and bridge multicast stuff make a difference? Which kernel version and Linux distribution are you using on the gateway? > > I see solicitations and advertisements on the gateway: > 16:59:54.567582 IP6 fd74:fdaa:9dc4:0:fa1a:67ff:feeb:c77e > > ff02::1:ff40:1: ICMP6, neighbor solicitation, who has > fd74:fdaa:9dc4::40:1, length 32 > 16:59:54.567661 IP6 fd74:fdaa:9dc4::40:1 > > fd74:fdaa:9dc4:0:fa1a:67ff:feeb:c77e: ICMP6, neighbor advertisement, > tgt is fd74:fdaa:9dc4::40:1, length 32 Measured on bat0 or on the bridge on top? > > Unfortunately it's not possible to access the router at the moment to > have look what's leaving on bat0 there. > > Regards > Björn Cheers, Linus PS: Please keep the mailinglists.

2 1

Re: [B.A.T.M.A.N.] batman-adv: Force line topology
by Sven Eckelmann 13 Jun '15

13 Jun '15

On Saturday 13 June 2015 19:17:57 Carlos Meralto wrote: > Thanks for the answer Sven. > > > You can patch the driver to allow this (it is just a simple check which > > disallows it in most drivers... or actually in wireless core [1]). But you > > should make sure that you still use the same mac addresses for vif + > > bridge > > and don't end up with 4 address packets. > > Can you explain how I can apply this "patch”? I saw the file attached but i > don't know what parameters must change. You have to modify this file or similar ones yourself to avoid that it sets IFF_DONT_BRIDGE. And then you have to recompile your kernel with your patch and run it - but you should be aware that this is only a hack. It was already discussed on this mailing list how the wifi stack avoids that the bridge accepts specific types of interfaces [1]. You should also find in this thread a patch [2] which shows how some ebtables functionality could in theory also be added to something like batman-adv. You should be aware that this is not in the upstream version because it is considered not acceptable by the Linux networking subsystem maintainer. You should also be aware that it is problematic to test to different protocols by using two different, protocol/implementation specific ways to force them to a specific topologies. Kind regards, Sven [1] https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2010-May/002718.html [2] https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2010-May/002731.html

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

B.A.T.M.A.N June 2015