Erfahrungen mit TC4400

[robert_s]

Daher sehe ich die UM-User auch zur VF-Kundengruppe zugehörig.

Bis die "Vereinigung" aber auch technisch umgesetzt ist, wird es sicherlich noch einige Zeit dauern. Was sich VFKD dann bzgl. der bei UM provisionierten Modems einfallen lässt, kann man jetzt noch gar nicht sagen. Vielleicht bleiben die UM-Systeme ja längerfristig so wie sie sind, vielleicht migriert man die irgendwann auf das Aktivierungsportal - und vielleicht läuft bis dahin längst eine neuere Version des DHCP-Servers, mit der sich selbst die "20er" TC4400 problemlos aktivieren lassen.

Entsprechend sind Behauptungen, dann würde eine größere Anzahl von TC4400 deprovisioniert werden, doch völlig haltlos. Was soll also diese Motzerei über ungelegte Eier?

[sch4kal]

Daher sehe ich die UM-User auch zur VF-Kundengruppe zugehörig.

Bis die "Vereinigung" aber auch technisch umgesetzt ist, wird es sicherlich noch einige Zeit dauern. Was sich VFKD dann bzgl. der bei UM provisionierten Modems einfallen lässt, kann man jetzt noch gar nicht sagen. Vielleicht bleiben die UM-Systeme ja längerfristig so wie sie sind, vielleicht migriert man die irgendwann auf das Aktivierungsportal - und vielleicht läuft bis dahin längst eine neuere Version des DHCP-Servers, mit der sich selbst die "20er" TC4400 problemlos aktivieren lassen.

Entsprechend sind Behauptungen, dann würde eine größere Anzahl von TC4400 deprovisioniert werden, doch völlig haltlos. Was soll also diese Motzerei über ungelegte Eier?

Das stimmt natürlich. Man geht aber wohl vom Worst-Case aus, da sich VF mit der Änderung ihrer Schnittstellenbeschreibung um die Aktivierung der .20er Firmware temporär verweigern zu können ja nicht gerade viele Freunde bei Manchen hier und im UM-Forum gemacht haben.

[Lutze]

Nun wieder zurück zum TC4400: mein bei Werner bestelltes TC4400 kam gestern leider mit der .20er Firmware, wohl noch Altbestände, muss er mir halt ein Neues schicken, auf die paar Tage kommt es jetzt aber auch nicht mehr an, hoffe nur das ich bald eine Rückmeldung der BNA bekomme.

Warum willst du es denn zurück senden die laufen doch mit der 20er Firmware im Vodafone Netz

Im Netz von Vodafone laufen TC4400 Modems mit .20er Firmware, wie willst du das rechtfertigen?

[sch4kal]

Nun wieder zurück zum TC4400: mein bei Werner bestelltes TC4400 kam gestern leider mit der .20er Firmware, wohl noch Altbestände, muss er mir halt ein Neues schicken, auf die paar Tage kommt es jetzt aber auch nicht mehr an, hoffe nur das ich bald eine Rückmeldung der BNA bekomme.

Warum willst du es denn zurück senden die laufen doch mit der 20er Firmware im Vodafone Netz

Im Netz von Vodafone laufen TC4400 Modems mit .20er Firmware, wie willst du das rechtfertigen?

Schöner Beweis für deine engstirnige und kleingeistige Denkweise, willkommen auf der Ignoliste.

[Lutze]

[treefiddy]

Nun wieder zurück zum TC4400: mein bei Werner bestelltes TC4400 kam gestern leider mit der .20er Firmware, wohl noch Altbestände, muss er mir halt ein Neues schicken, auf die paar Tage kommt es jetzt aber auch nicht mehr an, hoffe nur das ich bald eine Rückmeldung der BNA bekomme.

Warum willst du es denn zurück senden die laufen doch mit der 20er Firmware im Vodafone Netz

Im Netz von Vodafone laufen TC4400 Modems mit .20er Firmware, wie willst du das rechtfertigen?

[ externes Bild ]

[robert_s]

