Aufgrund von einigen Faktoren, soll der Freifunk Kassel gemeinsam mit dem ehem. Freifunk Frankenberg fusionieren. Der Freifunk Frankenberg e.V. wurde bereits in den Freifunk Nordhessen e.V. umbenannt.
Nun soll Kassel per Firmware migriert werden, die Firmwares und das Manifest ist nun auch signiert (2 Signaturen waren benötigt, es sind 3 gültige Signaturen hinterlegt).
Kommen wir nun zu folgendem Problem:
In der site.conf der Kasseler Firmware haben wir eine IPv6-ULA aus unserem IPv6-Bereich für Firmwares reserviert. Diese IP-Adresse liegt nun an unserem Webserver (ist per fastd zu den GWs im Mesh). Dort ist auch der nginx konfiguriert. Testweise hat der nginx eine ACL bekommen, sodass nur einige vereinzelte Testnodes diese Migrationsfirmware erhalten.
Kommen wir nun mal zum eigentlichen Problem:
Nachdem die ACLs und der HTTP-Webserver mit nginx steht, habe ich nun Probleme das Update auszulösen. Die Knoten laufen bereits seit einigen Tagen und haben sich das Update nicht gezogen.
Per SSH aufgeschaltet und überprüft:
Das Manifest und die Firmware Files lassen sich sauber per wget auf den Betroffenen Routern herunterladen.
Der Autoupdater zeigt einen wget-Fortschrittsbalken an und sieht erfolgreich aus, die Dateigröße passt auch zum Manifest
Im (temporär aktiviertem) Access Log des nginx sehe ich nun jede Menge 403’er für nicht freigeschaltete Router, jedoch nur 200’er bei den betroffenen Routern.
Folgende Meldung bekomme ich:
root@ffks-dariks-test-01:~# autoupdater
Connecting to [fdca:55e1:baca:baca::1:80] ([fdca:55e1:baca:baca::1:80]:80)
- 100% |*********************************************************************************************************************************************| 149k 0:00:00 ETA
There seems to have gone something wrong downloading the manifest from http://[fdca:55e1:baca:baca::1:80]/images/stable/sysupgrade
No usable mirror found.
Ich bitte um Hilfe und hoffe, dass uns hier geholfen werden kann
Vielen Dank!
Ebenfalls zu erwähnen wäre, dass ein ‚autoupdater -f‘ ebenfalls den selben Output liefert. Leider lässt sich die Ursache hier nicht auf Anhieb erkennen. Ich habe auch probiert testweise ein Linux-Notebook in das Netzwerk zu hängen mit der besagten IP-Adresse und dort einen Apache laufen zu lassen. Leider brachte dies auch nichts, da ich weiterhin nur die selbe Meldung erhalte.
Kannst du mal das manifest verlinken, dass die Router da ziehen?
P.S.: Nicht vergessen bei Gluon älter als 2017.1.8 erstmal auf 2017.1.8 oder den unreleasten 2016.2.x branch zu updaten. Außer natürlich ihr wollt eure CPE210 händisch de-bricken Siehe letzter Absatz in den Important Notes: Gluon 2019.1 — Gluon 2023.2.2 documentation
Vielen Dank für deine Nachricht.
Hier findest du die Manifest Datei: https://dl.freifunk-kassel.de/images/stable/sysupgrade/stable.manifest
(Intern natürlich via HTTP erreichbar…)
Alle CPE210/510, die in unserem Netz betrieben werden, sind alle von der selben Person, der überall seinen Key hinterlegt und eine eigene Firmware ausgerollt hat, daher macht das in diesem Sinne nichts.
Ich hoffe wir schaffen es diesen Fehler zu finden
Ich denke er erkennt deine Firmware einfach nicht als neuer an.
v2016.2-1-HEAD > 1.0.3.3
Im Detail kann ich das nicht sagen. dazu müsstest du dir mal den Vergleich im Code ansehen.
Hmm… Ein guter Ansatz! Ich habe gerade mal manuell die Datei /lib/gluon/release zurückgedreht auf die 1.0.2 und bekomme weiterhin den selben Fehler… Ich muss dir da aber Recht geben… Sobald das laufen würde, wäre das das nächste Problem gewesen…
Wir schauen uns mal nach einer Lösung zu dem Versionsproblem um, jedoch löst das leider auch nicht, dass der Autoupdater angeblich ein Problem beim Download des Manifests hat…
Ggf. im Netzwerk (mit curl oder so) schauen was da tatsächlich als Manifest zurückgeliefert wird.
Ansonsten, ja, die Version wird ein Problem sein.
Außerdem ist das Datum relativ aktuell, sodass später beim Update, je nachdem wie ihr die Probability in der site.conf konfiguriert habt, ein stufenweiser Rollout erfolgt (was ja durchaus erwünscht sein kann).
Bei solchen Fragen ist es grundsätzlich immer Fall sinnvoll die Gluon Site zu verlinken. Auf die schnelle konnte ich keine solche finden. So kann es sehr viel sein. Und wie @steneu (und @Felix) schreiben muss es mit curl am Knoten möglich sein das Manifest abzurufen.
So, ich habe bei in der Freifunk Nordhessen Technikrunde im Signal einen super Tipp bekommen!
Scheinbar hat jemand die Datei im Windows editiert und daher im DOS Format gespeichert. Nach einem ‚dos2unix stable.manifest‘ läuft es nun. Und tatsächlich: Die Router melden nun „No new firmware available“. Die Versionsnummer der Firmware steht, wenn ich das richtig verstehe, zwischen dem Gerätenamen und dem Hash oder? Dann müsste ich diesen hochschrauben.
Und ja, die Datei war per wget abrufbar. Das war eben das komplizierte an der Geschichte…
Vielen Dank schonmal für die vielen Vorschläge!
Siehe letzter Absatz in den Important Notes: