TL-WR841N will einfach keine andere Firmware

Hallo zusammen,

ich bin absoluter Freifunk-Neuling, wenn auch im Thema Vernetzung nicht völlig unbedarft. Von der Idee eines offenen Netzes für die nähere Umgebung angetan, war es mir auch die berühmten 16€ für den empfohlenen TL-WR841N wert. Jetzt hab ich das gute Stück hier stehen … und mein Altruismus-Gen nähert sich der Deaktivierung :cry:

Aber der Reihe nach: Zunächst mal habe ich - wie bei aktuellen Bestellungen zu erwarten - Revision 11 erhalten.

 Firmware Version: 3.16.9 Build 160325 Rel.62500n 
 Hardware Version: WR841N v11 00000000

Erfreulicherweise scheint die lokale Community dafür auch bereits eine Firmware anzubieten (wie ich mittlerweile weiss, vor nicht allzu langer Zeit keine Selbstverständlichkeit). Leider war es dann doch nicht so einfach: Die reguläre Firmware-Update-Funktion des Routers meldet nach Upload des oben verlinkten Downloads den Fehler

 Error code: 18005
 Upgrade unsuccessfully because the version of the
 upgraded file was incorrect. Please check the file name.

Nachdem ich erst dachte tatsächlich nur eine falsche Datei genutzt zu haben und vermeintliche Alternativen probiert habe (ohne Erfolg) wurde natürlich fleissig gegoogled, aber eine brauchbare Erklärung oder gar Lösung habe ich dort nicht gefunden.

Was ich jedoch gefunden habe war eine alternative Möglichkeit, das flashen über den failsafe-Modus des Routers machen, der dabei wohl an vordefinierten Adressen einen FTP-Download versucht. Ich habe also ein den Router per Kabel ans händisch konfigurierte Interface (192.168.0.66) angeschlossen und mit dem empfohlenen TFTPD die oben heruntergeladene Datei unter dem Namen wr841nv11_tp_recovery.bin bereitgestellt. Leider gibt es keinen Hinweis darauf dass der Router nach dem Reset (Aus- und Anschalten bei gedrücktem WPS/RESET) diese Datei anfragt. Im Syslog erscheint gar nichts, so dass es wohl auch nicht nur an einem falschen Dateinamen liegt. Da der Router im failsafe-Modus angeblich die IP 192.168.0.86 annimmt, wollte ich dies mal per ping überprüfen, aber zu keinem Zeitpunkt war der Router unter dieser Adresse ansprechbar, spätestens nach dem vollständigen Reboot war er wieder unter der normalen 192.168.0.1 erreichbar (auch über Webinterface). Ich dachte schon, dass ich vielleicht nicht die richtige Taste gedrück hatte und in Wirklichkeit nie im failsafe-Modus gelandet bin, aber das Verhalten der LED (Schloß-Symbol geht an) konnte ich wie in der Beschreibung beobachten.

Nun bin ich also völlig ratlos wie ich aus dem Router einen Freifunk-Knoten machen soll und natürlich auch verunsichert ob ich hier irgendetwas gehörig falsch verstanden habe, mir die super-duper-simpel-Lösung einfach nur entgangen ist oder sich dieser Router (in dieser Revision) wirklich als Sackgasse erweist.

Ich hoffe jemand hat noch einen heissen Tipp für mich …

Gruß, OEi

Hallo @oei,
versuch mal einen Downgrade der Orginalfirmware. Wenn das auch nicht geht, ist das vermutlich ein neues Feature. Ein Bekannter berichtetet ähnliches und erklärte es damit das die neueste TP-Link Firmware einen Ländersignierung überprüft.
Mit TFTP im Wiederherstellungs-Mode soll es über den Umweg der alten Firmware gehen…

Danke für den Hinweis. Als einzige Alternative zu der Version 160325, die bereits installiert war, habe ich eine Version vom 16.6.2015 gefunden. Der Versuch diese über die GUI zu installieren, erbrachte allerdings die selbe Meldung wie oben:

Error code: 18005
Upgrade unsuccessfully because the version of the 
upgraded file was incorrect. Please check the file name.

Wenn die Theorie mit der Signatur stimmt, scheint der Weg zurück also dadurch ebenfalls verbaut zu sein.

Edit: Hab auch die alte Firmware versucht per TFTP zu flashen, aber auch hier war es lediglich das oben beschriebene „scheint nichts zu tun“-Verhalten.

Für das debuggen einer tftp-verbindung hat sich bei mir tcpdump bewährt:

Um zu sehen ob der Router eine ARP-Anfrage macht, also überhaupt den Server im Netz sucht:

tcpdump -ni ethX arp

damit bekommt man auch die IP-Adressen raus, falls da eine Diskrepanz besteht.

Die tftp-verbindung kann man dann mit dem beobachten:

tcpdump -ni ethX udp

Wenn dabei einige hundert packete über die leitung gehen, wenn nur der router angeschlossen ist, dann war die übertragung vermutlich erfolgreich.
Das Log des tftp-servers hilft auch manchmal, vll ist ja die Firmwaredatei nicht am richtigen Platz oder ein symlink falsch gesetzt (…oder alles zusammen, wies mir erging :frowning: )

Alternativ ist auch wireshark eine schöne methode, die Anfragen grafisch zu beobachten.

Vermutlich muss deine Community aktualisieren, damit auch bei WR841 Geräten mit aktueller Hersteller-Frimware ein Update möglich ist.
Dort wird nämlich inzwischen ein „country code“ geprüft - das geht mit gluon zwar, aber erst seit einigen Wochen.

1 „Gefällt mir“

Das klingt in der Tat komisch.
Ich vermute wieder mal ein Problem, mit dem PC, der den wechsel der IP „hinter der MAC des Routers“ nicht mitbekommt „so spontan“.
Hatten wir leider schon mehrmals.

Ich würde vorschlagen, das gemeinsam mit jemanden aus der lokalen VfN-Community mal durchzuprobieren.

@RubenKelevra kann vielleicht da jemanden benennen.

@oei atftp ist oft nicht „schnell“ genug, da bei einem Neustart es etwas dauert bis das Netzwerk reagiert und dann „recht schnell“ die tftp Zeit rum is.
Da hilft wenn beides an einem Switch ist, oder an einem 2.Freifunkrouter - beides an Gelb (in diesem Fall).
Der zu flashenden Router wird in blau eingestöpselt.
hier mein atftp script auszug : ich beobachte gleichzeitig das IF und da sieht man dann sehr schnell ob da was „geht“
… und ja, poweroff und mit reset-tastergedrückt power-on … nach etwa 5-10 sekunden siehste den tcpdump traffic.

# ...
folder=/tftpboot
logf=/var/log/atftp
# ...
sudo touch /var/log/atftp
sudo tail -f /var/log/atftp &
sudo tcpdump -v -i eth0 |grep "192.168.0" &
# muss man später dann seperat killen
# ...
# datei muss ./wr841nv11_tp_recovery.bin heisssen
# und in /tftpboot liegen
#  ...
841)
        # for tplink 841 run with
        sudo ifconfig eth0 up
        sudo ifconfig eth0 192.168.0.66 netmask 255.255.255.0
        sudo atftpd --logfile $logf -v --no-source-port-checking --trace --bind-address 192.168.0.66 --daemon $folder

Versuche bitte mal, den Namen der Freifunk-Firmware Datei umzubenennen. zb in etwas kürzeres wie freifunk11boot.bin und diese hochzuladen

2 „Gefällt mir“

Guten Morgen zusammen,

schon mal vielen Dank für die ganzen Tipps. Ich habe mich mal durchprobiert:

Ich hab den Upload mit kürzeren Versionen des Dateinamens versucht, leider bleibt das Ergebnis dasselbe.

Ich musste zwar einen alten Laptop aus ner staubigen Ecke holen, aber damit konnte ich das ganze unter Linux machen. Ein Vorteil von diesem Gerät ist auch, dass es einen echten Ethernet-Port hat, mein Hauptrechner kann per Kabel nur über einen USB-Adapter netzwerkeln, nicht dass das normalerweise Probleme macht, aber für den Fall hier ist es eventuell ne zusätzliche Fehlerquelle die so auszuschließen ist.

Per tcpdump konnte ich wie erwartet beobachten, dass sich der Router als .86 meldet und nach .66 sucht. Die IP-Adressen waren also soweit richtig. Auch konnte ich beobachten dass direkt nach dem Start eine Datei namens wr841nv11_tp_recovery.bin abgerufen wurde, was ebenfalls dem erwarteten Dateinamen entsprach (und eigentlich auch bereit steht). Der Request wurde aber wohl nicht beantwortet:

192.168.0.86.3270 > 192.168.0.66.tftp:  44 RRQ "wr841nv11_tp_recovery.bin" octet timeout 2 

Das klingt jetzt für mich stark danach was fuzzle sagte, dass die Reaktionszeit von atftp nicht fix genug ist. Ich hatte zwar nicht die Chance mir als „Bremse“ einen Switch dazwischen zu stellen, aber ich habe dann statt als „normalen“ Ubuntu-Service den atftpd genauso gestartet wie in dem Beispielcode, in der Hoffnung dass das explizite Binden an die Adresse und der Verzicht auf den Port-Check den entscheidenden Geschwindigkeitsvorteil bringen.

Zunächst sah es auch wieder nach einem Timeout aus, aber dann schossen kiloweise Pakete durch die Leitung und der Router blinkte … anders. Nach kurzer Zeit war er dann wieder über die 192.168.0.1 erreichbar, aber präsentierte den Einrichtungsassitenten von Gluon!

Ergebnis: Knoten 2549 ist online :grinning:

Nochmals vielen Dank für die Hilfe und weiterhin viel Vergnügen beim freifunken.

Gruß, OEi

5 „Gefällt mir“

er war über 192.168.1.1 erreichbar, hoffe ich / denke ich :slight_smile: schön das esgeklappt hat - freu mich immer wenn da die Bytes so über den Bildschirm rasen (und es entsprechend geklappt hat)

2 „Gefällt mir“

Hm … nö, war 192.168.0.1. Da mein Heimnetz auf 172.16.0.0 läuft gibts da aber auch keine Konflikte, viellecht nimmt er häufig die .1.1 um dem oftmals belegten 192.168.0.0 auszuweichen?

Hallo, ich hab genau dasselbe Problem. Ich habe ebenfalls den WR841N Version 11. Die Firmware von der Freifunk Webseite mag er nicht installieren. Habe auch firmware von anderen Freifunk-Communitys probiert. Gibt es eine einfache Möglichkeit den Router zu flashen, ohne gleich die Linux-Hacker-Keule zu schwingen :wink:

Grüße Simon

Das Problem soll mit der aktuellsten Gluon-Version v2016.2.2 behoben sein. Wann es die als experimental/beta für dein Comunity geben wird, kann nur deine Comunity beantworten.

2 „Gefällt mir“