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.] [PATCH 0/2] pull request for net: batman-adv 2017-03-01
by Simon Wunderlich 02 Mar '17

02 Mar '17

Hi David, here are two bugfixes which we would like to see integrated into net. Please pull or let me know of any problem! Thank you, Simon The following changes since commit 4ea33ef0f9e95b69db9131d7afd98563713e81b0: batman-adv: Decrease hardif refcnt on fragmentation send error (2017-01-04 08:22:04 +0100) are available in the git repository at: git://git.open-mesh.org/linux-merge.git tags/batadv-net-for-davem-20170301 for you to fetch changes up to 51c6b429c0c95e67edd1cb0b548c5cf6a6604763: batman-adv: Fix transmission of final, 16th fragment (2017-02-21 18:33:35 +0100) ---------------------------------------------------------------- Here are two batman-adv bugfixes: - fix a potential double free when fragment merges fail, by Sven Eckelmann - fix failing tranmission of the 16th (last) fragment if that exists, by Linus Lüssing ---------------------------------------------------------------- Linus Lüssing (1): batman-adv: Fix transmission of final, 16th fragment Sven Eckelmann (1): batman-adv: Fix double free during fragment merge error net/batman-adv/fragmentation.c | 20 +++++++++++--------- 1 file changed, 11 insertions(+), 9 deletions(-)

2 3

[B.A.T.M.A.N.] [PATCH] RFC: batman-adv: Increase hashtable size for the global translation table
by Linus Lüssing 02 Mar '17

02 Mar '17

With the addition of multicast optimization features in batman-adv not only unicast but also multicast addresses are now fed into the translatation table. This approximately increases the number of entries by a factor of roughly 2 to 3. Also, the number of client devices in some known, public mesh networks has grown to nearly 4000. Therefore this patch inceases the global translation table size from 1024 to 16384 to reduce load in larger mesh networks. Signed-off-by: Linus Lüssing <linus.luessing(a)c0d3.blue> --- ToDo (maybe): Gather some statistics on how much this might reduce load in some particular networks. This might be a hotfix for some larger Freifunk mesh networks which are experiencing a significantly higher load level since they switched to a recent batman-adv version. Validating whether the hashtable size might be the reason is currently being investigated. On the long run we should switch to the resizable hash table implementation the kernel now provides since not that long ago. --- net/batman-adv/translation-table.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/batman-adv/translation-table.c b/net/batman-adv/translation-table.c index e75b493..e87825c 100644 --- a/net/batman-adv/translation-table.c +++ b/net/batman-adv/translation-table.c @@ -1462,7 +1462,7 @@ static int batadv_tt_global_init(struct batadv_priv *bat_priv) if (bat_priv->tt.global_hash) return 0; - bat_priv->tt.global_hash = batadv_hash_new(1024); + bat_priv->tt.global_hash = batadv_hash_new(16384); if (!bat_priv->tt.global_hash) return -ENOMEM; -- 2.1.4

1 0

[B.A.T.M.A.N.] [PATCH v2 0/4] batman-adv: cleanups patches for Linux 4.12
by Sven Eckelmann 28 Feb '17

28 Feb '17

Hi, here is the second version of cleanup patches. It addresses a couple of new checks from checkpatch.pl: * CHECK: Macro argument reuse '%s' - possible side-effects? * CHECK: Unbalanced braces around else statement The last check currently creates a lot of false positives but a fix for it was already submitted to Andrew Morton (+ accepted). It also contains a patch which converts the preprocessor blocks in multicast.c to simple inline checks. The compiler can directly take care of removing the unused code when some CONFIG_* option disabled. changes in v2: * rebased on top of master * split "Fix possible side-effects in macros" in two patches * converted BATADV_PRINT_VID to an inline function Kind regards, Sven Sven Eckelmann (4): batman-adv: Remove preprocessor checks in multicast.c batman-adv: Fix unbalanced braces around else statement batman-adv: Fix possible side-effects in _batadv_dbg batman-adv: Convert BATADV_PRINT_VID macro to function net/batman-adv/bridge_loop_avoidance.c | 38 +++++++++++++++--------------- net/batman-adv/distributed-arp-table.c | 6 ++--- net/batman-adv/log.h | 5 ++-- net/batman-adv/main.h | 16 +++++++++++-- net/batman-adv/multicast.c | 16 +++++-------- net/batman-adv/translation-table.c | 42 ++++++++++++++++++---------------- 6 files changed, 67 insertions(+), 56 deletions(-)

1 5

[B.A.T.M.A.N.] [PATCH v2 0/2] batman-adv: fragment size adjustments
by Sven Eckelmann 28 Feb '17

