You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since #726, by default, ethernet interfaces are configured as batadv hardifs (on top of 802.1ad vlan) while also being in the bridge. It is possible to produce batman-in-batman loops if there is a node that does not have batadv configured on ethernet (like before #726). To do so, one needs to connect via ethernet the LAN-ports of a node with no batadv-on-ethernet and two other nodes. Additionally, the one with no batadv-on-ethernet is connected via wifi to the same batadv-mesh as one of the other two.
Here is how that works:
batadv in node B or C sends a broadcast frame, which is sent out with a 802.1ad tag on the ethernet interface.
The frame is received by node A on its ethernet interface.
node A has no batadv configured on ethernet, therefore no matching vlan interface on top of it. The tagged frame is forwarded into bat0.
batadv on node A treats the tagged batadv frame like every other broadcast frame and sends it, encapsulated in other batadv frames, over the mesh.
The frame is received by batdv on node B and sent by batadv over the ethernet hardif, because it knows that node C is there.
The frame is received by node A on its ethernet interface.
...
Note that node C is only there so that node B sends the broadcast frames out via ethernet. There may be other ways to create this kind of loops. Here is how such a frame looks like after a few cycles:
The original frame starts at 0x0080. It is a BATADV_IV_OGM-frame tagged with vid 67 (88a8 0043). That frame is inside of some layers of BATADV_BCAST frames and vlan tags. Here, node A has 02:58:47:4e:88:90. 02:db:d6:e9:07:cb is the address of eth0_67 of node B.
This should only happen if batman is configured on top of 802.1ad vlans. I should not happen with 802.1q vlan or without vlan. This is because batman normally drops batman frames on its soft interface, and it understands 802.1q tags. It does, however, not understand 802.1ad tags. So we are successfully hiding the batman frames from batman by putting a 802.1ad tag on it. See here: soft-interface.c#L217-L233 and here: soft-interface.c#L437-L451
While these loops should not occur in default configuration (unless there is a bug that leads to batadv not being configured on the lan port of DSA devices that have only a single LAN port), when it happens it is not at all obvious. So I propose to somehow prevent this from happening. One easy way to do that might be to add a bridge filter rule that filters on batadv ethertype.
The text was updated successfully, but these errors were encountered:
Wow, great research work!!!
The ideal solution could also be to make sure this situation never occurs :)
But the firewall rule sounds like a meaningful alternative solution to me! @G10h4ck@spiccinini@javierbrk@selankon opinions?
Since #726, by default, ethernet interfaces are configured as batadv hardifs (on top of 802.1ad vlan) while also being in the bridge. It is possible to produce batman-in-batman loops if there is a node that does not have batadv configured on ethernet (like before #726). To do so, one needs to connect via ethernet the LAN-ports of a node with no batadv-on-ethernet and two other nodes. Additionally, the one with no batadv-on-ethernet is connected via wifi to the same batadv-mesh as one of the other two.
Here is how that works:
Note that node C is only there so that node B sends the broadcast frames out via ethernet. There may be other ways to create this kind of loops. Here is how such a frame looks like after a few cycles:
The original frame starts at
0x0080
. It is aBATADV_IV_OGM
-frame tagged with vid 67 (88a8 0043
). That frame is inside of some layers ofBATADV_BCAST
frames and vlan tags. Here, node A has02:58:47:4e:88:90
.02:db:d6:e9:07:cb
is the address ofeth0_67
of node B.This should only happen if batman is configured on top of 802.1ad vlans. I should not happen with 802.1q vlan or without vlan. This is because batman normally drops batman frames on its soft interface, and it understands 802.1q tags. It does, however, not understand 802.1ad tags. So we are successfully hiding the batman frames from batman by putting a 802.1ad tag on it. See here: soft-interface.c#L217-L233 and here: soft-interface.c#L437-L451
While these loops should not occur in default configuration (unless there is a bug that leads to batadv not being configured on the lan port of DSA devices that have only a single LAN port), when it happens it is not at all obvious. So I propose to somehow prevent this from happening. One easy way to do that might be to add a bridge filter rule that filters on batadv ethertype.
The text was updated successfully, but these errors were encountered: