Unitymedia Technicolor TC4400 FW Update Wie?

[sch4kal]

Update über USB ist wohl doch nicht möglich. Nur über das RF-Interface :traurig:

 

[Andreas1969]

Update über USB ist wohl doch nicht möglich.

Ha'ste's probiert :kratz:

 

[Wechseler]

Update über USB ist wohl doch nicht möglich. Nur über das RF-Interface :traurig:

Isch abe gar keine USB. :kratz:

 

[Andreas1969]

Isch abe gar keine USB.

Dosch, musch´te nur einlöten :winken:

 

[Wechseler]

Dosch, musch´te nur einlöten :winken:

Naja, wenn's weiter nichts ist... :glück:

 

[sch4kal]

Herr Werner hatte bei Technicolor angefragt.

 

[Andreas1969]

Herr Werner hatte bei Technicolor angefragt.

Und, was kam dabei heraus :kratz:

 

[Grinder]

Update über USB ist wohl doch nicht möglich. Nur über das RF-Interface :traurig:

Vermutlich das, Andreas.

 

[robert_s]

Merkwürdiger Threadverlauf... an mehreren Stellen scheinen Leute endlich etwas zu erreichen, und dann kommt überhaupt nichts mehr von ihnen. Wurden hier Beiträge gelöscht, oder hat TC denjenigen das Update-Tool herausgerückt, wenn sie dafür nicht weiter posten...?!?

z.B. auf Seite 17 war doch jemand so weit, dass das TC4400 eine Datei von seinem TFTP-Server anforderte. Aber wo man erwartet hätte, dass er die angeforderte Datei bereitzustellen versucht kam - gar nichts mehr.

Habt ihr alle plötzlich die Lust verloren, oder eure "20er" TC4400 längst selbst aktualisiert, dürft darüber aber nicht reden?

 

[Samsungstory]

Wir sind jetzt bei der Methode CMTS geblieben, was demnächst auch umgesetzt wird.

Ahh da hat jemand den Weg vom KDG Forum hier her gefunden :winken:

 

[rv112]

Es geht nur via CMTS.

 

[sparkie]

Habt ihr alle plötzlich die Lust verloren,

ganz sicher nicht. Wir geben nicht auf bevor alle TC4400 an allen Anschluessen laufen :smile: Trotz der vielen Huerden, die uns von den Providern in den Weg gelegt werden.

Ist ja schon toll was alleine bis jetzt alles erreicht wurde.

 

[tobsen]

Merkwürdiger Threadverlauf... [...]
Habt ihr alle plötzlich die Lust verloren, oder eure "20er" TC4400 längst selbst aktualisiert, dürft darüber aber nicht reden?

Also von Lust verloren haben kann hier nicht die Rede sein. :super:
Wir haben nur eingesehen, dass die Methode mit der Brechstange nicht wirklich zum Erfolg führt. In der Zwischenzeit, wo hier nix los war, wurde ein CMTS besorgt worüber wir nun Updates/Tests/etc machen können. Also unser eigenes kleines gekapseltes KNB-Labor einrichten können.

Wenn du also ein TC hast, wo eine neue Firmware drauf soll, dann gedulde dich noch ein paar Tage und dann gehts los! :hammer:

 

[Avatar]

Merkwürdiger Threadverlauf... [...]
Habt ihr alle plötzlich die Lust verloren, oder eure "20er" TC4400 längst selbst aktualisiert, dürft darüber aber nicht reden?

Also von Lust verloren haben kann hier nicht die Rede sein. :super:
Wir haben nur eingesehen, dass die Methode mit der Brechstange nicht wirklich zum Erfolg führt. In der Zwischenzeit, wo hier nix los war, wurde ein CMTS besorgt worüber wir nun Updates/Tests/etc machen können. Also unser eigenes kleines gekapseltes KNB-Labor einrichten können.

Wenn du also ein TC hast, wo eine neue Firmware drauf soll, dann gedulde dich noch ein paar Tage und dann gehts los! :hammer:

Wie wird das dann laufen? Modem wird dir(?) per Post zugeschickt, Du(?) machst das Update und es kommt per Post zurück?

 

[der-tim]

z.B. auf Seite 17 war doch jemand so weit, dass das TC4400 eine Datei von seinem TFTP-Server anforderte. Aber wo man erwartet hätte, dass er die angeforderte Datei bereitzustellen versucht kam - gar nichts mehr.

