Schön wäre ja irgendwann einmal ein Gluon Paket für Raspberry Pi 2 und BananaPi samt artverwandten, die ganz offiziöslich AutoUpdates mitmachen. Als „MeshOnWan“ Offloader braucht es nicht einmal zusätzliche Schnittstellen oder VLAN Frickeleien. 
3 „Gefällt mir“
Kann ich wohl die Debian-Pakete aus der Anleitung auf ein Ubuntu schmeißen oder muss ich das alles neu kompilieren?
Kannst du!
Batman wird ohnehin jedesmal automatisch passend für deinen Kernel kompilliert
Und @wusel; es scheint wir verfolgen unterschiedliche Philosophien.
Du willst die Technik von den Leuten fernhalten, und ich möchte die Technik den Leuten näher bringen
Richtig. Nur zwischen gut 25 MBit/sec mit dem 1042v2/Archer c5 und einer 50/10- oder gar 100/40-VDSL2-Anbindung liegen leider Welten. Du kannst also zwischen Pest und Cholera wählen, ich wähle da Cholera, weil weniger ekelig (oder, konkret: Energie zu verbraten stört mich weniger als Bandbreite zu verschenken).
Der @pberndro hat folgendes in seiner Anleitung Freifunk.net Pad geschrieben:
# batman installieren
# Bitte keine offizielle Batman-Adv Version verwenden, Clients müssen die Optimierte Version aus dem Gluon Repo verwenden.
wget https://github.com/freifunk-gluon/batman-adv-legacy/archive/master.zip
Bis jetzt gibt es keinerlei belastbare Aussagen dazu, wie sich der RPi2 schlägt, aber, ich würde wetten, daß der auch bei VDSL50/10 mehr als ausreichend sein wird.
Aber auch darauf würde ich nicht 1:1 GLUON portieren wollen.
Mit den Ressourcen, die so ein System bietet geht das deutlich besser!
Sowas könnte ich mir schon eher als Massen-tauglichen Offloader vorstellen.
Autoupdate ist übrigens auch keine Erfindung der GLUON-Entwickler
Zudem ist die Performance der Clients derzeit scheinbar ohnehin das geringste Problem, und der Flaschenhals liegt eher bei den Supernodes.
Wird es? Bei mir taucht immer wieder ein v15-Modul auf, welches ich dann erst mühsam totschlagen, exzorzieren und durch v14 aus dkms ersetzen muß. „dkms --force install batman-adv/2013.4.0“ ist einmalig nicht ausreichend, mit jedem aktuellen Kernel kommt das falsche, in-kernel-, Modul zurück. In der Münsteraner Anleitung fehlt eine korrekte Behandlung von Pinning 
Ich will Technologie nicht zwingend fernhalten; ich will ein wartbares Netz. Jeder kann und darf machen, was er/sie/es möchte; am Ende des Tages sind ggf. eine Hand voll Bastelknoten disconnected, weil sie notwendige Änderungen nicht nachvollzogen haben — kann ich mit leben.
Konkret geht es aber hier um den (generischen) Aufbau von VPN-Offloadern. Jene benötigen die aktuelle Liste von fastd-Gateways. DAS muß automatisiert funktionieren, AUCH wenn wir in einer Woche von Port 10000 auf Port 53 schwenkten. Daher Gluon-VMs. Die bekommen das mit. (Okay, ob sie wirklich am Auto-Update partizipieren, weiß ich wohl erst morgen … Falls nicht, war auch das ein Griif ins Klo.)
Ja, leider…das ist noch etwas eklig, aber kompilliert wird es. 
Das kann man aber auch automatisieren.
Ich bin da dran.
Da bin ich ganz bei dir, aber das lässt sich durch ein eigenes Repo mit einem Paket für jede Domain leicht lösen, und die Updates kommen dann auch zeitnah.
Ich hatte nicht viel Zeit, meinen RPi2 mit OpenVPN zu streßtesten; bei ca. 600 KByte/sec von kernel.org sehe ich allerdings ca. 25% CPU-Last des OpenVPN-Prozesses, deutlich mehr als 2,4 MByte/sec erwarte ich daher vom RPi2 nicht. Sprich: VDSL50 lastet der eher nicht aus … (Hint: OpenVPN wie fastd sind single-threaded.)
Natürlich läßt sich mit beliebigem Aufwand jedes Problem irgendwie lösen. Wir haben für Gütersloh aber konkrete Nachfrage nach „gimme perfomace, lad!“, i. e. VPN-Offloading. Leider nicht nur einfach. Natürlich kann ich die Anfragen mit 1x 1043v2 je 25 MBit/sec-Downstream-Banbreite erschlagen; aber das ist eben nur die halbe Wahrheit.
Das kannst du nicht vergleichen!
fastd ist nicht openvpn!
Versuch macht kluch
1 „Gefällt mir“
Yepp, been there, did that — und die fastd-Performance liegt nicht über der von OpenVPN auf der gleichen Plattform.
Wenn die Gateways AES erlauben, müsste man mit aes128-gcm doch eigentlich was reißen können oder? Man braucht halt nur einen Client, der es kann.
Also laut den Fastd-Devs ist selbst AES mit Hardwarebeschleunigung nicht so schnell wie salsa2012+umac Egal ob große CPU oder nicht.
Die Crypto ist allerdings das kleinste Problem.
Fastd ist ein User-Space Daemon. D.h. es wird als Programm außerhalb des Linux Kernels ausgeführt.
Wenn jetzt ein Datenpaket von einer Node ankommt wird dieses vom Kernel-Space zum User-Space Program (Der Fastd Daemon) kopiert. Anschließend geht das gleiche Spiel in die andere Richtung weiter, um die Antwort vom Server an den Client zu verschicken.
Dies nennt man Context-Changes und diese sorgen für die geringe Datenrate, nicht die Crypto!
Gut 80~ % der Leistung der Plastik-Kisten geht hier verloren
2 „Gefällt mir“
Wir haben derzeit allem Anschein nach 2-3 Threads in denen entgegen anderslautender Titel es immer muter durcheinander geht zwischen
- „Gluon auf x86“
- „Gluon auf RasPi&Co“
- „Fastd manuell installiert auf RasPi&Co“
- „fastd manuell installiert auf x86 (vm oder BareMetal)“
Ich finde das etwas verwirrend.
Entweder wir werfen das in einen gemeinsamen „offloader“-Thread.
Oder wir ziehen es sauber auseinander…
2 „Gefällt mir“
Kann man das fixen? Gut wäre für x86 auch Multithreadding für fastd, das würde die Gateways wohl auch entlasten.
Mach einfach zwei mit dem Verweis hierauf dicht. In den älteren würde eh schon länger nicht mehr gepostet.
Hallo zusammen,
wollte nur mal nachfragen, ob es da einen Status gibt, und allgemein wissen, wie da die Planung ist. Arbeitet da überhaupt jemand aktiv dran, oder hat das innerhalb des Projektes eher so einen „Nice-to-have“-Status?
Gibt es einen Punkt wo man einsteigen kann, damit man bei eigenen Versuchen, nen Client „von Hand“ ans Rheinlandnetz dranzuklöppeln nicht bei Null anfangen muss?
Bei meinen aktuellen (sehr kleinen) Installationen habe ich das Gefühl, dass ich mit Erhöhung des VPN-Durchsatzes das Netz wesentlich flinker hinbekommen könnte. Insbesondere mit meiner neuen Nanostation Loco M2 komme ich zwar weit, aber der Seitenaufbau läuft doch wesentlich holpriger ab als bei meinen TP-Links (auch bei „vollen WLAN-Balken“).
Benchmarks der anderen Aachener stützen meine Vermutung, dass dies an der schwächeren CPU der Loco liegen könnte. Liege ich da überhaupt richtig, oder jage ich da nur Gespenstern hinterher?
Und da das Thema direkt auf ist: Gibt es bereits Kleincomputer a la Raspberry Pi, die AES (oder so) in Hardware können? Und kann man das VPN dann auch für einzelne Clients auf einen solchen Cipher umstellen eventuell? Falls nicht, ist das natürlich auch nicht schlimm, dann muss man halt Clients mit dickerer CPU nehmen (wäre bei meinen aktuellen Installationen auch kein Problem), aber wäre ja schon ganz praktisch 
Bitte das Thema nicht falsch verstehen, es soll sich natürlich niemand gehetzt fühlen wollte nur wissen, ob da überhaupt was läuft 
Gruß
David
Hallo David,
aktuell kann ich dir nicht sagen wie es mit der Gluon x86 Portierung ausschaut.
Aber ich wollte auch nochmal im IRC Channel fragen gehen wenn ich ein wenig Zeit finde.
Der BeagleBone Black hat ein bissle Crypto im Programm.
Wie ich gerade gesehen habe gibt es dafür auch noch zusätzlich eine Crypto Board als extension.
https://www.sparkfun.com/products/12773
Ob das für den FastD taugt weiss ich aber nicht.
Schau ich mir aber auch noch mal in einer ruhigen Minute an.
Gruß
Thomas
Ich vermute, das eine Distribution für Cubietruck, BananaPi o.ä. deutlich preiswerter „als Gesamtsystem“ ist.
Ob das mit Gluon gehen wird: Vermutlich wird „meshkit“ da schneller was liefern können.
1 „Gefällt mir“