Unitymedia Technicolor TC4400 Docsis 3.1 Modem Info Thread

[rv112]

Das TM3402B. Aber das TC4400 bleibt zu empfehlen und macht zum größten Teil auch keine Probleme.

 

[Berny]

Das TM3402B. Aber das TC4400 bleibt zu empfehlen und macht zum größten Teil auch keine Probleme.

ich meine weil ein Kunde geschrieben hat, dass das Modem nicht mehr priorisiert wird.

 

[rv112]

Das ist auch Quatsch. Das Modem wird nach wie vor problemlos provisioniert. Es gibt nur mit bestimmten Kopfstationen aktuell Probleme die sämtliche D3.1 Geräte betreffen. UM ist dort aktuell am patchen und rumprobieren.

 

[Berny]

Das ist auch Quatsch. Das Modem wird nach wie vor problemlos provisioniert. Es gibt nur mit bestimmten Kopfstationen aktuell Probleme die sämtliche D3.1 Geräte betreffen. UM ist dort aktuell am patchen und rumprobieren.

Ok, kannst du mir sagen, ob die das auch mit DualStack machen?

 

[rv112]

Ja.

 

[MichaelBre]

Hier noch als Stütze was ich gemacht habe damals: https://www.unitymediaforum.de/viewtopic.php?f=53&t=36248&start=4125

Wie krieg ich denn ohne Internet ein neues Paket auf mein Debian :wand:
Muss mal schauen wie ich den ESXi ans Internet bekomme...

 

[rv112]

Thethering via Handy?

 

[MichaelBre]

Ich bin kein ESXi Admin daher hab ich es nicht hinbekommen...
Das gestückelte Internet des TC4400 hat gereicht um das snmp Paket zu installieren.

Alle Versuche wurden ohne Coax und nach einem Neustart durchgeführt.

Versuch mit 1.3.6.1.4.1.46366.4292.77.1.307 als v2

<i>
</i>$ snmpgetnext -v2c -c public 192.168.100.1 1.3.6.1.4.1.46366.4292.77.1.307
iso.3.6.1.4.1.46366.4292.77.1.307.0 = INTEGER: 1
$ snmpset -v2c -c public 192.168.100.1 1.3.6.1.4.1.46366.4292.77.1.307.0 i 2
Error in packet.
Reason: noAccess
Failed object: iso.3.6.1.4.1.46366.4292.77.1.307.0
$ snmpset -v2c -c public 192.168.100.1 1.3.6.1.4.1.46366.4292.77.1.307.0 i 0
Error in packet.
Reason: noAccess
Failed object: iso.3.6.1.4.1.46366.4292.77.1.307.0

Versuch mit 1.3.6.1.4.1.46366.4292.77.1.93 als v2

<i>
</i>$ snmpget -v2c -c public 192.168.100.1 1.3.6.1.4.1.46366.4292.77.1.93
iso.3.6.1.4.1.46366.4292.77.1.93 = No Such Object available on this agent at this OID
$ snmpgetnext -v2c -c public 192.168.100.1 1.3.6.1.4.1.46366.4292.77.1.93
iso.3.6.1.4.1.46366.4292.77.1.300.0 = INTEGER: 0
$ snmpset -v2c -c public 192.168.100.1 1.3.6.1.4.1.46366.4292.77.1.93 i 0
Error in packet.
Reason: notWritable (That object does not support modification)
Failed object: iso.3.6.1.4.1.46366.4292.77.1.93

Versuch mit 1.3.6.1.4.1.46366.4292.77.1.307 als v1

<i>
</i>$ snmpgetnext -v1 -c public 192.168.100.1 1.3.6.1.4.1.46366.4292.77.1.307
iso.3.6.1.4.1.46366.4292.77.1.307.0 = INTEGER: 1
$ snmpset -v1 -c public 192.168.100.1 1.3.6.1.4.1.46366.4292.77.1.307 i 2
Error in packet.
Reason: (noSuchName) There is no such variable name in this MIB.
Failed object: iso.3.6.1.4.1.46366.4292.77.1.307

Versuch mit 1.3.6.1.4.1.46366.4292.77.1.93 als v1

