Batman-adv ethernet meshing

[p4u]

Currently, by default, lime-config do not use BAT-ADV in ethernet interfaces. So the expected behavior would be to have eth0.15 (for instance) which runs BAT-ADV, but this was removed in some point because there were supose to be problems with BAT-ADV.

I would like to review this issue and if it does not exist anymore enable again the bat-adv ethetrnet mesh.

[p4u]

Thinking loud: this current setup can also have some negative impact on the DHCP lease share.

Since the ethernet attached nodes are bridged and bat-adv does not know about this connection (not sending OGM packets over it), it might be a situation where ALFRED is not sharing correctly the DHCP leasse file over the bridged nodes thus there might be duplicated IP addresses on the network.

[egon0]

i'm heavily using batman-adv via ethernet on our freifunk jena mesh at the moment, i can't see any drawbacks, especially alfred seems to work like a charm. but we use a old batman-adv version (a patched 2013.4)... if we could make a branch with enabled batman-adv-lan-meshing i maybe could test it in the next days.

[dangowrt]

On Mon, Jul 25, 2016 at 05:02:53AM -0700, Micha Stöcker wrote:

i'm heavily using batman-adv via ethernet on our freifunk jena mesh at the moment, i can't see any drawbacks, especially alfred seems to work like a charm. but we use a old batman-adv version (a patched 2013.4)... if we could make a branch with enabled batman-adv-lan-meshing i maybe could test it in the next days.

it surely works if you only use batman-adv over ethernet. however,
as batman-adv adds some encapsulation overhead, that either harms
performance (fragmentation) or needs the device's on-board switch to
be able to handle MTU > 1500 properly, which is not the case for all
devices (I had problems e.g. with TL-W8970B having an Infenion
switch IC).
For that reason it makes more sense to run a bridge in one VLAN and
batman-adv in another VLAN. BLA should prevent loops, however, there is
a race-condition if both, batman-adv and the bridged VLAN share the
same physical media. This was discussed during battlemesh this year and
we were wondering if Simon or Linus already came up with a fix.

[ilario]

Batadv on ethernet was disabled in this commit.

[altergui]

alfred does not depend on batman-adv. It can run on a purely switched (bridged) network. It only propagates information over a link-local (broadcast domain). It doesn't care if that link-local involves batman-adv or not.

So, no, this doesn't have any impact on dnsmasq-lease-share.

The only real problem caused by this setup is the impossibity of solving loops caused by two ethernet cables connecting two different BATADV clouds (but that are, in fact, all the same link-local)
To solve this scenarios, yes, we should revert that commit and push OGMs over a vlan (so that batman can solve the loop); but not before the race condition I've observed is confirmed solved in upstream BATMAN-Adv.

In conclusion, this "issue" is blocked by an upstream bug, but is not affecting alfred or anything at all, only complex scenarios of ethernet connections

[p4u]

Daniel sent recently a mail regarding the OGM race condition to
BattleMesh and lime-dev mailing lists. Maybe we should forward the
conversation there.

On 30/07/16 14:37, Gui wrote:

alfred does not depend on batman-adv. It can run on a purely switched
(bridged) network. It only propagates information over a link-local
(broadcast domain). It doesn't care if that link-local involves
batman-adv or not.

So, no, this doesn't have any impact on dnsmasq-lease-share.

The only real problem caused by this setup is the impossibity of
solving loops caused by two ethernet cables connecting two different
BATADV clouds (but that are, in fact, all the same link-local)
To solve this scenarios, yes, we should revert that commit and push
OGMs over a vlan (so that batman can solve the loop); but not before
the race condition I've observed is confirmed solved in upstream
BATMAN-Adv.

In conclusion, this "issue" is blocked by an upstream bug, but is not
affecting alfred or anything at all, only complex scenarios of
ethernet connections

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#56 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABBo9qjfiYdU76dnEmeq0S4fSAV5cj3xks5qa0WngaJpZM4JSKBa.

[G10h4ck]

By the way you can enable batman-adv on ethernet using specific config section

https://github.com/libre-mesh/lime-packages/blob/develop/packages/lime-proto-batadv/src/batadv.lua#L48

[ilario]

Can we re-examine this issue please?

The original LibreMesh purpose was to use the layer 3 routing protocol (BMX* or Babeld) just on the frontier nodes between clouds within which there should be just layer 2 routing by BATMAN-adv. Inside these clouds, Batman-adv should be in charge of routing also on cable (as Babeld is not there for managing that).

According to the comments above, it was related to an upstream bug, that I hope has been fixed over the last 3 years (?).
To re-enable BATMAN-adv on ethernet seems enough to revert dd07aef

@G10h4ck @spiccinini @nicopace @gmarcos87 @altergui opinions?

[ilario]

On some devices (I saw this on a MediaTek-based router YouHua WR1200JS) we could have problems due to switches breaking 802.1ad packages, see https://forum.openwrt.org/t/mediatek-and-vlan-802-1ad-on-ethernet/42346

[dangowrt]

I suggest to speak batman-adv on br-lan while br-lan contains bat0. Sounds impossible?
We can filter batadv hardif traffic from leaving the bridge on bat0, just like we do for bmx6/7:

ebtables -t nat -A POSTROUTING -o bat0 -p 0x4305 -j DROP

batman-adv this, but it's removing a check in the kernel to make it working:

--- a/net/batman-adv/hard-interface.c	2020-05-06 02:52:32.074707331 +0100
+++ b/net/batman-adv/hard-interface.c	2020-06-02 15:31:04.482354880 +0100
@@ -192,10 +192,6 @@
 	if (net_dev->addr_len != ETH_ALEN)
 		return false;
 
-	/* no batman over batman */
-	if (batadv_is_on_batman_iface(net_dev))
-		return false;
-
 	return true;
 }

[ilario]

The fact that we should modify Batman-adv's kmod means that we should host a binary routing repository (and fork the source code one), right?
Could you explain why we need both br-lan inside bat0 and bat0 inside br-lan?

[G10h4ck]

Could you explain why we need both br-lan inside bat0 and bat0 inside br-lan?

Is not that we need both of them in, it is that we need bat0 to stay inside br-lan so clients packets get routed by batman-adv.

Because of that then we would need ebtables trick as @dangowrt suggests

It is interesting to test how it would perform in this setup, and if performances are good we could attempt to convince batman-adv folks remove that check or make it optional into next release

[nicopace]

Could you explain why we need both br-lan inside bat0 and bat0 inside br-lan?

Is not that we need both of them in, it is that we need bat0 to stay inside br-lan so clients packets get routed by batman-adv.

Because of that then we would need ebtables trick as @dangowrt suggests

It is interesting to test how it would perform in this setup, and if performances are good we could attempt to convince batman-adv folks remove that check or make it optional into next release

I think @altergui did some tests on the ebtables performance implications

[ilario]

Fixed in #726