Fritzbox 6490 Cable Firmware Update?

Über http - Leiste ist ja bekannt - http://fritz.box/jason_boxinfo.xml
Was ich aber feststellen konnte die ausgespuckte Seriennummer ist doch die CM MAC - Adresse

Wenn man sich mal die Mühe macht und den Inhalt von "SerialNumber" aus dem Environment ausliest, wird man (m.W. auch bei der 6490, zumindest bei den bisher vertriebenen OEM-Boxen) recht schnell merken, daß da eben immer Nullen stehen und solange dann HWRevision und ProductID (eine 6490 hat sogar zwei davon, eine auf "a" endende für den ARM-Core und eine mit "x" am Ende für den ATOM-Core) übereinstimmen

das ganze mit Seriennummer und FB6490 ist "mysteriös", und dann kommt noch das Theater mit UnityMedia und telefonische Registrierung und Aufforderung "wie ist Ihre SerienNummer ?"
hier gibt es div. Userberichte, die über Probleme nach falsch Übermittelten Serien-Nummern (z.B. Verwechslung mit TR-069 Username, ...) berichten, da liegt es nahe, dass UnityMedia die Informationen quasi per Pushverfahren von FB6490 erhält und mit dem Account/Vertrag verknüpft.
 
DOCSIS macht SNMP o Ä, dort könnte so etwas übermittelt werden.
 
nun habe ich das Posting zum Thema FB6490 und "serial no" wieder gefunden:

das ja auch irgendwie in den individuellen Einstellungen der FRITZ!Box zu finden sein. Wir reden hier ja über die Seriennummer (Serial no.) auf dem Typenschild und nicht die "maca", die sowohl im CWMP-Account verwurstet ist als auch in diversen anderen Paketen (z.B. TR-069-INFORM oder Update-Abfragen beim Hersteller) als "serial number" übermittelt wird?

wie gesagt meine Fragestellung ist, wie die Seriennummer aus der FB6490 Hardware ausgelesen wird ?
wo wird diese gespeichert und wie gelangt diese zum KNB ?
die Antworten hierzu konnte ich bisher nicht finden oder habe ich irgendwie überlesen.
 
Ich bin ja nach wie vor der Meinung, daß diese Nummer nicht übermittelt werden kann.

Wo könnte so eine Nummer denn abgelegt werden?

Das geht ja nur bei der Finalisierung nach der Produktion und wenn man mal (bei den DSL-Boxen, weil es da einfacher ist, an einen Dump des Bootloaders zu gelangen) die Daten aus zwei Boxen desselben Modells miteinander vergleicht, findet man da nichts (abgesehen von MAC-Adressen), woraus sich diese Seriennummer "speisen" könnte.

Klar, die wird auch in irgendeiner Datenbank stehen und auch das Typenschild will ja erstellt werden, aber ich glaube nicht daran, daß das irgendwo "maschinenlesbar" hinterlegt ist in der Box - zumindest habe ich bisher noch nichts entsprechendes gefunden.

Das erinnert mich bei UM ein wenig an die von früher bekannte Abfrage der Seriennummer eines "zertifizierten Receivers", wenn man ein Premiere-/Sky-Abo abgeschlossen hat.
 
Ich bin ja nach wie vor der Meinung, daß diese Nummer nicht übermittelt werden kann.

UnityMedia behauptet auf Ihrer Internetseite, dass diese Informationen erforderlich sind.
https://www.unitymedia.de/privatkunden/beratung/info/routerfreiheit/
CM-MAC-Adresse und Seriennummer Ihres Routers benötigen wir, um Ihnen die gebuchte Leistung (etwa die korrekte Bandbreite) zuordnen und bereitstellen können.

Seltsam;
für mich sieht die Zwangs-Erfassung der Seriennummer durch UnityMedia nach "Anwender Schikane" oder "Ausschnüffeln" von Produkt-Nummer (Retail-Box oder Ex-Provider-Box) bzw. Herstellungsdatum aus, siehe: http://www.ip-phone-forum.de/showthread.php?t=286994&p=2179281&viewfull=1#post2179281
 