<i>
</i>$ snmpget -v1 -c public 192.168.100.1 1.3.6.1.4.1.46366.4292.77.1.93
Error in packet
Reason: (noSuchName) There is no such variable name in this MIB.
Failed object: iso.3.6.1.4.1.46366.4292.77.1.93
$ snmpgetnext -v1 -c public 192.168.100.1 1.3.6.1.4.1.46366.4292.77.1.93
iso.3.6.1.4.1.46366.4292.77.1.300.0 = INTEGER: 0
$ snmpset -v1 -c public 192.168.100.1 1.3.6.1.4.1.46366.4292.77.1.93 i 0
Error in packet.
Reason: (noSuchName) There is no such variable name in this MIB.
Failed object: iso.3.6.1.4.1.46366.4292.77.1.93

Spannend finde ich die Fehlermeldung bei snmpset v2 auf die 93er: Reason: notWritable (That object does not support modification)
Wahrscheinlich ist es einfach eine falsche Fehlermeldung, denn die OID gibt es ja nicht.

Anscheinend komme ich an dieser Front kein Stück weiter.

Kann denn mal jemand mit 70.12.40-180627 Firmware prüfen ob er dort etwas verändern kann?

 

[tar]

Kurzer Zwischenstand bei mir:

Gestern habe ich nach einer Woche geduldigen Wartens mal bei einem Techniker meines kleinen lokalen Providers nachgehakt, ob sie denn inzwischen Fortschritte beim Provisionieren meines TC4400 gemacht haben. Dahingehend hat auch Herr Werner selbst seine Hilfe angeboten. Leider haben sie das aber nicht weiter verfolgt, da die Geschäftsleitung diesen Techniker angewiesen hat, keine Aufwände mehr dahin zu investieren, weil sie
- schlechte Erfahrungen mit anderen TechniColor-Modems (TC7200) gemacht haben
- bereits ausreichend Alternativen anböten (Arris, Fritz!Box) und sich darauf fokussiert hätten, d.h. ich wäre der Einzige, der überhaupt ein anderes Modem anschließen wöllte
- zwar Routerfreiheit bestünde, man das bzgl. des Modems aber anders sieht, d.h. dass man dort keine Modemfreiheit akzeptiert

Nun stehe ich vor der Wahl, mich entweder bei der BNA zu melden und parallel ein Schreiben an die Geschäftsstelle zu verfassen oder das Ganze auf sich beruhen zu lassen und das TC4400 an Werner zurückzuschicken (falls er das noch akzeptiert) bzw. zu verkaufen.

Einerseits verstehe ich sie ja schon, wenn die Einrichtung für jeden Betreiber oder sogar Modemtyp separat aufwendig konfiguriert werden muss und ich hier wirklich "der einzige Schwule im Dorf" sein sollte - doch so wird mir das nicht kommunizert. Stattdessen werde ich mit fadenscheinigen Begründungen abgekanzelt, als doof hingestellt und hingehalten, was mich mittlerweile doch arg aufregt.

Rein technisch frage ich mich aber obendrein, ob es überhaupt gerade sinnvoll wäre, das weiterzuverfolgen, wenn bereits große Provider wie UM Provisionierungsprobleme mit CASA CMTS haben, da mein Provider ebenfalls CASA nutzt und sich eine saubere Provisionierung dann ja nochmals deutlich verzögern könnte/dürfte.

Ich werd bekloppt.

 

[lupus]

Ich frage mich ob eine FB 6591 bei diesem Provider reibungslos funktioniert. Aufgrund deiner Schilderungen würde ich mal behaupten dass auch die FB 6591 Probleme machen wird. Bisher scheint nur VF das Problem mit dem Casa und 3.1 im Griff zu haben.

 

[rv112]

Definitiv an die BNA wenden! Was soll die dümmliche Aussage dass ein Modem nicht zur Routerfreiheit gehört?

 

[addicted]

Heißt halt Endgerätefreiheit, nicht Routerfreiheit.

 

[MichaelBre]

...
Bei mir sind die selben Probleme wie bei @MichaelBre aufgetreten. Könnte ich nachher nochmal testen.
...

Und konntest du nochmal testen?
Kannst du bei der 41er Firmware den 93er oder 307 Wert per SNMP ändern?

 

[rv112]

Ich würde die .41 testen, bin aber gerade in der Hauptstadt. Ohne TC4400

 

[Andreas1969]

bin aber gerade in der Hauptstadt

Metallica :kratz:

 

[rv112]

Rennt hier überall rum, aber nein

 

[Hemapri]

Bisher scheint nur VF das Problem mit dem Casa und 3.1 im Griff zu haben.

Problem ist gut und VF hat da sicherlich nichts im Griff. Das sogenannte Problem bei UM und den CASAs bestand, bzw. besteht nur darin, dass die Firmware für den DOCSIS 3.1 Betrieb vertragsgemäß noch gar nicht installiert war. Das ist ein bürokratisches, kein technisches Problem. Dort, wo die Firmware mittlerweile installiert wurde, funktioniert es. Bei UM war durchaus bekannt, dass DOCSIS 3.1-Geräte an den CASA-CMTSn in der aktuellen Konfiguration niemals funktionieren können und haben die Servicepartner bereits im April per Rundschreiben darüber informiert.

MfG

 

[Andreas1969]

Bei UM war durchaus bekannt, dass DOCSIS 3.1-Geräte an den CASA-CMTSn in der aktuellen Konfiguration niemals funktionieren können und haben die Servicepartner bereits im April per Rundschreiben darüber informiert.

Unglaublich, diese Ignoranz :wand:

 

[MichaelBre]

Welche Werte sollte ein OFDM Kanal im besten Fall haben?

Zum Glück habe ich seit einiger Zeit Nagios am Laufen und kann ganz genau aufzeigen das der OFDM Kanal seit den 04.07.2019 um ca. 9:30 Uhr (+-9min) aufgeschaltet ist. Seitdem besteht auch die „Störung“.
Ich werde morgen eine entsprechende Mail an die Business Adresse aufsetzen und eine Gutschrift fordern.
Mal sehen was es bringt...

Der 7€ Amazon Filter kommt an Dienstag, bin gespannt ob der eine Verbesserung erzielt.

 

[vnheilig]

So. Ich hatte heute endlich Zeit, mein nicht-provisioniertes TC4400 im Kombination mit einem Casa CMTS (00:17:10) zu testen.
Was soll ich sagen, alle fünf LEDs grün und die berühmt-berüchtigte no-service.bin (mit 10er IP) kommt an. :bier:

Nur die Anmeldung beim CMTS dauert gefühlt etwas zu lange, etwa zwischen 5 und 10 Minuten bis alle LEDs grünes Licht zeigen. Wie lange dauert das bei euch normalerweise?
Aus den wenigen Log-Zeilen vom TC4400 werde ich nicht schlau und jetzt wäre eigentlich nur noch interessant zu wissen, ob das Casa CMTS bereits gepatcht wurde oder nicht? Lässt sich das irgendwie herausfinden oder ermitteln? :kratz:

Log:
[spoil]

 5 Sun Jul 7 20:56:11 2019 Notice (6) "TLV-11 - unrecognized OID;CM-MAC=REMOVED;CMTS-MAC=REMOVED;CM-QOS=1.1;CM-VE... 4 Sun Jul 7 20:56:11 2019 Warning (5) "DHCP WARNING - Non-critical field invalid in response ;CM-MAC=REMOVED;CMTS-MAC=REMOVED... 3 Time Not Established Notice (6) "Honoring MDD; IP provisioning mode = IPv4" 2 Time Not Established Critical (3) "SYNC Timing Synchronization failure - Failed to acquire QAM/QPSK symbol timing;;CM-MAC=REMOVED... 1 Time Not Established Critical (3) "No Ranging Response received - T3 time-out;CM-MAC=REMOVED;CMTS-MAC=REMOVED... 0 Time Not Established Critical (3) "SYNC Timing Synchronization failure - Failed to acquire QAM/QPSK symbol timing;;CM-MAC=REMOVED...

[/spoil]

Testumgebung:
[spoil]Bundesland: Hessen (nähe Frankfurt am Main)
Anschlusstyp: Dual Stack (DS)
Config: generic_100000_10000_ds_som_wifi-on_2id-off.bin
TC4400-EU Hardware Version: TC4400 Rev:3.6.0
TC4400-EU Software Version: 70.12.41-180903
[/spoil]

 

[MichaelBre]

Wie lange dauert das bei euch normalerweise?

1:17 Minuten ab Start bis alle LEDs leuchten und Link blinkt.

Kannst du mal testen ob du per SNMP den Wert 307 auf Integer 2 setzen kannst und ob dein TC4400 den 93 Wert hat?
Siehe ein paar Beiträge weiter oben.
Dazu das TC4400 vom Coax trennen, neustarten und dann mit iReasoning MIB Browser (Windows) oder snmp Paket (Linux) testen.

Auslesen:

snmpgetnext -v2c -c public 192.168.100.1 1.3.6.1.4.1.46366.4292.77.1.307
snmpgetnext -v2c -c public 192.168.100.1 1.3.6.1.4.1.46366.4292.77.1.93


Setzen:

snmpset -v2c -c public 192.168.100.1 1.3.6.1.4.1.46366.4292.77.1.307.0 i 2

oder

snmpset -v1 -c public 192.168.100.1 1.3.6.1.4.1.46366.4292.77.1.307 i 2


Danach wieder zurück auf Integer 1 außer du möchtest im DOCSIS 3.0 Modus ohne OFDM Kanal bleiben.

Danke!

 

[vnheilig]

Kannst du mal testen ob du per SNMP den Wert 307 auf Integer 2 setzen kannst und ob dein TC4400 den 93 Wert hat?

Klar, gerne. Mit 70.12.41-180903 spuckt das TC4400 folgendes aus:

snmpgetnext
[spoil][florian@arch tc4400]$ snmpgetnext --version
NET-SNMP version: 5.8

[florian@arch tc4400]$ snmpgetnext -v2c -c public 192.168.100.1 1.3.6.1.4.1.46366.4292.77.1.307
SNMPv2-SMI::enterprises.46366.4292.77.1.307.0 = INTEGER: 1
[florian@arch tc4400]$ snmpgetnext -v2c -c public 192.168.100.1 1.3.6.1.4.1.46366.4292.77.1.93
SNMPv2-SMI::enterprises.46366.4292.77.1.300.0 = INTEGER: 0[/spoil]


snmpset
[spoil]
[florian@arch tc4400]$ snmpset --version
NET-SNMP version: 5.8

[florian@arch tc4400]$ snmpset -v2c -c public 192.168.100.1 1.3.6.1.4.1.46366.4292.77.1.307.0 i 2
Error in packet.
Reason: noAccess
Failed object: SNMPv2-SMI::enterprises.46366.4292.77.1.307.0

[florian@arch tc4400]$ snmpset -v1 -c public 192.168.100.1 1.3.6.1.4.1.46366.4292.77.1.307 i 2
Error in packet.
Reason: (noSuchName) There is no such variable name in this MIB.
Failed object: SNMPv2-SMI::enterprises.46366.4292.77.1.307[/spoil]


PS: Unter Arch Linux wird net-snmp für die oben genannten Befehle benötigt (https://www.archlinux.org/packages/extra/x86_64/net-snmp/files/).

 

[MichaelBre]

Also keine Veränderung zur 40er Firmware...
Die Werte lassen sich nicht mehr ändern.

@rv112: Welche Firmware hat das TC4400 bei dem du den Wert ändern konntest?

----------

Seit dem Neustart gegen 21:40 Uhr, um die Zeit bis zur Verbindung zu messen, komme ich nicht mehr auf das Webinterface des TC4400...
Selbst direkt am Modem komme ich nur einmal kurz auf das Webinterface und alle weiteren Verbindungen schlagen fehl.
Ebenso ein Ping, der hält nur bis ein paar Minuten nach dem vollständigen Verbinden und bricht dann ab.

 

[robert_s]

Also keine Veränderung zur 40er Firmware...
Die Werte lassen sich nicht mehr ändern.

Vielleicht auch nur eine Frage der richtigen Community...?

Evtl. einfach mal "private" versuchen, siehe hier:

https://www.unitymediaforum.de/viewtopic.php?f=53&t=36496&p=407266&hilit=Snmp#p407266

 

[shm0]

Gibts nen Changelog für die .41 Firmware?
Wurde der Temp Sensor "Bug" behoben? (Thermal Throttle?)
Kann das Treshold über SNMP vielleicht verändern/deaktivieren?
Kann man bei Werner die Firmware updaten lassen?

Wer sagt ihr zu dem OFDM Kanal?