[Problem] 7362sl trotz erfolgreichem Recover nicht abrufbar bzw. Rebootschleife

[less1]

Hallo zusammen,
bin wegen Problemen mit meiner Fritzbox 7362sl auf dieses Forum gestoßen.

Sie lief einwandfrei und ist von einem Tag auf den anderen ausgefallen.
Als Anbieter haben wir die Telekom und es läuft über den Tarif Magenta XS.

Seit dem Ausfall startet sie ständig neu (ca im Minutentakt) und die webbasierte Oberfläche ist nicht erreichbar.

Zum Wiederherstellen wurde das Recovertool von AVM genutzt und auch mehrfach erfolgreich ausgeführt (Version 06.30). Nach dem Neustart befindet sie sich jedoch wieder in einer Rebootschleife und ist nicht über fritz.box oder Notfall IP ansprechbar.

Ein FTP connect über ADAM2 ist hingegen möglich. Hier habe ich schon versucht die mtd3 und mtd4 nach folgender Anleitung zu löschen:
http://www.xobztirf.de/selfsite.php?aktion=Recover
Das scheiterte jedoch daran, dass er die hinterlegten Leedateien nicht finden konnte.

Was kann ich noch ausprobieren? Bisher habe ich oft gelesen, dass noch was zu retten ist, wenn eine FTP Komunikation möglich ist.

Achja, die Box wurde mit einer originalen AVM Firmware betrieben.

Viele Grüße und danke im Vorraus

Less

 

[PeterPawn]

Du hast aber schon gelesen, daß es bei der von Dir verlinkten Seite noch um die 7170 ging? Das wären nur ca. 9 Jahre (angenommener Stillstand?), die diese Box schon auf dem Buckel hätte.

Und selbst die von Dir verlinkte Seite schreibt ausdrücklich:

*** ACHTUNG *** ACHTUNG *** dies nur bei Kernel 2.4 durchführen! Sonst macht ihr aus den Box einen Briefbeschwerer!

Abgesehen davon, daß dort keine Begründung dafür gegeben wird, sollte man das aber schon gelesen und berücksichtigt haben, wenn man ziemlich "unbeleckt" an die Reparatur einer FRITZ!Box geht (oder hat die 7362SL noch einen 2.4er-Kernel nach Deiner Meinung?) ... das ist zwar alles nur "Meckerei" meinerseits, aber wenn schon so deutlich wird, daß da jemand nicht lesen kann, stellt sich ein wenig die Frage, was da für die Zukunft und etwaige Hilfeversuche zu erwarten wäre ... aber versuchen wir es mal.

Das mit dem "plötzlichen Ausfall" liest sich zwar auch merkwürdig, aber wenn Du tatsächlich noch zum FTP-Login in die EVA kommst, dann kann es eigentlich nicht so "richtig schlimm" sein. Das erste, was man jetzt bräuchte, wäre eine Auflistung des "Environments", das Du in etwa mit der folgenden Kommandofolge abrufen könntest (so macht es jedenfalls das Recovery-Programm):

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.1964 0x0 0x740D
TYPE I
200 Type set to BINARY
MEDIA SDRAM
200 Media set to MEDIA_SDRAM
P@SW
227 Entering Passive Mode (192,168,178,1,12,8)
RETR env
150 Opening BINARY data connection
226 Transfer complete

Darin steht dann schon als erstes mal das verwendete Branding der Box (das muß zur installierten Firmware passen und der Fehler hört sich fast so an, als wäre das nicht der Fall) und bei der 7362SL sogar mit einiger Wahrscheinlichkeit eine Möglichkeit, auf das letzte funktionierende System umzuschalten. Aber das ist dann erst der zweite Schritt, erst einmal zeige uns das Environment. Dabei darfst Du den WLAN-Key (wlan_key) und die MAC-Adressen unkenntlich machen (im Rahmen) ... den Rest läßt Du bitte unverändert.

 

[less1]

Ein "plötzlicher Ausfall" war es für uns, da sich die FB von einem Tag auf den anderen sich nicht mehr einwählen konnte und sich ständig neustartete. Es wurden unsererseits keine Updates oder Änderungen in den Einstellungen gemacht.

Aber nun gut, ich habe versucht die Auflistung des environments zu bekommen. Leider endet es so:



Was mache ich falsch? Es handelt sich um einen Windows 7 PC. Firewall und Virenschutz sind abgeschaltet.

Mfg

Less

 

[PeterPawn]

