Quo vadis, Gluon?

Firmware
1

Moin,

wir nutzen aktuell noch Gluon v2016.2.x als Basis unserer Firmware. Ein Grund für die langsame Übernahme neuer Versionen bei uns sind die mit jedem Major-Release einhergehenden, teils tiefgreifenden, Veränderungen: wie die Vorgänger, erfordert auch Gluon v2017.1.x Änderungen bei eigenen Zusatzmodulen — und mit v2018.1 wird das nicht besser werden.

Bei unseren letzten Treffen hatten wir herausgearbeitet, daß wir, auch geschuldet der Personalstärke und dem notwendigen Know-How (bgzl. OpenWRT/LEDE und Lua insbesondere), eigentlich uns den Luxus von lokalen Änderungen dr Gluon-Basis-Firmware nicht (mehr) leisten können.

Leider ist Gluon über die Jahre effektiv zur »FreiFunkFirmware: reloaded« mutiert; Gluon ist kein Satz von zusätzlichen (OpenWRT-) Packages mehr, jedes Major-Release fußt auf einem speziellen OpenWRT-Release und bringt auf der Basis Änderungen mit (inkl. Patches des zugrundeliegenden OpenWRTs selbst). Dazu kommen mehr und mehr Änderungen, die in Gluon selbst begründet sind und Gluon nutzende Freifunker vor die unschöne Wahl stellen, den Weg so mitzugehen — oder den Anschluß zu verlieren, konkret: keine aktuell kaufbaren Routermodelle mehr unterstützen zu können.

Für FFGT hatte ich seinerzeit (2014) Gluon ausgewählt, weil es signifikante Vorteile gegenüber dem alternativen, z. B. in Berlin verfolgten, Ansatz brachte: in (batman-adv-basierten) Gluon-Netzen stellt man einfach einen weiteren Knoten auf — das Netz organisiert sich entsprechend um. In den seinerzeit »klassischen Freifunk-Netzen« war jeder Knoten ein FF-Hotspot mit lokalem Exit und lokalem DHCP — und, zwangsläufig, eigener SSID. Knotenaufstellung vergrößerte nicht das Mesh, sondern nur die Anzahl der einmalig pro Endgerät frei­zu­schal­tenden SSIDs …

Geplant war, für unsere Firmware ein finales, auf v2016.2.x basierendes, Release für die 4-MB-Geräte (betrifft insbesondere die 841er) zu veröffentlichen und jene dann damit weiterlaufen zu lassen. Wie die Gluon-Planung zeigt (VXLAN als Voraussetzung für Mesh ab Gluon v2018.1), ist das so nicht realistisch :frowning: Denn, wenn mit Gluon v20191.1 VXLAN Voraussetzung für’s Meshing wird, würden die 841er – die mit kapp 290 Geräten ca. 64% unserer Knoten ausmachen – nicht mehr mitspielen können (ohne neue, v2019.1-basierte, Firmware). Wir werden in ca. 9 Monaten also sowieso vor der Wahl stehen, entweder unser Netz auf VXLAN-Basis umzustellen und dafür »einfach Gluon« nutzen zu können — oder, wie jetzt schon, weitere eigene Patches pflegen zu müssen, die Gluon VXLAN wieder austreiben. (Was, da die Gluon- auch OpenWRT-Entwickler sind, nur ein Phyrrussieg sein könnte.)

Und nun?

2

Was ich mich frage mit Fortschreitender Firmware. Das Problem mit den Früher bliebten 841er Knoten gibt es ja nicht nur bei uns!
Im Münsterland sehe ich ca. 1300 Knoten und in Paderborn ca. 450 Knoten. Wie wollen die die Problematik lösen? Die haben ja auch etwas mehr Menpower.

3

Danke für die Ausführliche Schilderung des Problems.
Wenn die Personaldecke ein Problem ist, denke ich wie Thomas. Eine Zusammenarbeit mit anderen Communities könnte dann doch ggf. helfen.

4

Nacktes Gluon durchzukompilieren ist nicht das Problem. Unsere Firmware enthält allerdings ca. 15 zustätzliche Packages, die wir z. T. von anderen Communities übernehmen (in dem Fall entfällt Anpasungsaufwand für uns), z. T. aber auch selbst entwickelt haben (diese sind die, die zeitintensiv sind).

Nacktes Gluon allerdings ist auch keine wirkliche Option mehr …

Siehe oben, die Packages anderer Communities können wir nutzen und tun das ja auch, wir tauschen uns auch aus; unsere eigenen Anpassungen, die die damaligen Ziele umsetzen, sind das Problem.