Rich (BBCode):
0:38:859: send: STOR 0x866fa800 0x88000000
0:38:859: recv: 150 Opening BINARY data connection
0:38:859: now send image mtd1 to ram
0:38:875: send image (size=26187776) for mtd1
1:06:171: recv: 553 Execution failed.
1:06:171: flash error 553 Execution failed.
1:06:171: error (write image): -3
1:06:171: error on ram-(nand)-update
1:06:281: exit: errorcode=-3
Da liegt das Problem ... der Rest des Recovery-Programms hat eigentlich klaglos funktioniert.
Wenn das auch mit einem anderen System reproduzierbar ist (es gibt zwar andere Schreibzugriffe (auf MTD3 und MTD4), aber die übertragen deutlich weniger Daten (jeweils 384 KB) und daher KÖNNTE es immer noch ein Netzwerkproblem sein - wenn auch 384 KB schon nicht mehr in irgendwelchen "buffers" ablaufen sollten bzw. jenseits des TCP-Windows), dann sehe ich das eher als Hardware-Fehler.
Zu diesem Zeitpunkt muß der Bootloader nichts weiter machen, als die Daten vom Netzwerk entgegenzunehmen und ins RAM zu speichern. Danach probiert er, den Kernel am Beginn der übertragenen Daten zu entpacken und zu starten. Gelingt ihm das, meldet er ganz normal ein "226 Transfer complete" und bei jedem Problem (zumindest nach meiner Erfahrung) das gezeigte "553 Execution failed".
Da gibt es also nicht soo viele denkbare Fehlerquellen - ein "zerstörtes Image" im Recovery-Programm würde die Windows-Signaturprüfung schon aufdecken, also kann man davon ausgehen, daß die zu übertragenden Daten korrekt sind. Bleibt daher noch die Netzwerkverbindung, die die übertragenen Daten verfälschen könnte oder ein defekter Hauptspeicher, wo der Bootloader das System ablegen soll. Wenn der dann beim anschließenden Entpacken falsche Daten liefert, würde das natürlich ebenso gegen den Baum fahren.
Die 28 Sekunden bis zum "553" sind für 25 MB Datenübertragung aber auch ziemlich lang bzw. erscheinen mir "komisch" (mir fehlt aber auch der Vergleich für eine 7362SL) - zumindest dann, wenn man das nicht auf 10 MBit/s festgetackert hat. Ansonsten sind das knapp 210 MBit, die da übertragen werden sollen (26187776 Byte) und selbst mit Protokoll-Overhead sollte das bei einer 100 MBit/s-Verbindung nicht soo lange brauchen.
Anders als bei Schreibzugriffen auf NOR- oder SPI-Flash fällt hier ja keine zusätzliche Zeit für das Löschen von Flash-Pages an - es geht wirklich nur darum, die Daten an der angegebenen Stelle ins RAM zu schreiben. Das ist es auch, was mich immer noch etwas mißtrauisch auf die Netzwerkverbindung blicken läßt - aber eben ohne genau zu wissen, was hier "normal" wäre. Es erscheint mir halt nur sehr lang und erinnert mich schon fast wieder an ein Timeout.
Da es für den vorhergehenden Erfolg der Schreibzugriffe auf MTD3/MTD4 auch keine so richtige Prüfung gibt (wie das Entpacken des Kernels, wo jedes falsche Bit sofort auffällt), muß nicht einmal der angeblich erfolgreiche Abschluß des Speicherns eines neuen TFFS-Images als "Beweis" für eine einwandfrei funktionierende Netzwerkverbindung taugen, auch wenn sich das Environment hinterher wieder lesen läßt. Denn die Datenmenge für das neu zu schreibende TFFS-Image ist geradezu "winzig" ... das braucht i.d.R. keine zwei vollen Ethernet-Pakete (ca. 2500 Byte bringen Name-Table und Environment-Werte zusammen auf die Waage) und die können durchaus noch ohne "flow control" übertragen werden (der Rest in den 384 KB sind dann nur noch binäre Einsen).
Nach einem Test mit einem anderen Gerät an einem anderen Port der Box (um die Netzwerkverbindung weitgehend auszuschließen als Ursache - bei der 7362SL würde ich sogar alle vier Ports "durchprobieren", weil zwei ja den internen PHY benutzen (LAN1+LAN2) und die anderen zwei jeweils einen externen), würde ich u.U. noch versuchen, die schadhafte Stelle im RAM zu lokalisieren (das kann man machen, indem man ein kleineres System lädt und/oder es an verschiedene Offsets im RAM schiebt und die "memsize" jeweils passend begrenzt) und dann -. wenn das Problem im RAM gesichert ist, denn prinzipielll funktioniert der schon noch, sonst würde es gar nicht bis zur gezeigten FTP-Session kommen - die Box auch tatsächlich entsorgen.
Das RAM-IC ist bei der 7362SL als BGA-Chip direkt neben dem VRX288 (unter einem gemeinsamen EMI-Shield/Kühlkörper) aufgelötet - das da herauszubekommen und ein anderes IC wieder einzulöten (und zwar so, daß es auch funktioniert), ist eine Aufgabe für echte Spezialisten und braucht auch passende Ausrüstung (schon zum Entfernen eines BGA-Chips).
Hier wird Dir jedenfalls auch ein anderes Recovery-Programm nicht wirklich weiterhelfen ... es sei denn, das von Dir verwendete hatte keine gültige AVM-Signatur, die ja sowohl die Integrität des Programms bestätigt, als auch das dort enthaltene Image (hier sind das ca. 24 MB, die da als Payload vorliegen) gegen Beschädigungen sichert.
Wenn das tatsächlich nur ein kleiner Bereich in den obersten Adressen im RAM ist, der da ein Problem hat (man könnte auch ein kleines Diagnose-System entwerfen und "weiter unten" laden, das die Stelle(n) durch Schreiben und nachfolgendes Lesen näher eingrenzt), dann könnte man auch mit einer permanenten Verringerung der "memsize" versuchen, dessen Benutzung zu vermeiden ... dann hätte die Box eben entsprechend weniger RAM zur Verfügung (wobei alles oberhalb des Schadens unbenutzt bleiben muß, wenn man den Aufwand nicht noch höher treiben will). Wieviel genau das weniger wäre, hängt wieder von den schadhaften Stellen ab.
Nur stellt sich dann halt irgendwann auch die Frage, ob sich solcher Aufwand für eine 7362SL (bei eBay ca. 40 EUR, wenn's schlecht läuft) überhaupt noch lohnt - das ist dann wohl eher ein Projekt, "weil man's kann" oder weil man's lernen will. Ansonsten hätte die Box hier (immer vorausgesetzt, es ist nicht doch nur die Netzwerkverbindung oder der genutzte PC mit dem Recovery-Programm) auch das Ende ihres Lebens erreicht und sich das vermutlich auch verdient - ich weiß ja nicht, von wann die ist (kriegt man aus der Seriennummer heraus).
Aber solange das Recovery-Programm nicht wirklich "schadhaft" ist (und das würde die Signatur dieses Programms eben auch ungültig werden lassen), wirst Du auch mit irgendeinem anderen Recovery-Programm wieder nur dasselbe Ergebnis erzielen, wie es oben in der "ftp.log" zu sehen ist. Das geladene System ist dabei jedenfalls noch gar nicht wirklich zur Ausführung gekommen (deshalb spielt es auch keine Rolle, welche Version das ist) ... wenn der Kernel entpackt werden kann, meldet der FTP-Server erst mal sein "226", bevor er ihn startet.
Wobei die Tatsache, daß es "plötzlich" auftrat nach Deiner Beschreibung, auch wieder eher auf den Hardware-Schaden hindeutet als auf irgendein Netzwerk-Problem - vielleicht solltest Du also gleich in Erwägung ziehen, auf weitere Experimente zu verzichten, wenn Dir die gesparte Zeit am Ende das Wichtigste sein sollte. Ich würde die Erfolgsaussichten hier irgendwo bei < 10% einordnen.
