Hi!
You can see here a set of changes related with this comment:
https://github.com/libremesh/lime-packages/pull/1210
The “VLAN-on-wlan” path has been removed and now runs Babel directly on the
base mesh interfaces.
As you said, when a port serves *both* node-to-node and node-to-user, Babel
has to run on br-lan (untagged lives there). But if bat0 is also a member
of br-lan and there’s a pitfall, Babel hellos that arrive via Batman-adv
pop out on bat0 and the linux bridge will flood them to the other ports of
br-lan.
Then what happens is that a neighbour (with no eth) hears that 'hello' and
concludes the sender is a direct wired neighbour with the same cost (96),
so in this changes what has been done is that Babel kept on br-lan and
added a small nftables guard that runs at *netdev/ingress* on bat0 (only
focused on DSA for the moment, I do not have the hardware to implement
swconfig part).
El lun, 18 ago 2025 a las 12:49, pony via LibreMesh (<libremesh@???>)
escribió:
> 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
>
>
>
> --
> LibreMesh mailing list
> LibreMesh@???
> https://www.autistici.org/mailman/listinfo/libremesh
>
