ifconfig | less 
20202020202020
1 „Gefällt mir“
Ja, ifconfig war auch eher scherzhaft gemeint 
Geht mir mehr um die anderen Tools, die auf Interface-Basis arbeiten (z.B. daemons, iptables).
Also ich hab schon mit Systemen gearbeitet welche an die 400-500 Interfaces haben 
Dort gab es bis jetzt auch keine Probleme.
Kann der Tunneldigger auch IPv6? Ich habe es bis jetzt nur geschafft das er sich per IPv4 verbindet
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.
1 „Gefällt mir“
Was meinst du mit den Aussagen? Wir haben in dem up script die MTU statisch gesetzt.
Sobald auf der Bridge rebroudcasting ausgeschaltet ist? Verstehe ich nicht so ganz 
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?
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
1 „Gefällt mir“
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 
…