Versuch es mal mit "QUOTE PASV" anstelle von P@SW ... der Windows-FTP-Client ist da m.W. etwas scheu.

Ansonsten hilft ein anderer FTP-Client ... oder ein anderes System - beim passiven FTP-Modus (m.W. der einzige, den EVA unterstützt) muß eben der Client anhand der 227-Response die Datenverbindung aufbauen und nicht der Server.

 

[splenditnet]

ich habe versucht die Auflistung des environments zu bekommen. Leider endet es so:

Bitte mal "get env" "quote GETENV HWRevision" statt "quote RETR env" ausführen.

Gruß
Splenditnet

EDIT:
@PeterPawn:

Versuch es mal mit "QUOTE PASV" anstelle von P@SW

nach meinem Stand schickt der Client dem Server den Befehl "PASV", der Server schickt dem Client dann den Port auf dem der Client dann die Datenverbindung aufbauen kann und die Daten senden kann, d.h. "QUOTE PASV" wäre nicht ganz richtig ?

Frage: Unterstützt ein Windows-Client überhaupt Passive-Mode ?

Win7:
ftp> help
Befehle können abgekürzt werden. Befehle sind:

!               delete          literal         prompt          send
?               debug           ls              put             status
append          dir             mdelete         pwd             trace
ascii           disconnect      mdir            quit            type
bell            get             mget            quote           user
binary          glob            mkdir           recv            verbose
bye             hash            mls             remotehelp
cd              help            mput            rename
close           lcd             open            rmdir
ftp>

Empfehlung anderen Windows-FTP-Client, der Passive-Mode ("PASV ON") kann, testen

UPDATE:
hab gerade noch folgende hilfreiche Doku gefunden http://www.wehavemorefun.de/fritzbox/TinyFTP

Bewährt hat sich der Linux ftp Client und unter Windows das Programm ncftp.exe.
Der in der Windows-Eingabeaufforderung vorhandene ftp Befehl funktioniert nicht, da er keine passiven Dateitransfers unterstützt.

 

[less1]

Habe es jetzt mit Ncftp probiert.
Bei Eingabe von "quote RETR env" kommt ebenfalls "can't open data connection".
Bei "quote GETENV HWRevision" kommt "Invalid reply".


Sind die Befehle so richtig?

Ergänzung:
Falls es hilft ist hier nochmal der Text aus dem Protokoll des Recovertools:

FRITZ!Box 7362 SL suchen an: 192.168.178.1
Eine Anlage gefunden! - Ermitteln der aktuellen Version.
Version erfolgreich ermittelt!
    Hardware:       FRITZ!Box 7362 SL
    Urlader:           2964
    Firmware:       recovered=2
Flashbereich (mtd3)
    Lösche              Flashbereich (mtd3)
    Restauriere    Flashbereich (mtd3)
Flashbereich (mtd4)
    Lösche              Flashbereich (mtd4)
    Restauriere    Flashbereich (mtd4)
    Restauriere    Flashbereich (mtd1)
FRITZ!Box 7362 SL erfolgreich wiederhergestellt!
Die Wiederherstellung ist nach einem Neustart des Gerätes abgeschlossen.

 

[KunterBunter]

Falls es hilft ist hier nochmal der Text aus dem Protokoll des Recovertools:

    Firmware:       recovered=2

Das ist der Inhalt der Environment Variablen firmware_info. Normalerweise steht da die Version drin, also z.B. 131.06.30. Vielleicht bootet die Box ja deshalb nicht mehr.

 

[PeterPawn]

Da der Wert von "firmware_info" ziemlich früh im Startvorgang schon durch die Ausgabe von "/etc/version" überschrieben wird (in S01-head), deutet das darauf hin, daß das System nicht einmal richtig angelaufen ist nach dem vorhergehenden Recovery-Versuch (recovered=2 steht für das AVM-Recovery-Programm, 3 für "Werkseinstellungen" und "1" für "ar7man" (eine heute m.W. nicht mehr verwendete Einstellung oder ich habe nur noch nie die betreffenden Stellen gefunden) - nachzulesen ebenfalls in der S01-head).

Jeder gesetzte Wert von "recovered" führt zu einer exportierten Environment-Variablen (nicht mit dem Urlader-Environment verwechseln) "Recover_was_here" mit dem Wert von "recovered", was dann eben sofort wieder gelöscht wird und somit beim nächsten Start nicht mehr vorhanden ist.

