Nach längeren Tests liegt die FW für den TP-Link 841v10 nun als »Testing« auf unserem Firmwareserver.
Wie berichtet, war es nicht ganz trivial, Gluon 2015.1.2 für den TP-Link 841v10 zu bauen (einer der Gluon-Autoren hält das Unterfangen gleich für, Zitat, »Schwachsinn« ;-)), aber nachdem seit 14 Tagen nun mehrere Knoten damit laufen, kann man die Ankündigung getrost machen und den v10 als voll unterstützt von der Gütersloher Freifunk-Firmware bezeichnen.
Somit kann der TP-Link 841v10 nun im Kreis Gütersloh als auch der Müritz-Region als Freifunk-Knoten eingesetzt werden. Dank an dieser Stelle nochmals an Ralf Pieper, der uns zwei v10 zwecks Anpassung und Test der Firmware kurzfristig bereitstellte.
Daß diese Firmware derzeit nur im »Testing«-Zweig bereitsteht, ist der Tatsache geschuldet, daß, da wir derzeit zwei voneinander getrennte Build-Abläufe und -Systeme betreiben (müssen), das Bereitstellen für den Firmwareserver dadurch ein händischer Prozeß ist und wir erst nach Lösung der letzten derartigen Probleme sie in »Stable« aufnehmen wollen.
Warum Gluon v2015.1.2 nach OpenWRT »Chaos Calmer« ›vorwärtsportiert‹ wurde, ist relativ einfach zu sagen: die Gluon-Entwicklung geschieht im sogenannten »Master«-Zweig und eng an die jeweils als Basis gewählte OpenWRT-Version. Erst nach v2015.1.2 wurde von OpenWRT »Barrier Breaker« (BB) auf eben »Chaos Calmer« (CC) umgestellt, und erst in OpenWRT CC ist, durch dessen neueren Kernel, die Unterstützung für den Prozessor des 841v10 enthalten.
Gluon »Master« allerdings, die kommende Version 2015.2, ist wieder einmal eine stärkere Überarbeitung (unter anderem mit der Unterstützung eines neuen Meshing-Protokolls, einer verspielten – und dadurch leider nicht mehr sinnvoll per wget auslesbaren – Status-Seite), sodaß alte Erweiterungen, zumal, wenn sie tief eingreifen wie bei der Gütersloher Firmware, nicht ohne Anpassungen funktionieren. Wir standen also vor der Wahl, entweder unsere Pakete auf eine bestimmte Entwicklungsversion von Gluon, mit all ihren Problemen, zu portieren – ohne Garantie, daß sich nicht noch größere Änderungen ergeben, die wir dann nochmals nachziehen müßten –, oder aber ersteinmal zu versuchen, das »alte« Gluon mit dem neueren OpenWRT zu verheiraten. Denn Gluon ist an sich nur eine Paketsammlung zusätzlich zu OpenWRT — eigentlich kann das kein Hexenwerk sein, und das war es ja auch nicht.
Neben unschönen Änderungen am Linux-Kernel und dem Wegfall einer LuCI-Library, waren und sind es die komplexen – und für den, der nicht hauptberuflich Gluon bzw. OpenWRT entwickelt, undurchsichtigen – Abläufe beim Bau von OpenWRT-mit-Gluon-Firmware-Images, die das Unterfangen unnötig erschwerten. Leider gibt’s da keine Hilfestellung aus dem Gluon-Kern-Team, denn:
Für solchen Schwachsinn […] gibt’s aber hier keinen Support. […] Das kann einfach nicht funktionieren, sorry.
Tja, es funktioniert – und es sollte dies eigentlich auch, denn die Gluon-Pakete sind kein Hexenwerk –, nur leider nicht reproduzierbar (der Versuch, es im Jenkins-Umfeld erneut hinzubekommen, schlägt leider immer wieder fehl, ohne erkennbaren Grund/Fehler). Aber es verstößt halt gegen den Geschmack der Entwickler; aber naja, that’s life ;-)