Ich bin kein UM-Kunde und kann hier auch keiner werden ... wenn jemand mit der "falschen" Seriennummer sich eine passende für eine Retail-Box ausdenkt und mit dieser gelingt die Registrierung bei UM, wäre die Frage ja auch geklärt. Soweit bekannt, gibt es dort keine Prüfziffer - es sollte also nur sehr niedrige Hürden geben für die "Generierung" einer eigenen Seriennummer. Wobei die Frage der Prüfziffer ja auch durch einen "Ablesefehler" bei einer korrekten Seriennummer (8 statt 3 oder umgekehrt) schnell zu klären ist ... muß halt jemand machen, der dort Kunde ist.

PS: Ich habe hier gerade eine 6490 mit SN H394.621... und habe mal nachgesehen - da habe ich tatsächlich Probleme, die Ziffern 8 und 9 auf dem Aufkleber auseinanderzuhalten.
 
Zuletzt bearbeitet:
hab hier ne box mit old/old die sich weigert bei nem onlineupdate, fehler 106. ( auf der ersten telnet session steht da "ewnw_check_install" und das ding brich nach gefühleten 5 min ab, im webif erschein der fehler 106 ). an einem ffth sowie an einem dsl anschluss, kabel hab ich leider nirgendwo im bekanntenkreis. von 6.61 auf 6.62 oder 6.63.
wenn jemand um kunde ist, würde ich das ding für experiente zur verfügung stellen...
ist 6.61 drauf mit telnet oder dropbear...
 
Wie sieht es denn mit einer KDG-Box (FW 6.50, new/new) an einem KDG-Anschluss aus? Kann diese mit node 29 auf 6.63 gebracht werden und wird weiterhin provisioniert? Ist für DVB-C-Streaming immer noch ein entbranden notwendig?
 
@ noob_noob

Ich würde sie nehmen, bin UM-Kunde. Wenn ich es schaffe sie auf die 06.63 hochzujubeln mit (new/new) Certs, schick ich sie dir wieder zurück, gar kein Thema.
 
@ noob_noob

Ich würde sie nehmen, bin UM-Kunde. Wenn ich es schaffe sie auf die 06.63 hochzujubeln mit (new/new) Certs, schick ich sie dir wieder zurück, gar kein Thema.
auch wenn's nicht klaptt, hätt ich sie gern zurück. ;) rest per pm, oder? ;)
aber gerade bei dieser box bin ich skeptisch. siehe weiter früher im thread, die hat ne komplett andere seriennummer... willytel box...
vlt lässt sich dort ja was mitschneiden zum thema cert update ... nur bin ich da auf anweisungen von leuten angewiesen, die mehr plan haben. in richtung peter grinst ... :ziggi:
 
Zuletzt bearbeitet:
auch wenn's nicht klaptt, hätt ich sie gern zurück. ;) rest per pm, oder? ;)
aber gerade bei dieser box bin ich skeptisch. siehe weiter früher im thread, die hat ne komplett andere seriennummer... willytel box...
vlt lässt sich dort ja was mitschneiden zum thema cert update ... nur bin ich da auf anweisungen von leuten angewiesen, die mehr plan haben. in richtung peter grinst ... :ziggi:

Logo, das versteht sich doch von selbst. Ich unterschlage doch kein fremdes Eigentum. Ich bin froh dass meine weisse UM-Box am UM-Anschluss tadellos läuft.
Ich versuchs halt sie upzudaten, sollte es wirklich nicht hinhauen, schick ich sie zu den gleichen Konditionen wieder an dich zurück. :)
 
