Unitymedia Arris TM3402B Modem

[srxx]

Dafür akzeptiert das VF Portal nicht jedes X-beliebige Gerät :winken:

Nur die fehlerhaften nicht. Da gab es z.B. mal ein Hitron-Kabelmodem, welches im EuroDOCSIS-Modus ein DOCSIS-Zertifikat ablieferte.

Das war aber nicht zufällig das CDA-32372 oder? Funktioniert bei UM nämlich

 

[sch4kal]

Dafür akzeptiert das VF Portal nicht jedes X-beliebige Gerät :winken:

Nur die fehlerhaften nicht. Da gab es z.B. mal ein Hitron-Kabelmodem, welches im EuroDOCSIS-Modus ein DOCSIS-Zertifikat ablieferte. Oder eben das TC4400 mit dem einen Firmware-Release, wo sich ein Tab-Zeichen in die Firmwareversion eingeschlichen hatte. Wer würde auch auf die Idee kommen, so einen Fall vorab zu testen...?

Da ist mir doch die manuelle Freischaltung bei UM trotzt der ganzen Nachteile lieber :winken:

Ja, klar, damit Du im Zweifelsfall auch Deine 7590 bei UM "freischalten" lassen kannst... :super:

Natürlich, VF hat bei dir nie Schuld. Man kann sich seine Welt auch zurecht argumentieren, auch wenn man gegen geltende RFC schießt...

 

[robert_s]

Natürlich, VF hat bei dir nie Schuld. Man kann sich seine Welt auch zurecht argumentieren, auch wenn man gegen geltende RFC schießt...

Es ist doch vielmehr umgekehrt so, dass es hier einige Zeitgenossen gibt, die VF an allem die Schuld geben wollen.

Übrigens war ich es, der sich einst durch die zahlreichen Standardreferenzen hangelte, um am Ende bei besagtem RFC anzukommen, aus dem hervorgeht, dass Steuerzeichen in SNMP Display Strings durchaus zulässig sind, und entsprechend darauf hinwies. Ich weiß nicht, ob sich noch jemand anderes die Mühe gemacht hat, oder die Information von anderen nur weitergereicht wurde. Für fraglich halte ich, ob sich CableLabs dessen bewusst war, als sie auf diesen Standard für DOCSIS aufbauten - denn sie haben eigentlich nur festgelegt, dass der in SNMP vorhandene "sysDescr" Wert für DOCSIS-Kabelmodems eine besondere Anwendung findet.

Meine Sicht der Dinge ist jedenfalls, dass zuerst CableLabs eine in einem Aspekt "überraschende" Spezifikation erstellt hat (was bei der Komplexität schon mal vorkommen kann), dann Technicolor einen Fehler bei der Versionierung der Firmwares gemacht hat (denn darin ein TAB-Zeichen zu verwenden, ergibt keinen Sinn), und das Aktivierungs-Backend von VFKD dann eben davon "überrascht" wurde.

Also wenn Du "Schuldige" suchst, wären das in CableLabs, Technicolor und VFKD. Dann bitte auch alle 3 benennen und nicht behaupten, nur einer wäre Schuld. Denn hätte auch nur einer von den 3 den Fehler nicht gemacht, den er gemacht hat, dann wäre das Problem am Ende nicht aufgetreten. Nur durch alle 3 "Fehlerbeiträge" zusammen war das möglich.

 

[rv112]

Ist ja jetzt auch Wurst. Wir brauchen eine Lösung und die stellt aktuell auch das Arris da. Die Frage ist, ob es auch bei VDF synct und läuft. Bei UM mach ich mir da keine Gedanken.

 

[sch4kal]

Es ist doch vielmehr umgekehrt so, dass es hier einige Zeitgenossen gibt, die VF an allem die Schuld geben wollen.

Weil VF eben auch die Schuld trifft. Wer ein automatisiertes Aktivierungsportal nicht fehlertolerant auslegt, macht etwas falsch.

