B.A.T.M.A.N December 2015

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

15 participants
50 discussions

[B.A.T.M.A.N.] [PATCH] batctl: update copyright years for 2016
by Sven Eckelmann 06 Jan '16

06 Jan '16

Signed-off-by: Sven Eckelmann <sven(a)narfation.org> --- Makefile | 2 +- allocate.h | 2 +- bat-hosts.c | 2 +- bat-hosts.h | 2 +- bisect_iv.c | 2 +- bisect_iv.h | 2 +- debug.c | 2 +- debug.h | 2 +- functions.c | 2 +- functions.h | 2 +- hash.c | 2 +- hash.h | 2 +- ioctl.c | 2 +- ioctl.h | 2 +- list-batman.c | 2 +- list-batman.h | 2 +- main.c | 2 +- main.h | 2 +- packet.h | 2 +- ping.c | 2 +- ping.h | 2 +- sys.c | 2 +- sys.h | 2 +- tcpdump.c | 2 +- tcpdump.h | 2 +- traceroute.c | 2 +- traceroute.h | 2 +- translate.c | 2 +- translate.h | 2 +- 29 files changed, 29 insertions(+), 29 deletions(-) diff --git a/Makefile b/Makefile index d83d2e8..b82c0c6 100755 --- a/Makefile +++ b/Makefile @@ -1,7 +1,7 @@ #!/usr/bin/make -f # -*- makefile -*- # -# Copyright (C) 2006-2015 B.A.T.M.A.N. contributors +# Copyright (C) 2006-2016 B.A.T.M.A.N. contributors # # This program is free software; you can redistribute it and/or # modify it under the terms of version 2 of the GNU General Public diff --git a/allocate.h b/allocate.h index 02edf5c..a20f891 100644 --- a/allocate.h +++ b/allocate.h @@ -1,5 +1,5 @@ /* - * Copyright (C) 2009-2015 B.A.T.M.A.N. contributors: + * Copyright (C) 2009-2016 B.A.T.M.A.N. contributors: * * Marek Lindner <mareklindner(a)neomailbox.ch> * diff --git a/bat-hosts.c b/bat-hosts.c index 72bec80..a4add34 100644 --- a/bat-hosts.c +++ b/bat-hosts.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2007-2015 B.A.T.M.A.N. contributors: + * Copyright (C) 2007-2016 B.A.T.M.A.N. contributors: * * Andreas Langer <an.langer(a)gmx.de>, Marek Lindner <mareklindner(a)neomailbox.ch> * diff --git a/bat-hosts.h b/bat-hosts.h index f402455..78c7b2b 100644 --- a/bat-hosts.h +++ b/bat-hosts.h @@ -1,5 +1,5 @@ /* - * Copyright (C) 2009-2015 B.A.T.M.A.N. contributors: + * Copyright (C) 2009-2016 B.A.T.M.A.N. contributors: * * Marek Lindner <mareklindner(a)neomailbox.ch> * diff --git a/bisect_iv.c b/bisect_iv.c index 5b9c041..0f2c0cb 100644 --- a/bisect_iv.c +++ b/bisect_iv.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2009-2015 B.A.T.M.A.N. contributors: + * Copyright (C) 2009-2016 B.A.T.M.A.N. contributors: * * Marek Lindner <mareklindner(a)neomailbox.ch> * diff --git a/bisect_iv.h b/bisect_iv.h index ec575d2..ace76c7 100644 --- a/bisect_iv.h +++ b/bisect_iv.h @@ -1,5 +1,5 @@ /* - * Copyright (C) 2009-2015 B.A.T.M.A.N. contributors: + * Copyright (C) 2009-2016 B.A.T.M.A.N. contributors: * * Marek Lindner <mareklindner(a)neomailbox.ch> * diff --git a/debug.c b/debug.c index bcdeef7..3db3ed9 100644 --- a/debug.c +++ b/debug.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2009-2015 B.A.T.M.A.N. contributors: + * Copyright (C) 2009-2016 B.A.T.M.A.N. contributors: * * Marek Lindner <mareklindner(a)neomailbox.ch> * diff --git a/debug.h b/debug.h index 6cbfcd8..df65f50 100644 --- a/debug.h +++ b/debug.h @@ -1,5 +1,5 @@ /* - * Copyright (C) 2009-2015 B.A.T.M.A.N. contributors: + * Copyright (C) 2009-2016 B.A.T.M.A.N. contributors: * * Marek Lindner <mareklindner(a)neomailbox.ch> * diff --git a/functions.c b/functions.c index 3fcd2ad..be8f8b0 100644 --- a/functions.c +++ b/functions.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2007-2015 B.A.T.M.A.N. contributors: + * Copyright (C) 2007-2016 B.A.T.M.A.N. contributors: * * Andreas Langer <an.langer(a)gmx.de>, Marek Lindner <mareklindner(a)neomailbox.ch> * diff --git a/functions.h b/functions.h index 02ed5ea..d0b05b9 100644 --- a/functions.h +++ b/functions.h @@ -1,5 +1,5 @@ /* - * Copyright (C) 2007-2015 B.A.T.M.A.N. contributors: + * Copyright (C) 2007-2016 B.A.T.M.A.N. contributors: * * Andreas Langer <an.langer(a)gmx.de>, Marek Lindner <mareklindner(a)neomailbox.ch> * diff --git a/hash.c b/hash.c index 069a424..08d47b5 100644 --- a/hash.c +++ b/hash.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2006-2015 B.A.T.M.A.N. contributors: + * Copyright (C) 2006-2016 B.A.T.M.A.N. contributors: * * Simon Wunderlich, Marek Lindner * diff --git a/hash.h b/hash.h index aa27f25..b090888 100644 --- a/hash.h +++ b/hash.h @@ -1,5 +1,5 @@ /* - * Copyright (C) 2006-2015 B.A.T.M.A.N. contributors: + * Copyright (C) 2006-2016 B.A.T.M.A.N. contributors: * * Simon Wunderlich, Marek Lindner * diff --git a/ioctl.c b/ioctl.c index 068f894..ca02414 100644 --- a/ioctl.c +++ b/ioctl.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2012-2015 B.A.T.M.A.N. contributors: + * Copyright (C) 2012-2016 B.A.T.M.A.N. contributors: * * Marek Lindner <mareklindner(a)neomailbox.ch> * diff --git a/ioctl.h b/ioctl.h index 55c9aab..a6f8a08 100644 --- a/ioctl.h +++ b/ioctl.h @@ -1,5 +1,5 @@ /* - * Copyright (C) 2012-2015 B.A.T.M.A.N. contributors: + * Copyright (C) 2012-2016 B.A.T.M.A.N. contributors: * * Marek Lindner <mareklindner(a)neomailbox.ch> * diff --git a/list-batman.c b/list-batman.c index 1beafaf..affedb6 100644 --- a/list-batman.c +++ b/list-batman.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2006-2015 B.A.T.M.A.N. contributors: + * Copyright (C) 2006-2016 B.A.T.M.A.N. contributors: * * Marek Lindner * diff --git a/list-batman.h b/list-batman.h index c7372c8..53b8413 100644 --- a/list-batman.h +++ b/list-batman.h @@ -1,5 +1,5 @@ /* - * Copyright (C) 2006-2015 B.A.T.M.A.N. contributors: + * Copyright (C) 2006-2016 B.A.T.M.A.N. contributors: * * Marek Lindner * diff --git a/main.c b/main.c index 96aea4d..a2cda5b 100644 --- a/main.c +++ b/main.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2007-2015 B.A.T.M.A.N. contributors: + * Copyright (C) 2007-2016 B.A.T.M.A.N. contributors: * * Andreas Langer <an.langer(a)gmx.de>, Marek Lindner <mareklindner(a)neomailbox.ch> * diff --git a/main.h b/main.h index 437721d..58fe794 100644 --- a/main.h +++ b/main.h @@ -1,5 +1,5 @@ /* - * Copyright (C) 2007-2015 B.A.T.M.A.N. contributors: + * Copyright (C) 2007-2016 B.A.T.M.A.N. contributors: * * Andreas Langer <an.langer(a)gmx.de>, Marek Lindner <mareklindner(a)neomailbox.ch> * diff --git a/packet.h b/packet.h index fdb0163..e7f9151 100644 --- a/packet.h +++ b/packet.h @@ -1,4 +1,4 @@ -/* Copyright (C) 2007-2015 B.A.T.M.A.N. contributors: +/* Copyright (C) 2007-2016 B.A.T.M.A.N. contributors: * * Marek Lindner, Simon Wunderlich * diff --git a/ping.c b/ping.c index a38b31a..05d6e97 100644 --- a/ping.c +++ b/ping.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2007-2015 B.A.T.M.A.N. contributors: + * Copyright (C) 2007-2016 B.A.T.M.A.N. contributors: * * Andreas Langer <an.langer(a)gmx.de>, Marek Lindner <mareklindner(a)neomailbox.ch> * diff --git a/ping.h b/ping.h index a6c1e36..58d6bf9 100644 --- a/ping.h +++ b/ping.h @@ -1,5 +1,5 @@ /* - * Copyright (C) 2009-2015 B.A.T.M.A.N. contributors: + * Copyright (C) 2009-2016 B.A.T.M.A.N. contributors: * * Marek Lindner <mareklindner(a)neomailbox.ch> * diff --git a/sys.c b/sys.c index 838fcd8..afa8533 100644 --- a/sys.c +++ b/sys.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2009-2015 B.A.T.M.A.N. contributors: + * Copyright (C) 2009-2016 B.A.T.M.A.N. contributors: * * Marek Lindner <mareklindner(a)neomailbox.ch> * diff --git a/sys.h b/sys.h index 13c164e..da2769d 100644 --- a/sys.h +++ b/sys.h @@ -1,5 +1,5 @@ /* - * Copyright (C) 2009-2015 B.A.T.M.A.N. contributors: + * Copyright (C) 2009-2016 B.A.T.M.A.N. contributors: * * Marek Lindner <mareklindner(a)neomailbox.ch> * diff --git a/tcpdump.c b/tcpdump.c index 0bbfefc..db28414 100644 --- a/tcpdump.c +++ b/tcpdump.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2007-2015 B.A.T.M.A.N. contributors: + * Copyright (C) 2007-2016 B.A.T.M.A.N. contributors: * * Andreas Langer <an.langer(a)gmx.de> * diff --git a/tcpdump.h b/tcpdump.h index 37ab241..dc9e5a6 100644 --- a/tcpdump.h +++ b/tcpdump.h @@ -1,5 +1,5 @@ /* - * Copyright (C) 2007-2015 B.A.T.M.A.N. contributors: + * Copyright (C) 2007-2016 B.A.T.M.A.N. contributors: * * Andreas Langer <an.langer(a)gmx.de>, Marek Lindner <mareklindner(a)neomailbox.ch> * diff --git a/traceroute.c b/traceroute.c index 62cf000..2cd29d9 100644 --- a/traceroute.c +++ b/traceroute.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2007-2015 B.A.T.M.A.N. contributors: + * Copyright (C) 2007-2016 B.A.T.M.A.N. contributors: * * Andreas Langer <an.langer(a)gmx.de>, Marek Lindner <mareklindner(a)neomailbox.ch> * diff --git a/traceroute.h b/traceroute.h index 2f1512d..6dc5603 100644 --- a/traceroute.h +++ b/traceroute.h @@ -1,5 +1,5 @@ /* - * Copyright (C) 2009-2015 B.A.T.M.A.N. contributors: + * Copyright (C) 2009-2016 B.A.T.M.A.N. contributors: * * Marek Lindner <mareklindner(a)neomailbox.ch> * diff --git a/translate.c b/translate.c index cefa9da..62c696a 100644 --- a/translate.c +++ b/translate.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2007-2015 B.A.T.M.A.N. contributors: + * Copyright (C) 2007-2016 B.A.T.M.A.N. contributors: * * Andreas Langer <an.langer(a)gmx.de>, Marek Lindner <mareklindner(a)neomailbox.ch> * diff --git a/translate.h b/translate.h index e349a70..f652091 100644 --- a/translate.h +++ b/translate.h @@ -1,5 +1,5 @@ /* - * Copyright (C) 2009-2015 B.A.T.M.A.N. contributors: + * Copyright (C) 2009-2016 B.A.T.M.A.N. contributors: * * Marek Lindner <mareklindner(a)neomailbox.ch> * -- 2.6.4

