[Problem] 6490 ohne ansprechbaren Bootloader

[_web_]

Moin,

ich habe die Dämlichkeit begangen eine Fritzbox 6490 über eBay zu kaufen ohne auf mich mit dem Problem das Brandings dieser Boxen auseinder zu setzen. Nachdem ich nun eine funktionstüchtige Vodafone - Firtzbox hatte, wollte ich diese Debranden. Dabei habe ich zwei Fehler gemacht. Zum einen habe ich mir einer dieser Filmchen angeguckt wie man das machen könnte und es auch über EVA mit mäßigen Erfolg versucht.

Danach war die Box in einen Bootloop, ich konnte aber noch auf den FTP Server zugreifen.
Der zweite Fehler, war es die Firmeware wiederherstellen zu wollen. Dafür hatte ich die Anleitung von Triebwerk (https://www.triebwerk23.de/joomla/index.php/firewalls/fritzbox-6490-cable-reset-bei-bootloop) verwendet. Das lief auch recht problemlos bis zum restart der Box.
Danach konnte ich auch nicht mehr auf EVA zugreifen. Wenn ich die Box starte blinkt einige Sekunden später sofort die Info Lampe rot (immer vier Mal und danach eine Pause, bevor es wieder von vorne beginnt). Wenn ich die Fritzbox Recover Tools von AVM für ein anderes Modell oder eva_discover von YourFritz verwende, leuchtet kurz wieder die Power - Leuchte, bevor es wieder die Info leuchte blinkt.

Wahrscheinlich hatte hier schon irgendwann jemand diese Problem beschrieben und ich habe es nicht gesehen. Es ist nur meine Frage, ob man die Box wiederbeleben kann und wenn ja, wie oder ob ich den Kauf unter Lehrgeld verbuchen kann und sie auf dem Dachboden packe?

Vielen Dank,
Sascha

 

[stoney]

Wahrscheinlich hatte hier schon irgendwann jemand diese Problem beschrieben und ich habe es nicht gesehen.

stimmt, denn eine Suche zum Beispiel beim großen G mit "site:ip-phone-forum.de 6490+bootloop" fördert einiges zu Tage

Desweiteren sind Dein genaues Vorgehen (incl Terminallogs) anzugeben, sowie die daraus entstandenen Dateien (es scheint als hättest Du ein "curuppted file" erzeugt und geflasht - also das TFFS [dieses wäre sicherlich das interessanteste zu Beginn] aber wenig verwunderlich bei solchen "Anleitungen" wo zB die 192.168.178.1 als Notfall-IP bezeichnet wird..)

Es liest sich aber fast so, als hättest Du einen Briefbeschwerer, ich selbst hatte bzw habe da eine Box mit einem ähnlichem Verhalten rote Info LED nach Werkseinstellungen und ändern der Bootpartition (6490)

Kennst Du diesen Thread bzw dieses HTD bereits?
[HowTo] Ändern des Branding und installieren der Retail-Firmware bei FRITZ!Box Cable 6490

 

[NDiIPP]

Der zweite Fehler, war es die Firmeware wiederherstellen zu wollen. Dafür hatte ich die Anleitung von Triebwerk (https://www.triebwerk23.de/joomla/index.php/firewalls/fritzbox-6490-cable-reset-bei-bootloop) verwendet.

Blöd vor allem deshalb, da es auch noch die falsche Anleitung für dein Problem war (die Betonung liegt auf war, u.U. nun vielleicht nicht mehr). Die verlinkte Anleitung stellt auch nicht die Firmware der Box wieder her. Ein neues TFFS-Image zu Erstellen und hochzuladen (das beschreibt diese Anleitung) hilft schließlich überhaupt nicht weiter, wenn sich die Box lediglich wegen einer falsch eingestellten "Branding-Variable" in einem Bootloop befindet (zumindest wenn im neu erstellen TFFS-Image weiterhin ein unpassender Wert für die Branding-Variable verwendet wird).

Es hätte geholfen, einfach nur den Wert dieser Variable wieder passend zu ändern oder eine Firmware (per Bootloader) zu flashen, die die eingestellte Branding-Variable unterstützt.


Ich weiß ehrlich gesagt nicht, was passiert wenn man in mtd3+4 ein "ungültiges" TFFS-Image flasht (also ob dann wenigstens noch der Bootloader hochkommt und man ein neues TFFS-Image hochladen kann um die Box zu retten). Verständlicherweise habe ich das selbst noch nicht (freiwillig) ausprobiert.
Ich bzw. wir wissen auch nicht, ob das von dir erstellte TFFS-Image tatsächlich richtig gebaut wurde (da gab es ja in der Vergangenheit auch schon Stolpersteine dabei) oder dieses tatsächlich auch "nur" in mtd3+4 hochgeladen wurde (und vielleicht nicht versehentlich versucht wurde bspw. in mtd2 zu schreiben, was der Bootloader selbst wäre). Daher unterstreiche ich hiermit auch noch einmal den Hinweis von @stoney aus #2 bzgl. der Terminal-Logs von deiner durchgeführten Aktion.

Wenn man bspw. von einem "mtd2-Unfall" ausgeht und der Bootloader es nicht verhindert hat (das ist wohl auch von der Bootloader-Version abhängig, da könnte es Unterschiede geben), dass er überschrieben wird, wäre das quasi der ungünstigste Fall (die Box könnte dann aber immerhin noch als Türstopper oder Briefbeschwerer weiterverwendet werden).

Also ich würde als erstes noch einmal überprüfen, ob der Bootloader tatsächlich nicht mehr erreichbar ist:
https://www.ip-phone-forum.de/threads/wie-recovere-ich-eigentlich-richtig.299790/

Wenn tatsächlich nicht, dann halt s.o. (Türstopper/Briefbeschwerer).

 

[wutz65]

Wurden vor den Flashversuch erweiterte Supportdaten erstellt (damit wäre die Box vielleicht noch zu retten)?
Wenn mtd3 und mtd4 gelöscht wurden ist die Box-Mac-Adresse verstellt und die Box nicht direkt über die IP-Adresse ansprechbar.

(Schreibfehler Wurden)

 

[stoney]

Für Supportdaten ist es ja leider zu spät, daher wäre es interessant, "wie" das erstellte TFFS-Image nach dem Bau aussieht, sowie was ein "RETR env" ausspuckt (wenn man den Loader wieder erreichen sollte).

 

[PeterPawn]

Ich nutze die Gelegenheit gleich noch einmal, um darauf hinzuweisen, daß ich meinerseits bei "Einführuing" von "build_tffs_image", um sich mit den Dateien aus YourFritz/master/tffs ein neues Image zu bauen, auch noch ein komplementäres Skript zur Verfügung gestellt habe, weil man das selbst erzeugte Image VOR der Anwendung einfach noch einmal (mittels "dissect_tffs_dump") in seine Bestandteile zerlegen und das Ergebnis mit den Eingabedaten für "build_tffs_image" vergleichen sollte.

Erst wenn dabei in beiden Richtungen keine Fehler und keine Unterschiede auftauchen (außer welchen, die man sich erklären kann, wie z.B. den fortlaufenden Wert im Segment-Header), kann man davon ausgehen, daß weder das Skript, noch man selbst einen Fehler beim Zusammenbau des Images gemacht hat.

Insofern bin ich auch mit der "Spiegelung" des Repo-Inhalts aus dem Mai 2017 unter der URL der oben verlinkten Anleitung nicht so ganz glücklich, weil die natürlich die Korrekturen für die Fehler, die ich danach in diesen Dateien erkannt (ggf. erst nach entsprechenden Fehlermeldungen durch Benutzer) und mittlerweile geändert habe (z.B. das fehlende Erstellen der Name-Table in "dissect_tffs_dump"), nicht bereitstellt.

Das gilt ja auch nicht nur für diese letzten Änderungen ... wenn sich bei AVM tatsächlich etwas Grundlegendes ändert, kann ich darauf nur in den Dateien reagieren, die auch von mir bereitgestellt werden. Da sind solche "vagabundierenden Kopien" dann wenig hilfreich - man könnte das ja auch einfach in einem eigenen GitHub-Repo "lagern" und dort die Änderungen für die Anpassung auf "nur noch auf Debian-Systemen zu gebrauchen" vornehmen - das kann man dann (von GitHub) auch wieder automatisch zu einer ZIP-Datei zusammenpacken lassen. Dann hat man aber wenigstens noch die Möglichkeit, die anderen Änderungen jeweils nachzuziehen und bietet tatsächlich den neuesten Stand (oder zumindest einen irgendwann auch mal aktualisierten) an.

 

[_web_]

Vielen Dank für die Antworten. Ich bin tatsächlich sehr blauäugig an die Sache gegangen, ohne ein klares Verständnis der Materie zu haben.

Hier der Ausschnitt aus meiner bash_history

ftp 192.168.178.1
ls
mkdir fritzbox
git clone  https://github.com/PeterPawn/YourFritz
cd fritzbox/
ls
cd ..
cd YourFritz/eva_tools/
./eva_get_environment env 192.168.178.1 > ~/fritzbox/env.txt
cat eva_get_environment
vi eva_get_environment
./eva_get_environment env 192.168.178.1 > ~/fritzbox/env.txt
./eva_get_environment count 192.168.178.1 > ~/fritzbox/count.txt
ftp 192.168.178.1
./eva_get_environment env 192.168.178.1 > ~/fritzbox/env.txt
./eva_get_environment count 192.168.178.1 > ~/fritzbox/count.txt
cd ../tffs/
ls
vi build_tffs_image
./build_tffs_image tffs_name_table ~/fritzbox/env.txt ~/fritzbox/count.txt > ~/fritzbox/mtd.img
ls
./build_tffs_image name_table_from_tffs ~/fritzbox/env.txt ~/fritzbox/count.txt > ~/fritzbox/mtd.img
cd ../eva_tools/
ls
ftp 192.168.178.1
./eva_store_tffs mtd3 ~/fritzbox/mtd.img
vi eva_store_tffs
./eva_store_tffs mtd3 ~/fritzbox/mtd.img
./eva_store_tffs mtd4 ~/fritzbox/mtd.img
ifconfig
ping 192.168.178.1

Im Anhang befinden sich die gezippten erzeugten Dateien. Scheinbar ist die env.txt leer. Ich meine, dass ich damals Daten drine hatte, allerdings weiß ich nicht mehr wo sie sind. Außerdem habe ich im YourFritz - Repository eva_get_environment_session.log und die eva_store_tffs.log gefunden und die mitverpackt.

Ich werde mir die erwähnten Forums - Threads durchlesen und mal schauen, ob ich irgendwie mit der Box noch kommunizieren kann.

Viele Grüße,
Sascha

- edit -

Ich habe mit dem vi nur die das Bash - Skript auf /bin/bash geändert.

 

[NDiIPP]

Die mtd.img in deiner ZIP-Datei wurde tatsächlich mit einer leeren env.txt gebaut. Also hast du wohl tatsächlich ein korruptes TFFS-Image in mtd3+4 hochgeladen.

Aber eigentlich müsste der Bootloader dennoch erreichbar sein, aber vermutlich nicht mehr per "fester" 192.168.178.1... Siehe dazu der Link am Ende von Beitrag #3.

 

[_web_]

Das hatte ich mir schon fast gedacht, ich hatte es nicht gesehen. Ich habe mehrere statische IPs ausprobiert, allerdings kein Erfolg. Wie in dem Recovery Thread beschrieben, scheint die AVM Recovery Tools die Box kurzzeitig zu beleben und ich sehe, dass die Power Leuchte wieder anspringt. Nach 10 Sekunden blink allerdings wieder die Info - Leuchte.

 

[stoney]

Bist Du dem ersten Link aus #2 gefolgt?

Darin ist recht genau erklärt, wie Du die Box wieder erreichen kannst falls diese auch eine/diese ominöse MAC (bekommen)hat (wenn Du - wenn ich mich richtig erinnere - einen Paketmitschnitt des LANs der 6490 anfertigst - so aus dem Kopf heraus, genau steht's ja im verlinkten Thread)- Stichwort: arp

//edit: hab doch noch mal selbst durchgeblättert...

Durch setzten von

sudo arp -s 192.168.178.1 C8:0E:14:xx:xx:xx

also der richtigen maca (steht ja als CM MAC auf der Box und im ruKernel Log war sie ja auch noch)


Ist die Box wieder per 192.168.178.1 erreichbar (./eva_discover mit HOLD=1 hält die Box im Bootloader - ftp sowie ping funktionieren auch) adam2 zugriff möglich

 

[_web_]

Da war ich noch nicht allerdings bekomme ich ein 'SIOCSARP: Invalid argument' wenn ich das Command ausführe. Ich muss dazu sagen, dass ich auf einer Windows - Kiste mit Ubuntu - Shell unterwegs bin. Vielleicht kann es nicht den Netzadapter so einstellen. Ich werde mir den Thread noch genauer angucken.

Vielen Dank für die Hilfe!

 

[stoney]

Versuchen Sie, die Schnittstelle mit anzugeben -i. Wenn dies nicht funktioniert, versuchen Sie wahrscheinlich, einen MAC-Eintrag für Ihre eigene IP-Adresse hinzuzufügen

was gibt

ifconfig

aus?

PS: poste am Besten Dein Vorgehen - Terminallog, sodass jeder genau weiß was Du wie gemacht hast

 

[_web_]

Hier meine Ausgabe. Ich habe die MAC Adress wegge-x-t:

sascha@LAPTOP-FV0P505I:~$ sudo arp -i eth0 -s 192.168.178.1 C8:0E:14:XX:XX:XX
SIOCSARP: Invalid argument
sascha@LAPTOP-FV0P505I:~$ ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.178.10  netmask 255.255.255.0  broadcast 192.168.178.255
        inet6 fe80::a15f:67ef:f478:1ad8  prefixlen 64  scopeid 0xfd<compat,link,site,host>
        ether 98:29:a6:33:41:cf  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 1500
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0xfe<compat,link,site,host>
        loop  (Local Loopback)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Leider weniger Erfolg. Ich werde den erwähnten Thread weiterlesen.

 

[stoney]

Ob das an Deinem verwendeten (Sub)System liegt, weiß ich leider nicht (auf Raspbian funktioniert es Problemlos - ebenso auf W7 64bit das unten gezeigte Beispiel)
was sagt denn ein

arp -e

Hast Du das ganze vom Windows(Host) aus mal probiert (feste IP 192.168.178.2)

arp -s 192.168.178.1 11-22-33-44-55-66
arp -a

 

[_web_]

Ich konnte es jetzt unter Windows hinzufügen. Allerdings kann ich die IP nicht pingen und ich kann auch keine ftp - Verbindung aufbauen. eva_discovery sagt auch, dass es nichts findet und die AVM Recovery - Tools können die Version nicht auslesen.

PS C:\WINDOWS\system32> arp -a

Schnittstelle: 192.168.178.10 --- 0x4
  Internetadresse       Physische Adresse     Typ
  192.168.178.1         c8-0e-14-xx-xx-xx     statisch

Sie scheint mir tot zu sein.

 

[stoney]

die AVM Recovery - Tools können die Version nicht auslesen.

Bitte den Log des Recoverytools posten, wenn dies beim Auslesen "stehen" bleibt, müsste die Box im Bootloader "stehen" und dieser via FTP erreichbar sein

 

[PeterPawn]

Es hat auch niemand behauptet, daß nach dem Hinzufügen des ARP-Eintrags ein "ping" funktionieren MÜSSE - was soll also der Unsinn?

Das Kommando dient nur dazu, dem Host jetzt statisch mitzuteilen, welche MAC-Adresse er in die Pakete setzen soll, wenn es sich um IP-Pakete für die Adresse 192.168.178.1 handelt. Das wird dann stumpf anstelle der ansonsten fälligen ARP-Abfrage (per L2-Broadcast) verwendet, auf die bestimmte 6490 mit defektem TFFS nicht mehr richtig antworten.

Wer zuerst mal feststellen will, ob es sich hier tatsächlich um dieses Problem handelt, der schneidet den Netzwerkverkehr zwischen PC und Box mit und schaut, ob die Box auf eine ARP-Anfrage für die 192.168.178.1 (oder welche Adresse man auch immer per UDP-Broadcast - aka "eva_discover" - gesetzt hat) auch mit einer falschen Adresse (die hexadezimal mit 30:78:30:30:2C:20 übereinstimmt, was das Äquivalent zur Zeichenkette "0x00, " ist) antwortet.

Dazu muß natürlich der ARP-Eintrag nicht vorhanden sein, weil sonst keine Abfrage per Broadcast erfolgt.

Erst dann, wenn man tatsächlich sicher ist, daß das Problem an der falschen MAC-Adresse in der ARP-Antwort liegt (die Box "hört" nämlich nur auf die richtige MAC-Adresse und nicht auf dieses offensichtliche Ergebnis eines Buffer-Overflows), macht das Hantieren mit dem ARP-Kommando Sinn.

Ansonsten macht man mit unsystematischem "Herumprobieren" nur noch mehr kaputt, als durch das Schreiben des falschen TFFS-Images.

Wer das bis hierhin in diesem Thread einigermaßen aufmerksam liest, bemerkt eben auch, daß mit Dir noch nicht einmal geklärt wurde (und auch von Dir wurde es mit keinem einzigen Wort erwähnt), welche der vielen MAC-Adressen, die eine 6490 nun mal hat, von Dir im ARP-Kommando eigentlich verwendet wurde.

Und nur mal nebenbei ... ich bin ja auch für Datenschutz zu haben, aber das Ausixen der MAC-Adresse einer FRITZ!Box, von der man selbst glaubt, daß sie ohnehin nicht mehr funktioniert, ist schon einigermaßen widersinning. Die meisten würden hier wohl eher die komplette Liste der MAC-Adressen ihrer nicht mehr erreichbaren 6490 einstellen ... einfach in der Hoffnung, daß ihnen doch noch geholfen werden könnte.

------------------------------------------------------------------------------------------------------------------------------------

Ich persönlich habe aber mit:

Sie scheint mir tot zu sein.

auch kein Problem (das meinte ich auch im letzten Absatz mit dem eigenen Glauben an den Erfolg) ... nur finde ich es irgendwie abstrus, dann weiterhin diesen toten Gaul zu reiten.

Entweder man bringt den notwendigen Enthusiasmus und Optimismus mit (daß hier ganz offensichtlich ein falsches TFFS-Image geflasht wurde, dürfte inzwischen ja klar sein als Ursache des ganzen Kuddelmuddels - damit muß man das Kind mit der Flinte und dem Korn ja noch nicht automatisch in den Brunnen werfen) und versucht mit den Leuten hier gemeinsam die Box wiederzubeleben ... oder man stellt sich hin mit der oben zitierten Feststellung.

Nun darfst Du mal raten, welche Haltung die "Tippgeber" eher dazu animiert, sich weiter mit Dir und Deinem Problem zu befassen - auch für die ist es ja eher unbefriedigend, wenn man mitten im Fluß versucht, die Pferde zu wechseln oder es sich plötzlich dann doch wieder anders überlegt. Das notwendige Vertrauen, daß es eben nicht zu einem solchen unvermittelten "Abbruch" kommt, erzeugt man eher nicht mit solchem verbalen "Hängenlassen des Kopfes".

 

[_web_]

Das Log sieht recht ergebnislos aus:

FRITZ!Box 6810 LTE suchen an: 192.168.178.1
Eine Anlage gefunden! - Ermitteln der aktuellen Version.
Auslesen der Version gescheitert!

Wenn ich versuche in dem Zeitraum auf den Bootloader zuzugreifen passiert nicht viel:

sascha@LAPTOP-FV0P505I:~$ ftp 192.168.178.1
ftp: connect: Connection timed out
ftp> exit
sascha@LAPTOP-FV0P505I:~$ ftp 192.168.178.1
ftp: connect: Software caused connection abort
ftp> exit

Diese beiden Typen von Fehler bekomme ich auch, wenn das AVM Tool nicht läuft.

-- Aktualisiert --

Es geht mir nicht darum etwas hinzuschmeißen, allerdings ist mein Wissen von Netzwerk - Technik geschränkt und somit hantiert ich als Anfänger auf diesem Gebiet an dem Router rum.

Ich habe die CM Mac - Adresse verwendet, die hinter auf der Box steht und diese statisch mit arp hinzugefügt. Ich kann auch versuchen mit Wireshark etwas mitzuschneiden, oder gibt es eine bessere Möglichkeit, um ein mögliches Signal der Box abzufragen?

Es geht mir nicht darum pessimistisch zu sein, nur leider bekomme ich es nicht hin irgendwie mit der Box zu kommunizieren und das ist leider frustrierend. Eure Hilfe ist allerdings deutlich mehr, als ich erwarten konnte und ich danke dafür! Ich werde weiter versuchen sie zu Leben zu erwenken, so lange ich Ideen haben, wie es funktionieren könnte.

 

[PeterPawn]

Ich habe die CM Mac - Adresse verwendet, die hinter auf der Box steht und diese statisch mit arp hinzugefügt.

Das dachte ich mir fast ... nur sollte (solange der Bootloader nicht einfach alle MAC-Adressen setzt, ich weiß nicht, was der Switch-Baustein da kann und ich bin nicht sicher, wie der Bootloader es handhabt) es eben die "maca" sein und die ist i.d.R. nicht mit der CM-MAC identisch. Wenn man sie nicht mehr auf anderem Weg herausbekommt (irgendwelche alten Protokolle), steht sie entweder im CWMP-Account (im hinteren Teil) oder man muß die zwei bekannten Schemata halt "durchprobieren". Welche Reihenfolge bei der Vergabe ich kenne, habe ich für @stoney mal in dem (ganz am Beginn dieses Threads) verlinkten Thread aufgeschrieben.

Wenn ich bisher bei irgendwelchen Boxen mit diesem Problem konfrontiert wurde (ich habe auch schon ein paar zerwürgte Boxen von eBay auf diesem Weg wieder zum Leben erweckt), dann hat das bisher jedenfalls immer mit der "maca" funktioniert - u.U. steht diese auch auf dem Schild an der FRITZ!Box-Kiste, das sich auch mal (vom Umfang der Infos her) von dem auf der Rückseite der Box unterscheiden kann.

Aber wie bereits festgehalten ... das Setzen per "arp"-Kommando macht erst dann Sinn, wenn man sicher weiß, daß es sich auch um das richtige Problem handelt.

Dazu entfernt man die statischen ARP-Einträge auf dem Host-System und startet einen Paketmitschnitt ... wenn man Windows verwendet, eben einen mit "Wireshark" am besten.

Danach benutzt man das "EVA-Discovery.ps1"-Skript, wenn man mit Windows arbeitet ... das stellt erstens die Box auf die angegebene Adresse ein und versucht dann (anders als die Linux-Versionen der Skripte) gleich noch, die FTP-Verbindung herzustellen. Da diese über die IP-Adresse erfolgen muß, gibt es dann auch bereits dabei die passende ARP-Abfrage für die verwendete IP-Adresse ... und die FRITZ!Box sollte darauf dann auch irgendwie reagieren, aka "antworten". Die in dieser Antwort enthaltene Adresse (und zwar die aus dem Payload und nicht aus den L2-Headern) ist diejenige, die mit der Zeichenkette "0x00, " zu vergleichen ist.

 

[_web_]

Ich bin heute leider nicht dazugekommen etwas mit der Box zu machen. Ich werde es morgen so versuchen, wie du es beschrieben hast und mir einmal genauer den erwähnten Thread von @stoney anschauen. Vielen Dank für die Tipps!