Unitymedia Technicolor TC4400 FW Update Wie?

[robert_s]

So, ich habe jetzt auch die Stelle gefunden, wo die Dateien vom (internen) tftp-Server geladen werden. Also wer noch weiter "forschen" mag, bitte:

1. Mal probieren, ob man vom Modem tftp-Server neben "version.txt" vielleicht auch "cmversion.txt", "newreq.ca" und "newreq.key" laden kann.
2. Alle ladbaren Dateien auf einen EXTERNEN tftp-Server legen, dazu noch die "eroutercfg.bin" sowie die Firmware-Datei
3. Das Modem wieder mit dem "Ping-Trick" auf den EXTERNEN tftp-Server "umbiegen", und protokollieren, was von diesem angefordert wird.

 

[sparkie]

waere es speziell zum Debugging nicht doch besser alles von einem externen tftp zu laden?
Dann kann man den Traffic wenigstens komplett mitschneiden.
Zudem fuehrt der "Ping-Trick" unweigerlich immer wieder zu Verbindungs-Abbruechen, welche die Diagnose noch zusaetzlich erschweren. Und das Modem verhaelt sich wegen den auftretenden Fehlern vielleicht untypisch.

 

[robert_s]

hinter den 3 IPs verbergen sich folgende TCP/UDP Services:

Mal zusammengefasst und ergänzt:

172.31.255.20: (http, https, snmp) - HUB
172.31.255.40: (http, https, snmp, tftp) - RG
172.31.255.45: CM
172.31.255.70: (http, https, snmp) - STB

 

[robert_s]

waere es speziell zum Debugging nicht doch besser alles von einem externen tftp zu laden?
Dann kann man den Traffic wenigstens komplett mitschneiden.
Zudem fuehrt der "Ping-Trick" unweigerlich immer wieder zu Verbindungs-Abbruechen, welche die Diagnose noch zusaetzlich erschweren. Und das Modem verhaelt sich wegen den auftretenden Fehlern vielleicht untypisch.

Meinst Du mit "externen tftp" einen mit einer anderen IP-Addresse als 172.231.255.40? Ich denke nicht, dass wir uns das ohne weiteres aussuchen können, denn die Adresse ist ja irgendwo im Kabelmodem konfiguriert wenn nicht hardcodiert.

Übrigens hat man auch nur mit der Kabelmodem-IP 172.231.255.45 Zugriff auf den SNMP-Server des Routerteils:

<i>
</i># CM use 172.31.255.45 to get/set RG SNMP
rocommunity public 172.31.255.45/255.255.255.255
rwcommunity private 172.31.255.45/255.255.255.255

Hast Du eigentlich mal nmap auf die 172.231.255.45 losgelassen? Dazu musst Du Deinem PC natürlich eine andere IP-Adresse geben, sonst scannst Du Dich selbst Vielleicht die 172.231.255.40 versuchen, falls da auch nur bestimmte IP-Adressen zugelassen werden...

 

[sparkie]

Hast Du eigentlich mal nmap auf die 172.231.255.45 losgelassen? Dazu musst Du Deinem PC natürlich eine andere IP-Adresse geben, sonst scannst Du Dich selbst Vielleicht die 172.231.255.40 versuchen, falls da auch nur bestimmte IP-Adressen zugelassen werden...

ja habe ich. Aber die 172.231.255.45 ist nur ganz kurz ueberhaupt ansprechbar. Und deswegen kommt der Portscan nicht weit.

Meinem Testsystem selbst habe uebrigens in allen Tests die (noch unbenutzte) 172.231.255.31 gegeben. Ausser beim "Ping-Trick" (da war es die 172.231.255.40). Sonst gaebe es ja staendig Adresskonflikte.

Ich hole gleich mein 2. Modem mit SR70.12.33-180327 ab. Es wurde heute endlich im Pickup zugestellt. Dann setze ich parallel zum 1. Testsystem ein 2. System auf und kann dann alle Tests parallel auf beiden Modems ausfuehren.

 

[sparkie]

so, ich habe jetzt 2 parallele Testsysteme:

1. SR70.12.30a
2. SR70.12.33-180327

eure Befuerchtung hat sich nun bewahrheitet: in SR70.12.33-180327 kommt auf 172.31.255.20 und 172.31.255.40 waehrend der Bootphase kein Service hoch (im Gegensatz noch zu SR70.12.30a). Zumindest keiner der von 172.31.255.31 (jeweils IP meiner beiden unabhaengigen Testsysteme) aus ansprechbar waere.

