Fritzbox 6490 Cable Firmware Update?

PeterPawn frage an dich als experte was sagst du dazu was einem Kunden bei Primacom geschah, ich habe gestern schon geschrieben.
Wie ist das möglich dass der Provider in einem Privaten Router rumfuscht , und firmware downgrade vollzieht .

"Ich bin auch seit Samstag mit der eigenen FritzBox online... und jetzt kommt der größte Ärger:
Ich hatte auch FritzBox mit OS 6.60 gekauft und auf 6.61 geupdatet... Aktivierung lief ohne Probleme... SIP funktionierte jedoch überhaupt nicht und Daten waren kurze Zeit im Kundencenter zu sehen.. und danach verschwunden!.... heute mit einem Techniker über die SIP Problematik geredet - er hat einen Reset durchgeführt.... - und jetzt kommt das krasseste... - Meine FritzBox hat nun die 6.50 drauf und wurde komplett zurückgesetzt! - Ist gebrandet (noch steht dort "Rufnummer eintragen" möglich) und ich hab keine Möglichkeit mehr Updates zu machen!
Soeben mit AVM telefoniert... die können das gar nicht glauben, dass PrimaCom hier ein Firmware-Downgrade vollzogen hat ohne deren oder meines Einverständnisses!
 
Hallo opto hast du versucht den Trafik mitzuschneiden von der Retailbox wenn du auf update Butten drückst,
um zu sehen von welchen Server der das zieht.

Die 6490 sollte auch in der Retail-Version keinen direkten Zugriff auf die "capture.lua" zulassen

Hallo zusammen,
der Vorschlag von geronin sollte sich z.B. mit FB6490 im "Internet-Verbindung via LAN1" Modus mit vorgeschaltetem Switch mit Mirrorport,
alternativ vorgeschalteter LINUX-Router, ... umsetzen lassen.

Gruß
Pokemon20021
 
Hallo opto hast du versucht den Trafik mitzuschneiden von der Retailbox wenn du auf update Butten drückst, um zu sehen von welchen Server der das zieht.
Die 6490 sollte auch in der Retail-Version keinen direkten Zugriff auf die "capture.lua" zulassen ...
Man könnte doch Internetverbindung auf LAN1, Sniffer zwischen und dann Update suchen...? Oder machen die Retailboxen nur Update über Cable?
 
Warum sollte ich da eine andere Meinung haben als AVM ... wenn das eine Retail-Version gewesen sein sollte (es klingt ja so) und diese die notwendigen Zertifikate an Bord hat, die sie als Retail-Version ausweisen, dann sollte so etwas m.E. nicht möglich sein - das wäre für mich ein Software-Fehler.

Wo der dann genau liegt (das geht schon dabei los, daß sich diese ältere Version eigentlich nur als "Downgrade" mit "-f"-Parameter beim Aufruf von /var/install installieren lassen sollte und das ist normalerweise "ein Spezialfall"), wird sicherlich AVM schon im eigenen Interesse schnellstens klären ... spannend wäre es hier für mich, auf welchem Weg der Provider das Update in die Box bekommen hat. Als CVC-Datei wäre die naheliegendste Variante ... die Alternative wäre wohl doch TR-069 (wenn da z.B. ein ACS über DHCP gesetzt wurde), wenn das nicht richtig "stillgelegt" wurde in der Retail-Firmware. Daß so eine Installation generell möglich wäre über TR-069 (zumindest wenn so eine Datei korrekt signiert ist), war allerdings anzunehmen ... bei einer CVC-Datei sollte die mit dem CVC-Zertifikat von AVM signiert gewesen sein und bei einer TR-069-basierten Aktualisierung wäre dann wohl eine ähnliche Signatur wie bei den DSL-Modellen zu erwarten (deren Fehlen beim Pseudo-Image ab 06.50 das "Update" verhindert, was auch wenig überraschend ist und eigentlich schon in früheren Versionen so sein sollte).

