I've just tried out running batman-adv over 802.11s (unrouted) mesh as an alternative to trunking VLANs over L2 GRE tunnels. When running the BATMAN_V routing option, I see:
Relatively long times until a host is found by ping or the like (3-5 seconds)
Loss of connectivity even once established
sudo batctl o does show the nodes "checking in" within the expected 1-second period.
I strongly believe that the mesh connectivity is good, as I can quickly connect over a parallel (routed) 802.11s mesh on the same radios.
Switching back to the default BATMAN_IV routing protocol seems to have much better results, with the initial ping generally returned, or, at worst the second.
/etc/config/batman-adv is default
Is this a "known issue" with BATMAN_V?
Edit: The "discovery" process, while better with BATMAN_IV, seems to be unreliable, especially from wired hosts to on-mesh hosts. It "feels like" it is poor for "quiet" interfaces, such as those on my management VLAN.
config interface 'nwi_mesh1'
option ifname 'mesh1'
option mtu '1532'
option proto 'batadv'
# option routing_algo 'BATMAN_V'
option mesh 'bat0'
Hi @jeff, I know it's been a while since you last logged in but I was wondering if your experience with the BATMAN_V routing algorithm has changed since this post. The reason why I'm asking (and necroing this post) is that this very post is currently linked on the OpenWrt Wiki - batman-adv as an example of BATMAN_V unreliability (see bottom of the associate batman-adv with mesh section).
However, I've been using BATMAN_V for the past two months using the current stable (21.02) and both ath10k and ath9k modules without any issues whatsoever. I'm trying to re-organize the wiki to make it compatible with the current stable and per the comments at the bottom of the batman-adv- options for bat0 section, it might be a good opportunity to use the latest (throughput-based) algorithm in the examples.
(If anyone else who has experience with the BATMAN_V routing algorithm reads this message, please feel free to chime in.)
This is my scenario. With BATMAN_V I fixed the best route. Same configuration, switched routing algorithm:
With BATMAN_IV
root@openwrt3:~# batctl tr openwrt1
traceroute to openwrt1 (xx:xx:xx:xx), 50 hops max, 20 byte packets
1: openwrt1 (xx:xx:xx:xx) 1.895 ms 2.121 ms 1.507 ms
With BATMAN_V
root@openwrt1:~# batctl traceroute openwrt3
traceroute to openwrt3 (ec:08:6b:f9:1c:b3), 50 hops max, 20 byte packets
1: openwrt2 (18:d6:c7:86:82:2f) 2.969 ms 2.679 ms 1.593 ms
2: openwrt3 (ec:08:6b:f9:1c:b3) 4.265 ms 4.308 ms 6.169 ms
The right way now is openwrt3 -> openwrt2 -> openwrt1 and not openwrt3 -> openwrt1