Signed-off-by: Sven Eckelmann <sven(a)narfation.org>
v2: fixed "NodeA" in NodeB block
Documentation/networking/batman-adv.txt | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/Documentation/networking/batman-adv.txt b/Documentation/networking/batman-adv.txt
index 58e4904..ff23b75 100644
@@ -115,14 +115,17 @@ The "bat0" interface can be used like any other regular inter-
face. It needs an IP address which can be either statically con-
figured or dynamically (by using DHCP or similar services):
-# NodeA: ifconfig bat0 192.168.0.1
-# NodeB: ifconfig bat0 192.168.0.2
+# NodeA: ip link set up dev bat0
+# NodeA: ip addr add 192.168.0.1/24 dev bat0
+# NodeB: ip link set up dev bat0
+# NodeB: ip addr add 192.168.0.2/24 dev bat0
# NodeB: ping 192.168.0.1
Note: In order to avoid problems remove all IP addresses previ-
ously assigned to interfaces now used by batman advanced, e.g.
-# ifconfig eth0 0.0.0.0
+# ip addr flush dev eth0
I have recently moved 13 nodes previously using wds to batman-adv.
One problem that i am encountering is the gateway selection and its
This problem has be seen when the client nodes are set on class 20.
The node clients in fact select the gateways that advertise better link
quality usually above 200 but at the same time some clients end up
connecting to a gateway that is either too slow or unusable either due
to routing or other factors such as distance and even clear visibility.
In one case the node connects to something that defies logic.
I thought about ways to work around this and came up with an idea that
may help which means the creation of 2 new classes.
- Preferred gateway fall-back
- Preferred fixed gateway
For Preferred gateway fall-back:
consider the gateway's advertised quality towards the gateway and stick
with the selection until the gateway disappears returning to it soon as
it returns regardless of any other data.
- Preferred fixed gateway
Manual gateway selection by the node owner or admin. (wds type)
If these classes cannot be created; maybe a plugin of some sort could
be. could be called "gordon".
I understand that this idea may sound useless the same way blocking
originators may be for someone but in some scenarios just like blocking
originators it look to me very valid.
My current problem is that the link quality seems to go up and down like
a roller coaster in a specific order which causes the clients to switch
constantly sometimes many times per hour.
While this does not seem to be an issue for most client nodes; for 2 of
them it means no internet access at all.
The solution for now seems to be having these 2 nodes forced to use 1
I am quite open to any ideas that may help resolve this issue that has
been casing some "uninformed people" to become headaches.
there are some patches waiting in batman-adv's next branch which are currently
missing in davem's net-next. The diff from the daily build_test is stable
since 1 1/2 months :
net/batman-adv/bridge_loop_avoidance.c | 35 +++---------------------
net/batman-adv/routing.c | 19 ++-----------
net/batman-adv/translation-table.c | 24 ++--------------
net/batman-adv/types.h | 2 -
4 files changed, 12 insertions(+), 68 deletions(-)
The patches which are currently missing in net-next are:
All of them are from maint and thus have conflicts with patches that are
already in net-next. The rebased/squashed patches can be found in the
I am experimenting with using Alfred on a group of drones (initially
10 units) to send their GPS locations to each other.
The drones will be connected via batman-adv on WIFI, and each of them
read the GPS every 200ms (5Hz).
I would like to change alfred-gpsd from updating the GPS coordinates
every 10s to 200ms.
Does anyone see any issues with this change? ie it is even feasible/practical?
Im an engineer working in a R&D Project using batman-adv protocol. Were
trying to develop a mesh network using linux devices with the objective of
transmitting video in streaming. Video is being generated with gstreamer
The application works relatively fine with 2 devices, but efficiency heavily
decreases when introducing a new node in the mesh network (information need
two jumps to arrive to destination). Introducing more jumps in the network
is exponentially worst. We have been expecting a better behavior of this
protocol, since level 2 routing should be transparent (just increasing
delay when increasing the number of nodes).
We are using batman version 2015.0, over wifi interfaces, and our streaming
applications is working only point-to-point (not multicast or broadcast).
The nodes in between server and client are working just as wireless
repeaters using batman-adv.
We also discovered that worst case happens when changes in batman routing
tables are happening (sometimes, client is able to reach server in just one
jump, but with low quality, and chooses that option instead of jumping
through the repeater node, with better quality). When that happens, we're
droping lots of packets.
Any of you haver tried batman-adv for video streaming? Which was the maximum
number of jumps between batman nodes that you can manage maintaining a good
Can you recommend any specific configuration for improving batman behavior?