Unitymedia Technicolor TC4400 Docsis 3.1 Modem Info Thread

[Exiver]

Immer nur die erste Zeile eingeben, die zweite ist die Ausgabe ;-)

also z.B.

snmpgetnext -v2c -c public 192.168.100.1 1.3.6.1.4.1.46366.4292.77.1.307

und

snmpset -v2c -c public 192.168.100.1 1.3.6.1.4.1.46366.4292.77.1.307.0 i 2

 

[rv112]

Hm gerade eben ist die Leitung wieder absolut sauber! 400 MBits kommen auch voll durch. Der OFDM Kanal ist immernoch Particial Service.

Ups und während ich das geschrieben habe ist die Leitung wieder tot.

@Exiver

Danke, ich teste... :winken:

 

[rv112]

Scheint zu klappen oder?

 

[quietsche]

Scheint zu klappen oder?

Sieht gut aus.

 

[rv112]

Habe das nun mit meinen zweiten TC4400 zum testen gemacht. Der OFDM Kanal ist noch immer da, aber ich kann zumindest wieder pingen. Teste nun gleich mein provisioniertes Modem.

 

[Exiver]

Die Ausgabe sagt ja bei smnpgetnext "Integer: 1". Das ist also D3 only. Wenn du dann einen Wert setzen willst (z.b. die 2 wie in der nächsten Zeile deiner Konsole) musst du snmpset nutzen. snmpgetnext holt natürlich nur die Werte, set setzt sie ;-)
Die Frage ist ja aber eh: Willst du Wert 1 oder willst du Wert 2. Dementsprechend musst du beim snmpset am Ende des Befehls mit dem "i 2" herumspielen (z.B. "i 1")

 

[rv112]

Achso. Aber wenn 1 gesetzt ist, wieso nutzt er dann D3.1? Wenn ich 2 setzen will kommt:

 

[nts]

snmpset -v2c -c public 192.168.100.1 1.3.6.1.4.1.46366.4292.77.1.307.0 i 2

.0 vergessen :winken:

 

[rv112]

Die .0 war das Problem! OFDM Kanal ist weg.

 

[nts]

Achja, falls du ein Modem mit neuerer Firmware hast, könntest du auch gleich mal ausprobieren, ob das folgende Objekt vorhanden und schreibbar ist. Zumindest mit der .20 funktioniert es noch nicht:

<i>
</i>-- 1.3.6.1.4.1.46366.4292.77.1.93
tchCmDocsis31OfdmCapable OBJECT-TYPE
SYNTAX INTEGER
MAX-ACCESS read-write
STATUS current
DESCRIPTION "0 : false, Disable OFDM capability (force D3.1 CM to register as a D3.0 CM). 1: true, Enable OFDM capability. "
DEFVAL { 1 }
::= { tchCMMib 93 }

 

[Exiver]

Achja, falls du ein Modem mit neuerer Firmware hast, könntest du auch gleich mal ausprobieren, ob das folgende Objekt vorhanden und schreibbar ist. Zumindest mit der .20 funktioniert es noch nicht:

<i>
</i>-- 1.3.6.1.4.1.46366.4292.77.1.93
tchCmDocsis31OfdmCapable OBJECT-TYPE
SYNTAX INTEGER
MAX-ACCESS read-write
STATUS current
DESCRIPTION "0 : false, Disable OFDM capability (force D3.1 CM to register as a D3.0 CM). 1: true, Enable OFDM capability. "
DEFVAL { 1 }
::= { tchCMMib 93 }

Hab die SR70.12.40-180627 auf meinem TC4400. Werde es heute abend mal ausprobieren.

 

[tobsen]

Die .0 war das Problem! OFDM Kanal ist weg.

Kannst du mal bitte testen, ob das dauerhaft gespeichert wird oder ob das bei jedem reboot/resync gemacht werden muss?
Ansonsten müsste man sich ein kleines Script bauen, welches prüft ob das Modem rebootet/resynct hat und dann entsprechend einmal den snmp drüber bügelt :hammer:

 

[rv112]

Es funktioniert! Ich wäre dafür dass wir das irgendwo festhalten:

TC4400 OFDM Kanal deaktivieren

Mit .33 Labor und der .20 Firmware! Problem war jetzt nur noch dass ich mit dem Ubuntu PC das gemacht habe und danach ja meine pfSense damit benutzen möchte. Folgender Ablauf:

1. Modem ausschalten.
2. Coaxkabel abziehen.
3. Client mit Ubuntu inkl. SNMP Paket anschließen.
4. Modem einschalten und kurz warten.
5. Terminal auf Ubuntu starten und folgendes eingeben: snmpset -v2c -c public 192.168.100.1 1.3.6.1.4.1.46366.4292.77.1.307.0 i 2
6. Client mit Ubuntu abstecken und Router/Zielclient anschließen
7. Coaxkabel anstecken und freuen.

Hinweis: sobald das Coaxkabel angesteckt wurde, verbindet das Modem (DS blinkt, dann US, dann Online). Bei Online bleibt es knapp eine Minute hängen und startet danach neu mit DS. Nun kann DS bis zu 5 Minuten blinken, also geduldig warten.

 

[rv112]

Die .0 war das Problem! OFDM Kanal ist weg.

Kannst du mal bitte testen, ob das dauerhaft gespeichert wird oder ob das bei jedem reboot/resync gemacht werden muss?
Ansonsten müsste man sich ein kleines Script bauen, welches prüft ob das Modem rebootet/resynct hat und dann entsprechend einmal den snmp drüber bügelt :hammer:

Auch nach einem Neustart bleibt der Wert (2) gesetzt und der OFDM Kanal verschwunden! Ich werde mein Zweitmodem nun jedoch mit (1) als weiteres Interface mitlaufen lassen und überwachen wann der OFDM Kanal sauber wird. Eventuell wird das ja auch heute noch was. Für die Zukunft aber interessant.

Achja: danke für die Hilfe! Mal wieder zeigt sich was eine gute Community erreichen kann :winken:

 

[rv112]

Hm Problem ist jetzt nur dass ich für beide Modems die 192.168.100.1 IP habe. Ich habe das "Testmodem" jetzt an ein eigenes Interface in der pfSense gebunden und dem Interface die 192.168.100.100 gegeben. Das Interface erreiche ich, aber mit der 192.168.100.1 komme ich nur auf mein Hauptmodem. Steh ich auf dem Schlauch oder kann es so nicht gehen?

 

[Exiver]

Du könntest z.B. eine DST-Nat Regel festlegen, die bei Zieladresse 10.99.99.1 auf Interface A, IP 192.168.0.1 und bei Zieladresse 10.99.98.1 auf Interface B, IP 192.168.0.1 verbindet. Ob das mit pfsense sauber läuft kann ich nicht beurteilen. Bei Mikrotik-Routern ist es so jedoch möglich.

 

[Andreas1969]

Auch nach einem Neustart bleibt der Wert (2) gesetzt und der OFDM Kanal verschwunden!

Super Arbeit :super:
Hätte nicht gedacht, dass das klappt.

 

[Andreas1969]

Mit .33 Labor und der .33 Final Firmware!

Du meinst die .33 Labor und der .40 Final Firmware! :kratz:

 

[rv112]

Du könntest z.B. eine DST-Nat Regel festlegen, die bei Zieladresse 10.99.99.1 auf Interface A, IP 192.168.0.1 und bei Zieladresse 10.99.98.1 auf Interface B, IP 192.168.0.1 verbindet. Ob das mit pfsense sauber läuft kann ich nicht beurteilen. Bei Mikrotik-Routern ist es so jedoch möglich.

Stimmt, wäre gegangen. Habe es nun einfach mit einer statischen Route auf die 10er IP gelöst Läuft nun!

@Andreas

Ups sorry, ich bin total verwirrt. Meinte die .20 und die Labor.

 

[tobsen]

Es funktioniert! Ich wäre dafür dass wir das irgendwo festhalten:

TC4400 OFDM Kanal deaktivieren

Mit .33 Labor und der .20 Firmware! Problem war jetzt nur noch dass ich mit dem Ubuntu PC das gemacht habe und danach ja meine pfSense damit benutzen möchte. Folgender Ablauf:

1. Modem ausschalten.
2. Coaxkabel abziehen.
3. Client mit Ubuntu inkl. SNMP Paket anschließen.
4. Modem einschalten und kurz warten.
5. Terminal auf Ubuntu starten und folgendes eingeben: snmpset -v2c -c public 192.168.100.1 1.3.6.1.4.1.46366.4292.77.1.307.0 i 2
6. Client mit Ubuntu abstecken und Router/Zielclient anschließen
7. Coaxkabel anstecken und freuen.

ich könnte das in meinen DOCSIS-File mit aufnehmen und direkt beim FW-Update setzen... dann wäre der OFDM von haus aus erstmal deaktiviert. Aktivieren könnte man ihn dann ja immer noch händisch :kratz: :hammer:

 

[Andreas1969]

ich könnte das in meinen DOCSIS-File mit aufnehmen und direkt beim FW-Update setzen... dann wäre der OFDM von haus aus erstmal deaktiviert.

Macht Sinn, zumindest für den Zeitraum, bis Docsis 3.1 mal irgendwann flächendeckend und stabil ausgerollt ist.

 

[rv112]

Würde ich fast vorschlagen.

 

[sch4kal]

Außer bei den Vodafonern

 

[rv112]

Was ist bei den Vodafonern? Der OFDM Kanal ist glaube ich nicht "gestört" sondern am CMTS nicht sauber deaktivert, oder zwar da, überträgt aber noch nichts. Ich werde das versuchen über meine Kanäle so zu kommunizieren mit dem Hinweis dass es Kunden mit D3.1 Hardware bereits im Netz gibt.

 

[Andreas1969]

Was ist bei den Vodafonern?

Er meint, dass ein VF Kunde mit TC4400 den Workaround nicht braucht, da Docsis3.1 dort im Netz sauber läuft. :zwinker: