Und welche Treiberversion wurde beim Realtek LAN Adapter (onboard und USB) jeweils verwendet? Bitte einfach mal jeweils die Versionsnummer angeben. Danke.
Fritzbox 7490 recovery funktioniert nicht
- Ersteller Pingwing
- Erstellt am
-
- Schlagworte
- fritzbox 7490 recover
Hätte ich gerade nicht gesessen, dann hätten mich insbesondere die Daten der verwendeten USB Treiber fast umgehauen.
Realtek USB FE / GBE / 2.5G / 5G Ethernet Family Controller Software
Win10 Auto Installation Program Version 10.61.20 von 2024/08/30
www.realtek.com
Realtek PCIe FE / GBE / 2.5G / 5G Ethernet Family Controller Software
Win10/Win11 Auto Installation Program (NDIS) Version 10.72 von 2024/08/30
www.realtek.com
Realtek veröffentlicht leider keine Releasenotes und direkte Downloadlinks sind leider auch nicht möglich. Aber die aktuellen Versionen dürften auch Fehlerbehebungen enthalten, für Win 11 gibt es unter den Links auch noch separate Downloadmöglichkeiten.
Den bisherigen Treiber bitte zuerst in der Systemsteuerung deinstallieren und dann den aktuellen Treiber neu installieren. Bitte nicht einfach drüber installieren!
Dann sollte einem erneuten Recovery Versuch nichts mehr entgegenstehen. Dafür die Box mit LAN1 direkt an den PC anschliessen, kein Switch dazwischen und keine weiteren Geräte an der Box (LAN, USB, Telefone).
Realtek USB FE / GBE / 2.5G / 5G Ethernet Family Controller Software
Win10 Auto Installation Program Version 10.61.20 von 2024/08/30
Realtek
Realtek PCIe FE / GBE / 2.5G / 5G Ethernet Family Controller Software
Win10/Win11 Auto Installation Program (NDIS) Version 10.72 von 2024/08/30
Realtek
Realtek veröffentlicht leider keine Releasenotes und direkte Downloadlinks sind leider auch nicht möglich. Aber die aktuellen Versionen dürften auch Fehlerbehebungen enthalten, für Win 11 gibt es unter den Links auch noch separate Downloadmöglichkeiten.
Den bisherigen Treiber bitte zuerst in der Systemsteuerung deinstallieren und dann den aktuellen Treiber neu installieren. Bitte nicht einfach drüber installieren!
Dann sollte einem erneuten Recovery Versuch nichts mehr entgegenstehen. Dafür die Box mit LAN1 direkt an den PC anschliessen, kein Switch dazwischen und keine weiteren Geräte an der Box (LAN, USB, Telefone).
Leider muß man sich selbst um die Realtek-Treiber kümmern. Weder Windows-Update noch Intel's Driver & Support Assistant kommen von sich aus darauf, dem Benutzer Updates der RealTek-Treiber zu melden.
Ähnlich ist es bei "Marvell" - ich habe einen "Marvell AQtion 10 GB Network Adapter" auf meinem Mainboard (Asus ProArt Z790 Creator WiFi):
Auf der Asus-Support-Seite des Boards brauche ich nicht zu schauen - "Version 3.1.7.0, 2022/11/10"
*edit* Eventuell wird man beim Microsoft Update-Katalog fündig: https://www.catalog.update.microsoft.com/Search.aspx . Dort bekommt man allerdings lediglich den funktionalen Treiber - eventuelle Hilfsprogramme sind im CAB-Archiv nicht enthalten.
Ähnlich ist es bei "Marvell" - ich habe einen "Marvell AQtion 10 GB Network Adapter" auf meinem Mainboard (Asus ProArt Z790 Creator WiFi):
- Version 3.1.8.0
- Datum 2023-04-17
Auf der Asus-Support-Seite des Boards brauche ich nicht zu schauen - "Version 3.1.7.0, 2022/11/10"
*edit* Eventuell wird man beim Microsoft Update-Katalog fündig: https://www.catalog.update.microsoft.com/Search.aspx . Dort bekommt man allerdings lediglich den funktionalen Treiber - eventuelle Hilfsprogramme sind im CAB-Archiv nicht enthalten.
Zuletzt bearbeitet:
Im Zweifel auf der Webseite von Marvel unter "Downloads".
Public Driver Downloads | QLogic Fibre Channel HBAs and FastLinQ Ethernet adapters and controllers - Marvell
Download Marvell drivers by Platform or Part Number for Marvell QLogic Fibre Channel HBA and Marvell FastLinQ Ethernet adapters and controllers.
www.marvell.com
Marvell AQtion Windows 64-bit Driver, Date: 04/23/24, Version: 3.1.10
Damit das hier nicht OT wird und ein Moderator es einfach "wegputzt" vermute ich einfach mal ganz stark, der aktuelle Marvell Treiber wird benötigt, um eine 7490 zu recovern. ;-)
War ´ne nette Idee mit dem Realtek LAN-Treiber, aber leider nicht erfolgreich.
Mittlerweile habe ich noch einen anderen älteren PC mit nativem LAN ausgegraben, das Ergebnis ist immer das gleiche:
"... Recover der Partition mtd3 fehlgeschlagen"
Ich vermute, hier wurde ein früherer Flashvorgang hart abgebrochen, etwa durch Verbindungstrennung oder Spannungsabfall.
Dienstlich hatte ich gestern einen ähnlichen Fall, da ist ein Linux-basiertes Anlagendisplay ebenso abgekackt.
Da scheitert der Flash auch immer an einer bestimmten Stelle.
Mittlerweile habe ich noch einen anderen älteren PC mit nativem LAN ausgegraben, das Ergebnis ist immer das gleiche:
"... Recover der Partition mtd3 fehlgeschlagen"
Ich vermute, hier wurde ein früherer Flashvorgang hart abgebrochen, etwa durch Verbindungstrennung oder Spannungsabfall.
Dienstlich hatte ich gestern einen ähnlichen Fall, da ist ein Linux-basiertes Anlagendisplay ebenso abgekackt.
Da scheitert der Flash auch immer an einer bestimmten Stelle.
Eine Erklärung für den Fehler bei "mtd3" wäre auch das Folgende:
"Unabhängig von der Reihenfolge im Speicher wurde festgelegt dass mtd0 das root Dateisystem enthalten soll, mtd1 das Kernel, mtd2 ADAM2 selbst und mtd3 die Konfiguration. Letztere muss häufig geschrieben werden und trotzdem fehlerfrei sein und nutzt dabei das Flash ab. Um dies sicherer zu gestalten entwickelte AVM das TFFS, das durch doppelte “Pufferung” zwei gleich grosse Partitionen mtd3 und mtd4 benötigt."
Quelle: https://freetz-ng.github.io/freetz-ng/wiki/30_Expert/flash.html
"Unabhängig von der Reihenfolge im Speicher wurde festgelegt dass mtd0 das root Dateisystem enthalten soll, mtd1 das Kernel, mtd2 ADAM2 selbst und mtd3 die Konfiguration. Letztere muss häufig geschrieben werden und trotzdem fehlerfrei sein und nutzt dabei das Flash ab. Um dies sicherer zu gestalten entwickelte AVM das TFFS, das durch doppelte “Pufferung” zwei gleich grosse Partitionen mtd3 und mtd4 benötigt."
Quelle: https://freetz-ng.github.io/freetz-ng/wiki/30_Expert/flash.html
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,279
- Punkte für Reaktionen
- 1,754
- Punkte
- 113
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
Üblicherweise würden (iirc) auch erst einmal die Daten für ein
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 …
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 …
Zuletzt bearbeitet:
Danke allen für die Mühen. Die Box habe ich nun nun aufgegeben und mir eine andere funktionierende besorgt.
@ PeterPawn: Wenn Du die Box zum Spielen haben willst, schicke ich sie Dir zu. Ich will sie nicht wiederhaben.
@ PeterPawn: Wenn Du die Box zum Spielen haben willst, schicke ich sie Dir zu. Ich will sie nicht wiederhaben.
Zuletzt bearbeitet:
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,279
- Punkte für Reaktionen
- 1,754
- Punkte
- 113
Nein, danke. Das Modell ist mir dann inzwischen auch deutlich zu alt, zumal ich noch eine - ansonsten nicht weiter genutzte - 7490 mit bestückter Serieller habe, auf der ich ggf. testen kann.
Vielleicht interessiert sich ja jemand anderes für die Box (und gibt P+P dafür aus).
Vielleicht interessiert sich ja jemand anderes für die Box (und gibt P+P dafür aus).
Für Dich würde ich P+P übernehmen, ggf. auch für die Rücksendung.
Weil es mich interessiert, was mit der Box ist.
Weil es mich interessiert, was mit der Box ist.
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,279
- Punkte für Reaktionen
- 1,754
- Punkte
- 113
Sorry - wirklich KEIN Interesse.
Das Modell ist einfach schon zu alt (womit absehbar die Geräte Stück für Stück in freier Wildbahn weniger werden), ich habe noch eins für u.U. notwendige Fehlersuchen in meiner Software und ich habe nur begrenzte Ressourcen (Zeit), die ich im Moment beim Thema FRITZ!OS eher darin investiere, (selektiv) OpenWRT-Pakete auf Puma7-Boxen von AVM unter FRITZ!OS nutzbar zu machen, indem die passende Umgebung simuliert wird.
Die MIPS-Modelle sind einfach zu schwachbrüstig und dort sind die Kernel häufig zu alt - auch die 7590 lasse ich künftig (mangels Gerät, ich habe gerade eine Rücksendung an routermiete.de hier liegen) links liegen.
Ob ich das danach dann noch auf ARM-Modelle erweitere (da sind die Kernelversionen neu genug um z.B. Filesystem-Overlays und Namespaces zu unterstützen), weiß ich selbst noch nicht, hängt ja auch vom Erfolg ab und ob sich eben OpenWRT-Pakete überhaupt in ausreichendem Umfang ins FRITZ!OS integrieren lassen. Schließlich reicht es nicht, sie nur zum Laufen zu bringen - man muß sie ja auch noch irgendwie konfigurieren können.
Aber das sind noch viele ungelegte Eier …
Das Modell ist einfach schon zu alt (womit absehbar die Geräte Stück für Stück in freier Wildbahn weniger werden), ich habe noch eins für u.U. notwendige Fehlersuchen in meiner Software und ich habe nur begrenzte Ressourcen (Zeit), die ich im Moment beim Thema FRITZ!OS eher darin investiere, (selektiv) OpenWRT-Pakete auf Puma7-Boxen von AVM unter FRITZ!OS nutzbar zu machen, indem die passende Umgebung simuliert wird.
Die MIPS-Modelle sind einfach zu schwachbrüstig und dort sind die Kernel häufig zu alt - auch die 7590 lasse ich künftig (mangels Gerät, ich habe gerade eine Rücksendung an routermiete.de hier liegen) links liegen.
Ob ich das danach dann noch auf ARM-Modelle erweitere (da sind die Kernelversionen neu genug um z.B. Filesystem-Overlays und Namespaces zu unterstützen), weiß ich selbst noch nicht, hängt ja auch vom Erfolg ab und ob sich eben OpenWRT-Pakete überhaupt in ausreichendem Umfang ins FRITZ!OS integrieren lassen. Schließlich reicht es nicht, sie nur zum Laufen zu bringen - man muß sie ja auch noch irgendwie konfigurieren können.
Aber das sind noch viele ungelegte Eier …
Neueste Beiträge
-
Telefonie hinter einer FritzBox 6850 LTE nutzen- Letzte: chrsto
-
[Sammlung] FRITZ!Smart Control 440 - Firmware 4.89 - 5.xx
- Letzte: pawbrok
-
Mesh System- schlechter Empfang
- Letzte: frank.lennert20
-
[Sammlung] AVM-Gateway-kompatible Zigbee-Geräte- Letzte: alexandi
-
Von 7590AX (8.0) auf 5690Pro (7.62) wechseln
- Letzte: Brombaer
-
Fritzbox nicht unter IPv6 erreichbar
- Letzte: starbright
-
Rufumleitung Agfeo per Keypad im Amt möglich?
- Letzte: slemke
