Fritzbox 6490 Cable Firmware Update?

[Pokemon20021]

da ich auch eine Box mit 6.24 habe, ohne Zertifikatsinfos

@riddler:
man kann schon in der 06.24 ein Check durchführen, ob neue Certs vorhanden sind und wo sich ggf. die neuen Certs befinden (Urlader-Bereich oder /nvram-Bereich):

hierzu einfach mal folgende Diagnosebefehle in 06.24 Telnet Umgebung der Box eingeben:

# cat  /proc/sys/urlader/config | grep ZERTIFIKATE
# ls -la /var/tmp/urladercerts.tar.gz
# ls -lR /nvram/1/security/
# ls -lR /etc/docsis/security/

Anschließend kann eine Aussage getroffen werden.

Gruß
Pokemon20021

 

[riddler]

@riddler:
man kann schon in der 06.24 ein Check durchführen, ob neue Certs vorhanden sind und wo sich ggf. die neuen Certs befinden (Urlader-Bereich oder /nvram-Bereich):
...

Leider ist die 6.24 nicht mehr drauf, sondern nur noch die 6.62 & 6.63. Und da is die Situation meinem Verständnis nach etwas schwieriger. (aussichtslos?)

 

[stebe71]

Hallo allerseits!
Ist eigentlich noch von irgendwo der AVM-Cert-Server erreichbar, oder ist der jetzt endgültig down ?

 

[riddler]

Leider ist die 6.24 nicht mehr drauf, sondern nur noch die 6.62 & 6.63. Und da is die Situation meinem Verständnis nach etwas schwieriger. (aussichtslos?)

Update:
Gerade einfach nochmal probiert und - oh Wunder - das Update von 6.62 auf 6.63 über LAN1 hat funktioniert, obwohl es vor einigen Tagen immer den Fehler 106 gab.
Nun ist alles schick und die Zertifikate sind auch new/new. Kann ich jetz auch sorgenfrei ein Factory Reset machen, oder wäre das eine schlechte Idee?

 

[PeterPawn]

Die Firmware der Retail-Boxen berücksichtigt auch beim Factory-Reset, daß die JFFS2-Partition unter /nvram nicht einfach neu initialisiert werden darf (obwohl das eben bei den "echten" Retail-Modellen sogar möglich wäre, denn die haben die Zertifikate ja im Bootloader).

Solange also kein Fehler in der Struktur dieser Partition auftritt (dann klappt das Mounten nicht und im Rahmen der Fehlerbehandlung wird event. doch noch gelöscht, da habe ich aber - aus der Erinnerung - auch schon Varianten gesehen, die dann eher auf das Initialisieren verzichtet haben anstatt über ein "erase"-Kommando an "/proc/mtd" doch noch zu löschen), bleiben bei Firmware >= 06.50 (sofern es sich nicht um die Version 06.50 handelt, bei der CONFIG_C4=n gesetzt ist - kriegt man aus den Supportdaten raus) die von AVM geladenen Zertifikate auch in der "nvram"-Partition erhalten.

Es kann allerdings trotzdem nichts schaden, wenn man sich bei einer älteren Box, wo die Zertifikate nicht bereits im Bootloader enthalten sind, einfach noch eine eigene Sicherung anlegt - bei allen derzeit frei erhältlichen FRITZ!OS-Versionen 06.6x (für die Retail-Boxen) sind ja noch Lücken enthalten, über die man eine solche Sicherung auch interner Daten ausführen kann.

BTW ... bei welchem Provider hat denn das Zertifikate-Update heute noch funktioniert?

 

[riddler]

@PeterPawn
Ich stehe mit einer Zertifikatssicherung wie der Ochs vorm Berg und wäre für eine Anleitung bzw. einen Verweis zur selbiger sehr Dankbar.
Konkret ist es eine ehem. KDG Box (2000 2691) die jetzt auf 6.62/6.63 ist.

Ich bin bei einem ganz kleiner lokalen Kabelanbieter, der eigentlich einen Antenneservice ist und nur unser Wohngebiet versorgt. Aber wie geschrieben, die ganzen Tage (am letzen Wochenende) ging es nie mit dem Update und nu auf einmal...

 

[PeterPawn]

Das Sichern ist hier irgendwo im Thread von mir beschrieben ... wenn ich mir die Historie des entsprechenden Shell-Skripts im GitHub-Repository ansehe, dann müßte das um den 15.11.2016 herum gewesen sein, da habe ich das Skript noch einmal angepaßt (stand vorher nur in irgendeinem Thread in einem Code-Kasten herum) und eingecheckt.

Wenn das Zertifikate-Update bei einem kleineren Anbieter funktioniert hat und der nicht am Ende als Subnetz bei einem der "Großen" läuft, dann wäre das ja wieder einmal ein Indiz dafür, daß der Server auch aus anderen Netzen heraus erreichbar ist ... das klingt aber wieder seltsam. Vielleicht "kennt" AVM diesen Provider ja doch - warum der dann allerdings alte Boxen mit der Notwendigkeit des Updates in seinem (vermutlich eher kleinen) Bestand haben sollte, klingt auch wieder nicht sehr logisch.

Irgendwie wird man aus dem c4.avm.de nicht so richtig schlau ... vielleicht hat AVM den ja auch wieder etwas weiter "geöffnet", nachdem die ganzen Diskussionen darum in diesem Thread erst einmal etwas abgeflaut waren; dazu gab es ja jetzt (zumindest gefühlt) vier Wochen keine Neuigkeiten.

 

[riddler]

Habe gerade mal nachgeschaut. Mein ISP ist envia Tel GmbH und meine Hauptbox, eine weiße UM Box, läuft dort seit knapp nem Jahr mit old/old.
Ist ganz witzig, nach jedem Neustart, versucht der ISP mir ne neue FW draufzuspielen, was nie geht und vermutlich (nicht sichtbar) an Fehler 106 scheitert...

Natürlich würde ich die auch gerne mal auf new/new bekommen - nur kann ich die ja nicht hinter sich selbst an LAN1 hängen

 

[reinhard-gehlen]

@riddler:
man kann schon in der 06.24 ein Check durchführen, ob neue Certs vorhanden sind und wo sich ggf. die neuen Certs befinden (Urlader-Bereich oder /nvram-Bereich):

hierzu einfach mal folgende Diagnosebefehle in 06.24 Telnet Umgebung der Box eingeben:

# cat  /proc/sys/urlader/config | grep ZERTIFIKATE
# ls -la /var/tmp/urladercerts.tar.gz
# ls -lR /nvram/1/security/
# ls -lR /etc/docsis/security/

Gibt es noch eine andere Prüfmöglichkeit ausser dieser bzw. der mittels support.lua?

Grund der Frage: Bei der mir aktuell vorliegenden FB6490 (kdg, FW 6.22/6.26) wurde im Webinterface ein Passwort gesetzt. Der Vorbesitzer kann (oder will) sich nicht mehr daran erinnern. Aufgrund der zuletzt gemachten schmerzlichen Erfahrungen mit dem unbedachten Zurücksetzen auf Werkseinstellungen und dem damit verbundenen Löschen von neuen Zertifikaten möchte ich vorher prüfen welche Zertifkate drauf sind und sie ggfs. vor Werkseinstellungs-Reset sichern.

Über den EVA-FTP-Zugang komme ich rein. (Temporäres) Telnet kann ich nicht installieren, da nach meinem Verständnis der einschlägigen Anleitung die Telnet-Aktivierung (Einspielung eines Pseudo Image) über das Webinterface läuft.

Gibt evtl. die Möglichkeit über EVA die Zugangssperre des Webinterfaces zu umgehen, das alte Passwort zu löschen oder alternativ einen weiteren Benutzer neu anzulegen?

Alternative:
Gibt es eine Möglichkeit vorhandene Zertifikate über EVA zu sichern, ohne zu wissen, wo sie genau liegen?

Gibt es eine Abhängigkeit zwischen den Zertifikaten und dem Webinterface-Benutzer-Account (m.a.W. werden Benutzernamen und Passwort (aktuell unbekannt) bei einem evtl. Zurückspielen gesicherter, neuer Zertifikate benötigt)?.


VG

- - - Aktualisiert - - -


Plan B:
Ich habe den ganzen Thread nochmals kursorisch durchgeklickt. Ich konnte dennoch nicht genau herauslesen, wann einzelne Provider begonnen haben könnten, die Zertifikate gegen neue auszutauschen. Bei KDG wird dies allgemein mit Update auf die FW 6.31 angenommen (vgl. z.B. #443). Mit Inkraftreten des Routerfreiheitsgesetzes wurden die Retail-Boxen bereits mit neuen Boxen ab Werk verkauft. KDG-Homeboxen mit grünem Punkt (und FW 6.31) sollen angeblich auch schon neue Zertifikate bei Versand durch den Provider haben (ebenfalls z.B. #443).

Da meine betroffene Box aber noch die 6.26 ( bzw. die 6.22) hat und sie auch bereits vor einigen Monaten (ich versuche gerade beim Vorbesitzer heraus zubekommen, wann genau) vom Kabel ging, könnte noch die alten Zertifikate wie bei Versand durch den Provider drauf sein, so dass ich mich bei einem Werkseinstellung-Reset nicht nachträglich ärgern müsste.

Falls man einen Zeitpunkt oder einen Zeitraum festmachen könnte, vor dem die FB6490 vom Kabel gegangen sein müsste, bevor sie die neue Zertifikate hätte bekommen können, wann hätte dies sein müssen? Lt. einer Mitteilung im Vodafone-Forum ( https://forum.vodafone.de/t5/Internet-Phone/Update-FRITZ-Box-6490-auf-6-31/td-p/1214796 ) war die 6.31 zumindest Anfang 12/2015 noch in der Testphase.

- - - Aktualisiert - - -

Laut Vorbesitzer ging die betroffene Box bereits im Jahr 2015 vom Kabel und war seitdem nicht mehr dran (genauer kann er es aber leider nicht sagen).

VG

 

[Pokemon20021]

Gibt evtl. die Möglichkeit über EVA die Zugangssperre des Webinterfaces zu umgehen, das alte Passwort zu löschen oder alternativ einen weiteren Benutzer neu anzulegen?

diese Anforderungen werden durch "TFFS-Rücksetzung auf Initialzustand" erfüllt;
siehe auch Lösungspfad von fesc:
http://www.ip-phone-forum.de/showthread.php?t=285810&p=2162540&viewfull=1#post2162540
http://www.ip-phone-forum.de/showthread.php?t=282765&p=2185451&viewfull=1#post2185451
http://www.ip-phone-forum.de/showthread.php?t=282765&p=2185483&viewfull=1#post2185483
http://www.ip-phone-forum.de/showthread.php?t=282765&p=2185451&viewfull=1#post2185451

die Zertificate befinden sich im /nvram, dieser Bereich bleibt von dieser Aktion unangetastet, somit bleiben die Zerts (sofern neue vorhanden) unversehrt.

 

[reinhard-gehlen]

diese Anforderungen werden durch "TFFS-Rücksetzung auf Initialzustand" erfüllt;
siehe auch Lösungspfad von fesc:
http://www.ip-phone-forum.de/showthread.php?t=285810&p=2162540&viewfull=1#post2162540

...

die Zertificate befinden sich im /nvram, dieser Bereich bleibt von dieser Aktion unangetastet, somit bleiben die Zerts (sofern neue vorhanden) unversehrt.

Manchmal sieht man den Wald vor lauter Bäumen nicht. Vielen Danke an @Pokemon20021 für diesen wertvollen Hinweis. Bisher hatte ich die Prozedur von @fesc nur im Zusammenhang mit Bootloops und falschen IP-Routen in Hinterkopf.

Ich habe gemäß seiner Anleitung Zugang zur Box bekommen (und das auf die Schnelle mittels eine Ubuntu-16-10-VM und VMWarePlayer unter Windows 10).

Es waren doch tatsächlich neue Zertifikate auf der Box. Sie wurden - wie @Pokemon20021 schon vorher gesagt hat - nicht gelöscht.

Inzwischen ist die Box auf FW 6.63 mit Zertifikaten new/new.

VG

 

[Pokemon20021]

dann am Besten eine Sicherung der Zertifikate anstarten:
http://www.ip-phone-forum.de/showthread.php?t=286994&p=2195126&viewfull=1#post2195126

 

[TomTomNavigator]

Bei den neueren Fritz!OS Versionen werden die Zertifikate beim Rücksetzen nicht mehr gelöscht, steht auch irgendwo hier im Thread.
Ist also imho unnötig die Zertifikate jetzt noch zu sichern.

 

[reinhard-gehlen]

Hinsichtlich der fünften (und vorerst letzten(*)) von mir entbrandeten und mit einem Firmware-Update versehenen Providerbox FB6490 Cable habe ich noch einen Frage an @Pokemon20021 und/oder @PeterPawn und/oder jeden, der helfen kann.

Die letzte Box (Seriennummer beginnend mit F422) kam mit Firmware 6.50-kdg in FS0, FS1 war leer. Die Zertifikate waren new/new.

Nach den Hinweisen von@Pokemon20021 #1356 (http://www.ip-phone-forum.de/showthread.php?t=286994&p=2198201&viewfull=1#post2198201) und @tetzlav #1047 (http://www.ip-phone-forum.de/showthread.php?t=286994&p=2189010&viewfull=1#post2189010) habe ich mit den Scripten von @PeterPawn, den erweiterten Supportdaten und der provideraddtive.tar zuerst eine mtd.img-Datei gebaut und mit dem Script eva_store_tffs eingespielt. Das hat soweit wunderbar funktioniert.

Nach Neustart der Box habe ich im nächsten Schritt dann über newfirmware.image und den beiden Scripten run_update und update_firmware im Fritz!NAS (= /var/media/ftp) ein Update auf die FW 6.62 gemacht. Auch das hat problemlos funktioniert. Ziel war es, die FB6490 über LAN1 mit der am Kabel hängende FB6490 zu verbinden und von der FW 6.62 mittels normaler Online-Update-Funktion der Box auf die FW 6.63 zu kommen. So wie ich das bei den anderen vier auch gemacht hatte.
Der Online-Update-Prozess hat auch die neue FW 6.63 gefunden. Jedoch brach das (Online-)Update zuerst mit einem "unspezifiziertem Fehler 8" und dann bei der Wiederholung mit einem "unspezifiziertem Fehler 0" ab.
Daraufhin habe ich das FW 6.63-Image lokal heruntergeladen und offline versucht einzuspielen. Wieder der "unspezifiziertem Fehler 0".
Die einzige Möglichkeit, auf die FW 6.63 zu kommen, war wieder über newfirmware.image und die beiden Scripten run_update und update_firmware. So weit so gut, aber diese Prozedur ist für zukünftige Updates etwas umständlich, ich würde mir wünschen, dass der normale Online-Update-Prozess läufen würde.

Irgend eine Idee, was ich wo vielleicht falsch gemacht habe oder vergessen habe zu löschen?

VG


(*) Nr. 3 musste ich ja wg. meiner Unachtsamkeit bei den Zertifikaten wieder weiterverkaufen, bleiben zwei (eine aktiv, eine cold-standby) für mich und zwei (eine aktiv, eine cold-standby) für eine befreundete Familie.

 

[Pokemon20021]

Nach Neustart der Box habe ich im nächsten Schritt dann über newfirmware.image und den beiden Scripten run_update und update_firmware im Fritz!NAS (= /var/media/ftp) ein Update auf die FW 6.62 gemacht. Auch das hat problemlos funktioniert. Ziel war es, die FB6490 über LAN1 mit der am Kabel hängende FB6490 zu verbinden und von der FW 6.62 mittels normaler Online-Update-Funktion der Box auf die FW 6.63 zu kommen. So wie ich das bei den anderen vier auch gemacht hatte.
Der Online-Update-Prozess hat auch die neue FW 6.63 gefunden. Jedoch brach das (Online-)Update zuerst mit einem "unspezifiziertem Fehler 8" und dann bei der Wiederholung mit einem "unspezifiziertem Fehler 0" ab.
Daraufhin habe ich das FW 6.63-Image lokal heruntergeladen und offline versucht einzuspielen. Wieder der "unspezifiziertem Fehler 0".
Die einzige Möglichkeit, auf die FW 6.63 zu kommen, war wieder über newfirmware.image und die beiden Scripten run_update und update_firmware. So weit so gut, aber diese Prozedur ist für zukünftige Updates etwas umständlich, ich würde mir wünschen, dass der normale Online-Update-Prozess läufen würde.

Irgend eine Idee, was ich wo vielleicht falsch gemacht habe oder vergessen habe zu löschen?

zur Problemanalyse "unspezifiziertem Fehler 8" wäre das Logfile hilfreich:

bei bedarf kann man den Updateprozess mit dem Rechner via netcat -l 514 belauschen. EDIT: Dazu muss der lauschende Rechner natürlich auf die IP 192.168.178.2/24 konfiguriert sein oder man passt die entsprechende IP im Script run_update an: log_ip="192.168.178.x"

 

[reinhard-gehlen]

zur Problemanalyse "unspezifiziertem Fehler 8" wäre das Logfile hilfreich:

Der Log lief leider nicht mit. Ich arbeite nur im Notfall mit Ubuntu und dann nur in einer VM. Ich habe auch keine Idee, wie ich den Fehler nochmals "provozieren" könnte, da ich ja bereits auf FW 6.63 bin.

VG

 

[stoney]

Hallo allerseits!
Ist eigentlich noch von irgendwo der AVM-Cert-Server erreichbar, oder ist der jetzt endgültig down ?

Hab seit ca. 2 Wochen einen VPN Tunnel zu einem VF Anschluss (6490 KDG) welcher als Gateway dient - allerdings endet die Anfrage immer in

openssl s_client -connect c4.avm.de:51443
connect: Connection timed out
connect:errno=110

Edit:

Der Log lief leider nicht mit. Ich arbeite nur im Notfall mit Ubuntu und dann nur in einer VM. Ich habe auch keine Idee, wie ich den Fehler nochmals "provozieren" könnte, da ich ja bereits auf FW 6.63 bin.

VG

linux_fs_start

Damit schon versucht wieder auf die 6.62 zu kommen??

 

[reinhard-gehlen]

zur Problemanalyse "unspezifiziertem Fehler 8" wäre das Logfile hilfreich:

bei bedarf kann man den Updateprozess mit dem Rechner via netcat -l 514 belauschen. EDIT: Dazu muss der lauschende Rechner natürlich auf die IP 192.168.178.2/24 konfiguriert sein oder man passt die entsprechende IP im Script run_update an: log_ip="192.168.178.x"

Nach meinem Verständis wird das o.g. Logfile doch nur produziert, wenn das Update über newfirmware.image und die beiden Scripten run_update und update_firmware im Fritz!NAS (= /var/media/ftp) läuft. Oder sehe ich das falsch?

Ich hatte das Update von 6.50-kdg auf 6.62-avm über den vorgenannten Weg gemacht und da gab es keinen Fehler, welcher zu protokollieren gewesen wäre.
Erst bei dem Schritt 6.62-avm auf 6.63-avm kommt der Fehler 8 (bzw. Fehler 0). Dieses Update habe ich aber aus der WIN10-Umgebung über Webbrowser und dem eingebauten Webinterface der Box sowohl online als auch offline (Download-Image) angestoßen. Erst mit der Prozedur newfirmware.image und den beiden Scripten - ebenfalls angestoßen in der WIN10-Umgebung - hat das Update auch auf 6.63 funktioniert. Wie hätte ich dabei mit netcat ein Log mit dem Fehler 8 produzieren resp. protokollieren sollen?

VG

- - - Aktualisiert - - -

linux_fs_start

Damit schon versucht wieder auf die 6.62 zu kommen??

Ja, der Fehler läßt sich auch reproduzieren.

VG

 

[MGT]

Werte Experten,


aufgrund eurer Einträge habe ich mich jetzt auch mal schlau gemacht, wie ich meine KDG-Box mit FW 6.31 am Unitymedia Anschluss zum Laufen bringen könnte
(inkl. debranding + FW-Update bevor ich die Box-Daten an Unitymedia melde/ die Registrierung anstoße).


Da ja die "erweiterten Supportdaten" erst ab FW 06.50 zur Verfügung stehen, muss ich das tffs image ja über Umwege erstellen.
Auf der ersten Linux-Umgebung ist FW 06.31 (linux_fs_start 0). Unter linux_fs_start 1 blinkt nur die INfo-LED rot. Ich interpretiere das jetzt so, dass dies "empty" bedeutet?!


Folgende Vorgehensweise habe ich jetzt mal zusammengetragen.
Bevor ich es allerdings angehe würde ich euch bitten mal drüber zu schauen, ob das alles so OK ist.




1) VM-Ware Image von Freetz runterladen und in Virtual Box starten (https://sourceforge.net/projects/freetz-linux/)
2) git clone git://github.com/PeterPawn/YourFritz
3) Skripte von YourFritz auf bash anpassen (/bin/sh -> /bin/bash) und Path setzen (PATH=$PATH:.)
4) 001d.bin organisieren (provideradditive) (z.B. https://www.drop***com/s/w0f34vlsu2fyrzf/001d.bin?dl=1)
5) Box booten und in eva anhalten (bei blinken "ftp 192.168.178.1, adam2/adam2 einloggen, mit quit wieder raus)
6) env.txt, count.txt erstellen analog nach (http://www.ip-phone-forum.de/showthread.php?t=285810&p=2162540&viewfull=1#post2162540):
/eva_get_environment env 192.168.178.1 > /tmp/env.txt
./eva_get_environment count 192.168.178.1 > /tmp/count.txt
7) tffs image inkl. 001d.bin erzeugen (als 3. Parameter):

