Die Mac wird gesetzt damit die Map weiß das es sich um VPN Link handelt 
Der --vpn parameter vom Backend braucht ja statische Macs. Ansonsten sieht es aus wie ein Wifi-Link. Notwendig ist es nicht, ist halt eher kosmetisch.
Momentan fahre ich mit MTU 1364, damit habe ich etwas bessere Ergebnisse erziehlt. Jedoch kann die Trägheit auch mit einer Auslastung des Gateways zu tun haben.
Die MTU teste ich grade aus 
Das Geteway hat nur 3 Router derzeit, vom Gateway gehen Downloads mit ca. 120mbit/s durch.
Was meinst du mit der Bridge und was muss dafür getan werden?
Für den Bridge Ersatz kannst du die Scripts aus der Düsseldorfer Beispielconfig nehmen Schau einfach mal rein, sollte selbsterklärend sein
Meinst du diesen teil?
#!/bin/bash
INTERFACE="$3"
ip link set address 04:be:ef:25:00:01 dev $INTERFACE
ip link set dev $INTERFACE up mtu 1364
/usr/sbin/batctl if add $INTERFACE
echo "enabled" > /sys/devices/virtual/net/$INTERFACE/batman_adv/no_rebroadcastJa genau, das musst du natürlich noch anpassen. Die Mac sollte die selbe wie von Fastd sein.
Allerdings musst du auch einen aktuellen Kernel haben, die Mac-Address Änderung kam erst „kürzlich“ zum Kernel als Patch dazu.
Wir nutzen auf Debian Jessie den Backports Kernel 4.1.
Edit:
Hier der genaue Kernel Name:
linux-image-4.1.0-0.bpo.2-amd64 4.1.6-1~bpo8+1 amd64 Linux 4.1 for 64-bit PCs
Gibt es einen Plan für den Aktuellen master / 2015.2?
Ich habe gerade versucht den tunneldigger damit zu bauen, aber da ja gluon-simple-tc rausgeschmissen bzw. ersetzt wurde und gluon-config-mode-tunneldigger diesen aber vorraussetzt funzelt das natürlich nicht…
Sobald 2015.2 raus ist patche ich gerne das Paket 
Wir haben den Tunneldigger jetzt einfach aus dem Config Mode rausgelassen. In einer Experimental nutzt den eh keiner
Hi zusammen,
Wir nutzen für das FFRL-Packages Repo jetzt Releases, für Gluon 2015.1 habe ich bereits einen Release erstellt. Bitte nutzt die Commit-ID welche dem Release hinterlegt ist.
FFRL-Packages für Gluon 2015.1:
Hier wird immer wieder erwähnt, dass man das batman mit den gleichen Patches wie im Gluon benötigt. Ich nutze linux-image-4.2.0-0.bpo.1-amd64 auf einem lenny. Irgendwo habe ich mir schon mal raus gesucht, wie ich an die Patches komme und gebaut. Aktuell laufe ich mit dem Modul aus dem Paket.
Dank der Anleitung hier, läuft das mit dem l2tp (als Versuch) jetzt.
Da ist insbesondere der no_rebroadcast patch nicht drin. Finde ich irgendwo die Begründungen für die Patches? Was fange ich mir ohne patches ein?
Jo. Zumindest das mit dem no_rebroadcast habe ich jetzt gefunden. Split Horizon hätte ich gleich verstanden 
…
Also einfangen tust du dir dabei nichts, aber es erspart unnötige OGM pakete über den VPN Link
Ich habe übrigens deinen Pull-Request gesehen, allerdings ist der Master Branch nur für Entwicklerzwecke. Ähnlich wie bei Gluon selbst. Bitte nutze die Commit ID des Releases/Tag wenn du Gluon baust, der Master Branch ist schon für 2015.2
In diesem Fall:
0a8b47f6dbc175e61eb40a9a22b628a412b61599
Verstanden. Ich hab mich ins Bockshorn jagen lassen, weil ich für 2015.1.2 baue. Dass dann 2015.1 und die „.2“ ist halt nur ein im Zusammenhang unwesentlicher Patch. Funktioniert so viel besser. Danke für die Hinweise!
Gibt es eine möglichkeit den Tunneldigger auf Gluon per Default einzuschalten? In der site.conf?
Ja, schau mal hier in die Tunneldigger section.
https://github.com/Delta1977/Gluon-Site-Tdf/blob/master/site.conf
Das enabled = true in der Tunneldiggersection sollte eigentlich funktionieren , tut’s aber nicht!!
In der check_site.lua wird dieser boolsche Wert abgefragt ( need_boolean(‚tunneldigger_mesh_vpn.enabled‘, false) ,
das Upgrade-Script welches den Wert an UCI übergibt erwartet aber 0 oder 1
( enabled = site.tunneldigger_mesh_vpn.enabled and 1 or 0) .
Denke da wird der Fehler liegen.
Ich muss nochmal Fragen:
Bei uns gibt es immer wieder Kernel Panics wenn ein node eine Tunneldigger Verbindung beendet. Habt ihr das auch? Wenn nein habt ihr eine Idee warum unsere Server das machen?
Jup, hatten wir in Warendorf ganz extrem.
Mehr Infos aus erster Hand hat @paulinsche.
Ne, Warendorf ist zurück zu fastd gewechselt. Das Problem war wohl nachts zur Zeit der Zwangstrennungen extrem und die Server sind nicht richtig automatisch durchgestartet.