Habt ihr alle plötzlich die Lust verloren, oder eure "20er" TC4400 längst selbst aktualisiert, dürft darüber aber nicht reden?

Ich hab hier gleich einen Alu Hut für dich fertig, abholbereit in Düsseldorf....

Falls du den Eintrag von dem jemand auf Seite 17 noch mal liest, dann würdest du vielleicht feststellen, dass das TC vom Server eine andere Datei als bereitgelegt abfragt (die aber niemand hier hat). :zerstör:

 

[robert_s]

Falls du den Eintrag von dem jemand auf Seite 17 noch mal liest, dann würdest du vielleicht feststellen, dass das TC vom Server eine andere Datei als bereitgelegt abfragt (die aber niemand hier hat). :zerstör:

Also soweit ich das gelesen habe, wollte das Modem eine Datei namens "version.txt" laden - was liegt also näher, als sich eine Textdatei mit dem Inhalt "SR70.12.30a" zu erstellen und die vom Modem laden zu lassen? Ich würde erwarten, dass als nächstes dann die Firmware-Datei mit dieser Version vom Server angefordert wird, weil das Modem festgestellt hat, dass das eine andere als die derzeit installierte ist.

Davon, dass das probiert wurde, habe ich nichts gelesen. Warum nicht?

 

[der-tim]

Also, falls du wild Daten erstellen willst, dann mach das bitte, oder sende mir doch dein TC4400 zu Testzwecken zu. Da ich Student bin hab ich leider nicht das Spielgeld übrig :winken:

 

[robert_s]

Also, falls du wild Daten erstellen willst, dann mach das bitte, oder sende mir doch dein TC4400 zu Testzwecken zu. Da ich Student bin hab ich leider nicht das Spielgeld übrig

Das ergibt für mich noch weniger Sinn: Seitenlang wird hier die Firmware zerlegt, mit dem Modem herumprobiert, Leute öffnen das Gerät - und dann haben plötzlich alle Schiss, dass sie ihr Gerät mit einer Textdatei beschädigen könnten...?

Ich habe übrigens kein TC4400 und halte mehr von vollintegrierten Geräten. Aber als Technik-Freak (und Firmware-Entwickler) finde ich das Thema sehr interessant, und dass man in das TC4400 nicht lokal eine Firmware reinkriegen kann, davon bin ich noch nicht überzeugt. Da sind doch noch zu offensichtliche Möglichkeiten, denen nicht nachgegangen wurde.

 

[rv112]

Das Modem lädt eine Firmware nur üfer das RF Interface, sonst gar nicht. Daher keine Chance.

 

[lupus]

Keine Chance ist zu weit gegriffen. Ich sehe das an sich wie robert_s. Jedes Gerät hat Lücken. Es müssen halt nur die "richtigen" Leute ran. Die werden sich aber eher nicht mit einem recht unbekannten Modem beschäftigen^^ Aber egal, es gibt nun eine Lösung die auch hoffentlich funktioniert, wenn auch nicht so bequem wie ein eigenes Update der Firmware.

 

[robert_s]

Das Modem lädt eine Firmware nur üfer das RF Interface, sonst gar nicht. Daher keine Chance.

Um so weit zu kommen, muss das Modem praktisch komplett funktionstüchtig sein. Was, wenn sich doch mal ein Bug in die Firmware einschleicht, oder ein Fehler in der Fertigung gemacht wird und z.B. eine neue HW-Revision nicht mit der richtigen Firmware bespielt wird? Die Stückkosten werden kaum so gering sein, dass man dann locker mal eine Charge wegwerfen kann - aber vielleicht auch nicht hoch genug, um dann noch mal den Flash-Chip aus- und wieder einzulöten.

Das Risiko, Geräte mit fehlerhaften FIrmwares bzw. Firmware-Updates unwiderbringlich zu "bricken", ist Entwicklern üblicherweise zu groß, dass man da nicht irgendeine Möglichkeit zum Recovery vorsieht, die möglichst wenig funktionierende Firmware voraussetzt (z.B. nur den Bootloader). Wenn die Entwickler bei TC so mutig sind, das nicht zu tun, Hut ab! - aber ich bezweifle das.

 

[robert_s]

Das Modem fragt als 172.31.255.45 also die Datei version.txt vom tftp Server, findet er nicht weil ich die nicht habe, und hängt dann etwas weiter im Loop.

