2019.1.x oder 2020.1.x Firmware in Planung / Überlegungen

Angeregt durch Planungen in Wuppertal, habe ich in Radevormwald am vergangenen Freitag mit Vorbereitungen für eine neuere Firmware begonnen. Erste Stolpersteine sind auch schon ausgeräumt und im Output Ordner liegen nach langen Nächten seit gestern endlich die ersten Images :upside_down_face:

Ein Test heute macht einen guten Eindruck. Der Kontakt zu den alten Supernodes via Mesh-VPN klappt. Ebenso das Mesh über Kabel (vxlan) und Wifi mit Bestandsknoten. Und manuell nachgeholfen, erscheint der erste Knoten auch auf der Karte.

1 „Gefällt mir“

Kurze Frage, was sind eure Beweggründe jetzt noch eine Firmware auf v2019.1.x zu bauen und verwenden zu wollen?

Insbesondere seit dem die gelegentlichen Abstütze von fastd in v2020.1.3 behoben wurden, hat v2019.1.x jetzt noch zu verwenden eigentlich nur Nachteile was Features und Hardwarekompatiblität angeht?

1 „Gefällt mir“

Es betrifft nur indirekt Radevormwald. Aber in der Mutter Community ist im Moment Gluon 2016 mit IBBS mesh im Einsatz. Da möchte ich erst mal ein funktionierendes 2019.1.x

1 „Gefällt mir“

Gut, wenn man noch an IBSS-Mesh festhängt muss man erst mal ein maximal 2019.1.x ausrollen.
Aber eine Umstellung auf 11s sollte ja dank gluon-scheduled-domain-switch — Gluon 2021.1 documentation recht unkompliziert sein.

Unklompliziert?
Funktioniert IPv6-ntp in der Domain denn inzwischen? Oder wie kommen die Wifimesh-Knoten an eine gültige Uhrzeit?
Oder kann man das „wenn keine gültige Uhrzeit ist“ auch „einfach so“ laufen lassen und die uhrzeitlosen Knoten wechseln von allein irgendwann zufällig?

Nachdem ich den public NTP Server in der site.conf enfernt habe und nur die Netz internen eingetragen sind, gibt es an allen Knoten die korrekte Zeit. Das war mir fürs gluon-aptimeclock Package wichtig. Ob die Änderung oder mein vorheriges Problem speziell an meiner Struktur lag, kann ich nicht beurteilen.

Keine Ahnung, ob der domain-switch eine korrekte Zeit braucht. Rade ist auch schon auf 802.11s, vxlan und batman-adv-15. Aber für Wuppertal sollte man das klären. @mat, schreibst du das auf die Wuppertaler ToDo :slight_smile:

IPv6 NTP Funktioniert? Oder habt ihr einfach de.pool.ntp.org eingetragen? In dem Fall kann es sein das ihr einen Pool erwischt habt der ausschließlich mit A Records antwortet. Dann gibt es keine Zeit für die Knoten.

Und Doku zu dem Paket gelesen und verstanden?
Die Knoten schalten um, wenn die definierte Umschaltzeit abgelaufen ist. Falls der Knoten ausgeschaltet wurde, während dies eigentlich geschehen sollte, kann es sein, dass er nicht in der Lage ist, die korrekte Zeit zu ermitteln. In diesem Fall schaltet der Knoten um, nachdem er eine bestimmte Zeit lang kein Gateway gesehen hat.

Dafür sind die Optionen: switch_after_offline_mins und connection_check_targets

Also ja, der der Domain-Switch braucht für einen reibungslosen Ablauf funktionierendes NTP, wenn Knoten mal Keine Funktionierende Uhrzeit haben ist es allerdings halb so schlimm, Wechseln sie trotzdem nach gewisser Zeit in die korrekte Domain.

In dem Fall spricht ja nichts gegen v2020.1.3 :wink:

1 „Gefällt mir“

weder noch.
Zumindest in der parent-domain gibt es meines Wissens weder public ipv6, noch einen gültigen ntp-server mit AAAA-record in der site.conf, noch noch einen einen lokalen ntp.

Nein, Du hast es nicht verstanden!
Will sagen: Danke für den persönlichen Angriff, aber das kann ich auch!

Weil sonst Knoten -obwohl dauerhaft online- schon vor dem eingestellten Stichtag regelmäßig umschalten.
Vermutlich hast Du die Doku gelesen, aber halt nicht verstanden was in Wupper das Problem ist.