Auf welchem Weg nun diese Retail-Boxen "regulär" aktualisiert werden sollen, ist m.W. auch immer noch nicht abschließend geklärt - und hier meine ich ausschließlich die Retail-Boxen. Wenn AVM als (einzige) Variante tatsächlich das Online-Update verwendet (dann war meine frühere Interpretation des DOCSIS-Standards offenkundig falsch), dann wäre es ja unklar, wie der Provider die ältere Firmware überhaupt auf die Box gebracht hat ... da ist dann wohl etwas in der Firmware noch fehlerhaft. Die Existenz der "Datei-Update"-Seite bei der Retail-Version würde ja sogar wieder dafür sprechen, daß es irgendwann mal "richtige Image-Dateien" geben soll. Ist das tatsächlich der Fall, wird auch das "Modding" der 6490 wieder zum Hobby werden ... daher glaube ich bis zum ersten (offiziellen) Erscheinen einer solchen Datei noch nicht daran.

Am ehesten würde ich (rein aus dem Bauch heraus) auf eine nicht korrekt ausgeführte Installations-/Typ-Prüfung bei der Retail-Version der Firmware tippen, daß diese überhaupt auf die Idee kam, die ältere Version (für die Provider-Boxen) zu installieren.

- - - Aktualisiert - - -

Zum Mitschnitt: Klar könnte man das ... wenn AVM tatsächlich so leichtsinnig sein sollte, die Übertragung so eines Images nicht über TLS (oder sogar DRM, aber auch das ist oft genug diskutiert worden) abzusichern. Ähnliches gilt dann natürlich für die Update-Abfrage ... wobei die ja wohl auch in den anderen Firmware-Versionen zumindest in der Zukunft über TLS abgesichert sein wird, wenn sich die "libjuisclient.so" in allen Modellen durchsetzen sollte. Wenn man da natürlich die Download-Adresse "abgreifen" kann (also in der Abfrage, ob ein Update existiert, wo die Antwort bei anderen Modellen dann auch die Adresse für den Download enthält), dann ist das ebenfalls eine Schwachstelle "in der Lieferkette" und vielleicht ist ja gerade das auch ein Grund, warum im Moment wohl keine Updates auf 06.61 ausgeliefert werden (wenn man einigen anderen Beiträgen zu diesem Thema Glauben schenken will).
 
solange Du nicht konkret dazu schreibst, warum Du die Möglichkeit des Betriebs der 6490 mit Mobilfunk-Modem erwartest
Ich erwarte sie, weil ich es im Ausland vor anderthalb (?) Jahren gesehen habe. Die Box war vom Provider geliefert, aber Kundeneigentum und relativ frei (soweit wie man bei DOCSIS von Freiheit reden kann)

- - - Aktualisiert - - -

"Kabel", bei dem ipv6-natvi bzw DualStack unsichtbar sind

Hat das mal jemand getestet bei einer Box, die noch nie ein Koaxkabel gesehen hat?
 
