[Problem] Fritzbox 7590 bootet nicht mehr, defekt.

[Recover_Image]

@NDiIPP
linux_fs_start 1 habe ich gesetzt und wird auch mit GETENV bestätigt.
Das verhalten der Box bleibt gleich, die Box bleibt in einer Bootschleife.
Es spielt auch keine Rolle welches Recoverimage, ob 6.xx oder 7.xx .
Das mit dem rKt weiß ich nicht.

Wie kann ich das Environment auslesen? Irgendwie finde ich da nur Telnet befehle zu "cat /proc/....".
quote GETENV firmware_version ist avm, provider ist provider.

@decorR
So wie du es beschreibst mache ich es.
Ich habe die Box auch schon stundenlang so gelassen, es ändert sich nichts und bleibt in dieser Bootschleife leider hängen.

Netzwerkeinstellungen sind momentan auf 10mbit halfdublex, aber das hilft auch nicht.
Die Firewall ist auch aus.

 

[NDiIPP]

linux_fs_start 1 habe ich gesetzt und wird auch mit GETENV bestätigt.
Das verhalten der Box bleibt gleich, die Box bleibt in einer Bootschleife.

Das habe ich auch nicht anders erwartetet solange anschließend nicht gleich das Recovery-Tool verwendet wird. Aber das hast du ja anscheinend auch schon versucht oder? Was meldet eigentlich das Recovery-Tool überhaupt (siehe unten bzgl. der Variable "provider")?

Wie kann ich das Environment auslesen? Irgendwie finde ich da nur Telnet befehle zu "cat /proc/....".

Das AVM Recovery-Tool macht das bspw. folgendermaßen:

220 ADAM2 FTP Server ready
USER adam2
331 Password required for adam2
PASS adam2
230 User adam2 successfully logged in
SYST
215 AVM EVA Version 1.10211 0x0 0x46409
TYPE I
200 Type set to BINARY
MEDIA SDRAM
200 Media set to MEDIA_SDRAM
P@SW
227 Entering Passive Mode (169,254,19,1,12,0)
RETR env
150 Opening BINARY data connection
226 Transfer complete
USER adam2
331 Password required for adam2
PASS adam2
230 User adam2 successfully logged in
SYST
215 AVM EVA Version 1.10211 0x0 0x46409
TYPE I
200 Type set to BINARY
MEDIA SDRAM
200 Media set to MEDIA_SDRAM
P@SW
227 Entering Passive Mode (169,254,19,1,12,0)
RETR count
150 Opening BINARY data connection
226 Transfer complete
BYE
221 Thank you for using the FTP service on ADAM2
221 Goodbye.

[...]

(Also per "RETR env".)

provider ist provider.

Ist diese Variable tatsächlich vorhanden? Wenn ja, dann müsste doch das Recovery-Tool seine Arbeit verweigern...

 

[Recover_Image]

Das ist das Log des recovery Tools:

FRITZ!Box 7590 suchen an: 169.254.233.1
Eine Anlage gefunden! - Ermitteln der aktuellen Version.
Version erfolgreich ermittelt!
    Hardware: FRITZ!Box 7590
    Urlader: 4258
    Firmware: 154.06.83
Flashbereich (mtd8)
    Lösche Flashbereich (mtd8)
    Restauriere Flashbereich (mtd8)
    Restauriere Flashbereich (mtd1)
FRITZ!Box 7590 erfolgreich wiederhergestellt!
Die Wiederherstellung ist nach einem Neustart des Gerätes abgeschlossen.

Soll ich bei Provider was anderes setzen?
Die Firmware wird aber geflasht, denn es steht ja immer die da die ich flashe 6.xx bzw 7.xx.
Fals was schief geht steht bei Firmware recovered=2.

SYST funktioniert bei mir nicht(Windows CMD FTP Client).

 

[NDiIPP]

Soll ich bei Provider was anderes setzen?

Nee, die Variable dürfte gar nicht existieren (wenn die Box kein Provider-Additive besitzt). Irgendwas stimmt da einfach nicht, denn wenn es diese Variable tatsächlich geben sollte, dürfte das Recovery-Tool gar nicht erst mit der Arbeit anfangen... Aber das Recovery-Tool scheint ja zu arbeiten, demnach kann es eigentlich auch nicht sein, dass es diese Variable überhaupt gibt...

