Unitymedia Technicolor TC4400 FW Update Wie?

[Andreas1969]

Vielleicht ist es ja einfacher als man denkt und man muss einfach nur die FW als unsignierte Variante (also ohne die eroutercfg.bin) per TFTP auf's Modem schieben :kratz:

 

[sparkie]

und mit welchem speziellen Namen? Ich habe irgendwie den Eindruck als wenn es dem Teil voellig egal waere was man drauf schiebt. Es nuetzt nicht, schadet aber auch nicht

ich verstehe nicht warum sich TC so ziert eine FW-Upgrade-Beschreibung rauszuruecken. Die Geheimniskraemerei hat ihnen ja sowieso nichts genuetzt. Aber ohne CMTS waere es halt etwas komfortabler.

 

[Andreas1969]

und mit welchem speziellen Namen? I

Keine Ahnung :traurig:
Vielleicht hat Robert ne Idee

 

[tobsen]

ich verstehe nicht warum sich TC so ziert eine FW-Upgrade-Beschreibung rauszuruecken.

Naja sie haben halt von Anfang an ganz klar gesagt "RF Only" und nachdem der DOCSIS File sauber erstellt war, ist es auch über ein CMTS echt kein grosses Hexenwerk ein solches Update zu fahren. :winken:

 

[Andreas1969]

Die Geheimniskraemerei hat ihnen ja sowieso nichts genuetzt.

Doch schon, denn nicht jeder kauft sich zum Modem gleich noch'n CMTS dazu :winken:
Somit ist Otto normalo nicht in der Lage, das Update durchzuführen. :traurig:
Also Mission zu 99% erfolgreich. :super:

TC könnte ja das Modem gleich als Bundle mit einem CMTS anbieten, das steigert den Umsatz

 

[robert_s]

@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.

Das ist leicht beantwortet, denn das kann man ja im "dload" Script nachlesen:

<i>
</i>	snmpset -v2c -cprivate 172.31.255.45 1.3.6.1.4.1.4413.2.99.1.1.2.4.2.2.2.2.0 a $tftphost	echo "snmpset -v2c -cprivate 172.31.255.45 1.3.6.1.4.1.4413.2.99.1.1.2.4.2.2.2.2.0 a $tftphost"	snmpset -v2c -cprivate 172.31.255.45 1.3.6.1.4.1.4413.2.99.1.1.2.4.2.2.2.3.0 s $tftppath	echo "snmpset -v2c -cprivate 172.31.255.45 1.3.6.1.4.1.4413.2.99.1.1.2.4.2.2.2.3.0 s $tftppath"	snmpset -v2c -cprivate 172.31.255.45 1.3.6.1.4.1.4413.2.99.1.1.2.4.2.2.2.6.0 i 1	echo "snmpset -v2c -cprivate 172.31.255.45 1.3.6.1.4.1.4413.2.99.1.1.2.4.2.2.2.6.0 i 1"	echo "Finished."	echo ""	exit 0

Denkbar wäre allerdings, dass der CM-Code diese tftp-Zugriffe stets über sein Modem-Interface durchführt, und die entsprechend gar nicht vom internen tftp-Server oder von einem LAN tftp-Server geladen werden können...

Denn das dload-Script sieht auch noch eine Variante "Install monolith image via Ethernet" vor, und da wird nichts über das CM gemacht, sondern das Script lädt selbst das Firmware-Image vom tftp-Server und flasht es dann mit dem Befehl "/bin/rprogramstore -f /tmp/rootfs.img" - nur sehe ich derzeit keine Möglichkeit, wie man diesen Befehl (oder einfacher: das "dload" Script) von außen aufrufen könnte. Wobei man nicht ausschließen kann, dass es vielleicht ein kleines Hintertürchen gibt und irgendwo in den privaten SNMP-MIBs des RG ein Schätzchen schlummert, den man auf einen beliebigen Befehl zur Ausführung setzen könnte...

 

[sparkie]

Das ist leicht beantwortet, denn das kann man ja im "dload" Script nachlesen:

danke schon mal. Ich werde heute schauen ob sich da noch was machen laesst...

unter $tftphost will er die IP des Servers und in $tftppath einfach den Filenamen des *img File?

 

[sparkie]

soweit habe ich den aktuellen Kenntnisstand mal in einem Script umgesetzt.

Im Vergleich zur ersten Version kann man nun in Funktion 'wait_for' die response time fuer die echo requests als Argument mitgeben. Zudem reagiert der 'wait_for' sobald ueberhaupt eine Antwort von betreffender IP zurueckkommt sehr schnell, da das Intervall zwischen den echo requests sehr klein ist (10ms).