Ich erwarte sie, weil ich es im Ausland vor anderthalb (?) Jahren gesehen habe. Die Box war vom Provider geliefert, aber Kundeneigentum und relativ frei (soweit wie man bei DOCSIS von Freiheit reden kann.
Ein Mißverständnis ... anders als bei den Punkten IP-Client und WLAN-STA für WAN-Verbindung (auch "Bridge-Modus" gehört zu dieser Aufzählung) sollte ja der Mobilfunk-Punkt tatsächlich funktionieren.

Aber eben nur dann (wie bei den DSL-Modellen ja auch), wenn da ein USB-Stick angesteckt ist (und eine SIM dort eingelegt ist, die entsprechende Dienste unterstützt), der auch von der 6490 erkannt wird.

Das sind (oder waren zumindest mal) deutlich weniger (oder auch andere?) als bei den DSL-Modellen und es wird auch nicht anhand irgendeiner "usbgsm.cfg" auf dem ARM-Core der Stick erkannt. Auf dem x86-Core (da wo der Stick direkt angeschlossen ist) ist das zwar tatsächlich so, da sieht die usbgsm.cfg auch "wie gewohnt" aus:
Code:
VER=:14
###
V=:0421:05c6:0af0:1199:12d1:1410:16d8:1bbb:1c9e:1e0e:19d2:1ee8:
V=:0b3c:07d1:2357:0fce:
###
C=:1199:400b01
C=:12d1:000301
C=:19d2:c0a115
C=:0fce:c01102
###
B=:16d8:555342431234567800000000000009ff524445564348473100000000000000
B=:1c9e:1bbb:55534243123456780000000080000606f50402527000000000000000000000
B=:05c6:0af0:55534243123456780100000080000601000000000000000000000000000000
B=:1e0e:555342431234567800000000000006bd000000020000000000000000000000
B=:12d1:55534243876543210000000000000011062000000100000000000000000000
B=:12d1:55534243000000000000000000000611060000000000000000000000000000
B=:12d1:55534243123456780000000000000011062000000101000100000000000000
B=:0b3c:5553424312345678c000000080010606f50402527000000000000000000000
B=:0421:05c6:0af0:1199:12d1:1410:16d8:1bbb:1c9e:1e0e:19d2:1ee8:5553424312345678000000000000061b000000020000000000000000000000
B=:0b3c:07d1:2357:0fce:5553424312345678000000000000061b000000020000000000000000000000
###
B=:12d11f01:12d11f16:12d11f17:55534243123456780000000000000011062000000101000100000000000000
B=:12d11f19:55534243000000000000000000000611060000000000000000000000000000
###
S=:1c9e3003:2
S=:0fced0cf:3
S=:0fced0e1:2
###
M=:0af07251:D2
M=:1c9e9603:D2
M=:1c9e9605:D3V2C1
M=:1c9e3003:D1C2V3
M=:11996880:D3
M=:119968a3:D2
M=:1bbb0000:D2
M=:12d11001:12d11c05:12d114c9:12d11506:D0V1C2
M=:12d11003:12d11c08:D0C1
M=:12d1140c:12d11436:12d11465:12d114ac:D0V2C3
M=:12d11444:D1C0
M=:1e0e9000:D2
M=:19d20031:19d20117:D2C1
M=:19d20063:19d20104:D3C1
M=:19d20143:D0C1
M=:19d22003:D3V2C1
M=:19d21592:D0V2C1
###
Aber die dort eingerichteten seriellen Ports für das Mobilfunk-Modem werden dann eben über die interne Netzwerkverbindung zwischen den Systemen (die benutzen dafür die 169.254.1.1 (ARM) und die .2 (ATOM), der Port ist die 43210) emuliert, dafür kommt das Programm unter /bin/netttyd zum Einsatz. Die Steuerung bzw. die Benachrichtigung des ARM-Cores über Ereignise bei den USB-Modems erfolgt aus den udev-Skripten auf dem ATOM-Core heraus über den Aufruf von /etc/hotplug/remotegsm (als "entferntes Kommando") auf dem ARM-Core.

Dort wird dann ein LKM namens "netttym" als Client für den Port-Server auf dem x86-Core geladen und im Ergebnis dieses Ladevorgangs werden dann auch auf dem ARM-Core die passenden Schnittstellen eingerichtet ... eben die, die vom ATOM-Core signalisiert werden.

Im Zuge des Hinzufügen dieser Ports kommt dann auf dem ARM-Core irgendwann /etc/hotplug/usbgsm zur Ausführung und dort wird dann keine "usbgsm.cfg" mehr berücksichtigt, dort ist das alles im Skript "verdrahtet":
Code:
[...]
echo "loading GSM tty drivers ... " > $CONSOLE
modprobe option "vendor=0x$VID" "product=0x$PID"
test -d /var/gsm || mkdir /var/gsm
ln -f -s "$TTYUSB"0 /var/gsm/ttyDATA
case $VID in
16d8) ## 4G w12
ln -f -s "$TTYUSB"2 /var/gsm/ttyCONTROL
;;
1c9e) ## 4G xs14
case "$PID" in
9603)
ln -f -s "$TTYUSB"2 /var/gsm/ttyDATA
;;
9605)
ln -f -s "$TTYUSB"3 /var/gsm/ttyDATA
;;
*) ;;
esac
;;
1bbb) ## ALCATEL (TCT) X200S
ln -f -s "$TTYUSB"1 /var/gsm/ttyCONTROL
ln -f -s "$TTYUSB"2 /var/gsm/ttyDATA
;;
12d1) ## HUAWEI
case "$PID" in
1001)
ln -f -s "$TTYUSB"1 /var/gsm/ttyVOICE
ln -f -s "$TTYUSB"2 /var/gsm/ttyCONTROL
;;
1003|1c08)
ln -f -s "$TTYUSB"1 /var/gsm/ttyCONTROL
;;
140c)
ln -f -s "$TTYUSB"2 /var/gsm/ttyVOICE
ln -f -s "$TTYUSB"3 /var/gsm/ttyCONTROL
;;
1444)
ln -f -s "$TTYUSB"0 /var/gsm/ttyCONTROL
ln -f -s "$TTYUSB"1 /var/gsm/ttyDATA
;;
14ac)
ln -f -s "$TTYUSB"3 /var/gsm/ttyCONTROL
;;
1411)
ln -f -s "$TTYUSB"2 /var/gsm/ttyCONTROL
;;
*) ;;
esac
;;
0af0) ## OPTION
if [ "$PID" = "7401" ]; then
ln -f -s "$TTYUSB"3 /var/gsm/ttyDATA
ln -f -s "$TTYUSB"6 /var/gsm/ttyCONTROL
else
ln -f -s "$TTYUSB"2 /var/gsm/ttyDATA
fi
;;
1e0e) ## OPTION i210
ln -f -s "$TTYUSB"2 /var/gsm/ttyDATA
;;
1199) ## SIERRA
case "$PID" in
68a3)
ln -f -s "$TTYUSB"2 /var/gsm/ttyDATA
;;
*)
ln -f -s "$TTYUSB"3 /var/gsm/ttyDATA
;;
esac
;;
19d2) ## ZTE
case "$PID" in
0001)
ln -f -s "$TTYUSB"2 /var/gsm/ttyCONTROL
;;
0063)
ln -f -s "$TTYUSB"3 /var/gsm/ttyDATA
;;
0031)
ln -f -s "$TTYUSB"2 /var/gsm/ttyDATA
;;
0104)
ln -f -s "$TTYUSB"1 /var/gsm/ttyCONTROL
ln -f -s "$TTYUSB"3 /var/gsm/ttyDATA
;;
0117)
ln -f -s "$TTYUSB"2 /var/gsm/ttyDATA
;;
0143)
ln -f -s "$TTYUSB"1 /var/gsm/ttyCONTROL
;;
2003)
ln -f -s "$TTYUSB"3 /var/gsm/ttyDATA
ln -f -s "$TTYUSB"2 /var/gsm/ttyVOICE
ln -f -s "$TTYUSB"1 /var/gsm/ttyCONTROL
;;
*) ;;
esac
;;
[COLOR="#FF0000"]*) echo "Modem $VID:$PID not listed!" > /dev/console;[/COLOR]
esac
## time to boot
sleep 5
umtsd
[COLOR="#008000"]if [ "$CONFIG_USB_GSM_VOICE" = "y" ]; then
test -f /var/gsm/ttyVOICE && csvd
else
rm -f /var/gsm/ttyVOICE
fi[/COLOR]
else
echo "sending switch command to GSM modem $VID:$PID ..." > /dev/console
case "$VID" in
16d8) ## 4G W12
sndusbmsg $DEVICE b 555342431234567800000000000009ff524445564348473100000000000000
;;
1c9e) ## 4G XS14
sndusbmsg $DEVICE b 55534243123456780000000080000606f50402527000000000000000000000
;;
1bbb) ## Alcatel (TCT) X200S
sndusbmsg $DEVICE b 55534243123456780000000080000606f50402527000000000000000000000
;;
0af0) ## OPTION old
sndusbmsg $DEVICE b 55534243123456780100000080000601000000000000000000000000000000
;;
1e0e) ## OPTION I210
sndusbmsg $DEVICE b 555342431234567800000000000006bd000000020000000000000000000000
;;
1410) ## NOVATEL
sndusbmsg $DEVICE b 5553424312345678000000000000061b000000020000000000000000000000
;;
0421) ## NOKIA
sndusbmsg $DEVICE b 5553424312345678000000000000061b000000020000000000000000000000
;;
19d2) ## ZTE
sndusbmsg $DEVICE b 5553424312345678000000000000061b000000020000000000000000000000
;;
1199) ## Sierra
sndusbmsg $DEVICE c 400b01
;;
12d1) ## Huawei
case "$PID" in
1446|1449)
sndusbmsg $DEVICE b 55534243000000000000000000000611060000000000000000000000000000
;;
14d1|14fe|1505|1520|1c0b)
sndusbmsg $DEVICE b 55534243876543210000000000000011062000000100000000000000000000
;;
*)
sndusbmsg $DEVICE c 000301
;;
esac
;;
*) echo "Modem $VID:$PID not listed!" > /dev/console
;;
esac
else
echo "0" > $HANDLE
fi
Ein Stick, dessen VID-/PID-Kombination bis zur roten Zeile nicht in dieser Liste auftaucht, kann auf dem ARM-Core auch nicht als Mobilfunkmoden (und auch nicht als Telefoniegerät, das wäre der grüne Abschnitt) erkannt und verwendet werden und wenn die Firmware kein UMTS-Modem erkannt hat, wird (soweit ich das kenne) auch bei den DSL-Modellen der "Mobilfunk"-Punkt unterhalb von "Internet" ausgeblendet im Menü.

