Unitymedia Technicolor TC4400 Docsis 3.1 Modem Info Thread

[sparkie]

Wie und womit mache ich das am besten mit Telnet?

Entweder <IP> auf die Management-IP oder die 192.168.100.1 :

telnet <IP>
Login: admin
Password: admin
CM_Console> show all

mit 'show all' bekommst du alles gedumpt

 

[Siggy]

Was kann es sein?

 

[rv112]

Was soll es sein? Alles normal soweit.

Entweder <IP> auf die Management-IP oder die 192.168.100.1 :

telnet <IP>
Login: admin
Password: admin
CM_Console> show all

mit 'show all' bekommst du alles gedumpt

Also provisioniert bekomme ich nur conenction refused. Der Port scheint zu.

 

[Holzlenkrad]

Gibt es eigentlich irgendwo eine Übersicht/Changelog der verschiedenen Firmware-Versionen oder muss ich mir die hier in den 278 Seiten zusammen suchen?

Ich hab die .40 Firmware drauf und damit geht weder der Spectrum analyzer noch Telnet. Etwas ärgerlich

 

[rv112]

Von der .40 gibt es mehrere Firmwares. Die SR70.12.40-180814 hat

Fix
[TC4400GEN-4046] Fix thermal throttling

und die SR70.12.40-180627

Fixes
[TC4400GEN-3119] Secure CLI for all devices for 4400
[TC4400GEN-4033] D31 MIB "docsIf31CmUsOfdmaChanPreEqEnabled" is not functional, always
Enhancements
[TC4400GEN-4011] Integration of OBFC 18.1

Bei dieser gibt es aber einige Probleme:

Known Issues
[TC4400GEN-4031] Port Ethernet not reinit, workaround is a reboot
[TC4400GEN-3992] Ethernet not working after RF cutoff recovery.
[TC4400GEN-3970] After RF cut-off and on getting "T4 Timeout error", the modem is going for
Reboot then scanning instead of DS scanning without reboot.
[TC4400GEN-2801] Modem does not come online D3.0 with 10K (D3.0) when 'required attribute'
parameter is set
[TC4400GEN-3964] – Docsis 3.1 SC-QAM & ODFM RX Power SNMP response takes too long
[TC4400GEN-3183] - CPE has same address as local CM

 

[Holzlenkrad]

Danke für den Link. Passt perfekt, da ich eine Prometheus und eine Grafana VM habe.

So habe ich es bei mir installiert:

auf der Prometheus vm:

# exporter kompilieren:
...

Wer Docker hat und evtl. sogar Prometheus in einem Container laufen lässt, der kann auch einfach den TC400 Exporter in Docker laufen lassen.
Ich habe da mal schnell ein Dockerfile zusammen getippt:

FROM golang:alpine AS builder
RUN apk add git
RUN go get -v github.com/markuslindenberg/tc4400_exporter
FROM alpine:latest
COPY --from=builder /go .
EXPOSE 9623/tcp
CMD ["tc4400_exporter"]

Das große golang Image kann danach gelöscht werden, übrig bleiben ca. 86MB.
Denkt daran, dass in prometheus.yml das Target geändert werden muss, wenn ihr docker-compose oder Links verwendet, kann dort auch einfach der Containername rein

 

[Holzlenkrad]

Danke!
Ich habe die SR70.12.40-180627. Das hört sich ja alles nicht so gut an. Sind die Issues denn in .41 behoben? Sollte ich Updaten? Bis jetzt funktioniert mein Internet aber recht problemlos, wobei ich natürlich kein Vergleich habe, weil ich von Anfang an diese Firmware-Version hatte. War bei Werner auch recht lange so zu bekommen.
Welche wirklichen Probleme (die ein Neustart nicht fixt), habe ich denn zu erwarten?

Known Issues
[TC4400GEN-3183] - CPE has same address as local CM

Was bedeutet der Punkt im Detail?

 

[rv112]

Das ist alles nix Wildes und betrifft mehr den ISP als Dich. Wenn Dein Modem läuft, lass es laufen. Die Firmwarereleases sind nicht ohne Grund public, weil sich die Leute sonst nur unnötige Gedanken machen. Bis zur .30 soll der OFDM angeblich nicht aktiv sein. Ich konnte mit meinem .20 allerdings einwandfrei den OFDM empfangen. Von daher keep going

 

[sparkie]

Also provisioniert bekomme ich nur conenction refused. Der Port scheint zu.

dann teste doch mal mit einem nicht provisionierten Modem, das aber online sein muss. Du hast doch hierzu sicher (wie ich) noch ein paar TC4400 ungenutzt herumliegen
Da funktioniert der telnet 'show all' mit der .33 in jedem Fall. Vielleicht erlauben die so erhaltenen Daten auch schon interessante Erkenntnisse.

 

[rv112]

Werde ich die Tage machen, fange beim .20 an, übers .33 und dann zum .41

 

[sparkie]

ja, es ist immer wieder eine Freude in einen Schrank voller feiner Modems zu schauen (alle mit unterschiedlicher Firmware natuerlich)

 

[why_]

ja, es ist immer wieder eine Freude in einen Schrank voller feiner Modems zu schauen (alle mit unterschiedlicher Firmware natuerlich)

