Unitymedia Arris TM3402B Modem

[robert_s]

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.

Kommunikation gab es wohl durchaus. Aber VFKD hat nun mal keine weiteren TC4400 geordert, entsprechend gibt es auch keinen Support von Technicolor dafür. Ansonsten:

CableLabs - hat wohl nix gemacht, die aktuellen Standarddokumente sind an den entscheidenden Stellen nicht nachgebessert worden
Vodafone Kabel - hat die Schnittstellenbeschreibung ergänzt
Technicolor - hat eine Firmware herausgebracht, die das TAB-Zeichen aus dem BootROM-Versionsstring entfernt

Also zwei Akteure haben da durchaus was gemacht.

Technicolor will keine Modems hierzulande etablieren und die Provider freuen sich darueber, weil sie wollen das Modem ja sowieso nicht :smile:

Warum sollte man auch Modems bestellen, die bei der Evaluation "durchgefallen" sind...?

 

[Andreas1969]

Warum sollte man auch Modems bestellen, die bei der Evaluation "durchgefallen" sind...?

Robert, jetzt ist aber gut :streber:

 

[sch4kal]

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

Ja ist OT, höre ja schon auf damit.

Das Problem bei VF oder Software im Allgemeinen ist ja nicht, das sie Fehler enthalten kann oder Standards verletzt, aber es muss eben danach auch gefixt werden.
VF ändert halt lieber ihre Schnittstellenbeschreibung...so kann man natürlich die Endgerätefreiheit auch aushebeln.

 

[sch4kal]

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.

Kommunikation gab es wohl durchaus. Aber VFKD hat nun mal keine weiteren TC4400 geordert, entsprechend gibt es auch keinen Support von Technicolor dafür. Ansonsten:

CableLabs - hat wohl nix gemacht, die aktuellen Standarddokumente sind an den entscheidenden Stellen nicht nachgebessert worden
Vodafone Kabel - hat die Schnittstellenbeschreibung ergänzt
Technicolor - hat eine Firmware herausgebracht, die das TAB-Zeichen aus dem BootROM-Versionsstring entfernt

Also zwei Akteure haben da durchaus was gemacht.

Technicolor will keine Modems hierzulande etablieren und die Provider freuen sich darueber, weil sie wollen das Modem ja sowieso nicht :smile:

Warum sollte man auch Modems bestellen, die bei der Evaluation "durchgefallen" sind...?

Die könnten ruhig mal öffentlich machen, was die da so "evaluiert" haben.
Bei VF NZ und der Kabelprovider in Kanada scheinen die TC4400 ja zu laufen...komisch :zwinker:

 

[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)

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!

Du referenzierst die falsche Tabelle, das steht in der DHCPv4 Suboptions Table.

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

 

[Andreas1969]

Die könnten ruhig mal öffentlich machen, was die da so "evaluiert" haben.

Denen hat das TC4400 einfach nicht geschmeckt :streber:
Kunde hat damit zuviel Freiheiten :brüll:

 

[robert_s]

Die könnten ruhig mal öffentlich machen, was die da so "evaluiert" haben.

Da wirst Du weltweit wohl keinen einzigen KNB finden, der das tut. Zumal es durchaus sein könnte, dass mit den Kabelmodemherstellern gegenseitige NDAs abgeschlossen werden, weil keiner möchte, dass die Öffentlichkeit bzw. die Konkurrenz davon etwas erfährt. Speziell wenn ein Gerät "durchfällt", mag der Hersteller das sicherlich nicht veröffentlicht sehen. Aber vom TC4400 gibt es ja dummerweise die Pressefotos von der Präsentation des 8,x Gbit/s Experiments...

 

[Andreas1969]

Aber vom TC4400 gibt es ja dummerweise die Pressefotos von der Präsentation des 8,x Gbit/s Experiments...

Und genau damit hat VF erst recht Öl ins Feuer gegossen :winken:

 

[sparkie]

Also zwei Akteure haben da durchaus was gemacht.

ok, vielleicht in diesem Fall. Weil den trivialen <TAB> Bug wahrscheinlich ein Werkstundent bei Technicolor 'for free' fixen konnte :smile:

Es gibt aber noch mindestens das Problem bei der Provisionierung mit den CISCO CMTSen bei VF. Und da geht anscheinend gar nichts vorwaerts. Auch nicht in der tollen Final von Technicolor. Vermutlich, weil das eine etwas teurere Korrektur waere.

Warum sollte man auch Modems bestellen, die bei der Evaluation "durchgefallen" sind...?