Wenn ich also beim Punkt "Mobilfunk" nach der Begründung für die "Erwartung" gefragt habe, dann meinte ich schon die Aussage (steht m.E. auch so in meinem Beitrag, dort ist - aus der Erinnerung - auch von der Liste der erkannten USB-Geräte (bzw. deren Funktionen) die Rede), welcher Stick dort angeschlossen wurde und daß dieser (neben der vorhandenen SIM, denn der Mobilfunk-Punkt ist m.W. auch noch von einer eingelegten SIM abhängig, hier bin ich aber nicht 100% sicher) in der Liste der von der 6490 unterstützten Mobilfunk-Sticks auch auftaucht (am besten auch noch, wo man diese finden kann, damit man das nachlesen könnte) ... u.a. auch deshalb habe ich ja geschrieben, daß noch lange nicht jeder Stick, der an den neueren DSL-Modellen läuft (oder dort "gängig" gemacht werden kann durch Modifikation der usbgsm.cfg) am Ende auch bei der 6490 funktionieren muß.

- - - Aktualisiert - - -

Wenn man die Liste auf dem ARM-Core mal genauer ansieht, sind es praktisch nur drei Modelle, die von der 6490 als Telefonie-Modem verwendet werden können, zwei von Huawei und eines von ZTE ... nur die Geräte, für die ein "ttyVOICE"-Link eingerichtet wird.
 
Hallo.

Könnte mir einer kurz erklären, wie ich das Update nun genau schaffe. Auf der Box befindet sich das 6.10 OS.

Danke.
 
Alles klar :D

Telnet Verbindung habe ich schon mal. Aber woher das Update nun kommt, fehlt mir.
 
- Nach System/Sicherung/Wiederherstellen navigieren
- "Entwickler-Tools" im browser aktivieren
- Rechtsklick auf den "Datei auswaehlen" Button --> Inspect
- Folgende elemente im HTML code aendern:
id=uiImport aendern in id=uiFile
name=ConfigImportFile aendern in name=UploadFile
- Dann auf "Datei auswaehlen" und das pseudo-image (telnet-1.tar) hochladen
...
nachdem ich das getanhabe kommt
Anhang anzeigen 87118

Hallo fesc, hallo stanpete78 und andere Interessierte,
ich habe das gleiche Problem,
bei Providerbox FB6490 (VF Homebox) FW 06.26 mit AVM Branding erscheint nach Start von telnet-1.tar die Fehlermeldung:
"Es trat ein nicht näher spezifizierter Fehler während des Updates auf. (0)"

meine Config:
Code:
http://fritz.box/jason_boxinfo.xml
<j:BoxInfo>
  <j:Name>FRITZ!Box 6490 Cable</j:Name>
  <j:HW>213</j:HW><j:Version>141.06.26</j:Version>
  <j:Revision>30779</j:Revision>
  <j:Serial>CDAB3412EFHG</j:Serial>
  <j:OEM>avm</j:OEM>
  <j:Lang>de</j:Lang>
  <j:Annex>Kabel</j:Annex>
  <j:Lab/>
  <j:Country>99</j:Country>
  <j:UpdateConfig>1</j:UpdateConfig>