da sich VF mit der Änderung ihrer Schnittstellenbeschreibung um die Aktivierung der .20er Firmware temporär verweigern zu können ja nicht gerade viele Freunde bei Manchen hier und im UM-Forum gemacht haben.

Ich habe eher den Eindruck, dass manche schon vorab eine unbeirrbare Anti-VF Haltung hatten.

Was ist denn mit TC? Die haben mit ihrem fehlerhaften Steuerzeichen das Problem doch überhaupt verursacht, und die verweigern die Möglichkeit eines kundenseitigen Firmware-Updates, um ihren Fehler beheben zu können. Aber dennoch sind die "Freunde"?

Oder Werner, der Dir nicht den Artikel laut Beschreibung zugeschickt hat. Der darf sich Fehler erlauben, die Dich Ärger und Zeit kosten - aber VF? Die scheinen selbst dann "die Bösen" zu sein, wenn sie alles richtig machen. Für diese Voreingenommenheit habe ich kein Verständnis.

Übrigens zum TC4400: Da würde es mich doch wundern, wenn das nicht doch irgendeine Möglichkeit zum "Recovery" hat, mit der man eine Firmware lokal einspielen kann. Dem würde ich mal nachgehen. Warum hakt @AndreasNRW nicht mal diesbezüglich bei TC nach? Oder beschwert sich beim Verbraucherschutz...

Oder für die technisch Begabteren: Mal mit Wireshark mitschnüffeln, was das TC4400 so an seinen LAN-Ports tut, wenn man es ohne Kabelanschluss mit dem Strom verbindet, und mal nach einem versteckten Reset/Recovery-Taster suchen...

[VBE-Berlin]

Was ist denn mit TC? Die haben mit ihrem fehlerhaften Steuerzeichen das Problem doch überhaupt verursacht, und die verweigern die Möglichkeit eines kundenseitigen Firmware-Updates, um ihren Fehler beheben zu können. Aber dennoch sind die "Freunde"?

die haben doch keinen Fehler gemacht! VF hat den Fehler gemacht, einen DHCP-Server einzusetzen, der das TAB-Zeichen an der Stelle nicht haben möchte.
Da der DHCP-Server-Programmierer aber das nicht korrigieren will, muß Vodafone sich jetzt wegen der Masse an TC4400 einen anderen DHCP-Server kaufen.
So einfach und kostengünstig ist das.

Was ist denn mit TC? Die haben mit ihrem fehlerhaften Steuerzeichen das Problem doch überhaupt verursacht, und die verweigern die Möglichkeit eines kundenseitigen Firmware-Updates, um ihren Fehler beheben zu können. Aber dennoch sind die "Freunde"?

TC könnte ja die Modems auch zum Umprogrammieren zu sich ordern.
Aber das wollen sie anscheinend ja nicht.

[treefiddy]

da sich VF mit der Änderung ihrer Schnittstellenbeschreibung um die Aktivierung der .20er Firmware temporär verweigern zu können ja nicht gerade viele Freunde bei Manchen hier und im UM-Forum gemacht haben.

Ich habe eher den Eindruck, dass manche schon vorab eine unbeirrbare Anti-VF Haltung hatten.
Im onlinekosten Forum diskutierst du übrigens mit Telekom Technikern auf Augenhöhe. Vodafone hat sich bis heute nicht offiziell zum TC4400 geäußert, mehr als "Machen wir nicht weil wir die Schnittstellenbeschreibung geändert haben" kam da bisher nicht.

Was ist denn mit TC? Die haben mit ihrem fehlerhaften Steuerzeichen das Problem doch überhaupt verursacht, und die verweigern die Möglichkeit eines kundenseitigen Firmware-Updates, um ihren Fehler beheben zu können. Aber dennoch sind die "Freunde"?