fuer Leute die Features brauchen, die die roten Kinderspielzeuge aus Berlin nicht unterstuetzen (z.B. Multi-WAN Interfaces und autom. Failover bei Ausfaellen) gibt es nicht viel Alternativen.

 

[robert_s]

Du referenzierst die falsche Tabelle, das steht in der DHCPv4 Suboptions Table.

Und in "5.2 DHCPv6 CableLabs Vendor-Specific Information Option: Common Sub-Options" steht:

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

Worauf möchtest Du also hinaus?

 

[robert_s]

Es gibt aber noch mindestens das Problem bei der Provisionierung mit den CISCO CMTSen bei VF. Und da geht anscheinend gar nichts vorwaerts. Vermutlich weil das eine etwas teurere Korrektur wird.

Was das angeht, hat Vodafone Kabel übrigens den Wert, an dem sich das TC4400 laut Firmware "Known Issues" stören sollte, aus seinen configfiles entfernt - leider erfolglos. Da müsste wohl Technicolor doch mal die Firmware fixen. Aber wenn die die Produktion eigentlich schon eingestellt haben, ist das entsprechend unwahrscheinlich. Da kann man eher darauf hoffen, dass VFKD auch seine Cisco-CMTS mal ersetzt.

 

[sch4kal]

Du referenzierst die falsche Tabelle, das steht in der DHCPv4 Suboptions Table.

Und in "5.2 DHCPv6 CableLabs Vendor-Specific Information Option: Common Sub-Options" steht:

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

Worauf möchtest Du also hinaus?

Da scheint dasselbe drin zu stehen, da hab ich mich wohl vertan.

Nichtsdestotrotz wird nirgends auf die sysDescr aus der OSSI referenziert, was nicht weiter verwundert, denn dieses Dokument kommt bei der initialen Provisionierung erstmal gar nicht zum Tragen, da wird gar kein SNMP eingesetzt.
Es gilt deshalb das, was in CL-SP-CANN-DHCP-Reg steht:

[...]The boot rom version string as NVT ASCII text
MUST NOT be null terminated.[...]

Im Übrigen verweist selbst die OSSI auf RFC 3418.

 

[Wechseler]

Es gibt aber noch mindestens das Problem bei der Provisionierung mit den CISCO CMTSen bei VF. Und da geht anscheinend gar nichts vorwaerts. Auch nicht in der tollen Final von Technicolor. Vermutlich, weil das eine etwas teurere Korrektur waere.

Die 20er-Firmware läuft an Cisco-CMTSen, die hat halt nur das Tab-Zeichen drin. Im Prinzip bräuchte man für den Vodafone-Schluckauf nur eine 20er-Firmware ohne Tab-Zeichen und damit wär das Ding erledigt und in jedem anderen Land würde der KNB in seinem Netz genau diese Firmware ausrollen, wie von CableLabs vorgesehen.

Daran, daß man bei Primacom möglicherweise CM und CPE verwechselt, ändert das natürlich wenig, aber das ist ein relativ unbedeutender Kleinanbieter, der zumindest einen Workaround-Prozeß hat.

 

[Wechseler]

Es gibt aber noch mindestens das Problem bei der Provisionierung mit den CISCO CMTSen bei VF. Und da geht anscheinend gar nichts vorwaerts. Vermutlich weil das eine etwas teurere Korrektur wird.

Was das angeht, hat Vodafone Kabel übrigens den Wert, an dem sich das TC4400 laut Firmware "Known Issues" stören sollte, aus seinen configfiles entfernt - leider erfolglos. Da müsste wohl Technicolor doch mal die Firmware fixen. Aber wenn die die Produktion eigentlich schon eingestellt haben, ist das entsprechend unwahrscheinlich. Da kann man eher darauf hoffen, dass VFKD auch seine Cisco-CMTS mal ersetzt.

Das Problem war doch kein unpäßliches Konfigfile, sondern daß RF-technisch kein Sync mehr zustandekommt, weil Cisco und TC dort den Standard etwas unterschiedlich interpretieren. (Man kann also immer Spaß haben, wie man sieht. :brüll: )

 

[sparkie]

Die 20er-Firmware läuft an Cisco-CMTSen, die hat halt nur das Tab-Zeichen drin. Im Prinzip bräuchte man für den Vodafone-Schluckauf nur eine 20er-Firmware ohne Tab-Zeichen und damit wär das Ding erledigt und in jedem anderen Land würde der KNB in seinem Netz genau diese Firmware ausrollen, wie von CableLabs vorgesehen.

