Neue Firmware Experimental 1.0.3

Experimental 1.0.3

Diese Firmware ist nur ein Bugfix Release von Fehlern in unserer Site-Config

  • DNS Cache hat auf die falsche IPv6 Adresse gelauscht, wurde jetzt angepasst
  • Schreibfehler in den Übersetzungsdateien angepasst der zu einem nicht anzeigen des Registrierungs-Link führe.

Die Firmware ist ab sofort per Autoupdate und unserer Firmwareseite verfügbar.
Fehlermeldungen bitte mit Screenshot oder Logfile in diesen Thread.

2 „Gefällt mir“

Seit wann wird die Experimental 1.0.3 verteilt?

Bei mir lief vorher:
1.0.2-20170705 / gluon-v2017.1.1+

Seit heute Nacht (2017-07-12 04:29:06 Uhr) ist mein Experimental Node nun nicht mehr erreichbar:
https://map.ffrn.de/#!v:m;n:e894f668bc32

Zwangstrennung würde ich mal ausschließen, die war nämlich um 2017-07-12 03:06:19 Uhr.

Könnte das mit dem Update zusammenhängen? Logs (seriell) kann ich ohne Reboot keine liefern, müsste erst aufschrauben und Serielle Konsole dran löten…

Die wird seit heute Nacht verteilt.
Der Bug mit dem notwendigen Hard-Reboot seit Gluon 2017.1 ist bekannt.
Github Issue dazu: https://github.com/freifunk-gluon/gluon/issues/1160

Achso, der Hard-Reboot ist ab jetzt IMMER, bei jeder Aktualisierung erforderlich?

Nein, das ist ein Bug der aktuell Auftritt. Sobald behoben werden wir den auch integrieren.

Ich stehe gerade auf dem Schlauch, sorry… Nochnmal von vorn:

Ich musste nach dem Update auf: 1.0.2 neustarten
Ich müsste nach dem Update auf: 1.0.3 neustarten (heute dann)

Das heißt, der Bug besteht weiterhin und trotzdem wird die neue Firmware (wissentlich, dass alle Nodes anschließend neu gestartet werden müssen) weiter verteilt? Handelt sich ja “nur” um die Experimental, trotzdem ist das Neustarten natürlich ärgerlich.

Wäre es nicht sinnvoller, die nächste Experimental zu verteilen, sobald der Bug behoben ist?
Ich würde sonst wohl zwischendurch auf Stable umstellen und sobald der Bug gefixed ist wieder auf Experimental.

Experimental ist wirklich nur zum testen da, auch für diesen Bug. Also bitte alle Knoten bei denen ein Eingreifen nicht möglich oder erwünscht ist auf Stabe stellen.
Ich kopiere hier nochmal den Text unserer Firmware Seite:

Vorsicht! Unsere experimentelle Firmware wurde nicht getestet und kann dein Gerät jederzeit und unangekündigt in einen Zustand versetzen, in dem du nur mit einem Lötkolben und dem Öffnen des Gehäuses weiter kommst. Verwende diese Version nur, wenn Du Dir darüber im Klaren bist!

4 „Gefällt mir“

Interessanterweise haben zwei meiner Knoten das Update von 1.0.2 auf 1.0.3 ohne manuellen Neustart überlebt … die anderen warten auf Besuch …

Noch mal was neues …
Ein Knoten, den ich an Weihnachten kurz auf dem Marktplatz eingesetzt habe war noch auf 0.6.2
Ladenburg-OHS-007 ein 842V3
Dann habe ich den mit der Update-FW auf 0.6.9 gebracht. Er hat zwar funktioniert, aber er hatte dann zwei IPV6 … und dann habe ich ihn mit der Experimental noch mal geflasht und dabei die Einstellungen gelöscht, damit das alles konsistent ist.

Jetzt bootet er nicht mehr richtig. Ich erreiche den über die LAN-Schnittstelle und die mir noch bekannte IPV6 fe80::ee08:6bff:fe56:b90a Die POWER-LED blinkt langsam und WLAN wird nicht angezeigt
Aber das ist eine interne IPV6, oder?

Putty zeigt dann

BusyBox v1.25.1 () built-in shell (ash)

     _________
    /        /\      _    ___ ___  ___
   /  LE    /  \    | |  | __|   \| __|
  /    DE  /    \   | |__| _|| |) | _|
 /________/  LE  \  |____|___|___/|___|                      lede-project.org
 \        \   DE /
  \    LE  \    /  -----------------------------------------------------------
   \  DE    \  /    Reboot (17.01-SNAPSHOT, r3435+32-65eec8b)
    \________\/    -----------------------------------------------------------

