[OT] Automatische Updates

hermann72pb · 22 Jul 2015

PeterPawn · 22 Jul 2015

hermann72pb schrieb:
Erkennt ihr da irgendwo einen Parameter, der mir die Sicht versperrt, dass ich die automatische Updates deaktivieren kann?

Ich behaupte mal (ohne Garantie auf Richtigkeit meiner Vermutung), daß Du nur an der falschen Stelle in der FRITZ!Box suchst. Wenn Du unter "System/Update" das automatische Aktualisieren abstellst, sollte das schon mal die beiden "auto_update_*"-Parameter der ar7.cfg betreffen.

Ansonsten gäbe es noch TR-069-Einstellungen, aber daß ein Provider bei der 7490 selbst "normale Updates" ausliefert über TR-069, wäre neu ... da wäre dann der Provider als "Warnung" für andere Kunden ja nicht uninteressant. Warum Du den Namen des Providers "unkenntlich" machst, hat sicherlich seinen Grund ... aber es macht fundierte Antworten natürlich auch wesentlich schwieriger.

Jedenfalls brauchst Du für die geplanten Änderungen eher keinen nvi oder einen anderen Editor ... wenn Du auch in der "Experten-Ansicht" bei "System/Update" keine Registerkarte "Automatisches Update" haben solltest, wäre das ein vollkommen neues "customizing" des FRITZ!OS durch einen Provider.

Hans Juergen · 22 Jul 2015

Warum Du den Namen des Providers "unkenntlich" machst, hat sicherlich seinen Grund

Aber wozu das Ganze? In der Signatur steht er dann...
Wenn deine Konfiguration der FB genauso überlegt war... :-Ö

PeterPawn · 22 Jul 2015

Hans Juergen schrieb:
In der Signatur steht er dann...

Das wird eh nicht stimmen ... da ist eine 7490 gar nicht erwähnt und seit wann verwendet 1&1 "provider-additive"-Konfigurationen?

Hans Juergen · 22 Jul 2015

Glaub mir, ich bin schon etwas länger hier unterwegs und weiß, was ich sage.

Ein absolutes Totschlagargument... Aber bei dem, was du tust bist du nicht so sicher...

Hier in meinem letzten Fall war ich selbst schuld.

Hans Juergen · 22 Jul 2015

Nein, keine OT-Laberei. DU bist derjenige, der Behauptungen in den Raum stellst und nur vom Bauchgefühl unterlegst. Und deine Signatur weist in eine Richtung, die nach deinen nachfolgenden Posts offenbar falsch ist. DU solltest dir ernsthaft Gedanken machen, ob dieses Verhalten redlich ist...

PeterPawn · 22 Jul 2015

@hermann72pb:
1. Das ist ziemlich sicher das erste Mal, daß hier eine in dieser Form angepaßte 7490 auftaucht, zumindest habe ich noch nichts in dieser Richtung gelesen und Du hast ja offenbar bei Deiner Benutzung der Suchfunktion auch nichts dazu gefunden, sonst hättest Du ja nicht mehr fragen müssen. Mehr habe ich nicht geschrieben und wenn Du das Fehlen der Registerkarte "Auto-Update" (die ist bekanntlich relativ neu und erst seit 06.20 vorhanden) einfach definitiv erwähnt hättest, wärst Du auch von meiner Antwort in dieser Richtung verschont geblieben.

Schon die Frage

Zumindest finde ich die Einstellung nicht mehr bei den frisch draufgebügelten 06.30. Ist es bei euch auch so?

ist ja im Lichte Deiner weiteren Erläuterungen offensichtlich unsinnig ... es weiß niemand hier, bei welchem Provider Du überhaupt bist (womit die Frage sich eigentlich nicht an andere Kunden desselben Providers richten kann) und wenn es bei allen Benutzern der 06.30 diese Einstellung nicht mehr geben würde, wäre das sicherlich schon jemand anderem aufgefallen.

Angesichts Deines "Dienstalters" wirst Du ja hoffentlich vorher mal die Suchfunktion bemüht haben und dabei ja eher keine entsprechenden Funde gemacht haben, oder? Was sollte man Dir auf diese Frage also antworten bzw. welche neuen Erkenntnisse (jenseits von Gelaber und Mitleid) erwartest Du durch Antworten auf diese Frage zu gewinnen?

Wäre "Nein, bei mir ist diese Einstellung noch vorhanden." die erschöpfende Antwort gewesen, die Du Dir erhofft hast?

2. Die von Dir angeführten Einstellungen werden jedenfalls von der "Auto-Update"-Funktion verwendet, die es erst seit der 06.20-Release bzw. der Labor-Version davor gibt.

3. Wieso Du dann nach "nvi" und dem richtigen Vorgehen fragst und das nicht einfach per ctlmgr_ctl oder über das Lua-Variableninterface einstellen willst, anstatt Dich u.a. mit dem ar7-Caching des ctlmgr herumzuschlagen, wird sicherlich auch seinen guten Grund haben ... für die "Allgemeinheit" (der Kunden Deines Providers?), der Du mit dieser Frage helfen wolltest, wäre die Verwendung von "nvi" anstelle der angeführten Interfaces jedenfalls eher komplizierter. Die für ctlmgr_ctl zur Änderung dieser Einstellung notwendigen Angaben gibt es irgendwo in einem 06.10-Labor-Thread vor einem Jahr.

EDIT: Nach einer Suche zu diesem Thema habe ich sogar noch gefunden, welche Voraussetzungen überhaupt erst einmal erfüllt sein müssen, damit die "Auto-Update"-Registerkarte angezeigt wird. Angesichts Deiner Verve, mit der Du hier deutlich machen willst, daß es eine Änderung seitens Deines Providers ist, hast Du ja sicherlich die Voraussetzungen geprüft und nur vergessen, auch dieses zu erwähnen. Das kann hier aber niemand riechen und keiner wollte Dich hier "zur Sau" machen ... das erledigst Du - meine Meinung - mit Deiner überzogenen Reaktion ganz von alleine.

4. Was Du an meiner ersten Antwort jetzt unsachlich und off-topic gefunden haben magst, bleibt für mich auch Dein Geheimnis ... ich will es auch nicht wissen. Schönes Leben noch ... ich werde das hier gemäß Deinem Wunsch nicht in eine Laberrunde verwandeln.

Hans Juergen · 22 Jul 2015

3. Mich hat geärgert, dass ihr TROTZDEM auf diesem Provider rumreitet.

Hhmm, deine Signatur hast du jetzt verändert... offenbar hast du deinen Fehler jetzt auch gesehen... auf wem sollen wir jetzt herumreiten...? Die Informationen aus #1 sind immer komplett zu sehen, und da war von dir ein Provider konkret benannt.

PeterPawn · 23 Jul 2015

hermann72pb schrieb:
5. Erst im Posting #9 bekam ich inhaltliche Antworten, wofür ich mich hier natürlich auch bedanke. Um diese Antoworten zu generieren, hätte es eindeutig gereicht, die Informationen aus #1 zu analysieren, anstatt zu labern

Ungeachtet Deines Dankes hast Du offenbar den Schuß nicht gehört ... den Dank kannst Du Dir damit auch sonstwohin stecken.

Schon die Tatsache, daß man Deinen ersten Beitrag erst analysieren muß (Deine Wortwahl), um die relevanten Informationen darin zu finden (die einzige Hervorhebung ist ein rotes "no"), zeigt offensichtlich nur, daß Du einfach die Frage falsch gestellt hast.

Du würdest von mir genau dieselbe Antwort wie in #2 jederzeit wieder erhalten. Nicht ich habe die Information, daß die "Auto-Update"-Registerkarte nicht vorhanden ist, ausgelassen ... das warst immer noch Du und wenn man dann mal Dein "Gelaber" (wenn Du das anderen vorwirfst, wirst Du auch damit leben müssen, wenn man Deine Ausschmückungen so bezeichnet) aus #1 beiseite läßt, bleibt da nur Unsicherheit, warum Deine Box ein automatisches Update gemacht hat und die Frage Deinerseits, was man dagegen tun kann.

Was ich gerne wissen wollte: Erkennt ihr da irgendwo einen Parameter, der mir die Sicht versperrt, dass ich die automatische Updates deaktivieren kann?
[...]
Meine Fragen dazu: Geht es immer noch mit dem alten guten nvi? Oder muss ich es irgendwie anders machen? Reicht diese eine Option eurer Meinung nach oder habe ich was vergessen?

Da fehlt jede Information zur 7390 (was hinsichtlich des Auto-Updates ohnehin nur entfernt vergleichbar ist), zur Kenntnis der Auto-Update-Funktion an sich, usw. ... wenn wir uns das alles "denken" sollen, darfst Du Dich über "Gelaber" nicht wundern.

Auch die Frage (oder ist das Deinerseits auch "Gelaber" gewesen?)

Interessanter Weise standen da in dieser "addon-ar7.cfg" alle Zugangsdaten im Klartext... Ist eigentlich Frechheit. Wofür schraubt dann AVM die ganze Sicherheit mit ar7.cfg hoch... Aber egal, anderes Thema.

hättest Du Dir bei ein wenig eigener Überlegung sparen können.

Bekanntlich werden die Daten in den Einstellungsdateien mit von der konkreten Box abgeleiteten Parametern verschlüsselt.

Wenn der Provider da also verschlüsselte Angaben in die zusätzlichen Konfigurationsdateien schreiben würde, wären die genau auf einer einzelnen Box gültig oder er müßte tatsächlich für jeden einzelnen Kunden die Box entsprechend vorbereiten.

Da das ohnehin eher keine kundenspezifischen Zugangsdaten sind, die dort verwendet werden (auch das Login in den APN bei einer Mobilfunkverbindung ist z.B. nicht kundenspezifisch, Du bist also nicht der einzige Kunde mit dem Benutzernamen "t-mobile", wenn Du Dich dort für mobilen Internetzugang anmeldest) und die Leitung zu einem BRAS des Providers führen dürfte (ist m.W. bei O2-DSL auch so, daß dort nur generische Zugangsdaten stehen), ist da also gar kein Zusammenhang mit der Frage "Wofür schraubt dann AVM die ganze Sicherheit mit ar7.cfg hoch" nachzuvollziehen ... vollkommen abgesehen davon, daß wohl niemand versteht, wie AVM das machen sollte, "die ganze Sicherheit mit ar7.cfg hochzuschrauben". Wenn Du damit den Wegfall der Möglichkeit der Dekodierung der verschlüsselten Daten (früher mit allcfgconv möglich) meinst, schreib das doch einfach so hin ... dann braucht man das auch nicht "zu analysieren".

Was man von der Feststellung "Ist eigentlich Frechheit." jenseits der weiteren Interpretationsmöglichkeiten (vielleicht "i" statt "ch" und mehr als Grundrecht?) halten soll, muß ohnehin jeder Leser selbst entscheiden.

Und um auch noch auf die Frage "habe ich etwas vergessen?" einzugehen: "Ja, offenbar Deine 'Kinderstube' - ich unterstelle mal, daß Du eine ha(tte)st."

er13 · 23 Jul 2015

Hallo Hermann,

in /usr/www/avm/menus/menu_show.lua steht:

Code:

local manageUpdate=box.query("tr069:settings/UpgradesManaged")
...
menu.exists_page["/system/update_auto.lua"] = function()
if not config.GUI_AUTOUPDATETAB or "1" == manageUpdate or "1" ~= box.query("box:settings/allow_background_comm_with_manufacturer") then
return false
end
return not config.DOCSIS
end