28 Feb '17

Hi, here is the second version of both fragment size patches. There is no actual change - just rebased on top of master. I'll recommend the commit message (from Linus!) of the first patch for more details. v2: * rebased on top of master Kind regards, Sven Matthias Schiffer (1): batman-adv: decrease maximum fragment size Sven Eckelmann (1): batman-adv: Keep fragments equally sized net/batman-adv/fragmentation.c | 20 +++++++++++++------- net/batman-adv/main.h | 2 +- 2 files changed, 14 insertions(+), 8 deletions(-)

1 3

Re: [B.A.T.M.A.N.] Node freezes but still alive
by Derick Roman De Leon Leal 25 Feb '17

25 Feb '17

Thanks Linus and Antonio for your replies. I guess is a driver issue, the thing is that I have been using this exact same configuration in other 10 locations without a problem. It sure is strange. I don't know if this helps, but I saw this in the log. Sat Feb 25 17:23:52 2017 kern.info kernel: [21168.652823] batman_adv: bat0: IGMP Querier disappeared - multicast optimizations disabled Sat Feb 25 17:24:02 2017 kern.info kernel: [21178.691583] batman_adv: bat0: IGMP Querier appeared A quick google search showed that this has to do with multicast, which is disabled in my configuration. Should I enable it? Also, I have noticed that the node with the issue is constantly requesting who-has the gateway. I ran this command from the gateway. batctl td -x257 adhoc0 18:23:44.134458 BAT ae:86:74:47:8b:02: BCAST, orig ae:86:74:47:8b:02, seq 1933, ARP, Request who-has 10.10.0.1 tell 10.10.0.142 (ac:86:74:47:8b:00), length 28 18:23:44.145748 BAT ae:86:74:47:8b:02: BCAST, orig ae:86:74:47:8b:02, seq 1933, ARP, Request who-has 10.10.0.1 tell 10.10.0.142 (ac:86:74:47:8b:00), length 28 18:23:45.124692 BAT ae:86:74:47:8b:02: BCAST, orig ae:86:74:47:8b:02, seq 1934, ARP, Request who-has 10.10.0.1 tell 10.10.0.142 (ac:86:74:47:8b:00), length 28 18:23:45.125725 BAT 60:e3:27:f2:71:1c > ae:86:74:47:8b:02: UCAST, ttvn 2, ttl 50, ARP, Reply 10.10.0.1 is-at 6a:64:42:e7:bf:cb, length 28 18:23:45.139625 BAT ae:86:74:47:8b:02: BCAST, orig ae:86:74:47:8b:02, seq 1934, ARP, Request who-has 10.10.0.1 tell 10.10.0.142 (ac:86:74:47:8b:00), length 28 18:23:45.144519 BAT ae:86:74:47:8b:02: BCAST, orig ae:86:74:47:8b:02, seq 1934, ARP, Request who-has 10.10.0.1 tell 10.10.0.142 (ac:86:74:47:8b:00), length 28 Does this means that there is IPv4 transmission? Is there a way to make sure this is a driver problem? In the meanwhile I will try a LEDE and a newer Openwrt. Thanks again for all your help, any comment is welcome. Best Regards, Derick

1 0

Re: [B.A.T.M.A.N.] Node freezes but still alive
by Derick Roman De Leon Leal 25 Feb '17

25 Feb '17

Thanks for the quick reply Linus, No transmission on IPv4, haven't tried on IPv6 but I assume is going to be the same. Someone suggested that I should use a bssid that starts with 02 (eg. 02:12:34:56:78:9A). Is this a requirement for the mesh to work? Should I share a batman-adv log? which packet type should be more useful? Thanks a lot!! Kind Regards, Derick > ---------- Forwarded message ---------- > From: "Linus Lüssing" <linus.luessing(a)c0d3.blue> > To: The list for a Better Approach To Mobile Ad-hoc Networking <b.a.t.m.a.n(a)lists.open-mesh.org> > Cc: > Bcc: > Date: Fri, 24 Feb 2017 09:28:11 +0100 > Subject: Re: [B.A.T.M.A.N.] Node freezes but still alive > Hi Derick, > > On Thu, Feb 23, 2017 at 05:37:55PM -0600, Derick Roman De Leon Leal wrote: > > I have a little setup with two nodes and one gateway, from time to > > time one of the nodes just stops transmitting data. > > Very odd indeed. Can you check whether transmitting IPv4 or > IPv6 packets on adhoc0 directly still works when this happens? > > Cheers, Linus > > > _______________________________________________ > B.A.T.M.A.N mailing list > B.A.T.M.A.N(a)lists.open-mesh.org > https://lists.open-mesh.org/mm/listinfo/b.a.t.m.a.n >

3 2

Re: [B.A.T.M.A.N.] Node freezes but still alive
by Derick Roman De Leon Leal 24 Feb '17

24 Feb '17

Thanks for the quick reply Linus, No transmission on IPv4, haven't tried on IPv6 but I assume is going to be the same. Luan Jinlu suggested that I should use a bssid that starts with 02. Is this a requirement for the mesh to work? Should I share a batman-adv log? which packet type should be more useful? Thanks a lot for your kind help!! Best Regards, Derick > ---------- Forwarded message ---------- > From: "Linus Lüssing" <linus.luessing(a)c0d3.blue> > To: The list for a Better Approach To Mobile Ad-hoc Networking <b.a.t.m.a.n(a)lists.open-mesh.org> > Cc: > Bcc: > Date: Fri, 24 Feb 2017 09:28:11 +0100 > Subject: Re: [B.A.T.M.A.N.] Node freezes but still alive > Hi Derick, > > On Thu, Feb 23, 2017 at 05:37:55PM -0600, Derick Roman De Leon Leal wrote: > > I have a little setup with two nodes and one gateway, from time to > > time one of the nodes just stops transmitting data. > > Very odd indeed. Can you check whether transmitting IPv4 or > IPv6 packets on adhoc0 directly still works when this happens? > > Cheers, Linus > > > _______________________________________________ > B.A.T.M.A.N mailing list > B.A.T.M.A.N(a)lists.open-mesh.org > https://lists.open-mesh.org/mm/listinfo/b.a.t.m.a.n >

1 0

[B.A.T.M.A.N.] Node freezes but still alive
by Derick Roman De Leon Leal 24 Feb '17

24 Feb '17

First of all, thanks in advance for this fantastic mesh protocol. I am kind of new at this so any advice is welcome. I have a little setup with two nodes and one gateway, from time to time one of the nodes just stops transmitting data. I see the node on the originators list but the TQ never changes unlike when its working OK that the TQ changes a bit during the day. The thing is that the node is there, since the last-seen time is updating every few seconds just like when is working normal. I have tried changing my batman configuration with no positive results. Also, I have changed the nodes and this is still happening. This happens and resolves itself in a couple of hours, but it does not happen in other setups I have with more nodes. I tried to search the internet for this issue with zero luck. The three devices are OM2P-HS v3 running Openwrt r49395 with batman-adv 2016.2 using BATMAN IV. Have you guys have encountered this problem before? Is my configuration wrong in any way? Do you have any recommendations for me? Below is the configuration I am using, hope this helps. Please let me know if there is any more information I can make available to you to help me solve this problem. Thanks a lot for taking the time to read all this. I appreciate any comments and feedback you can give. Kind Regards, Derick Nodes Configuration: ----------------------------------------------------- batman-adv +++++++++++++++++++++ config 'mesh' 'bat0' option 'interfaces' 'mesh' option 'aggregated_ogms' option 'ap_isolation' '1' option 'bonding' option 'fragmentation' '1' option 'gw_bandwidth' option 'gw_mode' 'client' option 'gw_sel_class' option 'log_level' option 'orig_interval' option 'vis_mode' option 'bridge_loop_avoidance' '1' option 'distributed_arp_table' option 'multicast_mode' option 'network_coding' option 'hop_penalty' option 'isolation_mark' wireless +++++++++++++++++++++++++++ config wifi-device radio0 option type mac80211 option channel 6 option hwmode 11g option path 'platform/ar934x_wmac' option htmode HT20 option country MX config wifi-iface wlan0 option ifname wlan0 option device radio0 option network lan option mode sta option encryption none option disabled 0 config wifi-iface mesh0 option device radio0 option ifname adhoc0 option network mesh option mode adhoc option ssid MY-SSID111 option bssid CA:FE:CA:FE:CA:FE network +++++++++++++++++++++++++ config interface 'loopback' option ifname 'lo' option proto 'static' option ipaddr '127.0.0.1' option netmask '255.0.0.0' config globals 'globals' option ula_prefix 'fdaa:8902:bcc0::/48' config interface 'lan' option ifname 'eth0 bat0' option force_link '1' option type 'bridge' option proto 'dhcp' list dns 8.8.8.8 list dns 8.8.4.4 option peerdns 0 config interface 'wan' option ifname 'eth1' option proto 'dhcp' config interface 'wan6' option ifname 'eth1' option proto 'dhcpv6' config interface 'mesh' option proto 'batadv' option mtu '1528' option mesh 'bat0' Gateway configuration ------------------------------------------------------------- everything is the same as in the nodes configuration but batman-adv file. config 'mesh' 'bat0' option 'interfaces' 'mesh' option 'aggregated_ogms' option 'ap_isolation' '1' option 'bonding' option 'fragmentation' '1' option 'gw_bandwidth' option 'gw_mode' 'server' option 'gw_sel_class' option 'log_level' option 'orig_interval' option 'vis_mode' option 'bridge_loop_avoidance' '1' option 'distributed_arp_table' option 'multicast_mode' option 'network_coding' option 'hop_penalty' option 'isolation_mark'

