- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,279
- Punkte für Reaktionen
- 1,754
- Punkte
- 113
Ich bin bestimmt der Letzte, der gegen die AVM-Intention mit einem automatischen Update argumentieren würde - es ist tatsächlich ein Fortschritt für die Boxen, wo deren Besitzer diese einmal konfigurieren und sie ansonsten vergessen und höchstens mal die Dame des Hauses beim Staubwischen versehentlich das WLAN ausschaltet (ehe es negativ auffällt: Ich habe auch nichts dagegen, wenn Männer Staubwischen - solange ich es nicht machen soll.), weil keine Tastensperre aktiviert ist.
Aber so ein Mechanismus setzt dann eben auch voraus, daß man dem Hersteller bzw. dem Anbieter der Firmware vertrauen kann und daß dieser mit dem Vertrauen seiner Kunden (und das ist ein Vorschuß) dann nicht Schindluder treibt.
Warum interessiert mich dieses Thema ausgerechnet heute erneut?
Seitdem ich einmal bei der 7390 für ein eigentlich nur zum Testen benutztes Gerät ein unerwartetes Update erhielt (Sept. 2016) und dabei offensichtlich die Einstellungen bzgl. des Updates von der Firmware nicht beachtet wurden (so zeigen es jedenfalls Sicherungsdateien, die vor diesem Update gespeichert wurden), beobachte ich diesen Mechanismus etwas argwöhnisch ... und richtig - am 15.05.2017 um 09:37:30 Uhr meldete dann der AVM-Service auch, daß für eine Ausgangsversion 113.06.30i (also die internationale 7490) nunmehr ein kritisches Update vorliegen würde (priority=3), welches auch bei der ansonsten vorhandenen Einstellung
nunmehr unbedingt zu installieren wäre.
Das ist aus mehreren Gründen sehr überraschend. Es gab/gibt offiziell nur die Version 113.06.83i und diese gibt es aber bereits seit dem 23.03.2017 - wenn diese also von Beginn an als "kritisches Update" gesehen wurde, dann wäre ein derartiges Update bereits viel früher angesagt gewesen, denn das "check_intervall" oben ist ja auch eindeutig.
Wenn es sich hingegen um kein kritisches Update handelt, stellt sich wieder einmal die Frage, warum das nun auf einmal als solches deklariert wird oder warum die Firmware es trotzdem installieren wollte.
Ich kann jedenfalls auch bei intensivster Suche auf der AVM-Webseite keinen Hinweis finden, warum man nun die Einstellung bzgl. der Dringlichkeit dieses Updates geändert hätte und wann das wieder in die Gegenrichtung ausgeschlagen ist, denn fragt man inzwischen den Update-Service von AVM für genau diese Konstellation erneut ab (von 113.06.30-31156, OEM=avme), erhält man ebenfalls (wie zu erwarten) die Auskunft, daß es die 113.06.83i zwar gäbe - allerdings eben mit
und damit nicht als kritisches Update - und das nenne ich dann ein inkonsistentes Verhalten (vom Hersteller und vom von ihm betriebenen Info-Service). Für die "allerletzte Sicherheit", daß es an den Daten vom AVM-Service lag, bräuchte es zwar noch das "Live-Erlebnis" bei einer solchen Abfrage, aber der oben gezeigte Ausschnitt aus der "ar7.cfg" ist das Resultat dieser Abfrage und infolgedessen hat die Box dann auch in der folgenden Nacht (um 03:24 Uhr) versucht, das Update zu installieren. Die Abfrage des alten Update-Info-Service (wie es eine 06.30 noch machen würde, da gab es noch kein "JUIS") ergibt - nur damit das auch erwähnt wurde - genau denselben Stand (nur halt in anderer "XML-Verpackung") - es liegt also auch nicht an einem Unterschied in der Abfrage zwischen alten und neuen Versionen.
Das Update hat zwar hier gar nicht funktioniert (weil ich solchen unerwünschten Updates selbst einen Riegel vorgeschoben habe und die abgefragte Versionsnummer der Ausgangsversion ohnehin ein "Fake" ist - es gibt verschiedene Boxen bei Kunden, die mir an dieser Stelle quasi als Honeypot für das Erkennen solcher Inkonsistenzen im Autoupdate-Prozess von AVM dienen), aber ich wollte ja auch nach den bisherigen schlechten Erfahrungen nur ermitteln, ob nun der Update-Mechanismus im FRITZ!OS sich falsch verhält (und ein unkritisches Update installiert entgegen der aktuellen Einstellungen) oder ob tatsächlich - wie zuvor nur spekuliert - von AVM inkonsistente Daten veröffentlicht werden, die dann beim Kunden für unbändiges Staunen und mehr oder weniger Zweifeln an sich selbst und an den eigenen Einstellungen führen.
Damit wird von AVM (bei mir zumindest) praktisch jeder Kredit in dieser Richtung verspielt ... wenn es sich nicht nur um einen Honeypot handeln würde und es tatsächlich ein Update (mit dem "Vernichten der Spuren") gegeben hätte (wobei auch Download und Installation noch ausgeführt wurden, ich habe halt nur die Umschaltung von "linux_fs_start" verhindert), wäre es wieder vollkommen unklar, was die Box nun zu diesem Update-Versuch veranlaßt haben könnte.
Wenn der Kunde/FRITZ!Box-Besitzer schon sein "Schicksal" in die Hände des Herstellers legen soll, dann muß dieser auch zwingend sein Vorgehen so gestalten - und das meint auch eine transparente Darstellung für den Kunden -, daß dabei der Vertrauensvorschuß des Kunden sich nicht als Boomerang erweist.
Ich bin also nicht gegen ein automatisches Update der Firmware ... aber wenn der Hersteller dann - wie es hier AVM für mich wieder einmal demonstriert hat - seine Prozesse nicht im Griff hat, dann ist das auch ein Spiel mit dem Feuer und nicht umsonst werden eben in größeren Netzwerken solche Updates i.d.R. nicht direkt vom Hersteller eingespielt, sondern müssen von einem Administrator entsprechend freigegeben werden.
Wenn das mit dem Info-Service von AVM so weitergehen sollte, kann man kaum noch mit gutem Gewissen den Leuten empfehlen, wenigstens die kritischen Updates automatisch von AVM zu beziehen - wobei das sogar wieder davon ausgeht, daß die Einstellung "keine automatischen Updates" tatsächlich von der Firmware fehlerfrei interpretiert wird; auch das widerspricht eigentlich den Erfahrungen (sowohl meinen eigenen als auch denen einiger anderer hier im Forum) beim Update auf 06.5x bei der 7390 (wo es die "alle Updates installieren"-Einstellung ja gar nicht gibt). Wenn diese Angaben zur "importance" (oder "priority") so eines Updates von AVM mehr oder weniger "frei Schnauze" ausgewürfelt werden, ist das jedenfalls in meinen Augen kein wirklich gutes Zeichen.
-Wer auf seiner Box solche Aktionen auch verhindern will (bzw. wem die Installation in der anderen Partition egal ist (ja, wer die vielleicht sogar absichtlich ausführen lassen will, damit er sich den Inhalt hinterher zu Gemüte führen kann) und wer nur die "echte" Umschaltung verhindern will), der kann problemlos über die Datei "/proc/sys/urlader/environment" seine eigene Text-Version mounten (oder auch gleich die "/var/env" nehmen, wo AVM eine Kopie der Datei hält) - man muß dann nur dafür sorgen, daß man da irgendeine Benachrichtigung erhält, wenn die Firmware (nach dem Start aber erst, weil beim Start selbst immer etwas hineingeschrieben wird) dort einen Schreibzugriff ausführen wollte (die Benachrichtigung über "inotify" funktioniert dort) und dann muß man eben selbst dafür sorgen, daß diese "Änderungen" entweder blockiert werden oder in das "richtige" Environment übernommen werden (das meint natürlich ein automatisches Skript und entsprechende Modifikationen der Firmware, keine "Korrekturen" von Hand).
Da es sich dabei nur um eine emulierte Datei im procfs handelt, führt natürlich eine Schreiboperation mit einfacher Umleitung auch dazu, daß nur dieser neue Wert (und obendrein auch nur der zuletzt geschriebene) in der Datei existiert und man muß die dann schnellstens wieder regenerieren. Aber im "normalen Betrieb" sind Schreiboperationen ins Environment dann auch nicht so häufig (wie gesagt, nach dem Start und dem regelmäßigen Schreiben von "ptest" und "firmware_info") - da reicht dann auch so eine simple Lösung zum Abfangen unerwünschter Zugriffe bereits aus und für das "Umbiegen" von "linux_fs_start" im Zuge eines (unerwünschten) Updates funktioniert das allemal.
Aber so ein Mechanismus setzt dann eben auch voraus, daß man dem Hersteller bzw. dem Anbieter der Firmware vertrauen kann und daß dieser mit dem Vertrauen seiner Kunden (und das ist ein Vorschuß) dann nicht Schindluder treibt.
Warum interessiert mich dieses Thema ausgerechnet heute erneut?
Seitdem ich einmal bei der 7390 für ein eigentlich nur zum Testen benutztes Gerät ein unerwartetes Update erhielt (Sept. 2016) und dabei offensichtlich die Einstellungen bzgl. des Updates von der Firmware nicht beachtet wurden (so zeigen es jedenfalls Sicherungsdateien, die vor diesem Update gespeichert wurden), beobachte ich diesen Mechanismus etwas argwöhnisch ... und richtig - am 15.05.2017 um 09:37:30 Uhr meldete dann der AVM-Service auch, daß für eine Ausgangsversion 113.06.30i (also die internationale 7490) nunmehr ein kritisches Update vorliegen würde (priority=3), welches auch bei der ansonsten vorhandenen Einstellung
Code:
unattended_update {
update_found = yes;
running_version = "113.06.30";
no_update_found_time = "1970-01-01 01:00:00";
update_found_time = "2017-05-15 09:37:30";
[COLOR="#FF0000"][B] priority = 3;[/B][/COLOR]
check_intervall = 168;
status = 0;
StartTime = "1970-01-01 01:00:00";
enabled = yes;
auto_update_enable = yes;
auto_update_all_enabled = no;
}Das ist aus mehreren Gründen sehr überraschend. Es gab/gibt offiziell nur die Version 113.06.83i und diese gibt es aber bereits seit dem 23.03.2017 - wenn diese also von Beginn an als "kritisches Update" gesehen wurde, dann wäre ein derartiges Update bereits viel früher angesagt gewesen, denn das "check_intervall" oben ist ja auch eindeutig.
Wenn es sich hingegen um kein kritisches Update handelt, stellt sich wieder einmal die Frage, warum das nun auf einmal als solches deklariert wird oder warum die Firmware es trotzdem installieren wollte.
Ich kann jedenfalls auch bei intensivster Suche auf der AVM-Webseite keinen Hinweis finden, warum man nun die Einstellung bzgl. der Dringlichkeit dieses Updates geändert hätte und wann das wieder in die Gegenrichtung ausgeschlagen ist, denn fragt man inzwischen den Update-Service von AVM für genau diese Konstellation erneut ab (von 113.06.30-31156, OEM=avme), erhält man ebenfalls (wie zu erwarten) die Auskunft, daß es die 113.06.83i zwar gäbe - allerdings eben mit
Code:
<ns3:Priority>1</ns3:Priority>Das Update hat zwar hier gar nicht funktioniert (weil ich solchen unerwünschten Updates selbst einen Riegel vorgeschoben habe und die abgefragte Versionsnummer der Ausgangsversion ohnehin ein "Fake" ist - es gibt verschiedene Boxen bei Kunden, die mir an dieser Stelle quasi als Honeypot für das Erkennen solcher Inkonsistenzen im Autoupdate-Prozess von AVM dienen), aber ich wollte ja auch nach den bisherigen schlechten Erfahrungen nur ermitteln, ob nun der Update-Mechanismus im FRITZ!OS sich falsch verhält (und ein unkritisches Update installiert entgegen der aktuellen Einstellungen) oder ob tatsächlich - wie zuvor nur spekuliert - von AVM inkonsistente Daten veröffentlicht werden, die dann beim Kunden für unbändiges Staunen und mehr oder weniger Zweifeln an sich selbst und an den eigenen Einstellungen führen.
Damit wird von AVM (bei mir zumindest) praktisch jeder Kredit in dieser Richtung verspielt ... wenn es sich nicht nur um einen Honeypot handeln würde und es tatsächlich ein Update (mit dem "Vernichten der Spuren") gegeben hätte (wobei auch Download und Installation noch ausgeführt wurden, ich habe halt nur die Umschaltung von "linux_fs_start" verhindert), wäre es wieder vollkommen unklar, was die Box nun zu diesem Update-Versuch veranlaßt haben könnte.
Wenn der Kunde/FRITZ!Box-Besitzer schon sein "Schicksal" in die Hände des Herstellers legen soll, dann muß dieser auch zwingend sein Vorgehen so gestalten - und das meint auch eine transparente Darstellung für den Kunden -, daß dabei der Vertrauensvorschuß des Kunden sich nicht als Boomerang erweist.
Ich bin also nicht gegen ein automatisches Update der Firmware ... aber wenn der Hersteller dann - wie es hier AVM für mich wieder einmal demonstriert hat - seine Prozesse nicht im Griff hat, dann ist das auch ein Spiel mit dem Feuer und nicht umsonst werden eben in größeren Netzwerken solche Updates i.d.R. nicht direkt vom Hersteller eingespielt, sondern müssen von einem Administrator entsprechend freigegeben werden.
Wenn das mit dem Info-Service von AVM so weitergehen sollte, kann man kaum noch mit gutem Gewissen den Leuten empfehlen, wenigstens die kritischen Updates automatisch von AVM zu beziehen - wobei das sogar wieder davon ausgeht, daß die Einstellung "keine automatischen Updates" tatsächlich von der Firmware fehlerfrei interpretiert wird; auch das widerspricht eigentlich den Erfahrungen (sowohl meinen eigenen als auch denen einiger anderer hier im Forum) beim Update auf 06.5x bei der 7390 (wo es die "alle Updates installieren"-Einstellung ja gar nicht gibt). Wenn diese Angaben zur "importance" (oder "priority") so eines Updates von AVM mehr oder weniger "frei Schnauze" ausgewürfelt werden, ist das jedenfalls in meinen Augen kein wirklich gutes Zeichen.
-Wer auf seiner Box solche Aktionen auch verhindern will (bzw. wem die Installation in der anderen Partition egal ist (ja, wer die vielleicht sogar absichtlich ausführen lassen will, damit er sich den Inhalt hinterher zu Gemüte führen kann) und wer nur die "echte" Umschaltung verhindern will), der kann problemlos über die Datei "/proc/sys/urlader/environment" seine eigene Text-Version mounten (oder auch gleich die "/var/env" nehmen, wo AVM eine Kopie der Datei hält) - man muß dann nur dafür sorgen, daß man da irgendeine Benachrichtigung erhält, wenn die Firmware (nach dem Start aber erst, weil beim Start selbst immer etwas hineingeschrieben wird) dort einen Schreibzugriff ausführen wollte (die Benachrichtigung über "inotify" funktioniert dort) und dann muß man eben selbst dafür sorgen, daß diese "Änderungen" entweder blockiert werden oder in das "richtige" Environment übernommen werden (das meint natürlich ein automatisches Skript und entsprechende Modifikationen der Firmware, keine "Korrekturen" von Hand).
Da es sich dabei nur um eine emulierte Datei im procfs handelt, führt natürlich eine Schreiboperation mit einfacher Umleitung auch dazu, daß nur dieser neue Wert (und obendrein auch nur der zuletzt geschriebene) in der Datei existiert und man muß die dann schnellstens wieder regenerieren. Aber im "normalen Betrieb" sind Schreiboperationen ins Environment dann auch nicht so häufig (wie gesagt, nach dem Start und dem regelmäßigen Schreiben von "ptest" und "firmware_info") - da reicht dann auch so eine simple Lösung zum Abfangen unerwünschter Zugriffe bereits aus und für das "Umbiegen" von "linux_fs_start" im Zuge eines (unerwünschten) Updates funktioniert das allemal.
