Unitymedia Arris TM3402B Modem

[addicted]

Ich verstehe nicht warum es im Kabel Netz so kompliziert und eingeschränkt sein muss.

Da Du eben auch durch "Fummelei" am Modem nicht nur Deinen Anschluss stören kannst, sind gewisse Einstellungen eben nur über Umwege oder gar nicht möglich. Es ist eben ein geschlosseneres System und daher reagieren viele Provider auch etwas allergisch auf "freie" Modems / Router.

Von daher ist es nicht "einfach so" komplizierter, sondern hat technische Hintergründe die im Natur des Produktes liegen.

Die technischen Gründe liegen aber keinesfalls in der Störanfälligkeit. Das hast Du Dir nur schöngeredet. Wenn ich ein Kabelnetz stören *will*, dann kaufe ich mir dafür ja keine Fritzbox.

Die technischen Gründe liegen in der Manipulationsanfälligkeit von freien Endgeräten, weil man im Standard nicht bedacht hat, dass man die Dienstequalität auf Seite des CMTS einschränken wollen würde. Beispielsweise wird die maximale Bandbreite an einem Anschluss durch das Modem selbst gesteuert.
Die Hersteller (die letztlich die Standards festlegen) fürchten, dass durch eine Möglichkeit der Firmwareinstallation und freie Verfügbarkeit der Geräte die Betrugsfälle steigen.
Zudem kann man natürlich auf einem Modem keinen WiFiSpot schalten oder Daten über die angeschlossenen Endgeräte erheben.

 

[rv112]

Der letzte Abschnitt dürfte mit der Hauptgrund für unser Problem mit den Providerboxen sein.

 

[.Marcus.]

Ich verstehe nicht warum es im Kabel Netz so kompliziert und eingeschränkt sein muss.

Da Du eben auch durch "Fummelei" am Modem nicht nur Deinen Anschluss stören kannst, sind gewisse Einstellungen eben nur über Umwege oder gar nicht möglich. Es ist eben ein geschlosseneres System und daher reagieren viele Provider auch etwas allergisch auf "freie" Modems / Router.

Von daher ist es nicht "einfach so" komplizierter, sondern hat technische Hintergründe die im Natur des Produktes liegen.

Die technischen Gründe liegen aber keinesfalls in der Störanfälligkeit. Das hast Du Dir nur schöngeredet. Wenn ich ein Kabelnetz stören *will*, dann kaufe ich mir dafür ja keine Fritzbox.

Die technischen Gründe liegen in der Manipulationsanfälligkeit von freien Endgeräten, weil man im Standard nicht bedacht hat, dass man die Dienstequalität auf Seite des CMTS einschränken wollen würde. Beispielsweise wird die maximale Bandbreite an einem Anschluss durch das Modem selbst gesteuert.
Die Hersteller (die letztlich die Standards festlegen) fürchten, dass durch eine Möglichkeit der Firmwareinstallation und freie Verfügbarkeit der Geräte die Betrugsfälle steigen.
Zudem kann man natürlich auf einem Modem keinen WiFiSpot schalten oder Daten über die angeschlossenen Endgeräte erheben.

Dank Dir für Deine Antwort. Noch ein weiter interessanter Aspekt
Ich nehm mal an dass dies durch diese Config ala 'cust-own_400000_40000_ds_sip_wifi-on.bin' welches vom CMTS kommt geregelt wird :hirnbump:
Dass sind natürlich nochmal gute Argumente für die 'Geheimniskrämerei' der ISP und Gerätehersteller

 

[wittmann]

[...]Die technischen Gründe liegen in der Manipulationsanfälligkeit von freien Endgeräten, weil man im Standard nicht bedacht hat, dass man die Dienstequalität auf Seite des CMTS einschränken wollen würde. Beispielsweise wird die maximale Bandbreite an einem Anschluss durch das Modem selbst gesteuert.[...]