</j:BoxInfo>

Browser: FireFox 45.3.0 (ESR)

Wer kann mir hier Tips zur Problemlösung geben ?
Was ist hier zu tun ?
Gibt es hier verschiedenen FW 06.26 Versionen ?
Hat jemand eine FW 06.26-30779, die funktioniert ?

Bin für jeglichen Hinweis dankbar!

Gruß
Pokemon20021
 
Wer kann mir hier Tips zur Problemlösung geben ?
Was ist hier zu tun ?
Gibt es hier verschiedenen FW 06.26 Versionen ?

Leider kann ich nicht sagen, woran es liegt. Ich wüsste auch nicht, dass da gewissen Boxen sich anders verhalten sollen.
Google doch zur Sicherheit mal nach "thomasheinz pseudo image". Er hat auch eine .tar und vielleicht funktioniert die ja.
Ich hatte zuerst auch eine, die bei mir nicht laufen wollte. Aber wer weiß...

st
 
das war bei mir auch so seite hat ewig geladen und ging nicht weiter, probiere trotzdem ob telnet sich aufrufen lässt.
 
bei Providerbox FB6490 (VF Homebox) FW 06.26 mit AVM Branding erscheint nach Start von telnet-1.tar die Fehlermeldung:
Ich habe die gleiche Fritzbox, auch mit der gleiche OS Version am anfang und konnte telnet und später Update auf OS 6.50 durchführen aber mit lgi Branding.
Mache mal lgi Branding drauf und probiere nochmal.
 
Hallo stanpete78, Hallo geronin, Hallo Aux,
Vielen Dank für Euer Feedback mit Lösungsvorschläge;

Ich habe inzwischen einen Werksreset durchgeführt und die Sprache/Country auf Deutsch umgestellt, sowie einmal durch Assistent durchgeklickt;
anschließend hat das Pseudo-Image funktioniert, d.h. Fehlermeldung war weg und Telnetd war verfügbar..

Danke!

Gruß
Pokemon20021
 
Zuletzt bearbeitet:
Hallo,

also Telnet scheint zu klappen, wird jedenfalls im ruKernelTool angezeigt, auch wenn die 6490-Uploadseite nicht weitergelaufen ist. Wie aber bekommt man jetzt die richtige Firmware auf die Box?
 
meine Frage nach der "urladercerts.tar.gz" ist noch unbeantwortet, wenn ich das richtig überblicke

meine Frage nach den Zertifikaten im Urlader (die sind sicherlich Bestandteil der Finalisierung bei der Produktion) hat ja noch niemand beantwortet. Wer Telnet-Zugriff auf eine Retail-Box hat, sollte die Datei in /var/tmp finden und diese sollte sich auch auspacken lassen ... die dort enthaltenen Zertifikate kann man dann untersuchen.

Hallo PeterPawn,
ich habe in Supportdata der FB6490 VF Homebox3 mit 06.26 AVM nachgesehen,
die Datei urladercerts.tar.gz ist dort im Verzeichnis /var/tmp vorhanden:
Code:
ls -la /var/tmp
drwxr-x---   20 root     root          1220 Jan  1 01:02 .
drwxr-x---   15 root     root           261 Jun 26  2015 ..
SNIP
-rw-rw-r--    1 root     root           775 Oct 16  2015 cm_cert.cer
-rw-r-----    1 root     root          1013 Oct 16  2015 mfg_cert.cer
---------x    1 root     root          2115 Jan  1 01:00 urladercerts.tar.gz
-rw-r--r--    1 root     root          1277 Jan  1 01:01 websrv_ssl_cert.pem

end of DOCSIS SUPPORT
CM certificate: new/new
MFG certificate: new/new
##### END SECTION DOCSIS


##### BEGIN SECTION config Configuration
Configuration
-------------
/var/flash:
crw-r--r--    1 root     root      244, 208 Jan  1 01:00 cert.cfg

Inhalt der Tar-files:
Code:
# cp -p /var/tmp/urladercerts.tar.gz /var/tmp/urlader_certs.tar.gz
#

# gzip -d /var/tmp/urlader_certs.tar.gz
#

# tar tvpf /var/tmp/urlader_certs.tar
-rw-rw-r-- 0/0       634 2015-10-16 15:24:53 cm_key_prv.bin
-rw-rw-r-- 0/0       775 2015-10-16 15:24:53 cm_cert.cer
-rw-r----- 0/0      1013 2015-10-16 14:20:35 mfg_cert.cer
-rw-r----- 0/0       294 2015-10-16 14:20:35 mfg_key_pub.bin
#

Ich hoffe es hilft Dir, sollte noch was fehlen, dann einfach melden.

Gruß
Pokemon20021
 
Ich glaube PeterPawn meinte die Box die seit 01.8 freiverkäuflich ist mit Firmware ab 06.60 mit Update funktion
 
Thema Zertifikate:
Das ist schade ... ich hatte die Hoffnung, daß man das Fehlen der Zertifikate aus dem Urlader als "Unterscheidungsmerkmal" zwischen der Retail- und den früheren Versionen verwenden könnte und erst die Retail-Variante dann so richtig BPI+ (und die Zertifikate) verwenden würde - weil vorher die Provider die Geräte ja ohnehin immer eher als Bestandteil ihres Netzes angesehen haben und da ggf. die CMTS keine wirkliche Zertifikatprüfung vorgenommen haben, wobei m.W. das Schlüsselmaterial ja auch für die Verbindung CMTS<->CM verwendet werden müßte (insofern hätte ich vielleicht mehr nachdenken sollen).

Dann bleibt ggf. noch die Auswertung der Zertifikate bzw. bei den CM-Zertifikaten die Identifikation anhand des "issuers" oder des "subject" als denkbare Unterscheidung, falls AVM für die andere Artikelnummer dann ein anderes (Sub-)CA-Zertifikat verwenden sollte. Wenn es das auch nicht ist, wird es wohl doch keinen (Hard-/Software-)Unterschied zwischen den verschiedenen Artikelnummern geben.

Jedenfalls danke für's Nachsehen ... vielleicht wäre die Information zum Produktionsdatum noch nützlich. Da das CM-Zertifikat ja ein gerätespezifisches sein sollte (und nicht nur für das Modell gilt), müßte diese Box vom 16.10.2015 sein oder zumindest irgendwie um diesen Zeitpunkt herum, falls die CM-Zertifikate samt privatem Schlüssel "vorproduziert" werden sollten und nur bei der Finalisierung samt Bootloader geflasht werden.

Der "common name" (CN) für so ein CM-Zertifikat ist normalerweise die MAC-Adresse des Gerätes und dieses Zertifikat wird mit dem "mfg_cert.cer" (das ist das Herstellerzertifikat und dieses hat dann die x509v3-Extensions für eine "subCA" gesetzt ... also "Certificate sign" und "CRL sign") signiert (logischerweise mit dessen privatem Schlüssel, aber auf PKI-Grundlagen will ich jetzt nicht eingehen).

Ich weiß nur, daß ältere Modelle - die ich in der Hand hatte - dort entweder noch keine Zertifikate im Urlader liegen hatten (vermutlich weniger wahrscheinlich) oder diese zumindest nicht von der Firmware ins tmpfs kopiert wurden ... in älteren Support-Daten taucht diese Datei nicht auf und die hatten meiner Erinnerung nach auch kein "ZERTIFIKATE" im procfs stehen (das muß noch nicht heißen, daß der Urlader keine Zertifikate enthielt). Diese ganze Behandlung ist wohl erst seit der 06.26 dann in der Firmware vorhanden ... die Zertifikate mag es aber doch schon länger geben. Ich finde leider keine Sicherung des Urladers aus einer der ersten Boxen mehr - vielleicht hat ja noch jemand eine der ersten 6490 (mit einer 06.10) und kann da noch einmal nachsehen.

Nach dem, was man ansonsten in der 06.61-Firmware sieht, ist die Datei im tmpfs das Ergebnis des Schreiben von "ZERTIFIKATE /var/tmp/urladercerts.tar.gz" in das Pseudo-File /proc/sys/urlader/config in /bin/docsiscertdefaults und dieses Skript existierte in der 06.10 tatsächlich auch noch nicht.

