Sehe ich das richtig, dass man bei Anpassung der Community nur auf die Peers achten sollte?
Ich würde gerne fertige images für Einplatinencomputer wie Rpi oder BananaPi bauen wollen und die zur Verfügung stellen, damit nicht jeder durch diesen „Horror“ muss 
Klar gibt es im Nachinein Kleinigkeiten die angepasst werden müssen (aber das ist erstmal Nebensache)
Für einen Kurzschluss kommt natürlich entweder Mumble oder IRC in Frage…
Das würde ich SEHR begrüßen.
Du solltest Dir aber darüber im Klaren sein, dass Du damit ein „Gluon light“ baust… Und es hoffentlich in 5-8 Monaten obsolet sein wird beim übernächsten Gluon-Release, wenn BananaPi&Co nativ von Openwrt mit einem Release unterstützt wird.
(Alternativ könntest Du einen Openwrt-Backport in BarrierBreaker machen für BananPi, dann wäre es auch gelöst… Was halt einfacher ist.)
ohne Gluon. Es geht auch einfach mit Debian. Ich bin als Mediengestalter nur begrenzt technisch versiert und bräuchte da Unterstützung. Debian ist mir jetzt nich unbekannt und kann ganz gut mit der Kommandozeile. Deshalb kam mir die Anleitung von @DerTrickreiche sehr entgegen. Würde das gern mal zusammen mit anderen per shared-screen optimieren wollen. Dass Updates sein müssen ist denke ich mal klar.
Aber erstmal interessiert mich die generelle Machbarkeit. Ob das dann Mehrwert hat → zweite Frage…
Ich kenne eine Reihe Leute die es machen oder gemacht haben. Weiß aber auch, dass sie zeitlich eng angebunden sind…
Deshalb ärgert es mich umsomehr, dass es keine oder nur wenig Dokumentation dazu gibt… so bin ich drauf angeweisen anderen Leuten wieder auf den S… zu gehen.
Alleinstellungsmerkmale in Sachen Skill helfen dem Projekt Freifunk nicht…
Für @MPW passt das 100%ig, da die Doku von seiner Heimat-Community stammt.
Ich hatte beim ersten Mal was von Gateway gelesen. Aber es wird ja auch ein virtueller Client behandelt.
Welche Virtualisierungsoftware sollte ich nehmen? Hab bisher nur mit Vbox gearbeitet. Kann KVM sowas oder muss ich VBOX nehmen? (Das zickt leider oft bei Kernelupgrades.)
Würde dann virtuell wohl einfach Debian nehmen.
KVM ist am besten geeignet; hat auch keine Probleme mit Kernelmodulen und so.
Nein. Default ist tatsächlich „Gateway off“. Batman schickt so DHCP Discover Pakete unverändert als Broadcast durchs Netz.
Aber schön, wenn du es ans Laufen bekommen hast. 
VPN auf x86 läuft hier jetzt im produktiven Testbetrieb (Knotenname: Aegidiistrasse-nur-VPN-kein-WLAN). Dank @anon75826926 sind die notwendigen Netzwerktreiber für die VBox jetzt im Image und man muss nur noch Gluon-Master mit den Community-Einstellungen und GLUON_TARGET=x86-generic kompilieren und erhält ein fertiges VirtualBox-Image.
Die Performance ist hier in Münster ~20 Mbit/s ↓ und 5 Mbit/s ↑ an einer VDSL25-Leitung getestet auf einem i7-2600K. Also der Upload wird voll genutzt, wo die 5 Mbit/s im Download verloren gegangen sind, keine Ahnung. Da noch parallel 5 andere Clients an dem selben Router hingen ein absolut guter Wert.
Mein WR841N schafft leider trotz dem optimierten fastd hier immer nur so 8 Mbit/s von daher auf jeden Fall eine ordentliche Verbesserung.
Was mich noch ein bisschen stört ist, dass der Host, wenn die VBox auf dem NAS läuft, immer ~10-18 % CPU-Auslastung hat auch wenn der Client zu 99% idled. CPU ist dort ein J1800. Evtl. kann KVM das besser als VBox.
D. h. man braucht 'nen aktuellen Master von Gluon und hinten fällt dann ein Virtual-Box-Image raus?
Genau. Allerdings werde ich wohl nochmal probieren auf kvm umzustellen, denn VirtualBox hat einen ziemlich hohen Performanceverlust bei der Virtualisierung. Laut Benchmarks ist kvm rund 1/3 schneller.
/edit: KVM läuft jetzt auch. Vor dem ersten Start muss der Festplattencontroller auf IDE gestellt werden und das Netzwerkinterface auf e1000. Das geht im virt-manager nur, wenn man auf „Einstellungen von der Installation ändern“ klickt, sonst wird das Image direkt gestartet und ist dann verbrannt.
Leider ist die Performance auf meinem J1800 bescheiden. Libvirt braucht eher noch mehr Idle-Time (~5,5% libvirt + 13-15% qemu) und der Durchsatz schwankt sehr stark zwischen 3 und 12 Mbit/s. Ich weiß nicht, ob das Netz hier gerade lahmt oder ob die CPU einfach zu lahm ist. Wenn es an der CPU liegt, lohnt es demnach auch definitiv nicht auf Pi oder Bananas zu setzen.
Komisch ist, dass weder der Host noch der Client bei einem Speedtest irgendwo auf 100% fahren. Die Frage ist, ob es was bringt AES zu virtualisieren und man dadurch den Durchsatz steigern kann.
Weiß jemand welche Prozessoreigenschaften man in KVM aktivieren sollte?
[quote=„MPW, post:28, topic:3042“]
GLUON_TARGET=x86-generic[/quote]
's baut grade. Lt. x86-kvm_guest: remove unneeded image types from OpenWrt config · freifunk-gluon/gluon@dd29ac3 · GitHub würde ich ja sagen, es wird gar kein vdi-Image mehr erzeugt? Dafür sollte https://github.com/freifunk-gluon/gluon/commit/bad4288b904e26f2a48d2474e6931ed04af984f1das Target x86-kvm_guest bereitstellen?
Zum Thema „Bremsen in der Technik“ gab es bereits einen Artikel, der möglicherweise in die Richtung weist, in die Entwickler arbeiten sollten, um Fastd in Virtualisierungsumgebungen zu beschleunigen.
https://forum.freifunk.net/t/gluon-fur-x86-nicht-router-wg-mehr-vpn-durchsatz/706/29
Doch, das _guest ist glaub für den virtio-Netzwerktreiber oder so, weil da iwelche Anpassungen nötig waren.
Ah, das wird es sein. Da kann ich leider nichts zu beitragen. Das erklärt jedenfalls, warum laut top noch Luft ist, aber nicht mehr ankommt.
Da mein J1800 gar kein AES kann ist hier wohl Ende.
/edit: Glaub nativ kann ich es auch nicht wirklich laufen lassen, da ich auf der neuen Hardware nicht so gut die alten Kernel fahren kann. Und ist mir auch zu frickelig das alles zu bauen.
Das ist unter debian gar nix Wildes.
https://freifunk-muenster.de/wiki/doku.php?id=technik:virtualclient
GLUON 1:1 auf X86-Hardware zu übertragen ist imho der falsche Weg.
GLUON basiert auf OpenWRT, und die X86-Images sind eher für Entwickler gedacht, um Funktionen in einer VM schnell testen zu könne, ohne jedesmal erst flashen zu müssen.
UCI als „Registry für Arme“ ist auf Embedded-Sevices sicher ein genialer Schachzug, aber auf X86 eher hinderlich.
Das Selbe gilt für uclibs und busybox…etc.
Wenn man eine solide debian-Installation hat, kann man das auch auf anderen Maschinen „nebenbei“ mitlaufen lassen.
M.M.n. sollte man sich lieber darauf konzentrieren.
Ja gut, ich hab Ubuntu statt Debian. Problem ist, dass man wohl keinen zu neuen Kernel fahren darf, weil sonst das falsche Batman drin ist.
/edit: Das Kernelmodul kann man ja scheints tauschen. Werde das Mal testen, vllt. geht dann noch mehr.
Nein, das ist nicht wirklich ein Problem, da es für das passende Batman ein dkms-Paket gibt.
Nach Gesprächen mit den Paderborner Kollegen glaube ich nicht, daß gmac oder umac von AES profitierten; das mögen fastd-Adepten klären.
Da VirtualBox ja deutlich mehr Performance aus der VM rauskitzelt als KVM, dürfte das Problem ein emulatorisches sein. Vielleicht weiß ich bald endlich mehr:
make[1] images
make[2] image/GENERIC
make[2] image/VMDK
make[2] image/VDI
Getting there …
Sehe ich anders. Denn wenn wir Offloader einfach als (andere) Knoten in das Auto-Update packen können, ist viel mehr gewonnen als wenn wir a) Access und b) Know-How für all diese Kisten brauchten.
Unsere Gateways erlauben auch aes128-gcm.
Nein, die besseren Werte waren mit einem i7-2600K, der spielt in einer ganz anderen Liga. Die Werte von VBox und KVM auf dem J1800 waren ungefähr gleich beschissen wobei KVM noch mehr im Idle schluckt.
Unter der Prämisse ist ein X86-System einfach die falsche Hardware - völlig überdimensioniert.