der Hauptgrund warum sie noch Nachfolger fuer die 20er-Firmware herausbrachten war doch, weil sie immer mehr unliebsame Seiten aus der tollen Web-GUI verbannen wollten? Im Zuge dieser kosmetischen Korrekturen haben sie die Firmware eigentlich immer nur verschlimmbessert. Das Ganze gipfelte dann in der Final in der nicht mal mehr die Temperaturanzeige richtig funktioniert :heul:

 

[rv112]

Die Hersteller haben einfach nicht das Personal dafür bei den Stückzahlen groß Support zu leisten. Ist ja auch irgendwo verständlich.

Das Arris hat übrigens einen Nachteil: man sieht das Configfile nicht. Außer es versteckt sich hinter dem Advanced Menü welches mittels "Passwort of the day" gesperrt ist. Dieses konnte jedoch noch nicht ausfindig gemacht werden und die alten Generatoren funktionieren nicht mehr.

 

[Wechseler]

Die 20er-Firmware läuft an Cisco-CMTSen, die hat halt nur das Tab-Zeichen drin. Im Prinzip bräuchte man für den Vodafone-Schluckauf nur eine 20er-Firmware ohne Tab-Zeichen und damit wär das Ding erledigt und in jedem anderen Land würde der KNB in seinem Netz genau diese Firmware ausrollen, wie von CableLabs vorgesehen.

der Hauptgrund warum sie noch Nachfolger fuer die 20er-Firmware herausbrachten war doch, weil sie immer mehr unliebsame Seiten aus der tollen Web-GUI verbannen wollten? Im Zuge dieser kosmetischen Korrekturen haben sie die Firmware eigentlich immer nur verschlimmbessert. Das Ganze gipfelte dann in der Final in der nicht mal mehr die Temperaturanzeige richtig funktioniert :heul:

Die Temperaturanzeige gibt es in der 20er-Firmware auch nicht.

 

[Andreas1969]

Das Arris hat übrigens einen Nachteil: man sieht das Configfile nicht. Außer es versteckt sich hinter dem Advanced Menü welches mittels "Passwort of the day" gesperrt ist.

Da möchte ich für wetten, dass es dort versteckt ist :zwinker:

 

[GuBo]

Und wo kann man das jetzt kaufen? Und was kostet das?

 

[rv112]

Das Modem ist aktuell nur ein Testgerät, ob es für uns überhaupt in Frage käme. Der Vertrieb ist dann noch eine andere Hürde. Mehr dazu in der nächsten Zeit.

 

[rv112]

Kann jemand etwas damit anfangen, was ein Config File Seed ist?

 

[robert_s]

Kann jemand etwas damit anfangen, was ein Config File Seed ist?

Meinst Du das hier?
https://docsis.org/node/9030

 

[robert_s]

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

Worauf möchtest Du also hinaus?

Da scheint dasselbe drin zu stehen, da hab ich mich wohl vertan.

Nichtsdestotrotz wird nirgends auf die sysDescr aus der OSSI referenziert, was nicht weiter verwundert, denn dieses Dokument kommt bei der initialen Provisionierung erstmal gar nicht zum Tragen, da wird gar kein SNMP eingesetzt.
Es gilt deshalb das, was in CL-SP-CANN-DHCP-Reg steht:

Ohne OSSI gibt es gar kein "<Boot ROM version> field in the MIB object sysDescr", denn das wird erst in der OSSI definiert. Dass das DHCP-Dokument die OSSI nicht als Referenz aufführt ist ein weitere Beleg für mangelnde Sorgfalt bei der Erstellung der Standards.

Im Übrigen verweist selbst die OSSI auf RFC 3418.

Und widerspricht ihr bei der Definition der Felder sofort wieder. Wie ich schon schrieb: Da sind Fehler bei der Erstellung der Standards gemacht worden.

 

[rv112]

Kann jemand etwas damit anfangen, was ein Config File Seed ist?

Meinst Du das hier?
https://docsis.org/node/9030

Ja. Das setzt also der ISP?

 

[robert_s]

Kann jemand etwas damit anfangen, was ein Config File Seed ist?

Meinst Du das hier?
https://docsis.org/node/9030

Ja. Das setzt also der ISP?

Da es ein Arris-spezifisches MIB ist, nur, wenn er eine spezielle Config für Arris-Modems hat. In den Config Files von VFKD und UM für kundeneigene Geräte würde ich das nicht erwarten.