We've been using batman with alfred and MQTT on raspbian for about 3 years. We found it to be useful up to about 15 nodes, and then we'd saturate the wifi. Then we downgraded the driver and we can get slightly over 30. but something we found was all of our nodes were using gw_mode client 0, and we realized this isn't listed in the spec. Do you know what it does in that case, does it use the default of 20?
here is a little feature/cleanup pull request of batman-adv to go into net-next.
Please pull or let me know of any problem!
The following changes since commit b3a9e3b9622ae10064826dccb4f7a52bd88c7407:
Linux 5.8-rc1 (2020-06-14 12:45:04 -0700)
are available in the Git repository at:
for you to fetch changes up to 3bda14d09dc5789a895ab02b7dcfcec19b0a65b3:
batman-adv: Introduce a configurable per interface hop penalty (2020-06-26 10:37:11 +0200)
This feature/cleanup patchset includes the following patches:
- bump version strings, by Simon Wunderlich
- update mailing list URL, by Sven Eckelmann
- fix typos and grammar in documentation, by Sven Eckelmann
- introduce a configurable per interface hop penalty,
by Linus Luessing
Linus Lüssing (1):
batman-adv: Introduce a configurable per interface hop penalty
Simon Wunderlich (1):
batman-adv: Start new development cycle
Sven Eckelmann (2):
batman-adv: Switch mailing list subscription page
batman-adv: Fix typos and grammar in documentation
Documentation/networking/batman-adv.rst | 8 +++---
include/uapi/linux/batadv_packet.h | 50 ++++++++++++++++-----------------
include/uapi/linux/batman_adv.h | 7 +++--
net/batman-adv/bat_iv_ogm.c | 25 +++++++++--------
net/batman-adv/bat_v_elp.c | 10 +++----
net/batman-adv/bat_v_ogm.c | 27 +++++++++++-------
net/batman-adv/bridge_loop_avoidance.c | 6 ++--
net/batman-adv/distributed-arp-table.c | 2 +-
net/batman-adv/fragmentation.c | 6 ++--
net/batman-adv/hard-interface.c | 16 ++++++-----
net/batman-adv/log.h | 6 ++--
net/batman-adv/main.c | 2 +-
net/batman-adv/main.h | 8 +++---
net/batman-adv/multicast.c | 21 +++++++-------
net/batman-adv/netlink.c | 14 +++++++--
net/batman-adv/network-coding.c | 14 ++++-----
net/batman-adv/originator.c | 8 +++---
net/batman-adv/routing.c | 4 +--
net/batman-adv/send.c | 4 +--
net/batman-adv/soft-interface.c | 2 +-
net/batman-adv/tp_meter.c | 12 ++++----
net/batman-adv/translation-table.c | 10 +++----
net/batman-adv/tvlv.c | 4 +--
net/batman-adv/types.h | 18 ++++++++----
24 files changed, 156 insertions(+), 128 deletions(-)
With reference to the wiki topic at
Available since: batman-adv 2010.1.0
When running the mesh over multiple WiFi interfaces per node
batman-adv is capable of optimizing the traffic flow to gain maximum
performance. Per default it operates in the "interface alternating"
mode (which is suitable for most situations) that switches the WiFi
interface with each hop to avoid store & forward. Alternatively,
batman-adv can be switched into "bonding mode" in which batman-adv is
using all interfaces at the same time to send & receive data. However,
this mode is only recommended in special one-hop cases. You can read
about our alternatebonding test results to see what suits you best.
The wiki shows that this is the only change required on both nodes to
use it in default interface alternating mode
batctl meshif bat0 bonding enabled
The wiki does not say how the throughput was measured after bonding was enabled
Will batctl tp be ok?
[please never contact me privately about batman-adv without a really good
reason. Cc at least the mailing list]
On Thursday, 25 June 2020 13:12:34 CEST Mark Birss wrote:
> "Is the lower layer working or did the lower layer break? Can be
> tested easily with multicast/broadcast and unicast pings on the lower
> How to do this ?
* unicast: just ping as normal the lower device (not bat0) IPv4 address or
(link local) IPv6 address
* multicast: just send from both sides an multicast ping. For example
ff02::1%wlan0 and check if the remote (not your own device) responds with a
> As for originator and neighbours this can also be checked by batctl or
> proc file system.
proc? If you have batman-adv entries in proc then you should definitely
upgrade. This was removed in 2010.
Should this have been a question about where to find the originators and
neighbors table? And you can see this via "batctl meshif bat0 originators"
and "batctl meshif bat0 neighbors". The "meshif bat0" has to replaced with
"-m bat0" on older batctl versions.
> Another question is there a breakdown of the meaning of the messages for
> $ cat /sys/kernel/debug/batman_adv/bat0/log
> The additional debug output is by default disabled. It can be enabled
> during run time. Following log_levels are defined:
No idea what you want here. The help text already says what each message type
is about. If you don't know what a specific feature is then please check the
> and what is the Flags here
> root@LiMe-a376eb:~# batctl tl
> [B.A.T.M.A.N. adv 2020.1-openwrt-2, MainIF/MAC:
> dummy0/aa:84:86:a3:76:eb (bat0/72:8b:cf:a4:00:77 BATMAN_IV), TTVN: 4]
> Client VID Flags Last seen (CRC )
> 72:8b:cf:a4:00:77 -1 [.P....] 0.000 (0x1c349131)
> 50:3e:aa:06:6f:4d -1 [......] 0.280 (0x1c349131)
> 72:8b:cf:a4:00:77 0 [.P....] 0.000 (0x9243e316)
> cc:2d:e0:47:b3:56 -1 [......] 0.980 (0x1c349131)
> 72:8b:cf:a4:00:77 1 [.P....] 0.000 (0xdb7f9e31)
The flags here are
* 'R' BATADV_TT_CLIENT_ROAM
* 'N' BATADV_TT_CLIENT_NEW
* 'X' BATADV_TT_CLIENT_PENDING
* 'W' BATADV_TT_CLIENT_WIFI
* 'I' BATADV_TT_CLIENT_ISOLA
* 'P' BATADV_TT_CLIENT_NOPURGE
And they are documented in the wiki 
This bug is marked as fixed by commit:
blk-mq: Fix a recently introduced regression in
But I can't find it in any tested tree for more than 90 days.
Is it a correct commit? Please update it by replying:
#syz fix: exact-commit-title
Until then the bug is still considered open and
new crashes with the same signature are ignored.
I just recently been using BATMAN-adv over ethernet
What other debug information are available to troubleshoot connection issues?
I have enabled for OpenWRT
echo "CONFIG_BATMAN_ADV_DEBUG=y" >> .config
echo "CONFIG_BATMAN_ADV_DEBUGFS=y" >> .config
echo "CONFIG_BATMAN_ADV_BLA=y" >> .config
echo "CONFIG_BATMAN_ADV_DAT=y" >> .config
echo "CONFIG_BATMAN_ADV_MCAST=y" >> .config
echo "CONFIG_BATMAN_ADV_NC=n" >> .config
echo "CONFIG_BATMAN_ADV_BATMAN_V=y" >> .config
echo "CONFIG_BATMAN_ADV_SYSFS=y" >> .config
echo "CONFIG_BATMAN_ADV_TRACING=y" >> .config
echo 255 > /sys/class/net/bat0/mesh/log_level
since i want to understand also why on wifi mesh seems to crash for me ath10k
On Wednesday, 24 June 2020 21:23:09 CEST Rob Cowart wrote:
> I have another question regarding batman, is there a way to connect to the nodes using only batman?
batman-adv doesn't have any special TCP like protocol or remote shell access
protocol. But you can either try to find the neighbors using link local IPv6
and directly use this to connect to the remote:
And if you see a couple of dups like this:
$ ping ff02::1%wlan0
PING ff02::1%wlan0 (ff02::1%22): 56 data bytes
64 bytes from fe80::84ec:1cff:fea1:5629: seq=0 ttl=64 time=1.211 ms
64 bytes from fe80::6c39:baff:fe1c:6d11: seq=0 ttl=64 time=7.107 ms (DUP!)
then you can just ssh to this node over IPv6 link local like this:
Just make sure that you are actually add the interface name + "%" separator.
> We have a situation where we've deployed batman V / alfred mesh networks (in several factories in Mexico, US and China) and then found dnsmasq is not up to the task of keeping our ips straight (with 20-30 nodes per mesh even) over months and years. So we're trying to remotely change them all to static, but midway through the mesh (or whatever part of the mesh lets us ssh to the nodes) breaks down. The nodes still show on batctl
> pi@raspberrypi:~ $ sudo batctl n
> [B.A.T.M.A.N. adv 2018.4-23-g89ba2134-dirty, MainIF/MAC: wlan0/b8:27:eb:fb:4e:58 (bat0/d6:86:8d:7d:39:4d BATMAN_V)]
> IF Neighbor last-seen
> b8:27:eb:4e:73:6d 25.330s ( 1.0) [ wlan0]
> b8:27:eb:ff:0e:b6 23.320s ( 1.0) [ wlan0]
> b8:27:eb:08:13:37 18.850s ( 1.0) [ wlan0]
> b8:27:eb:aa:1e:6d 37.010s ( 1.0) [ wlan0]
> b8:27:eb:35:c6:77 63.590s ( 1.0) [ wlan0]
> b8:27:eb:e9:34:41 18.280s ( 1.0) [ wlan0]
> b8:27:eb:84:ca:90 30.560s ( 1.0) [ wlan0]
> b8:27:eb:1e:eb:cd 27.410s ( 1.0) [ wlan0]
> b8:27:eb:cb:80:34 23.100s ( 1.0) [ wlan0]
Not sure what the ELP interval is here but the last seen is extremely high. I
would guess that the lower link actually broke down and the neighbor entries
just didn't time out yet.
> Also I was trying to figure out how to snoop what alfred is doing, since our MQTT goes over alfred over batman and that's what's not working...
There was a wireshark dissector written by some person . But it might need
some updating to get it working with newer wireshark versions.
> So if you started from scratch how would you architect, is there a way to use batman for everything?
But the combination mqtt with alfred sounds weird. Alfred just stores some
very simple "facts" and distributes it slowly through the network. But MQTT is
a messaging protocol and is often used for realtime message transport. So in
most situations you would skip alfred and just use mqtt over whatever network
you want. No special batman-adv stuff needed.