Da muss ich dir leider mitteilen, dass das nicht stimmt! Woher kommt so eine Aussage eigentlich? Du sprichst von einem Standard und scheinst ihn nicht gelesen zu haben.

Das Rate-Limit im DS und US wird vom CMTS kontrolliert. Die Rate fuer DS und US wird dem Kabelmodem über das Config File bei der Anmeldung bekannt gegeben. Diese Rate wird dann vom Kabelmodem an das CMTS bei der Registrierung mitgeteilt. Damit ein User diese Werte nicht einfach aendern kann, werden die entsprechenden TLVs durch einen Message Integrity Check (MIC), geschuetzt durch ein "Shared-Secret", versehen. Dieses Shared-Secret ist dem Provisionierungssystem und dem CMTS bekannt. Aendert man das TLV und generiert den MIC neu, ohne Kenntnis des Shared-Secret, weiss das CMTS, dass die Settings nicht valide sind und wird die Registrierung abbrechen.

Wenn in der Vergangenheit, auf manchen Systemen das einfach so funktioniert hat, dann hat der Provider geschlampt, weil er z.B. kein Shared-Secret verwendet (Epic-Fail) hat oder es irgendeinen fiesen Bug gab.

In allen Faellen wird dem CMTS aber das Rate-Limit bei der Registrierung uebergeben und basierend darauf erfolgt das Scheduling/Zuteilung der Durchsatzrate allein durch das CMTS.

 

[rv112]

Das kann man so pauschal aber auch nicht sagen. Je nachdem was am Configfile nicht passt, wird es mit einer Notiz dennoch akzeptiert. Im Modemlog steht dann etwas wie "Config File Rejected due to Invalid or Unexpected TLV".

 

[robert_s]

In allen Faellen wird dem CMTS aber das Rate-Limit bei der Registrierung uebergeben

Wobei die Registrierung bei DOCSIS mir ein schon recht widersprüchliches Konstrukt erscheint, was vielleicht durch historisches Wachstum seit DOCSIS 1.0 so entstanden ist? Jedenfalls ist es widersinnig, das beide Seiten der jeweils anderen Informationen mitteilen, die eigentlich von der anderen Seite stammen: Das CMTS teilt dem Kabelmodem in der Registration Response dessen Fähigkeiten mit (falls es die seit dem Registration Request, wo es die selbst reingeschrieben hat, vergessen haben sollte?), und das Kabelmodem teilt dem CMTS mit, auf welche Geschwindigkeiten es provisioniert ist, was ja umgekehrt das CMTS aus eigener Quelle am besten weiß...

Da könnte man viel Unnützes streichen, eigentlich sogar das config file.

Im Vergleich dazu macht das Training bei DSL doch deutlich mehr Sinn...

 

[wittmann]

[..]Jedenfalls ist es widersinnig, das beide Seiten der jeweils anderen Informationen mitteilen, die eigentlich von der anderen Seite stammen: Das CMTS teilt dem Kabelmodem in der Registration Response dessen Fähigkeiten mit (falls es die seit dem Registration Request, wo es die selbst reingeschrieben hat, vergessen haben sollte?),

Das ist eigentlich gar nicht so widersinning. Die Mitteilung der TLV.5 (Modem Capabilities) und dessen Sub-TLVs dient auch quasi als letzte Moeglichkeit, dass das CMTS dem Kabelmodem Einstellungen mitteilt. Als Beispiel in der DOCSIS 3.1 Welt: Das Kabelmodem teilt dem CMTS in der Registrierungs-Anfrage (REQ-REQ-MP) mit, dass es eine MTU von 2000 unterstuetzt. Wenn das CMTS aber selbst immer noch nur eine MTU von 1500 unterstuetzt, wird es dem Kabelmodem bei der Registrierungs-Antwort (REG-RSP-MP) diese Informationen ueber die selbe TLV mitteilen. Das honoriert das Kabelmodem dann und konfiguriert seine MTU-Settings auf 1500.

