Fritz 6490 Cable mit Bootloop

[hardy-ulm]

Hallo Liebe Gemeinde,

vor Kurzem habe ich die besagte Box von einem Bekannten geschenkt bekommen, da sie übrig war nach einem Tausch. Leider war's kein Tausch weil "alt", sondern die Box hat tatschlich einen Bootloop-Fehler. Vornweg: Ich brauche die Box nicht, und sie ist mein Eigentum. Sie ist als Spielzeug gedacht, weil mich Router interessieren und ich auch schon diverse Kontakte mit Freifunk, openWRT, dd-wrt und entspr. D-Link, TP-Link Routern hatte. Ich bin also nicht ganz Anfänger auf dem Gebiet, habe auch schon Router über TFTP und eingelöteten Pins mit Serialkonsole wieder ans Laufen bekommen (auch wenn es in keinem Verhältnis zum Aufwand stand, da 20€ Router). Nur von den FRITZ-Dingern habe ich was das angeht bisher immer die Finger gelassen! Zu teuflisch waren die roten Kästchen...

Aber, nachdem meine Freundin einen UM Anschluß hat und dort diesen unsäglichen Vodafone Router mit dem Edelstahlrohr als Fuß - dachte ich so - das wäre doch nett wenn diese Box wieder leben würde. Auch, weil es mich stört sowas wegwerfen zu müssen wenn es (möglichweise) nur einen Softwarefehler hat.

Symptom: 2 Sek. Nach dem Einstecken leuchten alle LEDs kurz für eine Sekunden, dann blinkt Power für ca. 16 Sekunden, dann leuchtet Power für ca. 15 Sekunden konstant, blinkt dann noch ca. weitere 30 Sekunden und startet dann nach Aufleuchten aller LEDs wieder neu.

Das habe ich schon probiert: Ein anderes Netzteil, ohne Erfolg. Das Neuschreiben von mtd3/mtd4 nach der Anleitung von triebwerk23.de durch Yourfritz von PeterPawn (ich habe eine env.txt und count.txt gesichert und anschließend tffs mtd.image erstellt und auf die Box kopiert zu mtd3/mtd4). Die Shebang in den scripts habe ich auch vor Benutzung geändert. Das Schreiben von mtd0/mtd1 und mtd6/mtd7 mit den jeweiligen Image-Dateien (aus der Firmware 141.07.01 entpackt) und anschließendes Setzen der SETENV auf "avm" (Anleitung Firmware-Update von "eberhart"). Ich war der Meinung, 6.66 ist wirklich alt und warum dann nicht gleich eine neuere Version draufspielen. Diese Operationen sind alle ohne offensichtliche Fehler durchgelaufen. Mir ist klar dass die Box evtl. nach der Aktion evtl. nicht mehr Kabelfähig ist. Aber dann wäre sie immerhin noch ein cooler WLAN AP.

Hat noch jemand eine Idee was ich noch versuchen könnte außer ein neuer Rekord im Routerweitwurf? Ich wäre für alle Vorschläge dankbar, zumal mich das Thema technisch auch interessiert und gerade ausreichend Zeit durch Ausgangsbeschränkung vorhanden ist ...

Grüße aus dem Schwabenland

 

[prisrak1]

eine 6490 kann man kaum durch software kaput machen, zuminest aus meiner Sicht. Hier kann man was lernen..

 

[KunterBunter]

Das habe ich schon probiert:

Die Umschaltung auf das andere Partitionsset mittels linux_fs_start offenbar noch nicht. Das wäre für mich das erste gewesen.

 

[hardy-ulm]

Du meinst mit Linux_fs_start 0/1 nein das wusste ich in der Tat erst später. Wobei ich bin mir nicht sicher ob ich das richtig verstanden habe, es gibt zwei identische Partitionen und damit lege ich fest von welcher er startet? Ist dann 0 die primäre Start-Partition und 1 die Backup?

 

[KunterBunter]

Kann man so sehen. Ich wollte erst "alternierendes Partitionsset" schreiben. Nach der Umschaltung ist nämlich dann 1 die primäre Start-Partition und 0 die Backup.

 

[koyaanisqatsi]

Und...
Nach einem Recovery gibt es linux_fs_start nicht.
...erst nach Update ( Onlinesuche oder mit Image-Datei ).

 

[hardy-ulm]

Und...
Nach einem Recovery gibt es linux_fs_start nicht.
...erst nach Update ( Onlinesuche oder mit Image-Datei ).

Daraus würde ich schließen, dass es wohl bei einem Update angelegt wird, um notalls auf die ältere Version zurückgreifen zu können.
Wie könnte ich denn jetzt am besten weitermachen? Es ist ja nämlich auch gar nicht gesichert, dass die Box keinen Hardwarefehler hat...

 

[koyaanisqatsi]

Auf definierten Zustand bringen mit einer passenden: Recovery.exe

 

[hardy-ulm]

Auf definierten Zustand bringen mit einer passenden: Recovery.exe

Okay - soweit ich weiß gibt es für die 6490 cable keine Recovery ?

 

[koyaanisqatsi]

Stimmt ja, da war ja was.
( Hatte noch nie so Eine )

 

[NDiIPP]

Nach einem Recovery gibt es linux_fs_start nicht.

1. Gibt es kein Recovery-Tool für die 6490 (wie mittlerweile schon festgestellt) und
2. selbst wenn, würde das wohl für die 6490 nicht gelten, das andere Partitionsset müsste dabei vollständig erhalten bleiben (bei den GRX5 und IPQ4019 Modellen siehst das aber tatsächlich anders aus, wobei die Variable "linux_fs_start" dabei jedoch bestehen bleibt und somit auch nach einem Recovery weiterhin existiert, wenn sie vorher schon existierte).

Ansonsten das, was man kontrollieren/tun sollte:
... Ach nee, ich schreibe das jetzt doch nicht noch mal (wird langsam langweilig), ich verlinke stattdessen auf ein erst vor kurzem erstelltes Thema:
https://www.ip-phone-forum.de/threa...mtd0-mtd1-mtd6-mtd7-in-reboot-schleife.306363


BTW:

(Anleitung Firmware-Update von "eberhart").

Ich weiß zwar nicht, was das für eine Anleitung sein soll, aber ich würde eher auf diese verweisen:
http://yourfritz.de/desc-docsis


BTW 2/Edit:

Das Neuschreiben von mtd3/mtd4 nach der Anleitung von triebwerk23.de durch Yourfritz von PeterPawn (ich habe eine env.txt und count.txt gesichert und anschließend tffs mtd.image erstellt und auf die Box kopiert zu mtd3/mtd4).

Ich würde ja mal das erstellte TFFS-Image überprüfen. Vor allem deshalb, weil die von dir erwähnte Anleitung leider nicht mehr ganz aktuell ist und so mit einem aktuellen Checkout des YourFritz-Repository von PeterPawn nicht mehr funktioniert (Ort und Name der nametable hat sich im Repository geändert). Wäre zumindest nicht das erste mal, das dabei "Müll" erstellte wurde und somit nach dem flashen dieses die Box erst recht nicht mehr funktioniert.

 

[hardy-ulm]

... Ach nee, ich schreibe das jetzt doch nicht noch mal (wird langsam langweilig), ich verlinke stattdessen auf ein erst vor kurzem erstelltes Thema:
https://www.ip-phone-forum.de/threads/6490-cable-lgi-6-50-nach-anfänger-flash-über-ftp-mtd0-mtd1-mtd6-mtd7-in-reboot-schleife.306363

Ja, den hab ich auch schon durchgelesen. Allerdings nutze ich seltenst Windows und eigentlich kein Powershell, weshalb ich die FTP Befehle einfach mal eingetippt hab (im Terminal, Ubuntu Linux). Was auch immer Media set to SDRAM bedeutet, er hat es nicht verweigert. Allerdings das "quote RETR env" - ich mutmaße es heisst retrieve environment - erzeugt bei mir einen 425 - cant open data connection.

Nun habe ich ja eine env.txt sowie eine count.txt (in der stehen allerdings hinten den Variablen nur u's) von vor den Flash Versuchen.

HWRevision            213
HWSubRevision         4
ProductID             Fritz_Box_HW213a
SerialNumber          0000000000000000
annex                 Kabel
autoload              yes
bootloaderVersion     1.3167
bootserport           tty0
cpufrequency          1200000000
firstfreeaddress      0x00b20000
firmware_info         141.06.66
firmware_version      kdg
flashsize             nor_size=0MB sflash_size=2MB nand_size=2048MB
maca                  E0:28:6D:60:B7:44
macb                  E0:28:6D:60:B7:45
macwlan               E0:28:6D:60:B7:46
macwlan2              E0:28:6D:60:B7:47
macdsl                E0:28:6D:60:B7:41
memsize               0x10000000
modetty0              38400,n,8,1,hw
modetty1              38400,n,8,1,hw
mtd0                  0x0,0x4000000
mtd1                  0x4000000,0x4800000
mtd2                  0xa0000,0xc0000
mtd3                  0xc0000,0x100000
mtd4                  0x100000,0x140000
mtd5                  0x140000,0x1e0000
mtd6                  0x4800000,0x8800000
mtd7                  0x8800000,0x9000000
mtd8                  0x0,0x80000
mtd9                  0x80000,0x90000
mtd10                 0x90000,0xa0000
mtd11                 0x9000000,0xd000000
mtd12                 0xd000000,0xd800000
mtd13                 0xd800000,0x11800000
mtd14                 0x11800000,0x12000000
my_ipaddress          192.168.178.1
prompt                Eva_AVM
req_fullrate_freq     100000000
sysfrequency          100000000
tr069_passphrase      iq5567WP9LrN
tr069_serial          00040E-E0286D60B744
urlader-version       4167
usb_board_mac         E0:28:6D:60:B7:42
usb_device_id         0x0000
usb_device_name       USB DSL Device
usb_manufacturer_name  AVM
usb_revision_id       0x0000
usb_rndis_mac         E0:28:6D:60:B7:43
wlan_key              99024536890967807370

 

[PeterPawn]

Ich würde hier noch versuchen, die eMMC-Partition für das NAS neu initialisieren zu lassen - vom Timing her könnte das in etwa hinkommen, daß da (zu lange) versucht wird, die ext4-Partition zu mounten, anstatt das Dateisystem einfach neu zu initialisieren.

Dazu muß nur die Variable "firmware_info" im Urlader-Environment um die Zeichenkette ",recovered=2" ergänzt werden, das geht auch ohne das erneute Erzeugen eines TFFS-Images über ein passendes SETENV im FTP-Server des Bootloaders.

=======================================================================

Was das mit dem Environment aus #12 soll, verstehe ich nicht ... das ist entweder ein uraltes oder Du hast die in #1 beschriebenen Änderungen dann doch nicht "fachgerecht" vorgenommen, wenn es eine aktuelle Version sein sollte. Wenn da eine Retail-Firmware 07.01 installiert ist, dann gehört ein "avm" in "firmware_version" und spätestens dann sollte auch nach dem nächsten Start in "firmware_version" ein "141.07.01" zu lesen sein. Wenn man natürlich mit so einer alten "env"-Datei sein eigenes TFFS-Image gebaut hat, anschließend per EVA den Inhalt von "firmware_version" auf "avm" ändert und danach dann das TFFS-Image nach MTD3 und/oder MTD4 schreibt, ist die Änderung an "firmware_version" ja (logisch, oder?) wieder weg.

Es ist also vermutlich das Beste, wenn hier - anstelle der (durchaus anschaulichen) Beschreibung in Prosa aus #1 - mal ein (vollständiges) Protokoll gezeigt wird und zwar vom Auslesen der Daten über das Erstellen und Flashen des TFFS-Images bis zur Installation der neuen Firmware. Ich würde - anhand des bisher Gelesenen - schwören, daß hier (ggf. auch auf der Basis anderer, eben doch nicht ganz vollständiger Beschreibungen an anderen Stellen im Netz) die Abläufe vermischt bzw. in der falschen Abfolge oder ohne notwendige Anpassungen irgendwelche Aktionen vorgenommen werden, die am Ende zu einer Unverträglichkeit zwischen Environment und installierter Firmware führen.

=======================================================================

Ansonsten bleibt wohl doch nur das Bestücken einer seriellen Schnittstelle (irgendwo hier gibt es einen Thread, welche Pins für welches System sind bei der 6490) und die Installation einer geeigneten Firmware, bei der die Ausgabe auf der seriellen Schnittstelle noch nicht unterdrückt werden. Da böte sich dann z.B. die 06.83 an - für die weiß ich es sicher. Alles ab 07.xx ist dann ohne serielle Schnittstelle (bzw. mit einem Kernel, bei dem die Aus- und Eingaben auf der seriellen Schnittstelle durch eine Compile-Time-Option deaktiviert wurden) und da bringt dann deren Bestücken nichts mehr.

Wenn es wirklich ein Hardware-Schaden sein sollte und der zu einer "kernel panic" mit entsprechendem Restart führt, dann kriegt man auch keinen sinnvollen Zugriff mehr auf das Kernel-Protokoll beim Start (die Ausgabe z.B. von "dmesg" oder "cat /proc/kmsg") und es bleibt nur noch das "Live-Bild" auf der seriellen Schnittstelle, zumal es bei einem Hardware-Fehler auch vollkommen Bummi ist, wie alt die verwendete FRITZ!OS-Version ist.

Allerdings nutze ich seltenst Windows und eigentlich kein Powershell

Dafür gibt es das ganze Zeugs ja auch als Shell-Skript ... keine Ahnung, was Du da (außer den in #1 verlinkten, verstreuten Anleitungen, die leider nicht wirklich alle auf dieses Board als "Originalquelle" verlinken) noch so gelesen hast und was nicht.

Die Anleitung aus dem Link in #11 (http://yourfritz.de/desc-docsis - wobei das nur die Adresse einer Redirection auf die Wayback-Machine ist) kannst Du als die "autorisierte" betrachten ... der Rest sind i.d.R. nur Nacherzählungen von Anleitungen (mal mehr, mal weniger korrekt und/oder vollständig), die sich hier im IPPF finden lassen und mit etwas Pech sind es sogar (eindimensionale) Anleitungen, die nur unter eng umrissenen Voraussetzungen auch so funktionieren, wie es beschrieben oder gezeigt wird (es gibt da ein "berüchtigtes" YouTube-Video, die "Beschwerden" derjenigen, bei denen das eben nicht paßte, finden sich da in den Kommentaren) und wo die Leute am Ende dann doch wieder hier aufschlagen, manchmal auch erst dann, wenn das Kind schon im Brunnen liegt (und die Geschichte mit dem Brathuhn und dem Tierarzt fällig wäre).

 

[hardy-ulm]

Ich würde hier noch versuchen, die eMMC-Partition für das NAS neu initialisieren zu lassen - vom Timing her könnte das in etwa hinkommen, daß da (zu lange) versucht wird, die ext4-Partition zu mounten, anstatt das Dateisystem einfach neu zu initialisieren.

Dazu muß nur die Variable "firmware_info" im Urlader-Environment um die Zeichenkette ",recovered=2" ergänzt werden, das geht auch ohne das erneute Erzeugen eines TFFS-Images über ein passendes SETENV im FTP-Server des Bootloaders.

Das probiere ich gleich mal aus!

Was das mit dem Environment aus #12 soll, verstehe ich nicht ... das ist entweder ein uraltes oder Du hast die in #1 beschriebenen Änderungen dann doch nicht "fachgerecht" vorgenommen, wenn es eine aktuelle Version sein sollte. Wenn da eine Retail-Firmware 07.01 installiert ist, dann gehört ein "avm" in "firmware_version" und spätestens dann sollte auch nach dem nächsten Start in "firmware_version" ein "141.07.01" zu lesen sein. Wenn man natürlich mit so einer alten "env"-Datei sein eigenes TFFS-Image gebaut hat, anschließend per EVA den Inhalt von "firmware_version" auf "avm" ändert und danach dann das TFFS-Image nach MTD3 und/oder MTD4 schreibt, ist die Änderung an "firmware_version" ja (logisch, oder?) wieder weg.

Das env.txt ist noch vor allen Versuchen ausgelesen, auch bevor ist das "neue" TFFS in die Box übertragen habe. Ich habe auch an diesen Daten nichts verändert (außer die firmware_version zu avm). Ich werde versuchen mit den eva_tools die jetzt aktuellen Daten auszulesen. Ich hätte vermutlich noch besser darauf hinweisen sollen dass es alt ist, dafür entschuldige ich mich.

Das mtd3/mtd4 habe ich seither, auch nach dem Flash, nicht mehr angerührt. Ich ging davon aus, dass er diese Daten selber wieder neu aufbaut und entsprechend aktualisiert mit der neuen Firmware. Aber, wenn das nicht der Fall ist, dann passen diese Daten auf gar keinen Fall zur (jetzt) installierten Firmware. Wobei das mit dem firmware_info, recovered=2 dann wohl vorerst keinen Sinn macht, solang das env nicht angepasst ist ?

Leider habe ich die "Referenz Anleitung" im web-archiv erst später gesehen, sie war nicht auf Anhieb zu finden. Trotzdem vielen Dank schon einmal für die vielen Anregungen!

Hier ist die aktuelle Ausgabe von eva_get_environment:

root@lucifer:/usr/local/YourFritz/eva_tools# ./eva_get_environment
Found AVM bootloader: AVM EVA Version 1.3167 0x0 0x36409
Environment read from device:
HWRevision            213
HWSubRevision         4
ProductID             Fritz_Box_HW213a
SerialNumber          0000000000000000
annex                 Kabel
autoload              yes
bootloaderVersion     1.3167
bootserport           tty0
cpufrequency          1200000000
firstfreeaddress      0x00b20000
firmware_info         141.07.01
firmware_version      avm
flashsize             nor_size=0MB sflash_size=2MB nand_size=2048MB
linux_fs_start        1
maca                  E0:28:6D:60:B7:44
macb                  E0:28:6D:60:B7:45
macwlan               E0:28:6D:60:B7:46
macwlan2              E0:28:6D:60:B7:47
macdsl                E0:28:6D:60:B7:41
memsize               0x10000000
modetty0              38400,n,8,1,hw
modetty1              38400,n,8,1,hw
mtd0                  0x0,0x4000000
mtd1                  0x4000000,0x4800000
mtd2                  0xa0000,0xc0000
mtd3                  0xc0000,0x100000
mtd4                  0x100000,0x140000
mtd5                  0x140000,0x1e0000
mtd6                  0x4800000,0x8800000
mtd7                  0x8800000,0x9000000
mtd8                  0x0,0x80000
mtd9                  0x80000,0x90000
mtd10                 0x90000,0xa0000
mtd11                 0x9000000,0xd000000
mtd12                 0xd000000,0xd800000
mtd13                 0xd800000,0x11800000
mtd14                 0x11800000,0x12000000
my_ipaddress          192.168.178.1
prompt                Eva_AVM
req_fullrate_freq     100000000
sysfrequency          100000000
tr069_passphrase      iq5567WP9LrN
tr069_serial          00040E-E0286D60B744
urlader-version       4167
usb_board_mac         E0:28:6D:60:B7:42
usb_device_id         0x0000
usb_device_name       USB DSL Device
usb_manufacturer_name  AVM
usb_revision_id       0x0000
usb_rndis_mac         E0:28:6D:60:B7:43
wlan_key              99024536890967807370

Update: Ich habe es mit SETENV firmware_info 141.07.01,recovered=2 versucht. Der Reboot bleibt nach wie vor. Die Version im environment hat er ja doch offensichtlich selbständig angepasst.

Ich habe den Thread gefunden mit dem Serialanschluss. Ich muss dann bei Gelegenheit meinen Arduino wieder umbauen, ich habe keine so eine Wandlerkarte wie Du auf dem Foto da eingebaut hast. Meinst Du das ist die Arbeit wert, besteht tatsächlich die Möglichkeit die Box wieder zu erwecken? Ich hätte eher schon von Anfang an nicht damit gerechnet, deshalb war ich vielleicht auch ein bisschen leichtfertig dem Aktionismus verfallen.

 

[PeterPawn]

Meinst Du das ist die Arbeit wert, besteht tatsächlich die Möglichkeit die Box wieder zu erwecken?

Ich würde hier von Chancen deutlich jenseits von 50% ausgehen. Die Frage wäre es halt, was da eigentlich defekt ist. Wenn es z.B. das Cable-Modem ist und das System auf dem ARM-Core deshalb irgendwann aufgibt und die ganze Box mit in den Abgrund reißt (beim Beginn des 30-sekündigen Blinkens sollte die Box mit dem Scannen des Cable-Networks beginnen), dann kann man sie zumindest noch - über LAN1 - als zusätzlichen WLAN-AP und Mesh-Client einsetzen. Ist es das WLAN, kann man es ausknipsen und das gilt ebenso für die Telefonie.

Also ja, ich denke schon, daß man da noch "was machen kann" (das wäre ja auch die Frage des Brathuhn-Besitzers an den Tierarzt gewesen, die ich in #13 am Ende meinte) und sich ein Versuch in jedem Falle lohnt.

Solltest Du Dich dazu nicht entschließen können, nehme ich sie gerne (zunächst nur für 10 EUR + Porto/Verpackung - bis ich den tatsächlichen Umfang des Schadens dann kenne, dann zahle ich gerne bis zu einem "fairen Preis" (eBay-Kleinanzeigen oder eBay direkt, natürlich nicht AVM's Mondpreise) noch dazu), bevor Du sie einfach nur in den Elektroschrott wirfst. Wofür man sie am Ende noch einsetzen kann, hängt (hinsichtlich des Cable-Modems) ja auch davon ab, was für ein Zertifikat an Bord ist und woher das kam (Download oder Produktion).

Die erwähnten 10 EUR kannst Du jedenfalls schon für ein gültiges Zertifikat "verlangen" (wenn man mit dem Gerät nichts mehr anfangen kann, aber das Zertifikat noch "erreichbar" ist), denn damit lassen sich (wenn man weiß wie) auch andere Geräte, die selbst halt kein gültiges Zertifikat haben (warum das so sein könnte, kann man im Internet nachlesen), wieder als CM betreiben. Das lohnt sich erst dann nicht mehr, wenn man die aufzuwendende "Arbeitszeit" für Diagnose und weitere Aktionen (angepaßte Firmware, Zertifikat-Transplantation, o.ä.) auch noch in die Rechnung aufnimmt und nicht unter "Lernkurve" oder "Hobby" verbuchen kann.

Kommerziell lohnt sich das (für ein einzelnes Gerät) nicht und gegen einen Händler, der das in etwas größerem Stil betreiben will mit dem "Refurbishing" (EDIT: nur hinsichtlich "Branding" und "Retail-Firmware", nicht daß das jetzt jemand auf die Transplantation von Zertifikaten bezieht), versucht AVM ja gerade gerichtlich vorzugehen (https://www.heise.de/ct/artikel/AVM-verhindert-Verkauf-gebrauchter-Fritzboxen-4688693.html) und hat sich dabei u.U. sogar mit dem ausgelösten Shitstorm ein Eigentor geschossen (mal sehen, wie das Verfahren dann ausgeht). Mittlerweile spielt eben auch der "Nachhaltigkeitsgedanke" eine deutlich größere Rolle, als AVM vielleicht erwartete und da versteht man eben nicht, wenn 20.000 Geräte, die absolut "noch gut" wären (mit der richtigen Behandlung und den passenden Zertifikaten in den alten Boxen) und den Käufern - gerade auch in diesen Zeiten, wo so mancher beginnen muß "zu knapsen" und niemand weiß, wohin die Reise wirklich geht, wenn man "auf Sicht" fährt - doch einiges an Geld sparen könnten, jetzt "vernichtet" werden sollten.

EDIT: Da fehlte noch was ...

Da man den Gedanken der Nachhaltigkeit eben auch im Kleinen hegen sollte, würde ich also die Box an Deiner Stelle nicht wegwerfen - sie ist zwar kein "Goldstaub", aber selbst als "Lernobjekt" für jemanden, der sich mit dem Aufbau von FRITZ!Boxen an sich befassen will (auch wenn die Puma-Modelle schon "sehr speziell" sind, ist die Firmware-Struktur ja praktisch dieselbe, seitdem das CM vom FRITZ!OS isoliert wurde), kann sie garantiert noch ein anderer brauchen, wenn Du das nicht selbst machen möchtest.

 

[hardy-ulm]

Hallo Peter und nochmal vielen Dank für Deine super ausführliche Antwort!

Ja, ich wollte in der Tat auch etwas mehr über die Boxen lernen. Denn bisher habe ich das so gehandhabt, dass alles was nicht mehr ging (egal ob DSL oder Kabel) in den Schrott fliegt und durch eine neue ersetzt wird. Bis auf zwei Ausnahmen, eine, die trotz DSL-Schaden noch als WLAN Router einwandfrei funktioniert (7490) und eine, bei der ich einen Keramik-Kondensator mit Kurzschluss und zwei Dioden ersetzt habe (7360) die aber noch keinen Test am DSL oder allgemein einen Dauertest erlebt hat. Das bloße "wieder funktionieren" war mir in diesem Fall schon ein riesiges Erfolgserlebnis.

Ich finde aber, und fand schon immer, dass das eine unmögliche Resourcenverschwendung ist. Diese Box, an der ich meine Versuche bisher gemacht hab, sollte ebenfalls in den Schrott. Die Versuche sind dem Umstand geschuldet, dass meine Freundin einen Kabel-BW Anschluss hat (mit deren Standard-Router) und dort schon lang das WLAN nicht mehr richtig funktioniert. Nun wollen sie halt keine Box für 200€ zum "Versuch" kaufen. Deshalb dachte ich, ich probiere einfach mein Glück ob ich sie zur Kooperation bewegen kann.

Mit anderen Geräten habe ich schon einiges angestellt (openWRT, dd-wrt, Freifunk) und das war auch meistens erfolgreich. Bis auf einmal, da musste ich tatsächlich eine serielle Konsole benutzen und mit TFTP die Firmware eines Routers wiederherstellen. Aber auch das ging letztlich gut. Ich hätte auch einen EEprom-Flasher zur Not noch greifbar. Der wirtschaftliche Gedanke steht eher im Hintergrund, da verbrät man eh soviel Zeit damit, dass sich das niemals lohnt. Aber hier überschneidet sich einfach mein Beruf, die Informatik, mit dem Hobby, der Elektronik. Denn so ein alter WLAN-Router mit openWRT hat wieder relativ aktuelle Sofware und ist durchaus noch benutzbar und auch nicht so angreifbar wie mit der original-uralt-firmware. Der Lebenszyklus ist ja bei solchen Geräten wohl allgemein so lange vorgesehen.

Bei den Fritzen ist jedoch alles, was ich da bisher kenne, anders. Allein schon die Vielzahl der Partitionen ist ja der Wahnsinn. Ich glaube aber, dass ich die "Referenz-Anleitung" ganz gut verstanden habe. War sehr aufschlussreich, wennglich ich da auch nur an der Spitze des Eisbergs kratze. Wenn Du mir noch ein paar Ratschläge geben kannst (und auch Lust drauf hast), was ich noch versuchen könnte um den Fehler (möglicherweise auch Hardware) einzugrenzen, dann habe ich da auf jeden Fall Lust und gerade ja auch Zeit dazu!
Ansonsten würde ich Dir die Box einfach schicken. Bezahlen musst Du mir dafür nichts, Du hast ja auch schon Deine Zeit in Form der vielen Beiträge investiert.

Gruß aus dem Schwabenländle

EDIT: Achso, wegen der Aktion von AVM ... die stinkt natürlich, wie ich finde. Ich glaube dass die nicht soo besonders viele Kabelboxen verkaufen, und, das ist ja klar, jede gebrauchte verkaufte ist eine neue weniger, die verkauft wird. Ich glaube dass denen das bei 20.000 Stück schon echt weh tut. Nichts desto trotz find ich es nicht gut, auch wenn ich ein wenig Verständnis daür habe. Man sollte im Sinne des Verbrauchers und der Umwelt handeln, sie brauchen ja keine Garantie oder Support zu bieten, das sehe ich natürlich ein.

 

[PeterPawn]

Mach am besten erst mal eine serielle Schnittstelle dran bzw. den Wandler. Der kostet keine 5 EUR (wenn man einen mit CP2102 und USB-A-Stecker nimmt, da hat man dann halt nur die "fliegenden Anschlüsse" bis irgendwo dort, wo man den Stecker einführen könnte) und man muß ihn auch nicht - wie ich bei denen mit FT232 und Mini-USB-Buchse - "fest" ins Gerät einbauen, so daß der max. Verlust, den man hat, falls das Gerät dann doch weggeworfen wird, die Pfostenleiste ist, die man dort einlöten sollte anstelle einer "festen" Verbindung des Wandlers mit dem PCB, weil man dann auch mal einen anderen Wandler testen kann, wenn einem etwas "komisch" vorkommt - ich habe auch schon nach Problemen in der Hardware einer Box gesucht und dann war nur das RS232-USB-Interface kaputt.

Dann die bereits erwähnte, ältere Firmware installiert, damit man da auch etwas sieht und dann kriegt man schon raus, wo das Problem liegt, was den Neustart verursacht. Das Patchen des "mute"-Flags in neueren Kernel-Images ist dann erst der nächste Schritt auf dem Weg - da braucht's dann intensivere Beschäftigung mit den Interna - und für die Diagnose eines echten Hardwareschadens reicht eine alte Firmware auch aus.

Alles Weitere muß man dann sehen ... die Investitionen, selbst wenn sie sich als umsonst herausstellen sollten, liegen dann bei unter 10 EUR (schon mit Kabeln, Pfostenleiste, Wandler, Versand - wobei man natürlich 3 oder 4 Pins einer Pfostenleiste oder auch drei/vier "Patchkabel" nicht wirklich einzeln kriegt und besser in der "Bastelkiste" haben sollte) und - sagen wir mal - max. 1 Stunde Arbeitszeit, wenn man weiß, an welchem Ende der Lötkolben heiß wird und man einen passenden Schraubendreher hat (ich weiß aus dem Kopf nicht mal, was da für Schrauben drin sind - sehen stark nach Torx aus, wenn ich (ohne Brille) draufschaue).

Ansonsten hat hier eigentlich jeder noch die Antworten auf seine Fragen erhalten ... entweder durch eigene Suche, weil die schon an andere gegeben wurden, oder auch durch neue Threads wie diesen, wenn das dann nicht wieder Fragen waren, die schon 1000x durchgekaut wurden.

Insofern bedanke ich mich auch mal meinerseits für diesen Thread ... #1 unterscheidet sich wohltuend von dem, was man ansonsten so manches Mal lesen kann/muß/darf "als Einstieg" in ein Problem und da solche Hardware-Schäden i.d.R. auch per se schon etwas "Einmaliges" sind (mal abgesehen von gelöschten TFFS-Partitionen und nicht erreichbaren Boot-Loadern, weil die falsche ARP-Antworten senden), sehe ich auch kein wirkliches Problem, solche Hardware-Probleme dann - bei Bedarf bzw. wenn es paßt auch nur mit Verweis auf andere Threads - im Einzelfall "zu ventilieren".

 

[hardy-ulm]

Hallo, ich wollte mich mal nochmal zurückmelden. Am WE habe ich versucht die serielle Schnittstelle in Gang zu bekommen. Ich habe dafür einen Arduino Uno mit den Tx/Rx Anschlüssen benutzt. Allerdings konnte ich nicht lauschen. Ich kam dann auch dahinter warum: Ich habe nur die Firmware 6.87 als älteste bei mir, die 6.83 würde ich wohl benötigen. Ich habe ziemlich lange gesucht, allerdings nicht gefunden. Deshalb stagniert das Vorhaben gerade ein wenig, ich weiss echt nicht wo ich die herbekomme. Es gäbe wohl auch die Möglichkeit, die neuere Firmware mit gepatchtem Kernel zu compilieren, aber damit kenne ich mich leider so gar nicht aus.

 

[stoney]

FW-Anfragen kannst Du ganz simpel hier im Subforum anfragen (ist sogar Sticky/gepinnt)

[Sammlung] Suche Firmware & Recover-Images

 

[PeterPawn]

Ausnahmsweise mal von mir, weil mich das Thema auch selbst interessiert, woran es denn nun wirklich liegen mag: Auf entfernt stehen für eine begrenzte Zeit (nicht aus Urheberrechtsgründen, sondern weil ich die alten Versionen bei den DOCSIS-Modellen nicht verbreiten WILL - das ist hier ein Sonderfall) folgende Images zum Download zur Verfügung (die Rechte werden danach einfach wieder so geändert, daß diese Image-Dateien nicht länger für die Öffentlichkeit erreichbar sind und auch den Beitrag hier ändere ich dann wieder):

entfernt

Das ist einfacher, als jetzt jede einzelne Version durchzuprobieren, wo die Serielle "muted" ist und wo nicht - bei der 141.06.83 SOLLTE das nicht der Fall sein, wobei ich auch nicht sicher bin, ob ich eine originale Version oder doch schon eine geänderte auf der eigenen Box habe (und ich habe keine Lust, das jetzt per Vergleich zu ergründen). Es sind alles Images für die Retail-Boxen, die AVM so auch bereitgestellt hat - sprich: Sie sollten auch die Signaturprüfung bestehen, wenn sie jemand entsprechend überprüfen möchte. Und natürlich werden sie dann auch wieder (unverändert) unter GPL-Bedingungen weiterverbreitet von mir ...