build_tffs_image tffs_name_table /tmp/env.txt /tmp/count.txt /home/freetz/001d.bin > /tmp/mtd.img


--> stimmt der Aufruf so mit der 001d.bin? Muss die Box während der Erstellung im Eva sein oder wird die Generierung unabhängig von einem Boxzugriff durchgeführt?
Ich hatte bei einem ersten Test die Box ausgeschalten. Die Erstellung hat ca. 20 min gedauert und die erstellte mtd.img ist lediglich 5KB groß??
(Anzeige der Dateigröße, wenn ich die Datei zum Windows-Host hin sichere... komischerweise wird ca. 385000k unter Linux angezeigt).


Bevor ich jetzt zum flashen gehe wollte ich mich jetzt an dieser Stelle nochmal absichern, ob das alles so OK ist/war.


Dann:


8.) eva_store_tffs mtd3 /tmp/mtd.img
eva_store_tffs mtd4 /tmp/mtd.img

und dann weiter mit Schritt 6) unter http://www.ip-phone-forum.de/showthread.php?t=286994&page=53&p=2189010&viewfull=1#post2189010




Passt das so oder habe ich was übersehen? Insbesondere die Größe der Datei mtd.img bzw. der lange Erstellungsprozess bereiten mir Bauchschmerzen...




