[Info] AVM-Autoupdate ... Fluch oder Segen?

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
15,138
Punkte für Reaktionen
1,703
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
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;
}
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
Code:
<ns3:Priority>1</ns3:Priority>
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.
 
Nicht dass du glaubst, dass es keiner gelesen hat... :)

Ich bin ganz bei dir.
Ich war verärgert, als meine "nur notwendige Updates" Auswahl plötzlich mit 6.83 beglückt wurde, obwohl ich dieses bereits seit mehreren Wochen bewusst gemieden habe. Zu meinem Glück funktioniert noch alles einigermaßen (abgesehen von deutlich häufigeren WLAN Ab- und Anmeldungen von einem Client, was vorher definitiv OK war).
Oder hab es eine gravierende Sicherheitslücke, die von 6.51 auf 6.83 geschlossen wurde?
 
Ich bin auch nicht der "Clown vom Frühstück" :p
Mir passt das auch nicht und AVM sollte da mal schnell nachbessern.
 
Zuletzt bearbeitet:
Ich bin auch nicht der "Clown vom Frühstück"
Ich meinte ja auch nicht den anderen Betroffenen ... ich verbinde halt mit "komisch" immer automatisch den alten Witz mit dem Clown zum Frühstück und der Frage, wie der wohl geschmeckt haben mag. War vielleicht mißverständlich formuliert von mir ...
 
Ich habe das nicht falsch verstanden und der Betroffene sicher auch nicht.
Die Formulierung ist TOP, daher habe ich es wiederholt :kasper:
 
Nach 06.60 ist jedes Update eher nen Fluch egal ob manuell oder freiwilliger Zwang. ;)
 
Uber Notwendigkeit des Updates...
Ich weiss nicht ob es damit zu tun hat, aber 7390 v6.3 Boxen funktionieren nicht mehr normal nach ein Provider Upgrade in Holland (ich meine ihre Infrastruktur). DSL funktioniert aber ein IP bekommt der Box nie oder manchmal.


Ein Upgrade nach 6.5i löst dieses Problem aber dann funktioniert WiFi nicht mehr. Die WiFi Schnittstelle ist verschwunden.

Da gerät ersetzten durch ein 7490 war der einzige Lösung die ich zu bieten hätte.
 
Die andere Lösung, die ich zu bieten hätte, wäre das Verbinden mit dem Internet, damit das WLAN Plugin der Fritzbox 7390 Firmware nachgeladen wird.
 
Die andere Lösung, die ich zu bieten hätte, wäre das Verbinden mit dem Internet, damit das WLAN Plugin der Fritzbox 7390 Firmware nachgeladen wird.
Ich versteh dein Antwort nicht...
Der Freetz hat Internet aber kein WLAN mit ein 6.53 firmware...
Mittlerweile hat PeterPawn mich informiert das ein und ander mit tr069 removal zu tun hat.

Trotzdem versteh ich dein Antwort nicht.
 
In deinem Beitrag vorher stand nichts von Freetz. Das AVM-Autoupdate, worum es in diesem Thread hier geht, funktioniert ohne TR-069.
 
Spaßig oder auch traurig ... auch wenn es inzwischen so aussieht, war dieser Thread meinerseits keineswegs eine Reaktion auf einen "News-Artikel" bei AVM: https://avm.de/aktuelles/neues-von-fritz/2017/schon-auf-dem-neuesten-stand/

Als ich den Thread hier eröffnet habe, gab es diese Meldung bei AVM noch gar nicht (zumindest nicht auf der öffentlich zugänglichen Webseite) und auch heute ist sich irgendwie das CMS bei AVM noch nicht so ganz einig, wann dieser Artikel nun erschienen sein soll (oder wäre hier vielleicht "erschienen gewesen sein soll" die bessere (unsaubere) Zeitform?):

aktuelles.PNGWarte nur balde.PNG

Stellt sich am Ende gar die Frage, ob vielleicht der AVM-Artikel eine Reaktion auf meinen Rant ist. :mrgreen: Ich nehme aber nichts zurück ... ein Autoupdate erfordert ein transparentes Vorgehen des Herstellers, sonst ist nicht alte Firmware, sondern der Hersteller selbst das größere Risiko. Wenn da ein böswilliger Mitarbeiter verseuchte Updates ausspielen kann, weil nicht jeder einzelne Schritt penibel (intern) dokumentiert und durch ein "Vier-Augen-Prinzip" abgesichert ist, dann gibt es auch keinen Unterschied, ob nun irgendein Provider den Kunden mit einem Zwangsupdate beglückt (und dabei ggf. auch noch Mist macht - EDIT: ich will nur an entsprechende Vorkommnisse bei Vodafone/KDG erinnern) oder ob das direkt der Hersteller ist.

