Fritzbox 6490 Cable Firmware Update?

Sidebar Sidebar
Upgrade 3CX to v18 and get it hosted free!
Soweit ich weiß (das ist hier wirklich nur "Buschfunk" und ich habe es niemals selbst gesehen/gemacht), erfolgt(e) das Update über einen speziellen Server bei AVM (der irgendwo mal erwähnte c4.avm.de) und der rückte die neuen Daten nur dann heraus, wenn das CM auf einer vorher "angemeldeten" Liste stand.

Das lief auch (soweit man das im "cm_dl_cert" sehen kann) nicht über TR-069, sondern über einen HTTPS-Request (x-www-form-urlencoded) auf Port 51443.

Wenn AVM entsprechende Vorsorge getroffen hat (was ich mal unterstellen will, alles andere kann ich mir nicht vorstellen und da habe ich als Türsteher auch gar keinen Einfluß/Einblick), dann rückt der heutzutage gar keine Zertifikate mehr heraus ... es sollten eigentlich alle Modelle bei den Providern "durch" sein (das alte Zertifikat wurde ja wohl abgeschaltet) und das geladene Zertifikat überlebt auch so ziemlich jeden Blödsinn, den man mit der Box anstellen könnte.

Lediglich Recovery (das setzt dann das erwähnte "recovered=2" im Normalfall) würde (beim derzeitigen Stand in der 06.61, die 06.62 habe ich noch nicht entpackt) diesem Zertifikat gefährlich werden oder eben ein Fehler im Flash.
EDIT: Vermutlich habe ich das mit der 06.60 verwechselt (meine Sicherung davon habe ich leider verloren, daher kann ich nicht nachsehen), bei der 06.61 wird jedenfalls bei der Existenz von /bin/docsisfactorydefault auch das Dateisystem für /nvram nicht mehr komplett gelöscht (bei der 06.50 schon noch).

Da es kein Recovery-Programm gibt und die Box beim Hardware-Fehler ohnehin zum Hersteller kommt, gibt es m.E. keinen wirklichen Grund, den Service noch laufen zu lassen und auf dem Port reagiert folgerichtig auch kein Server mehr (das ist jetzt ein "black hole").

Warum da die Ausführung von "cm_dl_cert" dann hängen bleibt (anstatt "timeout" und einen Fehler zu liefern, vielleicht war ich auch nur zu ungeduldig), weiß ich auch nicht ... es macht den Eindruck, als würde eben nur der erfolgreiche Download (egal wie oft es probiert wird) als Trigger für die Umschaltung auf das neue System und den automatischen Neustart angesehen.
 
Zuletzt bearbeitet:
Nordstern schrieb:
ich frage, da ich nun FW v6.62 und
...
habe und dennoch nicht von VF KD provisioniert werde.:mad:
Zum Vergrößern anklicken....

geht es um diese Ebay Box, die bei VF-KDG schon mal provisioniert war ?
Nordstern schrieb:
Wie sich herausstellte, war eine Nummer von einer eBay UM 6490 Box, die ich bereits provisioniert hatte, jedoch kurz darauf wieder von KDG gekickt wurde
Zum Vergrößern anklicken....

die Frage ist mit welcher Begründig VF-KD die Provisionierung nicht machen will;
ansonsten können wir nicht helfen.
 
Zuletzt bearbeitet:
Ja, genau diese Box. Laut VF ist sie nicht mehr im System... aber mir scheint, dass sie doch noch irgendwo drinhängt...
 
könntest Du mal in Supportdata.txt nachsehen,
da gab es Berichte, dass duch Update von 06.2x nach 06.50 sich die MAC-Adresse geändert hat, d.h. der Aufkleber wäre dann "Asche"

Bitte dann die richtige CM-MAC an VF-KD melden.
 
@Nordstern:
Mit welcher Begründung? CM-MAC hinterlegt?

Ich habe an anderer Stelle gerade Probleme, überhaupt den Aktivierungscode und/oder die Auftragsbestätigung "an Land zu ziehen" (ist als stille Post halt schlecht), daher weiß ich nicht, welche Angaben KDG da erwartet. Wenn das Zertifikat paßt, sollte das auch funktionieren.