Danke und Gruß,
MGT

 

[PeterPawn]

Da stimmt dann auch etwas mit der "mtd.img" mit einiger Sicherheit nicht ... auch die 20 Minuten sind deutlich zuviel (der Fehler mit dem "base64" in Shell-Code anstelle des Aufrufs einer binären Version, sollte ja weg sein).

Ansonsten mag eine 6490 wohl kein "quit" in einer FTP-Session - ein normales "Ctrl-D" sollte da die bessere/sicherere Alternative sein. Das sei nur deshalb angemerkt, weil sonst beim Auslesen der Daten aus der Box Probleme auftreten können.

Es ist ja kein Problem, vor dem Aufruf von "build_tffs_image" die Eingabedaten (man von der 001d.bin abgesehen, wobei ich die auch selbst erstellen und nicht auf eine fremde zurückgreifen würde) erst einmal einer "Sichtprüfung" zu unterziehen.

Warum und wo da 20 Minuten gebraucht werden, würde ich auch erst einmal genauer ermitteln (da macht es dann eben Sinn, wenn man nicht nur ausgetretene Pfade entlang latscht, sondern weiß was man wie machen muß) - normal wären vieleicht zwei, erst recht in einer VM anstelle eines eher schwachbrüstigen "embedded device".

Keinesfalls würde ich so eine Datei irgendwie in die Box schreiben, solange deren Gültigkeit nicht nachgewiesen ist.