Wenn da heutzutage (egal wie kurzzeitig das auch sein mag) vom Hersteller falsche Angaben zur Dringlichkeit eines Updates kommen, dann ist es morgen vielleicht (Verschwörungstheorie ein) ein präpariertes Update für einzelne Kunden, die anhand der MAC-Adresse im Update-Check-Request identifiziert werden (Verschwörungstheorie aus). Nur ein (jederzeit und - bei gleichen Bedingungen - von jedem Kunden) reproduzierbares Ergebnis so einer Update-Prüfung kann die Grundlage für eine Überprüfung durch den Kunden sein ... wenn der nach drei Stunden dieselbe Abfrage noch einmal macht und ein anderes Ergebnis erhält, obwohl sich an der Version nichts geändert hat, ist das aber das genaue Gegenteil von "reproduzierbar".

Wenn so etwas aufgrund von Fehlern von Mitarbeitern unabsichtlich geschieht, gehört dazu dann im Nachhinein das Aufdecken der Karten (und ggf. sogar eine Entschuldigung des Herstellers) und nicht das Ausbreiten des Mantels des Schweigens und ein Vertuschen. Ob das hier bei AVM so war oder nicht, kann ich leider nicht detailliert genug beweisen ... aber wenn sich die Stimmen mehren, daß 113.06.30 kürzlich zwangsweise aktualisiert wurde bei Kunden, obwohl diese ebenfalls "nur wichtige Updates" gesetzt hatten, dann wird es auch für AVM deutlich schwerer, diese Kunden alle auf einmal als Spinner abzutun und wenn man den Kunden das Update wirklich ernsthaft als dringend ans Herz legen will, dann sollte man einfach mal deutlich erklären (und zwar auch hier detailliert und nicht mit dem üblichen Geschwafel, was man nun wirklich zur Genüge kennt, wenn man schon ein paar Versionen lang die "info.txt" von AVM für neue Versionen liest - hier rächt sich eben auch, wenn AVM immer nur "ein Wolf, ein Wolf" ruft und nie einen zeigen kann oder will), warum das nun auf einmal ein kritisches Update sein sollte (bei mir rennt man damit ohnehin offene Türen ein, ich betone das seit dem Erscheinen der 06.8x-Reihe), wenn doch eigentlich nur "Verbesserungen" vorgenommen wurden, so man der "info.txt" des Herstellers folgen will.

Die drei Tage Differenz bei der Angabe von AVM zum Alter des Artikels machen auch keinen großen Unterschied, aber beim "Protokollieren" von nachträglichen Änderungen an Webinhalten auf der AVM-Präsenz (zuletzt fiel es (mir) auf bei den Angaben zum Marktstart von 7590 und 6590 in der Pressemitteilung zur CeBIT 2017, die auch im Nachhinein wundersamerweise spurlos "entfleucht" sind) kann man ja gar nicht sorgfältig genug vorgehen - man hat ja hinterher immer wieder Probleme mit der Frage (die man sich mitunter auch selbst stellt), ob man die falsche Brille hatte oder unter Wahnvorstellungen leidet, wenn bei solchen "Nebensächlichkeiten" immer wieder Korrekturen erfolgen, die nirgends kenntlich gemacht sind und eher "heimlich" erfolgen.

Gerade bei "Pressemitteilungen" ist das ja nun ein sehr ungewöhnliches Vorgehen, wenn man den Text im Nachhinein noch einmal ändert, das nicht kenntlich macht und damit ggf. sogar Sinnentstellungen oder Mißverständnisse bei solchen Differenzen provoziert, wo dann ja heutzutage als erstes die Journalisten in den Verdacht geraten, nicht sorgfältig genug recherchiert oder auch nur gelesen zu haben, wenn in einem (unabhängigen (haha)) Artikel am Ende etwas steht, was so eine Pressemitteilung im Nachhinein gar nicht mehr enthält.
 
Zuletzt bearbeitet:
In deinem Beitrag vorher stand nichts von Freetz. Das AVM-Autoupdate, worum es in diesem Thread hier geht, funktioniert ohne TR-069.
Durch ein Link im Freetz Thread war ich hier gelandet. Ich war mich nicht bewusst da es sich um ein anderes Thread handelte.
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.