root@ffrn-ec086b56b90a:~#

Wenn ich gleichzeitig WAN anschließe und einen PING auf 8.8.8.8 versuche:
root@ffrn-ec086b56b90a:~# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
ping: sendto: Network unreachable

Wenn ich verscuhe in die Config-Oberfläche zu booten reagiert die Kiste auf 192.168.1.1, aber nachdem die URL dann auf die Config-Oberfläche zeigt, steht dann dort nur “LuCI - Lua Configuration Interface” auf schwarzem Hintergrund. Er versucht etwas zu laden, aber das klappt nicht. Da kommt dann ein TimeOut für “http://192.168.1.1/cgi-bin/luci

Wie kann ich den jetzt wieder in gang bekommen?

Okay … also ganz toll …

Ich habe einen nagelneuen 842 von der OriginalFW auf die Experimental 1.0.3 geflasht und genau das gleiche bekloppte Ergebnis…

Die Datei zum Flashen ist die “gluon-ffrn-1.0.3-20170711-tp-link-tl-wr842n-nd-v3.bin” und es ist ein 842N V3.1

Bin ich nur grade dumm, oder ist da was faul mit der 1.0.3 FW?

Gibt es einen TFTP im Netz für den 842V3.1 ? Wie müsste das Image heißen, wenn ich selber einen einrichte?
Starten des Routers mit gedrückter “reset”-Taste und halten bis das Schloss leuchtet?
Dann müsste er nach dem Neustart das Image laden, oder?

PS: Ich habe mir einen TFTP hier eingerichtet.
Als Image habe ich habe ich die neueste Stable genommen und die wr842nv3_tp_recovery.bin genannt.
Wenn ich den Router starte dann sehe ich in TFTP wie er die Date holt.
Gestartet GET Dateiname …
Abgeschlossen GET Dateiname …
Der Router startet dann neu und blinkt langsam (Power)
Das Kabel dann wieder an den internen Port und die IP des Anschlusses ist dann wieder 192.168.1.2 (für den PC).

Allerdings komme ich dann nicht mit Firefox auf die Oberfläche. Mit IE10 gehts?!
Jedenfalls scheint der Knoten zu laufen wieder … Etwas schräg die Nummer.

Bei meinem 841v9 Meshknoten lief dieses Update ohne Probleme und ohne Neustart durch. Bei einem der letzten hat der Knoten jedoch auch manuellen Neustart gebraucht.

Bei mir lief das Update auf einem 842er auch ohne manuellen Neustart durch. Es ist wohl nicht zwangsläufig so, dass ein Reset gebraucht wird.

Es gibt wohl Hinweise darauf, dass das Update eher durchläuft, wenn der Knoten vor dem Update frisch gestartet wird.

Der Knoten bei mir, wo das Update durchlief, war zufällig gerade frisch gestartet.

Hinweis: es sieht so aus, als wenn diese Firmware bei einem Offloader mindestens eine 256MB große CF-Karte benötigt.

Ältere Images liefen auch mit kleineren Karten. Habe gerade mehrmals versucht, einen ursprünglich funktionierenenden Offloader mit 128MB Karte neu aufzusetzen, und habe den Fehler jetzt wohl gefunden.

Das Trickreiche daran ist, dass sich das Image problemlos auf die zu kleine Karte aufspielen lässt, die Partition dann aber einfach zu kurz für die Partitionstabelle ist.

Das ist soweit richtig. Genaue Infos stehen unter Gluon 2017.1 — Gluon 2017.1.8 documentation

Ehrlich gesagt habe ich aber noch nirgends Futros mit CF Karten kleiner als 512MB gesehen.

Meine Offloader hatten 512MB Karten, die aber mit meinem CF-Reader nicht kompatibel waren. Daher habe ich einfach andere Karten genommen, damit lief (bisher) alles problemlos.

Jetzt habe ich ein neues Lesegerät, und bin wieder auf die Originalkarten zurückgegangen.

Wie groß muss eine Karte denn sein? Reichen 256MB oder muss sich mindestens 273MB groß sein?

Ab sofort muss das Speichermedium mindestens 273MB haben.

1 „Gefällt mir“