Unitymedia Technicolor TC4400 FW Update Wie?

[robert_s]

die Vorgehensweise waere also ein Updateversuch ueber den internen tftp, ok?
Sprich:

<i>
</i>put FW_33-fixed_FW.img
put tc4400bootCustTFTP_33-fixed.cfg eroutercfg.bin

auf 172.31.255.40 ok?

Ja, wobei Du, wenn die Zeit knapp wird, weil der FW-Upload zu lange dauert, noch probieren könntest, mit atftp die Datei in größeren Blöcken zu senden (z.B. --option "blksize 1280").

 

[sparkie]

Jup, Checksummen stimmen

ok

Korrekt ist:
FW_33-fixed.img

ok danke, das haette ich jetzt glatt uebersehen

Passe ich dir an, wenn du magst. Oder hast du selber einen DOCSIS-File Editor?

koenntest du fuer die 2 Versuche mit internem '172.31.255.40' und externem '172.31.255.31' tftp mir die Files bitte generieren? Da ich sowas noch nicht gemacht habe moechte ich hier eine Fehler quelle moeglichst ausschliessen. Ich koennte dann gleich pruefen ob ich in Zukunft auf das gleiche Ergebnis komme :smile:

ansonsten muss in der *.cfg wohl nichts weiter angepasst werden

 

[sparkie]

mit atftp die Datei in größeren Blöcken zu senden (z.B. --option "blksize 1280").

ok alles klar. Der Upload scheint ja gefahrlos zu sein solange er das 'eroutercfg.bin' noch nicht hat? Dann sollten ja 'partial uploads' von 'FW_33-fixed.img' nichts ausmachen. Falls es hier zu Problemen kommen sollte.

 

[tobsen]

koenntest du fuer die 2 Versuche mit internem '172.31.255.40' und externem '172.31.255.31' tftp mir die Files bitte generieren?

Jop, ist erledigt. Liegen im gleichen Ordner.

<i>
</i>MD5 (tc4400bootInternTFTP_33-fixed.cfg) = d4121f60f1d30b4c4fad6395fac55e03
MD5 (tc4400bootExternTFTP_33-fixed.cfg) = e528cf64244f5725bbce9f4d05dee516

 

[sparkie]

super, checksummen stimmen

 

[Andreas1969]

Da bin ich jetzt aber mal gespannt :kafffee:

 

[sparkie]

also der Upload dauert mit normalem tftp definitiv zu lange als dass er in das 10s Fenster passen wuerde. Das partielle Upload-File wird im Zuge des naechsten Reboot geloescht oder ist zumindest nicht unter dem Original zu finden. Ich schau mal was sich mit atftp bzw. externem tftp machen laesst. Da muss man wenigstens nichts Uploaden :smile:

 

[tobsen]

also der Upload dauert mit normalem tftp definitiv zu lange als dass er in das 10s Fenster passen wuerde. Das partielle Upload-File wird im Zuge des naechsten Reboot geloescht oder ist zumindest nicht unter dem Original zu finden. Ich schau mal was sich mit atftp bzw. externem tftp machen laesst. Da muss man wenigstens nichts Uploaden :smile:

Fangen die beiden LEDs für DS und US beide gleichzeitig an zu blinken? Wenn nicht, dann wird erst gar kein Update getriggert.
Wenn ja, dann scheint das Modem auf jeden Fall den Config-File schonmal zu fressen.

 

[sparkie]

bis zum *.cfg kommt er noch gar nicht (ich teste noch mit dem internen tftp).

Die Frage ist, muss in meinem Fall das RF-Kabel eigentlich gezogen oder gesteckt sein. Ich ziehe es mal bis auf weiteres ab.

 

[Andreas1969]

Die Frage ist, muss in meinem Fall das RF-Kabel eigentlich gezogen oder gesteckt sein. Ich ziehe es mal bis auf weiteres ab.

Mach mal mit abgezogenem RF-Kabel einen WR (über 10s drücken), ich meine, da bleibt das Modem länger im Zugriffsmodus

 

