Neue stabile Firmware Version 0.5.2-20160307

Ab sofort steht die neue Firmware Version 0.5.2 auf Basis von Gluon 2016.1 im stable Branch zum Download und Autoupdate bereit. Damit gibt es jetzt eine stabile Firmware Version für den TL-WR841N v10 und die neue Statusseite für alle.

Außerdem sollten jetzt die OPKG Repositories funktionieren so wie sie mitgeliefert werden. Außerdem haben wir jetzt funktionierende Kernel Module. Falls also noch jemand Platz findet oder ein Gerät mit mehr als 4MB Flash hat :)

Im experimental Branch folgt dafür dann bald eine Firmware auf Basis von Gluon 2016.1.1

5 „Gefällt mir“

Ich habe zwei TP-Link TL-WR842ND v1 die seit dem Firmwareupdate nicht mehr online gehen. Die LEDs sind eher seltsam. Wenn der Uplink angesteckt ist und ich das Gerät nach dem stromlos machen starte blinkt nur die Internet LED. Ziehe ich den Uplink ab und starte, blinkt die Configurations LED, leuchtet irgendwann dauerhaft und WLAN blinkt wie gewohnt. Das Schloss Symbol habe ich nicht einmal blinken sehen. Nach dem Neuaufspielen der Firmware, ohne Übernehmen der Einstellungen ist er wieder online. Allerdings nur, wenn ich zuvor den Uplink abziehe. Und das Schloss Symbol leuchtet nach wie vor nicht.

Ich nehme die beiden Geräte mal mit nach Hause und baue nächste Woche andere auf. Dann können wir das nächste Woche einmal analysieren.

HD-Altstadt-023-Pannonica https://map.ffrn.de/#!v:m;n:90f6522b5a04 (den habe ich bereits angefasst)
HD-Altstadt-026-Musikzimmer https://map.ffrn.de/#!v:m;n:64700252bf88

Laut Statistik gibt sind zwei weitere Geräte dieses Modells im Einsatz. @leah könntest Du bitte einmal schauen ob die auch seit gestern offline erscheinen? Dann gibt es hier möglicherweise ein Bug.

Ich habe einen von den 842ND v1 bei mir, teste später mal das update

2 „Gefällt mir“

Als kleine Rückmeldung von mir: der auf experimental noch problematische MR3420 V1 tut mit der aktuellen stable.

@hdvalentin vielen danke für die Info. Ich gucke mir das später mal an.

Muss man eine Firmware eigentlich immer neu kompilieren, um sie als stabile Firmware freizugeben? Ist evtl. der Default-Autoupdater-Branch der Grund? Gibt es noch andere Gründe?

Aktuell sieht es immer so aus, als wäre die stable eine neuere Version als experimental, was eher unintuitiv ist.

Ja, man muss sie immer neu bauen damit das funktioniert. Und ja unter anderem ist der default Branch der Grund dafür, es gibt aber noch einige weitere. An sich ist das aber kein Problem.

Joah, das ist so. Ist aber eigentlich auch logisch, dass in der Stabilisierungsphase das Build Datum mit der Nähe zum Release steigt. So ist das ja bei den meisten Software Versionsnummern. Letztlich ist das relevante was die Firmware Version angeht der Teil vor dem Datumsstring.

Gibt es hier Neuigkeiten, neue Erkenntnisse?

Ich hab versucht das hier bei einem 842ND v1 nachzustellen und kann Probleme bestätigen. Irgendwie spinnt das Gerät mit der aktuellen Stable Firmware. Ich versuche aktuell noch mehr raus zu bekommen.

1 „Gefällt mir“

@leah ich habe zwei weitere die nach dem Update nicht mehr starten. Nur das Powerlämpchen ist an.
Modell: beide TL-WR841ND v7.2

Ich habe einen weiteren Router der sporadisch Probleme macht:
HD-Hendesse-03 https://map.ffrn.de/#!v:m;n:f4ec38c9c0ba TL-WR1043N/ND v1
http://s.ffrn.de/dashboard/db/nodes?from=1458229886257&to=1458251486257&var-Node=HD-Hendesse-03

Bei ihm ist in unregelmäßigen Abständen nur noch das Powerlämpchen an. Mache ich ihn stromlos läuft er wieder einwandfrei.

Das Problem hing wohl mit diesem Bug zusammen:

Ich baue gerade eine neue Experimental Version in der das Problem gefixt ist auf Basis von Gluon 2016.1.2. Wäre super wenn du testen könntest, ob die Firmware dann das Problem löst. Wenn ja werde ich entsprechende Firmware für den Beta und Stable Branch bauen.

1 „Gefällt mir“

Das werde ich mit Freude testen. Danke Dir.