wobei GUI_AUTOUPDATETAB scheinbar zur Firmware-Build-Zeit gesetzt wird (Ausschnitt aus /usr/www/avm/lua/guiflags.lua):

Code:

flags.GUI_AUTOUPDATETAB = false // vermutlich immer da
flags.GUI_AUTOUPDATETAB = true  // vermutlich Build spezifisch

In /usr/www/avm/system/update_auto.lua selbst findet dann ein Redirekt statt, falls die Bedingung nicht erfüllt ist:

Code:

if not menu.check_page( "system", "/system/update_auto.lua") then
require("http")
require("href")
http.redirect(href.get("/home/home.lua"))
end

Mit anderen Worten, es ist vermutlich "tr069:settings/UpgradesManaged", die dazu führt, dass die Seite ausgeblendet wird. config.DOCSIS dürfte nur bei Kabelmodem-Boxen gesetzt sein und "1" ~= box.query("box:settings/allow_background_comm_with_manufacturer") wäre (unter Annahme, dass es sich dabei um ein Boolean und kein Enum handelt) gleichbedeutend mit "0" == box.query("box:settings/allow_background_comm_with_manufacturer"), was ich wiederum als "ist eine Kommunikation mit dem Hersteller überhaupt zulässig" interpretieren würde. Wenn diese nicht zulässig ist, dann ergibt auch eine Seite mit AutoUpdate-Einstellungen nicht viel Sinn.

Es gilt zu verstehen, wie dieses "tr069:settings/UpgradesManaged" gesetzt wird und ob es sein kann, dass dieses als default den Wert 1 hat. In meiner tr069.cfg ist diese Option explizit vorhanden. In Deiner fehlt diese komischerweise.

VG,
Gene

p.s. alle Untersuchungen auf Basis der 113.06.30 vom AVM's FTP. Weiß nicht, ob es providerspezifischen Firmware-Builds für 7490 gibt und Du eben nach dem AutoUpdate auf 06.30 einen providerspezifischen Build drauf hast, wo das Ganze irgendwie anders geregelt wird und Deine tr069.cfg daher anders aussieht.

PeterPawn · 23 Jul 2015

Ich erlaube mir mal die Zusammenfassung, daß sich gegenüber dem Stand hier eigentlich nichts geändert hat.

Wenn man einfach die betreffenden Einstellungen anschaut, sollte sich die Ursache der fehlenden Registerkarte ja problemlos ermitteln lassen.

Wenn jemand hingeht und von Hand oder über die ~~Support-Seite~~ Service-Seite die Einstellung "allow_background_comm_with_manufacturer" ändert, ändern sich dabei nicht automatisch auch die Einstellungen unter "auto_update_*".

Bliebe also die Frage, wie diese Einstellung zum Zeitpunkt des Updates aussah - wenn die Firmware die generelle Festlegung zur Hintergrund-Kommunikation ignorieren sollte, wäre das sicherlich ein Fehler. Wenn diese Kommunikation erlaubt ist, wäre die Frage, welcher Punkt zur "Nichtanzeige" führt.

PeterPawn · 23 Jul 2015

Für weitere Leser, die ggf. vor demselben Problem stehen (auch wenn man anhand des Thread-Titels ja nicht automatisch auf die Suche nach der Registerkarte "Auto-Update" schließen würde):

