Speedport W503V nach abgebrochenem Update Tot

[derfuchss]

Hallo

Ich habe hier einen Speedport W503V TYP A der bei einem Automatischen Firmwareupdate vom Strom getrennt wurde, und nun nicht mehr bootet!

nach dem Start passiert folgendes:
-LAN-Ports werden angesprochen dann aber deaktiviert (zumindest laut PC "Netzwerkkabel wurde entfernt"
-Power LED blinkt rot wenn der Bootvorgang abgeschlossen ist!

Ich habe bereits speed2Fritz versucht aber die VM (Speed2Fritz) findet den Router leider nicht beim Reboot!
Ich habe in den Optionen die Feste IP auch auf 192.168.2.1 geändert da der Router bisher noch nicht gefritzt wurde, was jedoch auch nicht geholfen hat!

hat jemand ne Idee wie der wiederzuerwecken ist?

Danke schonmal im Vorraus
grz

 

[3949354]

Hallo,
Vielleicht kannst Du ja einmal nach dem ruKernelTool suchen und es damit versuchen.

 

[hasomaso]

Hallo,

ich habe das gleiche problem wie bei "derfuchss" nach einem neustart des Speedport's W503v Typ:A blinkt der Power/DSL in 2 sec. zeitabständen ROT und das wars dann auch..! kann per LAN auch nicht mehr ins WebIf des Speedport's damit ich wenigstens die originale T-Com Firmware draufladen kann.
Was für möglichkeiten habe ich noch..? ruKernelTool wie und was muss ich hier alles machen damit das gerät wieder anspringt



Gruß
hasomaso

 

[informerex]

warum hast du nicht die Board-Suche verwendet?

http://www.rainerullrich.de/ruKernelTool.html (sowie siehe Signatur - ruKernelTool hier im Board)
http://www.rainerullrich.de/ruKernelTool/FAQ.html

 

[Ernest015]

Im Script die Option "Build recover image" anwählen, "Push firmware to box via FTP" abwählen.
Nach Durchlauf des Scriptes ist dann im Ordner Firmware.new eine unter Windows ausführbare .exe-Datei. Diese wird so benutzt, wie im zweiten Teil (Reparatur unter Windows) in diesem Beitrag beschrieben. Also feste IP-Adressen wie angegeben setzen und das Programm unter Win7 oder Vista mit "Als Administrator starten" ausführen.

Noch etwas dazu:

Ich habe in den Optionen die Feste IP auch auf 192.168.2.1 geändert da der Router bisher noch nicht gefritzt wurde,...

Hier wird die Adresse der Weboberfläche (192.168.2.1 mit TCOM-Firmware) mit der FTP-Adresse verwechselt. Die Adresse der Weboberfläche ist firmwarebedingt, die FTP-Adresse, über welche das Script oder auch die FTP-Programme das kernel.image hochladen, ist jedoch frei einstellbar. In der Regel lautet sie bei allen Boxen ("echte" Fritzboxen und auch Speedports): 192.168.178.1
Der Rechner braucht dann eine IP aus dem gleichen Subnetz, beispielsweise 192.168.178.19

mfg

 

[nukem]

Hallo zusammen!

Wenn man schon feste IP Adressen verwendet, kann man dem Netzwerkinterface auch gleich eine zweite Adresse verpassen. Dadurch hat man ggf. neben dem Zugriff auf den zu fritzenden Router auch immer noch eine Verbindung ins Internet. Außerdem muss man nicht immer mal wieder die IP-Adresse des eigenen Rechners ändern.
Bisher konnte ich noch keine negativen Nebeneffekte auf die Netzwerkkommunikation mit dem zu flashenden Router feststellen ([OFF TOPIC]mal davon abgesehen, dass ich noch kein funktionsfähiges Kernel gebaut bekommen habe. Aber das ist vermutlich ja ein ganz anderes Problem... Immerhin lässt sich das original tcom-Kernel erfolgreich flashen.[/OFF TOPIC]).

Natürlich sollte man dem Zweit-/Internet-Router dann eine andere Adresse aus dem Bereich 192.168.2.x geben als die 192.168.2.1. Denn sonst knallen die beiden Router spätestens dann zusammen, wenn man auf den zu flashenden Router wieder das original Telekom-Kernel gießt. Der kommt (mit seinem Web-Interface) ja dann ebenfalls mit der 192.168.2.1 hoch...

Mein Konglomerat sieht dann also so aus:

Win7-PC:      192.168.2.19/24
              192.168.178.19/24
              default Route: 192.168.2.10

Ubuntu 10.04: 192.168.2.18/24
(in einer VM) 192.168.178.18/24
              default Route: 192.168.2.10

Wie also bereits erwähnt, haben dadurch beide Betriebssysteme sowohl einen Internetzugang als auch jederzeit Zugriff auf den Router, egal unter welcher IP der gerade bootet... (Außer es geht gar nichts mehr und man muss über die 169.254.1.1 an den Router. Aber selbst hier könnte man durch eine dritte Adresse auf den Netzwerkinterfaces Abhilfe schaffen. )

Ich weiß, dass der Beitrag hier etwas off topic ist und entschuldige mich gleich mal dafür. Aber vielleicht wäre er es ja hilfreich, einen entsprechenden Tipp in einer Anleitung einzubauen. Wobei ich vermute, dass die Netzwerkspezialisten unter uns auch selbst auf diese glorreiche Idee gekommen sind... Insofern befürchte ich auch, dass dieser Hinweis vielleicht auch schon mehrfach hier im Forum herumgeistert.
Aber gerade, wenn man den Router nicht auf Anhieb geflasht bekommt, schont das schon etwas die Nerven (und spart Zeit).
Ich räume allerdings auch ein, dass - je nach Gerätepark - störende Effekte nicht gänzlich auszuschließen sind. Wenn die IP Adressen im eigenen Netz sorgfältig gewählt sind, fällt mir allerdings keine Ursache ein, die für Kommunikationsprobleme sorgen könnte, die man nicht schon vorher hatte. Die Konfiguration "eine feste IP und Direktverbindung zum Router" dürfte dabei aber tatsächlich die sicherste sein (Paranoia-Settings? ).

Gruß
Michael

 

[Jpascher]

Das stimmt alles, leider sind nicht alle so fit mit Netzwerkseinstellungen wie du, darum sind die Empfehlungen einfacher gehalten.

Für einen Upload kannst du auch den FTP_Uploader verwenden.

Ansonsten gilt natürlich was Ernest015 im Betrag #5 schreibt.

 

[nukem]

Für's FTP nehme ich gerne den TotalCommander. Der hat sich bei mir schon seit Version 2.54 bewährt! Auf den Windows-Explorer könnte ich liebend gerne verzichten. Bin NortonCommander-geschädigt...

Einen Tipp hätte ich noch, was die Timeouts in den Download-Skripten betrifft: Dort sind mit wget 2 Optionen festgelegt. Anzahl Versuche (t) und das Timeout (T). Trotz einer ordentlich funktionierenden Internetverbindung, einem Aktuellen 4-Kern-Rechner mit reichlich RAM und ohne weiteren Stress fürs Netzwerk, sind die in den Skripten festgelegten Grenzen zu eng gezogen. :x

Mein Download bei s2f und Freetz scheiterte an "wget -t3 -T 20 ...". Wenn ich den Timeout auf 40 Sekunden anhebe, klappen alle Downloads. Vielleicht hängt das ja mit der Kombination aus Win7x64, VMWare und Ubuntu zusammen. Aber wie auch immer, 20 Sek. mehr sollten ja auf jeden Fall drin sein...

Zumal hier ja im Wesentlichen diese Konfiguration auch empfohlen wird (Windows mit VM und Ubuntu). Ums Haar hätte ich den Kram nämlich frustriert hingeworfen und meine tcom-Firmware behalten...

Aber wie es aussieht, ist es mir jetzt doch gelungen (mit der r1197) ein funktionierendes Kernel zu erzeugen!

Vielen Dank also noch für dieses großartige Skript!!!

:groesste:

 

[Jpascher]

Wenn das erwünscht ist ändere ich das gerne bei speed-to-fritz, du bist der erste der damit Problem hatte.

Bezüglich Freetz: Die Entwickler von Freetz müsste man gesondert darauf ansprechen oder ein Tiket diesbezüglich aufmachen.

Wenn du noch angibst in welchen Skripteilen du die Parameter geändert hast würde mir das mehr Sicherheit geben.
Ich finde in speed-to-fritz derzeit nur eine Stelle bei der der Parameter Verwendung fand.