Unitymedia Technicolor TC4400 Docsis 3.1 Modem Info Thread

[__QT__]

Das Aus- und Einschalten muss man von einem Host intern (zB Router, RaspberryPi, oder ähnliches) starten und gleich als 1 Befehl

$ steckdose_aus && sleep 10s && steckdose_ein

Ob es geht, sollte man vorher aber intern testen. Hab ich aber schon erfolgreich mit "ifdown eth0 && ifup eth0" gemacht. Mut zum Risiko

 

[Ool3eiV3aetooChu]

Und wie willst'n die von ausserhalb wieder einschalten

per "reboot" command z.B.

 

[Red-Bull]

Also ich bin z.Zt echt weit von zu Hause entfernt... wäre fatal wenn das Modem nach "Restore Default Settings" nicht wieder hoch kommt..
KAnn es jm testen der quasi vor Ort ist und ggf. bei sich dann sowas gefahrlos mal testen kann?

 

[guenna]

Ich versuche derzeit von Office Internet 400 auf Company Internet 1000/60 zu wechseln, bekomme da aber von VF die Auskunft, dass bei Company Internet grundsätzlich keine Kundengeräte benutzt werden können. Bei der Umstellung will ich vom vorhandenen HITRON auf eine TC4400 umsteigen.

Da von der gleichen Stelle die merkwürdige Auskunft kommt "Dual-Stack mit statischer IP4/IP6 kann nicht gebucht werden. Lediglich dynamisch. Statisch ist immer IPV4.", bin ich mir nicht sicher ob die Auskunft fundiert ist.

 

[Andreas1969]

Ich versuche derzeit von Office Internet 400 auf Company Internet 1000/60 zu wechseln, bekomme da aber von VF die Auskunft, dass bei Company Internet grundsätzlich keine Kundengeräte benutzt werden können. Bei der Umstellung will ich vom vorhandenen HITRON auf eine TC4400 umsteigen.

Da von der gleichen Stelle die merkwürdige Auskunft kommt "Dual-Stack mit statischer IP4/IP6 kann nicht gebucht werden. Lediglich dynamisch. Statisch ist immer IPV4.", bin ich mir nicht sicher ob die Auskunft fundiert ist.

Die Auskunft ist leider korrekt!

 

[guenna]

Die Auskunft ist leider korrekt!

Dann bleibe ich wohl doch besser beim Office Internet 400 mit dem HITRON Modem. Eine Fritte will ich hier nicht in der Anlage haben. Schade, hätte halt gerne etwas mehr Upstream gehabt.

Ist denn die zweite Aussage auch korrekt ?

Macht es denn dann irgendeinen Sinn das HITRON durch eine TC4400 zu ersetzen ? Sonst geht die erst einmal ins Regal für später.

 

[Andreas1969]

Ist denn die zweite Aussage auch korrekt

Ja

 

[guenna]

Ja

Ist das denn bei Office Internet auch so, wenn man Dual-Stack aktivieren möchte ? Geht dann auch die statische IP4 verloren ?

 

[Tom_123]

Hi,

auch diese Antwort ist korrekt. Statische IP gibt's nur mit Providergeräte und leider kein statisches Dual Stack, sondern nur dynamisch :/

 

[MichaelBre]

Wobei sich die IPv4 und auch das IPv6 Präfix so gut wie nie ändert...
Ich habe zumindest seit Wechsel auf einen Unitymedia Office Internet & Phone und auch jetzt zu Vodafone Business CableMax noch keine anderen erhalten.

 

[guenna]

Wobei sich die IPv4 und auch das IPv6 Präfix so gut wie nie ändert...
Ich habe zumindest seit Wechsel auf einen Unitymedia Office Internet & Phone und auch jetzt zu Vodafone Business CableMax noch keine anderen erhalten.

Das ist nämlich auch genau meine Frage, ob es mit Dual-Stack nicht auch eine feste IP Addresse geben kann. Mir reicht ja eine IP4 Addresse fürs VPN und ein /30 Subnet mit einer statischen IP brauche ich auch nicht.

 

[MichaelBre]

Offiziell fest ist die nicht, allerdings ändert die sich nicht.

 

[Ool3eiV3aetooChu]

Hm. Seit heute nacht 00:50 kam ich weder über die 192.168.100.1 noch über die management-IP (10.145.xxx.xxx) auf das Webinterface (timeout). Ping auf die 192.168.100.1 ging noch, auf die 10.145.xxx.xxx nicht mehr. Wollte das Modem gerade neu starten, dachte aber, probierst es erstmal noch mit der 192.168.0.1. Und siehe da: Darüber antwortet das Webinterface.
Das Eventlog wurde gespammt mit fec loss und recovery auf dem ofdm, kann also nicht feststellen, was um kurz vor 1 los war. Da mein Modem bisher auf keine anderen Adressen als 192.168.100.1 und die management-IP von Unitymedia reagiert hat – gibt's neben 192.168.0.1 noch andere Kandidaten?

 

[rv112]

Nö, nur die zwei. Vermutlich war der Anschluss down und daher wurdest Du nicht auf die 192.168.100.1 geroutet. Die 192.168.0.1 antwortet auf mit der .41 noch auf ICMP.

 

[Ool3eiV3aetooChu]

Ok, danke. Dann lautet, falls es jemandem hilft, meine haproxy-config nunmehr:

defaults mode http option http-server-close timeout client 60s timeout server 60s timeout connect 4s
frontend tc4400_fe bind 192.168.255.3:80 name tc4400 default_backend tc4400_be
backend tc4400_be server tc_lan1 192.168.100.1:80 check server tc_lan2 192.168.0.1:80 check backup server tc_mgmt 10.145.xxx.xx:80 check backup

 

[Edding]

Hm. Seit heute nacht 00:50 kam ich weder über die 192.168.100.1 noch über die management-IP (10.145.xxx.xxx) auf das Webinterface (timeout). Ping auf die 192.168.100.1 ging noch, auf die 10.145.xxx.xxx nicht mehr. Wollte das Modem gerade neu starten, dachte aber, probierst es erstmal noch mit der 192.168.0.1. Und siehe da: Darüber antwortet das Webinterface.
Das Eventlog wurde gespammt mit fec loss und recovery auf dem ofdm, kann also nicht feststellen, was um kurz vor 1 los war. Da mein Modem bisher auf keine anderen Adressen als 192.168.100.1 und die management-IP von Unitymedia reagiert hat – gibt's neben 192.168.0.1 noch andere Kandidaten?

gab gestern ab 0 Uhr wartunsarbeiten in und um Hanau

 

[millen]

Daran hatte ich ebenfalls gedacht. War ein relativ großes Gebiet.

 

[Mr.Goodcat]

Hier gab es ebenfalls grade Wartungsarbeiten mit ähnlichem Effekt. Vor allem ist die Anzahl der Kanäle von 31+OFDM(86MHz) auf 24+OFDM(86MHz) gesunken Alle Kanäle unter 546MHz sind nun weg. Ich hoffe einfach mal, dass es ein Nodesplit inkl. Vorbereitung für mehr OFDM (Uplink?) war. Die Latenz ist gesunken und liegt nun bei 12-13ms zu Googles DNS - werden Remote Phys oder ähnliche Topologien ausgerollt?

 

[why_]

Ich hoffe einfach mal, dass es ein Nodesplit inkl. Vorbereitung für mehr OFDM (Uplink?) war.

in der Region gibt es mit Sicherheit keinen OFDM Uplink bzw. Uplink überhaupt, außer du hast FTTB wovon ich mal nicht ausgehe.

 

[millen]

Hier gab es ebenfalls grade Wartungsarbeiten mit ähnlichem Effekt. Vor allem ist die Anzahl der Kanäle von 31+OFDM(86MHz) auf 24+OFDM(86MHz) gesunken Alle Kanäle unter 546MHz sind nun weg. Ich hoffe einfach mal, dass es ein Nodesplit inkl. Vorbereitung für mehr OFDM (Uplink?) war. Die Latenz ist gesunken und liegt nun bei 12-13ms zu Googles DNS - werden Remote Phys oder ähnliche Topologien ausgerollt?

Exakt so ist es bei mir auch gewesen Anfang Juli, bei uns wurde auch gesplittet und alle Kanäle unterhalb 546 MHz sind weggefallen. Dann ist dein Segment wohl genauso wie meins, an eine neue CMTS gehängt worden, die nur noch 24 DS Kanäle hat. Die andere hälfte des alten Segments wird bei dir wahrscheinlich, genauso wie bei mir, weiterhin an der CMTS hängen mit den 31 Kanälen.

Wie sehen denn deine SNR Werte jetzt aus? Meine sind seitdem alle auf -39 db bis 40,4 db.

 

[Mr.Goodcat]

Beim SNR hat sich nicht zuviel getan. Meist +0,5 bis +1dB auf ~38dB. Der OFDM wirft noch immer Fehler die nicht durch FEC abgefangen werden.

 

[MartinP_Do]

Beim SNR hat sich nicht zuviel getan. Meist +0,5 bis +1dB auf ~38dB. Der OFDM wirft noch immer Fehler die nicht durch FEC abgefangen werden.

Merkwürdig - die -38 dB in den DOCSIS 3.0 Kanälen sind ja eigentlich perfekt .... Wie sehen den SNR und Pegel im OFDM aus?

 

[rv112]

Einen OFDM ohne korrigierbare Fehler will man doch gar nicht. Ist ja ähnlich wie Vectoring wo man gezielt "Fehler" auf die Leitung wirft um diese dann am CPE wieder filtern zu lassen und dadurch von "schlechten Fehlern" zu unterscheiden. Ich meine mal einen alten Cisco Beitrag zu DOCSIS3.1 gehört zu haben, bei dem das so geschildert wurde.

 

[Mr.Goodcat]

Merkwürdig - die -38 dB in den DOCSIS 3.0 Kanälen sind ja eigentlich perfekt .... Wie sehen den SNR und Pegel im OFDM aus?

-3.8 dBmV bei 30,5dB SNR. Zumindest bricht die Verbindung nicht mehr alle paar Sekunden ganz runter. Bisher gab es soviele Fehler, dass das TC4400 ständig das OFDM Profil wechselte und TCP gar nicht mehr klar kam. Richtig sauber wird das wohl erst wenn die mal den Abzweiger austauschen - was schon vor Monaten geplant war.

Einen OFDM ohne korrigierbare Fehler will man doch gar nicht. Ist ja ähnlich wie Vectoring wo man gezielt "Fehler" auf die Leitung wirft um diese dann am CPE wieder filtern zu lassen und dadurch von "schlechten Fehlern" zu unterscheiden. Ich meine mal einen alten Cisco Beitrag zu DOCSIS3.1 gehört zu haben, bei dem das so geschildert wurde.

Ich sprach von Unkorrigierbaren, also solchen die das FEC nicht mehr kitten kann.

 

[floh667]

beobachte mal wenn möglich den OFDM, ob er spät nachts besser rein kommt. Bei uns ist das nämlich so. Spät nachts liegt der teils bei 34,5db. Nur gegen mittag bis abend fällt er dann auf so 31 - 32,8dB ab.