[sparkie]

ich habe jetzt mal einen Versuch mit externem tftpd unternommen.

IP tftpd (mein testsystem): 172.31.255.31

dort das File 'FW_33-fixed.img' hinterlegt. Es laesst sich uebrigens mit einem Laptop per tftp von dort in nur 8s holen.

dann:
- Modem aus/einschalten
- sobald tftpd des Modems verfuegbar ist:

<i>
</i>put tc4400bootExternTFTP_33-fixed.cfg eroutercfg.bin

auf die 172.31.255.40 des Modems.

im *.cfg ist der 172.31.255.31 natuerlich entsprechend konfiguriert.

zu Beginn der 10s Phase blinken DS/US/Online im Gleichtakt. Das Blinken
geht weiter auch wenn die 10s schon vorbei sind. Nach vielleicht insgesamt 20s blinkt nur
noch die DS. Aber da ist das Modem dann ganz normal ueber 192.168.100.1 erreichbar.

Der Upload des 'tc4400bootExternTFTP_33-fixed.cfg' beeinflusst den obigen Ablauf nicht
im Geringsten. Wenn ich ihn nicht mache dann ist die Blinkfolge gleich.
Man sieht auch im Log des tftpd, dass vom Modem kein 'get' versucht wird.

 

[sparkie]

(über 10s drücken), ich meine, da bleibt das Modem länger im Zugriffsmodus

nein, bleibt es nicht.

ich mache morgen mit atftp weiter...

 

[Andreas1969]

Jetzt ist guter Rat teuer
Vielleicht hat Robert ja noch´ne Idee :kratz:

 

[tobsen]

Nach vielleicht insgesamt 20s blinkt nur
noch die DS. Aber da ist das Modem dann ganz normal ueber 192.168.100.1 erreichbar.

Dann bootet das Modem ganz normal. Sobald nur noch die DS LED blinkt, ist das Modem gebootet und versucht den DS zu syncen, da aber kein RF Kabel gesteckt ist, wird es diesen Status bis in den sankt nimmerleinstag beibehalten.
Wenn du keinen Get auf dem externen TFTP bekommst, dann scheint in dem erouter-file noch ein bisschen mehr stehen als die reine DOCSIS-Config oder gar etwas völlig anderes. :hammer:

ich mache morgen mit atftp weiter...

Das klingt gut!

 

[robert_s]

Vielleicht hat Robert ja noch´ne Idee :kratz:

Probieren kann man noch vieles... @sparkie schrieb ja auch mal, dass man die IP-Adresse des CM (*.45) kurzzeitig "sehen" kann. Auch nur 1s lang könnte reichen, um da per SNMP die Werte zu setzen, die das Update anstoßen, falls die eroutercfg.bin tatsächlich nicht vom CM gefressen werden sollte...

 

[sparkie]

so, mit atftp wird der Upload so schnell, ich kann sowohl 'eroutercfg.bin' als auch 'FW_33-fixed.img' sogar innerhalb 10s wieder zuruecklesen und mit dem Original vergleichen- alles ok soweit.

nur der Flash wird nicht getriggert, die US/DS/Online LED Blinkabfolge ist unveraendert (egal ob mit oder ohne Upload).

Muss man vielleicht den Reset gedrueckt halten und dann erst das Modem einschalten, um in den Upgrade Mode zu gelangen? Moeglichkeiten gibt es viele :smile:

das Vorgehen krankt an den Diagnosemoeglichkeiten. Die LEDs alleine sind etwas duerftig. Ich koennte mal an den seriellen Schnittstellen mitlesen. Irgendwo hat jemand mal was geschrieben, wie er dem Teil zumindest beim Boot ein paar Zeilen entlocken konnte...

 

[tobsen]

Muss man vielleicht den Reset gedrueckt halten und dann erst das Modem einschalten, um in den Upgrade Mode zu gelangen? Moeglichkeiten gibt es viele