Übrigens war ich es, der sich einst durch die zahlreichen Standardreferenzen hangelte, um am Ende bei besagtem RFC anzukommen, aus dem hervorgeht, dass Steuerzeichen in SNMP Display Strings durchaus zulässig sind, und entsprechend darauf hinwies. Ich weiß nicht, ob sich noch jemand anderes die Mühe gemacht hat, oder die Information von anderen nur weitergereicht wurde.

Ist das so ? https://www.kdgforum.de/viewtopic.php?f=68&t=38748&start=450#p603064

Für fraglich halte ich, ob sich CableLabs dessen bewusst war, als sie auf diesen Standard für DOCSIS aufbauten - denn sie haben eigentlich nur festgelegt, dass der in SNMP vorhandene "sysDescr" Wert für DOCSIS-Kabelmodems eine besondere Anwendung findet.

Vielleicht bestand die Möglichkeit, dass ein Hersteller vielleicht auch keine alphanumerischen Zeichen darin verwenden wollen würde ?!

Meine Sicht der Dinge ist jedenfalls, dass zuerst CableLabs eine in einem Aspekt "überraschende" Spezifikation erstellt hat (was bei der Komplexität schon mal vorkommen kann), dann Technicolor einen Fehler bei der Versionierung der Firmwares gemacht hat (denn darin ein TAB-Zeichen zu verwenden, ergibt keinen Sinn), und das Aktivierungs-Backend von VFKD dann eben davon "überrascht" wurde.

Ja, man wird natürlich "überrascht" wenn man sich die RFC nicht durchliest oder ignoriert. :brüll:

Also wenn Du "Schuldige" suchst, wären das in CableLabs, Technicolor und VFKD. Dann bitte auch alle 3 benennen und nicht behaupten, nur einer wäre Schuld. Denn hätte auch nur einer von den 3 den Fehler nicht gemacht, den er gemacht hat, dann wäre das Problem am Ende nicht aufgetreten. Nur durch alle 3 "Fehlerbeiträge" zusammen war das möglich.

Komisch, dass es bei UM und PYUR nicht an dem TAB-Zeichen scheiterte :roll:

 

[robert_s]

Übrigens war ich es, der sich einst durch die zahlreichen Standardreferenzen hangelte, um am Ende bei besagtem RFC anzukommen, aus dem hervorgeht, dass Steuerzeichen in SNMP Display Strings durchaus zulässig sind, und entsprechend darauf hinwies. Ich weiß nicht, ob sich noch jemand anderes die Mühe gemacht hat, oder die Information von anderen nur weitergereicht wurde.

Ist das so ? https://www.kdgforum.de/viewtopic.php?f=68&t=38748&start=450#p603064

Ich habe das Ende März 2018 durchexerziert. Wenn Du das im Mai 2018 völlig unabhängig davon gemacht hast, dann weiß ich jetzt, dass ich nicht der einzige war.

Vielleicht bestand die Möglichkeit, dass ein Hersteller vielleicht auch keine alphanumerischen Zeichen darin verwenden wollen würde ?!

Kannst Du drehen und wenden wie Du willst, aber Whitespace-Zeichen in einem Versionsstring ergeben wenig Sinn.

Ja, man wird natürlich "überrascht" wenn man sich die RFC nicht durchliest oder ignoriert. :brüll:

Glaubst Du ernsthaft, man könne noch irgendeine Software in endlicher Zeit entwickeln, indem man sämtliche Standards zu 100% durchliest? Das ist realitätsfern. Man kommt gar nicht mehr drumrum, für viele Dinge auf fertige Libraries aufzubauen, gerade weil man sich nicht mehr mit allen Details befassen kann. Und RFC 854 ist so weit "unten" in der Kette, dass man da nicht leicht drauf stößt.

Komisch, dass es bei UM und PYUR nicht an dem TAB-Zeichen scheiterte :roll:

Ich vermute mal, dass die sich den Versionsstring gar nicht anschauen.

 

[rv112]

Nach guten 12 Stunden, hier ein kleiner Vorgeschmack vom BQM an meinem Anschluss. Beide Modem hängen an der gleichen Dose und dem gleichen Router. Die roten Spikes sind Reconnects, bzw. beim Arris der rote Spike lag an mir, hier habe ich die Firewallrules frisch geladen da mir die DHCP Requests von WAN auf den Zeiger gingen. Diese also bitte nicht beachten. Bei beiden Geräten gab es keinerlei Packetloss. Bitte nur die Nachtzeit von 0-6 Uhr vergleichen, da hier garantiert werden kann, dass beide Leitungen frei von Traffic waren.

