Hab hier schon vor längerer Zeit etwas gelesen und auch AVM hat ja auf seiner cati Seite seinerzeit den folgenden Text nicht ohne Grund ganz oben eingeblendet gehabt:
Ich wollte das ja auch nicht bestreiten, daß es Probleme geben
könnte. So einen Text würde ich als Hersteller auch veröffentlichen, wenn ich mit Support-Anfragen von "dummen Usern" (das ist sogar noch eine Stufe unter DAU, insofern bitte nicht als Wertung irgendwelcher Thread-Teilnehmer hier mißinterpretieren) bombardiert werde, die der Meinung sind, eine Firmware paßt für alles oder zu blöd sind, den Unterschied zwischen den Modellnummern eines MT zu begreifen.
Da dort - wie bereits geschrieben - keinerlei Versionskontrolle stattfindet (zumindest keine, die man im Skript-Code sehen könnte und wohl auch keine, die in CS stattfindet, sonst würde das ja als Downgrade nicht funktionieren), ist eben wirklich entsprechende Sorgfalt notwendig. Die Leute, die beim AVM-Support in dieser Angelegenheit aufschlagen, dürften mit einiger Wahrscheinlichkeit schon etwas falsch gemacht haben, die erfolgreichen Versuche werden dort sicherlich eher nicht registriert.
Insofern würde ich diesen Text von AVM nicht wesentlich höher bewerten, als die Warnung vor der Benutzung anderer Tools für Recovery oder vor der Verwendung "fremder Images" oder vor dem Einschalten von Telnet.
Ist aber tatsächlich nur mein Standpunkt und daß es - bei falscher Ausführung, das habe ich jetzt schon mehrfach betont - ein Risiko ist, versteht sich von selbst. Aber das Flashen eines eigenen Kernels mit "ruKernelTool" birgt genau dasselbe Risiko - eine Endlosschleife, die man allerdings sicherlich unterbrechen könnte, denn im Gegensatz zu einem MT gibt es ja immer wieder die Möglichkeit des Bootloaders. Ob und wie so etwas ähnliches bei einem MT umgesetzt wurde, mußte ich glücklicherweise noch nie selbst erkunden - da dort Updates über DECT von der Basis kommen müssen, stelle ich mir das etwas komplizierter vor, aber so etwas wie einen rudimentären Bootloader und eine (interne) Service-Schnittstelle gibt es da garantiert auch ... alles andere wäre als "Umweltsünde" eine extrem schlechte Note wert, ähnlich einem fest mit dem Gerät verklebten Akku, was hier ja hoffentlich auch nicht der Fall ist (ich habe nichts zum "Aufschrauben" eines C4 finden können auf die Schnelle).
Vor dem plötzlichen Stromausfall der Basis bei der Übertragung eines Images ist auch ein "normales Update" nicht gefeit, also wird es dort entsprechende Sicherungsmaßnahmen geben (Integritätsprüfung auf dem MT vor dem Flashen) oder man muß eben mit solchen Problemen rechnen und dann dürfte es mit einigem Aufwand auch für den Hersteller verbunden sein, nun nachzuweisen, daß das ein Downgrade und kein (automatisch angebotenes) Update war, was da aus dem MT einen Briefbeschwerer gemacht hat. Solange da nicht auch zwei Versionen in so einem MT zu finden sind und man damit nachweisen kann, daß die vorhergehende Version schon eine höhere Nummer hatte, fiele mir auch bei intensivem Nachdenken kein Weg ein, wie man das (bei geänderter Firmware, die natürlich für das MT passen muß, das betone ich aber auch extra) nachweisen könnte. Ich nehme aber begründete Vorschläge dazu gerne an ... die Ableitung der Annahme, daß ein MT mit einer bestimmten Nr. (MAC) schon mal eine höhere Version installiert hatte, weil es eine entsprechende Anfrage beim Update-Server von AVM gab, lehne ich aber vorsichtshalber sofort ab; ein Zusammenhang ist nicht zwingend, so ein Request könnte auch "von Hand" ausgeführt worden sein, um eine passende URL für eine Nachfolgeversion zu erhalten (und das muß nicht einmal zwingend vom Besitzer des MT erfolgt sein, eine solche MAC kann ich auch zufällig treffen).
Wenn AVM so ein eigenes Vorgehen durch den Kunden tatsächlich verhindern will, dann muß man eben die Funktion des USB-Updates ausbauen oder mit zusätzlichen Sicherungen versehen. Solange ich als Kunde eine von AVM-signierte Update-Datei mit passendem Namen auf einen USB-Stick an der Box speichern kann und
dann beginnt ein automatischer Vorgang, solange ist AVM auch verantwortlich.
Wenn man dafür die Verantwortung ablehnt, muß man (mir) auch sagen, was ich konkret eben
nicht unternehmen darf, ansonsten ist auch ein "zufälliges Zusammentreffen" nicht auszuschließen (die Wahrscheinlichkeit interessiert dabei gar nicht) und ohne fundierte(!) Warnung vor bestimmten Handlungen (wo dann eben nichts von "Bitte laßt die Finger davon ..." sondern "Machen Sie das und das bitte nicht ..." beschrieben ist) kann mir niemand einen Vorwurf daraus machen, wenn mir so etwas "aus Versehen" passiert.
Will ein Hersteller das verhindern, muß er eben weitere Sicherungen einbauen. Der "spezielle Dateiname" ist genauso wenig ausreichend wie die nunmehr unbedingt erforderliche (auch da hat AVM eben von 06.0x auf 06.20 nachgebessert, von wann der von Dir zitierte Text stammt, weiß ich nicht ... ich kenne die ganze "cati"-Seite nicht) gültige Signatur einer solchen Update-Datei.
Der Inhalt eines solchen Images wird in start_dect_update.sh (kann jeder selbst in seiner Box nachlesen) nur überwindlich geprüft ... kein Wunder, wenn das dort liegende install-Skript die im Image noch mit Versions- und Modellnummer vorliegenden Files einfach als dect.lowfile oder dect.highfile kopiert.
Code:
#! /bin/sh
LOW_FILE_NAME=BOB_de-03.56-03.01.low.bin
HIGH_FILE_NAME=BOB_de-03.56-03.01.high.bin
FW_VERSION=03.56
HW_VERSION=03.01
cp /var/packet/var/BOB_de-03.56-03.01.low.bin /var/dect.lowfile
cp /var/packet/var/BOB_de-03.56-03.01.high.bin /var/dect.highfile
exit 0
Die gesetzten Variablen werden - nur dem Augenschein nach, der dect_manager ist ClosedSource - nicht weiter berücksichtigt(man sieht ja, daß nicht einmal der Dateiname für das Kopieren daraus zusammengesetzt wird), nur so ist (meiner Meinung nach) auch das Downgrade machbar.
Wäre dort noch ein Vergleich mit der aktuellen Firmware-Version des MT enthalten und würde nicht nur anhand von Dateinamen, sondern von Prüfsummen oder Wasserzeichen in den Binärdateien der DECT-Firmware ein Versionscheck ausgeführt, wäre sicherlich auch ein Downgrade schwieriger bis unmöglich.
Solange das alles machbar ist (und zwar ohne "Hacks"), ist das normale Benutzung und solange bei einem auf diesem Weg am MT signalisierten Update nicht ein entsprechender Hinweis auftaucht, kann das der "normale Benutzer" ja gar nicht von einem "regulären Update" seitens AVM unterscheiden.
PS: Daß auch ein manuelles Start der start_dect_update.sh über das Mobilteil machbar ist, war schon klar ... ich wollte eigentlich mehr darauf hinaus, daß es für einen normalen Benutzer auch ohne manuelle Suche (die man ja als Zeichen für die Erwartung, es gäbe ein solches Update auf dem USB-Stick, weil man es selbst dort abgelegt hat, interpretieren könnte) nach spätestens 48 h oder eben ca. 60 Sekunden nach dem Herstellen der Internetverbindung nach einem Neustart der FRITZ!Box auch automatisch signalisiert wird als Update. Und dabei wird m.W. die Versionsnummer des gefundenen Updates sogar angezeigt ... aber offenbar vom MT (oder der Basis) nicht mit der bereits installierten verglichen; ob das absichtlich so ist oder "nur" versehentlich, will ich gar nicht spekulieren.