Offenbar wurde die "Hintertuer" in den neueren Firmwaren tatsaechlich gefixt.

 

[Andreas1969]

Mißt, was macht TC da für´n Scheiß :wand:

 

[sparkie]

1. Mal probieren, ob man vom Modem tftp-Server neben "version.txt" vielleicht auch "cmversion.txt", "newreq.ca" und "newreq.key" laden kann.

die "cmversion.txt", "newreq.ca" und "newreq.key" wird im Gegensatz zu "version.txt" und "hardware_id.txt" nicht gefunden. Zumindest nicht im default-Directory

 

[sparkie]

Übrigens hat man auch nur mit der Kabelmodem-IP 172.231.255.45 Zugriff auf den SNMP-Server des Routerteils:

<i>
</i># CM use 172.31.255.45 to get/set RG SNMP
rocommunity public 172.31.255.45/255.255.255.255
rwcommunity private 172.31.255.45/255.255.255.255

auf welche MIBs bezieht sich das? Weil ein

<i>
</i>snmpwalk -v 2c -c public -m all 172.31.255.20

liefert zumindest schon mal Ergebnisse auf die MIBs, die bei meinem Debian standardmaessig dabei sind. Mein Testsystem hat dabei (wie immer) 172.31.255.31

 

[Andreas1969]

auf welche MIBs bezieht sich das?

https://workupload.com/file/MLYDGUb

 

[robert_s]

auf welche MIBs bezieht sich das? Weil ein

<i>
</i>snmpwalk -v 2c -c public -m all 172.31.255.20

liefert zumindest schon mal Ergebnisse auf die MIBs, die bei meinem Debian standardmaessig dabei sind. Mein Testsystem hat dabei (wie immer) 172.31.255.31

Die .20 IP-Adresse gehört aber zum HUB. Es geht um die .40 Adresse des RG - kannst Du da SNMP ansprechen? Wenn nicht, gib Deinem PC mal die .45...

 

[Andreas1969]

Eigentlich sollte das doch alles recht einfach per SNMP durchzuführen sein:

SnmpMibObject docsDevSwAdminStatus.0 Integer 2; 
SwUpgradeServer 172.22.0.13; 
SwUpgradeFilename "DORGKLDT_SR701230a_JK_84-E.img"; 

Speziell für die Labor FW müsste wohl noch folgendes Objekt mitgegeben werden. da die FW auf einer neuen Architektur aufbaut:

SnmpMibObject enterprises.4413.2.99.1.1.2.2.10.1.0 HexString 0x3140;

Noch mal zur Erinnerung, so ist das Update per SNMP definitiv möglich, zumindest von der HFC Seite aus, das müsste doch über die 172er Adressen auch funktionieren :kratz:

 

[sparkie]

ich bekomme die Fehlermeldung

<i>
</i>TCH-CABLEBROADBAND-MIB::technicolor = No Such Object available on this agent at this OID

bei

<i>
</i>snmpwalk -v 2c -c private -M/usr/share/snmp/mibs/iana:/usr/share/snmp/mibs/ietf:/root/MIBS -m ALL 172.31.255.40 1.3.6.1.4.1.46366 > snmp.log

Testrechner hat .45.

Aber wahrscheinlich bin ich zu bloed den 'snmpwalk' richtig aufzurufen. Muss mal in den man pages nachlesen. In '/root/MIBS' stehen natuerlich die 3 TC MIBs von oben

 

[sparkie]

was ist jetzt eigentlich die Erwartungshaltung?

Wenn ich im hochgefahrenen Zustand

<i>
</i>snmpwalk -v 2c -c public -M+/root/MIBS -m all 192.168.100.1 1.3.6.1.4.1

(Testsytem habe ich statisch einfach 192.168.100.22 zugewiesen)
dann listet er wunderschoen alles moegliche aus 'TCH-CM-MIB'

Ziel ist es jedoch an die Variablen von 'TCH-HW-MIB' zu kommen? Das habe ich bislang noch nicht hinbekommen (auch nicht mit 172.31.255.40 etc..)

 

[robert_s]

was ist jetzt eigentlich die Erwartungshaltung?
Ziel ist es jedoch an die Variablen von 'TCH-HW-MIB' zu kommen? Das habe ich bislang noch nicht hinbekommen (auch nicht mit 172.31.255.40 etc..)

Du sprichst mit dem falschen SNMP-Server. Ich habe ja schon mal gepostet, welche SNMP-Befehle das dload-Script auf dem Modem verwendet:
https://www.unitymediaforum.de/viewtopic.php?f=53&t=36496&start=525#p405523