Drücken des Reset und dann einschalten hat glaube ich keinen wirklichen Effekt. Also dieser typische 30-30-30 Reset hat auf das Modem keinerlei Einfluss, außer dass es bei >10 drücken einen factory reset macht.
Ich kann dir leider nur berichten, wie die Blinkfolge beim Update via CMTS aussieht..
- ganz normale Blinkfolge des Bottvorgangs
- Power LED dauerhaft an, DS blinkt alleine, Link-LED abhängig ob Gerät angeschlossen oder nicht
- Power LED dauerhaft an, DS nach erfolgreichem Sync dauerhaft an, US LED blinkt, Link-LED...
- Power LED dauerhaft an, DS dauerhaft an, US LED nach erfolgreichem sync dauerhaft an, Online-LED blinkt, Link-LED...
- Power LED kurz aus (<1 sec), DS und US LED blinken parallel, Online-LED dauerhaft an, Link-LED...
## Jetzt erfolgt das Update.
FW wird per TFTP unter der im config-file hinterlegten IP abgeholt und geprüft. Passt die FW und ist per SNMP alles sauber gesetzt, wird die FW installiert. Wenn die Installation abgeschlossen ist (egal ob erfolgreich oder mit einem Fehler) startet das Modem automatisch neu und die Blink-Prozedur geht von vorne los.
Wenn das Update nicht erfolgreich war, dann versucht es das Modem beim nächsten mal direkt nochmal, sobald es den DOCSIS-File bekommen hat. Im Event-Log kann man dann einen oder mehrere spartanische Fehler lesen.
War das Update vorher allerdings erfolgreich, macht das Modem gar nix mehr und alle LEDs bis auf die Link-LED sind dauerhaft an.

das Vorgehen krankt an den Diagnosemoeglichkeiten.

Ja das hab ich auch schon festgestellt. Also das Logging im Event-Log ist mehr als dürftig und warum die Error-Message auch noch am Ende abgeschnitten ist, entzieht sich meinem Verständnis. Aber das ist ja selbst mit aktuellster FW immer noch nicht behoben :wand:

Ich koennte mal an den seriellen Schnittstellen mitlesen. Irgendwo hat jemand mal was geschrieben, wie er dem Teil zumindest beim Boot ein paar Zeilen entlocken konnte...

Das wäre so noch die letzte Möglichkeit, die da auch sehen würde, um irgendwie noch an debugging Infos zukommen.
Ich glaub aber so richtig viele Infos standen in der einen Zeile jetzt nicht drin...

Ich tippe einfach mal, dass in der "eroutercfg" nicht das drinsteht, was das Modem an dieser Stelle erwartet. Hab allerdings auch mal überhaupt keine Ahnung, wie man an einen validen Inhalt oder gar eine Keyword Liste kommen kann.
Finde es aber schonmal cool, dass das Modem dann trotzdem weitermacht und normal bootet... Mein CMTS hatte sich ja erstmal Urlaub genommen, nachdem die DHCPD-Config einen Fehler hatte :wand:

 

[Flole]

Kann man vielleicht die eroutercfg auslesen während ein Update über das CMTS gemacht wird? Ansonsten gibt's noch Reverse engineering, da muss man aber wissen welche Software sich um die Datei kümmert, sonst sucht man da ja ewig. Also find | xargs strings| grep eroutercfg oder so in der Art , vielleicht kann man da ja was sehen. Ansonsten wäre telnet zugriff natürlich Gold wert, dann macht man eben den tftp wieder an und schaut dann das man alles da hin kriegt wo es hingehört....

 

[tobsen]

Kann man vielleicht die eroutercfg auslesen während ein Update über das CMTS gemacht wird?

Zu diesem Zeitpunkt ist das Modem bereits betriebsfertig provisioniert.
Wenn ich das richtig in Erinnerung habe, dann sind die kleinen Türchen bereits wieder zu.

Ansonsten gibt's noch Reverse engineering

Naja die eroutercfg ist halt ein Bin-File. Ohne da jetzt Details zu kennen, wird das ein großes Gerate, was den Inhalt angeht.

 