und das Kabelmodem teilt dem CMTS mit, auf welche Geschwindigkeiten es provisioniert ist, was ja umgekehrt das CMTS aus eigener Quelle am besten weiß...

Das ist es ja, aus der Historie heraus hat das CMTS keine eigene Quelle fuer die Informationen der Einstellungen*. Zu Beginn waren die CMTS nicht in der Lage, ueber Mittel wie z.B. TFTP-Enforcement oder Dynamic-Shared-Secret den Inhalt der Kabelmodem Config Files zu kennen und sich damit quasi als TFTP-Server-Proxy zwischen eigentlichem TFTP-Server und Kabelmodem zu schalten. Sie haben lediglich den TFTP-Download des Config Files vom TFTP-Server zum Kabelmodem durchgeleitet und nicht gesnooped. Einige dieser Features und noch ein paar andere waren vor DOCSIS 3.0 z.B. propritaere Features von Herstellern und wurden mit DOCSIS 3.0 in der SEC-Spezifikation uebernommen. Eine Anbindung des CMTS z.B. an einen Radius-Server oder eine andere AAA Schnittstelle zur Verifizierung einer MAC Adresse gibt es nicht fuer die Registrierung der Kabelmodems auf einem CMTS. Dafuer gibt es ja das Shared-Secret um die Einstellungen zu validieren.

Da könnte man viel Unnützes streichen, eigentlich sogar das config file.

Im Vergleich dazu macht das Training bei DSL doch deutlich mehr Sinn...

Ja man koennte nach heutigem Massstab so viel anders machen aber Altlasten ziehen sich immer verdammt lange durch, besonders wenn man dann der Rueckwaertskompatibilitaet froehnt.

*Ausser man arbeiten mit Class-Names aber das ist ein anderes Kapitel.

 

[rv112]

Arris hat ganz frisch eine neue Firmware mit der Version 11.2.37.1.5 veröffentlicht. Ob die bestellten Geräte diese schon erhalten ist aber unbekannt.

 

[addicted]

Woher kommt so eine Aussage eigentlich? Du sprichst von einem Standard und scheinst ihn nicht gelesen zu haben.

Natürlich habe ich keine Docsis-Standards gelesen, ich bitte Dich.
Meine Aussage stützt sich darauf, dass es in der Vergangenheit möglich war, sich Leistungen zu erschleichen.

 

[JPDribbler]

Arris hat ganz frisch eine neue Firmware mit der Version 11.2.37.1.5 veröffentlicht. Ob die bestellten Geräte diese schon erhalten ist aber unbekannt.

Gibt es eine Changelog die man veröffentlichen kann?

 

[THX1138]

Arris hat ganz frisch eine neue Firmware mit der Version 11.2.37.1.5 veröffentlicht. Ob die bestellten Geräte diese schon erhalten ist aber unbekannt.

Ich habe eines dieser Modems. Die Firmware ist TS11.01.057.4_101117_70.SIP.03 vom Wed Oct 11 20:00:35 EDT 2017.

BTW: Das Modem hat sich problemlos mit einem CASA CMTS von UM gesynched. Da ich es aber nur als Backup für ein TC4400 nutzen will, habe ich es nicht provisionieren lassen. Ob das ohne Probleme geht, weiss ich also nicht.

 

[rv112]

Danke für die Rückmeldung. Welches Bundesland?

 

[THX1138]

Danke für die Rückmeldung. Welches Bundesland?

NRW

 

[rv112]

Danke!

 

[rv112]

Aktuell sind wieder Arris TM3402B mit neuer Firmware (TS 11.2.37.1.5) lieferbar! :winken:

 

[Soldierofoc]

Hat das Gerät/Modem jemand an einem Unifi USG (Pro) im Einsatz?
Bin aktuell noch bei der Telekom, würde aber gerne ggf. in Zukunft, da nun bei mir ausgebaut wird, zu UM zurück. Vorraussetzung wäre allerdings, dass ich Dualstack und eben das USG 1:1 wieder so nutzen könnte

 