<i>
</i>#!/bin/sh MYIP=172.31.255.31
#MYIP=172.31.255.20
#MYIP=172.31.255.40
#MYIP=172.31.255.45
#MYIP=192.168.100.22 IP=172.31.255.20 # http, snmp IP=172.31.255.40 # http, snmp, tftp address RG
# IP=172.31.255.45 # ??? internal tftp client/ snmp server?
# IP=172.31.255.70 # http, snmp
# IP=172.31.255.31 # my
# IP=192.168.100.1 # my
# IP=$MYIP
# IP=localhost
wait_for()
{
awk 'BEGIN { EXIT_TRIGGER = ("'$2'" ? "'$2'" : 0) + 0 CMD = "ping -DOl1 -i0.01 '$1'"
print "wait for: " "'$1'"
print "exit trigger: " EXIT_TRIGGER while (CMD | getline line > 0) { if (match(line, "^\\[")) { split(line, a, "\\[|\\]") if (!match(line, "Unreachable|no answer yet for")) print strftime("%T", a[2]) ":" a[3] a[4] a[5] if (match(line, "bytes from.*time=([^ ]+) ms$", a)) { if (a[1] < EXIT_TRIGGER) { print a[1] " < " EXIT_TRIGGER " triggers wait loop exit" exit } } } }
}'
}
echo "interfaces: $MYIP --> $IP"
ifconfig eth0 $MYIP netmask 255.255.255.0 up
#ip ad add 172.31.255.20 dev eth0 label eth0:0
# ==========================================
wait_for 172.31.255.40 2000
atftp --option "blksize 2048" $IP << !
status
put FW_33-fixed.img_ FW_33-fixed.img
put tc4400bootInternTFTP_33-fixed.cfg_ eroutercfg.bin
!
# ==========================================
SNMP_IP=172.31.255.45
wait_for $SNMP_IP 5000
snmpset -v2c -cprivate $SNMP_IP 1.3.6.1.4.1.4413.2.99.1.1.2.4.2.2.2.2.0 a 172.31.255.40
snmpset -v2c -cprivate $SNMP_IP 1.3.6.1.4.1.4413.2.99.1.1.2.4.2.2.2.3.0 s FW_33-fixed.img
snmpset -v2c -cprivate $SNMP_IP 1.3.6.1.4.1.4413.2.99.1.1.2.4.2.2.2.6.0 i 1

liefert:

<i>
</i>5858 root@fire-a[/root] > scan_tc4400
interfaces: 172.31.255.31 --> 172.31.255.40
wait for: 172.31.255.40
exit trigger: 2000
16:49:18: 64 bytes from 172.31.255.40: icmp_seq=68 ttl=64 time=991 ms
991 < 2000 triggers wait loop exit
Option blksize = 2048
tftp> status
Connected: 172.31.255.40 port 69
Mode: octet
Verbose: off
Trace: off
Options tsize: disabled blksize: enabled timeout: disabled multicast: disabled
mtftp variables client-port: 76 mcast-ip: 0.0.0.0 listen-delay: 2 timeout-delay: 2
Last command: put tc4400bootInternTFTP_33-fixed.cfg_ eroutercfg.bin
tftp> put FW_33-fixed.img_ FW_33-fixed.img
tftp> put tc4400bootInternTFTP_33-fixed.cfg_ eroutercfg.bin
tftp>
wait for: 172.31.255.45
exit trigger: 5000
16:49:31: 64 bytes from 172.31.255.45: icmp_seq=54 ttl=64 time=817 ms
817 < 5000 triggers wait loop exit
Timeout: No Response from 172.31.255.45
Timeout: No Response from 172.31.255.45
Timeout: No Response from 172.31.255.45

bis zum Aufruf 'snmpset' klappt alles wunderbar. Dann allerdings sieht es so aus, als wenn sich hinter 172.31.255.45 gar kein snmp Service befinden wuerde. Zudem ist die IP 172.31.255.45 nur so extrem kurz online, da ist nicht mal ein Portscan moeglich. Zumindest nicht aus einem shell Script heraus.

Witzigerweise befinden sich hinter '172.31.255.20', '172.31.255.40' und '172.31.255.70' snmp Services die komfortable 10s lang online sind. Wenn ich spasseshalber dann Variable 'SNMP_IP' auf eine dieser 3 IPs setze dann sagt er, dass das entsprechende Objekt nicht schreibbar sei:

<i>
</i>5859 root@fire-a[/root] > scan_tc4400
interfaces: 172.31.255.31 --> 172.31.255.40
wait for: 172.31.255.40
exit trigger: 2000
17:06:49: 64 bytes from 172.31.255.40: icmp_seq=551 ttl=64 time=992 ms
992 < 2000 triggers wait loop exit
Option blksize = 2048
tftp> status
Connected: 172.31.255.40 port 69
Mode: octet
Verbose: off
Trace: off
Options tsize: disabled blksize: enabled timeout: disabled multicast: disabled
mtftp variables client-port: 76 mcast-ip: 0.0.0.0 listen-delay: 2 timeout-delay: 2
Last command: put tc4400bootInternTFTP_33-fixed.cfg_ eroutercfg.bin
tftp> put FW_33-fixed.img_ FW_33-fixed.img
tftp> put tc4400bootInternTFTP_33-fixed.cfg_ eroutercfg.bin
tftp>
wait for: 172.31.255.40
exit trigger: 5000
17:06:52: 64 bytes from 172.31.255.40: icmp_seq=1 ttl=64 time=0.250 ms
0.250 < 5000 triggers wait loop exit
Error in packet.
Reason: notWritable (That object does not support modification)
Failed object: iso.3.6.1.4.1.4413.2.99.1.1.2.4.2.2.2.2.0
Error in packet.
Reason: notWritable (That object does not support modification)
Failed object: iso.3.6.1.4.1.4413.2.99.1.1.2.4.2.2.2.3.0
Error in packet.
Reason: notWritable (That object does not support modification)
Failed object: iso.3.6.1.4.1.4413.2.99.1.1.2.4.2.2.2.6.0

Verbesserungsvorschlaege willkommen :smile:

 

[robert_s]

Verbesserungsvorschlaege willkommen :smile:

Wenn ich das richtig sehe, hast Du für Deinen PC immer die IP-Adresse 172.31.255.31 verwendet? Das könnte schon mal ein Fehler sein, denn z.B. die snmpd.conf für den RG beschränkt den SNMP-Zugriff auf die IP-Adresse des CM, 172.31.255.45. Du müsstest also diese Adresse für Deinen PC verwenden, wenn Du mit dem SNMP-Server des RG, 172.31.255.40, etwas anfangen möchtest.

Entsprechend würde ich vermuten, dass Du, um SNMP-Befehle an das CM abzusetzen, die IP-Adresse des RG, 172.31.255.40, für Deinen PC verwenden musst. Dann kannst Du den tftp-Server des RG nicht mehr verwenden, aber Du kannst den ja dann auch "extern" anbieten.

Was die knappe Zeit angeht, hilft es vielleicht, den Ping-Test zu überspringen und den ersten SNMP-Befehl in einer Schleife abzusetzen zu versuchen, bis das mal klappt, und dann die anderen SNMP-Befehle hinterherzuschicken...?

 

[Flole]

Hat eigentlich mal jemand getestet was der USB Anschluss kann? Den muss man ja auch nicht löten sondern kann den mit der Hand in Position drücken und so gedrückt halten während jemand anders den PC bedient.

 

[y0r]

Hat eigentlich mal jemand getestet was der USB Anschluss kann? Den muss man ja auch nicht löten sondern kann den mit der Hand in Position drücken und so gedrückt halten während jemand anders den PC bedient.

Bisher wohl nicht. @0rko hatte auch einige interessante Ansätze geliefert. Er hatte es wohl sogar geschafft auf die Linux CLI zuzugreifen!?

 

[Meich]

Push

Es sind wieder 2,5 Jahre seit dem letzten Post vergangen. Als aktuelle Version wird die .44 kommuniziert. Ist es auch die letzte/aktuellste?

Habe mir ein TC4400 besorgt und werde es die Tage eine Inbetriebnahme durchführen. Es ist die ältere .42 drauf.

Wechsle von einer privat angeschafften FB6690 im Bridgemode, diese hat aber für mein Vorhaben einige Limits. Hat mir genug graue Haare beschert

 

[Tom_123]

Als aktuelle Version wird die .44 kommuniziert. Ist es auch die letzte/aktuellste

Ja, ist die aktuellste verfügbare Version. Meiner Ansicht nach, kommt da auch keine Neue mehr.

 

[MartinP_Do]

Wechsle von einer privat angeschafften FB6690 im Bridgemode, diese hat aber für mein Vorhaben einige Limits. Hat mir genug graue Haare beschert