Diese Variable wird dann offenbar nur noch in S15-filesys verwendet um zu entscheiden, ob das NAND-Flash (also das YAFFS2 unter /var/media/ftp) nun komplett gelöscht und neu initialisiert werden soll (bei 1+2) oder ob der Inhalt dort erhalten bleibt (nach "Werkseinstellung", was der NAND-Inhalt problemlos überlebt).

Es sollte also nichts mit dem Eintrag in "firmware_info" zu tun haben (wobei ich das auch nicht ausschließen will, aber eigentlich deutet in den bis zu diesem Zeitpunkt (also S01-head) genutzten Quellen nichts darauf hin) und dieser Eintrag wird ja dann auch sehr schnell neu geschrieben ...

 

[less1]

Was kann ich jetzt versuchen, um der Sache auf die Schliche zu kommen?

Kann es sein, dass das Ganze durch ein automatisches Update zustande gekommen ist? Im normalen Betrieb sollten diese Bereiche ja eigentlich nicht verändert werden.

Könnte eine ältere Recovery Version Abhilfe schaffen?

Viele Grüße

 

[PeterPawn]

nach meinem Stand schickt der Client dem Server den Befehl "PASV", der Server schickt dem Client dann den Port auf dem der Client dann die Datenverbindung aufbauen kann und die Daten senden kann, d.h. "QUOTE PASV" wäre nicht ganz richtig ?

Wenn der Windows-FTP-Client den "passive mode" unterstützen würde (das macht er aber tatsächlich nicht ... ich habe den zugegebenermaßen noch nie für Transfers genutzt, für den Control-Channel (GETENV/SETENV) reicht er aus), wäre aber "QUOTE PASV" tatsächlich richtig.

Mit dem "QUOTE"-Kommando sagt man in der Regel (auch das ist eigentlich kein richtiger Standard, soweit ich weiß - müßte ich aber auch erst nachsehen im RFC), daß das folgende Kommando nicht für den Client gedacht ist und direkt an den Server zu übermitteln ist.

Die Umschaltung auf "passiven Modus" erfolgt z.B. bei vielen FTP-Clients ganz simpel mit dem (Client-)Kommando "passive", daraus leitet der Client dann seinerseits ein einfaches "PASV" (oder P@SW, was mal eine Verschleierung des Kommandos für ALGs war) ab und interpretiert die Server-Antwort mit der Adresse und dem Port für die Datenverbindung dann entsprechend. Will jetzt der "Bediener" des Clients seinerseits ein Kommando an den Server senden, für das es kein passendes Client-Kommando gibt, nimmt er dafür eben das "QUOTE" ... ein Beispiel wäre eben "QUOTE GETENV xyz", denn das "GETENV" kennt normalerweise kein Client.

Frage: Unterstützt ein Windows-Client überhaupt Passive-Mode ?

Nein, tut er wohl tatsächlich nicht ... jedenfalls nicht der Kommandozeilen-Client "ftp.exe" von MS. Der Windows-Explorer (bzw. früher mal die msieftp.dll, keine Ahnung, ob das heute auch noch so ist) kann jedoch sehr wohl als Client auch den passiven Modus nutzen, im entsprechenden GUI-Dialog war m.W. sogar eine passende Checkbox. Da das hier aber nicht weiterhilft, meintest Du sicherlich mit "Windows-Client" auch eher die "ftp.exe" und die kann es eben nicht.

@less1:
Ich bleibe dabei, daß selbst bei teilweise defektem Flash-Speicher die Umschaltung auf das alternative System schon helfen könnte, damit die Box wieder startet. Dazu braucht es aber einen Einblick in das Environment der Box und ich bin nicht bereit, da nur zu raten. Wenn das AVM-Recovery-Programm die Box neu programmiert, hat es vorher in jedem Falle das Environment ausgelesen. Wenn das Dir mit dem FTP-Zugriff nicht gelingt (wenn der Windows-Client es nicht kann, dann muß man eben etwas flexibler reagieren - mein Beispiel weiter oben stammte (so steht es da auch) aus einer Aufzeichnung einer Recovery-Sitzung), bliebe Dir immer noch ein Packet-Dump (z.B. mit Wireshark), um dem "Geheimnis" des Environments auf die Spur zu kommen.

Schon das passende SETENV-Kommando könnte helfen ... aber um zu wissen, was "passend" wäre, braucht man eben den derzeitigen Inhalt. Nur mit "trial & error" mag ich nicht mitspielen ... das muß dann jemand anderes übernehmen.