Du musst also mit dem SNMP-Server unter der .45 sprechen - und das möglicherweise wieder mit der .40er IP als Absender.

 

[sparkie]

also die MIBs fuer 'technicolor', 'tchCableBroadband', 'tchCM' sind problemlos auszulesen.
Was bis jetzt nicht geht ist die 'tchHwDescr'.
Dabei habe ich alles durchpermutiert:
SRC (Testsystem): 172.31.255.31, 172.31.255.40, 172.31.255.45, 192.168.100.22
DST (Modem): 172.31.255.20, 172.31.255.40, 172.31.255.45, 192.168.100.1
Fehlermeldung:

<i>
</i>TCH-HARDWARE-MIB::tchHwDescr = No Such Object available on this agent at this OID

BTW: Irgendwelche Services von 172.31.255.45 abzugreifen ist generell schwer. Im Gegensatz zu 172.31.255.20, 172.31.255.40 ist die 172.31.255.45 nur ganz kurz ansprechbar. Als wenn die vom Modem nur ganz kurz konfiguriert wuerde (vielleicht 1s).

 

[sparkie]

SnmpMibObject enterprises.4413.2.99.1.1.2.2.10.1.0 HexString 0x3140;

was ist das eigentlich fuer ein Objekt? Ich finde die Definition nirgends.

 

[Andreas1969]

SnmpMibObject enterprises.4413.2.99.1.1.2.2.10.1.0 HexString 0x3140;

was ist das eigentlich fuer ein Objekt? Ich finde die Definition nirgends.

cmSwUpgradeEnable

Please follow the following information for upgrading this test release SR70.12.33-180327
This test release is based on a new software architecture, so please read carefully the following comment:

When upgrading to this test software, it is mandatory to have the following
cmSwUpgradeEnable OID entry in the cm config file to ensure a successful upgrade with the
CM UBIFS component.
SnmpMibObject enterprises.4413.2.99.1.1.2.2.10.1.0 HexString 0x3140;

 

[sparkie]

ok, danke. Aber genau dieses 'cmSwUpgradeEnable' finde ich in keiner MIB

 

[robert_s]

Mal zur Funktionsweise des "Thomson Firmware Upgrade Tool", das ist ja freundlicherweise in einer der enthaltenen XML-Dateien dokumentiert:

<i>
</i>	- Detect: configure the interface with a static IP and detect the device.	- Backup: backup configuration files.	- Start and transfer: sets the device in BOOTP and transfers the firmware image.	- Install: wait until the device has finished installing the firmware.	- Restore: restore the configuration files.

Also läuft das über BOOTP...

 

[sparkie]

so, ich habe jetzt 2 parallele Testsysteme:

1. SR70.12.30a
2. SR70.12.33-180327

oehm, kann mir einer sagen was hier passiert ist?

statt SR70.12.30a ist jetzt auf meinem 1. Modem ploetzlich SR70.12.20 aktiv :smile:

eigentlich gar nicht schlecht. Jetzt habe ich sogar wieder die Menuepunkte, die in SR70.12.30a wegoptimiert wurden.

natuerlich hab ich nicht nach jedem Experiment geprueft ob die Firmware zurueckgestuft wurde.

Aber es scheint fuer einen Downgrade offenbar einen Weg zu geben...

...haengt moeglicherweise damit zusammen, dass ich auch oefters mal am Reset-Knopf rumgespielt habe. Man sieht ja nun leider nix was er macht, Vielleicht wenn ich an den seriellen Schnittstellen mitgelesen haette?

 

[Wechseler]

Es gibt im Flash vermutlich eine zweite Partition und dort ist noch die alte 20er-Firmware gespeichert, auf die du wohl durch zu oft Resetten umgeschaltet hast.

 

[sparkie]

ja klar. Dann bekommt man das Teil ja wohl (wie auch immer) auf einen lauffaehigen Stand. Selbst nach einem kleineren Firmware-Upgrade-GAU.

Die Inhalte von 'version.txt' und 'hardware_id' haben sich durch den Downgrade uebrigens nicht veraendert.

 

[Samsungstory]

Oh. Das würde erklären, wieso bei mir das eine Gerät dann von der 30a wieder bei der 20 war.... :wand:

 

[sparkie]

richtig uebel wird es aber dann, wenn jemand mit Vodafone, der auf >=SR70.12.33-180327 angewiesen ist, auf diese Weise ploetzlich nicht mehr ins Netz kommt :brüll:

vielleicht kann man den Effekt auch wieder umkehren? Keine Ahnung ob sowas irgendwo dokumentiert ist