Unitymedia Technicolor TC4400 Docsis 3.1 Modem Info Thread

[umffm]

An dieser Stelle möchte ich mich kurz bedanken.

Dank der Infos hier im Thread habe ich nun neben dem Cisco Nachfolger TC4400 auch einen neuen Tarif 400/40 seit heute Abend. (Kündigung, Anruf, "Telekom"-Pistole -> flutsch 29,99 für 24Monate)

Ich erhalte scheinbar auch in den Abendstunden (20-21 Uhr) problemlos die volle Bandbreite, wie ihr im Bildchen unten sehen könnt. Die Modemwerte sind wohl nicht toll, es waren vor dem Reset wg Tarifumstellung schon erhblich viele unkorrigierbare Fehler.

Hier ein Bild nach einer Stunde im neuen Tarif:



Bei diesem Ping Ergebniss, kann es auch nicht soo schlimm sein mit den Modemwerten, oder?

 

[wittmann]

Zweifelst Du jetzt gerade gelebte Technik (DVB-C, FEC RS 204/188) von ueber 25 Jahren an? Wenn von 34079 Codewords in der Sekunde 1500 korrigiert werden mussten und die FEC keine unkorrigierbaren Codewords meldet, dann hat das keinen Einfluss auf den Inhalt des uebertragenen MPEG-Transportstrom, weil alle Pakete fehlerfrei an die hoehere Instanz uebergeben worden sind.

Also, wenn die Anzahl der korrigierbaren Fehler völlig Hupe ist, dann frage ich mich immer noch, wo an meinem Anschluss diese hohen Latenzsprünge herrühren :kratz:

Kann man schwer sagen, nur die korrigierbaren Fehler sind es nicht.

@umffm:

Also bei den Pegel- und MER-Werten (>38/39 dB) sind die korrigierbaren Codewords schon komisch. Also wie schon geschrieben, haben diese korrigierbaren Codewords keinen Einfluss auf den Durchsatz aber sie sollten dem Operator dazu veranlassen, mal einen vernuenftigen Blick auf den Uebertragungspfad (Optik) werfen zu lassen.

 

[Menano]

Hallo Menano,

wie hast Du denn die Werte am HÜP gemessen? Hast Du das Kabel vom In-Eingang des Verstärkers abgemacht und dieses dann direkt ans Modem angeschlossen, oder hattest Du zufällig das Modem über die MP-IN-Buchse am Verstärker angeschlossen welche ja mit 20 db bedämpft ist?

Testweise könntest Du den Interstage Slope Stecker (grau) ganz oben rechts von jetzt 0db auf 7db umstecken!

Anstatt deiner jetzt verbauten MM-Dose mit 15db würde ich dir dann aber eher eine 10er oder 12er Dose empfehlen! Leider bräuchtest Du dann auch einen anderen Dämpfungspad für den Rückweg von derzeit 12db auf empfehlenswerte 20db, dein Powerlevel im Upload wäre dann bei ca. 41-43.
Deine Powerlevel-Pegel im Download sollten damit dann theoretisch bei + 3 bis + 7db liegen, hoffe ich doch mal. Und der SNR auf 770MHz auch etwas höher. Leider ist er am HÜP schon ziemlich niedrig.

Schau doch einfach mal ob sich was an den Werten ändert. Schlimmer wirds kaum. Und kannst es ja auch wieder zurückstecken. Würde mich wirklich interessieen dein Ergebnis.

Hall UHeinz13,

die Werte am HÜP habe ich gemessen indem ich das Kabel was normalerweise vom galvanischen Trennglied in den Verstärker geht direkt ins Modem gesteckt habe.

Ich habe nun mal wie du beschrieben hast den Interstage Slope Stecker auf -7dB gesteckt!

Alles andere habe ich mal nicht verändert da ich gerade weder eine MMD noch ein Dämpfungspad da habe. MMD könnte ich mir ja besorgen. Wo ich die Dämpfungspads herbekomme wüsste ich nicht.

Durch diese kleine Veränderung haben sich die Modemwerte nun auf folgende geändert:



Was hältst du von den Werten? Sind schonmal ein ordentliches Stück besser oder? Was könnte ich noch machen um die Werte weiter zu verbessern?

Danke für deine Hilfe! :super:

 

[UHeinz13]

Ja die Werte sind besser geworden vor allem ja im oberen Frequenzbereich wo wir es brauchen. Super das freut mich Wie gesagt mit dem Ersetzen der Dose durch z.B. eine 10dB MM-Dose würde das ganze noch besser werden. Dann noch ein Dämpfungspad für den Rückweg mit 18 db oder 20db und alles wäre im grünen Bereich.

Das jetzt noch auf dem Rückweg gesteckte 12db Dämpfungspad (welches Du ja mit dem 18er oder 20er ersetzt) kannst Du dann noch testweise dorthin setzen wo jetzt das 9dB Entzerrerpad(oben links) sitzt. Damit sollen die Pegel noch gerader werden.

Achso Dämpfungspads kriegst übers Intenet. z.B. hier:

https://www.elektronetshop.de/product/astro-strobel-daempfungsglied-lang-521583-typ-pads-18-db-lang.65125.html?p=16&gclid=Cj0KCQiAxs3gBRDGARIsAO4tqq0ua2Q6D9ZO40Pb-DY7nUw7B1mGBUGsAo1qgkcpTdhoAUMJsF1UyvAaAuVXEALw_wcB
https://www.elektronetshop.de/product/astro-strobel-daempfungsglied-lang-521603-typ-pads-20-db-lang.65132.html

Hoffe der Link ist erlaubt, wenn nicht einfach löschen.

 

[rv112]

Wieso den Rückweg dämpfen? Der sieht mit den 38-40dBmV doch gut aus oder?

 

[shm0]

Keine Ahnung...
Unter 45 bekomm ich keinen stabilen Upload hin...

Hat sonst wer das Problem, das die lan ports am tc4400 nach einer gewissen Zeit auf 100mbit/s runter schalten?

 

[UHeinz13]

Wenn Menano seine MM-Dose von jetzt ner 15er auf ne 10er tauscht muss er den Dämpfungspad im Verstärker um ca. 5-6db erhöhen. Sonst wäre sein Sendepegel bei nur noch 33-35. Versteht ihr wie ich meine.

 

[rv112]

Ach so, ja klar so rum wird ein Schuh draus

@shm0

Ja, hatte ich bei einem TC4400 auch mal! Meine anderen machen das jedoch nicht. Hast Du ein .20 FW Modem?

 

[Andreas1969]

Ich erhalte scheinbar auch in den Abendstunden (20-21 Uhr) problemlos die volle Bandbreite, wie ihr im Bildchen unten sehen könnt.

Kein Wunder, bei Dir ist ja auch schon Docsis3.1 aufgeschaltet :zwinker:

 

[shm0]

Ach so, ja klar so rum wird ein Schuh draus

@shm0

Ja, hatte ich bei einem TC4400 auch mal! Meine anderen machen das jedoch nicht. Hast Du ein .20 FW Modem?

FW ist die 70.12.40-180627

Hab mal das Kabel gewechselt :kratz:

 

[Menano]

Die Dämpfungspads sind mir wegen den Versandkosten zu teuer. Dann muss das ganze wohl so bleiben. Irgendwie finde ich es traurig dass hier einer ausm Forum per Ferndiagnose mehr erreichen konnte als 5-6 Techniker wo vor Ort waren die letzten Monate. :hammer:

 

[UHeinz13]

Kriegst nicht eventuell noch ne Multimediadose über den Shop? Dann wäre das Verhältnis mit den Versandkosten nicht mehr so groß!

Ansonsten lässt es jetzt wie gesagt einfach mal laufen, sollten jetzt weniger Fehler auftreten hoffe ich mal.

 

[umffm]

Ich erhalte scheinbar auch in den Abendstunden (20-21 Uhr) problemlos die volle Bandbreite, wie ihr im Bildchen unten sehen könnt.

Kein Wunder, bei Dir ist ja auch schon Docsis3.1 aufgeschaltet :zwinker:

Heißt das, ich profitiere davon auch ohne den 1000er Tarif zu haben? (sorry Laien Frage)

 

[umffm]

- Gibt es etwas einzustellen am Modem ? Welche Einstellungen muss ich am Router vornehmen ?
(Ich habe dem USG die IP 192.168.100.2 gegeben und als Router dort 192.168.100.1 eingetragen)

Sers,
nix einstellen am WAN-Port, auf DHCP lassen, dann bekommst ne IP und damit Internet.

Am Modem ist zwar nichts einzustellen, aber ich habe zwei offene Ports zum Internet mit einem Port Scanner festgestellt.


Erst mit folgender Rule in meiner pfsense Firewall war alles dicht:

 

[rv112]

Was hast Du denn für Rules auf dem WAN Interface? Normal ist alles dicht außer das was Du frei gibst.

 

[umffm]

Was hast Du denn für Rules auf dem WAN Interface? Normal ist alles dicht außer das was Du frei gibst.

Eigentlich ja. WAN Rules könnte doch auch leer sein und dann wäre die hardcoded Rule "DENY All" aktiv und es sollte keinen offenen Ports geben. So verstehe ich das. Aber warum erhalt ich dann offene Ports angezeigt? Ich hab nur folgendes erlaubt:

Die geschwärzten Sachen sind zwei andere offene Ports (VPN..) und zwei Blocks von IPs, die sich nicht mehr auf dem VPN verbinden dürfen. Dh alles Sachen, die nicht zu den offenen 8080 und 8081 führen.

 

[rv112]

Weil Du ja mit einem Portscan von LAN auf WAN zugreifst und die Firewall das durchlässt. Port 80 oder 443 machst Du ja auch nicht auf und kommst dennoch auf diese Seite hier

 

[umffm]

Weil Du ja mit einem Portscan von LAN auf WAN zugreifst und die Firewall das durchlässt. Port 80 oder 443 machst Du ja auch nicht auf und kommst dennoch auf diese Seite hier

Nein ich hab den Portscan vom Internet verwendet. Ich habe testweise ein leeres Ruleset auf WAN ausprobiert und nur 8080 und 8081 sind offen!

 

[rv112]

8080 ist das GUI. 8081 Alternativport. Vielleicht hast Du hier was offen? Ansonsten darf da nix auf sein. Ein Portforward hast Du nicht?

 

[tobsen]

Irgendwie finde ich es traurig dass hier einer ausm Forum per Ferndiagnose mehr erreichen konnte als 5-6 Techniker wo vor Ort waren

Also ich will jetzt hier nicht irgendwas in den Himmel loben aber das Schwarmwissen hier ist schon echt feeeett. :super: :hammer:
Mich würde ja mal interessieren, ob UM hier still und heimlich mitliest und das Fachwissen hier absaugt

Die Dämpfungspads sind mir wegen den Versandkosten zu teuer.

Ich schaue später mal in meiner Kramkiste, ob ich in der Firma noch Dämpfungspads liegen habe und ob die passen. Dann könnte man da irgendwas mit nem kleinen Briefumschlag/Versandtasche regeln :winken:

 

[Menano]

Kriegst nicht eventuell noch ne Multimediadose über den Shop? Dann wäre das Verhältnis mit den Versandkosten nicht mehr so groß!

Habe auf der Seite keine geeignete MMD gefunden. :traurig:

Ich schaue später mal in meiner Kramkiste, ob ich in der Firma noch Dämpfungspads liegen habe und ob die passen. Dann könnte man da irgendwas mit nem kleinen Briefumschlag/Versandtasche regeln :winken:

Schreib mir dann einfach eine PN. :super:

 

[Shimo]

Wenn ich meinen Rechner direkt am Ethernetport (1 oder 2) des TC4400 Modems anschließe, erhalte ich "volle" Geschwindigkeit (up- und download).

Wenn ich meinen Router (Turris Omnia) dazwischenhänge geht die Geschwindigkeit "in den Keller". Mit meinem bisherigen Modem (Cisco EPC3212) gab es dieses Verhalten nicht.

Auf dem Turris Omnia Router habe ich IPv4 DHCP, "kein DHCP hostname" und für IPv6 "deaktiviert" eingestellt. TC4400 hat aktuelle Firmware (SR70.12.40-180627).

Hat jemand eine Idee, was ich einstellen muss, um das TC4400 auch mit Router betreiben zu können? Danke!

Hier in der Gegenüberstellung die eth1 Interface Daten für (a) TC4400 Modem <-> Router und (b) Cisco Modem <-> Router. Kann das Problem an "Link partner advertised pause frame use: Symmetric Receive-only" liegen?

 

[tobsen]

Wenn ich meinen Router (Turris Omnia) dazwischenhänge geht die Geschwindigkeit "in den Keller"

Was bedeutet das in Zahlen "in den keller"?

Was hast du denn für einen Tarif?
Hast du DS-Lite oder Dual-Stack?
Wie misst du die Geschwindigkeit? Beide Messungen erfolgen über LAN?
Was hast du alles im Router konfiguriert? QoS, Firewall, Ratelimits?

Rein technisch gesehen, sollte dein Router das packen. Stehen WAN oder LAN Ports evtl noch in irgendeinem eco-Mode, sodass dort nur 100Mbit durch gehen?

 

[rv112]

Wie gesagt, ich hatte das mit einem TC4400 auch. Habe dann auf dem Router den Port fix auf 1000baseT gestellt.

 

[shm0]

Seit ich das Kabel gewechselt habe, ist das Problem bis jetzt (toi toi toi) noch nicht wieder aufgetreten.
Gibt es sowas wie eine minimale Länge für Ethernet kabel? Hab mal gehört unter 1m könnte es zu Problemen kommen...
Hatte vorher ein relativ kurzes Kabel verwendet, 20cm oder so...
Beim TC4400 hätte man auch mal nen ordentliches cat6 Kabel beilegen können und nicht so nen 0185 Standard cat5e Kabel... x)

Auto negation is auch aus, also fest auf 1000BaseT eingestellt.
und ethtool sagt:

 Supported link modes: 1000baseX/Full Supported pause frame use: No Supports auto-negotiation: No Supported FEC modes: Not reported Advertised link modes: 1000baseX/Full

Ka wie da überhaupt nen "Fallback" auf 100BaseT erfolgen kann...
Mysteriös mal wieder... :kratz:

So die kombo tc4400 und openwrt Router läuft eigentlich ganz gut..
Auch mit DualStack, hat direkt alles funktioniert.
Aber so IPv6.... man sollte schon die Privacy Extension nutzen, sonst lässt sich jedes Gerät weltweit eindeutig identifizieren...

Weiß wer was hier passiert?

Sat Dec 15 14:31:40 2018 daemon.notice netifd: wan (2029): udhcpc: sending renew to 10.130.x.x
Sat Dec 15 14:35:26 2018 daemon.notice netifd: wan (2029): udhcpc: sending renew to 10.130.x.x
Sat Dec 15 14:37:18 2018 daemon.notice netifd: wan (2029): udhcpc: sending renew to 10.130.x.x
Sat Dec 15 14:38:14 2018 daemon.notice netifd: wan (2029): udhcpc: sending renew to 0.0.0.0
Sat Dec 15 14:38:14 2018 daemon.notice netifd: wan (2029): udhcpc: lease of 95.222.xx obtained, lease time 3600

Warum antwortet der DHCP Server von UM nicht direkt beim ersten renew request (unicast)?
Sondern erst beim 4. Request der dann nen Broadcast Request ist?
Werd's mal mit "Use broadcast flag" in den wan interface settings probieren, mal gucken...
broadcast flag macht keinen Unterschied