Die Ausgabe in den Support-Daten entsteht aus:
Code: 
CMSECPATH=/nvram/1/security
CMDLPATH=/nvram/1/security/download
if [ -f $CMSECPATH/cm_cert.cer ] ; then
   if [ "`readlink $CMSECPATH/cm_cert.cer`" = $CMDLPATH/cm_cert.cer ] ; then
      echo -n "CM certificate: new"
   else
      echo -n "CM certificate: old"
   fi
else
   echo -n "CM certificate: missing"
fi

if [ -f $CMSECPATH/cm_key_prv.bin ] ; then
   if [ "`readlink $CMSECPATH/cm_key_prv.bin`" = $CMDLPATH/cm_key_prv.bin ] ; then
      echo "/new"
   else
      echo "/old"
   fi
else
   echo "/missing"
fi

if [ -f $CMSECPATH/mfg_cert.cer ] ; then
   if [ "`readlink $CMSECPATH/mfg_cert.cer`" = $CMDLPATH/mfg_cert.cer ] ; then
      echo -n "MFG certificate: new"
   else
      echo -n "MFG certificate: old"
   fi
else
   echo -n "MFG certificate: missing"
fi

if [ -f $CMSECPATH/mfg_key_pub.bin ] ; then
   if [ "`readlink $CMSECPATH/mfg_key_pub.bin`" = $CMDLPATH/mfg_key_pub.bin ] ; then
      echo "/new"
   else
      echo "/old"
   fi
else
   echo "/missing"
fi
und wenn da "new/new" steht, sollte das auch stimmen.

Die "Initialisierung" in "docsiscertdefaults" legt die "eingebauten" Zertifikate eben so ab, daß sie sich genauso verhalten, wie die ursprünglich von AVM geladenen - ab da macht es für die Firmware in /nvram dann keinen Unterschied mehr und ob die nun aus dem Urlader oder von Download stammen, sieht man nur noch am Fehlen der "urladercerts.tar.gz".

Die ist eigentlich auch nur ein Relikt aus dem Start der Box, wenn das dort liegende Zertifikat mit dem in /nvram verglichen wird - bei Ungleichheit gewinnt das aus dem Bootloader.

Das "new/new" sagt also nichts darüber aus, woher die Zertifikate und Schlüssel stammen, nur ob sie vorhanden und an der erwarteten Stelle (nach echtem oder "Pseudo"-Download) liegen. "old" sind dann die Boxen, wo das Zertifikat das Ergebnis der dynamischen Erzeugung ist und "missing" hat eben gar kein Zertifikat oder den Schlüssel.
 
Pokemon20021 schrieb:
könntest Du mal in Supportdata.txt nachsehen,
da gab es Berichte, dass duch Update von 06.2x nach 06.50 sich die MAC-Adresse geändert hat, d.h. der Aufkleber wäre dann "Asche"

Bitte dann die richtige CM-MAC an VF-KD melden.
Zum Vergrößern anklicken....
Die macdsl aus der Support-Datei stimmt noch...
 
Zuletzt bearbeitet:
Pokemon20021 schrieb:
könntest Du mal in Supportdata.txt nachsehen,
da gab es Berichte, dass duch Update von 06.2x nach 06.50 sich die MAC-Adresse geändert hat, d.h. der Aufkleber wäre dann "Asche"

Bitte dann die richtige CM-MAC an VF-KD melden.
Zum Vergrößern anklicken....
Kann ich es nicht so bestätigen, CM MAC ist so nach wie vor gleich.
Wenn es anders sein sollte, dann wäre ich bestimmt nicht mehr online wenn man davon ausgeht, dass UM die Informationen abfragen tut.
 
@lleeaaddeerr Vielen Dank für Deine Anleitung in Post #441.
Punkt 3 bricht bei mir immer mit Fehler 106 (Ein nicht näher spezifizierter Fehler traf während des Updates auf.).

Was mache ich falsch?
 
Roadrunner2k schrieb:
@lleeaaddeerr Vielen Dank für Deine Anleitung in Post #441.
Punkt 3 bricht bei mir immer mit Fehler 106 (Ein nicht näher spezifizierter Fehler traf während des Updates auf.).

Was mache ich falsch?
Zum Vergrößern anklicken....

Nichts machs Du falsch, ungültige oder keine Zertifikate - leider
Kannst aber über linux_fs_start umbiegen wo möglich.
Anleitungen dazu findest hier im Forum - Stichwort: "FTP> quote GETENV linux_fs_start"

