VF wird auch immer "lustiger" (ich bin einfach mal dem Link in #193 gefolgt) ... man könnte fast soweit gehen zu behaupten, sie
täuschten ihre Kunden absichtlich über die tatsächliche Lage.
Wenn
da etwas von
vodafone.de schrieb:
Kann ich Firmware-Updates meines Leih-Gerätes jetzt selbst durchführen?
Das ist nicht möglich. Firmware-Updates werden weiterhin ausschließlich durch Vodafone verteilt. Ein manueller Eingriff in die Hard- und Software der Leih-Geräte ist untersagt.
steht, dann ist das vielleicht die Ab- oder Ansicht von Vodafone, die aber in den (auch heute noch) gültigen AGB (
http://www.vodafone.de/downloadarea/kabel-agb-internet-telefon.pdf - SHA256: 25fea5ecdc57ed5b7e78c18ee352d28b3d3b7e3dc2b2e5bad6855e6b1c26bd51) gar nicht zu finden ist - weder in Punkt 3 noch in Punkt 4 (den Rest tue ich mir nicht erneut an, das habe ich mal gemacht, als ich noch KDG-Kunde war und
bevor ich die Firmware auf solchen Leihgeräten geändert habe) ist auch nur die Rede davon, daß der Kunde die Software der Leihgeräte nicht verändern darf. Er hat nur bei Störungen durch solche Änderungen keinen Anspruch auf kostenlose Beseitigung des Problems durch Vodafone ... was auch die wenigsten überraschen dürfte.
Solange sich diese Änderungen rückgängig machen lassen, ist das auch keine Beschädigung des VF-Eigentums - vermutlich steht deshalb auch "unter
sagt" auf der Seite, schließlich muß das keinen Kunden wirklich interessieren, was der Provider ihm "sagt", solange nicht entsprechende vertragliche Regelungen getroffen wurden. Selbst der "Sport" des Freischaltens der WLAN-Option auf alten Hitron-Geräten ist erst einmal kein Problem (gewesen), solange der Anbieter (KDG) eben gerade keine
geeigneten Maßnahmen dagegen getroffen hatte - und eine Maßnahme, die zwar plakativ vorhanden, aber technisch unwirksam ist, wird glücklicherweise auch in der Rechtssprechung (überwiegend jedenfalls) nicht anerkannt.
Wenn ein Hersteller eine Firmware mit Lücken bereitstellt und Vodafone diese Firmware auf eigenen Geräten (hier geht es ja um Leihgeräte und der Zusammenhang zwischen Homespot und Provider-Geräten ist ja auch nicht ganz zufällig) beim Kunden einsetzt, dann ist der Versuch des Kunden, diese Firmware zu modifizieren, maximal ein Verstoß gegen vertragliche Vereinbarungen (hier wohl nicht einmal ein solcher, außer ich habe beim Lesen "geschusselt") und Zivilrecht. Erst wenn mit einer modifizierten Firmware dann weitere Aktionen unternommen werden (z.B. Angriffe auf andere Benutzer oder Geräte oder das Erschleichen von Leistungen), erst dann wird das vielleicht ein Fall für "verboten" bis "strafbar".
Warum dann "ehemalige Leihgeräte" bei Vodafone immer noch einem Kunden zugeordnet sein sollen, wenn der doch längst den Schadensersatz an Vodafone gezahlt hat und dann nicht ohnehin automatisch eine event. noch vorhandene "Zuordnung" aufgehoben wird (Wie lange steht so ein Kunde eigentlich nach dem Vertragsende noch in den Datenbanken bei Vodafone herum? Was sagt denn da der Datenschutzbeauftragte von Vodafone/KDG zu irgendwelchen Speicherfristen und dem Umfang der gespeicherten Daten?), wird wohl auch ein Geheimnis von VF bleiben, bis dann mal der erste Kunde so richtig "Stunk" macht.
Auch wenn ich das Verhalten von AVM (keine Updates für OEM-Geräte) für vertretbar halte und meinetwegen auch noch anerkennen will, daß die Installation einer (Mindest-)Version der Firmware die Voraussetzung für die Benutzung sein darf (wenn andere Versionen bekanntermaßen gegen die Schnittstellenbeschreibung verstoßen und auch hier gilt, daß die Provider für ihre eigenen Geräte diese Bestimmungen durchaus ja auch lockern dürfen (und ältere Versionen mit Lücken auf eigenes Risiko einsetzen), ich wüßte nicht, wo das im Gesetzestext verboten wäre), ist das bei VF einfach nur saudumm formuliert.
So ist jedenfalls meine Ansicht dazu, weil ich daraus lese, daß es um "ehemalige Leihgeräte des Providers" geht und hier kann "der Provider" ja wohl nur VF selbst sein - eine Rolle als "Hilfssheriff" kann VF sich ja wohl nicht ernsthaft anmaßen wollen, solange die tatsächlichen Eigentumsverhältnisse der Box nicht
im Einzelfall geklärt sind.
Ich erinnere nur daran, daß es auch (Provider-)Angebote zum
Kauf der 6490 mit der alten Artikelnummer gab und gibt, damit kann VF gar nicht wirklich feststellen, ob die Box bei irgendeinem anderen Provider als "ehemaliges Leihgerät" registriert ist (abgesehen davon wäre das "none of their goddamn business").
Es geht VF schlicht nichts an, woher ein Kunde eine andere Box haben mag (nicht mal, wenn es eine von KDG selbst ist, solange die "Ablöse" gezahlt wurde) - wenn eine Box die technischen Voraussetzungen erfüllt uund das ist ggf. die Firmware-Version und das notwendige gültige Zertifikat, dann ist die auch verwendbar.
Zwar steht der Kunde vor dem Problem, sich ein passendes CM-Zertifikat zu besorgen und auf seine Box zu bringen (wenn diese nicht schon ein solches haben sollte aufgrund eines früheren Updates) ... ist das erfolgt, kann (nach allem, was wir bisher wissen und/oder zusammengetragen haben) der Provider ohne Blick auf das Typenschild (ich unterstelle einfach mal eine "gefälschte" CM-MAC, weil sonst die Frage des CM-Zertifikats ebenfalls offen wäre - auch wenn ich den Austausch von Datenbankden der MAC-Adressen "gültiger" (Kunden-)Geräte zwischen AVM und den Providern für ziemlich illegal (zumindest fragwürdig) halten würde, denn soweit wir wissen, laufen auch andere Modelle unter der OUID "C8:0E:14") vermutlich gar nicht feststellen, welche Artikelnummer das Gerät tatsächlich hat und eine bestimmte Artikelnummer taucht auch in keiner Schnittstellenbeschreibung von Vodafone auf - mithin ist das wohl eher auch kein Grund für eine (rechtlich einwandfreie) Weigerung, eine ältere Box zu provisionieren, auf die der Kunde (auf welchem Weg auch immer, das ist nicht der Kern der Sache) eine Firmware gebracht hat, die den Anforderungen (nach Angabe des Geräteherstellers, warum sollte der Kunde selbst den Nachweis führen müssen) gerecht wird und bei anderen Geräten des Herstellers auch problemlos funktioniert und akzeptiert wird.
Wenn solche Firmware mit jeder bekanntwerdenden Lücke (wg. Verstoß gegen "Chapter 9.2") auch sofort die "Zulassung" beim Provider selbst verlieren würde, kommen vermutlich hektische Zeiten auf die KNB zu und die bisher eher gemächlichen Rollouts neuer Firmware sind Geschichte.
Da, wo es bisher eher Hobby war, die DOCSIS-Geräte zu penetrieren, tut sich jetzt eben ein neuer Markt auf (auch das ist nicht wirklich überraschend, der Standard versucht ja nach Kräften "vorzubauen") und das ist am Ende trotzdem immer ein Katz- und Maus-Spiel zwischen den Leuten, die dort eindringen wollen und denen, die das verhindern wollen. Apple kann bei seinen mobilen Geräten seit Jahren ein Lied davon singen. Auch wenn es komplizierter wird von mal zu mal, bis zu "unmöglich" ist es in aller Regel ein sehr weiter Weg und mit neuen Funktionen (und sei es ein "Homespot" oder ein neuer Weg des Firmware-Updates :mrgreen
ziehen mit hoher Wahrscheinlichkeit auch neue Lücken ein (das gilt auch nicht nur für AVM), solange die Qualitätssicherungsstandards (und die Ausbildung/Anzahl der Leute, die das programmieren sollen) nicht auf ganz andere Level angehoben werden, was dann am Ende kein Mensch mehr (für ein Consumer-Gerät) bezahlen kann (und will).
Auf der anderen Seite tut sich bei den Retail-Modellen auch eine vollkommen neue Herausforderung für AVM auf ... da, wo es bisher eher galt, den Kunden aus der Provider-Box herauszuhalten, muß es nun eben auch beachtet werden, daß der Provider nicht in eine Kunden-Box eindringt - und zwar ganz klar auch nicht eindringen
kann und nicht, daß sich der Kunde darauf verlassen soll, daß der Provider schon nichts anstellen wird (abgesehen davon, daß AVM wohl kaum für jeden Mitarbeiter beim KNB die Hand ins Feuer legen will).
Bei der Frage des "feature disable" ist da zumindest schon mal eine "Sperre" vorhanden, falls irgendjemand Befürchtungen hatte, der Provider könne weiterhin den DVB-C-Empfang mit der Box deaktivieren:
Code:
cfgfile_ok )
# feature disable over snmp
[COLOR="#008000"] # do not allow feature disabling for retail boxes, see JZ-25211
if [ ${OEM} == "avm" ]; then
echo "$0: Preventing remote disabling of features"
exit 0
fi
[/COLOR]
Das ist tatsächlich neu - hier wurde offenbar "mitgedacht" bei der Retail-Firmware (es ist die 06.61).
Wie das mit TR-069 aussieht, wird die Zukunft zeigen ... die
eRouter-Spezifikation verlangt in Anhang C seit 2011 die Existenz eines TR-069-Stacks, zumindest in Richtung KNB (operator facing) und wir wissen von anderen Geräten (bzw. aus früheren leidvollen Erfahrungen mit einigen KNB, ich persönlich mit einem bestimmten), welche Möglichkeiten der Provider dort über diese Schnittstelle hat ... das war ja auch für andere (und nicht nur für mich persönlich) desöfteren ein Grund für einen Herzkasper. Die meisten der dort aufgeführten Profile sind trotzdem nur "MAY", also nicht unbedingt erforderlich (MUST) - auch wenn sie bei AVM natürlich vorhanden sind.
Wenn das nicht ordentlich deaktiviert wurde in den Retail-Firmwares (das ist durch bloßes Starren auf den (überwiegend binären) Code nicht wirklich zu erkennen, da sieht man halt nur, daß es
vorhanden ist), dann warte ich eigentlich nur auf den ersten Provider, der "versehentlich" eine kundeneigene FRITZ!Box auch mal kurzerhand zurücksetzt, weil der Support es nicht anders gewohnt ist.
Wie weit das ansonsten noch ginge - vom "Download" für neue Konfigurationen - vielleicht auch VPN-Konfigurationen, die "Anlagen" sind ja vorhanden - bis zum "Upload" von Diagnosedaten (bzgl. "emailnotify:settings/supportdata_enhanced" kann ich z.B. auf Anhieb(!, das braucht noch Analyse/Tests) mal keine "Sonderbehandlung" finden bei der 06.61, falls die Daten über TR-069 abgerufen werden sollten) - wird auch erst zu klären sein ... die generelle Seite zum Deaktivieren von TR-069 unter "Anbieterdienste" sollte zwar vorhanden sein bei der 06.6x, dürfte aber bei einem eDOCSIS-Gerät gemäß der Spezifikation in einige "Stürme" geraten, wo das "Kurshalten" auch mal Ansichtssache ist.
So wird z.B. für
eDOCSIS-Geräte (Punkt 5.2.4) vorgeschrieben, daß diese beim DHCP die Option 43 unterstützen
müssen (Seite 33) ... allerdings nur die Sub-Optionen 2 bis 10 und somit wäre die Unterstützung der Sub-Option 1 (die setzt den ACS für TR-069) eigentlich optional. Das ist auch ein Punkt, der bei AVM (zumindest bei den DSL-Modellen) umgeschaltet werden kann - aber er ist erst einmal vorhanden. Wenn es jetzt keine Möglichkeit zur Umschaltung der "Anbieterdienste" im GUI gäbe, könnte man auch nicht umschalten.
Da hat AVM aber ebenfalls Vorsorge getroffen und mit der Zeile
Code:
local cable_retail = config.DOCSIS and config.oem == "avm"
letztlich sogar alle DOCSIS-Geräte als Retail-Box "geadelt", solange sie ein Branding "avm" verwenden. Das ist auch keine "Spezialität" der 06.61 für die 6490, diese Zeile steht auch bei der 7490 (ab 06.69) in der "providerservices.lua", wie jeder problemlos nachlesen kann (womit dann die Brücke zum "Branding entfernen" wieder geschlagen wäre :mrgreen
.
Taucht diese Zeile irgendwann auch mal in den Provider-Firmware-Versionen für die 6490 auf im Zuge des nächsten Updates (vielleicht ist sie auch schon drin), kann man also (zumindest vorübergehend) auch dort (bei vorhandenen "avm"-Directories in der Firmware an den notwendigen Stellen, was bei "kdg" vielleicht wieder scheitert - ich kenne eben die 06.50 nicht und schon gar nicht in der KDG-Version) diese Seite wieder "hervorzaubern".
Ich würde an dieser Stelle (bei der Steuerung von TR-069) ja zu gerne mal wissen wollen, wie sich die Konfiguration von "aus" in der tr069.cfg und die Möglichkeit des Überschreibens über TLV 2.1 in der eRouter-Konfiguration (Annex B, 3.3.1) durch den Provider zueinander verhalten ... sprich, wer da die Oberhand gewinnt, wenn der Provider eben doch ein "true" für das "EnableCWMP" über die eRouter-Konfiguration "befiehlt".
Egal, die AVM-Änderungen führen dann zumindest zur Anzeige der "Anbieterdienste"-Seite ... und da wartet dann auch schon die nächste Überraschung (alles noch die Datei aus der Labor-Version für die 7490, aber eben erst seit der 06.69) - mir ging es zumindest so:
Code:
function writehtml_snmp_enabled()
if cable_retail then
html.hr{}.write()
html.div({class = "formular"},
html.input({
type = "checkbox", name = "enable_snmp_on_wan", id = "uiEnableSnmp",
checked = box.query("[COLOR="#FF0000"]remoteman:settings/enable_snmp_on_wan[/COLOR]") == "1"
}),
html.label({["for"] = "uiEnableSnmp"},
[[{?8636:182?}]]
),
html.p({class = "form_input_explain"},
[[{?8636:127?}]]
)
).write()
end
end
Hier war ich tatsächlich verblüfft (und dachte zuerst fälschlicherweise schon an SNMP auch bei den anderen Modellen, als ich das zum ersten Mal sah), denn auch das Vorhandensein von SNMP auf der WAN-Seite (operator faced) ist eigentlich "mandatory" ... aber hier wird wohl doch nicht das eCM gemeint sein (also das Modem), sondern der
eRouter. Wobei ich auch hier (wohl wieder aufgrund einer falschen Interpretation des Standards) bisher der Meinung war, der eRouter müsse zumindest einige "basics" (Anhang A und B der eRouter-Spezifikation) immer unterstützen (und natürlich nicht nur "bereithalten", sondern auch "bereitstellen").
Damit hinterläßt diese Option bei mir die berühmten Fragezeichen in den Augen ... mal sehen, was der AVM-Support dazu schreiben wird, was damit nun genau "disabled" wird ... nicht gleich, es gibt noch einige weitere Punkte, wo mehr Fragen auftauchen als bisher (vom Handbuch oder der KB) beantwortet werden und bei den Retail-Modellen zieht dann auch die Aussage "Wenden Sie sich an den Provider." nicht mehr; also erst einmal sammeln und dann (mit der richtigen Seriennummer!) als Support-Anfrage absetzen.
Es ist sicherlich auch für AVM nicht ganz einfach, den Schritt von der FRITZ!Box für den Provider hin zur FRITZ!Box für den Kunden zu vollziehen ... insbesondere das Berücksichtigen von schutzwürdigen Interessen des Kunden wird bei den weitreichenden Zugriffsmöglichkeiten der DOCSIS-Spezifikation (wobei auch da vieles eben "MAY" ist und ggf. früher implementiert wurde, weil es ein "Schmankerl" für den Provider war, heute dann u.U. ein "SHOULD NOT" oder "MUST NOT" bei einer Retail-Box ist oder zumindest konfigurierbar sein sollte) nicht ganz einfach sein und irgendwie erwarte ich da am Beginn geradezu auch Fehler - solange diese dann auch irgendwann abgestellt werden.
Auf der anderen Seite hat AVM da wohl auch mit einem ziemlich "harten Besen" gekehrt in der Retail-Version ... die (früher zumindest) in der Provider-Firmware zu findenden Möglichkeiten der Konfiguration des eMTA über PACM (da wurden dann u.a. die Telefonnummern gesetzt) sind auf Anhieb in der 06.61 gar nicht zu sehen.
Fehlt das alles (auch die "libpacm*"-Bibliotheken fehlen alle), dann wäre es u.U. sogar wieder denkbar, daß der Provider die Telefonie-Einstellungen tatsächlich gar nicht konfigurieren könnte, selbst wenn er das wollte und es nicht nur ein "willst Du meine Box nicht, sieh zu, wie Du klarkommst" ist.
Das verhindert natürlich auch gleich, daß ein etwas schusseliger Support-Mitarbeiter bei einem KNB dann tatsächlich quasi auf Knopfdruck die (mühsam ausgewürfelten) Telefonie-Einstellungen des Kunden killt - vielleicht war ja die WLAN-Pleite bei KDG im Nov. 2015 auch AVM eine Warnung.
Mich würde mal interessieren, wie das tatsächlich in der 06.50 aussieht, was die PACM-eMTA-Konfiguration angeht - ich kann mir irgendwie nicht vorstellen, daß AVM das alles kurzerhand komplett umgestellt hat (und vor allem nicht, worauf). Wenn also ein 06.50-Besitzer mit "console access" mal freundlicherweise nachschauen könnte, ob es dort noch eine /usr/sbin/pacm_mta_control gibt (nicht die pacm_state_changed, die ist als Überbleibsel auch bei der 06.61 noch vorhanden - nur halt niemand, der sie aufrufen würde), wäre ich ihm/ihr dankbar.