Liegt dies nun an der site.conf oder funktioniert der NTP client auf den Knoten trotz funktionierenden Servern in der site.conf nicht?

Nein, das ist nicht der Fall.

Wenn ein Knoten dauerhaft online (erreichbares gateway) ist, so switcht dieser auch nicht automatisch. Auch schaltet ein Knoten nur einmalig um, regelmäßiges Umschalten findet auf einem einzelnen Knoten somit nicht statt.

Oder bezieht sich das regelmäßig auf einen Fehlerfall? Kannst du in diesem Fall beschreiben wie es dazu kommt?

Die Ausgangslage für die „Mutterdomain“ ist die hier:

Und zumindest als ich das Letzte mal geschaut habe gab es kein rdns für ntp.services.ffw.

Achtung, evtl. OT!

Ernst gemeinte Frage:
Was spricht denn, ausser der erweiterten Hardware-Unterstützung, „für“ das gerade mal 7 Tage alte Gluon v2020.1.3 Release?
Und gerne auch nochmal andersrum, was spricht neben der geringeren Hardware-Unterstützung denn gegen z.B. ein Gluon v2019.1.x ?

Ich kann diesen ganzen sich überschlagenden „neu ist zwangsläufig immer besser, aber Gründe liefere ich nicht“ Aussagen nicht immer ganz folgen. Neu ist gut, es handelt sich um Veränderung und ist extremste wichtig, Vielfältigkeit und Beständigkeit sind es jedoch ebenso. Eine Daseinsberechtigung ist nicht nur auf Grund von wegen „neu“ automatisch immer und wie selbstverständlich gegeben. Mir fehlen da einfach Begründungen.
Wie gesagt, ernst gemeinte Frage.

3 „Gefällt mir“

Second that. Wer the latest and greatest nutzen will, der möge dies tun. Es mag aber auch die Einstellung geben, daß »stable« etwas sein soll, daß die Funktion schon tausendfach bewiesen hat.

Nicht zuletzt – und das bitte nicht als Kritik verstehen; neue Software hat prinzipbedingt Bugs – hat auch 2020.1 Probleme eingeführt, die in Point-Releases dann behoben wurden. Es ist eine legitime Communityentscheidung, gerade nicht »latest & greatest« einzusetzen, wie es eine legitime Communityentscheidung ist, Master auszurollen.

1 „Gefällt mir“

Ich kann verstehen das sich manche Communities nicht immer vorpreschen wollen und sofort die neuste „latest and greatest“ Software einsetzten wollen, weil vielleicht Prioritäten anders liegen.

Der Gluon v2020.1.3 Relase ist viellicht jetzt grade mal eine Woche alt, v2020.1 gibt es jetzt aber schon seit Mitte Februar. Genug Zeit für Fehleranalysen, Bugfixes, und dann Releases die die Bugfixes dann beinhalten, wie es v2020.1.3 nun mal ist.

Außer dem Hardware-Support muss ich dir recht geben, gibt es für den Endnutzer relativ wenig Neuerungen in v2020.1. Es wurde vor allem unter der Haube gearbeitet. Gluon basiert ab dann auf OpenWRT 19.07, es gibt Updates an der Statusseite die es einfacher machen zu erkennen in welcher Domain man ist und wer Meshpartner ist, es gibt Performance Verbesserungen für Geräte mit 8MB Flash und 32MB RAM. Aber ich denke Relase Notes kann jeder lesen. :wink: Mit v2020.2.x wird es da deutlich mehr interessante Änderungen geben.

Insbesondere im Freifunk Kontext sind wir aber auf gute und breite Hardwareunterstützung angewiesen, nachdem viele der Standartmodelle nur noch auf dem Gebrauchtmarkt zu erwerben sind, bin ich Persönlich froh um jede neue Plattform die Unterstützt werden kann. Mit den Aruba Instant On AP11 hast du z.B. zum selben Preis wie für einen Unifi AC-Lite ein wesentlich leistungsfähigeres Gerät für die Montage an Decken und Wänden.

Sich diese Möglichkeiten vorzuenthalten, nur aus dem Grund, das man gerne gut abgehangene Software verwendet, kann ich beim besten Willen nicht nachvollziehen.
Daher auch meine Ursprüngliche Frage an @steneu was die Beweggründe waren.
Hätte es z.B. Community Spezifische Pakete gegeben die erst angepasst werden müssten, verstehe ich wenn man weiterhin ein altes Release nutzt.

