ich betreibe seit einer Weile einen FFAC-Knoten, allerdings mit geliehener Hardware, da es nicht unbedingt einfach ist, ein passendes Modell mit der richtigen Hardware-Version zu finden, was von OpenWrt/Gluon unterstützt wird und für meine Zwecke nicht überdimensioniert ist.
Nun wollte ich die geliehene Hardware irgendwann auch mal wieder an den Eigentümer zurückgeben und im Rahmen dessen ist mir ein TP-Link Archer C6 v2 sehr günstig zugeflogen. Der wird zwar von Gluon unterstützt, aber erst ab 2020.1. Wie ich der FFAC-Siteconfig entnehme, sind die 2020er-Versionen mit den Aachener Servern nicht kompatibel - ich vermute mal, weil in 2020.1 der Support für batman v14 entfernt wurde, aber ich kenne die Netzstruktur und die Feinheiten als „dummer“ Node-Betreiber nicht so gut.
Ich vermute mal, v14 soll nicht ewig das Mittel der Wahl bleiben, und irgendwann sollen auch neuere Gluons verwendbar sein. Gibt es da schon Pläne? Könnt ihr noch Unterstützung gebrauchen? Ich hab ein gewisses Maß an Entwickler-Erfahrung und auch das eine oder andere in Richtung Netzwerken, allerdings eher nicht so im Backbone-Bereich.
Und wenn ich jetzt ganz abenteuerlustig behelfsweise in Gluon 2020.x Unterstützung für batman v14 reinfrickeln würde (sicher nicht meine erste Wahl, wenn schon was anderes geplant ist), kann ich dann halbwegs damit rechnen, dass ich mit dem Node ins FFAC-Netz reinkomme, oder ist das erst die Spitze des Eisbergs?
Wir haben tatsächlich damit angefangen neue Server für eine neue zu Gluon 2020.x und neuer passende Infrastruktur aufzusetzten.
Da ist allerdings noch einiges zu tun, bei Interesse kannst du dich dabei gerne einbringen, das wäre vermutlich spannender als die Portierung der alten Firmware auf die neue Hardware.
Wir treffen uns immer Dienstags in unserem Jitsi, zumindest solange es nicht möglich ist sich in einer Kneipe zu treffen:
Edit: Der Termin der in der Vorschau geladen wird ist nicht passend, beim klickt wird es aber korrekt angezeigt: 2. März 2021 um 19:30 – 21:00
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.
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.
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“. ?)
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
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.
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.
@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
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.