[Andreas1969]

Naja die eroutercfg ist halt ein Bin-File. Ohne da jetzt Details zu kennen, wird das ein großes Gerate, was den Inhalt angeht.

Das wird uns wohl nur TC verraten können.
Kennt vielleicht irgendjemand jemanden bei TC :kratz:
Sonst wird's schwierig mit dem Rätselraten

 

[sparkie]

Naja die eroutercfg ist halt ein Bin-File. Ohne da jetzt Details zu kennen, wird das ein großes Gerate, was den Inhalt angeht.

das verstehe ich nicht. Meint ihr ein File 'eroutercfg.bin' oder wirklich 'eroutercfg'? Das 'eroutercfg.bin' wurde doch von uns selbst generiert. Dann ist der Inhalt doch bekannt?

 

[Andreas1969]

Meint ihr ein File 'eroutercfg.bin'

Ja, das meinen wir.

Das 'eroutercfg.bin' wurde doch von uns selbst generiert. Dann ist der Inhalt doch bekannt?

Ja, richtig, den Inhalt haben wir ja selbst erzeugt, daher ist er natürlich bekannt.
Wird aber zum Download vom CMTS auf das Modem verwendet (per Docsis Config).

Beim 'eroutercfg.bin' handelt es sich aber um ein Configfile, welches das Modem erwartet, wenn man von der LAN Seite aus updaten will.
Und der Inhalt muss wahrscheinlich ein anderer sein, als per CMTS, da der Docsis Kram ja für das lokale Update nicht benötigt wird.

 

[tobsen]

Das 'eroutercfg.bin' wurde doch von uns selbst generiert.

Wie Andreas schon gesagt hatte, haben wir einen DOCSIS-File generiert. Dazu gibt es entsprechende Editoren und auch eine öffentliche Referenz.
Mittels des Editors wird dann aus dem Text-File ein Bin-File erzeugt. Dieses Bin-File wird dann auf einen TFTP geladen. Entweder auf den internen vom CMTS oder auf einen externen.
Wenn sich das Modem beim CMTS meldet, wird mittels DHCP die IP des TFTP mit übermittelt. Danach holt sich das Modem vom TFTP das bin-File und parst es.
In dem bin-File, dass ich dir geschickt habe, sind dann alle Parameter für ein Update gesetzt und das Modem holt sich dann vom im bin-file (DOCSIS-File) gesetzten TFTP das Image und installiert es.

Die "eroutercfg.bin" ist aber eine völlig andere Datei. Es war lediglich ein Versuch, ob der Inhalt dem DOCSIS-File entspricht und ob sich dadurch ein Update über den LAN-Port triggern lässt.
Wie es aber scheint, ist der Inhalt ein anderer und das Modem verwirft nun die Infos aus dem File und bootet normal.

 

[sparkie]

Und der Inhalt muss wahrscheinlich ein anderer sein, als per CMTS,

vermutlich das. Oder es fehlt ein wichtiger Schritt. Denn der gesamte Upload wird scheinbar ignoriert. Und nach dem naechsten Reboot sind die betreffenden Files auch nicht mehr da. Dabei funktioniert der Upload selbst mittlerweile wunderbar (mit atftp).

@sparkie schrieb ja auch mal, dass man die IP-Adresse des CM (*.45) kurzzeitig "sehen" kann. Auch nur 1s lang könnte reichen, um da per SNMP die Werte zu setzen, die das Update anstoßen, falls die eroutercfg.bin tatsächlich nicht vom CM gefressen werden sollte...

abgesehen davon, dass es etwas schwierig wird exakt die 2 Sekunden, die einem etwa zur Verfuegung stehen zu finden und zu nutzen, waere die Frage welche Werte denn genau gesetzt werden sollen.

 

[sparkie]

Die "eroutercfg.bin" ist aber eine völlig andere Datei. Es war lediglich ein Versuch, ob der Inhalt dem DOCSIS-File entspricht

ok, das ist der Knackpunkt, danke.