Open-Mesh » batman-adv

Multicast messages (icmpv6 RA, icmpv6 RS,... as well as broadcast for the IPv4 (ARP) are broadcasted on layer 2 (MAC-Address bit 0 set to 1).
For the case we have two or more GW the layer 2 broadcast received on an interface attached to bat0 to the other interfaces. This is basically correct.

On my test System each RA,RS, ARP and so on which arrive at the VPN interface are send back to the gateway. This occur also for a normal Freifunk router.

The problem seem for me to be the recognition of a direct neighbors.

On a normal node this seem to work well. IPv6 Messages send to a broadcast address via respond reach only the direct neighbors.

If two or more gateways are connected with a tunnel attached to the same bat interface as the vpn connection for the nodes, the tunnel is recognized on the node as neighbor.
The following shall explain this
<-vpn-> bat0-on- gw2 <-tunnel-> bat0-on-gw1 <-vpn-> node1 <-mesh-> node2 <-mesh-> node3

node2 will report that node1 and node 3 are neighbors, this is OK.
node1 report that the neighbors are tunnel-to-gw2 (wrong) and node2 (OK). GW2 may be considered to be a neighbors but it act as gateway and is handled in an other way.

If I have a look to the batadv.bcast.ttl I have tree different value
If the message is send by the correct gw the ttl was 49.
broadcast originated by the 2. gw had ttl 48.

The message was send from the node to the other neighbors with a ttl of 48 or 47 according to the ttl from the incoming message.

GW1 (ttl=49) -> NODE (ttl=48) -> GW2
GW2 (ttl=48) -> NODE (ttl=47) -> GW1

The only connection for the node what the vpn connection to GW1

      GW
     BAT0
    |    |
    V    V
    P    P
    N    N
    |    |
    |    V
    |    P
    |    N
    |    +-BAT0 Node_3 Neighbor: -, GW: GW
    V
    P
    N
    |  
    +-BAT0 Node_1 Neighbor: Node_2, GW: GW
    M
    E
    S
    H
    |    
    |
    M
    E
    S
    H
    +-BAT0 Node_2 Neighbor: Node_1 GW: via Node_1

This shall represent what I expect if bat0 has more as one tunnel. I was not able to test this.

If Node_3 is a GW it will appear as neighbor with the MAC of the tunnel GW-to-GW to Node_1 and act also as regular GW with the correct GW-MAC. This is wrong.

Hi Jean-Jacques,

Before you go into details of your setup. What is the nature of problem? Packetloss? Or too many broadcast packets?

Then:

"This occur also for a normal Freifunk router." -> what firmware exactly? A Gluon one? Which firmware version? Which Freifunk community?

"On my test System [...]" -> So that's supposed to be a simple node, not a gateway node, right? And this is the one with just one neighbor on its VPN interface (which is a gateway / VPN server)?

My current guess is that you are wondering why there is a rebroadcast towards on a simple node back to its gateway?

Rebroadcasting a multicast/broadcast packet on an incoming interface is the current behavior of a vanilla batman-adv and necessary in many, typical topologies.

Gluon has this extra patch to toggle this behaviour per interface:

https://github.com/freifunk-gluon/gluon/blob/master/patches/packages/routing/0002-batman-adv-introduce-no_rebroadcast-option.patch

You might also want to try this automatic approach/detection which was not part of a batman-adv release yet: https://git.open-mesh.org/batman-adv.git/commit/a00797d8fa8fd1471e8be1ac23d506f76d866aaa

(if this is what you mean, I'm still not sure :D)

Mit andere Worte, das Problem ist nicht direkt Broadcast, Multicast oder Unicast.
Die Nachbarn werden nicht richtig verwaltet wenn ein Gateway mit ein anderen Gateway verbunden ist. Ob dies auch so bei der Verwendung von mehreren VPN Anschlüssen an ein GW (p2pt oder fastd) kann ich nicht ohne weiteres testen.
Ein Tunnel zwischen verschiedene Gateways ist im Sinne des Ausfalls von Vorteil und wenn alle Alles Systeme eine gemeinsamer Präfix teilen, mehr als Sinnvoll.

Das Problem liegt daran dass Broadcast von eine Node, über das ankommenden Interface an weitere (vermeintliche in dem Fall) Nachbarn der Broadcast weiter geleitet wird.

Die Clients sehen davon nicht viel, über das Wifi-Mesh Interface ist der Verkehr sicherlich vorhanden und reduziert unnötig die zur Verfügung stehende Bandbreite.

The community is Freifunk-Suedpfalz.
We use gluon-v2016.1.5

My Test system is a PC with a FF-Router configuration working within a network space.
The only connection what via the fastd tunnel to one of our gateway.
The configuration correspond the the configuration on our normal gluon router.
The behavior what also found on a normal gluon router attached to my pc which
what configured as normal router.

Rebroadcasting via the incoming interface seemed me not to be very useful and I can't imagine for which topologie this shall be necessary.

The original problem has to to with router advertisement. but while looking at the wireshark record I have seen that all multicasts message are rebroacasted.

This increase the traffic for broadcast which is seen by our gateways. One outgoing broadcast will result to more as 400 broadcast which will send back and reach the gateways. If I only consider RA and RS, there are a lot of message. My record with a duration of 5 minutes showed 306 RA (the half incoming the rest outgoing). The number of RS what about 409. The gateway had to process much more 12000 - 16000 within this period.

The option mesh_no_rebroadcast what not known to me. I will test this at least on my PC, but I use 2016.4!

@Jean-Jacques: Can you join #batman on IRC/Freenode-server?

Might be easier to discuss there.