Von meinem (doch eher laienhaften) Standpunkt aus betrachtet liegt es daran, dass der OpenWRT Backport nicht vollständig war.
Da die Entwicklung von OpenWrt zu Gunsten von LEDE aufgegeben wurde, fehlt die Implementierung der MIPS Machine ID für WR841N-v12 im Kernel. Das führt dazu, dass dieser nicht bootet und mit einem Kernel-Panic hängen bleibt.
Ich habe das dann umgangen, indem ich den Boardnamen der v11er Reihe verwendet habe. Das täuscht dem Kernel beim booten eine v11 Plattform mit geänderter HWID vor. Nach Inaugenscheinnahme des Bootlogs und der Platine konnte ich das auch ruhigen Gewissens tun, denn die Hardwareplattform ist nahezu identisch.
Danke für die Erläuterung.
d.h. unser freiwilliger Tester hatte wirklich keine Chance und allenfalls ein Pushbutton-TFTP hätte das Ding noch retten können „ohne Aufschrauben“.
Das habe ich auch verifiziert. TFTP Recovery war jederzeit noch möglich. Wer also einen, durch meinen ersten Patch gebrickten Router hat, kann diesen mittels TFT Pushbutton wiederherstellen.
Ich habe auch das OpenWRT Wiki um die nötigen Informationen und Bilder ergänzt.
Wenn nochmal jemand probieren möchte (ich selbst habe leider nach wie vor keinen v12er)
(Wenn’ss schief gehen sollte, denn tausche ich dann versandkostenfrei gegen einen v11er. Beim letzten Brick war ich leider unterwegs, so dass ich nicht schnell genug zuschnappen konnte.)
hier aus den config wizard:
Hardware-Modell
TP-Link TL-WR841N/ND v12
Gluon-Version
v2016.2.5-3-g378ef3d
Firmware-Release
2017050319-exp
Site
Freifunk Duesseldorf-Flingern
Könnte einer von euch, nochmal kurz die Patche auflisten, die man auf v2016.2.3 schmeißen muss, damit es läuft? Quasi ein v2016.2.3+WR841V12. Der zuletzt verlinkte Patch ändert quasi die Boardbezeichnung und dann brauche ich vermutlich noch in der Profildatei einen Eintrag für den V12?
Dann könnte das jeder Firmwarekoch für seine Community bauen, ohne sich groß in Master und Lede einarbeiten zu müssen.
Der Patch wird auch auf 2016.2.3 anwendbar sein.
Trotzdem würde ich (wegen der diversen CVEs) empfehlen, von einem 2016.2.5 zu bauen. (Ist aber ein anderes Thema)
Evtl. können wir ja @anon75826926 überreden den Pull Request zeitnah in den 2016.2.x Branch mit aufzunehmen.
Zumal es jetzt ja schon positive Rückmeldungen gibt.
Verdammt @rotanid, Du hast recht. Die zwei von mir gesehenen Kommentare beziehen sich auf ein und den selben Router. Mea culpa.
Aber das ist doch schonmal ein schöne Knospe, welche evtl. im 2016.2.x Branch in voller Pracht erblühen darf und dann schön reif im Release 2016.2.6 geerntet werden kann
Im ernst, ich packe alles was in ./patches/openwrt/ liegt, was mit einer Nummer anfängt und auf .patch endet nur mit der Zange an. Daher hoffe ich irgendwie auf eine kleine Erntehilfe
Wenn dann mal ein v12 bei uns aufschlägt, und mit unserer Experimental geflasht wird, dann werden wir auch berichten.
Ich habe nun v13 sch…ön
V11 geht natürlich nicht und da kommt nun die Frage, soll ich V12 aus diesem Beitrag überhaupt noch probieren?
In der Firmware (Aachen) ist leider nur bis V11 (stable).
Dazu direkt ein Angebot:
Wer schreibt es auf V13 um bzw. kann es umschreiben? Dem schicke ich gerne das Gerät zu (nur Deutschland natürlich) damit er alles durchtesten kann.
Kurz zusammengefasst: LEDE läuft zwar schon, der WLAN Treiber ist aber noch hochgradig instabil, so dass eine Unterstützung derzeit noch keinen Sinn macht. Wir müssen weiter hoffen, dass hier treiberseitig was passiert. Es ist jedenfalls eine komplett andere Hardwarebasis als die Vorgänger, d.h. v12 wird nicht laufen.
Wow, danke für die Blitzantwort. Den Beitrag hatte ich nicht gefunden.
Egal, dann gehe ich sofort mal lesen
Hmmm, ist die neue Hardware-Basis ok?
Sonst jage ich den v13 zurück und schaue mal ob ich v11 noch bekommen kann, aber ich denke mal die werden dann gerade gefragt sein.