Solange es bereits die Dateien mit den neuen Zertifikaten auf der Box gibt, beendet sich das "cm_dl_cert" nebenbei bemerkt recht früh selbst - damit ist dann auch wieder klar, warum sich niemand um das Ergebnis von "/var/docsiscertdefaults" schert und der Versuch des Updates in jedem Falle aufgerufen wird. Da bereits auf der Box vorhandene Zertifikate ja zuvor an die richtigen Stellen kopiert werden, solange sie dort nicht bereits liegen, führt der Aufruf auf einer Box mit "new/new" gar nicht erst zu einem Verbindungsversuch und damit bleibt das Update da auch nicht hängen, wenn keine Online-Verbindung besteht. Das heißt aber im Gegenzug auch, daß eine einmal aktualisierte Box ohne weitere Vorbereitungen (sprich Löschen der vorhandenen neuen Zertifikate) keinen neuen Versuch starten wird.

EDIT: Vielleicht macht es auch noch einen Unterschied, welche IP-Variante am benutzten Anschluß zur Verfügung steht ... jedenfalls wird für das Update zuerst eine IPv6-Adresse gesucht und erst nach einem Fehlschlag beim Versuch einer IPv6-Verbindung kommt dann IPv4 zum Einsatz. Meine "Fehlversuche" waren bisher alle mit IPv4.
 
Zuletzt bearbeitet:
Code:
# ls -la /nvram/1/security
drwxr-xr-x    3 root     root             0 Jan  1 01:00 .
drwxr-xr-x    5 root     root             0 Jan  1 01:01 ..
-rw-r--r--    1 root     root           760 Jan  1 01:01 cm_cert.cer
-rw-r--r--    1 root     root           636 Jan  1 01:01 cm_key_prv.bin
drwxr-xr-x    2 root     root             0 Jan  1 01:00 download
lrwxrwxrwx    1 root     root            38 Jan  1 01:00 mfg_cert.cer -> /etc/docsis/security/euro_mfg_cert.cer
lrwxrwxrwx    1 root     root            41 Jan  1 01:00 mfg_key_pub.bin -> /etc/docsis/security/euro_mfg_key_pub.bin
lrwxrwxrwx    1 root     root            42 Jan  1 01:00 root_pub_key.bin -> /etc/docsis/security/euro_root_pub_key.bin

Code:
# ls -la /nvram/1/security/download
drwxr-xr-x    2 root     root             0 Jan  1 01:00 .
drwxr-xr-x    3 root     root             0 Jan  1 01:00 ..
#
 
Nochmal zum Thema Serial Number, die wird per DHCP Option 43 übermittelt. Was das Modem alles übermittelt kann man bei cablelabs nachlesen. (keine Sorge ist mal ne kurze Spec)
https://www.cablelabs.com/wp-content/uploads/specdocs/CL-SP-CANN-DHCP-Reg-I10-130808.pdf

Ich kann garantieren, dass diese Serial übermittelt wird, ohne wird auch hier kein Modem freigeschaltet. Im Aktivierungsportal werden diese Daten auch angezeigt wenn der Kunde sein Modem aktivieren will.

Oder per SNMP mal auf der eigenen Box auslesen -> docsDevSerialNumber

Allerdings hat diese Serial komischerweise nix mit der auf dem Aufkleber der Box zu tun ;)
Ist bei den "meisten" Fritzboxen die letzten 3 Octets der MAC Adresse.

Hier mal 2 Beispiele, einmal Fritzbox, einmal TC7200.20

DHCP Option 43 - Vendor Specific Information text: ..ECM..ECM:EMTA:EROUTER..20:01:XX..213.4..141.06.62..1.2411..C80E14..6490..AVM GmbH..EROUTER

DHCP Option 43 - Vendor Specific Information text: ..ECM..ECM:EMTA:EROUTER..00997451703XXX..1.0..STDC.01.04..2.4.0..001095..TC7200.20..Technicolor...
 
Zuletzt bearbeitet:
Daß die an diversen Stellen (nicht nur beim DHCP, auch bei TR-069 oder bei der Suche nach einem Update) als "serial" übermittelte Information existiert, ist unstrittig (hatten wir schon am 23.08.) - das ist aber (fast) immer die bzw. eine MAC-Adresse der Box (mal "maca", mal "macdsl"), die u.a. auch im CWMP-Account und noch einigen anderen Angaben steckt.