1 „Gefällt mir“

Aus Frankfurter Sicht kann ich sagen:
Wir fahren deutlich besser und einfacher in Sachen Support, seitdem wir den Backlog (11s und Batman 15) aufgeräumt haben, möglichst wenig Communityspezifika haben und Gluon-Releases zeitnah ausrollen.

Man muss wenig doppelt machen, hat mehr Hardware zur Verfügung usw. Getestet ist das Setup besser, je näher man am Upstream ist - gefühlt verursachen alte Gluon-Versionen in den Communitys, in denen ich aktiv bin, mehr Probleme, als sie lösen.

Das wird jetzt arg off-topic, daher nur soviel:

Ist Dein gutes Recht, aber nicht jeder muß der gleichen Meinung sein. Zumal nicht überall der Bedarf nach neu(est)er HW im Vordergrund steht, auch dank der Aufnahme von AVM-Geräten.

Das ist ein Grund, warum $hier noch mit 2018.1/2018.2 gearbeitet wird, bis wir den Batman-Wechsel und den Schwenk von fastd auf L2TP vollzogen haben. Beides geht nicht per gluon-scheduled-domain-switch AFAICS. Kurzum: Fragen der Art »warum nimmst Du nicht Gluon $lastest?!« sind in der Regel wohl überflüssig, die Leute denken sich ja schon was bei dem, was sie tun, siehe auch die Antwort von @steneu.

1 „Gefällt mir“

Da ich die Überlegungen für meine „Planung“ sehr gut finde, habe ich den Topic angepasst :slight_smile:

2 „Gefällt mir“

Ich denke nicht das Fragen dieser Art überflüssig sind, insbesondere als Admin oder eben als Verantwortlicher für Freifunk Firmware sollte man sich diese Fragen immer wieder selber stellen. Insbesondere wenn man noch in der Planung ist. Warum baue diese Firmware so wie sie ist? Welche Pakete brauche ich? Warum setzte ich auf einen speziellen Release von Gluon und eben nicht den neusten?

Und wenn man nicht den neusten Release verwenden kann, warum? Was kann ich machen damit ich die Updates auch an meine Community weiter geben kann? Gibt es einen speziellen Bug der Blockiert, wenn ja, wie kann ich dazu beitragen ihn zu beheben?

Damit implizierst Du, dies würde nicht geschehen, was ich ehrlich gesagt für nicht angemessen halte, positiv formuliert.

Zum Beispiel, weil die breaking changes eine direkte Integration der eigenen Änderungen wiedereinmal verhindern, man sich des Aufwandes gegenwärtig ist und sich bewußt für diesen Weg entschieden hat, da die Auffassungen von ›Upstream‹ von den eigenen hinreichend stark divergieren, daß der Fork der bessere, streßfreiere, Weg ist. Nicht alles ist ein Nagel …

Ganz ehrlich: Wenn meine Changes einen eigenen Fork erfordern (und keine Chance haben, zumindest als Paket Upstream angenommen zu werden), denke ich nicht, dass diese in eine Stabile Firmware gehören. Ich meine explizit keine Backports.

Ich sehe die Realisierung von Features in der „Community-Insel“ eh kritisch. Wenn es ein Problem löst, wieso nicht allen verfügbar machen?

Ich habe mir mal die site.conf angeschaut, da du sagt es gibt kein rdns für ntp.services.ffw. Dementsprechend kann ich leider nicht sagen ob es einen funktionierenden NTP Server Netzintern gibt.
ntpX.ptb.de liefert aber auf jeden Fall auch per v6 korrekte Antworten zurück. Falls es in Wupper IPv6 Verbindung ins Internet gibt, sollten auch eure Knoten NTP nutzen können. Es braucht ja kein Public v6, zur Not frisst der Teufel Fliegen und nimmt v6 NAT auf Private Adressen.

Aber ich verstehe ab der Stelle wirklich das Problem das es in Wupper mit dem Paket gibt nicht. Falls es kein NTP gibt, fängt dich der Offline Switch. Wegen Fehlendem NTP stellt sich ja die Uhr nicht vor? Auch wird nur einmal gewechselt, und nicht immer hin und her. Im Worst Case wackelt das Netz den Zeitraum, den du als offline Switch Time angegeben hast.

Daher auch von mir die Frage, kannst du den Fehlerfall genauer beschreiben, oder zumindest anreißen was das Problem genau ist?