B.A.T.M.A.N

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

15 participants
4308 discussions

[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

[B.A.T.M.A.N.] openwrt config changes when upgrading from 2014-4 to 2015-0 ?
by Ufo 13 Jun '15

13 Jun '15

thank you for upgrading batman-adv inside openwrt trunk to 2015-0 im testing new version (yesterdays openwrt trunk) but have problems: the bridge (br-mesh12) with bat-interface and wifi-vAP isnt complete, the bat-interface is missing :-( the "wifi" command also doesnt repair that :-( but, when i delete vlan-setting (for interface, where batman-adv is running on) problems are gone. maybe config for openwrt/batman-adv has changed, or some of our settings are outdated and now obsolete? ufo p.s. with 10 days old openwrt trunk (and batman-adv 2014-4) the problem doesnt appear p.p.s. maybe my former firmware problems are related to that? some of them are gone when we only use one batman-adv on each node instead of two https://github.com/freifunk/meshkit-firmware/issues/23 https://github.com/freifunk/meshkit-firmware/issues/12 ---- tested with minimalized setup it looks like this: some config-files... config interface 'wireless0' option dns '8.8.8.8 212.204.49.83 141.1.1.1' option netmask '255.255.255.255' option proto 'static' option ipaddr '10.61.234.70' option mtu '1536' config interface 'mesh12' option type 'bridge' option ifname 'bat12' option proto 'none' config interface 'meshbat12' option ifname '@wireless0.12' option proto 'batadv' option mesh 'bat12' option mtu '1532' ------ config wifi-device 'radio0' option type 'mac80211' option path 'platform/ar934x_wmac' option htmode 'HT20' option diversity '1' option distance '1000' option disabled '0' option country 'DE' option channel '44' option hwmode '11na' config wifi-iface 'radio0_iface' option device 'radio0' option encryption 'none' option mode 'adhoc' option mcast_rate '6000' option network 'wireless0' option ssid 'leipzig.freifunk.net' option bssid '02:44:CA:FF:EE:EE' config wifi-iface 'radio0_meshap12' option network 'mesh12' option mode 'ap' option device 'radio0' option encryption 'none' option ssid '012Freifunk-Test' root@234-70:~# cat /etc/config/batman-adv config mesh 'bat12' option gw_mode 'client' option multicast_mode '0' option bridge_loop_avoidance '1' ---- root@234-70:~# brctl show bridge name bridge id STP enabled interfaces br-mesh12 7fff.16cc204886e0 no wlan0-1 ----------------------------- ############################# changing to test setting, its working in a proper way: config interface 'meshbat12' option ifname '@wireless0' option proto 'batadv' option mesh 'bat12' option mtu '1532' --- root@234-70:~# brctl show bridge name bridge id STP enabled interfaces br-mesh12 7fff.16cc204886e0 no wlan0-1 bat12 -- --- Freifunk Leipzig http://leipzig.freifunk.net

2 2

[B.A.T.M.A.N.] [PATCH] batman-adv:Make the function batadv_softif_is_valid bool
by Nicholas Krause 13 Jun '15

13 Jun '15

This makes the function batadv_softif_is_valid bool due to this particular function only returning either one or zero aas it s return value. Signed-off-by: Nicholas Krause <xerofoify(a)gmail.com> --- net/batman-adv/soft-interface.c | 6 +++--- net/batman-adv/soft-interface.h | 2 +- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/net/batman-adv/soft-interface.c b/net/batman-adv/soft-interface.c index 5ec31d7..dc683c8 100644 --- a/net/batman-adv/soft-interface.c +++ b/net/batman-adv/soft-interface.c @@ -974,12 +974,12 @@ static void batadv_softif_destroy_netlink(struct net_device *soft_iface, unregister_netdevice_queue(soft_iface, head); } -int batadv_softif_is_valid(const struct net_device *net_dev) +bool batadv_softif_is_valid(const struct net_device *net_dev) { if (net_dev->netdev_ops->ndo_start_xmit == batadv_interface_tx) - return 1; + return true; - return 0; + return false; } struct rtnl_link_ops batadv_link_ops __read_mostly = { diff --git a/net/batman-adv/soft-interface.h b/net/batman-adv/soft-interface.h index dbab22f..48a7aa4 100644 --- a/net/batman-adv/soft-interface.h +++ b/net/batman-adv/soft-interface.h @@ -24,7 +24,7 @@ void batadv_interface_rx(struct net_device *soft_iface, int hdr_size, struct batadv_orig_node *orig_node); struct net_device *batadv_softif_create(const char *name); void batadv_softif_destroy_sysfs(struct net_device *soft_iface); -int batadv_softif_is_valid(const struct net_device *net_dev); +bool batadv_softif_is_valid(const struct net_device *net_dev); extern struct rtnl_link_ops batadv_link_ops; int batadv_softif_create_vlan(struct batadv_priv *bat_priv, unsigned short vid); void batadv_softif_vlan_free_ref(struct batadv_softif_vlan *softif_vlan); -- 2.1.4

1 0

[B.A.T.M.A.N.] Mesh hickups with 2014.3
by Bjoern Franke 12 Jun '15

12 Jun '15

Hi, in the last days we upgraded nearly all (~500) routers of our Freifunk -mesh from 2013.4 to 2014.3. The most things run fine again, but with some routers we have connectivity issues as follows: - gateway gets alfreddata from router - router pingable via batctl - ping via linklocal, ULA and public-IPv6 from gateway to router not possible - other routers in the same mesh can ping it via ULA etc (connected via the same fastd-VPN) Public-IPv6 is announced from a gateway via radvd into the mesh. Unfortunately we are out of ideas where we can search for the reason. Regards bjo -- xmpp bjo(a)schafweide.org

4 7

[B.A.T.M.A.N.] [PATCH] batman-adv:Remove unnessary break statements for switch statement in the function batadv_bla_proccess_claim
by Nicholas Krause 11 Jun '15

11 Jun '15

This removes the unnessary break statements for the switch statement in the function, batadv_blav_procces_claim for checking the structure pointer, bla_dst's variable member, type due to returning directly for the cases in this switch if they evaluate to be equal to the value of the member variable type of the structure pointer, bla_dst and thus no need to avoid fallthrough with break statements in this particular switch statement. Signed-off-by: Nicholas Krause <xerofoify(a)gmail.com> --- net/batman-adv/bridge_loop_avoidance.c | 5 ----- 1 file changed, 5 deletions(-) diff --git a/net/batman-adv/bridge_loop_avoidance.c b/net/batman-adv/bridge_loop_avoidance.c index ac4b96e..c9a548a 100644 --- a/net/batman-adv/bridge_loop_avoidance.c +++ b/net/batman-adv/bridge_loop_avoidance.c @@ -961,23 +961,18 @@ static int batadv_bla_process_claim(struct batadv_priv *bat_priv, if (batadv_handle_claim(bat_priv, primary_if, hw_src, ethhdr->h_source, vid)) return 1; - break; case BATADV_CLAIM_TYPE_UNCLAIM: if (batadv_handle_unclaim(bat_priv, primary_if, ethhdr->h_source, hw_src, vid)) return 1; - break; - case BATADV_CLAIM_TYPE_ANNOUNCE: if (batadv_handle_announce(bat_priv, hw_src, ethhdr->h_source, vid)) return 1; - break; case BATADV_CLAIM_TYPE_REQUEST: if (batadv_handle_request(bat_priv, primary_if, hw_src, ethhdr, vid)) return 1; - break; } batadv_dbg(BATADV_DBG_BLA, bat_priv, -- 2.1.4

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

B.A.T.M.A.N