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
Carlos, thank you so much for your mesh networking guide!
I am using BATMAN_V (on OpenWrt 23.05.3) and I find it to be faster than BATMAN_IV. However, my network is very straightforward with four wifi connected routers, one with internet connection, so I am not really pushing the envelope!
Works perfectly for months without reboot.
If you ever update your guide for 23.05, I finally worked out that you cannot stop the dnsmasq process or the routers will randomly stop routing mesh traffic and will also lose all IP connectivity so they cannot be managed. Also, it is important to tick the "use default gateway" for lan on all the routers except the one with internet access so the routers use the correct VLAN for ntp and other things needing internet access.
Also, for my ASUS RT-AX53U and AX54 routers, any attempt to set the MTU completely bricks them and requires a system reset. However, using BATMAN_V, "batctl s" appears to show fragmentation as a minor issue.