2 1

[B.A.T.M.A.N.] [PATCH maint 1/2] batman-adv: Fix double free during fragment merge error
by Sven Eckelmann 21 Feb '17

21 Feb '17

The function batadv_frag_skb_buffer was supposed not to consume the skbuff on errors. This was followed in the helper function batadv_frag_insert_packet when the skb would potentially be inserted in the fragment queue. But it could happen that the next helper function batadv_frag_merge_packets would try to merge the fragments and fail. This results in a kfree_skb of all the enqueued fragments (including the just inserted one). batadv_recv_frag_packet would detect the error in batadv_frag_skb_buffer and try to free the skb again. The behavior of batadv_frag_skb_buffer (and its helper batadv_frag_insert_packet) must therefore be changed to always consume the skbuff to have a common behavior and avoid the double kfree_skb. Fixes: 9b3eab61754d ("batman-adv: Receive fragmented packets and merge") Signed-off-by: Sven Eckelmann <sven(a)narfation.org> --- Cc: Martin Hundebøll <martin(a)hundeboll.net> net/batman-adv/fragmentation.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/net/batman-adv/fragmentation.c b/net/batman-adv/fragmentation.c index ead18ca8..7b523e6c 100644 --- a/net/batman-adv/fragmentation.c +++ b/net/batman-adv/fragmentation.c @@ -239,8 +239,10 @@ err_unlock: spin_unlock_bh(&chain->lock); err: - if (!ret) + if (!ret) { kfree(frag_entry_new); + kfree_skb(skb); + } return ret; } @@ -313,7 +315,7 @@ free: * * There are three possible outcomes: 1) Packet is merged: Return true and * set *skb to merged packet; 2) Packet is buffered: Return true and set *skb - * to NULL; 3) Error: Return false and leave skb as is. + * to NULL; 3) Error: Return false and free skb. * * Return: true when packet is merged or buffered, false when skb is not not * used. @@ -338,9 +340,9 @@ bool batadv_frag_skb_buffer(struct sk_buff **skb, goto out_err; out: - *skb = skb_out; ret = true; out_err: + *skb = skb_out; return ret; } -- 2.11.0

2 3

[B.A.T.M.A.N.] [PATCH maint] batman-adv: Fix transmission of final, 16th fragment
by Linus Lüssing 21 Feb '17

21 Feb '17

Trying to split and transmit a unicast packet in 16 parts will fail for the final fragment: After having sent the 15th one with a frag_packet.no index of 14, we will increase the the index to 15 - and return with an error code immediately, even though one more fragment is due for transmission and allowed. Fixing this issue by moving the check before incrementing the index. While at it, adding an unlikely(), because the check is actually more of an assertion. Signed-off-by: Linus Lüssing <linus.luessing(a)c0d3.blue> --- Compile time tested only --- net/batman-adv/fragmentation.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/net/batman-adv/fragmentation.c b/net/batman-adv/fragmentation.c index 0854ebd..f181868 100644 --- a/net/batman-adv/fragmentation.c +++ b/net/batman-adv/fragmentation.c @@ -499,6 +499,12 @@ int batadv_frag_send_packet(struct sk_buff *skb, /* Eat and send fragments from the tail of skb */ while (skb->len > max_fragment_size) { + /* The initial check in this function should cover this case */ + if (unlikely(frag_header.no == BATADV_FRAG_MAX_FRAGMENTS - 1)) { + ret = -EINVAL; + goto put_primary_if; + } + skb_fragment = batadv_frag_create(skb, &frag_header, mtu); if (!skb_fragment) { ret = -ENOMEM; @@ -515,12 +521,6 @@ int batadv_frag_send_packet(struct sk_buff *skb, } frag_header.no++; - - /* The initial check in this function should cover this case */ - if (frag_header.no == BATADV_FRAG_MAX_FRAGMENTS - 1) { - ret = -EINVAL; - goto put_primary_if; - } } /* Make room for the fragment header. */ -- 2.1.4

2 5

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