Es gab updates für den Tunneldigger und demnach wurde das ffrl-packages Repository geupdated.
Außerdem ist ein neues Paket dazu gekommen „gluon-migrate-vpn“, dies ist ein Meta-Paket welches dazu verwendet wird um von Fastd zu Tunneldigger zu wechseln oder umgekehrt.
Dazu muss das Paket lediglich in der site.mk hinterlegt werden, sonst wird nichts benötigt.
Dies löst das Problem wenn Fastd aktiv war und nach dem Wechsel zu Tunneldigger kein VPN mehr aktiv ist.
Also V4 Adressen bekommen die Nodes gar nicht über das Mesh. Nodes selbst haben nur Ipv6.
Die Route die du dort gepostet hast ist vom Wan Interface (Ich nehme an eine Fritzbox dahinter, die nutzen auch 192.168.178.0/24).
Edit: Ich sehe gerade eure MTU ist 1492, das ist viel zu groß. Maximum sind etwa 1462. Besser aber man wählt etwas kleineres, z.b. 1312 (1280 ist das Minimum für Ipv6 und 32 Bytes wäre für den Batman Compat 15 Header)
Die local-node Route - ja. Wodurch wird diese gesetzt?
Leider fehlt diese komplett. Wo kann die MTU auf dem Router denn eingestellt werden, ohne jedesmal eine neue FW backen zu müssen…
Nein leider noch nicht wie @mattes es schon beschrieben hat.
Ich denke das es nachgeliefert wird, aber selbst via V4 sind die Tunnel performanter als Fastd via nativ V6
Übrigens habe ich ein Howto für das Broker Setup gemacht, basiert auf der Düsseldorfer Config. Habe gesehen das ihr euch da in Troisdorf etwas im Kreis dreht (Via Github).
Die Scripts die bei Tunneldigger dabei sind um die Interfaces zu verwalten sind nicht kompatible mit dem Gluon-Paket was ich gebastelt habe. Die Path-MTU discovery funktioniert zwar, aber Batman kommt damit nicht klar.
Zudem zerstört das bündeln der Interfaces in eine Bridge die Möglichkeit rebroadcasting abzuschalten welches den Downstream der Nodes schont und unötige Pakete auf dem VPN Link weiter reduziert.
Ah wenn die MTU statisch gesetzt ist dann ist es kein Problem, aber die Bridge muss halt noch weg ;). Daher am besten die original Interface Scripts in die Tonne hauen.
Splithorizon bzw „No Rebroadcast“ klappt nur wenn jeder Link als einzelnes Interface in bat0 hängt :).
No_rebroadcast sorgt dafür das die Pakete die empfangen werden nicht auf dem selben Interface repliziert werden.
Also nehmen wir an das Node A sich über VPN bemerkbar macht, dann würde in eurem Falle ein „Echo“ von dem Gateway kommen mit dem selben Paket. Dies macht natürlich überhaupt keinen Sinn und verschwendet kostbare Bandbreite auf dem VPN Link.
Da Fastd ähnlich wie die Bridge als nur ein Interface in bat0 hängt, ist es dort das selbe Problem. Alle Nodes werden über ein Interface gesehen und daher müssen die Pakete als Echo zurück geschickt werden da sonst die anderen Nodes nichts von dem Rest mitbekommen.
Bei Funk/Wifi ist das sinnvoll und würde auch ohne nicht funktionieren da die Funk-Verbindung ja ein shared Medium ist und natürlich kann eine weitere Node noch andere Nodes sehen. Daher muss das Paket erneut auf dem selben Interface repliziert werden.
Ah okay.
Wenn du mir dann jetzt noch sagst was ich auf dem Server machen muss, dann schließ ich dich in mein Abendgebet ein.
Der speed ist tatsächlich etwas träge. Mtu ist auf 1312 statisch gesetzt. Up Script habe ich von dir genommen. Wofür setzt du jeweils die mac in dem.Script?
Diese sollte nachwievor da sein, das Paket hat nichts damit zu tun.
20202020202020
Dort gab es bis jetzt auch keine Probleme.