2 1

[B.A.T.M.A.N.] [PATCH v2 01/30] batman-adv: Fix list removal of batadv_hardif_neigh_node
by Sven Eckelmann 05 Jan '16

05 Jan '16

The neigh_list with batadv_hardif_neigh_node objects is accessed with only rcu_read_lock in batadv_neigh_node_get and batadv_iv_neigh_print. Thus it is not allowed to kfree the object before the rcu grace period ends (which may still protects context accessing this object). Therefore the object has first to be removed from the neigh_list and then it has either wait with synchronize_rcu or call_rcu till the grace period ends before it can be freed. Fixes: fed2826b490c ("batman-adv: add list of unique single hop neighbors per hard-interface") Signed-off-by: Sven Eckelmann <sven(a)narfation.org> --- v2: - split patchset into fixes and kref migration to make it easier when the decision is made where each patch will be applied net/batman-adv/originator.c | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/net/batman-adv/originator.c b/net/batman-adv/originator.c index 00b0437..2681c7d 100644 --- a/net/batman-adv/originator.c +++ b/net/batman-adv/originator.c @@ -217,10 +217,6 @@ static void batadv_hardif_neigh_free_rcu(struct rcu_head *rcu) hardif_neigh = container_of(rcu, struct batadv_hardif_neigh_node, rcu); - spin_lock_bh(&hardif_neigh->if_incoming->neigh_list_lock); - hlist_del_init_rcu(&hardif_neigh->list); - spin_unlock_bh(&hardif_neigh->if_incoming->neigh_list_lock); - batadv_hardif_free_ref_now(hardif_neigh->if_incoming); kfree(hardif_neigh); } @@ -233,8 +229,13 @@ static void batadv_hardif_neigh_free_rcu(struct rcu_head *rcu) static void batadv_hardif_neigh_free_now(struct batadv_hardif_neigh_node *hardif_neigh) { - if (atomic_dec_and_test(&hardif_neigh->refcount)) + if (atomic_dec_and_test(&hardif_neigh->refcount)) { + spin_lock_bh(&hardif_neigh->if_incoming->neigh_list_lock); + hlist_del_init_rcu(&hardif_neigh->list); + spin_unlock_bh(&hardif_neigh->if_incoming->neigh_list_lock); + batadv_hardif_neigh_free_rcu(&hardif_neigh->rcu); + } } /** @@ -244,8 +245,13 @@ batadv_hardif_neigh_free_now(struct batadv_hardif_neigh_node *hardif_neigh) */ void batadv_hardif_neigh_free_ref(struct batadv_hardif_neigh_node *hardif_neigh) { - if (atomic_dec_and_test(&hardif_neigh->refcount)) + if (atomic_dec_and_test(&hardif_neigh->refcount)) { + spin_lock_bh(&hardif_neigh->if_incoming->neigh_list_lock); + hlist_del_init_rcu(&hardif_neigh->list); + spin_unlock_bh(&hardif_neigh->if_incoming->neigh_list_lock); + call_rcu(&hardif_neigh->rcu, batadv_hardif_neigh_free_rcu); + } } /** -- 2.6.4

2 41

[B.A.T.M.A.N.] [PATCH] batctl: Fix typo "preferrably"
by Sven Eckelmann 31 Dec '15

31 Dec '15

Signed-off-by: Sven Eckelmann <sven(a)narfation.org> --- man/batctl.8 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/man/batctl.8 b/man/batctl.8 index 73d15e7..e804a08 100644 --- a/man/batctl.8 +++ b/man/batctl.8 @@ -186,7 +186,7 @@ Example 3: 16 or 0x0F .IP The batman-adv kernel module comes with a variety of debug tables containing various information about the state of the mesh seen by each individual node. These tables are exported via debugfs and easily accessible via batctl. You will need debugfs -support compiled into your kernel and preferrably have mounted the debugfs to a well-known mountpoint. If debugfs is not +support compiled into your kernel and preferably have mounted the debugfs to a well-known mountpoint. If debugfs is not mounted batctl will attempt to do this step for you. All of the debug tables support the following options: -- 2.6.4

2 1

Re: [B.A.T.M.A.N.] Super high package loss and weak connection
by no name 30 Dec '15

30 Dec '15

Hello Simon Thanks for your input! I did not try that, but I have a Logilink WL0084B adapter which has 150Mps only thus, I could never have a HT40 connection. Don't you agree? Thanks Richard On 29 December 2015 at 15:36, Simon Müller <simon.f.mueller(a)gmail.com> wrote: > Hi Richard, > > have you tried to set all devices to HT20? > > Regards, Simon > > 2015-12-29 13:42 GMT+01:00 no name <keinepostnurmuell(a)gmail.com>: >> >> I once again tried some settings and I want to use this message as a >> bump. I am close to certain, that the RT5370 (rt2800usb) drivers are >> to blame, but I hope some of you guys have some input for me: >> >> Here is the output from batctl td -x 1 bat0 when my client is being >> pinged with a hop node in between: >> >> 21:24:36.769860 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id >> 1326, seq 5, length 64 >> 21:24:36.770399 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id >> 1326, seq 5, length 64 >> 21:24:37.266371 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, >> Request from b2:d5:c7:9e:49:96, length 331 >> 21:24:37.461997 IP6 fe80::c489:38ff:fe52:b84b > >> fe80::b0d5:c7ff:fe9e:4996 ICMP6 neighbor solicitation, who has >> fe80::b0d5:c7ff:fe9e:4996, length 72 >> 21:24:37.465750 IP6 fe80::b0d5:c7ff:fe9e:4996 > >> fe80::c489:38ff:fe52:b84b ICMP6 neighbor advertisement, tgt is >> fe80::b0d5:c7ff:fe9e:4996, length 64 >> 21:24:37.769275 ARP, Request who-has 192.168.2.213 tell 192.168.2.1 >> (b2:d5:c7:9e:49:96), length 28 >> 21:24:37.769834 ARP, Reply 192.168.2.213 is-at c6:89:38:52:b8:4b, length >> 28 >> 21:24:37.770174 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id >> 1326, seq 6, length 64 >> 21:24:37.770398 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id >> 1326, seq 6, length 64 >> 21:24:38.770444 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id >> 1326, seq 7, length 64 >> 21:24:38.770959 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id >> 1326, seq 7, length 64 >> 21:24:39.772064 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id >> 1326, seq 8, length 64 >> 21:24:39.772547 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id >> 1326, seq 8, length 64 >> 21:24:40.774724 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id >> 1326, seq 9, length 64 >> 21:24:40.775103 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id >> 1326, seq 9, length 64 >> 21:24:41.778532 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id >> 1326, seq 10, length 64 >> 21:24:41.778937 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id >> 1326, seq 10, length 64 >> 21:24:42.205531 IP6 fe80::1cbf:71ff:fe42:cc98 > ff02::1:ff9e:4996 >> ICMP6 neighbor solicitation, who has fe80::b0d5:c7ff:fe9e:4996, length >> 72 >> 21:24:42.287275 IP6 fe80::b0d5:c7ff:fe9e:4996.16962 > ff02::1.16962: >> UDP, length 4 >> 21:24:42.456688 IP6 fe80::c489:38ff:fe52:b84b.16962 > >> fe80::b0d5:c7ff:fe9e:4996.16962: UDP, length 64 >> 21:24:42.457072 IP6 fe80::c489:38ff:fe52:b84b.16962 > >> fe80::b0d5:c7ff:fe9e:4996.16962: UDP, length 8 >> 21:24:42.771977 ARP, Request who-has 192.168.2.1 tell 192.168.2.213 >> (c6:89:38:52:b8:4b), length 28 >> 21:24:43.771977 ARP, Request who-has 192.168.2.1 tell 192.168.2.213 >> (c6:89:38:52:b8:4b), length 28 >> 21:24:43.779838 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id >> 1326, seq 12, length 64 >> 21:24:43.780191 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id >> 1326, seq 12, length 64 >> 21:24:44.771969 ARP, Request who-has 192.168.2.1 tell 192.168.2.213 >> (c6:89:38:52:b8:4b), length 28 >> 21:24:48.319048 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, >> Request from c6:89:38:52:b8:4b, length 332 >> 21:24:51.165017 ARP, Request who-has 192.168.2.1 tell 192.168.2.212 >> (1e:bf:71:42:cc:98), length 28 >> 21:24:52.165044 ARP, Request who-has 192.168.2.1 tell 192.168.2.212 >> (1e:bf:71:42:cc:98), length 28 >> 21:24:52.212253 IP6 fe80::b0d5:c7ff:fe9e:4996.16962 > ff02::1.16962: >> UDP, length 4 >> 21:24:52.456960 IP6 fe80::c489:38ff:fe52:b84b.16962 > >> fe80::b0d5:c7ff:fe9e:4996.16962: UDP, length 64 >> 21:24:52.457448 IP6 fe80::c489:38ff:fe52:b84b.16962 > >> fe80::b0d5:c7ff:fe9e:4996.16962: UDP, length 8 >> 21:24:55.421775 ARP, Request who-has 192.168.2.1 tell 192.168.2.213 >> (c6:89:38:52:b8:4b), length 28 >> 21:24:55.445452 ARP, Reply 192.168.2.1 is-at b2:d5:c7:9e:49:96, length 28 >> 21:24:55.446159 IP 192.168.2.213.44353 > 79.140.41.209.1883: TCP, >> Flags [...PA.], length 2 >> 21:24:55.780191 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id >> 1326, seq 24, length 64 >> 21:24:55.780571 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id >> 1326, seq 24, length 64 >> 21:24:56.783649 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id >> 1326, seq 25, length 64 >> 21:24:56.784025 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id >> 1326, seq 25, length 64 >> 21:24:57.788219 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id >> 1326, seq 26, length 64 >> 21:24:57.788734 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id >> 1326, seq 26, length 64 >> 21:24:58.788459 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id >> 1326, seq 27, length 64 >> 21:24:58.788969 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id >> 1326, seq 27, length 64 >> 21:24:59.788102 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id >> 1326, seq 28, length 64 >> 21:24:59.788613 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id >> 1326, seq 28, length 64 >> >> As you can see, I get a lot of ARP requests, indicating, that my >> clients are loosing the connection farily often, resulting exactly in >> the observed behavior. I really would appreciate some help, or even a >> hinch in some direction what could lead further ... >> >> Has ever someone tried to use 20+ raspberries in a meshed network as >> nodes and hops? >> >> Thanks >> Richard >> >> On 28 December 2015 at 23:43, no name <keinepostnurmuell(a)gmail.com> wrote: >> > I once again tried some settings and I want to use this message as a >> > bump. I am close to certain, that the RT5370 (rt2800usb) drivers are >> > to blame, but I hope some of you guys have some input for me: >> > >> > Here is the output from batctl td -x 1 bat0 when my client is being >> > pinged with a hop node in between: >> > >> > 21:24:36.769860 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id >> > 1326, seq 5, length 64 >> > 21:24:36.770399 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id >> > 1326, seq 5, length 64 >> > 21:24:37.266371 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, >> > Request from b2:d5:c7:9e:49:96, length 331 >> > 21:24:37.461997 IP6 fe80::c489:38ff:fe52:b84b > >> > fe80::b0d5:c7ff:fe9e:4996 ICMP6 neighbor solicitation, who has >> > fe80::b0d5:c7ff:fe9e:4996, length 72 >> > 21:24:37.465750 IP6 fe80::b0d5:c7ff:fe9e:4996 > >> > fe80::c489:38ff:fe52:b84b ICMP6 neighbor advertisement, tgt is >> > fe80::b0d5:c7ff:fe9e:4996, length 64 >> > 21:24:37.769275 ARP, Request who-has 192.168.2.213 tell 192.168.2.1 >> > (b2:d5:c7:9e:49:96), length 28 >> > 21:24:37.769834 ARP, Reply 192.168.2.213 is-at c6:89:38:52:b8:4b, length >> > 28 >> > 21:24:37.770174 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id >> > 1326, seq 6, length 64 >> > 21:24:37.770398 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id >> > 1326, seq 6, length 64 >> > 21:24:38.770444 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id >> > 1326, seq 7, length 64 >> > 21:24:38.770959 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id >> > 1326, seq 7, length 64 >> > 21:24:39.772064 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id >> > 1326, seq 8, length 64 >> > 21:24:39.772547 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id >> > 1326, seq 8, length 64 >> > 21:24:40.774724 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id >> > 1326, seq 9, length 64 >> > 21:24:40.775103 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id >> > 1326, seq 9, length 64 >> > 21:24:41.778532 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id >> > 1326, seq 10, length 64 >> > 21:24:41.778937 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id >> > 1326, seq 10, length 64 >> > 21:24:42.205531 IP6 fe80::1cbf:71ff:fe42:cc98 > ff02::1:ff9e:4996 >> > ICMP6 neighbor solicitation, who has fe80::b0d5:c7ff:fe9e:4996, length >> > 72 >> > 21:24:42.287275 IP6 fe80::b0d5:c7ff:fe9e:4996.16962 > ff02::1.16962: >> > UDP, length 4 >> > 21:24:42.456688 IP6 fe80::c489:38ff:fe52:b84b.16962 > >> > fe80::b0d5:c7ff:fe9e:4996.16962: UDP, length 64 >> > 21:24:42.457072 IP6 fe80::c489:38ff:fe52:b84b.16962 > >> > fe80::b0d5:c7ff:fe9e:4996.16962: UDP, length 8 >> > 21:24:42.771977 ARP, Request who-has 192.168.2.1 tell 192.168.2.213 >> > (c6:89:38:52:b8:4b), length 28 >> > 21:24:43.771977 ARP, Request who-has 192.168.2.1 tell 192.168.2.213 >> > (c6:89:38:52:b8:4b), length 28 >> > 21:24:43.779838 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id >> > 1326, seq 12, length 64 >> > 21:24:43.780191 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id >> > 1326, seq 12, length 64 >> > 21:24:44.771969 ARP, Request who-has 192.168.2.1 tell 192.168.2.213 >> > (c6:89:38:52:b8:4b), length 28 >> > 21:24:48.319048 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, >> > Request from c6:89:38:52:b8:4b, length 332 >> > 21:24:51.165017 ARP, Request who-has 192.168.2.1 tell 192.168.2.212 >> > (1e:bf:71:42:cc:98), length 28 >> > 21:24:52.165044 ARP, Request who-has 192.168.2.1 tell 192.168.2.212 >> > (1e:bf:71:42:cc:98), length 28 >> > 21:24:52.212253 IP6 fe80::b0d5:c7ff:fe9e:4996.16962 > ff02::1.16962: >> > UDP, length 4 >> > 21:24:52.456960 IP6 fe80::c489:38ff:fe52:b84b.16962 > >> > fe80::b0d5:c7ff:fe9e:4996.16962: UDP, length 64 >> > 21:24:52.457448 IP6 fe80::c489:38ff:fe52:b84b.16962 > >> > fe80::b0d5:c7ff:fe9e:4996.16962: UDP, length 8 >> > 21:24:55.421775 ARP, Request who-has 192.168.2.1 tell 192.168.2.213 >> > (c6:89:38:52:b8:4b), length 28 >> > 21:24:55.445452 ARP, Reply 192.168.2.1 is-at b2:d5:c7:9e:49:96, length >> > 28 >> > 21:24:55.446159 IP 192.168.2.213.44353 > 79.140.41.209.1883: TCP, >> > Flags [...PA.], length 2 >> > 21:24:55.780191 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id >> > 1326, seq 24, length 64 >> > 21:24:55.780571 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id >> > 1326, seq 24, length 64 >> > 21:24:56.783649 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id >> > 1326, seq 25, length 64 >> > 21:24:56.784025 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id >> > 1326, seq 25, length 64 >> > 21:24:57.788219 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id >> > 1326, seq 26, length 64 >> > 21:24:57.788734 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id >> > 1326, seq 26, length 64 >> > 21:24:58.788459 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id >> > 1326, seq 27, length 64 >> > 21:24:58.788969 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id >> > 1326, seq 27, length 64 >> > 21:24:59.788102 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id >> > 1326, seq 28, length 64 >> > 21:24:59.788613 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id >> > 1326, seq 28, length 64 >> > >> > As you can see, I get a lot of ARP requests, indicating, that my >> > clients are loosing the connection farily often, resulting exactly in >> > the observed behavior. I really would appreciate some help, or even a >> > hinch in some direction what could lead further ... >> > >> > Has ever someone tried to use 20+ raspberries in a meshed network as >> > nodes and hops? >> > >> > Thanks >> > Richard >> > >> > On 21 December 2015 at 16:32, <b.a.t.m.a.n-owner(a)lists.open-mesh.org> >> > wrote: >> >> Message rejected by filter rule match >> >> >> >> >> >> >> >> ---------- Forwarded message ---------- >> >> From: no name <keinepostnurmuell(a)gmail.com> >> >> To: The list for a Better Approach To Mobile Ad-hoc Networking >> >> <b.a.t.m.a.n(a)lists.open-mesh.org> >> >> Cc: >> >> Date: Mon, 21 Dec 2015 16:32:36 +0100 >> >> Subject: Re: [B.A.T.M.A.N.] Super high package loss and weak connection >> >> Right now I am working on a new set of measurements with the basis as >> >> follows: >> >> >> >> Raspberry Pi b+ with a LOGILINK WL0084B USB Stick on Jessie with Kernel >> >> 4.1.13+, batman2015-0 >> >> >> >> I tested: >> >> >> >> Batman + Ad-Hoc >> >> Batman + 802.11s >> >> only 802.11s >> >> >> >> against each other. This lead to the following results: >> >> >> >> All of the above configurations show basically the same behaviour: >> >> When pinging, the reply times from directly connected nodes are really >> >> stable (1-4ms, depends on the range). >> >> When pinging via one hop in between, the network seems to take some >> >> breaks. A burst of pings (5-10) are replied pretty accurate, but always >> >> followed by a really long break of about 2-3 seconds >> >> >> >> The problem is less intense when using the batman configurations >> >> (->actually does rout better (: ). >> >> >> >> Facing this results I think I might be staring at a driver's issue, but >> >> still wanted to see if anyone here can help me with ideas. >> >> >> >> Thanks everyone for the time and help! >> >> >> >> Richard >> >> >> >> >> >>> ---------- Forwarded message ---------- >> >>> From: Sven Eckelmann <sven(a)narfation.org> >> >>> Date: 18 December 2015 at 18:30 >> >>> Subject: Re: [B.A.T.M.A.N.] Super high package loss and weak >> >>> connection >> >>> To: no name <keinepostnurmuell(a)gmail.com> >> >>> Cc: The list for a Better Approach To Mobile Ad-hoc Networking >> >>> <b.a.t.m.a.n(a)lists.open-mesh.org> >> >>> >> >>> >> >>> On Friday 18 December 2015 18:22:40 no name wrote: >> >>> > I made a little table were I tried wheezy against jessy and 802.11 >> >>> > as >> >>> > someone suggested earlier in the mailing list to me. I placed the >> >>> > raspberries next to each other on my table and tested through >> >>> > different >> >>> > settings: >> >>> > >> >>> > ad-hoc+batman-2014.X@debian wheezy: 1m distance .. 200 >> >>> > pings, 0% >> >>> > paket loss, reply time -> (min,avg,max,mdev 1.2ms, 1.8ms, 6.4ms, >> >>> > 0.8ms) >> >>> > ad-hoc+batman-2015.2@debian jessie: 1m distance .. 200 >> >>> > pings, >> >>> > 6% paket loss, reply time -> (min,avg,max,mdev 1.1ms, 170ms, 1400ms, >> >>> > 370ms) >> >>> > 802.11s @debian jessie: 1m distance >> >>> > .. >> >>> > 200 pings, 0% paket loss, reply time -> (min,avg,max,mdev 1.05ms, >> >>> > 1.8ms, >> >>> > 14ms, 1.5ms) >> >>> >> >>> Your "table" is incomplete. adhoc without batman-adv and meshpoint >> >>> (802.11s >> >>> without fwding+ttl=1)+batman-adv are missing. You also mixed two >> >>> different >> >>> batman-adv versions. Either you use the same batman-adv version >> >>> everywhere or >> >>> make sure that the kernel+wifi driver doesn't change. Changing >> >>> multiple >> >>> variables between two tests tests make the results more or less >> >>> useless for >> >>> comparisons. >> >>> >> >>> Kind regards, >> >>> Sven >> >>> >> >> >> >> > > >

1 0

[B.A.T.M.A.N.] [PATCH-maint] batman-adv: fix lockdep splat when doing mcast_free
by Simon Wunderlich 30 Dec '15

30 Dec '15

From: Simon Wunderlich <simon(a)open-mesh.com> While testing, we got something like this: WARNING: CPU: 0 PID: 238 at net/batman-adv/multicast.c:142 batadv_mcast_mla_tt_retract+0x94/0x205 [batman_adv]() [...] Call Trace: [<ffffffff815fc597>] dump_stack+0x4b/0x64 [<ffffffff810b34dc>] warn_slowpath_common+0xbc/0x120 [<ffffffffa0024ec5>] ? batadv_mcast_mla_tt_retract+0x94/0x205 [batman_adv] [<ffffffff810b3705>] warn_slowpath_null+0x15/0x20 [<ffffffffa0024ec5>] batadv_mcast_mla_tt_retract+0x94/0x205 [batman_adv] [<ffffffffa00273fe>] batadv_mcast_free+0x36/0x39 [batman_adv] [<ffffffffa0020c77>] batadv_mesh_free+0x7d/0x13f [batman_adv] [<ffffffffa0036a6b>] batadv_softif_free+0x15/0x25 [batman_adv] [...] Signed-off-by: Simon Wunderlich <simon(a)open-mesh.com> --- Changes to PATCH: * rebase on maint, add actual splat --- net/batman-adv/multicast.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/net/batman-adv/multicast.c b/net/batman-adv/multicast.c index eb76386..75fa501 100644 --- a/net/batman-adv/multicast.c +++ b/net/batman-adv/multicast.c @@ -802,7 +802,9 @@ void batadv_mcast_free(struct batadv_priv *bat_priv) batadv_tvlv_container_unregister(bat_priv, BATADV_TVLV_MCAST, 1); batadv_tvlv_handler_unregister(bat_priv, BATADV_TVLV_MCAST, 1); + spin_lock_bh(&bat_priv->tt.commit_lock); batadv_mcast_mla_tt_retract(bat_priv, NULL); + spin_unlock_bh(&bat_priv->tt.commit_lock); } /** -- 2.6.2

5 7

[B.A.T.M.A.N.] [PATCH] batctl: Remove bogus length check in debugfs_make_path
by Sven Eckelmann 30 Dec '15

30 Dec '15

The length check never used the mesh_iface length in the size calculation. Instead it used the length of the mountpoint and the format string. But the length of the format string is not the length of the final string. Instead remove this check and depend completely on the return value of snprintf. Signed-off-by: Sven Eckelmann <sven(a)narfation.org> --- debugfs.c | 9 +-------- 1 file changed, 1 insertion(+), 8 deletions(-) diff --git a/debugfs.c b/debugfs.c index 04e47e9..3c58195 100644 --- a/debugfs.c +++ b/debugfs.c @@ -42,19 +42,12 @@ static const char *debugfs_known_mountpoints[] = { /* construct a full path to a debugfs element */ int debugfs_make_path(const char *fmt, char *mesh_iface, char *buffer, int size) { - int len; - if (strlen(debugfs_mountpoint) == 0) { buffer[0] = '\0'; return -1; } - len = strlen(debugfs_mountpoint) + strlen(fmt) + 1; - if (len >= size) - return len+1; - - snprintf(buffer, size-1, fmt, debugfs_mountpoint, mesh_iface); - return 0; + return snprintf(buffer, size, fmt, debugfs_mountpoint, mesh_iface); } static int debugfs_found; -- 2.6.4

2 1

[B.A.T.M.A.N.] [PATCH] batman-adv: Fix invalid read while copying bat_iv.bcast_own
by Sven Eckelmann 30 Dec '15

30 Dec '15

batadv_iv_ogm_orig_del_if removes a part of the bcast_own which previously belonged to the now removed interface. This is done by copying all data which comes before the removed interface and then appending all the data which comes after the removed interface. The address calculation for the position of the data which comes after the removed interface assumed that the bat_iv.bcast_own is a pointer to a single byte datatype. But it is a pointer to unsigned long and thus the calculated position was wrong off factor sizeof(unsigned long). Signed-off-by: Sven Eckelmann <sven(a)narfation.org> --- net/batman-adv/bat_iv_ogm.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/net/batman-adv/bat_iv_ogm.c b/net/batman-adv/bat_iv_ogm.c index ad678f0..a6d389b 100644 --- a/net/batman-adv/bat_iv_ogm.c +++ b/net/batman-adv/bat_iv_ogm.c @@ -185,7 +185,8 @@ unlock: static int batadv_iv_ogm_orig_del_if(struct batadv_orig_node *orig_node, int max_if_num, int del_if_num) { - int chunk_size, ret = -ENOMEM, if_offset; + int ret = -ENOMEM; + size_t chunk_size, if_offset; void *data_ptr = NULL; spin_lock_bh(&orig_node->bat_iv.ogm_cnt_lock); @@ -203,8 +204,9 @@ static int batadv_iv_ogm_orig_del_if(struct batadv_orig_node *orig_node, memcpy(data_ptr, orig_node->bat_iv.bcast_own, del_if_num * chunk_size); /* copy second part */ + if_offset = (del_if_num + 1) * chunk_size; memcpy((char *)data_ptr + del_if_num * chunk_size, - orig_node->bat_iv.bcast_own + ((del_if_num + 1) * chunk_size), + (uint8_t *)orig_node->bat_iv.bcast_own + if_offset, (max_if_num - del_if_num) * chunk_size); free_bcast_own: -- 2.6.2

2 1

Re: [B.A.T.M.A.N.] Super high package loss and weak connection
by no name 29 Dec '15

29 Dec '15

I once again tried some settings and I want to use this message as a bump. I am close to certain, that the RT5370 (rt2800usb) drivers are to blame, but I hope some of you guys have some input for me: Here is the output from batctl td -x 1 bat0 when my client is being pinged with a hop node in between: 21:24:36.769860 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id 1326, seq 5, length 64 21:24:36.770399 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id 1326, seq 5, length 64 21:24:37.266371 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from b2:d5:c7:9e:49:96, length 331 21:24:37.461997 IP6 fe80::c489:38ff:fe52:b84b > fe80::b0d5:c7ff:fe9e:4996 ICMP6 neighbor solicitation, who has fe80::b0d5:c7ff:fe9e:4996, length 72 21:24:37.465750 IP6 fe80::b0d5:c7ff:fe9e:4996 > fe80::c489:38ff:fe52:b84b ICMP6 neighbor advertisement, tgt is fe80::b0d5:c7ff:fe9e:4996, length 64 21:24:37.769275 ARP, Request who-has 192.168.2.213 tell 192.168.2.1 (b2:d5:c7:9e:49:96), length 28 21:24:37.769834 ARP, Reply 192.168.2.213 is-at c6:89:38:52:b8:4b, length 28 21:24:37.770174 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id 1326, seq 6, length 64 21:24:37.770398 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id 1326, seq 6, length 64 21:24:38.770444 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id 1326, seq 7, length 64 21:24:38.770959 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id 1326, seq 7, length 64 21:24:39.772064 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id 1326, seq 8, length 64 21:24:39.772547 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id 1326, seq 8, length 64 21:24:40.774724 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id 1326, seq 9, length 64 21:24:40.775103 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id 1326, seq 9, length 64 21:24:41.778532 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id 1326, seq 10, length 64 21:24:41.778937 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id 1326, seq 10, length 64 21:24:42.205531 IP6 fe80::1cbf:71ff:fe42:cc98 > ff02::1:ff9e:4996 ICMP6 neighbor solicitation, who has fe80::b0d5:c7ff:fe9e:4996, length 72 21:24:42.287275 IP6 fe80::b0d5:c7ff:fe9e:4996.16962 > ff02::1.16962: UDP, length 4 21:24:42.456688 IP6 fe80::c489:38ff:fe52:b84b.16962 > fe80::b0d5:c7ff:fe9e:4996.16962: UDP, length 64 21:24:42.457072 IP6 fe80::c489:38ff:fe52:b84b.16962 > fe80::b0d5:c7ff:fe9e:4996.16962: UDP, length 8 21:24:42.771977 ARP, Request who-has 192.168.2.1 tell 192.168.2.213 (c6:89:38:52:b8:4b), length 28 21:24:43.771977 ARP, Request who-has 192.168.2.1 tell 192.168.2.213 (c6:89:38:52:b8:4b), length 28 21:24:43.779838 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id 1326, seq 12, length 64 21:24:43.780191 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id 1326, seq 12, length 64 21:24:44.771969 ARP, Request who-has 192.168.2.1 tell 192.168.2.213 (c6:89:38:52:b8:4b), length 28 21:24:48.319048 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from c6:89:38:52:b8:4b, length 332 21:24:51.165017 ARP, Request who-has 192.168.2.1 tell 192.168.2.212 (1e:bf:71:42:cc:98), length 28 21:24:52.165044 ARP, Request who-has 192.168.2.1 tell 192.168.2.212 (1e:bf:71:42:cc:98), length 28 21:24:52.212253 IP6 fe80::b0d5:c7ff:fe9e:4996.16962 > ff02::1.16962: UDP, length 4 21:24:52.456960 IP6 fe80::c489:38ff:fe52:b84b.16962 > fe80::b0d5:c7ff:fe9e:4996.16962: UDP, length 64 21:24:52.457448 IP6 fe80::c489:38ff:fe52:b84b.16962 > fe80::b0d5:c7ff:fe9e:4996.16962: UDP, length 8 21:24:55.421775 ARP, Request who-has 192.168.2.1 tell 192.168.2.213 (c6:89:38:52:b8:4b), length 28 21:24:55.445452 ARP, Reply 192.168.2.1 is-at b2:d5:c7:9e:49:96, length 28 21:24:55.446159 IP 192.168.2.213.44353 > 79.140.41.209.1883: TCP, Flags [...PA.], length 2 21:24:55.780191 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id 1326, seq 24, length 64 21:24:55.780571 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id 1326, seq 24, length 64 21:24:56.783649 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id 1326, seq 25, length 64 21:24:56.784025 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id 1326, seq 25, length 64 21:24:57.788219 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id 1326, seq 26, length 64 21:24:57.788734 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id 1326, seq 26, length 64 21:24:58.788459 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id 1326, seq 27, length 64 21:24:58.788969 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id 1326, seq 27, length 64 21:24:59.788102 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id 1326, seq 28, length 64 21:24:59.788613 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id 1326, seq 28, length 64 As you can see, I get a lot of ARP requests, indicating, that my clients are loosing the connection farily often, resulting exactly in the observed behavior. I really would appreciate some help, or even a hinch in some direction what could lead further ... Has ever someone tried to use 20+ raspberries in a meshed network as nodes and hops? Thanks Richard On 28 December 2015 at 23:43, no name <keinepostnurmuell(a)gmail.com> wrote: > I once again tried some settings and I want to use this message as a > bump. I am close to certain, that the RT5370 (rt2800usb) drivers are > to blame, but I hope some of you guys have some input for me: > > Here is the output from batctl td -x 1 bat0 when my client is being > pinged with a hop node in between: > > 21:24:36.769860 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id > 1326, seq 5, length 64 > 21:24:36.770399 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id > 1326, seq 5, length 64 > 21:24:37.266371 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, > Request from b2:d5:c7:9e:49:96, length 331 > 21:24:37.461997 IP6 fe80::c489:38ff:fe52:b84b > > fe80::b0d5:c7ff:fe9e:4996 ICMP6 neighbor solicitation, who has > fe80::b0d5:c7ff:fe9e:4996, length 72 > 21:24:37.465750 IP6 fe80::b0d5:c7ff:fe9e:4996 > > fe80::c489:38ff:fe52:b84b ICMP6 neighbor advertisement, tgt is > fe80::b0d5:c7ff:fe9e:4996, length 64 > 21:24:37.769275 ARP, Request who-has 192.168.2.213 tell 192.168.2.1 > (b2:d5:c7:9e:49:96), length 28 > 21:24:37.769834 ARP, Reply 192.168.2.213 is-at c6:89:38:52:b8:4b, length 28 > 21:24:37.770174 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id > 1326, seq 6, length 64 > 21:24:37.770398 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id > 1326, seq 6, length 64 > 21:24:38.770444 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id > 1326, seq 7, length 64 > 21:24:38.770959 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id > 1326, seq 7, length 64 > 21:24:39.772064 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id > 1326, seq 8, length 64 > 21:24:39.772547 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id > 1326, seq 8, length 64 > 21:24:40.774724 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id > 1326, seq 9, length 64 > 21:24:40.775103 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id > 1326, seq 9, length 64 > 21:24:41.778532 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id > 1326, seq 10, length 64 > 21:24:41.778937 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id > 1326, seq 10, length 64 > 21:24:42.205531 IP6 fe80::1cbf:71ff:fe42:cc98 > ff02::1:ff9e:4996 > ICMP6 neighbor solicitation, who has fe80::b0d5:c7ff:fe9e:4996, length > 72 > 21:24:42.287275 IP6 fe80::b0d5:c7ff:fe9e:4996.16962 > ff02::1.16962: > UDP, length 4 > 21:24:42.456688 IP6 fe80::c489:38ff:fe52:b84b.16962 > > fe80::b0d5:c7ff:fe9e:4996.16962: UDP, length 64 > 21:24:42.457072 IP6 fe80::c489:38ff:fe52:b84b.16962 > > fe80::b0d5:c7ff:fe9e:4996.16962: UDP, length 8 > 21:24:42.771977 ARP, Request who-has 192.168.2.1 tell 192.168.2.213 > (c6:89:38:52:b8:4b), length 28 > 21:24:43.771977 ARP, Request who-has 192.168.2.1 tell 192.168.2.213 > (c6:89:38:52:b8:4b), length 28 > 21:24:43.779838 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id > 1326, seq 12, length 64 > 21:24:43.780191 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id > 1326, seq 12, length 64 > 21:24:44.771969 ARP, Request who-has 192.168.2.1 tell 192.168.2.213 > (c6:89:38:52:b8:4b), length 28 > 21:24:48.319048 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, > Request from c6:89:38:52:b8:4b, length 332 > 21:24:51.165017 ARP, Request who-has 192.168.2.1 tell 192.168.2.212 > (1e:bf:71:42:cc:98), length 28 > 21:24:52.165044 ARP, Request who-has 192.168.2.1 tell 192.168.2.212 > (1e:bf:71:42:cc:98), length 28 > 21:24:52.212253 IP6 fe80::b0d5:c7ff:fe9e:4996.16962 > ff02::1.16962: > UDP, length 4 > 21:24:52.456960 IP6 fe80::c489:38ff:fe52:b84b.16962 > > fe80::b0d5:c7ff:fe9e:4996.16962: UDP, length 64 > 21:24:52.457448 IP6 fe80::c489:38ff:fe52:b84b.16962 > > fe80::b0d5:c7ff:fe9e:4996.16962: UDP, length 8 > 21:24:55.421775 ARP, Request who-has 192.168.2.1 tell 192.168.2.213 > (c6:89:38:52:b8:4b), length 28 > 21:24:55.445452 ARP, Reply 192.168.2.1 is-at b2:d5:c7:9e:49:96, length 28 > 21:24:55.446159 IP 192.168.2.213.44353 > 79.140.41.209.1883: TCP, > Flags [...PA.], length 2 > 21:24:55.780191 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id > 1326, seq 24, length 64 > 21:24:55.780571 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id > 1326, seq 24, length 64 > 21:24:56.783649 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id > 1326, seq 25, length 64 > 21:24:56.784025 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id > 1326, seq 25, length 64 > 21:24:57.788219 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id > 1326, seq 26, length 64 > 21:24:57.788734 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id > 1326, seq 26, length 64 > 21:24:58.788459 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id > 1326, seq 27, length 64 > 21:24:58.788969 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id > 1326, seq 27, length 64 > 21:24:59.788102 IP 192.168.2.1 > 192.168.2.213: ICMP echo request, id > 1326, seq 28, length 64 > 21:24:59.788613 IP 192.168.2.213 > 192.168.2.1: ICMP echo reply, id > 1326, seq 28, length 64 > > As you can see, I get a lot of ARP requests, indicating, that my > clients are loosing the connection farily often, resulting exactly in > the observed behavior. I really would appreciate some help, or even a > hinch in some direction what could lead further ... > > Has ever someone tried to use 20+ raspberries in a meshed network as > nodes and hops? > > Thanks > Richard > > On 21 December 2015 at 16:32, <b.a.t.m.a.n-owner(a)lists.open-mesh.org> wrote: >> Message rejected by filter rule match >> >> >> >> ---------- Forwarded message ---------- >> From: no name <keinepostnurmuell(a)gmail.com> >> To: The list for a Better Approach To Mobile Ad-hoc Networking <b.a.t.m.a.n(a)lists.open-mesh.org> >> Cc: >> Date: Mon, 21 Dec 2015 16:32:36 +0100 >> Subject: Re: [B.A.T.M.A.N.] Super high package loss and weak connection >> Right now I am working on a new set of measurements with the basis as follows: >> >> Raspberry Pi b+ with a LOGILINK WL0084B USB Stick on Jessie with Kernel 4.1.13+, batman2015-0 >> >> I tested: >> >> Batman + Ad-Hoc >> Batman + 802.11s >> only 802.11s >> >> against each other. This lead to the following results: >> >> All of the above configurations show basically the same behaviour: >> When pinging, the reply times from directly connected nodes are really stable (1-4ms, depends on the range). >> When pinging via one hop in between, the network seems to take some breaks. A burst of pings (5-10) are replied pretty accurate, but always followed by a really long break of about 2-3 seconds >> >> The problem is less intense when using the batman configurations (->actually does rout better (: ). >> >> Facing this results I think I might be staring at a driver's issue, but still wanted to see if anyone here can help me with ideas. >> >> Thanks everyone for the time and help! >> >> Richard >> >> >>> ---------- Forwarded message ---------- >>> From: Sven Eckelmann <sven(a)narfation.org> >>> Date: 18 December 2015 at 18:30 >>> Subject: Re: [B.A.T.M.A.N.] Super high package loss and weak connection >>> To: no name <keinepostnurmuell(a)gmail.com> >>> Cc: The list for a Better Approach To Mobile Ad-hoc Networking <b.a.t.m.a.n(a)lists.open-mesh.org> >>> >>> >>> On Friday 18 December 2015 18:22:40 no name wrote: >>> > I made a little table were I tried wheezy against jessy and 802.11 as >>> > someone suggested earlier in the mailing list to me. I placed the >>> > raspberries next to each other on my table and tested through different >>> > settings: >>> > >>> > ad-hoc+batman-2014.X@debian wheezy: 1m distance .. 200 pings, 0% >>> > paket loss, reply time -> (min,avg,max,mdev 1.2ms, 1.8ms, 6.4ms, 0.8ms) >>> > ad-hoc+batman-2015.2@debian jessie: 1m distance .. 200 pings, >>> > 6% paket loss, reply time -> (min,avg,max,mdev 1.1ms, 170ms, 1400ms, 370ms) >>> > 802.11s @debian jessie: 1m distance .. >>> > 200 pings, 0% paket loss, reply time -> (min,avg,max,mdev 1.05ms, 1.8ms, >>> > 14ms, 1.5ms) >>> >>> Your "table" is incomplete. adhoc without batman-adv and meshpoint (802.11s >>> without fwding+ttl=1)+batman-adv are missing. You also mixed two different >>> batman-adv versions. Either you use the same batman-adv version everywhere or >>> make sure that the kernel+wifi driver doesn't change. Changing multiple >>> variables between two tests tests make the results more or less useless for >>> comparisons. >>> >>> Kind regards, >>> Sven >>> >> >>

1 0

[B.A.T.M.A.N.] [PATCH v2] batman-adv: Add lockdep assert for container_list_lock
by Sven Eckelmann 29 Dec '15

29 Dec '15

The batadv_tvlv_container* functions state in their kernel-doc that they require tvlv.container_list_lock. Add an assert to automatically detect when this might have been ignored by the caller. Signed-off-by: Sven Eckelmann <sven(a)narfation.org> --- v2: remove this from the kref patchset and instead submit it as standalone patch net/batman-adv/main.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/net/batman-adv/main.c b/net/batman-adv/main.c index 19ad0bb..c9b8205 100644 --- a/net/batman-adv/main.c +++ b/net/batman-adv/main.c @@ -720,6 +720,8 @@ static struct batadv_tvlv_container { struct batadv_tvlv_container *tvlv_tmp, *tvlv = NULL; + lockdep_assert_held(&bat_priv->tvlv.container_list_lock); + hlist_for_each_entry(tvlv_tmp, &bat_priv->tvlv.container_list, list) { if (tvlv_tmp->tvlv_hdr.type != type) continue; @@ -752,6 +754,8 @@ static u16 batadv_tvlv_container_list_size(struct batadv_priv *bat_priv) struct batadv_tvlv_container *tvlv; u16 tvlv_len = 0; + lockdep_assert_held(&bat_priv->tvlv.container_list_lock); + hlist_for_each_entry(tvlv, &bat_priv->tvlv.container_list, list) { tvlv_len += sizeof(struct batadv_tvlv_hdr); tvlv_len += ntohs(tvlv->tvlv_hdr.len); -- 2.6.4

2 1

Re: [B.A.T.M.A.N.] Super high package loss and weak connection
by Sven Eckelmann 21 Dec '15

21 Dec '15

On Friday 18 December 2015 18:22:40 no name wrote: > I made a little table were I tried wheezy against jessy and 802.11 as > someone suggested earlier in the mailing list to me. I placed the > raspberries next to each other on my table and tested through different > settings: > > ad-hoc+batman-2014.X@debian wheezy: 1m distance .. 200 pings, 0% > paket loss, reply time -> (min,avg,max,mdev 1.2ms, 1.8ms, 6.4ms, 0.8ms) > ad-hoc+batman-2015.2@debian jessie: 1m distance .. 200 pings, > 6% paket loss, reply time -> (min,avg,max,mdev 1.1ms, 170ms, 1400ms, 370ms) > 802.11s @debian jessie: 1m distance .. > 200 pings, 0% paket loss, reply time -> (min,avg,max,mdev 1.05ms, 1.8ms, > 14ms, 1.5ms) Your "table" is incomplete. adhoc without batman-adv and meshpoint (802.11s without fwding+ttl=1)+batman-adv are missing. You also mixed two different batman-adv versions. Either you use the same batman-adv version everywhere or make sure that the kernel+wifi driver doesn't change. Changing multiple variables between two tests tests make the results more or less useless for comparisons. Kind regards, Sven

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

B.A.T.M.A.N December 2015