Jedes Mal wenn wir ports ändern verlieren wir zweistellig Knoten, weil es trotzt aller Warnungen gerade in unseren Kreisen viele „Aluhüte“ gibt, die ihre opnsense&co zunageln und dann aber auch nicht mitbekommen, wenn ihr Knoten offline geht, weil sie selbst ff nicht als User nützen daheim.
Ob es um solche User/Knoten schade ist oder nicht: zweifelhaft.
Sorgt aber dafür, dass wir keine BreakingChanges mögen. (abgesehen von den „Vollalu“-Knoten mit deaktivieren Autoupdater und deaktiviertem Reapondd, die wir nur in den Batman Tabellen und den L2TP-if-Liste sehen. evtl sind das auch selbstaufgesetzte Systeme ohne Gluon)
Nunja, Änderungen kann man als Maintainer machen, man mag auch gute Gründe vorzuweisen glauben mögen — ob die Schafherde folgt, ist dann noch immer nicht ausgemacht. Siehe VXLAN, siehe ff05::2:1001 … Das ist dann die angenehmere Seite von Open Source: was Dir total gegen den Strich geht, kannst Du – some skills required – notfalls rauspatchen.
1 „Gefällt mir“
Namentlich 2023.2, was, nachdem OpenWrt 23.05 endlich draußen ist, und hinsichtlich des Kalenders, irgendwann im November/Dezember ansteht. Sprich: nach dem Jahreswechsel haben »Tunneldigger-Communities« ein neues Problem an der Backe.
Daß fastd mit »null@l2tp« identische Werte über einen IPv4-Transport erreicht wie ein Tunneldigger-Setup, dazu liegen AFAICS keine »Fakten« vor.
Unbestreitbarer Fakt allerdings ist, daß für eine fastd-Gegenstelle vorab ein Key in der Firmware hinterlegt sein muß — kann man als positives Feature werten, muß man aber nicht.
Aber damit sammelte ich zumindest Fleiß-Herzchen von meiner Aluhut-Fraktion — null@l2tp ist hingegen nur Tunneldigger in anders und damit genauso »unsicher«; das goutiert niemand.
Letztlich ist das Thema aber für uns auch durch. Wir forken das letzte Gluon-mit-Tunneldigger-Release und gucken dann mal alle 1-2 OpenWrt-Releases, ob der Überbau noch tut oder welchen Änderungen es bedarfs — back to the roots!
aprospos, schon wieder ein Problem mit tunneldigger:
Das ist aber imho ein known issue/works as designed seit jeher. Ist mir vor ein paar Monaten auch aufgefallen – ich konfiguriere i. d. R. Mesh-VPN aktiv, auch für als Mesh-only geplante Knoten – und wollte bei Gelegenheit daher Mesh-VPN in Abhängigkeit vom Link-State ggf. de- und reaktivieren. Auf 'nem DAP X1860 ohne WAN-Uplink führt das zu 'ner Standard-Load von 0,3-0,5 unter OpenWrt 22.03/Gluon 2022.1.4+:
Mit verbundenem WAN ist der Load-Graph auch deutlich über Null …
EDIT: im Logauszug steht nix von tunneldigger-watchdog … falsche Fährte?
1 „Gefällt mir“
Das ist nicht neu, leider schon immer so, Geräte mit schwächlicher CPU (archer C6v2 z. B.) macht das nahezu unbenutzbar. Die ständigen network/fw reloads bei jedem „Anwahlversuch“ sorgen für load gröesser 2.
daher ja auch tunneldigger watchdog-forks in den Communities.
1 „Gefällt mir“
Seit Jahren fahren die Freifunk-Rhein-Sieg e.V. Hoods Tunneldigger Protokoll.
Community Map und nein, das Mismatch zwischen Nodes und Nodes onlie ist kein Bug - wir haben die ubiquity mit Stock FW in der Map.
Bei einer Umstellung des VPN-Protokolles wären nicht nur neue Firmware zu bauen, sondern auf 6 produktiven VMs mit multidomain-Setup wäre die Infrastruktur abzuändern.
Weiterhin würden die in Betrieb befindlichen abgekündigten 4/32er Freifunk-Nodes mit ihrer alten Firmware offline gehen.
Eine Umstellung bringt als Fazit also:
- Invest von zusätzlicher ehrenamtlicher Arbeit an Firmware/Infrastruktur
- keinen erhöhten Datendurchsatz
- erschwertes Debugging bei Einwahl-Fehlern
- Verlust von Nodes mit alter Firmware, die aus dem Support gefallen sind
- Verlassen einer Architektur, die seit 2015 stabil durchläuft
Die Community-Personaldecke bei den ehrenamtlichen Systemadmins ist eh hauchdünn bis gar nicht mehr vorhanden. Die Alternative bei Abkündigung von Tunneldigger im gluon wäre, die vorhandenen Systeme mit eingefrorener Firmware einfach weiterlaufen zu lassen Wenn ich in die Firmwaredownloads mancher Communities schaue, machen die das oft eh schon mangels Leuten, die neue Images bauen. Geschweige denn, Freifunk Aktivisten die neu gebaute Firmware auch gründlich vor dem Rollout durchtesten.
Ich habe selten so eine problematische Gluon Version wie die 2023.1 gesehen - ungetestete Änderungen, die in ein stable release gehen. Die stable-3.8.3 für RSK liegt zwar auf dem Updateserver, ist aber nicht für den Rollout signiert, weil sie auf der gleichen Hardware unterschiedliche Disfunktionalitäten gezeigt hat - wie bislang bei keinem der vorigen Testbetrieben.
Fehler beim Tunneldigger, Übernahme der DHCP-Nameserver in die DNS-Auflösung klappte nicht, ar-150 brauchte nach dem update einen powercycle, um wieder hoch zu kommen …
Die Tunneldigger-Geschichte habe ich gemeldet - alles andere muss erstmal unter gleichen Bedingunen reproduzierbar werden.
Das Brett wird immer dünner, auf dem man da tanzen soll - macht langsam keinen Spass mehr.
2 „Gefällt mir“
Moin!
Hierzu sei auf
verwiesen — eine Tatsache, die mir vorher nicht bekannt war. Daß so ein Setup mindestens auf längere Sicht vor die Wand fährt, ist unausweichlich.
Da es vermutlich Gründe gibt, daß es so ist, wie es ist – Package-Development findet in Commuities ja offensichtlich statt, nur nicht im Rahmen der Gluon-Entwicklung –, lade ich Vertreter von TD-Communities ein, mir hier 'ne Nachricht zu schicken zwecks Besprechung der Zukunft von Tunneldigger/Gluon. (Discourse-Nachrichten können mehrere Empfänger enthalten, so läßt sich quasi eine Ad-Hoc-Mailingliste bilden. Ob man sich dann woanders neu formiert, kann man dann sehen.)
Naja, wie Du schon schriebst, mit dem Bau ist es ja nicht getan (und schon der erweist sich mir zunehmend als zeitraubend und frustrierend störanfällig); und in Planungen mit anderen Communities, sie »aus 2020 abzuholen« – dabei aber auf TD zu migrieren, denn zwei VPN-Services sind erfahrungsgemäß nicht »twice the fun«, sondern nur »double the trouble« – wirkt diese Entscheidung auch paralysierend.
Ich sag da mal etwas dramatisch: Das ist halt das Prinzip von EoL. Wenn es Änderungen gibt können da Sachen brechen. Wenn man sich davon aufhalten lässt bedeutet das ja effektiv das man kein EoL verkündet hat sondern ein „ab xy machen wir keine Änderungen mehr“.
Die Geräte sind mit v2022.1 aus Gluon entfernt worden, es ist jetzt noch nichteinmal das direkt darauf folgende Release und das brechen ist ja keine zwangsläufige Konsequenz darauf.
Denn einerseits ist es ja möglich Tunneldigger und fastd parrallel laufen zu lassen und wenn man das als Community nicht über „längere Zeit“ machen möchte wäre es ja sogar eine Option die alten Nodes ebenfalls auf fastd zu migrieren. Klar, das ist dann wohl eine „Verschlechterung“ und braucht vermutlich etwas mehr Resourcen auf Server Seite usw.
Aber bei den Low Traffic - Low User Nodes um die es dort gehen dürfte (die anderen wurden doch vermutlich eh schon ersetzt bzw. es „lohnt“ sich dort dann noch mehr es zu tun) vermutlich dann doch verschmerzbar.
Gluon wird ja von einer absurden Menge an Vollzeit Beschäftigter maintained … (IRONIE !!!)
Was du da forderst ist das andere Ehrenamtliche in ihrer Freizeit ohne eigenen Nutzen dauerhaft etwas für dich maintainen, testen usw. weil du nicht den einmaligen Aufwand in eine Migration stecken willst.
Die Probleme mit v2023.1 waren ja ein entscheidender Grund zu evaluieren ob tunneldigger im Gluon Core überhaupt noch Sinn macht.
Dabei spielte es sowohl eine Rolle das fastd mit null@l2tp ein Dienst zur Verfügung steht der anders als Tunneldigger IPv6 kann, deutlich regelmäßiger getestet ist und auch ohne einen anscheinend schlecht funktionierenden Watchdog auskommt. Aber ein Teilaspekt war eben auch zu überlegen ob eine Migration für die Communities (und wenigstens für aktuell supportete Nodes auch ohne wirkliche Einschränkungen bzw. sogar mit Verbesserungen) „möglich“ ist.
Und so richtig hat dem noch niemand widersprochen. Also abgesehen von „Argumenten“ die eher mal auf „keine Lust“ basieren.
Der Anspruch an ein Gluon Release und den Gluon Core ist ja eben das Sachen doch eigentlich funktionieren sollten. Wenn aber niemand Sachen testet (bzw. es ein Test Framework gibt das es regelmäßig automatisch prüft) dann ist der Gluon Core der falsche Ort für ein „redudantes“ Packet das, wenn man auf „der grünen Wiese“ nicht wählen würde.
Es zwingt ja auch niemand Communities nun von tunneldigger auf fastd mit null@l2tp umzusteigen. Das ist die Empfehlung und der „supportete“ Weg vorwärts, aber es ist ja trotzdem eine Option tunneldigger dann künftig anstatt als Core Package als Community Package einzubinden. Es braucht da auch keinen Gluon Fork usw. Aber es muss halt dann von denen die es nutzen wollen selbst maintained und getestet werden.
Und wenn ich hier lese das es sowieso schon Communities gibt die Teilaspekte verbessert haben, die Änderungen aber nie Upstream gelandet sind, dann macht es für die Interessenten doch nur noch mehr Sinn ein gebündeltes tunneldigger Packet zu bauen was sich dann in Gluon als Package einbinden lässt.
Dann wiederspreche ich hier mal deutlich. Fliegt Tunneldigger aus Gluon raus, schmeisse ich die Brocken einfach hin. ‚Nachwuchs‘-Schulungen habe ich bereits in der Community als Workshop gegeben - sollen andere sich damit rumschlagen. Ich werde mir persönlich den Aufriss mit strukturellem Umbau des Freifunks nicht geben.
»Der Verzicht auf eine Sprachausgabe ist unproblematisch, es gibt ja die Braillezeile als Alternative.«
Kurz: Entscheidungen wie diese sich mal flott zusammenzumumblen, ohne Vorankündigung und ohne Beteiligung Betroffener, ist eines der Dinge, die mich von engerer Interaktion mit »den Gluon-Maintainern« abhalten.
Ja, klar, alles ehrenamtlich, in jeder Individuums Freizeit — dennoch bezeichnet sich Gluon selbst als Firmware Framework: »Gluon is a firmware framework to build preconfigured OpenWrt images for public mesh networks.« Und von Maintainern eines Frameworks kann die darauf aufsetzende Nutzergruppe auch von Ehrenamtlern (d/m/w) mehr Einbeziehung in grundlegede Entscheidungen erwarten.
Dann hätte es gar nicht im Framework landen sollen — oder zumindest in den vergangenen Jahren mal – dort, wo die Nutzer sich tummeln, i. e. hier im Forum – mal klar kommuniziert werden sollen, daß alle Tunneldigger betreffenden Aspekte Gluons seitens der Gluon-Maintainer nicht getestet werden. Ich bin alt und vergeßlich, falls es so einen Hinweis/Aufruf hier gab, nähme ich das Gesagte nach Hinweis darauf natürlich bedauernd zurück.
Wenn die Interessen so dermaßen diametral auseinander laufen, wie es offensichtlich (und leider nicht nur scheinbar) der Fall ist – Tunneldigger ist ja nicht der erste Knatsch –, ist ein Fork die einzig konsequente Option. Die Frage ist nur, macht das jeder für sich oder tun sich ein paar Menschen zusammen.
Das mag der Upstream-Maintainer so sehen. Als zeitbeschränkter Ehrenamtler vor Ort ist es gleichwohl zielführender, gleich die Firmware als Ganzes in nur die Richtung weiterzuentwickeln, die man für richtig hält. Dann erfreulicherweise ohne die Friktion mit Maintainern, die bestimmte Entwicklungen im Keim ersticken, und ohne überraschende Änderungen ›upstream‹, die den eigenen Code betreffen.
Out-of-tree saugt, das kann ich nach 5+ Jahren bestätigen. Aber frei zu sein in seinen Entscheidungen überkompensiert den Schmerz 
Seit v2021.1 sind VPNs in Gluon komplett modular:
Das bedeutet, wenn man tunneldigger weiterhin verwenden möchte, sollte es so ungefähr damit getan sein das gluon-mesh-vpn-tunneldigger package einfach irgendwo anders (der Vorschlag waren hier eben die community-packages) hin zu kopieren.
Die Entfernung aus dem Core bedeutet also das die Communities, die das auch künftig verwenden möchten, in Zukunft komplett selbst verantwortlich sind zu schauen ob Anpassungen nötig sind und nicht mehr versucht wird das dies Leute übernehmen die teilweise tunneldigger noch nie eingesetzt haben, kein entsprechendes Gateway haben um das zu testen usw.
Das letzteres kein tragfähiges Konzept ist, insbesondere auch wenn auch niemand proaktiv regelmäßig testet, dürfte ja hoffentlich verständlich sein.
Täter-Opfer-Umkehr bringt nicht weiter. Bis zum Beweis des Gegenteils bleibe ich dabei, daß der Beitrag da oben die erste Verbalisierung des Problems, daß Tunneldigger von den Gluon-Maintainern seit 2017 gar nicht getestet wird, da nicht genutzt, ist.
Klar, man kann natürlich sagen, ›hätte ja auch mal jemand fragen können‹, augenscheinlich ist aber erst in 2031.1 zu einem größeren Problem mit Tunneldigger in einem Gluon-Release gekommen? Daß man dann nach einem neuen Ansatz sucht: Haken dran. Aber es nun als Bringschuld der Nutzer darzustellen, zu dem ihnen AFAICS unbekannten Problem gefälligst mal 'ne Lösung zu bringen, ist mindestens mal stilistisch fragwürdig.
Also hier von Täter und Opfer zu sprechen finde ich wirklich absurd. Wir machen das hier alle in der Freizeit und die Abkündigung des Supports von irgendwas (zumal mit guter Alternative) ist wohl kaum ein Verbrechen.
Erwähnung fand die Situation rund um die fehlende Testung von Tunneldigger im übrigen schon 2019:
Die Situation hat sich halt seitdem insofern verändert als das es nun eine bessere Möglichkeit gibt L2TP mit Gluon zu nutzen und, wie zuvor erwähnt, die Möglichkeit geschaffen wurde VPNs komplett packetbasiert modular einzubinden wenn Communities an Tunneldigger festhalten möchten. Was aber wohl eben nicht die Empfehlung sein wird.
1 „Gefällt mir“
genau dafür gibt es doch
https://github.com/freifunk-gluon/community-packages
wo auch z.b. ffmuc seine wireguard lösung drin hat … aber @TomH schrieb das ja schon ausführlicher.
siehe meine Antwort in diesem Post ein paar Zeilen weiter oben.
Denn: wenn du/ihr die Zeit+Fähigkeiten für einen Fork hättet, wäre es viel einfacher ihr bringt dies direkt bei gluon ein, das kostet weniger Zeit
Erschließt sich mir gerade nicht, was dir ein Fork bringt, spätestens mittelfristig massenhaft Nachteile?
Aber es ist Open Source, feel free 
Absurd ist die Unterstellung, die nutzenden Communities hätten aktiv »versucht«, daß die Pflege die »Leute übernehmen die teilweise tunneldigger noch nie eingesetzt haben«. Wir zumindest, und anzunehmend auch anderere Communities, haben sich aufgrund der Unzulänglichkeiten von fastd seinerzeit ab- und Tunneldigger zugewandt in der Annahme, daß Tunneldigger ein vollständig unterstütztes Protokoll des Gluon-Firmware-Frameworks sei. Auch und gerade nach dem verlinkten Beitrag vom Juni 2019: eingangs wurde darauf hingewiesen, wie das Problem mit dem Testen via Github adressiert werden könnte, und nach 2 Tagen war das Thema offensichtlich erledigt, keine Nachfragen bzgl. Github/Testern mehr.
Rückblickend offenbar nicht; Kommunikation, wieder einmal ein Thema.
Vielleicht das noch am Rande: natürlich sind wir dankbar für die Arbeit, die in Gluon investiert wurde — selbst könnten wir derlei schon fachlich – OpenWrt-Patches – nicht leisten. Das geht in der Konstellation »nimm den Code und mach’ Dein Ding« – aka Firmware-Framework – leider unter.
Aber ein Framework, das stumpf von den Interessen eines signifikanten Teils der Communities wegentwickelt wird – Replik: friß’ oder stirb’ –, hat einen Großteil seiner Nützlichkeit für diese Nutzer dann halt auch schlicht verloren.
Und gefühlt – auch aus der Lektüre von Gluon-Issues – stehe ich da nicht alleine mit der Ansicht »das muß ich mir nicht geben in meiner Freizeit«.
Da wir eine grundlegend andere Setup-Philosophie verfolgen, verwenden wir zwangsweise eh’ schon seit ~5 Jahren eigene Sourcetrees. War etwas nervig, jedesmal wieder von Null zu patchen — der Ansatz mit site/patches hatte einen gewissen Charme.
… aber nur noch selektiv OpenWrt-basierte Patches nachzuziehen, statt einer Gluon-base hinterherzupatchen, macht die Sache perspektivisch (noch) einfacher.
das ist doch auf beiden „Seiten“ so, nicht für jeden, aber für einen Teil
wer es sich einfach machen will, verfolgt halt keine eigene Philosophie - wer viel patcht, darf sich doch über Probleme/Mehrarbeit nicht wundern?
Die eine Seite ist aber massiv privilegiert gegenüber der anderen. Und es gibt keine zweite Chance auf den ersten Eindruck — das war’s dann einfach. Da hilft auch kein »«.
Daß Gluon-Maintainer Mitlläufer Mitdenkern vorziehen, ist Teil des Problems, AFAICS.
Eben. Wenn man Gluon als hinreichend feature-complete ansieht, spart eine stabile Codebasis Arbeit.
auch dass ich/wir hier diskutieren dient doch 0 mir/uns oder Gluon, sondern hat die Hoffnung dir und anderen Tunneldigger-Nutzern einen Weg aufzuzeigen.
Wenn man als Dank 95% Gemecker/Contra/… erntet, wird das doch nur dazu führen, dass noch mehr Leute (als sowieso schon) kein Bock auf das Publikum hier im Forum haben und deine/eure Sorgen noch viel weniger Ernst genommen werden als du denkst, dass sie bisher werden.