Mir würde es mehr freude machen einen Ordner auf dem PC zu haben mit all den verschiedenen Firmwares und nur ein Modem zum testen zu brauchen.

 

[sparkie]

ja das stimmt.

Schade, dass der kundenseitige Firmware-Update Versuch ueber HFC nicht mehr weiter verfolgt wurde/wird.

Ich haette wie gesagt (noch) die Moeglichkeit HFC-seitig an das unprovisionierte Modem zu kommen. Weil mein Provider (Pÿur) den Adressraum der Modem- Management -IPs nicht absichert.
Vielleicht waere es auf diese Weise sogar moeglich einen Firmware-Update ohne CMTS zu machen. Wenn ich nur selbst ein CMTS haette und den regulaeren Update damit mal durchspielen koennte...
dann wuerde mir vielleicht schon was einfallen.

 

[Andreas1969]

Ich haette wie gesagt (noch) die Moeglichkeit HFC-seitig an das unprovisionierte Modem zu kommen. Weil mein Provider (Pÿur) den Adressraum der Modem- Management -IPs nicht absichert.

Das ist doch ein Traum, dann könntest Du doch einen TFTP Server hinter einem unprovisionierten Modem aufsetzen. Der wäre dann auch im 10er Bereich erreichbar und dann dann per HFC an einem zweiten Modem den Update Prozess anstoßen

 

[rv112]

Sollte in der Tat klappen.

Ist zwar ein DSL Modem, aber ein Technicolor, vielleicht findet einer der Cracks hier ja was Brauchbares. Poste es auch noch mal im entsprechenden Thread: https://www.crc.id.au/hacking-the-technicolor-tg799vac-and-unlocking-features/

 

[Andreas1969]

Dann könnte @sparkie ja für uns die FW Updates an seinen Pÿur Anschluss durchziehen

 

[sparkie]

ja, ich brauchte erst mal saemtliche Files, Infos und Unterlagen wie der Update per CMTS ablaeuft. Dann koennte man den Prozess Schritt fuer Schritt auf meinen Pÿur Anschluss uebertragen. Aber leider ist Tobsen ja nicht mehr aktiv hier,,,

 

[sch4kal]

Vielleicht wurde er von den KNB mundtot gemacht ?

 

[Andreas1969]

Vielleicht wurde er von den KNB mundtot gemacht ?

Oder die Steuerfahndung ist Ihm auf'n Pelz gerückt

 

[sparkie]

eine andere Moeglichkeit als den gesamten (funktionierenden) FW-Update Vorgang anhand einer CMTS zu analysieren und anschliessend auf ein Verfahren (ohne CMTS) zu uebertragen sehe ich nicht. Ansonsten ist das Ganze ein ewiges Stochern im Nebel.

Oder gibt es sonst noch Ideen wie wir mit einem FW-Update ohne CMTS in endlicher Zeit weiterkommen?

 

[sch4kal]

Der Update-Vorgang dürfte in den CableLabs Standards sogar definiert sein, meine das mal in einem Dokument gesehen zu haben.

 

[rv112]

ja, ich brauchte erst mal saemtliche Files, Infos und Unterlagen wie der Update per CMTS ablaeuft. Dann koennte man den Prozess Schritt fuer Schritt auf meinen Pÿur Anschluss uebertragen. Aber leider ist Tobsen ja nicht mehr aktiv hier,,,

Die Firmware kann ich Dir zukommen lassen, aber Unterlagen zum Update habe ich nicht. Kommt ja auch auf die entsprechende CMTS an.

 

[sparkie]

danke, ich denke ohne ein komplettes System, das mit Standardmitteln den Update durchzufuehren kann macht es wenig SInn. Und das koennte ich nach derzeitigem Kenntnisstand nur zusammen mit Tobsen reverse-engineeren.

 

[Andreas1969]

danke, ich denke ohne ein komplettes System, das mit Standardmitteln den Update durchzufuehren kann macht es wenig SInn. Und das koennte ich nach derzeitigem Kenntnisstand nur zusammen mit Tobsen reverse-engineeren.

Das bringt Dich aber auch nicht weiter, da dies hier eine andere Vorgehensweise wäre.

Du müsstest per SNMP den Pfad der FW Datei Deines TFTP Servers eintragen und anschließend per Telnet im CLI das Update antriggern, wenn ich mich da noch recht entsinne. Hab das damals nicht weiter verfolgt, da ich (im UM Netz) erst garnicht auf's CLI gekommen bin.

 

[rv112]

Nachdem ich nun mittels Raspberry Pi auch meine Segmentauslastung auswerte, fällt mir auf dass jemand in meinem Segment wohl gelegentlich nur einen DS Kanal nutzt. So war eben der 474 MHz bei 40 MBit/s, wohin alle anderen 30 Kanäle bei maximal 5 MBit/s waren. Ich hatte zu diesem Zeitpunkt keine Last auf der Leitung

Mache ich einen Volllasttest, springen alle 31 SC-QAM Kanäle um jeweils ca. 5 MBit/s hoch. Demnach kann es doch kein 1:1 Loadbalancing zum OFDM sein, sondern dieser wird definitiv stärker genutzt. Ob das nun "neu" ist, oder die Auswertung mittels SBC einfach ungenauer ist, weiß ich natürlich nicht.