Die Frage ist also nicht, ob irgendwo eine Angabe als "serial number" übermittelt wird (und auch nicht unbedingt, welche anderen Angaben das sind), sondern ob das wirklich die Nummer auf dem Aufkleber auf der Rückseite der Box ist - und das war sie zumindest nach allen bisher vorliegenden Erkenntnissen noch nicht.

Da diese Nummer ja offensichtlich nicht in einem Firmware-Image enthalten sein kann (das ist ja für mehrere Boxen dasselbe), muß sie also irgendwo in den "individuellen Daten" einer Box zu finden sein und da steht so etwas erst einmal nicht - die MAC-Adressen hingegen schon und das sind - soweit ich das weiß - auch die einzigen "serial numbers", die bisher beobachtet wurden. Es gibt auch nicht so sehr viele Stellen mit Ausnahme der Daten aus der Finalisierung im Bootloader, wo sich eine solche Nummer "verstecken" könnte und auch dann müßte es ja noch irgendein Interface geben, damit das ausgelesen werden kann.

Einen direkten Zugriff auf die Bootloader-Partition mit Auslesen der Daten von einer bestimmten Stelle würde vermutlich auch AVM nicht programmieren - aber entscheidender ist für mich eigentlich die Überlegung, daß andere Provider ja auch ohne die Angabe der "Serien-Nummer" einer FRITZ!Box klarkommen ... das gilt natürlich nicht für die CM-MAC-Adresse der Box, die auch per Zertifikat beglaubigt ist.

Entweder das ist wirklich die "Schikane" mit dem (m.E. untauglichen) Versuch des Aussiebens alter Boxen über so eine Nummer (das hat bei Premiere auch nie so richtig geklappt, da haben die Leute die S/N irgendeiner Box im Schrank angegeben) und dann lehnt der Provider Boxen mit einer Seriennummer, die nicht mit H beginnt und die 621 in der zweiten Zahlenreihe hat, rundheraus ab oder da hat jemand einfach nicht vorher nachgesehen, daß es bei der FRITZ!Box einen Unterschied zwischen der CM-MAC-Adresse und einer "Serien-Nummer" gibt und nun fehlt die Flexibilität, das noch einmal umzustellen - also wird es halt abgefragt, wobei da auch die Schuhgröße oder das Geburtsdatum angegeben werden könnten, solange nur das Format irgendwie paßt.

Da UM meines Wissens der einzige Provider ist, der diese Nummer wissen will, können das aber auch nur UM-Kunden entsprechend ausloten.
 
Bei einigen wird die Seriennummer im CRM System gespeichert und wurde dort schon immer für interne Zwecke auch verwendet. Gleichzeitig wird so auch überprüft ob eine Box schon einmal angemeldet war oder ein ehemaliges Leihgerät ist, obwohl die MAC dann auch nochmal berücksichtigt wird. Bei Fritzboxen ist die Seriennummer etwas merkwürdig, da sie soweit ich es gesehen habe immer die MAC des eCM ist, ohne die OUI. Bei anderen Boxen stimmt sie aber tatsächlich mit dem Aufkleber auf der Box überein, Thomson, Cisco, Arris z.B.
Denke hier spielt das Provisioning System eine Rolle welches eingesetzt wurde und ob man die Seriennummer einfach schon immer in irgendeiner Form verwendet hat. Da UM ja noch keine Automatisierung für die Freischaltung der Modems hat, werden die nach der Seriennummer suchen, ob die schonmal vorhanden war, wobei ich hier denke das eine gefälschte Seriennummer in der Form wie sie auf dem Aufkleber ist, nicht überprüfbar ist, ich wüsste nicht wie man das herausbekommen sollte. Bei Boxen die vom Provider ausgegeben werden, wird diese Nummer ja beim verschicken des Modems im System registriert, daher ist die überhaupt vorhanden im CRM.
 
