Das war aber noch NOR-Flash, auf den sich die alten Infos aus Freetz (daher stammt das ja ursprünglich) beziehen. Die 7490 verwendet andere Chips/Technologien, auch für die Konfiguration (SPI für Bootloader und Konfiguration und NAND für das FRITZ!OS + NAS).
Die Wahrscheinlichkeit, daß sich der SPI-Flash "abgenutzt" haben könnte, ist äußerst gering und erklärt nicht wirklich, warum da nach 15 ms die Datenverbindung geschlossen wird, wenn die zu übertragende Datenmenge bei 384 KB(!) liegt und die Übertragung von 1.404 Bytes in der Gegenrichtung schon 62 ms benötigte. Da die Daten für
env
und
count
erst noch vom Bootloader aufbereitet werden müssen (der liest das ja auch aus dem TFFS, wobei er es ebenso aus den Daten im Konfigurationsbereich des Bootloaders regenerieren könnte, wenn weder
mtd3
noch
mtd4
lesbar sein sollten - das habe ich ja auch genau so in meinem
bootmanager
implementiert), könnte das zwar etwas länger dauern, aber die 384 KB für das TFFS-Image sollten dennoch schon etwas länger brauchen als 15 ms - wirklich sicher sieht man das in der Netzwerk-Analyse.
Üblicherweise würden (iirc) auch erst einmal die Daten für ein
STOR
-Kommando im RAM gepuffert, BEVOR sie in den Flash geschrieben werden. Wenn meine Interpretation stimmt und die Box sich mit der
426
-Meldung über den Verbindungsabbruch seitens des PC
beschwert (sie ihn somit nicht selbst auslöst, was man ja am
RST
-Flag in den TCP-Paketen sehen kann - von einem Packet-Dump habe ich hier noch nichts gesehen, trotz entsprechendem Hinweis), dann liegt auch die Ursache NICHT in der Box.
Löst sie den Abbruch selbst aus, KÖNNTE das zwar tatsächlich an einem Problem beim Löschen und Schreiben des Flashs liegen, aber dann sollten zumindest mal genug Daten für eine komplette Erase-Line bereits übertragen worden sein.
Dann kann man immer noch auf das Schreiben der TFFS-Images verzichten (die Inhalte werden auch bei weiteren Versuchen ja keine anderen sein, als beim letzten erfolgreichen(!) Schreibvorgang) und zumindest mal "zu Fuß" versuchen, eine Firmware ins RAM zu bringen und zu starten. Das ist dasselbe Vorgehen wie bei der Installation einer eigenen Firmware und funktioniert üblicherweise auch mit einem Windows-System.
Allerdings sollte man dazu einigermaßen sicher wissen, wo das EIGENTLICHE Problem liegt - das hier einfach mal "blind" zu probieren, anstatt erst einmal den Netzwerk-Verkehr genauer zu untersuchen, wäre sicherlich nur wenig hilfreich.
Denn in Kenntnis der eigentlichen Ursache (ja, es KÖNNTE am Ende tatsächlich ein Problem beim Beschreiben des SPI-Flashs sein, auch wenn das nicht die erste/wahrscheinlichste Erklärung ist) kann man sich dann ein entsprechend angepaßtes eigenes Image erstellen.
Oder man bestückt einfach mal schnell die Serielle - da sollte man ein Problem beim SPI-Schreiben auch sehen können … auch wenn ich selbst so etwas noch nie hatte und ich habe schon viele Schreibvorgänge ausgeführt.
Aber (ohne jetzt Datenblätter zu suchen, wie das bei der 7490 konkret ist) es könnte ja auch noch sein, daß da durch einen Schaden dauerhaft ein WP-Signal (write protect) anliegt (wobei das ja meist ein negiertes Signal ist und damit eine Unterbrechung auch als Schreibschutz gesehen würde) und daher der SPI gar nicht weiter beschrieben, aber noch ausgelesen werden kann. Nur geht das alles immer weiter in den Bereich der Spekulation bei der Suche nach möglichen Erklärungen und nach "
Occam's razor" sollte man mit den wahrscheinlicheren Ursachen für ein Problem beginnen bei der eigenen Suche.
EDIT/PS: Nach Treiberproblemen würde ich hier aber auch erst ganz am Ende suchen - die FTP-Kommunikation klappt ja ausweislich der Protokoll-Dateien. Vorher würde ich in jedem Fall einen Aufbau mit einem Switch zwischen der Box und dem PC testen - so richtig schlau werde ich nicht daraus, was hier auf der PC-Seite alles an Netzwerk-Adaptern zum Einsatz kommt und was dabei funktioniert und was nicht (#55 und #59).
Am Switch kann man dann wenigstens auch erkennen, auf welche Geschwindigkeiten sich die Ethernet-Schnittstelle der Box und der Switch verständigen - daß die Box hier nur selten "gefunden" wird, könnte ja wirklich noch an den verwendeten LAN-Adaptern liegen, aber hier würde ein Switch (am besten noch ein älterer ohne 2,5 GB/s) schon dafür sorgen, daß die Pakete zwischengespeichert und mit der ausgehandelten Geschwindigkeit übertragen werden. Ob da ein Treiber-Update Besserung versprechen würde, bezweifle ich eher - vor allem dann, wenn von event. vorhandenen Problemen im Treiber nichts weiter zu bemerken war und das nur i.V.m. der FRITZ!Box auftreten soll. Wobei auch ein "Kreuztest" mit ggf. weiteren vorhandenen Boxen ja aussagekräftig sein könnte …