Unitymedia Technicolor TC4400 FW Update Wie?

[addicted]

Soweit ich mich erinnere war das .20-Problem lediglich während der Provisionierung relevant. Bei 2 Kunden mit manueller Provisionierung lief es danach ja scheinbar problemlos.

 

[Wechseler]

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:

Man braucht die 33er-Labor nur zur Erstaktivierung. Danach könnte man das Gerät auch auf die 20er downgraden und es sollte immer noch laufen, denn das CMTS kennt die CM-MAC schließlich.

 

[sparkie]

ok, danke fuer die Erklaerung. Das funktioniert aber nur, wenn jemand nicht waehrend seiner Experimente temporaer ein anderes Geraet provisioniert, um im Internet zu bleiben

weil Vodafone vergisst bei Neuprovisionierung das alte Geraet. D.h. es muesste bei Rueckbau wieder ganz normal provisioniert werden. Was aber dann mit der .20 nicht mehr geht.

 

[robert_s]

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?

Kann das vielleicht schon durch einen "Factory Reset" kommen, also dass der nicht nur die Konfiguration, sondern auch gleich die Firmware auf den Auslieferungszustand zurückversetzt? Oder hattest Du zuvor schon mal einen Factory Reset (Reset-Taster > 10s gedrückt halten) gemacht, ohne dass Dich das auf die 20er Firmware zurückgeworfen hätte?

In der Firmware finde ich auf den ersten Blick jedenfalls keinen A/B Mechanismus, also dass der Firmwares in alternierende Slots flasht...

 

[Samsungstory]

Passiert anscheinend, wenn man mehrmals länger den Reset Taster drückt...glaube 2x über 10s reichen dazu...

 

[sparkie]

in Kenntnis, dass >10s einen Factoryreset ausloest, habe ich den Resettaster sicher nie laenger als ca. 5s am Stueck gedrueckt.

jedoch hatte ich das Modem mit dem Ein/Ausschalter in allem moeglichen Betriebszustaenden und waehrend Portscans etc. oft aus/eingeschaltet. In die Bootphasen hinhein sicher auch mal den Resettaster kurz gedrueckt.

Man weiss ja ohne eine Konsole nicht wo sich das Modem im Hochfahrzustand gerade mal wieder zufaellig befindet. Vielleicht hat da das Teil mal irgendwann etwas in den falschen Hals bekommen :smile:

 

[Wechseler]

Man weiss ja ohne eine Konsole nicht wo sich das Modem im Hochfahrzustand gerade mal wieder zufaellig befindet.

Das zeigt es über die LEDs eigentlich zuverlässig an.

 

[Andreas1969]

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.

Das ist ja jetzt auch nicht mehr dramatisch, man kann ja wohl jederzeit mit einem Factoryreset auf die 20er Auslieferungsfirmware zurück und von da aus eine aktuelle FW einspielen

 

[sparkie]

Das zeigt es über die LEDs eigentlich zuverlässig an.

naja eine Alphaconsole waere doch noch was anderes.

 

[Andreas1969]

Soweit ich mich erinnere war das .20-Problem lediglich während der Provisionierung relevant. Bei 2 Kunden mit manueller Provisionierung lief es danach ja scheinbar problemlos.

Nein, das ist ein Trugschluss :streber:
Bei PYUR mag das funktionieren, aber nicht bei VF :traurig:
Auch wenn Du das Modem mit der 33er Labor provisioniert bekommen hast und anschließend auf die 20 downgradest, bist Du bei VF Offline :winken:

Das Modem bezieht ja dann vom DHCPV6 Server keine Management IP mehr und somit kann es ja dann nicht mehr Online gehen. :wand:

 

[Andreas1969]

Um auf Nummer sicher zu gehen, brauchen wir dringend die lokale Update Möglichkeit über die LAN Ports des Modems, sonst muss man es jedesmal nach einem ungeplanten Downgrade zum CMTS Mann (Tobsen) einschicken. Aber das läuft ja auch noch nicht rund.

 

[MartinP_Do]