bei um scheinen die boxen mit old/old ja zumindest ne verbindung über kabel mit der gegenstelle aufzubauen. bei kd-schland baut meine box keine datenverbindung auf sodas ich nicht auf dei registierungsseite für ne box komme die an dem anschluss nicht registiert ist ...
 


WICHTIG VORAB: Das ist keine Step-by-Step-Anleitung für Leute die nicht wirklich wissen/verstehen was hier passiert. Ich habe diese "Anleitung" nur erstellt um zu zeigen dass das in den vorangegangene Beiträgen diskutierte Proof-of-Concept wirklich funktioniert und versiertere Linux-Nutzer es nachvollziehen können. Wer nicht versteht was hier gemacht wird: LASS ES BITTE und/oder ließ dir ersteinmal den kompletten Thread hier durch!

Weil ich es jetzt schon zum zweiten mal machen musste hier mal eine kleine Zusammenfassung/Gedankenstütze wie man eine Fritzbox 6490 über die provideradditive.tar "öffnet" und auf die aktuellste, bei Bedarf modifizierte Firmware updatet:

EDIT: Damit die scripte fehlerfrei arbeiten sollte man vorab überprüfen welche shell sich hinter /bin/sh verbirgt. ls -al /bin/sh sollte möglichst ein link auf bash sein. Unter Debian/Ubuntu hilft ein sudo dpkg-reconfigure dash mit [x]NO auf default shell.

EDIT2: Und weil PeterPawn mein schönes Listing hier zu kompliziert erschien, hat er kurzerhand ein nettes script tffs_add_file in sein Repo eingecheckt. Es dient primär dazu beliebige Inhalte ins tffs zu packen oder Nodesinhalte auszutauschen. Es holt sich netterweise auch gleich die enviroment-Variablen und counter aus der support-Datei. Das ganze Prozedere hier unten reduziert sich damit nun auf das Erstellen (oder Herunterladen) der provideradditive.tar (Punkt 3), einen Einzeiler und das eigentliche flashen/updaten (Punkt 5.3 bis 8):

./tffs_add_file /<pfad_zur>/support\ FRITZ.Box\ 6490\ Cable\ 141.xxxxxx.txt -o 5 29 /tmp/provideradditive.tar > /tmp/mtd.img

Achso: laut PeterPawn braucht man jetzt das erstellte tffs-Image auch nicht mehr in beide mtd-Partitionen schreiben (Punkt 5.5/5.6). Es reicht wenn man in eine von beiden beschreibt, das System erkennt die aktuellere automatisch anhand der geänderten Segment-ID.

Achso2: bei ./tffs_add_file bitte nicht die die zlib-komprimierte 001d.bin, sondern die ungepackte provideradditive.tar verwenden (selbst erstellen oder von hier)