Viel Glück!

Ps. Muss noch aber dazu erwähnen, dass Du neue Firmware auf die Kiste bekommst, aber ob es dann bei dem Provider Provisioniert wird ist andere Sache
 
Pokemon20021 schrieb:
könntest Du mal in Supportdata.txt nachsehen,
da gab es Berichte, dass duch Update von 06.2x nach 06.50 sich die MAC-Adresse geändert hat, d.h. der Aufkleber wäre dann "Asche"

Bitte dann die richtige CM-MAC an VF-KD melden.
Zum Vergrößern anklicken....

Es ist wirklich vorgekommen das sich die CM MAC durch das Update geändert hat?
 
opto schrieb:
Ist CM-MAC eine andere wie die Mac Adresse des externen Interfaces?
Die kann man nämlich über ar7.cfg (export) überschreiben mit "override" Option
Zum Vergrößern anklicken....

Ja, CM MAC kommuniziert mit der CMTS und Provisioning System das andere ist die Router MAC.
Dann bekommst du zwar eine IP aber es geht kein Traffic mehr wenn du die Router MAC in der ar7.cfg änderst.. Hoffe das ist bei allen Firmwares so ;)
Obwohl das Sicherheitstechnisch nicht so relevant wäre, kann man ja mit nem eigenem Router auch jederzeit hinter dem Modem machen.
 
Zuletzt bearbeitet:
@Nordstern

Antwort auf #440

Hab ich. Von 40 auf 50. oder wie groß sonst??
 
Zuletzt bearbeitet:
update uber gui ergab bei mir fehler 106

über telnet manuall angestubst


# .//var/install
install: have Kernel 2.6.39.3 - set kversion '2.6.39' and FlashUpdateTool '/lib/modules/2.6.39.3/kernel/drivers/char/flash_update/flash_update.ko'
install: check and install new firmware ...
OEM=avm
ANNEX=Kabel
testing acceptance for device Fritz_Box_HW213a ...
korrekt install type: arm_2GB_xilinx_4eth_2ab_isdn_nt_usb_host_dect_wlan11ac_kabel_03023
device has installtype arm_2GB_xilinx_4eth_2ab_isdn_nt_usb_host_dect_wlan11ac_kabel_03023
assumed ANNEX Kabel -- found ANNEX Kabel
device has ANNEX Kabel
OK - OEM avm is supported
OK - accept this update for device Fritz_Box_HW213a ...
testing acceptance for device Fritz_Box_HW213a done
curr: 141.06.24 new: xx.06.61
debug: curr: 141.06.24
debug: new: "XX.06.61"
major_currFWver=141
middle_currFWver=6
minor_currFWver=24
middle_newFWver=6
minor_newFWver=61
check Firmware Version: xx.06.61
DEBUG: 6 >= 6
DEBUG: 61 >= 24
Accept Firmware Version: xx.06.61
install: 2.6.39 check files...
read 0xa305d81e MACIG 0xc453de23
File already contains the checksum, verifying
[cs_calc_sum] sum 0xa305d81e
Calculated checksum is A305D81E
Saved checksum is A305D81E
Checksum validation successful!
chksum for file /var/remote/var/tmp/x86/filesystem.image ok
size for file /var/remote/var/tmp/x86/filesystem.image ok
read 0xbedb5733 MACIG 0xc453de23
File already contains the checksum, verifying
[cs_calc_sum] sum 0xbedb5733
Calculated checksum is BEDB5733
Saved checksum is BEDB5733
Checksum validation successful!
chksum for file /var/remote/var/tmp/x86/kernel.image ok
size for file /var/remote/var/tmp/x86/kernel.image ok
read 0xe47496d0 MACIG 0xc453de23
File already contains the checksum, verifying
[cs_calc_sum] sum 0xe47496d0
Calculated checksum is E47496D0
Saved checksum is E47496D0
Checksum validation successful!
chksum for file /var/remote/var/tmp/filesystem.image ok
size for file /var/remote/var/tmp/filesystem.image ok
read 0x109af085 MACIG 0xc453de23
File already contains the checksum, verifying
[cs_calc_sum] sum 0x109af085
Calculated checksum is 109AF085
Saved checksum is 109AF085
Checksum validation successful!
chksum for file /var/remote/var/tmp/kernel.image ok
size for file /var/remote/var/tmp/kernel.image ok
902+1 records in
903+0 records out
3272+1 records in
3273+0 records out
443+1 records in
444+0 records out
3636+1 records in
3637+0 records out
/var/docsiscertdefaults: Kein CM Zertifikat im Urlader
dl complete but fp still open. (written 0 / 0)
dl complete but fp still open. (written 0 / 0)