Um auf Nummer sicher zu gehen, brauchen wir dringend die lokale Update Möglichkeit über die LAN Ports des Modems, sonst muss man es jedesmal nach einem ungeplanten Downgrade zum CMTS Mann (Tobsen) einschicken. Aber das läuft ja auch noch nicht rund.

Wenn durch zweimaligen Factoryreset die .20er Firmware wieder aktiviert wird, hat man doch eine recht "runde" Vorgehensweise...
Nach einem Downgrade auf eine "vernagelte" Version durch den Provider kann man ja auf die "nicht vernagelte .20 downgraden - außer, der Werkslieferzustand ändert sich, und es ist nach einem erzwungenen Ruckschritt auf das Factory-Image keine "offene" Version auf dem Modem aktiv...

Ansonsten müsste man sich das Datenblatt des Flash-Bausteins anschauen, ob es eine Schreibschutz-Möglichkeit gibt. Ein Schreibschutz wäre aber nur dann hilfreich, wenn Schreibzugriff zum Flash-Baustein im Betrieb des Modems (z. B. zur Ablage der Konfigurationsdatei des Providers) nicht nötig ist ...
Nachtrag: Nach kurzem Blick scheint das Auflegen des Pins 19 (#WP) auf L das Beschreiben des Bausteins zu verhindern....

Den müsste man aber ablöten, hochbiegen, und zb. eine entsprechende dreipolige Jumperbrücke zwischen Lötpad und dem hochgebogenen Pin anbringen.
Mittelpin=Hochgebogener Pin des Flash-Bausteins.
erster seitlicher Pin = Lötpad des hochgebogenen Pins (Bei gesetzter Brücke zwichen Mittelpin und diesem Pin ist Schreiben möglich)
anderer seitlicher Pin = Gnd (Bei gesetzter Brücke zwichen Mittelpin und diesem Pin ist Schreiben nicht möglich)

Falls man durch vorheriges Messen feststellt, dass der Pin 19 eine direkte Verbindung zu Vcc hat, könnte man sich die knifflige Verbindung zwischen erstem seitlichem Jumperbrücken Pin und dem Lötpad sparen, und Vcc von einer bequemer erreichbaren Stelle beziehen ...

Hier hat jemand einen Schreibschutz an einem gleichartigen Chip auf einem USB-Stick nachgerüstet:
https://www.vkldata.com/Schreibschutzschalter-am-USB-Stick-nachruesten

Die beiden dortigen Lösungen gefallen mir noch besser, weil man mit einer zweipoligen Pfostenleiste auskommt ...

 

[Andreas1969]

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.

Nun
1. SR70.12.20
2. SR70.12.33-180327


Bald
1. SR70.12.20
2. SR70.12.20

 

[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
Jetzt hast Du ja die idealen Voraussetzungen, um das Update von der 20 auf die 30a zu testen, da man dort das
Objekt "SnmpMibObject enterprises.4413.2.99.1.1.2.2.10.1.0 HexString 0x3140;"
nicht setzen brauch. (Ist nur bei der Labor so)
Darum kümmern wir uns dann, wenn das Update dann überhaupt mal klappt. :zwinker:

 

[sparkie]

Klingt nicht schlecht :smile:
aber ich komme leider erst am Wochenende dazu...

 

[Andreas1969]

Sind eigentlich die 10er Management IP´s für TFTP Port 69 durchlässig?
Eine blöde Idee hätte ich da noch, falls das Update wirklich nur über die HFC Schnittstelle akzeptiert wird:

Ein Device hinter einem unprovisionierten Modem bekommt ja auch eine 10er IP zugewiesen, da könnte man ja dann den TFTP Server mit der FW-Datei unter der 10er IP drauf laufen lassen.
Wenn ich dann das FW Update per SNMP initiiere und als TFTP Server das Devíce hinter dem unprovisionierten Modem angebe, müsste sich das Modem ja dann das Update über die HFC Schnittstelle übers UM-Netz ziehen :kratz:

Nur mal so als Gedankenanstoss :winken:

 

[Andreas1969]

Da ich hier eh noch mehrere Modems rumfliegen hab, werd ich das mal testen.
Ich lass dann mal vom Device hinter dem unprovisionierten Modem einen Portscan zur 10er Management IP meines provisionierten TC4400 laufen.

 

[Flole]

Also können unprovisionierte Modems untereinander kommunizieren? Das könnte zumindest in der Theorie doch unterbunden werden, oder nicht? Oder geht das nur über das Management-Netz, nicht jedoch über die normale IP wo man zum Aktivierungsportal kommt? Wäre natürlich ne Maßnahme wenn jemand im Vodafone Netz (geht es dort denn auch? Und eventuell sogar CMTS-Übergreifend oder immer nur an der selben CMTS?) einen Server bereitstellen würde (ich melde mich freiwillig, brauche nur ein Modem und dann bin ich gerne bereit das 24/7 zu betreiben und die Firmware zu hosten).

Wenn das echt die Lösung ist dann ist das alles doch einfacher als erwartet bzw. gedacht.

 

[Andreas1969]

Wenn das echt die Lösung ist dann ist das alles doch einfacher als erwartet bzw. gedacht.

Nee, gerade mal getestet, das ist nicht die Lösung.
Zumindest hat UM da alles dicht gemacht, keinerlei Kommunikation im 10er Netz untereinander möglich. :traurig:

Also, unprovisioniertes Modem, mein Device dahinter bekommt folgendes Netzwerk zugewiesen:

IP: 10.195.142.59
Subnet: 255.255.252.0
Gateway und DHCP Server: 10.195.140.1

Von diesem Device hab ich folgende 2 Portscans gemacht:

1. Zu meinem TC4400 mit der Management IP 10.154.xxx.yyy
Der Scan liefert keinen einzigen offenen Port, das Einzige, was der Portscan als Ergebnis liefert, ist die MAC Adresse und Vendor meines CMTS:
00:17:10:98:30:89 [Casa Systems Inc.]

2. Zum UM TFTP Server (10.145.0.1)
Der Scan liefert da auch keinen einzigen offenen Port (hier hätte ich zumindest den Port 69 erwartet)
Das Einzige, was der Portscan hier ausspuckt, ist ein Ping von 13ms

 

[Flole]

Das war so ja fast zu erwarten da es getrennte Netze sind, die Frage ist was passiert wenn du 2 unprovisionierte Geräte anschließt, können die denn untereinander kommunizieren oder funktioniert das ebenfalls nicht? So könnte man eventuell noch versuchen über das "WAN" das Update zu laden.

 

[Andreas1969]

was passiert wenn du 2 unprovisionierte Geräte anschließt, können die denn untereinander kommunizieren oder funktioniert das ebenfalls nicht?

Hab ich auch schon versucht, funktioniert ebenfalls nicht :traurig:

 

[Andreas1969]

Anscheinend hat UM das soweit abgedichtet, dass nur die Management Adressen der Modems selbst mit dem TFTP Server kommunizieren dürfen, nicht aber die 10er IP's, die dem Device hinter einem unprovisionierten Modem zugewiesen werden.
Vielleicht funktioniert das ja im BW Bereich oder im VF Netz, oder PYUR :kratz:

 

[rv112]

In BW bekommt ein unprovisioniertes Modem bzw. der Router dahinter eine öffentliche IPv4 und 1 MBits. Das kommt wohl noch daher dass die Techniker bei KabelBW die Modems direkt beim Kunden provisioniert haben.

 

[Andreas1969]

In BW bekommt ein unprovisioniertes Modem bzw. der Router dahinter eine öffentliche IPv4 und 1 MBits. Das kommt wohl noch daher dass die Techniker bei KabelBW die Modems direkt beim Kunden provisioniert haben.

Das würde ja dann in BW überhaupt nicht funktionieren. :traurig:

Edit: Bekommt denn ein 2tes Device hinter dem Modem auch eine öffentliche IP, oder dann ne 10er :kratz:

 

[Andreas1969]

Das bringt mich gerade auf noch eine Idee:
Ein zweites Device hinter dem TC4400 anschließen, das bekommt ja dann auch eine 10er IP, und von da aus versuchen, die Management IP des TC4400 zu erreichen :zwinker: