Moin,
am letzten Wochenende wurden Schritte unternommen, unsere Firmware auf Basis der Arbeiten der Kollegen in Celle weiterzuentwicklen. Die Celler Freifunker haben sich die Mühe gemacht, die notwendigen Änderungen für 821v10+ und 1043v2+ (sowie weitere Verbesserungen) auf Gluon-v2015.1-Basis, OpenWRT Barrier Breaker, rückzuportieren.
Für die initiale Unterstützung der 841v10-Hardware wurde bei uns auf einen Hybriden gesetzt, OpenWRT Chaos Calmer mit Gluon v2015.1 als Überbau; das ist technisch nicht trivial und klappt derzeit nur genau in einer Systemumgebung — die zu diesem Zwecke geklont und in eine VM überführt wurde.
Dank der Vorarbeit der Kollegen in Celle jedoch sind wir nun in der Lage, wieder eine einheitliche Firmware für alle Geräte zu nutzen – inklusive 841v11 –, und das auf Basis des erprobten und gut verstandenen OpenWRT »Barrier Breaker« und des Gluon-v2015.1-Codes.
Um die Firmwareentwicklung weiter zu beschleunigen, wurde eine weitere Firmware-Kategorie eingeführt: »Rawhide«. Die Firmwareseite [1] wurde entsprechend erweitert, und auch hinter den Kulissen wurde munter jongliert. (Just for the records: da der Speicherplatz in Gütersloh knapp wurde, die Firmware aber sowieso bei Bedarf auf 6 von 8 Kernen eines Hetzner-Hosts in Falkenstein gebaut wird, läuft der Webserver weiterhin in Gütersloh, die Firmwareverzeichnisse werde aber per NFSv4 aus Falkenstein benutzt, wo 3 TB zur Verfügung stehen.)
Auch vorher schon wurden die Änderungen an der Firmware automatisch verfolgt und führten zu automatischen Firmwarebuilds; jene mußten bislang aber manuell zur »experimental« Firmware erhoben werden, bevor sie überhaupt zugreifbar war.
Diese Restriktion ist mit »rawhide« gefallen: sofern der Bau der Firmware (gebaut werden die Gluon-»Targets« ar71xx-generic (die meisten TP-Link-Geräte), mpc85xx-generic (TP-Link WDR-4900), ramips-rt305x (D-Link DIR 615 Rev. D), x86-kvm_guest sowie x86-generic mit Patches für die Futros — alles in allem über 80 verschiedene Images) erfolgreich war, werden diese Images automatisch für den Firmwareserver bereitgestellt! Die Warnungen auf dem Firmwareserver sind dahingehend ernst gemeint: der Code hat niemals einen Router gesehen, die Chance, daß man sich einen teuren Briefbeschwerer erflascht, liegt bei »rawhide«-Images bei 30-60 Prozent!
Für »rawhide« existiert auch kein Autoupdater. Natürlich kann man ein »rawhide«-Image flashen und den Autoupdater auf »experimental« stellen: sobald dann eine neuere »experimental«-Firmware verfügbar ist als die Version, die man mal von »rawhide« nahm, würde der Knoten sich wieder automatisch aktualisieren. Dies ist auch der gewünschte Weg, mit »rawhide«-Images zu arbeiten 
Die Grundidee ist es, jedermann zu ermöglichen, an der Firmwareentwicklung direkt zu partizipieren; durch das Forum [2] haben wir auch einen bi-direktionalen, direkten Kommunikationsweg. Nach wie vor befindet sich die Firmware auf github [3], sodaß durch pull-requests auch hier die Teilnahme jedermanns möglich ist.
Ach so, warum »rawhide«? Das ist effektiv eine Anlehnung an RedHat/Fedora, bei denen die dauerhafte Entwicklungsversion »rawhide« heißt [4] — bei Debian wäre das »sid«. Aber durch das »raw« (engl. für »roh«) in »rawhide« erschien jener Name angemessener; die Arbeit mit FFGTs »rawhide« wird, alles in allem, nicht immer lustig sein 
MfG,
-kai
[1] http://firmware.4830.org
[2] https://forum.freifunk-kreisgt.de
[3] https://github.com/ffgtso
[4] https://de.wikipedia.org/wiki/Rawhide