>>>>>>>>>>>>>>>>>Komplizierte Anleitung>>>>>>>>>>>>>>>>>


  1. erweiterte Supportdaten via http://192.168.178.1/support.lua erstellen und speichern
  2. tffs aus dem den supportdaten extrahieren
    1. git clone git://github.com/PeterPawn/YourFritz
    2. cd YourFritz/tffs
    3. mkdir /tmp/tffs_dump
    4. ./tffs_from_supportdata /<pfad_zur>/support\ FRITZ.Box\ 6490\ Cable\ 141.xxxxxx.txt /tmp/tffs_dump/ 1 (bzw. 2, je nachdem welches linuxfs gerade bootet und aktueller ist. (EDIT: welches tffs gerade aktueller ist, siehe Post von PeterPawn)
    5. ./dissect_tffs_dump < /tmp/tffs_dump/tffs_1.dump
    6. mv /tmp/tmp_<zufallsnummer_des_angezeigten_tempfs> /tmp/tffs_dump/tffs_1
  3. provideradditive.tar erstellen oder meine nehmen
    1. cd /tmp
    2. touch provider_additive_enables_post_install.txt (ist nur ein Platzhalter um ein tar-file zu erstellen und könnte später auch wieder raus)
    3. tar cvf /tmp/provideradditive.tar ./provider_additive_enables_post_install.txt
    4. ln -s /var symlink_to_var
    5. tar --append -f /tmp/provideradditive.tar symlink_to_var
    6. rm symlink_to_var
    7. mkdir symlink_to_var
    8. cp /<pfad_zur_modifizierten>/post_install ./symlink_to_var/post_install
      1. original post_install
      2. notwendige Modifizierung
    9. chown 0:0 ./symlink_to_var/post_install
    10. chmod 755 ./symlink_to_var/post_install
    11. tar --append -f /tmp/provideradditive.tar symlink_to_var/post_install
    12. zlib-flate -compress < /tmp/provideradditive.tar > /tmp/provideradditive.zlib (EDIT: alternativ sollte das auch mit openssl zlib -e <input_file >output_file möglich sein)
    13. cp /tmp/provideradditive.zlib /tmp/tffs_dump/tffs_1/001d.bin
  4. env.txt, count.txt und nametable erstellen (anlaog zur Anleitung von fsec ohne Punkt 4 und 5, waren bei mir nicht notwendig, bzw. führten zu Fehlern)
    1. cd YourFritz/eva_tools
    2. Box im adam2 halten, entweder ./eva_discover oder ftp 192.168.178.1, adam2/adam2 einloggen und mit quit wieder raus, EDIT: oder ganz einfach nur echo quit | nc 192.168.178.1 21
    3. ./eva_get_environment env 192.168.178.1 > /tmp/env.txt
    4. ./eva_get_environment count 192.168.178.1 > /tmp/count.txt
    5. /tmp/nametable nach Punkt 6 erstellen (EDIT: es liegt nun auch eine passende nametable im YourFritz-Repo unter YourFritz/tffs/tffs_name_table)
  5. neues tffs erstellen und flashen
    1. cd YourFritz/tffs
    2. ./build_tffs_image /tmp/nametable /tmp/env.txt /tmp/count.txt /tmp/tffs_dump/tffs_1/*.bin > /tmp/mtd.img (das kann ein Weilchen dauern)
    3. cd ../eva_tools/
    4. Box im adam2 halten, entweder ./eva_discover oder ftp 192.168.178.1, adam2/adam2 einloggen und mit quit wieder raus, EDIT: oder ganz einfach nur echo quit | nc 192.168.178.1 21
    5. ./eva_store_tffs mtd3 /tmp/mtd.img
    6. ./eva_store_tffs mtd4 /tmp/mtd.img
  6. Box neu starten und dann via ftp oder Fritz!NAS die beiden scripte von @PeterPawn aus #967 (UNBEDING LESEN!) run_update und update_firmware aus YourFritz/autoupdate nach /var/media/ftp/
  7. neuste Firmware von avm herunterladen (nach Bedarf dropbear/mpd/etc mittels des ffritz-mods von fesc modifizieren) und als newfirmware.image via ftp oder Fritz!NAS nach /var/media/ftp
  8. Fritzbox via Webinterface neu starten, warten und freuen (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")
  9. EDIT: Danach bitte nicht vergessen die Datei newfirmware.image wieder zu löschen, sonst wird das Update beim nächsten reboot erneut ausgeführt und überschreibt evtl. das 2te System welches man u.U. noch behalten wollte. Übrigens: Wie man sehr einfach ein Backup der Systeme anfertigen hat @PeterPawn hier beschrieben.
  10. EDIT2: Mittlerweile wird bei/nach erfolgreichem Update die Datei newfirmware.image umbenannt (siehe #1144).


Ich hoffe ich hab nix vergessen...
Vielen Dank mal wieder an @PeterPawn und @fesc und all die vielen anderen die hier ihr Wissen teilen!

<<<<<<<<<<<<<<<<<Komplizierte Anleitung<<<<<<<<<<<<<<<<<
 
Zuletzt bearbeitet:
:cool: :eek::wow:

aber auch meinen ganz fetten dank an dich...
brauchbar, äusserst ...

aktualisiert aufgrund browserfehler
 
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.