TC4400:

TM3402B:

Wie man sieht, nimmt sich das Arris nichts zum TC. Die Connectbox im Haus liefert hier deutlich schlechtere Ergebnise und auch eine Fritzbox im Haus zeigt keine so sauberen Linien. Das Arris ist beim Jitter sogar gefühlt etwas besser. Auf dem Mitschnitt des Routers der etwas nicht so detailliert ist, sind beide Modem auf gleichem Niveau. Für mich heißt das, dass der Puma7 definitiv nicht das Puma6 Problem geerbt hat, zumindest bei diesem Gerät nicht. Ob er wirklich so gut wie der Broadcom ist, kann ich jedoch so noch nicht sagen.

 

[Andreas1969]

Abwarten, wir wissen noch nicht, wie sich das Arris am VF Portal verhält, bzw. ob es sich überhaupt aktivieren lässt.
In Bezug auf die Übernahme ist es eigentlich der wichtigste Punkt, ansonsten ist es wertloser Elektroschrott :streber:

 

[rv112]

Na ob die Übernahme überhaupt stattfindet, steht in den Sternen. Und selbst wenn, denke ich dass sich so schnell erst mal gar nichts ändert. Bevor die Leute nun also verzweifelt ein altes Cisco kaufen, wären sie mit dem Arris erst mal gut bedient.

 

[Andreas1969]

Und selbst wenn, denke ich dass sich so schnell erst mal gar nichts ändert.

Nein, gerade der Punkt mit dem Portal wird eines der ersten Dinge sein, die VF nach der Übernahme recht zügig umsetzten wird, da die Provisionierung bei UM verdammt Personalintensiv ist :streber:
Das wird VF sofort einstellen wollen, um Kosten einzusparen.

 

[Andreas1969]

Bisher gibt es bei VF ja nur 2 Positivmeldungen:

- Die Kabelfritten
- TC4400 mit der 33er Labor und der 40er Final

Die 40er Final läuft allerdings etwas wackelig, weshalb ich die 33er Labor momentan bevorzugen würde.

 

[rv112]

Bei UM wird die Provisionierung in BW nach wie vor über das KabelBW System durchgeführt, so viel dazu. Was genau da der Unterschied ist, weiß ich nicht. Aber es gibt ihn. Das ist auch der Grund warum man immer nach dem Bundesland gefragt wird. Übrigens darf 1 Jahr lang nach der Übernahme am Unternehmen keine Personaländerung durchgeführt werden laut Gesetzt.

BTT:

Die 4 Ports am Modem haben übrigens alle die gleiche MAC, sie sind also eine harte Bridge sozusagen. Mit LAG gibt es keine Probleme.

 

[Andreas1969]

Übrigens darf 1 Jahr lang nach der Übernahme am Unternehmen keine Personaländerung durchgeführt werden laut Gesetzt.

Das heißt aber nicht, dass die nicht mehr benötigten MA aus der Provisionierungsabteilung nicht auch in einem anderen Bereich eingesetzt werden dürfen, wo vielleicht gerade ein Engpass besteht. :winken:

Auch wenn es noch 1 Jahr so weiterläuft, es wird wohl niemand Bock darauf haben, sein Arris nach 1 Jahr in die Tonne zu werfen.
Das sollte man schon im Voraus abchecken.

 

[Wechseler]

Kannst Du drehen und wenden wie Du willst, aber Whitespace-Zeichen in einem Versionsstring ergeben wenig Sinn.

Der "Versionsstring" ist "druckbar". Deshalb sind dort alle Zeichen erlaubt, die ein Drucker auch versteht. Foren können solche Zeichen übrigens auch interpretieren, wenn man sie in code-Tags einklammert. Das hier ist eine perfekt valide sysDescr:

<i>
</i>Hersteller:	Technicolor
Modell:	TC4400
Firmwarestand:	1234
Standard	Downstream-Kanaele	Upstream-Kanaele	Anmerkungen
EuroDOCSIS 3.0	32	8	keine Kompatibilität zu DOCSIS 3.0 oder EuroDOCSIS 1.0-2.0
DOCSIS 3.1	2	2

Inklusive Zeilenumbrüchen, Tabzeichen, Sonderzeichen und allem. Es ist ein Freitextfeld und nicht mal die Sprache ist vorgeschrieben!

Komisch, dass es bei UM und PYUR nicht an dem TAB-Zeichen scheiterte :roll:

Ich vermute mal, dass die sich den Versionsstring gar nicht anschauen.

Bei UM nicht, bei TC scheitert es daran, daß deren Portal das Gerät hinter einem echten Bridge-Modem erkennt (das "CPE", z.B. der angeschlossene OpenWrt-Router) und dann das zugehörige Kabelmodem dazu nicht findet. Da hat man sich wohl einen Hack gebastelt, der nur mit Fritzboxen funktioniert (z. B. irgendwelches Herleiten der CM-MAC aus CPE-MAC-Adresse).

 

[robert_s]

Der "Versionsstring" ist "druckbar". Deshalb sind dort alle Zeichen erlaubt, die ein Drucker auch versteht. Foren können solche Zeichen übrigens auch interpretieren, wenn man sie in code-Tags einklammert. Das hier ist eine perfekt valide sysDescr:

Nicht nach DOCSIS-Standard:

The CM MUST report each Type and Value for the sysDescr object identified in Table 30, with each Type field and corresponding Value field separated with a colon followed by a single blank space and each Type-Value pair is
separated by a semicolon followed by a single blank space. The correct format is illustrated below.

<i>
</i>HW_REV: <value>; VENDOR: <value>; BOOTR: <value>; SW_REV: <value>; MODEL: <value>

Offensichtlich darf ein "value" auch kein Semikolon enthalten. Jetzt erkläre mal bitte, wie das im Einklang mit RFC 854 stehen soll!

 

[sch4kal]

Der "Versionsstring" ist "druckbar". Deshalb sind dort alle Zeichen erlaubt, die ein Drucker auch versteht. Foren können solche Zeichen übrigens auch interpretieren, wenn man sie in code-Tags einklammert. Das hier ist eine perfekt valide sysDescr:

Nicht nach DOCSIS-Standard:

The CM MUST report each Type and Value for the sysDescr object identified in Table 30, with each Type field and corresponding Value field separated with a colon followed by a single blank space and each Type-Value pair is
separated by a semicolon followed by a single blank space. The correct format is illustrated below.

<i>
</i>HW_REV: <value>; VENDOR: <value>; BOOTR: <value>; SW_REV: <value>; MODEL: <value>

Offensichtlich darf ein "value" auch kein Semikolon enthalten. Jetzt erkläre mal bitte, wie das im Einklang mit RFC 854 stehen soll!

Das bezieht sich auf die SNMP-Schnittstelle des CMs, nicht auf die Zeichen der DHCPv6-Solicit Nachricht während der Provisionierung.

 

[Andreas1969]

Das bezieht sich auf die SNMP-Schnittstelle des CMs, nicht auf die Zeichen der DHCPv6-Solicit Nachricht während der Provisionierung.

Lass gut sein...
Die Katze (ähm Robert) lässt das Mausen nicht :brüll:

 

[sch4kal]

Das bezieht sich auf die SNMP-Schnittstelle des CMs, nicht auf die Zeichen der DHCPv6-Solicit Nachricht während der Provisionierung.

Lass gut sein...
Die Katze lässt das Mausen nicht :brüll:

Er will es doch genau haben, SNMP wird doch bei der Provisionierung gar nicht genutzt (und sogar in der DOCSIS-Konfig bei VF für eigene Endgeräte deaktiviert !?), da werden die Option Fields der DHCPv6-Nachrichten genutzt.

 

[robert_s]

Das bezieht sich auf die SNMP-Schnittstelle des CMs, nicht auf die Zeichen der DHCPv6-Solicit Nachricht während der Provisionierung.

Und was steht dazu im Standard:

Boot ROM version. Identical to value as reported in the <Boot ROM version> field in the MIB object sysDescr.

Der Wert muss identisch mit dem im sysDescr sein. Wenn also im Wert im sysDescr - im Widerspruch zum referenzierten RFC 854 - kein Semikolon enthalten sein darf, dann in der DHCPv6-Solicit Nachricht offensichtlich auch nicht.

Wie Du siehst, ist der Standard "unsauber". Offensichtlich hat man sich selbst bei CableLabs nicht die Standards ins letzte Detail durchgelesen. Aber Du forderst, dass VFKD das hätte tun müssen.

 

[Edding]

Also die Minimum Latency ist definitiv besser beim TC4400
Auch die avg sieht gute 2ms besser aus

 

[rv112]

Ne, die Latency ist exakt gleich. Thinkbroadband nutzt unterschiedliche Adressen und Routing, da hat die Minimum weniger was zu sagen.

 

[Andreas1969]

Ne, die Latency ist exakt gleich.

Also eine echte Alternative :zwinker:
Dann steht nur noch der Test im VF Portal aus :kratz:

 

[sch4kal]

Boot ROM version. Identical to value as reported in the <Boot ROM version> field in the MIB object sysDescr.

Der Wert muss identisch mit dem im sysDescr sein. Wenn also im Wert im sysDescr - im Widerspruch zum referenzierten RFC 854 - kein Semikolon enthalten sein darf, dann in der DHCPv6-Solicit Nachricht offensichtlich auch nicht.

Wie Du siehst, ist der Standard "unsauber". Offensichtlich hat man sich selbst bei CableLabs nicht die Standards ins letzte Detail durchgelesen. Aber Du forderst, dass VFKD das hätte tun müssen.

Nö, der muss identisch zur sysDescr in der SNMPv2 MIB sein (https://tools.ietf.org/html/rfc3418), sysDescr : Typ: DisplayString == ASN.1 OCTET STRING (limitiert auf die NVT ASCII characters) (https://www.ietf.org/rfc/rfc1213.txt)

 

[sparkie]

also "Versionsstring" hin oder her. Ich verstehe die Diskussion nicht. Ist zudem OT hier.

Ich habe jahrelang an Protokollstacks gearbeitet. Und es kommt immer mal vor, dass man etwas in der Spec ueberliest, man deswegen das Protokoll verletzt und einen die Gegenseite nicht versteht. Insofern wundert einen eher, dass das TC4400 ueberhaupt so gut laeuft wo es doch anscheinend (zumindest in Deutschland) von den verschiedensten Providern nie richtig evaluiert wurde.

Das Hauptproblem ist doch vielmehr, dass selbst jetzt wo diverse Fehler im Protokollablauf sogar genau lokalisiert wurden, keiner was macht. Kommunikation zwischen Modemhersteller und Provider ist nicht. Technicolor will keine Modems hierzulande etablieren und die Provider freuen sich darueber, weil sie wollen das Modem ja sowieso nicht :smile:

just my 2 cents

 

[robert_s]

Boot ROM version. Identical to value as reported in the <Boot ROM version> field in the MIB object sysDescr.

Der Wert muss identisch mit dem im sysDescr sein. Wenn also im Wert im sysDescr - im Widerspruch zum referenzierten RFC 854 - kein Semikolon enthalten sein darf, dann in der DHCPv6-Solicit Nachricht offensichtlich auch nicht.

Wie Du siehst, ist der Standard "unsauber". Offensichtlich hat man sich selbst bei CableLabs nicht die Standards ins letzte Detail durchgelesen. Aber Du forderst, dass VFKD das hätte tun müssen.

Nö, der muss identisch zur sysDescr in der SNMPv2 MIB sein (https://tools.ietf.org/html/rfc3418), sysDescr : Typ: DisplayString == ASN.1 OCTET STRING (limitiert auf die NVT ASCII characters) (https://www.ietf.org/rfc/rfc1213.txt)

Nö, der muss identisch zu dem Wert des Felds <Boot ROM version> sein, für das der DOCSIS-Standard (leider implizit) Restriktionen einführt, die in den RFCs nicht vorkommen!