SYST funktioniert bei mir nicht(Windows CMD FTP Client).

Sollst du ja auch nicht machen, war ja nur als Beispiel gedacht, wie es das Recovery-Tool macht. Der relevante Befehl ist "RETR env". Ansonsten kann man auch das Shell-Script "eva_get_environment" oder das PowerShell-Script "EVA-FTP-Client.ps1" verwenden zum auslesen des Environment.

 

[Recover_Image]

Das "EVA-FTP-Client.ps1" habe ich auch mal ausprobiert.

Wenn ich mit ".\EVA-FTP-Client.ps1 -ScriptBlock { BootDeviceFromImage -filename .\bla....image.in-memory}" ein Image hochladen möchte kommt: "Error uploading image file". Scriptblock.Invoke

 

[NDiIPP]

Wenn ich mit ".\EVA-FTP-Client.ps1 -ScriptBlock { BootDeviceFromImage -filename .\bla....image.in-memory}" ...

Nee, ich meine doch ".\EVA-FTP-Client.ps1 -ScriptBlock { GetEnvironmentFile }".

... kommt: "Error uploading image file". Scriptblock.Invoke

Wobei das wiederum darauf hindeutet, dass du eine zu alte PowerShell-Version verwendest. Man muss mindestens die PowerShell Ver. 5.1 verwenden.

 

[Recover_Image]

Installiere jetzt erstmal Powershell 5.1.

 

[Recover_Image]

Ist das mit dem mtd7 so korrekt?
Die Daten stimmen auf jeden Fall mit dem was unten auf der Box steht überein.

HWRevision            226
HWSubRevision         4
ProductID             Fritz_Box_HW226
SerialNumber          J394xxxxxxxxxxx
annex                 B
autoload              yes
bootloaderVersion     1.3258
firstfreeaddress      0x852852B0
firmware_info         154.07.10
firmware_version      avm
flashsize             nor_size=0MB sflash_size=0KB nand_size=512MB
linux_fs_start        1
maca                  E0:28:6D:65:E2:59
macb                  E0:28:6D:65:E2:5A
macwlan               E0:28:6D:65:E2:5B
macwlan2              E0:28:6D:65:E2:5C
macdsl                E0:28:6D:65:E2:56
memsize               0x08000000
mtd0                  0x0,0x2C00000
mtd1                  0x500000,0xD00000
mtd2                  0x0,0x100000
mtd3                  0x100000,0x500000
mtd4                  0xD00000,0x1500000
mtd5                  0x1500000,0x20000000
mtd7                  ê
my_ipaddress          169.254.233.1
prompt                Eva_AVM
provider              provider
tr069_passphrase      qDiXzX1gwzUk
tr069_serial          00040E-E0286D65E259
usb_board_mac         E0:28:6D:65:E2:57
usb_device_id         0x0000
usb_device_name       USB DSL Device
usb_manufacturer_name  AVM
usb_revision_id       0x0000
usb_rndis_mac         E0:28:6D:65:E2:58
webgui_pass           xxx
wlan_key              xxx
wlan_ssid             FRITZ!Box#7590#WM

 

[NDiIPP]

WTF, da stimmt ja einiges nicht.

• Die Variable "memsize" müsste den Wert "0x20000000" haben und nicht "0x08000000"
• Die Variable "mtd7" dürfte nicht existieren (das stimmt also nicht um deine Frage zu beantworten)
• Die Variable "my_ipaddress" müsste den Wert "192.168.178.1" haben und nicht "169.254.233.1" oder "99.88.77.1"
  (Wobei der Wert dieser Variable die Probleme nicht erklärt und der Wert "99.88.77.1" vom rKt gesetzt wurde, das ist also eher "Beiwerk")
