Auch wenn es immer wieder als "böser Wille" von AVM oder den KNB angesehen wird ... da stehen tatsächlich schon entsprechende Beschränkungen in den derzeit gültigen DOCSIS-Standards. Wenn die jemandem nicht passen, muß er eben versuchen, diese Standards zu ändern.
Nach der "
Operations Support System Interface"-Spezifikation (OSSI) für (Euro-)DOCIS 3 ist es per se schon mal
vorgeschrieben, daß es keinen "console port" (dazu gehört auch Telnet auf der Box, wenn darüber der Zugang zum CM möglich ist) gibt:
Punkt 9.2 Console Access schrieb:
The CM MUST NOT allow access to the CM functions by a console port. In this specification, a console port is defined as a communication path, either hardware or software, that allows a user to issue commands to modify the configuration or operational status of the CM. The CM MUST only allow access using DOCSIS defined RF interfaces and operator-controlled SNMP access by the CMCI.
(Hervorhebung durch mich)
Wenn also ein (standardkonformes) Gerät einen solchen Zugang (auch zum CM) ermöglicht (das ist bei einem "eDOCSIS"-Gerät meist nicht zu vermeiden, denn dieses kleine "e" steht eben nicht für "Euro", sondern für "embedded"), ist das eigentlich ein Software-
Fehler und wenn der dann vom Hersteller beseitigt wird, kann man sicherlich auf die DOCSIS-Spezifikation "schimpfen" ... der Hersteller kommt hier nur seiner Verpflichtung nach, das Gerät (nach bestem Wissen und Gewissen) zum Standard konform zu halten.
Es wäre auch ziemlich widersinnig, wenn einerseits der Standard eine komplette PKI-Architektur zur Absicherung von PACM vorschreibt und auf der anderen Seite dann der (meist ja doch recht ahnungslose) Benutzer/Kunde wieder dort eingreifen kann.
Ich warte noch auf das Gerät, wo die DOCSIS-Funktionen dann tatsächlich als "black box" ausgeführt sind (ist ja bei den WLAN-Treibern auch nicht anders) und man trotzdem noch (mit gutem Gewissen) den Zugriff auf die restlichen Funktionen so eines IAD (und die CM-Funktionalität - selbst MTA und DVA - ist eben nur
ein einzelner Aspekt so eines Gerätes) zugänglich machen kann.
Leider gibt es das noch nicht ... der oben zitierte Punkt in der Spezifikation ist auch der Grund, warum ich mich einigermaßen damit zurückhalte, wie man denn nun in so eine (aktuelle) "FRITZ!Box Cable" eindringen könnte bzw. sogar aktiv dagegen arbeite, wenn ich gefundene Lücken an AVM melde.
Ich will zwar auch wissen, was so eine FRITZ!Box (zumindest eben jenseits des "Modem-Teils") in meinem Netz veranstalten kann ... aber solange da diese Trennung nicht umgesetzt ist (es gibt ja inzwischen sogar den Ansatz, die Funktionen so eines IADs in getrennte VMs zu splitten und auch entsprechende Prozessoren), halte ich den Telnet-Zugriff an dieser Stelle auch für ein ernsthaftes Problem - womit ich dann wieder beim "überwiegend ahnungslosen Benutzer" bin und für diesen Standpunkt (auch wenn er überheblich klingen mag), findet man auch hier im IPPF genug Belege.
Sollen die Leute meinetwegen "debranden" bis das Rot der Boxen in ein helles Grau übergeht, weil das (metaphorische) "Feuer" der Box erloschen ist ... das ist alles noch kein Telnet-Zugriff und wenn die Provider diejenigen Boxen aus dem Netz ausschließen, die eine bekanntermaßen angreifbare Firmware enthalten, ist das zunächst mal 100% DOCSIS-Standard.
Wie weit AVM dann für die ehemaligen Provider-Modelle (die sicherlich eine ganz andere Gewinnmarge hatten als die heutigen Retail-Boxen) die Firmware liefern müßte, um diese "graue Ware" jetzt standardkonform zu machen, wage ich nicht einzuschätzen ... aber ich kann es verstehen, wenn man es nicht (freiwillig) macht.
Wer sich eine eigene 6490 vor dem 01.08. besorgt hat, der sollte auch um das Risiko der Inkompatibilität gewußt haben (auch hier im IPPF sollte man dazu genug finden können) ... jetzt "heulen" ist da für mich eine ziemlich unverständliche Reaktion.
BTW ... wer wissen will, was aus einem "CM" (cable modem) "rauskommen" darf/soll, der schaut sich dann einfach mal die Definition des CMCI (cable modem to CPE interface) an.
)