Ich habe bei dir das Gefühl, dass du zu sehr eine unbeiirbare Pro-VF Haltung hast, sieht man auch an deinen zahlreichen - teils absurden - Onlinekosten.de Posts (z.B. über die Transparenz bei Vodafone https://www.onlinekosten.de/forum/showt ... ost2433461 ). Auch ansonsten hast du eine scheinbar unbeiirbare Anti-Telekom Haltung.

Laut Schnittstellenbeschreibung (bis zur plötzlichen Änderung von Vodafone ohne weitere INformationen) war das Tab erlaubt, also eher ein Fehler bei Vodafone.
Technicolor hingegen hat den Fehler in der neuen Firmware bereits behoben, Vodafone nicht. Warten wir da mal auf die BNA und schieben das Problem nicht direkt auf Techicolor oder Vodafone.

Siehe auch:

Daran glaubst Du?
Dann müßte ja die komplette DOCSIS-Norm in dieser Schnittstellenbeschreibung abgelegt sein.
Die Frage, ob dieses TAB-Teichen laut DOCSIS zulässig ist, konnte auch hier bisher keiner beantworten.

Also fangen wir mal an: Vodafone setzt die Schnittstellenbeschreibung "Vodafone Kabel Deutschland pNTP Interface Specification" voraus, diese bezieht sich auf die ANGA 100 001 (aka "Konformitätserklärung der deutschen KNBs mit den CableLabs Standards"). Dort heißt es auf S.32: Annex H "DHCPV6 VENDOR SPECIFIC INFORMATION OPTIONS FOR DOCSIS 3.0 (NORMATIVE)" mandatory & relevant for IF spec. Annex H wird aus CM-SP-MULPIv3.0-I29-151210 (Data-Over-Cable Service Interface Specifications DOCSIS® 3.0 MAC and Upper Layer Protocols Interface Specification) zitiert. Dort steht auf Seite 698 "Please refer to [CANN DHCP-Reg], CableLabs DHC Options Registry Specification". CANN DHCP-Reg bezieht sich auf ein weiteres CableLabs Dokument "CL-SP-CANN-DHCP-Reg-I12-151210" (CableLabs® Specifications
CableLabs' DHCP Options Registry). Dort findet sich der Knackpunkt auf Seite 35 "5.2.7 Boot Rom Version Option". "The boot rom version string as NVT ASCII text MUST NOT be null terminated". Was bedeutet NVT ASCII ? -> https://public.support.unisys.com/aseri ... 20945.html bzw. RFC 854 (Telnet).
The NVT‑ASCII character set contains:

• All 95 ASCII graphics characters (hexadecimal 20 through 7E)
• [...] Horizontal tab Hex-Code 09 [...]

VF hat aber in seiner pNTP Spezifikation am 26.4. genau Punkt 7.1 abgeändert, sodass nur noch die ASCII-Zeichen 0x20 bis 0x7E erlaubt sind. Ursprünglich wurde auf die o.g. Standards referenziert, die ein horizontales Tab-Zeichen im Boot ROM Option String explizit dulden!

Jetzt klar ?

Oder Werner, der Dir nicht den Artikel laut Beschreibung zugeschickt hat. Der darf sich Fehler erlauben, die Dich Ärger und Zeit kosten - aber VF? Die scheinen selbst dann "die Bösen" zu sein, wenn sie alles richtig machen. Für diese Voreingenommenheit habe ich kein Verständnis.

Vodafone hat doch gezeigt, dass sie das TC4400 auch mit .20 aktivieren können. WARUM sie dies jedoch nicht mehr machen wollen wissen wir nicht. Zu diesen Problemen ist Vodafone leider überhaupt nicht transparent. Wenn Vodafone besser kommunizieren würde wären viele TC4400 Besitzer auch nicht so sauer.

Übrigens zum TC4400: Da würde es mich doch wundern, wenn das nicht doch irgendeine Möglichkeit zum "Recovery" hat, mit der man eine Firmware lokal einspielen kann. Dem würde ich mal nachgehen. Warum hakt @AndreasNRW nicht mal diesbezüglich bei TC nach? Oder beschwert sich beim Verbraucherschutz...

Oder für die technisch Begabteren: Mal mit Wireshark mitschnüffeln, was das TC4400 so an seinen LAN-Ports tut, wenn man es ohne Kabelanschluss mit dem Strom verbindet, und mal nach einem versteckten Reset/Recovery-Taster suchen...

Haben wir bereits versucht, wenn du uns dabei helfen kannst - gerne : https://www.unitymediaforum.de/viewtopi ... are+update

[sch4kal]

Ich habe eher den Eindruck, dass manche schon vorab eine unbeirrbare Anti-VF Haltung hatten.

Das stimmt bei mir natürlich, das hat aber auch andere, hier nicht näher erwähnenswerte Gründe. (Vertrags- und Rechnungsmodalitäten, Kundenumgang, etc.)

Was ist denn mit TC? Die haben mit ihrem fehlerhaften Steuerzeichen das Problem doch überhaupt verursacht, und die verweigern die Möglichkeit eines kundenseitigen Firmware-Updates, um ihren Fehler beheben zu können. Aber dennoch sind die "Freunde"?

Sie verweigern keine kundenseitigen Firmware-Updates, es ist schlicht von den CableLabs-Standards nicht vorgesehen und wird auch in keinem Land der Welt von keinem Hersteller außer AVM so gehandhabt. Vielleicht könnte Andreas bei seinem Kontakt anfragen, ob sie denn nicht beim TC4400-EU eine Ausnahme machen würden. Natürlich besteht ein Minor-Bug in der .20er Firmware, das habe ich auch nie beschönigt. Dennoch sollte der DHCPv6-Server über dieses Zeichen hinwegsehen, darum geht es ja.

Oder Werner, der Dir nicht den Artikel laut Beschreibung zugeschickt hat. Der darf sich Fehler erlauben, die Dich Ärger und Zeit kosten - aber VF? Die scheinen selbst dann "die Bösen" zu sein, wenn sie alles richtig machen. Für diese Voreingenommenheit habe ich kein Verständnis.

Ich weiß nicht ob es hier in VFKD-Forum deutlich wurde, natürlich ärgere ich mich das ich das Gerät wieder zu DPD bringen muss zur Retoure, wie so oft gilt hier jedoch: Der Ton gibt die Musik an. Keine halbe Stunde nachdem ich das Modem bei Werner beanstandet hatte bekam ich eine Antwort mit Entschuldigung und die Zusendung eines TC4400 mit Laborfirmware als Vorausersatz. Natürlich kann man einen kleinen Fachhandel für Kabel- und Antennentechnik nicht mit einem Weltkonzern vergleichen, jedoch war der Kontakt zu Werner Electronics bis jetzt immer positiv gestimmt. Ich hatte jedenfalls das Gefühl, auf Augenhöhe und mit Interesse bedient zu werden, Attribute, die ich von vielen Hotlinern bei VF/KDG sehr vermisse.

Übrigens zum TC4400: Da würde es mich doch wundern, wenn das nicht doch irgendeine Möglichkeit zum "Recovery" hat, mit der man eine Firmware lokal einspielen kann. Dem würde ich mal nachgehen. Warum hakt @AndreasNRW nicht mal diesbezüglich bei TC nach? Oder beschwert sich beim Verbraucherschutz...

Wird schon danach gesucht: https://www.unitymediaforum.de/viewtopi ... 44#p399044. Leider gibts bis jetzt nicht viel erfolgsversprechendes zu vermelden, an einer angelöteten UART-Schnittstelle bekam man ein paar Bootloader-Meldungen zu Gesicht, es wird eCOS eingesetzt. Jedoch kam man bis jetzt noch nicht auf das System drauf. Ohne Internals von Broadcom zum 3390 wirds auch mit JTAG nix werden...

Oder für die technisch Begabteren: Mal mit Wireshark mitschnüffeln, was das TC4400 so an seinen LAN-Ports tut, wenn man es ohne Kabelanschluss mit dem Strom verbindet, und mal nach einem versteckten Reset/Recovery-Taster suchen...

Wurde auch schon alles versucht https://www.unitymediaforum.de/viewtopi ... hilit=TFTP. Es war laut Werner Electronics Zulieferer auch mal von einem USB-Stick die Rede, mit der sich das TC4400 beim Boot ein Firmware-File zieht und flasht, das ist jedoch auch im Sand verlaufen. Es wurde und wird auch noch nach Lücken in der Firmware selbst gesucht, daher kam man auch in manchen Shellskripten zu der Annahme, ein Update via USB-Stick müsste möglich sein.