B.A.T.M.A.N January 2018

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

11 participants
14 discussions

[B.A.T.M.A.N.] Can b.a.t.m.a.n. be configured to ARP for unknown clients?
by Robert Bates 05 Jan '18

05 Jan '18

Hello, Is it possible to have b.a.t.m.a.n. ARP if packets are received at bat0 for a client which has been removed/deleted due to timeout, and is therefore no longer in the translation tables? In one customer application of a product of ours (a mesh AP we've licensed from another vendor/developer, which is based on openWRT/b.a.t.m.a.n.), we are being adversely affected by the 10 minute inactivity timer on transtable_local. The clients in this customer's network/application are stationary devices which basically do not speak unless spoken to (e.g. when they are polled for data). They are periodically polled by a management platform, using an upper layer protocol running over TCP. The problem is that this customer's polling cycle time is variable, and occasionally it is taking longer than 10 minutes between successive polls of a given client/device. When this happens, that client is of course removed from transtable_local, and transtable_global on the other nodes in the mesh. Meanwhile, the polling/management platform has a very long ARP cache life, so it never ARPs (and apparently it is not possible on this platform to have the customer implement dynamic, rather than static ARP table entries, in which it would ARP upon polling failure). So once we get into this state, polls to this client device which has dropped out of the mesh are not possible, and their management platform throws alarms, etc. To bring it back in service at that point requires an ARP, which the customer is manually triggering with a ping, whenever one of these "outages" occurs. We know that the transtable_local inactivity/removal timer value can be extended, and we will probably do that, but we would also like to know if it is possible to have b.a.t.m.a.n. ARP for the removed client in this case. We prefer this approach, rather than arbitrarily changing the tt_local timer to some value which may not work well in some other customer's network/application. I know that there is a statistically valid underlying assumption with this 10 minute inactivity timer on transtable_local, that clients will typically be "chatty". But again, that is not the case in this application, which is a very common one in the industry in which we operate, where clients are very often fixed devices which only respond to explicit queries or commands. This is a new product and protocol for us, and this could beg the question of whether or not b.a.t.man.-based meshing is the right solution in this type of application. We believe it can be; it would just be helpful if we can configure it to ARP in this type of scenario. Can you please comment on how this might be possible (config or otherwise)? Thanks very much, Robert Bates IMPORTANT NOTICE: This communication, including any attachments, is the property of FreeWave Technologies, Inc. and may contain proprietary, confidential, or privileged information. Unauthorized use or disclosure of this communication is strictly prohibited and may be unlawful. Information contained herein may be subject to a Proprietary Information / Non-Disclosure Agreement and shall be maintained in confidence and not disclosed to third parties without the written consent of FreeWave Technologies, Inc. If you have received this communication in error, please immediately notify the sender and destroy all copies of the communication and any attachments.

5 8

[B.A.T.M.A.N.] [PATCH] batman-adv: Fixed statements not starting on a tabstop
by Sven Eckelmann 05 Jan '18

05 Jan '18

Also multiline macros should have their statements start on a tabstop. This was detected by checkpatch.pl with "checkpatch: Improve the TABSTOP test to include declarations". Signed-off-by: Sven Eckelmann <sven(a)narfation.org> --- net/batman-adv/main.h | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/net/batman-adv/main.h b/net/batman-adv/main.h index 5f34c495..1a9c7a3c 100644 --- a/net/batman-adv/main.h +++ b/net/batman-adv/main.h @@ -331,11 +331,13 @@ static inline bool batadv_has_timed_out(unsigned long timestamp, * * Return: true when x is a predecessor of y, false otherwise */ -#define batadv_seq_before(x, y) ({typeof(x)_d1 = (x); \ - typeof(y)_d2 = (y); \ - typeof(x)_dummy = (_d1 - _d2); \ - (void)(&_d1 == &_d2); \ - _dummy > batadv_smallest_signed_int(_dummy); }) +#define batadv_seq_before(x, y) ({ \ + typeof(x)_d1 = (x); \ + typeof(y)_d2 = (y); \ + typeof(x)_dummy = (_d1 - _d2); \ + (void)(&_d1 == &_d2); \ + _dummy > batadv_smallest_signed_int(_dummy); \ +}) /** * batadv_seq_after() - Checks if a sequence number x is a successor of y -- 2.11.0

1 0

Re: [B.A.T.M.A.N.] checkpatch: Add test for keywords not starting on tabstops
by Sven Eckelmann 05 Jan '18

05 Jan '18

On Donnerstag, 21. April 2016 12:41:37 CET Joe Perches wrote: > It's somewhat common and in general a defect for c90 keywords to > not start on a tabstop. > > Add a test for this condition and warn when it occurs. This seems to create some new false positives: WARNING: Statements should start on a tabstop #919: FILE: ./net/batman-adv/sysfs.c:919: + char ifname[IFNAMSIZ]) total: 0 errors, 1 warnings, 0 checks, 1251 lines checked The code at this position is: /** * batadv_store_mesh_iface_finish() - store new hardif mesh_iface state * @net_dev: netdevice to add/remove to/from batman-adv soft-interface * @ifname: name of soft-interface to modify * * Changes the parts of the hard+soft interface which can not be modified under * sysfs lock (to prevent deadlock situations). * * Return: 0 on success, 0 < on failure */ static int batadv_store_mesh_iface_finish(struct net_device *net_dev, char ifname[IFNAMSIZ]) { struct net *net = dev_net(net_dev); I know, my mail client is most likely mangling the tabs - so better check https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/tree/net… Problem seems to be the [IFNAMSIZ] Kind regards, Sven

1 1

[B.A.T.M.A.N.] 11ac throughput on mesh links
by Daniel Ghansah 01 Jan '18

01 Jan '18

I am testing an implementation of batman-adv, alfred, 802.11s, 11ac. In this implementation I have my mesh interface on the 5GHz radio (qca9882), Using LEDE/Openwrt 17.01.04 I am getting root@Daniel Node:~# batctl tp 9c:b7:93:e3:56:e4 Test duration 10020ms. Sent 142966836 Bytes. Throughput: 13.61 MB/s (114.15 Mbps) is this inline with what everyone has seen. That data rate established is high however the throughput is very low root@Daniel Node:~# iw mesh0 station dump Station 9c:b7:93:e3:56:e4 (on mesh0) inactive time: 100 ms rx bytes: 75007154 rx packets: 910406 tx bytes: 968480244 tx packets: 635811 tx retries: 0 tx failed: 7 rx drop misc: 15 signal: -45 dBm signal avg: -44 dBm Toffset: 18446744061225933893 us tx bitrate: 6.0 MBit/s rx bitrate: 650.0 MBit/s VHT-MCS 7 80MHz short GI VHT-NSS 2 rx duration: 10763380 us mesh llid: 44135 mesh plid: 29835 mesh plink: ESTAB mesh local PS mode: ACTIVE mesh peer PS mode: ACTIVE mesh non-peer PS mode: ACTIVE authorized: yes authenticated: yes associated: yes preamble: long WMM/WME: yes MFP: no TDLS peer: no DTIM period: 2 beacon interval:100 short slot time:yes connected time: 12825 seconds What may I be doing wrong?

4 5

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

B.A.T.M.A.N January 2018