Nützliche Sicherheitsvorkehrungen vor dem "Fritzen"

[MSprecher]

Als selbst vom Schicksal einer Reboot-Schleife mehrmals Gebeutelter empfehle ich mittlerweile VOR dem "Fritzen" folgendes vorzukehren und zu bedenken:

Solange der Router noch funktioniert, skyteddys ruspeedportuploader installieren und NCftp über dieses nützliche Tool installieren lassen. Ein Kernel.Image einer funktionierenden FW ins ruspeedportuploader-Verzeichnis legen. (Aus dem bisher verwendeten FW.image entpacken!)

Beim Erstellen der Firmware in S2F unter Optionen den Punkt für die Erstellung des Recover.EXE-Files wählen.

Nach dem Bau der Firmware liegen die neuen Files: FW-Image, Kernel.image und hoffentlich Speedport-Recover.exe im "Firmware_New"-Verzeichnis unter Linux/Ubuntu.

Mit einem Speedport-Recover-File, einem kenel.image und skyteddys' Tool ist man gut gewappnet und kann einer Reboot-Schleife, die doch ab und zu auftritt, gelassen entgegen sehen.

Gruss
Matthias

P.S.
Am reibungslosesten klappt es bei mir mit Windows XP ohne jegliche Sicherheitsprogramme (Security Suiten, Firewalls, Defender, Antivirus etc, etc.)
Für diesen Zweck habe ich mir ein TrueImage-Festplattenabbild von einer solche XP-Minimalinstallation mit Ubuntu 8.04 als VM erstellt.

 

[Jpascher]

Eine Reboot-schleife wird auch oft zu traumatisch gesehen.

Wird mit dem Skript per push Option geflasht ist es egal ob die Box in einer Reboot schleife hängt oder nicht.

Problem dabei:

Normal bekommt der PC seine Netzwerkseinstellungen per DHCP und verliert die wenn diese versucht erneut eine neu Adresse zu beziehen die kann dieser aber nicht erneut beziehen wenn die Box in einen Reboot-schleife hängt.
Adresse wird aber nicht verloren wenn nicht neu Verkabelt wird oder sonst irgendwas verändert wird.
Einen Hub vorher zwischen Box und PC zu hängen bringt auch gewisse Vorteile.

Verliert man aber die Einstellungen aus irgend einen Grund am PC so muss man die Netzwerkseinstellungen am PC auf statsche 192.168.178.15 und Maske 255.255.0.0 umstellen.

Also wenn die Box wiederholt rebootet -- gelassen bleiben -- erneut Skript starten und erneut mit veränderten Skripteinstellungen flashen.
Ist man sicher, dass die erstellte Firmware sowieso in Ordnung ist, dann kann man ./ftpXXX verwenden um erneut mit push FTP die Firmware zu übertragen.
Ist die Ursache für die Reboots, dass mdt3/4 nicht gelöscht wurden gibt es auch ./CLER_ENV

Eine Recover-Firmware die man sich erstellt hat löst das Problem auf jeden Fall dauert aber etwas länger als wenn man nur erneut flasht.

Jeder der das Skript selber einsetzt bracht keine Windows Tools wie NCFP ...
Ohne Linux bracht man die entsprechende Firmware und NCFP oder Hilfsprogramme die NCFTP verwenden.

 

[MSprecher]

..... Eine Recover-Firmware die man sich erstellt hat löst das Problem auf jeden Fall dauert aber etwas länger als wenn man nur erneut flasht. ...

Danke für die ausführlichen Ergänzungen.

Ich verwende im Alltag Linux ausser für Speed-to-fritz nie. Als 08/15-Windows-Anwender bin ich froh um jede exe- oder bat-Datei, die mir seit 1983 von MS-DOS her geläufiger ist als jedes Linux-Kommando. Gerade in Not-Situationen (die für einen wie Dich natürlich keine sind), wenn die Box scheinbar nicht mehr erreichbar ist und hängt, bevorzuge ich Tools wie die oben beschriebenen.

Gerade die Recover-Firmware-Datei kommt mir da sehr entgegen und ist seit kurzem mein Favorit. Beim letzten Gebrauch hat diese Datei tatsächlich noch das Media-Sensing korrigiert, danach den Rechner gebootet und anschliessend selbständig die Box recovered.
Ich lasse keine Firmware mehr bauen ohne die Option für den Bau einer entsprechenden Recover-Firmware gewählt zu haben.

Ob es an der Verwendung einer auf Windows aufgesetzten Linux-Installation als VM liegt, dass es trotz der Verwendung von CLEAR mdt3/4 und der Push-option immer mal wieder zu solchen Zwischenfällen kommt?

Gruss und Danke an Dich und alle, die uns hier mit Rat und Tat zur Seite stehen.
Matthias

 

[Jpascher]

Eine Übertragung per FTP oder NCFTP muss nicht immer klappen.
Es gibt hin und wieder Fälle, dass einzelne Bytes nicht richtig ankommen.
Wenn einen serielle Konsole am Speedport angeschlossen ist sieht man auch, dass Fehler bei der Übertragung aufgetreten sind. Normalerweise kommt es dann aber zu keinen Flaschen weil die Prüfung anspricht und der Speedport bootet neu ohne, dass alles sauber abgeschlossen wurde.
Das sind aber extreme Ausnahmefälle.
Möglich, dass bei dir erhöre Störeinfüße aus der Umgebubg vorhanden sind.

Eine Fehlerhafte Firmwareerstellung ist kaum der Grund.
Mir sind keine Fälle bekannt bei denen bei intakten Skript Einstellungen nicht wiederkehrend reproduzierbare saubere Ergebnisse erzielt wurden.