[rv112]

Ich wüsste nicht was es da für Probleme geben sollte.

 

[Soldierofoc]

Hatte hier nur kurz gelesen dass manche wohl Probleme mit dem TC4400 hätten, deswegen die Nachfrage. Bin aber hier zu lange raus bzw. nicht belesen genug um hier differenzieren zu können.

Und zu guter letzt: Kann man über einen der LAN-Ports 2-4 einen separaten Zugang zum GUI bekommen? Und hier ggf. noch die IP dafür manuell vergeben? Sprich Port 1 an den WAN Port, Port 2 dann zum Management direkt an den Switch/Router.

 

[rv112]

Nein, die Ports sind eine Bridge untereinander auf WAN. Nachdem Du aber nur eine IP bekommen kannst, dürfte das Probleme geben. Aufs GUI kommst Du aber immer über den Uplink zum Modem. Die Modem IP kann nicht geändert werden. Das GUI würde ich über Firewallregeln reglementieren.

 

[Hagbard]

Und zu guter letzt: Kann man über einen der LAN-Ports 2-4 einen separaten Zugang zum GUI bekommen? Und hier ggf. noch die IP dafür manuell vergeben? Sprich Port 1 an den WAN Port, Port 2 dann zum Management direkt an den Switch/Router.

Ja, die 4 Ports arbeiten als Bridge. Aber aus meiner Sicht können diese wie von Dir angedacht benutzt werden.
Port 1 geht dann zum USG, welches wiederum eine IP per DHCP bzw. DHCPv6 anfragt.
Port 2 kann auf eine Management-Station gehen oder Switch, von wo aus eben kein DHCP Request kommt, sondern was im jeweiligen Management-Segment des Modems (hier: 192.168.100.0/24) hängt. Das Modem reagiert auf ungetaggte IP Pakete mit der Destination 192.168.100.1 und beantwortet daher die ARP Requests mit der MAC-Adresse. Es muss jedoch im selben Segment liegen. Auf dem Modem ist, soweit mir bekannt, kein Default-GW gesetzt, falls die Anfragen aus einem anderen Segment kommen.

Soviel zur Theorie. Inwiefern das Modem hier im praktischen Ansatz mitspielt oder Probleme hat, muss die Praxis zeigen bzw. können die beantworten, die das Gerät produktiv im Einsatz haben.

 

[rv112]

Ich weiß nicht ob das Modem auf die Anfrage reagieren wird an einem zweiten Port ohne IP. Wenn ich die Zeit finde, teste ich es mal aus.

 

[shortie]

Hallo zusammen,

habe einen zweiten U-Anschluss mit einer 6490, kann ich das Arris daran anschlissen, ohne mit UM in Kontakt zu treten? Oder wie soll ich den Post auf Seite 1 verstehen.

Danke,
shortie

 

[sch4kal]

Ich weiß nicht ob das Modem auf die Anfrage reagieren wird an einem zweiten Port ohne IP. Wenn ich die Zeit finde, teste ich es mal aus.

Beim TC4400 geht das.

 

[rv112]

Hallo zusammen,

habe einen zweiten U-Anschluss mit einer 6490, kann ich das Arris daran anschlissen, ohne mit UM in Kontakt zu treten? Oder wie soll ich den Post auf Seite 1 verstehen.

Danke,
shortie

Ja kannst Du. Es wird aber nur eine IPv4 durchgereicht.

 

[Andreas1969]

Ja kannst Du. Es wird aber nur eine IPv4 durchgereicht.

Er muss doch das Arris provisionieren lassen, wenn er die 6490 damit ersetzen will :winken:
Schau aber vorher in der 6490 nach, an was für einem CMTS Du hängst. Sollte es ein Casa sein, würde ich da erst mal die Finger von lassen und die 6490 weiter betreiben.