Wir waren leider mit vielem beschäftig, tatsächlich auch damit einen Testserver fürs neue Gluon aufzusetzen.
Sonderlich weit sind wir damit jedoch nicht gekommen, vermutlich auch, weil wir bei der Gelgenheit gleich auf Wirequard umsteigen wollten.
Wir stellen gerne VMs bei uns auf der Infra zur Verfügung um ggf auch erstmal als parallel Infra Knoten mit aktueller Firmware/Hardware betreiben zu können.
Darf man fragen, warum?
Gluon mit L2TP ist ein erprobtes Setup; Gluon mit VXLAN via WireGuard ist neu…er.
In die Daten gucken darf(!) kein Transportanbieter.
Und das Freifunk-WLAN ist unverschlüsselt …
2-5 mal mehr Speed laut FF München wäre alleine ja schon Grund genug. Wenn man dann Verschlüsselung nach dem Stand der Technik on top bekommt mehr als genug Gründe.
Auch neu ist relativ: FF MUC macht das seit über einem Jahr.
Die braunschweiger Freifunker haben auch kürzlich den Produktivbetrieb von fast auf Wireguard umgestellt, jetzt läuft ein Gemisch aus Batman im lokalen Mesh und Wireguard zu den Gateways.
Der Geschwindigkeit hat es gut getan
Was hat das jetzt mit der Fragestellung „unterstützung für neue Geräte“ zu tun?
Weil 2-5 mal mehr Speed besser ist also 10 mal mehr Speed mit L2TP?
(oder geht’s nur darum, den Thread zu derailen? Oder einfach nur „warum neue Geräte unterstützen, wenn man doch erstmal eine andere Baustelle aufreissen kann, aus welchen Gründen auch immer“, getreu dem Motto „Lieber einen großen Schritt übermorgen als mehrere kleine gestern, heute und morgen“. ?)
Du hast nicht gelesen, was Wusel schrieben hat.
Gegenüber L2TP? Würde mich wundern, da beides im Kernel abgefrühstückt wird und bei L2TP nur eine Tunnelebene vorhanden ist. Kontext der Frage war ja, daß die Erneuerung in Aachen ‚hängt‘, weil der Umstieg auf neue Infrastruktur mit Umstieg auf VXLAN-über-wg verknüpft ist. Der Weg weg von fast zu L2TP hat $hier auch nur ein paar Jahre gedauert, zum Teil auch, weil weitgehende Automation des Deployments mit auf der Agenda stand.
Daher die ernstgemeinte Frage nach dem warum bzgl. WireGuard, wenn es doch sich als Hinderniss bei der Erneuerung der Infrastruktur herausstellt.
Ich habe nichts gegen den Ansatz, VXLAN auf WG zu satteln, um einen verschlüsselten, performanten Tunnel hinzubekommen. Es ist nur komplexer als notwendig – außer, man hat non-technical debt –, und an sich ist der Kram schon komplex genug 
Gibt ja auch in fastd v22 nun eine null@l2tp Methode. Damit wird es schneller und gleichzeitig ist kein großer Umbau erforderlich.
Aktuell ist der dafür notwendige Merge Request für Gluon noch nicht gemerged, aber im Testbetrieb läuft es:
Dem Merge steht auch meines Wissens nicht mehr wirklich etwas im Weg.
Auch wir in München haben immer „one change at a time“ gemacht. Unter Anderem deswegen gibt es wireguard-vxlan mit batman damit wir nicht von Batman weg müssen.
Jeder Change zu seiner Zeit und dann geht es. Wir haben durch dieses Verfahren alles von fastd auf wireguard an einem Tag umgestellt.
Achja, komplex ist es nicht mehr als l2tp ;). Vor allem nicht mit all der Software die wir opensourced haben.
Der Fred-Starter fragt, wie Chancen sind, aktuellere Geräte in seiner Heimat-Domain nutzen zu können, wann es z. B Firmware aus einem aktuellen gluon geben wird.
Und hier bekommt er jetzt eine Diskussion, wie man am sinnvollsten eine Domain von fastd zu wireguard statt fastd migriert oder ob L2TP nicht doch besser ist.
Ja, sorry, war allerdings nicht meine Intention … Anyway:
Und:
Ich verstehe das so, daß FFAC »neue« Infra für neueres Gluon zur Verfügung stellen würde. Wobei ich gerade nicht verstehe, warum es neuer Infra bedarf; Gluon v2019.2 ist sooo alt doch nicht? Außer, FFAC läuft noch auf batman-adv compat v14? Aber gerade dann wäre ein Umstieg von fastd/batman_v14 auf fastd/batman_v15 ›zweckmäßiger‹ als direkt ein Umstieg auf VXLAN-over-WireGuard/batman_v15 — just saying.
Wenn ich die aktuelle site.conf dort richtig lese, ist da noch das Mesh auf „ibss“ statt auf 11s, d.h. ohne „backports“ oder Tricks (für den Fall dass man nicht nur Hotspot-VPN-Freifunk macht, sondern Wifimesh wirklich benutzt): Da ist eine Migration notwendig, die geplant werden sollte.
tl;dr und insbesondere als Erklärung für die, die technisch nicht so tief drin stecken: es sind zwei, für den Einsatz modernerer Versionen zwingende, technische Neuerungen in Gluon nach, IIRC, 2018.x umzusetzen — Wechsel der WLAN-Meshtechnik und Wechsel der Version der »Layer-2-Emulation« batman-adv.
Letzteres bedeutet im Grunde nichts weiter als einen Neustart des Freifunknetzes auf einer grünen Wiese und ist, wenn man keine Knoten des alten Netzes dabei verlieren will, nicht ganz trivial. Der Wechsel des VPN-Protokolls hingegen ist optional — bietet sich aber klar an, wenn man eh’ alle Gateways neu machen muß.
Okay, das und auch noch mesh-batman-adv-14, uff. Das haben wir zweistufig vollzogen, erst Anfang 2019 von ibss auf 802.11s – das betrifft ›nur‹ die meshenden Knoten –, dann, Anfang 2021, Wechsel von v14 auf v15 und von fastd auf L2TP in einer FW — dafür braucht man wirklich eine zweite Infrastruktur, denn während man fastd und L2TP (oder VXLAN over WireGuard) auf den Gateways parallel fahren kann, geht das beim Kernelmodul batman-adv.ko nicht. Bei uns hat es sich u. a. dadurch verzögert, daß tecff-autoupdater-wifi-fallback (bzw. prinzipiell jedes *-autoupdater-wifi-fallback-Package, IIRC) nicht mehr funktionierte (siehe Thread), d. h. ein Knoten mit inkompatibler Firmware dauerhaft offline geblieben wäre. Nach dem Fix war der tiefgreifende FW-Wechsel aber angenehm fluffig.
Hallo zusammen,
ich hänge mich mal dran und würde gerne fragen, wie der Stand bezüglich einer aktuellen Firmware ist? Ich würde auch seit längerem gerne mal meine Freifunk-Installation erweitern, aber hab keine Lust dazu uralte Geräte neu zu kaufen, bzw die momentan empfohlene Hardware sagt mir wenig zu.
Anscheinend ist hier überhaupt keiner mehr aktiv.
@MrMM Ich würde euch empfehlen, die WireGuard Migration zu machen, nachdem ihr eine neue Firmware gebaut habt, wenn euch das sonst so sehr ausbremst.
Wenn ihr bei der Migration zu WireGuard Infrastruktur Hilfe oder Erfahrungen gebrauchen könnt, meldet euch gerne. Wir haben jetzt seit anderthalb Jahren einen erfolgreichen zweigleisigen Betrieb und bisher keine Knoten an die Migration verloren.
Das muss nicht notwendigerweise eine Hau-ruck Aktion sein, die auf Anhieb fehlerfrei ist.
Und andersherum @Skeptiker, wenn sich hier länger keiner meldet, das Bauen von neuer Firmware ist ein Aufwand von einem kleinen Nachmittag.
Und wenn Aachens Infrastruktur darin besticht - sagen wir beständig zu sein -, bau sie dir einmal selbst auf einem neuen Stand, nachdem du dir angesehen hast, welche Geräte dir in Gluons Portfolio aktuell gut gefallen 
https://gluon.readthedocs.io/en/latest/user/supported_devices.html
Das wäre wohl nicht das Problem, aber kann ich die dann in Aachen überhaupt betreiben? Ich meine da gab es ein Problem mit einem legacy Protokoll, dass in neueren Gluons nicht mehr mit drin ist.
Oh. Das müsste ich kurz nachsehen, sorry. Augenblick.
edit Gerade mal reingeguckt; neben nem 2019er Branch den die in der site haben, exisitiert auch einer für 2022.
Bin beim Lesen über @Djfe gestolpert, der seit deren v2022.1.13 signing Rechte hat.
Er engagiert sich zumindest gerade relativ viel in der Gluon-Repo. Im Zweifel kann der dir Handlungs-Empfehlungen zum aktuellen Stand Aachens Firmware geben.
edit und @fmaurer natürlich genauso.
Nice. Gerade gesehen, wie weit die mit der Supernodeseite zu WireGuard schon sind und dass sie unsere Hilfe nicht mehr brauchen, da sie sie schon längst genutzt haben
Hallo @Skeptiker,
sorry dass hier nicht geantwortet wurde, ich hatte bisher das Topic „Regio Aachen“ nicht in meinen Einstellungen abboniert.
Aktuell ist Wireguard beim FFAC noch die Test-Domain - kann aber gerne für Neuinstallation (und auch händisch aktualisiert für Updates bestehender) genutzt werden.
Aktuell nur unter ipv6 unter https://community-build.freifunk-aachen.de gibt es die Firmware.
Dort gibt es verschiedene Firmware-Stände:
Untereinander mesh v2021 allerdings mit v2022 - man kann also bestehende Wolken gesamt schon auf die neue Firmware-Version aktualisieren.
Allerdings wird daran immernoch mal wieder gewerkelt, über Feedback freuen wir uns jedoch immer.
In naher Zukunft werden wir das auch mal announcen und bestehende Experimental Geräte migrieren.
Ich hoffe, dass ich dir vorerst jedoch helfen konnte!
Update jetzt ist die Firmwareseite auch über IPv4 erreichbar
Wenn du dein Gerät dort nicht findest, aktiviere testweise den Haken für „nicht empfohlene Geräte“. Wir blenden Firmware für „broken“ devices standardmäßig aus.
Wir sind in Aachen aktuell auf anderes fokussiert gewesen und Support im Forum ging dabei regelmäßig etwas unter, leider. Ich versuch mich auch mal einzubringen, damit das in Zukunft wieder besser wird. An dieser Stelle danke @Aiyion.Prime, dass du uns auf den Post aufmerksam gemacht hast :).
Durch die Umstellung von Testdomain auf Hauptdomain, die bald ansteht, erwarte ich auch ein erhöhtes Supportaufkommen. Da ist es angebracht, hier aktiv erreichbar zu sein.
Wenn wir mal nicht reagieren, sind wir per Mail erreichbar unter kontakt@freifunk-aachen.de und technik@freifunk-aachen.de