Habe auch einen betroffenen Knoten (TP WR841N v9.3), der jedoch überhaupt nicht mehr hoch fährt und netzwerkseitig keinerelei Reaktion zeigt.

Wenn man beim Einschalten die Reset-Taste gedrückt hält, dann leutet einige Zeit das Schlosssymbol und er sendet ein paar IP-Pakete raus - ich vermute das ist das TFTP-Server-Discovery, oder?

Gibt es einen internen Trick zur Wiederbelebung und falls nein: Sollte die Bereitstellung eines Images per TFTP problemlos funktionieren?

Verstehe ich das richtig, dass die 0.5.2-20160218 (experimental) das Problem vielleicht nicht hatte, aber dafür die 0.5.2-20160307 (stable)?

Oder dass es zumindest möglich gewesen wäre, dass die experimental Version das Problem nicht hatte, es dann aber in die stable reingekommen wäre?

Falls ja, sollten wir dann nicht das Release-Prozedere ändern? Otto-Normaluser bekommt nämlich einen so gebrickten Knoten selbst mit einer Schritt-für-Schritt-Anleitung nicht wieder zum Leben.

Kann man nicht einfach immer beim Erzeugen einer experimental Version exakt dieselbe als stable bauen, und die dann

  • wegwerfen, wenn Bugs bekannt werden
  • genau diese Version veröffentlichen, wenn keine Bugs gefunden werden?

Ich vermute, gluon unterscheidet sich beim recovery nicht von OpenWRT, daher ist wahrscheinlich das hier die richtige Doku:

Ja, leider. So ein Bug lässt sich aber durch testen quasi nicht finden. Daher kann sowas schon mal passieren. Meiner Schätzung nach sind aber zum Glück maximal 20 Knoten von dem Bug betroffen.

Nein leider geht das nicht, wie in einem anderen Thread schon mal erläutert, braucht es für jeden Branch einen eigenen Build. Das Problem wäre also das Gleiche.

Ich sehe aktuell keinen Bedarf den Prozess an der Stelle zu ändern. Das war jetzt zwar ein unschöner Bug, aber sowas kann passieren. Die neue Firmware war 3 Wochen im Experimental Branch bevor sie Stable wurde. Normal hätten sich da alle Probleme zeigen müssen. Die häufigsten Router hatte ich ja auch vor dem Release getestet. Aber so ist das mit nicht deterministischen Fehlern :(

Um die betroffene Firmware aus dem Verkehr zu ziehen, würde ich darum bitten, das sich alle Betroffenen hier melden.
Dann kann ich die Firmware so lange aus dem Stable und Beta Branch entfernen bis die neue experimental getestet ist. Aktuell ist der Fehler zumindest in Einzelfällen für folgende Geräte gemeldet:

  • TP WR841N v9.3
  • TL-WR841ND v7.2
  • TL-WR1043N/ND v1
  • TL-WR842ND v1

Die aktuelle Experimental Firmware Version ohne diesen Bug ist jetzt bereit. Da ich die so schnell wie möglich nach stable bringen möchte, wäre es super, wenn alle Betroffenen das Update testen würden.

Die potenziell betroffenen Firmware Versionen sind jetzt erstmal deaktiviert worden.

Ich habe drei weitgehend identische TL-WR841 N v9.3 mit benachbarter Seriennummer.

Gerät 1: Bootet gar nicht mehr
Gerät 2: Hatte einen unklaren Ausfall, lebt aber wieder nach Reboot
Gerät 3: Hatte keine Probleme.

Alle standen auf stable+autoupdate. Bei 2+3 kann ich verifizieren, dass ein automatisches Update auf 0.5.2-20160307 erfolgt ist. Zuvor sollten die auf 0.4.5-20151225 gewesen sein.

Wenn es ein Software-Problem ist: Wieso betrifft es nur das eine Gerät?

Ist es wahrscheinlicher, dass das FW-Update bereits fehlschlägt oder gibt es Nodes die erst nach den Update ausgefallen sind?

Das hängt einfach damit zusammen, dass das gleiche Image mal geht und mal nicht geht. Warum es bei manchen Geräten quasi immer und bei anderen quasi nie passiert kann ich dir nicht sagen. Es kann also ein Reboot reichen, und es geht nicht mehr. Wieder einer und es geht. Daher habe ich mich auch dazu entschieden, so bald wie möglich die 0.5.3er Version ausrollen um weitere Probleme zu verhindern.

Umgekehrt hatte ich bislang keinen Erfolg. Mein gebrickter Knoten hat sich auch bei >15 Versuchen nicht ein einziges Mal booten lassen …

Es wird dann wohl auf das TFTP-Recovery hinauslaufen.