Diese Pseudo-Datei "config" dient offenbar zum Zugriff auf den Konfigurationsbereich im Urlader, in dem bei der Produktion bestimmte Daten abgelegt werden und dazu sollte bei einer Cable-Box eigentlich auch das CM-Zertifikat für BPI+ bei EuroDOCSIS 3 gehören. Auch andere Daten (welche dort liegen, sollte ein "cat /proc/sys/urlader/config" verraten) müßten sich durch das Schreiben von "<config-part> <filename>" dann "auslesen" lassen - eigentlich wird ja das Schreiben in die angegebene Datei veranlaßt.

Wenn man in den Dump eines Recovery-Programms von AVM sieht, gibt es wohl bei einigen Modellen die Möglichkeit, diesen Konfigurationsbereich im Urlader auch über EVA auszulesen, dazu dient wohl ein "RETR CONFIG" ... das würde auch insofern Sinn machen, als bei einem Update des Bootloader-Codes ja auch die Daten der Finalisierung irgendwie in die neu zu schreibenden Daten für das Urlader-Image gelangen müssen, weil das wohl nicht an integralen Grenzen bezogen auf die "erase size" des Flashs liegt und damit "überleben" könnte, wenn man die Erase-Kommandos entsprechend segmentiert.

Das geht auch bei der 6490 und da die Zertifikate ja offenbar als Tarball und mit gzip gepackt vorliegen, dürfte das aber "auf den ersten Blick" nicht als solches zu erkennen sein. Aber das "gzip magic" 0x1F8B, gefolgt von einem 0x08 für die Kompressionsmethode (siehe RFC 1952), sollte sich auch in dieser "CONFIG"-Datei finden lassen, womit dann dem "Extrahieren" des gzip-Files auch nichts mehr im Weg steht.

Man müßte also auch ohne Telnet-Zugang zu einer 6490 an die Zertifikate gelangen können und dort könnte man dann prüfen (ganz normal mit "openssl" nach "gunzip" und "untar" - allerdings sind die Zertifikate im DER-Format, also "-inform der" angeben), mit welchem Herstellerzertifikat das CM-Zertifikat signiert wurde. Ich habe immer noch die Hoffnung, daß es sich dabei um zwei unterschiedliche Sub-CAs für die unterschiedlichen Artikelnummern handeln könnte ... ansonsten verstehe ich nicht mehr, wie die Firmware das unterscheiden sollte und dann wird wohl doch "alles austauschbar" sein zwischen den verschiedenen Artikelnummern.

Wobei da vielleicht noch die MAC-Adresse an sich bliebe ... haben eigentlich alle Retail-Boxen (2000 2778) eine "spezielle" MAC-Adresse, die nicht mit "C8:0E:14" oder "34:31:C4" beginnt? Die Providerboxen, die ich bisher gesehen habe (waren alle von KDG/VF), hatten "34:31:C4" als OUID in der MAC-Adresse - keine Ahnung, was deren Artikelnummer mal war, die kriege ich auch nicht mehr ermittelt. Aber ich kenne auch noch Boxen mit der Artikelnummer 2000 2657, deren MAC-Adressen eben mit dem erwähnten "C8:0E:14" beginnen. Da das ja ohnehin alles "Software-Einstellungen" sind, wäre natürlich auch noch denkbar, daß AVM die Retail-Boxen alle unter einer gesonderten OUID versammelt hat.
 
Zuletzt bearbeitet:
Ich habe hier eine 6490 cable mit 6.10 OS mit KD branding. Die Firmware habe ich nun auf 6.50 aktualisiert. Aber die Box meldet sich nicht an der CMTS an. (MAC ist neu)

Wenn ich das von @PeterPawn lese, dann fehlt bei der "alten" box das Zertifikat zur Anmeldung oder?
 
die box hat durch das updaten eine neue mac bekommen???
bei welchem Provider bist du denn? entsprechendes Branding wieder eingestellt nach dem update?
 

Zurzeit aktive Besucher

Neueste Beiträge

Statistik des Forums

Themen
244,872
Beiträge
2,219,909
Mitglieder
371,594
Neuestes Mitglied
AA-Idealbau
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.