Es gibt ja (auch nach den Ausführungen in #16) nur drei Bedingungen, die die Anzeige der Auto-Update-Seite in menu_show.lua verhindern könnten.

1. Die Variable "GUI_AUTOUPDATETAB" ist nicht gesetzt.

2. "manageUpdate" (ausgelesen aus tr069:settings/UpgradesManaged) ist "1".

3. box:settings/allow_background_comm_with_manufacturer ist nicht "1".

Punkt 1 kann man beruhigt ausschließen, sowohl hier als auch von er13 in #13 wird festgestellt, daß diese Variable statisch gesetzt wird und nicht durch eine Einstellung zu beeinflussen ist.

Punkt 2 kann es offenkundig ebenfalls nicht sein. Wenn "manageUpdate" den Wert "1" hätte, würde weder die Seite /system/update.lua noch /system/update_file.lua angezeigt werden, wie der folgende Code aus menu_show.lua (113.06.30) offenbart:

Code:

local manageUpdate=box.query("tr069:settings/UpgradesManaged")
[COLOR="#FF0000"]menu.exists_page["/system/update.lua"] = function()
if (manageUpdate=="1") then
return false
end
return not config.DOCSIS
end
menu.exists_page["/system/update_file.lua"] = function()
if (manageUpdate=="1") then
return false
end
return not config.DOCSIS
end
[/COLOR]menu.exists_page["/system/update_auto.lua"] = function()
if not config.GUI_AUTOUPDATETAB or "1" == manageUpdate or "1" ~= box.query("box:settings/allow_background_comm_with_manufacturer") then
return false
end
return not config.DOCSIS
end

Das ist aber beim TE durchaus nicht der Fall, wie der Screenshot in #5 deutlich zeigt. Damit kann diese Ursache eigentlich auch schon ausgeschlossen werden.

Bleibt also noch Punkt 3, den man - wie schon weiter oben bemerkt - von Hand entweder mit dem AVM-Variableninterface oder einem Editor in der ar7.cfg oder per GUI über die Seite "services.lua" verändern kann:
Anhang anzeigen 82889
Nachdem die Änderung der Abfrage beim TE ja nach der Aussage in #16 den gewünschten Erfolg erbringt, kann es also nur noch Punkt 3 sein, der die Anzeige verhindert.

tl;dr:
Auch wenn der in #16 beschriebene Weg sicherlich ebenfalls funktioniert ... für die meisten Anwender dürfte das Setzen der oben gezeigten Einstellung der bessere Weg sein, um an die Anzeige der betreffenden Seite zu gelangen.
Auch für Freetz sollte diese Einstellmöglichkeit ausreichend sein ... ein zusätzlicher Patch, um diese Seite in jedem Falle anzuzeigen, macht m.E. nicht wirklich Sinn und greift - wie man an anderen Patches des GUI sieht - früher oder später auch ins Leere.

Warum am Ende beim TE trotzdem ein automatisches Update erfolgte, steht auf einem anderen Blatt ... eigentlich sollte man ja davon ausgehen können, daß anhand der in #1 dargestellten Einstellungen

Code:

unattended_update {
[...]
        auto_update_enable = yes;
        auto_update_all_enabled = no;
}

die GUI-Auswahl "Über neue FRITZ!OS-Versionen informieren und notwendige Updates automatisch installieren (Empfohlen)" aktiviert ist (intern ist das "update_important" bei den ctlmgr-Settings). Da das Update (meines Wissens) von AVM nicht als "notwendig" gekennzeichnet wurde, ist das zumindest komisch, wenn die Box es bei dieser Einstellung von selbst installiert.

Das ist hier wohl der erste Thread, wo ein automatisches Update auf 06.30 beschrieben wird und bei Standard-Einstellungen für den Update-Check (168 Stunden) sollten inzwischen viele weitere Kunden betroffen sein. Das Update erschien am 16.07.2015, heute abend sollte eigentlich jede Box einmal auf ein vorhandenes Update gecheckt haben, seitdem diese Version verfügbar ist.

Die Standard-Einstellung bei AVM ist jedenfalls "update_important", wie man an dieser Stelle in "update_auto.lua" sehen kann:

Code:

g_update_mode = box.query("updatecheck:settings/auto_update_mode")
g_update_modes = {check=true,update_important=true,update_all=config.AUTOUPDATE}
if not g_update_modes[g_update_mode] then
g_update_mode = "update_important"
end

Solange also niemand da die Einstellung "update_all" vornimmt, sollte so eine FRITZ!Box kein automatisches Update auf eine "normale neue Version" machen - das Ergebnis der Standard-Einstellung (update_important) ist jedenfalls genau die oben gezeigte Kombination aus "auto_update_enable" und "auto_update_all_enabled".

Auch sollte natürlich ein Wert von "nicht 1" für "allow_background_comm_with_manufacturer" das automatische Update ohnehin unterbinden ... und nachdem das als einziges Merkmal für die fehlende Anzeige der Auto-Update-Seite übrig bleibt (s.o.), könnte man - sofern man der Schilderung in #1 folgen will - eigentlich nur noch schlußfolgern, daß diese Einstellung nicht richtig berücksichtigt wird (das erklärt immer noch nicht, warum das Update beim TE als "notwendig" erachtet wurde von der Firmware).

Wenn AVM da tatsächlich die Bedeutung des Updates "hochgestuft" haben sollte, werden wir ja in den nächsten Tagen noch einige solcher Meldungen kriegen ... ansonsten funktioniert entweder die Firmware nicht (dann ist es auch egal, ob man die "Auto-Update"-Seite zur Anzeige bringt und was man da einstellt) oder die Schilderung in #1 paßt nicht zu den angeführten Punkten oder die Ansage in #15, daß es sich bei den geposteten Einstellungen nicht um die richtigen Werte handelt, geht weiter als man das auf den ersten Blick vermuten würde.

Ansonsten bliebe halt noch eine komplette Fehlfunktion des FRITZ!OS beim TE; es ist ja nicht nur eine einzelne Merkwürdigkeit. Außer es reduziert sich eben doch auf die Unwirksamkeit von "allow_background..." (damit Auto-Update nicht angezeigt wurde, muß das ja "nicht 1" gewesen sein) bei der Suche nach Updates und es war auch noch "auto_update_all_enabled" gesetzt (sonst dürfte - theoretisch - 06.30 nicht automatisch installiert werden) ... ob das dann am "Freetzen" liegt oder nicht, kann man auch nur spekulieren. Warum das dann bei diesen Einstellungen (die auch bei vielen anderen Freetz-Usern so vorhanden sein dürften) nicht viel häufiger auftritt, ist die große Frage ... es werden ja nicht alle Freetz-User innerhalb der "check time" sofort auf ein neues Image auf der Basis der 06.30 gewechselt sein.

EDIT: Nachdem nun #1 alle inhaltlichen Beiträge von hermann72pb in diesem Thread komplett verschwunden ~~ist~~sind, wird zwar der Zusammenhang nicht mehr klar, wenn man erst später hier liest ... aber ich lasse das trotzdem stehen.

andiling · 23 Jul 2015

Zum besseren Verständnis der OP:

Automatisches Update wieder zugeschlagen

Heute hat es mich wieder erwischt... Automatisches Update vom Provider, AVM oder wem auch immer. Meine schöne alte "7490_06.24-freetz-devel-13015.de" mit dem damals aktuellen Trunk Mitte März dieses Jahres ist weg. Ich hatte ja um Jahreswechsel den Provider gewechselt und wahrscheinlich vergessen bei der neuen Box dieses "Feature" abzustellen. Mittlerweile bin ich sogar der Meinung, dass die Einstellung von mir bewusst versteckt wurde. Zumindest finde ich die Einstellung nicht mehr bei den frisch draufgebügelten 06.30. Ist es bei euch auch so?
Während mein aktuelles Freetz gerade durchkompiliert, habe ich mich auf die Suche gemacht und die letzte FREETZ-Sicherung ausgepackt. Fakt ist, dass der lokale Provider keinen Branding benutzt, sondern eine provideradditive.tar, die ich in der FREETZ-Sicherung unter /var/flash gefunden habe. In dem Archiv sind ar7.cfg und tr069.cfg drin mit dem entsprechend "additiven" Inhalt. Ich poste mal den Inhalt hier:

Code:

/* * /var/flash/ar7.cfg * Sat Jan 1 01:00:00 2000 */ ar7cfg { mode = dsldmode_router; active_provider = "Mein_Lokaler_Provider"; vccs { VPI = 1; VCI = 32; dsl_encap = dslencap_pppoe; } dslifaces { name = "internet"; stay_always_online = yes; } { name = "voip"; } targets { name = "internet"; local { username = "zensiert"; passwd = "zensiert"; } bProviderDisconnectPrevention = yes; ProviderDisconnectPreventionInterval = 1d; ProviderDisconnectPreventionHour = 4; bProviderDisconnectPreventionHourSet = yes; } { name = "voip"; } dslglobalconfig { autodetect = no; } } // EOF

Code:

/* * /var/flash/tr069.cfg * Sat Jan 1 01:00:00 2000 */ tr069cfg { enabled = yes; igd { managementserver { url = "https://111.222.333.444:1234/zensiert/genericTR69"; ACSInitiationEnable = yes; } } FirmwareDownload { enabled = yes; enabled_converted = yes; } ACS_SSL { verify_server = no; } Download_SSL { verify_server = no; } guimode = guimode_hidden; } // EOF

Interessanter Weise standen da in dieser "addon-ar7.cfg" alle Zugangsdaten im Klartext... Ist eigentlich Frechheit. Wofür schraubt dann AVM die ganze Sicherheit mit ar7.cfg hoch... Aber egal, anderes Thema.
Was ich gerne wissen wollte: Erkennt ihr da irgendwo einen Parameter, der mir die Sicht versperrt, dass ich die automatische Updates deaktivieren kann?

Ich habe eigentlich schon einen Plan, wie ich vorgehe. Wenn FREETZ wieder drauf ist, gehe ich in die ar7.cfg und ändere zunächst

Code:

unattended_update { update_found = yes; running_version = "113.06.20"; no_update_found_time = "1970-01-01 01:00:00"; update_found_time = "2015-01-19 22:12:31"; priority = 1; check_intervall = 168; status = 0; StartTime = "1970-01-01 01:00:00"; enabled = yes; auto_update_enable = yes; auto_update_all_enabled = no; }

in

Code:

auto_update_enable = no;

Meine Fragen dazu: Geht es immer noch mit dem alten guten nvi? Oder muss ich es irgendwie anders machen? Reicht diese eine Option eurer Meinung nach oder habe ich was vergessen?

Und jetzt noch zum Thema, warum es eigentlich hier bei FREETZ platziert ist. Hat sich schon jemand mit dem Thema beschäftigt, so eine Ansicht zu aktivieren (a-la reaktivieren der 2.PVC-Webseite) oder irgendeine andere Möglichkeit zu schaffen, den Parameter zu verstellen. Denn eigentlich ist diese Auto-Update-Funktion kontraproduktiv für einen FREETZ-Nutzer. Und zumindest für einen geneigten Nutzer gehört sie rausgepatcht. Ich persönlich bin schon 2 oder 3 Mal damit auf die Nase gefallen. Natürlich nicht nur bei mir, sondern im Bekannten/Verwandten-Kreis, da wo ich die Boxen betreue. Vor allem die 1und1 waren da in Vergangenheit ganz frech damit unterwegs. Es ist aber dort eher tr069 gewesen. Hier in meinem letzten Fall war ich selbst schuld.

MfG

Languages

Suche

Languages

Suche

[OT] Automatische Updates

hermann72pb

IPPF-Promi

PeterPawn

IPPF-Urgestein

Hans Juergen

Guest

PeterPawn

IPPF-Urgestein

Hans Juergen

Guest

Hans Juergen

Guest

PeterPawn

IPPF-Urgestein

Hans Juergen

Guest

PeterPawn

IPPF-Urgestein

er13

Aktives Mitglied

PeterPawn

IPPF-Urgestein

PeterPawn

IPPF-Urgestein

andiling

IPPF-Promi

Zurzeit aktive Besucher

Neueste Beiträge

Statistik des Forums