On wireless mesh interfaces, I believe the vlan subinterfaces for babeld
and batadv could simply be removed. I shouldn't be a problem to run both
batadv and babeld on the same mesh interface.
For wired interfaces, it is more complicated. When a switch port is
configured for node-to-node connection, i.e. it is not bridged in br-
lan, then the situation is the same as for wireless mesh interfaces. But
for ports that are configured for both node-to-node and node-to-user
connection, babeld would need to run on br-lan (since that's where the
untagged traffic goes). Then babeld would see every other node in the
subnet/mesh-cloud as direct neighbor (through bat0).
Maybe it wouldn't actually be that bad to have babeld see every other
node in the mesh-cloud as direct neighbor. Babeld would know which node
in the subnet is connected to the destination subnet and create
appropiate routes. batadv would then make sure the packets go the best
path to this node. I think this is the simplest way to combine L2 and L3
routing.
Only downside I can see with running babeld on br-lan is that babeld
doesn't know the actual metric of links that go through batadv. But this
only matters for large networks with multiple clouds. For example: Cloud
B is not connected to internet, then babeld might make suboptimal
decisions about whether from certain point in Cloud B it is better to
reach the internet via Cloud A
versus via Cloud C.
This gives me an idea what a future GSoC project could be: Take link
metrics from batadv and put them into babeld. Then the two could work
perfectly together.
On Saturday, 9 August 2025 20:41:52 Central European Summer Time Ilario
via LibreMesh wrote:
> Hi!
> One of the two GSoC project currently running is about simplifying
> LibreMesh, and one of the sub-projects is about allowing users to use
> Babeld on the plain network interfaces, not on dedicated virtual
> interfaces (VLAN) as is mandatory now.
> Agustin and Matteo are working on this :)
> https://projects.freifunk.net/#/projects?project=simplify_libremesh_an
> d_get_it_closer_to_openwrt
>
> And you can see their projects on Freifunk's blog:
> https://blog.freifunk.net/author/agustin-trachta/
>
> The question is: do we actually need to keep the option to use Babeld
> on VLAN interfaces, or can we just replace the support for Babeld on
> VLAN with Babeld on plain interfaces?
> I mean, if there is a usecase that requires using it on VLAN it's ok
> to keep them both, otherwise I would keep just the simplest that
> works.
>
> There is some more information on this at these links:
> https://github.com/libremesh/lime-packages/issues/581
> https://github.com/libremesh/lime-packages/pull/631
>
> Ciao!
> Ilario
