Als nun aber wirklich wirklich wirklich letzte Firware für 4/32-Geräte, ackert sich unser Buildserver mal wieder durch Gluon & OpenWrt, um die Firmware 1.2.0 zu erzeugen. (Bzw. wurde gerade fertig, »Buildtime: 91 minutes @ 48 core(s)«.)
Sprich: It’s rawhide time
Änderungen: Unterbau ist statt Gluon 2018.2.4 nun Gluon 2019.1.3. Wesentliche Änderungen gibt’s eher nicht, beides basiert auch OpenWrt 18.06. Allerdings hat Gluon nun den »outdoor-mode« eingeführt, was soweit ich sehen kann, aber nur bei der (Erst-) Installation zum tragen kommt. Ansonsten bringt v2019.1 primär Bugfixes und Abkündigungen für folgende Gluon-Versionen, nämlich der Unterstützung von Batman Advanced Compatibility Level 14 (aus 2014), der Unterstüzung von IBSS (»Ad-Hoc«) als Funkmeshprotokoll sowie der Unterstützung von Geräten mit 4 MB Flash und/oder 32 MB RAM.
Heißt: nach 1.2.x/Gluon 2019.1 ist definitiv Ende Gelände mit neuer Firmware für Geräte mit 4 MB Flash und/oder 32 MB RAM — angekündigt haben wir das ja schon 2019
Ich denke, daß wir bei Gluon 2020.x einerseits nicht die Geräte unter dem Label »lantiq-xway« bauen sollten – das sind primär alte Fritzboxen, die in 2020.1 offiziell eingeführt und mit 2020.1.2 wieder rausgeworfen wurden – und andererseits mit Lippe gleichziehen und 2020er Firmwares als 1.4.x labeln sollten. (Die Fritzboxen der 736x-Serie (insbes. 7360 und 7360SL) unterstützt unsere Firmware seit 1.1.x und natürlich auch weiterhin.)
Ah, ein Problem gibt’s doch; ein breaking change, weshalb ich 2019 eigentlich auslassen wollte:
With Gluon v2019.1, nodes will not answer respondd queries on [ff02::2:1001]:1001 anymore. Respondd querier setups still using this address must be updated to the new address [ff05::2:1001]:1001 (supported since Gluon v2017.1). This change was required due to cross-domain leakage of respondd data. If you are using hopglass-server to query respondd data, you need to update it to at least commit f0e2c0a5.
Sprich: die sich aktualisiert habenden Knoten fallen (erstmal) aus der Karte, bis ich die neu hochgezogen habe …
Jain, siehe Patch zu unserem Tree unten. Dennoch scheint sich mein Testnode nicht »sauber« zu melden, denn u. a. der händisch eingetragene Ortswechsel wird auf der Karte igoriert/nicht reflektiert.
Jetzt fällt es mir wieder ein. Mit py-respondd und Hopglass war es seinerzeit auch bei uns problematisch, es lief erst vernünftig nach dem Umstieg auf Meshviewer mit Yanic als Backend.