Würdest Du Dich trauen, in diesem Zustand mal zu probieren, ob Du mit tftp GET eine Datei namens "hardware_id.txt" vom Modem holen kannst...?

 

[sparkie]

ich habe gestern genau an dieser Stelle mal etwas experimentiert. Man sieht an den ARP requests des Modems will offenbar eine 172.31.255.40 und eine 172.31.255.20. Deswegen habe ich dann ueber einen Switch diese IPs drangehaengt (2 Raspberries). Im tcpdump erkennt man dann anschliessend, dass das Modem anscheinend hinter 172.31.255.40 einen tftpd und hinter 172.31.255.20 einen snmpd erwartet. Diese habe ich auf den entsprechenden RPIs installiert. Und siehe da das Modem holt sich vom tftpd die oben genannte Datei version.txt. WIe vorgeschlagen habe ich da einfach mal SR70.12.31a eingetragen. Das Modem hat bei mir aktuell SR70.12.30a. Das war's dann. Das Modem zieht sich die version.txt rein aber sonst passiert nix Auffaelliges mehr.

Das was mich am meisten wundert ist: das Modem holt sich die version.txt ueberhaupt nur dann wenn von der 172.31.255.40 staendig ein ping auf das Modem (172.31.255.45) laeuft. Und das Zeitfenster innerhalb dem die echo requests beantwortet werden (und die version.txt gesucht wird) ist sehr kurz (vielleicht 2 Sekunden). Danach faehrt das Modem normal hoch.

ohne genauere Hinweise wie das alles zum SPielen kommen soll, macht es glaube ich, wenig SInn... Man muesste bei TC jemanden kennen

Aber sinnvolle Test-Vorschlaege werden natuerlich gerne entgegengenommen :smile:

die Angaben oben natuerlich ohne Gewaehr. Vielleicht habe ich noch was falsch gesehen. Es war schon spaet. Vorher hatte ich das Modem mal geoeffnet und das Gehaeuse anschliessend so praepariert, dass es sich in Zukunft leicht oeffnen laesst. Falls man doch mal was an den Seriellen oder USBs anloeten muesste :smile: . Aber ohne *etwas* konkretere Hinweise was zu tun ist habe ich das mal auf Eis gelegt...

 

[robert_s]

ohne genauere Hinweise wie das alles zum SPielen kommen soll, macht es glaube ich, wenig SInn... Man muesste bei TC jemanden kennen

Oder die Datei bin/erouterctld mal durch den Disassembler schicken, denn die scheint das zu machen. Und da finde ich eben auch einen Befehl, um einen tftpd zu starten, der auch das Hochladen(!) von Dateien erlaubt:

udpsvd -c 2 -E %s 69 /sbin/tftpd -c /var/tftpboot &

Direkt dahinter steht als nächster String übrigens "172.31.255.40"...

 

[sparkie]

nach Einschalten des Modems ist "172.31.255.40" tatsaechlich fuer ein paar Sekunden ansprechbar. Ein Portscan auf TCP/UDP liefert das

<i>
</i>19043 root@whyalla[/root] > nmap --system-dns -Pn -p1-300 --max-retries 1 -sU 172.31.255.40
Starting Nmap 7.40 ( https://nmap.org ) at 2018-05-26 21:25 CEST
Warning: 172.31.255.40 giving up on port because retransmission cap hit (1).
Nmap scan report for 172.31.255.40
Host is up (0.0060s latency).
Not shown: 288 open|filtered ports
PORT STATE SERVICE
13/udp closed daytime
63/udp closed via-ftp
69/udp open tftp
119/udp closed nntp
125/udp closed locus-map
161/udp open snmp
193/udp closed srmp
215/udp closed softpc
241/udp closed unknown
257/udp closed set
280/udp closed http-mgmt
281/udp closed personal-link
Nmap done: 1 IP address (1 host up) scanned in 5.19 seconds
19053 root@whyalla[/root] > nmap --system-dns -Pn 172.31.255.40
Starting Nmap 7.40 ( https://nmap.org ) at 2018-05-26 21:35 CEST
Nmap scan report for 172.31.255.40
Host is up (0.048s latency).
Not shown: 997 closed ports
PORT STATE SERVICE
80/tcp open http
443/tcp open https
8080/tcp filtered http-proxy
Nmap done: 1 IP address (1 host up) scanned in 2.80 seconds

ein tftpd laeuft jedenfalls :smile: