Das sollten bei der 7390 nur zwei Optionen sein.
Wobei ich ähnliches erlebt habe ... da es sich um eine (auf "Anderer Anbieter" eingestellte) Box an einem 1&1-Anschluß handelte, kann man auch ziemlich sicher konstatieren, daß AVM an dieser Stelle vermutlich einen ganz ganz kapitalen Bock geschossen hat ("auto_update_enable" stand bei der Box auf "no").
Vorher lief auf der Box eine angepaßte (und zumindest um die mir bekannten Probleme "erleichterte") Version 06.20 - weil es dort die Notwendigkeit gab/gibt, das GUI mit einem älteren Browser zu bedienen.
Die neue Version 06.51 wurde am 22.09.2016 um 10:49:59 gefunden (steht in der gesicherten ar7.cfg in der ersten Push-Mail) und in der Nacht vom 22.09. auf den 23.09. dann zweimal (erfolglos) versucht zu installieren (04:16 und 04:32 Uhr), ohne auf die Einstellung bzgl. des "Auto-Update" Rücksicht zu nehmen.
Am 24.09. um 03:31 Uhr war das Update dann erfolgreich ... für alle drei Zeitpunkte liegen "Gesicherte Einstellungen" als E-Mail vor und für die Nacht vom 24.09. auf den 25.09. ist dann die Änderung des Formats der Push-Mail zu konstatieren.
Im Moment sieht die Antwort auf die neue Update-Abfrage so aus:
Code:
<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Header xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"/>
<soap:Body ID="Body">
<ns2:BoxFirmwareUpdateCheckResponse xmlns:ns2="http://juis.avm.de/updateinfo" xmlns:ns3="http://juis.avm.de/response" xmlns:ns4="http://juis.avm.de/request">
<ns2:ResponseUpdateInfo>
<ns3:ResponseHeader>
<ns3:Nonce>WKRJEHbu7iOQvDY7d4W/Pg==</ns3:Nonce>
</ns3:ResponseHeader>
<ns3:UpdateInfo>
<ns3:CheckInterval>168</ns3:CheckInterval>
<ns3:Found>true</ns3:Found>
<ns3:Name>EXTERN Release P15 2016-04-26 AZI</ns3:Name>
<ns3:Version>84.06.51</ns3:Version>
<ns3:Type>1</ns3:Type>
<ns3:DownloadURL>ftp://ftp.avm.de/fritz.box/fritzbox.fon_wlan_7390/firmware/deutsch/FRITZ.Box_Fon_WLAN_7390.AnnexB.84.06.51.image</ns3:DownloadURL>
<ns3:InfoURL>ftp://ftp.avm.de/fritz.box/fritzbox.fon_wlan_7390/firmware/deutsch/info.txt</ns3:InfoURL>
<ns3:InfoText>PERL 15 EXTERN</ns3:InfoText>
<ns3:HintURL/>
<ns3:IconURL/>
<ns3:Priority>1</ns3:Priority>
<ns3:AutoUpdateStartTime>0</ns3:AutoUpdateStartTime>
<ns3:AutoUpdateEndTime>0</ns3:AutoUpdateEndTime>
<ns3:AutoUpdateKeepServices>true</ns3:AutoUpdateKeepServices>
</ns3:UpdateInfo>
</ns2:ResponseUpdateInfo>
</ns2:BoxFirmwareUpdateCheckResponse>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
<Reference URI="#Body">
<Transforms>
<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
<DigestValue>g3UQmBBIMQtwEhge1fMXlpbuRpZGGzL4DyEI8PR4RSk=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>ezrAb4KycIdHjgpQvuZ5ExwzMtZczuw5lLyko1fRDK2TAuGWyboltx7IT2wMP0l+UUYPEba1mYCgrw8114fKitK6h+NRNfKDsJOMNmGnn3shbjItuab3JRu9GMDvrkJSOlrVvhwOGs22kF9RUIuJomSyVoDTs6Q4a8O432avC2mI8PNxXiUmKbH9kfrzL5ZRQGfhHPTyXs0BYT3RwArQqoKe8zgDyQ5nkWhj8KrO8t6HU/OQpP9skbPkuQZhQ8S2SXvowHsnK24oOFdKPjzkPs631aOE1gjlDfavDmGNGe3Vg2cqXNgNbsDvD9awD7j+LGO/gt8tzmiyUNRrZ44h2w==</SignatureValue>
</Signature>
</soap:Body>
</soap:Envelope>
, allerdings fragt ältere Firmware ja auch die ältere Schnittstelle ab:
Code:
<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Header xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"/>
<soap:Body ID="Body">
<BoxFirmwareUpdateCheckResponse xmlns="http://jason.avm.de/updatecheck/">
<BoxFirmwareUpdateCheckResult>
<ResponseHeader>
<Nonce>NIORAgKSRffLsdJ3A/ZnJw==</Nonce>
</ResponseHeader>
<UpdateCheckResult>
<CheckIntervall>168</CheckIntervall>
<Found>true</Found>
<Version>84.06.51</Version>
<DownloadURL>ftp://ftp.avm.de/fritz.box/fritzbox.fon_wlan_7390/firmware/deutsch/FRITZ.Box_Fon_WLAN_7390.AnnexB.84.06.51.image</DownloadURL>
<InfoURL>ftp://ftp.avm.de/fritz.box/fritzbox.fon_wlan_7390/firmware/deutsch/info.txt</InfoURL>
<InfoText>PERL 15 EXTERN</InfoText>
<HintURL/>
<Priority>1</Priority>
<AutoUpdateStartTime>0</AutoUpdateStartTime>
<AutoUpdateEndTime>0</AutoUpdateEndTime>
<AutoUpdateKeepServices>true</AutoUpdateKeepServices>
</UpdateCheckResult>
</BoxFirmwareUpdateCheckResult>
</BoxFirmwareUpdateCheckResponse>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<Reference URI="#Body">
<Transforms>
<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>w1QHYARo+wZrE8BFBzluZraWW+A=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>Ubx7sa5ugMaFHXGjbOvR2LYSWmvN/+exYrxSv4a9UwNJ4r6nzykjXFz8RIjFJWU6u6X6w2awGxIsd9Co4udRIANuxd3We+C0PEJZOgGMGpk8nF1RFxeqmxkXxvPI24SLt8DFklbtdMCxfdmV638aCaUzJBebCmzmFuU4I0KyPqE=</SignatureValue>
</Signature>
</soap:Body>
</soap:Envelope>
Jedenfalls kann man festhalten, daß die 7390 mit 06.20 auf irgendeinem Weg von AVM dazu gebracht wurde (ob das ein Firmware-Fehler war oder der Update-Service die 06.51 zwischendrin als "kritisches Update" klassifiziert hat, kriegt man nicht mehr ohne weiteres heraus), die Einstellung bzgl. "Auto-Update" zu ignorieren und die Firmware auf 06.51 (und zwar die originale von AVM, die ein mittelschwerer Witz in meinen Augen ist, auch die strotzt nur so vor Security-Problemen - ich habe alleine acht oder neun offene Incidents dafür) zu aktualisieren.
Es hilft vielleicht, der Box die Kommunikation mit dem Hersteller komplett zu verbieten - wobei man auch da ja weder sicher sein kann, daß die Box sich daran hält, noch ob nicht ein Fehler in der Implementierung die Firmware doch noch aktualisiert.
So sehr ich auch sichere Firmware auf "normalen Boxen" begrüße, so sehr empfinde ich diese Situation (auch wenn sie auf einem Fehler beruhen sollte, was ich mal ganz stark hoffen will) als Zumutung, denn die neue Oberfläche läßt sich eben nicht mehr mit älteren Geräten (z.B. iOS vor Version 6) bedienen.
Wenn sich die Firmware nicht an die vorhandenen Einstellungen hält, verliert man als Kunde das Vertrauen - wenn ich der FRITZ!Box das autarke Update verbiete, dann erwarte ich, daß es nicht stattfindet. Punkt.
Eine "Entschuldigung" dafür gibt es praktisch nicht ... ich kann wenigstens noch den Zeitpunkt des Updates feststellen, denn anhand der zur Zeit ausgelieferten Informationen für das Update auf 06.51 (s.o.) kann man eigentlich nicht darauf schließen, daß es als "kritisch" eingestuft war. Die Abfragen oben erfolgten beide mit einer "06.20" als angeblicher Ausgangsversion.
Bleibt also die Frage, ob was die Ursache war ... da vor dem Download der neuen Firmware keine Information vorliegt, wie lange so ein neues Update bereits verfügbar ist bzw. wie alt es ist, kann eigentlich nur der AVM-Service das Update als "kritisch" markiert haben und zu allem Überfluß hat dann noch die Firmware die Einstellung bzgl. Auto-Update (das stand auf "nur benachrichtigen") ignoriert.
Bei der 7390 kann ein Update auch nur dann installiert werden, wenn es als "kritisch" markiert ist, auch bei der 06.51 gibt es dort keinen "dritten Weg":
Daraus würde ich jetzt die Schlußfolgerung ableiten, daß zu irgendeinem Zeitpunkt am 22.09.2016 das Update mal entsprechend markiert gewesen sein muß (es bleiben ja praktisch nur die Felder
Code:
<Priority>1</Priority>
<AutoUpdateStartTime>0</AutoUpdateStartTime>
<AutoUpdateEndTime>0</AutoUpdateEndTime>
<AutoUpdateKeepServices>true</AutoUpdateKeepServices>
als denkbare Anzeigen übrig, außer es wird ein weiteres XML-Element generiert für kritische Updates) ... wenn das ein Versehen von AVM war, würde ich zumindest erwarten, daß man eine entsprechende Nachricht auf der eigenen Webpräsenz veröffentlicht und sich ggf. sogar bei den Kunden entschuldigt, denen man damit unnötige Arbeit aufgebürdet hat.
Eigentlich dürfte sich eine 7390 gar nicht automatisch aktualisieren, solange AVM ein Update nicht als "notwendig" (die von mir gewählte Formulierung "kritisch" gibt es bei AVM ja nicht - normal wäre die Unterteilung in "recommended" und "critical", keine Ahnung, was davon dann "notwendig" sein soll) kennzeichnet - egal, wie die Einstellungen der Box bzgl. "Auto-Update" auch sein mögen.
Wenn AVM dann hingeht und eine Version, die einen derart deutlichen Bruch beim Kunden bewirken kann (das "responsive design" ist eben nur mit neueren Geräten oder neueren Browsern zu bedienen und die hat der Kunde ggf. gar nicht), als "notwendig" ausweist, dann ist das schon ein ziemlich starkes Stück und es hat - solange es sich nicht um einen Fehler handelt, wozu AVM sich aber bisher auch nicht positioniert oder "bekannt" hat - schon etwas von einer "Gutsherren-Manier", das für mich einen ähnlichen Stallgeruch bzw. schalen Nachgeschmack entwickelt, wie die Story von HP und dem DRM für den Toner, das nach 6 Monaten dann irgendwann zuschlägt.
Wenn es eine Notwendigkeit geben sollte, ein Update unbedingt auszuführen, weil eine neue kritische Lücke bekannt wird (die entsprechende Warnung von AVM wäre aber ebenfalls an mir vorübergegangen), dann muß eben - wenn der Kunde dem Hersteller schon das automatische Update "anvertraut" - eine Version mit dem alten GUI erzeugt werden, die diese Lücke schließt.
Ein "Zwangsupdate", was sämtliche Brücken hinter sich abbricht, ist nur eines ... eine Zumutung seitens des Herstellers und seine ungefragte Installation ist die Entmündigung (man könnte auch schreiben "Entmannung") des Kunden. Da spielt es also auch gar keine Rolle, wie das "Auto-Update" bei der 7390 eingestellt war oder ist ...
- - - Aktualisiert - - -
Ich muß mich korrigieren ... auf der fraglichen Box wurde doch der Anbieter "1und1" ausgewählt (das ist der einzige 1&1-Anschluß, auf den ich Zugriff habe und vermutlich habe ich das verbockt, als ich etwas mit "1und1" als Provider testen wollte, denn ältere Sicherungen zeigen "anderer Anbieter"), aber in jedem Falle war die "Automatische Einrichtung durch den Dienstanbieter zulassen" ausgeschaltet. Im Moment sieht es bei der 06.51 sogar so aus:
Code:
**** CFGFILE:tr069.cfg
/*
* /var/tmp.cfg
* Tue Sep 27 10:01:00 2016
*/
meta { encoding = "utf-8"; }
tr069cfg {
enabled = yes;
litemode = yes;
tr181_support = no;
dhcp43_support = yes;
igd {
DeviceInfo {
ProvisioningCode = "005.000.000.000";
FirstUseDate = "2014-03-07 14:11:27";
}
managementserver {
url = "https://acs2.online.de";
username = "$$$$11USLFO1TJSNV54CMAQUXGQNLKHRHM6TYOSPAWEZKTIF31OEETCA5FZQWIJM2RFUZFET425ZPYVSGW4E";
password = "$$$$KR5TAROPSBCIUPQVCAOSUZAMCVUEOTHZWTIFUDYNHGMICHNKI6EMTVTT1EHKOMG1INZXUG5JL2AVSW4E";
URLAlreadyContacted = yes;
LastInformReq = "2016-09-27 03:35:45";
LastSuccessfulContact = "2016-09-27 03:35:46";
URLbyDHCPIface = "";
PeriodicInformEnable = no;
PeriodicInformInterval = 0;
PeriodicInformTime = "1970-01-01 01:00:00";
UpgradesManaged = no;
ACSInitiationEnable = no;
ACSInitiationPorts = "46000+1000";
SessionTerminationWithEmptyPost = no;
ConnectionRequestUsername = "";
ConnectionRequestPassword = "";
dnsprefer = tr069dnsprefer_ipv6;
}
}
FirmwareDownload {
enabled = no;
enabled_converted = yes;
upload_enabled = no;
valid = no;
suppress_notify = no;
status = 0;
StartTime = "1970-01-01 01:00:00";
CompleteTime = "1970-01-01 01:00:00";
method = Download_Method_DL;
}
RebootRequest = no;
RebootRequest_CommandKey = "";
ACS_SSL {
verify_server = yes;
trusted_ca_file = "/etc/default/1und1/root_ca.pem";
}
Download_SSL {
verify_server = yes;
trusted_ca_file = "/etc/default/1und1/root_ca.pem";
}
guimode = guimode_visible;
}
// EOF
**** END OF FILE ****
Das ist die tr069.cfg aus dem Export, gleichzeitig zeigt das GUI folgendes an:
Wem soll man jetzt glauben? Es wäre (schon wegen der "Sonderbehandlung" für 1&1 mit dem "litemode") also auch denkbar, daß da bei 1&1 etwas schief gelaufen ist ... das wäre aber auch nur wieder ein überdeutliches Zeichen, daß die versprochene "Abschaltung" von TR-069 über das GUI bei "1&1" als eingestelltem Provider eben doch nicht wirksam ist (keine Überraschung für diejenigen, die hier regelmäßig lesen) - und bevor jemand auf die Idee mit einem "Branding" als Ursache kommt: Es ist eine rote 7390 mit "avm"-Branding.
Aber man sieht eben schon an "LastInformReq" und "LastSuccessfulContact", daß da weiterhin Kommunikation mit dem Provider erfolgt und wenn der dann (trotz der anderen oben gezeigten Einstellungen bzgl. Update - da steht ja auch "FirmwareDownload - enabled = no;") in der Lage ist, die Box mit neuer Firmware zu "bespaßen", dann ist das eindeutig ebenfalls eine Sicherheitslücke, die vom Hersteller sogar absichtlich eingebaut wurde ... so etwas nennt man einfach "backdoor".
Da steigt dann (zumindest bei mir) auch wieder die Skepsis, ob das mit "argo" so eine gute Idee ist. Das benutzt genauso die TR-069-Mechanismen, um die Box in regelmäßigen Intervallen mit dem Hersteller kommunizieren zu lassen und wenn schon der Provider einen Weg gefunden hat (absichtlich oder nicht, interessiert gar nicht), an den Einstellungen der Box vorbei eine Firmware zu aktualisieren, dann ist das für den Hersteller (mit Kenntnis der diversen Sicherheitslücken) noch viel einfacher.
Wobei mich die zeitliche Korrelation mit mind. einer anderen Beobachtung eines automatischen Updates (und da geht es ja offensichtlich nicht um einen 1&1-Anschluß) doch eher an die Theorie glauben läßt, daß es bei AVM "verbockt" wurde - die fragliche Box meldete sich bisher seit dem Erscheinen der 06.51 immer brav mit der Information, daß es ein neues FRITZ!OS gibt und kam vorher nie auf die Idee, diese Version automatisch installieren zu wollen.