kann mir da einer weiterhelfen
 
babboy schrieb:
update uber gui ergab bei mir fehler 106

über telnet manuall angestubst

Code: 
# .//var/install
SNIP
/var/docsiscertdefaults: Kein CM Zertifikat im Urlader
dl complete but fp still open. (written 0 / 0)
dl complete but fp still open. (written 0 / 0)

kann mir da einer weiterhelfen
Zum Vergrößern anklicken....

Hallo babboy,
Aus Entfernung würde ich sagen, der Befehl "/var/cm_dl_cert" hat die Meldungen:
Code: 
dl complete but fp still open. (written 0 / 0)
dl complete but fp still open. (written 0 / 0)
ausgeworfen und war "unglücklich", weil er zwei Certifikate nicht schreiben konnte;

Frage: Welches WAN-Interface nimmst Du ? DOCSIS oder LAN1 ?

bei DOCSIS-WAN würde ich mal das Update per LAN1-Router-Mode vorschlagen.
das hätte den Vorteil, dass man die DOCSIS-Zertifikate für Betrieb nicht benötigt und somit die Meldung "fp/filepointer still open" nicht erscheint.

habe andere HW-/SW-Config, daher kann ich das Fehlerbild nicht nachstellen.

Just my 2 ct.

Gruß
Pokemon20021

- - - Aktualisiert - - -

PeterPawn schrieb:
Problem:
Firmware akzeptiert keine unsignierten Images (damit auch kein "originales" Pseudo-Image), aber entpackt sie nach /var anstelle von /var/unpack
Lösung:
  • Spezielles Image verwenden, das für das Öffnen eines Telnet-Zugangs nicht auf die Ausführung der /var/install angewiesen ist - es gab da mal etwas von den Gegnern des "blauen Teams" (wenn man in rot/blau-Kategorien denken sollte)
Zum Vergrößern anklicken....

bei diesem Problembild denke ich, dass es um Lücke CVE-2014-8886 https://www.redteam-pentesting.de/d...execution-through-manipulated-firmware-images geht,
d.h. "a password-less telnetd listening on port 9999 will be started"
 
hab nun wann über Lan 1 laufen gleiches resultat konnte in dem ersten terminal irgenwas mit

ARM Calling additional procedure failed: UPDATE FAIL 1

lesen

oder sollte die box offline sein


auf versuch die bootpartition zu änderen kam das

ftp> quote GETENV linux_fs_start
linux_fs_start 1

200 GETENV command successful
ftp> quote GETENV linux_fs_start 0
501 Syntax error: Invalid number of parameters
ftp>
 
Moins


Ja, dann versuch es doch mal mit...
Code: 
quote [b]SETENV[/b] linux_fs_start 0
:rolleyes:
 
Um antworten zu können musst du eingeloggt sein.

Zurzeit aktive Besucher

Gesamt: 422 (Mitglieder: 31, Gäste: 391)

Neueste Beiträge

Statistik des Forums

Themen
245,823
Beiträge
2,240,687
Mitglieder
373,086
Neuestes Mitglied
Ben dietl
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.
Ihr E-Mail-Adresse verifizieren

Ihr E-Mail-Adresse verifizieren

Wir haben Ihnen eine E-Mail geschickt. Klicken Sie auf die Schaltfläche im E-Mail-Text, um Ihre E-Mail-Adresse zu verifizieren – (Können Sie diese nicht finden können, dann überprüfen Sie Ihren Spam-Ordner).

IPPF im Überblick

Neueste Beiträge

Direktlinks Telefonanlage

Website-Sponsoren

3CX sponsor
KONTAKTIEREN SIE UNS BEI INTERESSE
| Style by ThemeHouse
XenPorta 2 PRO © Jason Axelrod of 8WAYRUN
Oben Unten
Zurück