BATMAN_V Routing -- On-prem Connectivity Loss Seen

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