Etwas off-topic: Hier gibt es doch einen Thread, dass der Bridgemode nur in Leih-Boxen funktioniert, da die kundeneigenen Boxen nur mit MAX_CPE=1 provisioniert würden - hat sich da etwas geändert?

https://www.kabeluser.de/threads/37511/page-6#post-425206
Nachtrag - den Wert findet man in der Textdatei "Supportdaten", wenn man die von der Fritzbox generieren lässt ...

Sync Time: 368972 s
Last locked frequency: 498 MHz
MDF support: Promiscuous
Max CPE: 3
Tx channel config: YES

 

[Meich]

Etwas off-topic: Hier gibt es doch einen Thread, dass der Bridgemode nur in Leih-Boxen funktioniert, da die kundeneigenen Boxen nur mit MAX_CPE=1 provisioniert würden - hat sich da etwas geändert?

Hallo Martin,

der Bridgemode (per LAN Port 2) hat wunderbar an meiner privaten 6690 funktioniert.

OPN sense hat die übliche Public IPv4/IPv6 bezogen, sogar hat das WLAN mit nem zweiten paar IPs funktioniert (hatte also einmal die gesicherte ENV der OPNsense, sowie die 0815 Konsumer ENV der Fritzbox zeitgleich aktiv.

Die FB hatte aber Probleme beim Abschalten des WiFis und bei Umschaltung des Clienten daseins über Port 1.

Die 6690 ist auch ein kleiner Hitzkopf gewesen, Sie war im Schrank liegend eingebaut, aber von einem 40er Noctua gekühlt worden

Ich bin kein geborener Netzwerk-Admin und muss/te mich in die Netzwerk-Thematik reinfuchsen - war mir die FB der Störfaktor. Imho lag das Problem an meinem Heimnetzwerk letztendlich immer an der 6690.

Werde diese nach dem Update des TC4400 in den Urlaub schicken und mein Netzwerk daheim umstellen.

Vllt hatte ich ja unrecht und meine Probleme waren letztendlich nur meine Unwissenheit

 

[shm0]

Push

Es sind wieder 2,5 Jahre seit dem letzten Post vergangen. Als aktuelle Version wird die .44 kommuniziert. Ist es auch die letzte/aktuellste?

Habe mir ein TC4400 besorgt und werde es die Tage eine Inbetriebnahme durchführen. Es ist die ältere .42 drauf.

Wechsle von einer privat angeschafften FB6690 im Bridgemode, diese hat aber für mein Vorhaben einige Limits. Hat mir genug graue Haare beschert

https://www.reddit.com/r/Calgary/comments/te0mk3
Da wird 70.12.45 und 70.13.41 erwähnt.
70.12.45 scheint broken zu sein.
Der Post is 2 Jahre alt...

Auch interessant wie man bei dem Lightspeed ISP nur ein reines Modem mieten oder direkt kaufen kann.
Wahnsinn...

 

[MartinP_Do]

Bei Werner scheint immer noch die 70.12.44 bei den Updates genutzt zu werden, wenn man den Webseiten-Infos glaubt ..

https://shop.wernerelectronic.de/tc4400-eu-kabel-modem-docsis-3-1-2478.html

 

[shm0]

Vielleicht gibt es die 70.13.* Firmware (noch) nicht für den EU Markt?
Kann auch sein dass sich die Versionsnummern für den EU Markt unterscheiden... glaub ich aber eher weniger.
Oder Werner wartet erst noch bis er genug *.44 Firmware Updates verkauft hat...

 

[Meich]

Vielleicht gibt es die 70.13.* Firmware (noch) nicht für den EU Markt?
Kann auch sein dass sich die Versionsnummern für den EU Markt unterscheiden... glaub ich aber eher weniger.
Oder Werner wartet erst noch bis er genug *.44 Firmware Updates verkauft hat...

Das wäre echt kein schönes Geschäftsgebaren, denke aber er kommt einfach schlichtweg nicht direkt/regelmäßig an neue Updates.

In der automotiven Szene eines dt. Herstellers ist es zb so: Ein jeder der an ein Update kommt (egal auf welchem Wege, legal, semilegal,...) und es für andere Fahrzeugbesitzer aufspielt, ist stets bemüht das aktuellste für das jeweilige Stg. aufzuspielen bzw jenes Update, was Probleme/Bugs und andere ungewünschte Abweichungen behebt. Bringt letztendlich mehr Zufriedenheit und €€€.

Canada hat wenn man Google fragt, viel mehr Entwicklung beim TC4400-AM. Sogar kam dieses Jahr noch ein Update für deren Markt raus.... WOW