• Die Variable "provider" existiert. Alleine das ist sehr verwunderlich, da das Recovery so seine Arbeit gar nicht erst tun dürfte aber es scheint dennoch zu arbeiten... Was ist das eigentlich genau für eine Box? Woher stammt die? Artikel-Nr.? Hatte die vielleicht doch mal ein Provider-Additive oder ist diese Variable auch nur ein Fehler ähnlich wie die Variable "mtd7"?

Kurzum, irgendwas wurde da vielleicht bei den verschiedenen Versuchen zerschossen... Ich würde versuchen entweder mal ein neues TFFS-Image zu bauen (mit einem korrigierten Environment) und dieses hochzuladen oder die entsprechenden Variablen einzeln manuell zu korrigieren (per SETENV und UNSETENV).

 

[KunterBunter]

WTF, da stimmt ja einiges nicht.

• Die Variable "memsize" müsste den Wert "0x20000000" haben und nicht "0x08000000"
• Die Variable "mtd7" dürfte nicht existieren

Eine weitere Ungereimtheit: Beim Recover-Versuch in #23 wird in mtd8 geschrieben.
Wie lautet denn die Artikel-Nummer der Box auf dem Typenschild und wo wurde sie gekauft?

 

[chilango79]

Nochmal woher hast du die Box. Ist das eventuell eine internationale?

 

[Recover_Image]

Also die Artikelnummer ist 2000 2784.
Die Box ist eine für Deutschland.

Sie wurde von mir gekauft im Mediasaturn Markt, welcher von beiden weiß ich nicht mehr genau.

Die Box war Original verpackt, die Aufkleber waren auch in Ordnung. Die war auf jeden Fall neu.

Die Box lief auch zuverlässig und ein oder zwei Updates hat sie auch mitgemacht.

Wie könnte es jetzt weiter gehen?

Provider habe ich jetzt mal rausgenommen.
Wie kann ich die Partitionstabelle reparieren?

 

[Goggo16]

Hi,

nur eine Idee. Kann auch Mumpitz sein: Könnte es sein, dass das/die Recover-Images wegen eines Signaturproblems nicht angenommen werden?

Irgendwo auf der ersten Seite war zu lesen, dass Du alle Recover-Images ab 6,83 versucht hast. Es scheint ja so, dass nach jedem Versuch das Verhalten unveraendert bleibt, ergo die Recover Image(s) werden nicht angenommen.

Mir ist so dunkel in Erinnerung, dass ab 6.50 ein Signatur-Check eingefuehrt wurde, der im Zweifel einen FirmwareUpdate ablehnt. Ob das auch fuer Recover gilt, weis ich nicht. Vielleicht mal ein Recover vor 6.49 versuchen.

LG, Goggo

 

[stoney]

Ein so altes Recovery gibt's für die 7590 nicht, wenn man davon aus geht, dass die Box mit FW 6.83 auf den Markt kam.

Außerdem geht das Recovery wie bereits seit längerem bekannt ist, direkt über den Bootloader und diesen interessiert die Signatur nach wie vor nicht.

 

[NDiIPP]

Eine weitere Ungereimtheit: Beim Recover-Versuch in #23 wird in mtd8 geschrieben.

Nein, das ist praktisch "normal". Das behauptet das AVM Recovery-Tool zumindest bis heute wenn das neue TFFS-Image tatsächlich in "mtdnand" (anstatt mtd3 und mtd4 bei den Boxen wo das TFFS noch im NOR-Flash liegt wie bspw. bei einer 7490) geschieben wird.

Mir ist so dunkel in Erinnerung, dass ab 6.50 ein Signatur-Check eingefuehrt wurde, der im Zweifel einen FirmwareUpdate ablehnt.

Das gilt nicht beim flashen über den Bootloader! Also nein, kann nicht sein.

Edit:

Wie kann ich die Partitionstabelle reparieren?

Die scheint doch in Ordnung zu sein Ach so, ich vergaß "mtd7". Wenn du die Variable "memsize" meinst, wenn es manuell nicht geht, bleibt wohl nur noch der Versuch, selbst ein neues TFFS-Image zu erstellen und dieses hochzuladen.

Edit 2:
Wobei das mit der memsize doch nicht ganz ungewöhnlich zu sein scheint:

Außerdem ist mir noch ein Unterschied aufgefallen (das erste Mal, daß ich da wirklich genau hingesehen habe) ... der Bootloader verwendet im FTP-Server unterschiedliche Angaben für "memsize", je nachdem, wie man das abfragt. Ruft man das komplette Environment über "RETR env" ab, stehen dort 128 MB drin (0x08000000) und fragt man den Wert einzeln mit "GETENV" ab, sind es die tatsächlich installierten 512 MB (0x20000000). Damit ist dann auch geklärt, warum/wie das Recovery-Programm nur 128 MB beim Laden des Images ins RAM verwendet - das berechnet die Daten ja anhand der geladenen Datei (aus der auch gleich noch das TFFS-Image fürs Zurücksetzen der Einstellungen generiert wird) und dort sind es eben nur 128 MB. Das muß man halt berücksichtigen/wissen, falls man doch mal selbst am "memsize" herumfummelt - der Wert wird ja beim Booten ohnehin jedesmal neu gesetzt.

Aber auch das vom Recovery-Programm erzeugte TFFS-Image enthält eben nur diese 128 MB in "memsize" ... wenn man sich da ein eigenes baut, muß man sich ggf. entscheiden (falls das mit 512 MB nicht funktionieren sollte). Beim Schreiben über den Bootloader wird ja (anders als bei der Speicherung) auch bei NAND-Flash dasselbe Format verwendet - es wird halt nur ein einziges Mal nach "mtdnand" geschrieben und nicht in zwei (SPI-)Partitionen, wie bei den VR9-Geräten mit NAND und SPI. Ich kann mich auch noch an irgendeinen Thread erinnern, wo schon Zweifel bzgl. des tatsächlich installierten Speichers aufkamen, weil da eben auch nur die 128 MB sichtbar waren in einem Mitschnitt.

 

[Goggo16]

Ein so altes Recovery gibt's für die 7590 nicht, wenn man davon aus geht, dass die Box mit FW 6.83 auf den Markt kam.

Ah, OK, logisch. Bin wohl noch zu sehr ein 4790er Juenger. ;-)

 

[avm_7170]

Wie kann ich die Partitionstabelle reparieren?

Wenn da jemand mal eine gute Anleitung hätte, es werde immer mal wieder 7590 Boxen angeboten die in einer Bootschleife hängen ...

 

[KunterBunter]

Dazu müsste man erstmal mit Sicherheit wissen, ob die Ursache der Bootschleife überhaupt in der Partitionstabelle liegt.
Und eine gute Anleitung, um ein neues TFFS-Image zu erstellen und dieses hochzuladen, gibt es ja bereits im Forum.

 

[PeterPawn]

Kleiner Tipp noch von meiner Seite ... ich weiß ja nicht, was "Firewall ist ausgeschaltet" bedeutet, aber ein paar der Fehlermeldungen bzw. -berichte hören sich eher nach einer nicht richtig funktionierenden FTP-Verbindung an, was immer mal wieder vorkommt, wenn da irgendeine "Security-Suite" installiert ist, die ihrerseits die FTP-Dialoge überwacht und sich davon erst durch Deinstallation abbringen läßt und nicht von so ein paar lumpigen Einstellungen irgendwo.

Das Speichern der Firmware im RAM der Box hat eben ein ungewöhnliches Format für ein STOR-Kommando beim FTP und es gibt ganz offensichtlich (und nachweislich) genug von diesen "Security-Suites" (oder Suiten?), die an dieser Stelle "schlampig" programmiert sind, wie man hier für diverse Erzeugnisse aus dieser (imho einigermaßen überflüssigen) Software-Kategorie nachlesen kann.

Wenn also gar nichts mehr helfen sollte (es ist schon sehr ungewöhnlich, wenn ein FTP-Dialog angeblich nicht zum Ende kommt und die Box danach noch Stunden einfach so herumsteht), dann würde ich mal zu einem "frischen" Windows 10 (wg. der PS-Version) oder einer Linux-Installation greifen und das Ganze noch einmal in aller Gründlichkeit testen.

Das Speichern im RAM ist nun mal das erste Kommando mit einem abweichenden Format (es hat einen Parameter mehr als gewöhnlich), alle vorhergehenden Kommandos (des Recovery-Programms von AVM) stimmen mit den Vorgaben aus dem FTP-RFC überein.

Deren Funktionieren ist also nur ein Indiz dafür, daß die Box nicht komplett defekt ist ... was nicht heißen muß, daß die Installation der neuen Firmware tatsächlich erfolgreich ist, denn danach meldet die Box nur noch den Abschluß der Übertragung und startet den übertragenen Kernel ... ein "REBOOT" seitens des FTP-Client ist da gar nicht mehr erforderlich und auch keine weitere Reaktion.

Das ist also tatsächlich "der Abschluß" und wenn bei dem etwas schiefgehen sollte (und das Ausbleiben der Bestätigung, wenn man eine meiner Skript-Dateien verwendet, ist ein deutliches Zeichen dafür), kriegt es das AVM-Programm nicht mal zwingend mit.

Aber man kann sich ja das neu installierte TFFS-Image ansehen (einfach per Wireshark mitschneiden) ... dort sollte ein "recovered=2" in "firmware_info" enthalten sein. Steht das nach einiger Zeit (sagen wir mal 5-10 Minuten) dort immer noch und kann beim nächsten Neustart der Box über den FTP-Server ausgelesen werden, konnte entweder der Kernel nicht gestartet werden oder er hat sein Dateisystem nicht finden können.

Ansonsten wird dieser Wert gleich ziemlich am Beginn der Initialisierung wieder gelöscht (und in einer internen Variablen "Recover_was_here" für spätere Aktionen bereitgehalten) und ist damit beim nächsten Auslesen natürlich nicht vorhanden.

Wurde der Wert erfolgreich gelöscht, ist damit schon mal definitiv klar, daß sowohl Kernel als auch Dateisystem gefunden wurden und funktionieren ... der Kernel muß zuvor entpackt werden, das funktioniert nur, wenn er unbeschädigt ist und das Dateisystem muß ebenfalls bereits gemountet sein (weil das Löschen von "recovered=n" in einer Datei dort erst erfolgt), was bei einem SquashFS-Dateisystem auch erfordert, daß die Verwaltungsinformationen am Ende passen und gelesen werden konnten - nur irgendwelche Fehler in der Mitte sind dann noch nicht ausgeschlossen, weil m.W. keine Prüfsumme über das gesamte Dateisystem gebildet und mit einer Vorgabe verglichen wird.

Stürzt die Box erst danach ab, kann man soviele Versuche unternehmen, ein anderes OS zu installieren, wie man will ... wenn die fehlerhafte Komponente essentiell für den Betrieb der Box ist (z.B. der FPGA für die Telefonie), dann kommt man mit einer Standard-Firmware, die eine defekte Komponente trotzdem anspricht, auch nicht einen Schritt weiter.

Hier sollte also erst einmal (und zwar definitiv und nicht nur mittels Raten) geklärt werden, wie weit die Box beim Bootvorgang tatsächlich kommt ... die anderen Merkwürdigkeiten (kein "linux_fs_start", obwohl mehrfach auch Updates erfolgt sein sollen und eine "provider"-Variable im Environment) wurden ja schon aufgezeigt.

EDIT: Zur korrekten Beschreibung gehört natürlich auch - wie irgendwo weiter vorne schon erwähnt - die Beobachtung der LEDs über den gesamten Zeitraum ... vom Start des Recovery-Programms (bzw. vom Einstecken der Stromversorgung der Box) bis zur Feststellung "klappt nicht". Denn nach dem Laden ins RAM und dem Start von dort, installiert sich die Firmware ja normalerweise selbst in den Flash-Speicher und startet danach die Box noch einmal neu, was man am "Lichterspiel" problemlos erkennen kann. Bleibt dieser Neustart aus, deutet das bereits darauf hin, daß der übertragene Kernel nicht entpackt und gestartet werden konnte ... das ist dann wieder ein deutliches Zeichen für ein FTP-Problem, was auch einfach darin bestehen kann, daß sich irgendeine (vorgeblich für die Sicherheit sorgende) Software in den Datenstrom der Übertragung eingeklinkt hat und den jetzt erst mal mit ihrem Virenscanner o.ä. analysieren will - das muß also auch nicht zwangsläufig auf einem "Unverständnis" für das Format des STOR-Kommandos beruhen, wenn die Übertragung nicht erfolgreich abgeschlossen werden kann.

 

[Recover_Image]

Eine Anleitung um ein TFFS Image zu erstellen habe ich bisher noch nicht wirklich gefunden.

Was ich gefunden habe ist ein Thread über die 7490 wo darüber diskutiert wurde. Aber so ganz schlau bin ich daraus nicht geworden. Auch finde ich auf den Avm ftp Server keinen Quellcode dafür.

Die ganzen Dokumentationen sind hier für noobs ziemlich unübersichtlich. Da in jedem Thread immer ein bißchen steht.

Zu den Powershell Scripten finde ich keine Übersicht welche Befehle diese abarbeiten können. Eine Seite mit Befehlsübersichten wäre toll.

Was ich auch nicht verstehe ist das letzte mal das ich mich mit sowas beschäftigt habe war zu dbox2(Sat/Kabelreceiver) Zeiten. Dort konnte ich sämtliche Vorgänge über die serielle Schnittstelle sehen. Die einzelnen Partitionen wurden im Image vorgegeben.

Was beinhaltet das Kernelimage außer dem Kernel und wozu ist dieses? Müsste der Kernel nicht im eigentlichen *.image enthalten sein und dort auch die mtd Tabelle festgelegt werden. Ist das TFFS sozusagen der Bootloader? Kann man diesen nicht aus einer anderen Box auslesen und einspielen?


Zu Windows, es ist ein frisches Windows7 im Einsatz, darauf installiert ist nur Winrar, filezilla, Telnet client und nun Powershell 5.1. Windows10 läuft nicht auf diesem Rechner bzw ist so langsam das ein Arbeiten kaum möglich ist. Für Investitionen diesbezüglich kann ich mir auch eine neue Fritzbox kaufen. Es befindet sich keine Security Suit auf dem Rechner. Die Firewall wurde ganz normal in den Systemeinstellungen deaktiviert für private und öffentliche Netzwerke. Das aufspielen über das Recover Programm scheint zu funktionieren. Da sich die Versionsnummer des Images bei unterschiedlichen Images ändert. Seid Powershell 5.1 funktioniert auch über dem EVA-FTP Client das aufspielen. True meldet EVA am Ende. Auch hier danke für den Tipp.

Das aufspielen über ftp funktioniert nicht weil.... Das Windows FTP das anscheinend nicht kann. Alternative Empfehlung? Mit Filezilla komme ich nicht auf die Box.
Die Versuche über FTP einzuspielen erfolgen über eine Homebrew Client in Mac OS Mojave. Darüber wird das Image aber nicht komplett hochgeladen. Die Datenrate sinkt nach und nach und bricht ab. Unterschiedliche Clienten gleicher Fehler.

Angeschlossen ist die Box jeweils direkt am Rechner. Wireshark werde ich als nächstes installieren, mal schauen in wie fern das alles protokolliert.

Der Recovervorgang läuft so ab das das Image „erfolgreich“ auf die Box geschoben wird. Danach blinkt in gewissen Abständen die Power und Fon LED auf. Irgendwann blinken alle LED kurz und die Box bootet vermutlich neu. Weil danach die Power led leuchtet ausgeht leuchtet und dann wieder alle led kurz aufblinken. Dieses Spiel setzt sich dann ewig fort. Egal ob die Box dann auch mal Stromlos gemacht wurde oder nicht. Um allerdings wieder per FTP zugegriffen werden kann muss die Box erst wieder vom Strom. Über die Bootschleife ist es zwischen durch nicht möglich.

Welche Linux Distribution könnt ihr für diese Sache hier empfehlen um weiter zu kommen?

Im übrigen danke für die bisherigen Hilfen und auch Shells sind toll. Scripte kann ich bisher wegen fehlender Linux dist nicht probieren und den Mac möchte ich hierbei lieber außen vorlassen.