[Info] Update-Check über den neuen AVM-Service
- Ersteller PeterPawn
- Erstellt am
Vielen Dank 
Leider konnte ich mit der Info nicht viel anfangen, trotzdem Danke für die Hilfe
Leider konnte ich mit der Info nicht viel anfangen, trotzdem Danke für die Hilfe
Zuletzt bearbeitet:
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,298
- Punkte für Reaktionen
- 1,760
- Punkte
- 113
Das Ende der Übergangsfrist für die DSGVO wirft seine Schatten voraus ... und das hat auch Auswirkungen auf "juis_check".
Wenn AVM tatsächlich inzwischen die Abfragen für Inhouse-Versionen bei DOCSIS-Modellen nur noch mit der passenden Version und deren URL beantwortet, wenn diese Box mit ihrer "Serial" (das ist die "maca") in einer Whitelist steht (so klingt das hier zumindest, keine Ahnung, wie verläßlich die Quelle ist, aus der @v!king die Informationen bezieht), wäre das nur konsequent --- und war irgendwo auch zu erwarten - ich hoffe mal, daß die Quelle nicht nur darauf beruht, daß ich das mal irgendwo als Beispiel angeführt habe, wie AVM das besser abdichten könnte, wenn man nur wollte.
Wobei nach der DSGVO auch hier ohnehin wieder die Einwilligung des Kunden notwendig sein könnte (Erwägungsgrund 30) und ich schon etwas länger am Überlegen war, wie ich das für "juis_check" zumindest einmalig vom Benutzer bestätigen lassen könnte - die offensichtlichste Lösung mit einer passenden Datei, deren Vorhandensein das Einholen der Einwilligung überspringen läßt, begeistert mich gar nicht soo sehr, wäre aber als "Notnagel" mit irgendeinem "dot file" (die werden unter Linux nur mit speziellen Optionen vom "ls" angezeigt) im Home-Verzeichnis auch eine Alternative.
Denn zumindest in der Theorie liest ja dann "juis_check" die Angabe mit der LAN-MAC (das ist die Stelle, wo die "maca" verwendet wird) aus der FRITZ!Box aus und übermittelt sie an AVM - ob, wo und wie lange diese Information jetzt bei AVM wieder gespeichert wird, kann man "von außen" halt nicht wissen und für die Übermittlung an sich (sofern es sich um "juis_check" oder irgendeine andere Lösung handelt und nicht um die boxeigene Abfrage nach einem Update) ist AVM noch nicht verantwortlich zu machen - vielleicht gerade noch dafür, daß diese "maca" in allen möglichen anderen Zusammenhängen noch eine Rolle spielt (u.a. auch bei der verschlüsselten Speicherung von Einstellungen oder beim Kennwort für den privaten RSA-Schlüssel einer FRITZ!Box) und daher eigentlich ohnehin nicht freiwillig gesendet werden sollte, wenn es dafür keine begründete Notwendigkeit gibt. So eine Whitelist wäre ggf. eine solche Notwendigkeit - ansonsten sollte auch AVM in neuen Versionen auf diese Übermittlung verzichten (es ist nur ein weiterer Punkt für das Art.30-Verzeichnis, der gepflegt werden muß).
Daher (bzw. wenn mir nichts besseres mehr einfällt, wie ich eine wirksame Einwilligung zum Auslesen und zur Übermittlung an AVM einholen kann ... und zwar einmalig) werde ich die automatische Übermittlung der "maca" als "Serial" aus "juis_check" entfernen (bis zum 25.05.2018) und sie durch irgendeinen Phantasie-Wert (oder auch durch Zufallswerte mit passender OID für den Hersteller, die dann wieder auf dem Wert aus der Box basiert - damit nicht schon an den letzten drei Stellen der "Serial" die "externe Abfrage" erkannt werden kann) ersetzen - das hätte dann die Konsequenz, daß nur noch die explizite Angabe der "Serial" durch den Aufrufer selbst dazu führen würde, daß da wirklich die Daten einer konkreten Box benutzt werden.
Bei der expliziten eigenen Angabe ist dann auch wieder der Benutzer dafür verantwortlich, wenn diese Daten an AVM übermittelt werden. Dieses Vorgehen mit einer zufälligen MAC-Adresse paßt dann auch wieder zu dem Anspruch bzw. der in der DSGVO niedergelegten Aufforderung, die Übermittlung von personenbezogenen Daten (die MAC-Adresse gehört da sicherlich dazu, denn sie ergibt sich eben - anders als die IP-Adresse - nicht explizit aus einem Erfordernis im verwendeten Transportprotokoll und vor allem ist sie - auch wieder anders als die IP-Adresse bei den meisten - unveränderlich und dauerhaft als Merkmal zur Verknüpfung von Daten geeignet) auf das Unvermeidliche zu reduzieren.
Sollte es bei AVM inzwischen wirklich eine Whitelist für die MAC-Adressen von DOCSIS-Boxen mit Inhouse- oder Labor-Firmware geben (das hat nichts damit zu tun, was die KNB da ggf. mit ihren eigenen Boxen testen - wobei auch hier natürlich eine solche Whitelist für JUIS denkbar wäre, aber halt andere Firmware-Versionen annonciert werden müssen), müßte man entweder auf korrekte Arbeit von "juis_check" verzichten oder eben von Hand die richtige MAC-Adresse vorgeben.
====================================================
Die Datenschutzerklärung von AVM (exemplarisch für die 7490) ist leider für diesen konkreten Fall auch (noch?) nicht sehr ergiebig ... es stehen halt nur "Allgemeinplätze" zu personenbezogenen Daten in dieser:
Ich bin auch mal gespannt, inwieweit am Ende der CWMP-Account einer FRITZ!Box als "personenbezogene Daten" einzustufen wäre - auch diese Angaben werden (sofern vorhanden) natürlich von der FRITZ!Box (ob das der Provider nun will oder nicht und insofern ist der erst wieder für eine Auswertung, Verwendung und Speicherung zuständig, aber nicht für die Übermittlung) unaufgefordert und ohne echte Information der Kunden über diesen Umstand übertragen - hier könnte man höchsten noch darüber streiten, wie weit das bei der Nutzung von TR-069 unvermeidbar ist.
Bei der Übermittlung der MAC-Adresse zur Update-Abfrage dürfte sich diese Frage aber nicht stellen ... eine objektive Notwendigkeit wäre hier wohl nur schwer zu begründen, wenn der Kunde parallel dazu auch ohne Angabe dieser Daten die Adresse für die neue Firmware ermitteln kann (einfach durch Lesen von Daten in seinem Browser) und auch der Download dann ohne die Angabe weiterer Daten möglich ist. Das ist eben - außer bei DOCSIS-Firmware - auch der Normalfall ist und die Tatsache, daß bei DOCSIS-Boxen ggf. eine solche Selektion erfolgt, rechtfertigt es wiederum nicht, diese Daten von allen anderen Geräten auch zu erheben bzw. zu übermitteln ... was auch zur "Verarbeitung" (Art. 4 DSGVO, Zf. 2) von Daten gehört.
Das klingt alles sehr "bürokratisch" ... aber es zeigt eben auch, an wievielen Stellen bisher (auch vollkommen unnötig) Daten verarbeitet wurden und es wohl immer noch werden, ohne daß sich Hersteller und Kunden dieses Umstandes bewußt waren bzw. sind. Insofern macht eben auch so ein "Verarbeitungsverzeichnis" nach Art. 30 DSGVO tatsächlich Sinn ... und sei es nur dafür, daß der Hersteller sich selbst mal einen echten Überblick verschafft, wo er überall Daten erhebt, übermittelt und speichert, die er eigentlich gar nicht bräuchte bzw. wo er diese Daten bei einer Speicherung tunlichst umgehend pseudo- bzw. anonymisieren sollte.
Dann kann man sich zumindest mal überlegen, ob man nicht diese unnötigen Anteile besser gleich wegläßt (dann braucht es auch keinen zusätzlichen Aufwand zur Pseudo-/Anonymisierung) ... selbst bei der JUIS-Abfrage könnte man das durch ein zweistufiges Verfahren (oder eine andere Implementierung bei den Modellen, wo so eine Whitelist erforderlich sein mag) besser lösen.
Wenn AVM tatsächlich inzwischen die Abfragen für Inhouse-Versionen bei DOCSIS-Modellen nur noch mit der passenden Version und deren URL beantwortet, wenn diese Box mit ihrer "Serial" (das ist die "maca") in einer Whitelist steht (so klingt das hier zumindest, keine Ahnung, wie verläßlich die Quelle ist, aus der @v!king die Informationen bezieht), wäre das nur konsequent --- und war irgendwo auch zu erwarten - ich hoffe mal, daß die Quelle nicht nur darauf beruht, daß ich das mal irgendwo als Beispiel angeführt habe, wie AVM das besser abdichten könnte, wenn man nur wollte.
Wobei nach der DSGVO auch hier ohnehin wieder die Einwilligung des Kunden notwendig sein könnte (Erwägungsgrund 30) und ich schon etwas länger am Überlegen war, wie ich das für "juis_check" zumindest einmalig vom Benutzer bestätigen lassen könnte - die offensichtlichste Lösung mit einer passenden Datei, deren Vorhandensein das Einholen der Einwilligung überspringen läßt, begeistert mich gar nicht soo sehr, wäre aber als "Notnagel" mit irgendeinem "dot file" (die werden unter Linux nur mit speziellen Optionen vom "ls" angezeigt) im Home-Verzeichnis auch eine Alternative.
Denn zumindest in der Theorie liest ja dann "juis_check" die Angabe mit der LAN-MAC (das ist die Stelle, wo die "maca" verwendet wird) aus der FRITZ!Box aus und übermittelt sie an AVM - ob, wo und wie lange diese Information jetzt bei AVM wieder gespeichert wird, kann man "von außen" halt nicht wissen und für die Übermittlung an sich (sofern es sich um "juis_check" oder irgendeine andere Lösung handelt und nicht um die boxeigene Abfrage nach einem Update) ist AVM noch nicht verantwortlich zu machen - vielleicht gerade noch dafür, daß diese "maca" in allen möglichen anderen Zusammenhängen noch eine Rolle spielt (u.a. auch bei der verschlüsselten Speicherung von Einstellungen oder beim Kennwort für den privaten RSA-Schlüssel einer FRITZ!Box) und daher eigentlich ohnehin nicht freiwillig gesendet werden sollte, wenn es dafür keine begründete Notwendigkeit gibt. So eine Whitelist wäre ggf. eine solche Notwendigkeit - ansonsten sollte auch AVM in neuen Versionen auf diese Übermittlung verzichten (es ist nur ein weiterer Punkt für das Art.30-Verzeichnis, der gepflegt werden muß).
Daher (bzw. wenn mir nichts besseres mehr einfällt, wie ich eine wirksame Einwilligung zum Auslesen und zur Übermittlung an AVM einholen kann ... und zwar einmalig) werde ich die automatische Übermittlung der "maca" als "Serial" aus "juis_check" entfernen (bis zum 25.05.2018) und sie durch irgendeinen Phantasie-Wert (oder auch durch Zufallswerte mit passender OID für den Hersteller, die dann wieder auf dem Wert aus der Box basiert - damit nicht schon an den letzten drei Stellen der "Serial" die "externe Abfrage" erkannt werden kann) ersetzen - das hätte dann die Konsequenz, daß nur noch die explizite Angabe der "Serial" durch den Aufrufer selbst dazu führen würde, daß da wirklich die Daten einer konkreten Box benutzt werden.
Bei der expliziten eigenen Angabe ist dann auch wieder der Benutzer dafür verantwortlich, wenn diese Daten an AVM übermittelt werden. Dieses Vorgehen mit einer zufälligen MAC-Adresse paßt dann auch wieder zu dem Anspruch bzw. der in der DSGVO niedergelegten Aufforderung, die Übermittlung von personenbezogenen Daten (die MAC-Adresse gehört da sicherlich dazu, denn sie ergibt sich eben - anders als die IP-Adresse - nicht explizit aus einem Erfordernis im verwendeten Transportprotokoll und vor allem ist sie - auch wieder anders als die IP-Adresse bei den meisten - unveränderlich und dauerhaft als Merkmal zur Verknüpfung von Daten geeignet) auf das Unvermeidliche zu reduzieren.
Sollte es bei AVM inzwischen wirklich eine Whitelist für die MAC-Adressen von DOCSIS-Boxen mit Inhouse- oder Labor-Firmware geben (das hat nichts damit zu tun, was die KNB da ggf. mit ihren eigenen Boxen testen - wobei auch hier natürlich eine solche Whitelist für JUIS denkbar wäre, aber halt andere Firmware-Versionen annonciert werden müssen), müßte man entweder auf korrekte Arbeit von "juis_check" verzichten oder eben von Hand die richtige MAC-Adresse vorgeben.
====================================================
Die Datenschutzerklärung von AVM (exemplarisch für die 7490) ist leider für diesen konkreten Fall auch (noch?) nicht sehr ergiebig ... es stehen halt nur "Allgemeinplätze" zu personenbezogenen Daten in dieser:
Die Anfrage bei AVM nach den Informationen für diesen konkreten Fall, also der Prüfung auf ein vorhandenes Update (das die Box ja genauso macht, auch dort ist diese "Serial" enthalten) und ob bzw. wie lange da etwas gespeichert wird, was die Box eineindeutig identifizieren würde (unter der Annahme, daß die MAC-Adresse von AVM nur einmal vergeben wurde, was der Normalfall wäre), wird vermutlich auch erst nach dem Ablauf der Übergangsfrist am 25.05.2018 einen Sinn ergeben, wenn AVM dann antworten muß (Art. 15 DSGVO) - wobei natürlich unter dem Punkt "Updates" in dieser Datenschutzerklärung durchaus steht, daß Informationen zur Identifikation der Geräte übermittelt werden. Dafür fehlt dann aber auch bei den Einstellungen zum "Auto-Update" wieder jeglicher Hinweis auf diese Datenschutzerklärung und der zeitliche (und personelle) Zusammenhang zwischen dem ersten GUI-Aufruf (das war bisher der einzige Punkt, wo diese Datenschutzerklärung explizit erwähnt wird und direkt erreichbar ist) und einer Änderung dieser Einstellung ist auch nicht zwangsläufig anzunehmen.
Ich bin auch mal gespannt, inwieweit am Ende der CWMP-Account einer FRITZ!Box als "personenbezogene Daten" einzustufen wäre - auch diese Angaben werden (sofern vorhanden) natürlich von der FRITZ!Box (ob das der Provider nun will oder nicht und insofern ist der erst wieder für eine Auswertung, Verwendung und Speicherung zuständig, aber nicht für die Übermittlung) unaufgefordert und ohne echte Information der Kunden über diesen Umstand übertragen - hier könnte man höchsten noch darüber streiten, wie weit das bei der Nutzung von TR-069 unvermeidbar ist.
Bei der Übermittlung der MAC-Adresse zur Update-Abfrage dürfte sich diese Frage aber nicht stellen ... eine objektive Notwendigkeit wäre hier wohl nur schwer zu begründen, wenn der Kunde parallel dazu auch ohne Angabe dieser Daten die Adresse für die neue Firmware ermitteln kann (einfach durch Lesen von Daten in seinem Browser) und auch der Download dann ohne die Angabe weiterer Daten möglich ist. Das ist eben - außer bei DOCSIS-Firmware - auch der Normalfall ist und die Tatsache, daß bei DOCSIS-Boxen ggf. eine solche Selektion erfolgt, rechtfertigt es wiederum nicht, diese Daten von allen anderen Geräten auch zu erheben bzw. zu übermitteln ... was auch zur "Verarbeitung" (Art. 4 DSGVO, Zf. 2) von Daten gehört.
Das klingt alles sehr "bürokratisch" ... aber es zeigt eben auch, an wievielen Stellen bisher (auch vollkommen unnötig) Daten verarbeitet wurden und es wohl immer noch werden, ohne daß sich Hersteller und Kunden dieses Umstandes bewußt waren bzw. sind. Insofern macht eben auch so ein "Verarbeitungsverzeichnis" nach Art. 30 DSGVO tatsächlich Sinn ... und sei es nur dafür, daß der Hersteller sich selbst mal einen echten Überblick verschafft, wo er überall Daten erhebt, übermittelt und speichert, die er eigentlich gar nicht bräuchte bzw. wo er diese Daten bei einer Speicherung tunlichst umgehend pseudo- bzw. anonymisieren sollte.
Dann kann man sich zumindest mal überlegen, ob man nicht diese unnötigen Anteile besser gleich wegläßt (dann braucht es auch keinen zusätzlichen Aufwand zur Pseudo-/Anonymisierung) ... selbst bei der JUIS-Abfrage könnte man das durch ein zweistufiges Verfahren (oder eine andere Implementierung bei den Modellen, wo so eine Whitelist erforderlich sein mag) besser lösen.
Zuletzt bearbeitet:
Die MACs allein sind ja keine Personenbezogenen Daten, und die Whitelist wären ja nur Angaben die man eh bereits hat durch die Produktion. Über die Seriennummern weiß AVM ja auch welches Modell, wann produziert usw., evt. noch den Vertriebsweg aber auch nicht mehr. Der Knackpunkt wäre doch eher, ohne Einwilligung dürfte die FB nicht mal ein Kontaktversuch zu AVM machen, also weder zum Prüfen ob FW verfügbar ist oder für Jugendschutzfilter die Liste updaten, oder Automatische Einrichtung durch den Anbieter, da ja die IP vom Anschluss übermittelt wird, und diese wäre eher Personenbezogen, bzw. spätestens dann die Antwort vom Anbieter für die automatische Einrichtung.
Mehr Daten durch AVM werden in Verbindung mit MyFritz verarbeitet oder bei Angabe der SN im Support Ticket oder der bei Übermittlung der Support Datei sowie den freiwilligen Angaben des Nutzers im Formular.
Mehr Daten durch AVM werden in Verbindung mit MyFritz verarbeitet oder bei Angabe der SN im Support Ticket oder der bei Übermittlung der Support Datei sowie den freiwilligen Angaben des Nutzers im Formular.
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,298
- Punkte für Reaktionen
- 1,760
- Punkte
- 113
In ihrer Funktion in so einem SOAP-Request als eindeutiges Merkmal der FRITZ!Box, erfüllt diese MAC-Adresse (noch mal, es geht hier nicht darum, daß diese im Rahmen des Transports von Informationen technisch erforderlich wäre, wie es bei der IP-Adresse der Fall ist) ziemlich exakt die Erklärungen aus dem - bereits oben erwähnten und verlinkten - Erwägungsgrund 30 und aus dessen zweitem Satz geht dann hervor, warum man auf die Verarbeitung (das umfaßt Erheben, Übermitteln, Auswerten, Speichern) solcher Daten verzichten sollte. Dabei interessiert es auch kein Stück, ob AVM diese Daten bereits aus der Produktion vorliegen oder nicht (das ist sogar eher ein weiterer Grund, warum dieses Merkmal eben doch personenbezogen ist) ... und auch die Frage, ob die MAC-Adresse allein zur Identifikation ausreicht oder ob über sie nur die Informationen aus verschiedenen Quellen zusammengeführt werden können, interessiert dabei nicht wirklich.
Und klar ... AVM muß theoretisch die Einwilligung des Kunden zu jedem Versuch (wenn auch nicht zu jedem einzelnen), irgendwie automatisch "nach Hause zu telefonieren", einholen - man könnte durchaus (zumindest bisher, wo die Notwendigkeit der expliziten Einwilligung und die Anforderungen an die "Freiwilligkeit" einer solchen Zustimmung nicht so ausdrücklich festgelegt waren) den Standpunkt vertreten, daß der Kunde die Einwilligung auf der allerersten Seite erteilt (hat), sofern er die automatische Suche nach Updates nicht deaktiviert ... auch wenn er in der ersten Seite "Diagnose und Wartung" nicht aktiviert (läßt).
Dort ist die Datenschutzerklärung immerhin erreichbar und diese kann wohl als Information verstanden werden, wenn es um die Frage der Updates geht und die Nutzung dieser Funktion in Kenntnis der Folgen ist dann wohl eine (konkludente) Einwilligung. Ob das nach der DSGVO (bzw. nach der Novellierung des BDSG auf dieser Basis) tatsächlich noch ausreicht mit so einer konkludenten Einwilligung und ob nicht AVM doch besser noch eine Checkbox ("Ich habe die Datenschutzerklärung gelesen und verstanden.") bei der Änderung von Einstellungen, die ihrerseits eine solche Übermittlung auslösen, unterbringt, wird die Zukunft zeigen.
Hier ist auch die IP-Adresse gar nicht wirklich der Knackpunkt - ohne sie kann gar keine Kommunikation erfolgen und damit ist ihre Übermittlung hier zweifellos auch notwendig. Spannend wird es erst bei der Frage, ob/wie AVM die übermittelten Daten in so einer Abfrage von der Box jetzt irgendwo speichert (die dann wieder die "Serial" enthalten, aber nicht zwangsläufig die IP-Adresse - das sind wieder verschiedene "Schichten" in einer Anwendung) und sei es nur in einem Protokoll der Abfragen des Webservices, das die IP-Adressen (aus nachvollziehbaren Gründen) gar nicht mehr enthält. Mit dieser "Serial" ließen sich dann auch aus diesen gespeicherten Daten neue Zusammenhänge erschließen, sofern dasselbe Ordnungskriterium auch noch in anderen Zusammenhängen übermittelt wird.
Dabei ist gegen ein solches "Ordnungsmerkmal" auch noch nichts einzuwenden ... wenn es denn zweckgebunden ist und nicht für - per se erst mal nicht zwingend zusammengehörige - weitere Anwendungen genutzt wird. Ein denkbarer Ausweg wäre z.B. eine (feste, aber erst beim Kunden generierte) GUID für solche Update-Abfragen ... die dann aber nichts mehr mit einer weiteren GUID zu tun hat, mit der die Box irgendwelche Telemetrie-Daten zum DSL-Anschluß an den Hersteller sendet (o.ä.). Genau diese Möglichkeit der nachträglichen Verknüpfung von Daten aus unterschiedlichen Quellen mit einem solchen gemeinsamen Merkmal, macht dieses Datum erst "personenbezogen" (Art. 4 Zf. 1 DSGVO).
Und klar ... AVM muß theoretisch die Einwilligung des Kunden zu jedem Versuch (wenn auch nicht zu jedem einzelnen), irgendwie automatisch "nach Hause zu telefonieren", einholen - man könnte durchaus (zumindest bisher, wo die Notwendigkeit der expliziten Einwilligung und die Anforderungen an die "Freiwilligkeit" einer solchen Zustimmung nicht so ausdrücklich festgelegt waren) den Standpunkt vertreten, daß der Kunde die Einwilligung auf der allerersten Seite erteilt (hat), sofern er die automatische Suche nach Updates nicht deaktiviert ... auch wenn er in der ersten Seite "Diagnose und Wartung" nicht aktiviert (läßt).
Dort ist die Datenschutzerklärung immerhin erreichbar und diese kann wohl als Information verstanden werden, wenn es um die Frage der Updates geht und die Nutzung dieser Funktion in Kenntnis der Folgen ist dann wohl eine (konkludente) Einwilligung. Ob das nach der DSGVO (bzw. nach der Novellierung des BDSG auf dieser Basis) tatsächlich noch ausreicht mit so einer konkludenten Einwilligung und ob nicht AVM doch besser noch eine Checkbox ("Ich habe die Datenschutzerklärung gelesen und verstanden.") bei der Änderung von Einstellungen, die ihrerseits eine solche Übermittlung auslösen, unterbringt, wird die Zukunft zeigen.
Hier ist auch die IP-Adresse gar nicht wirklich der Knackpunkt - ohne sie kann gar keine Kommunikation erfolgen und damit ist ihre Übermittlung hier zweifellos auch notwendig. Spannend wird es erst bei der Frage, ob/wie AVM die übermittelten Daten in so einer Abfrage von der Box jetzt irgendwo speichert (die dann wieder die "Serial" enthalten, aber nicht zwangsläufig die IP-Adresse - das sind wieder verschiedene "Schichten" in einer Anwendung) und sei es nur in einem Protokoll der Abfragen des Webservices, das die IP-Adressen (aus nachvollziehbaren Gründen) gar nicht mehr enthält. Mit dieser "Serial" ließen sich dann auch aus diesen gespeicherten Daten neue Zusammenhänge erschließen, sofern dasselbe Ordnungskriterium auch noch in anderen Zusammenhängen übermittelt wird.
Dabei ist gegen ein solches "Ordnungsmerkmal" auch noch nichts einzuwenden ... wenn es denn zweckgebunden ist und nicht für - per se erst mal nicht zwingend zusammengehörige - weitere Anwendungen genutzt wird. Ein denkbarer Ausweg wäre z.B. eine (feste, aber erst beim Kunden generierte) GUID für solche Update-Abfragen ... die dann aber nichts mehr mit einer weiteren GUID zu tun hat, mit der die Box irgendwelche Telemetrie-Daten zum DSL-Anschluß an den Hersteller sendet (o.ä.). Genau diese Möglichkeit der nachträglichen Verknüpfung von Daten aus unterschiedlichen Quellen mit einem solchen gemeinsamen Merkmal, macht dieses Datum erst "personenbezogen" (Art. 4 Zf. 1 DSGVO).
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,298
- Punkte für Reaktionen
- 1,760
- Punkte
- 113
Ich habe die Version im Repository dahingehend geändert, daß sie nicht länger die reale "Serial" sendet. Wer das braucht, kann es mit der "-r"-Option erzwingen, es gibt dann aber keine weitere Info, daß personenbezogene Daten (für mich ist diese "Serial" ein solches Datum) an AVM gesendet werden.
Ansonsten wird aus der OUI (die ersten drei Bytes der MAC-Adresse) und einem Zufallswert eine neue "Serial" gebildet, die definitiv eine andere als der reale "maca"-Wert ist.
Wenn jemand den Wert für "Serial" irgendwie anders festlegt (beim Aufruf oder in einer Konfigurationsdatei), dann wird natürlich diese Angabe verwendet.
Ansonsten wird aus der OUI (die ersten drei Bytes der MAC-Adresse) und einem Zufallswert eine neue "Serial" gebildet, die definitiv eine andere als der reale "maca"-Wert ist.
Wenn jemand den Wert für "Serial" irgendwie anders festlegt (beim Aufruf oder in einer Konfigurationsdatei), dann wird natürlich diese Angabe verwendet.
prisrak1
Mitglied
- Mitglied seit
- 14 Mai 2017
- Beiträge
- 573
- Punkte für Reaktionen
- 75
- Punkte
- 28
Public=1 oder 0 ergibt keine neue source version '141.06.xx. Wie kommt man an die neue Versionen(Labor o. so) dran?
Code:
... /tools$ ./juischeckupdate fritz.box Version=141.06.87 Name=FRITZ\!Box\6490 HW=213 OEM=avm Public=1
No newer version found, check was made with source version '141.06.87'.
NDiIPP
IPPF-Promi
- Mitglied seit
- 13 Apr 2017
- Beiträge
- 9,867
- Punkte für Reaktionen
- 2,405
- Punkte
- 113
Für die 6490 über JUIS derzeit wohl nicht, die werden über diesen Service von AVM derzeit imo nicht verteilt.
- Mitglied seit
- 7 Okt 2015
- Beiträge
- 9,347
- Punkte für Reaktionen
- 1,476
- Punkte
- 113
Indem man mit etwas Phantasie sich einen Link incl Benutzer+Kennwort auf Grundlage der bislang über JUIS ausgegebenen DL-URLs auf die Daten des gesuchten Images abändern. Und wenn man die korrekte Ordnerstruktur vorne weg stellt, sollte ein DL möglich sein (falls diese Versionen überhaupt noch auf dem FTP liegen sollten)
prisrak1
Mitglied
- Mitglied seit
- 14 Mai 2017
- Beiträge
- 573
- Punkte für Reaktionen
- 75
- Punkte
- 28
Also wenn ich "... mit etwas Phantasie sich einen Link .." Erzeugen lasse, komme ich ständig auf E-Mail von GMX oder ähnlichen Providern. Anscheinend fällt mir etwas an meiner Phantasie, um an die gewünschte Firmware Version heranzukommen.Gibt es da womöglich einen Tipp, um meinen Gedankenspiel in die richtige Richtung zu weisen?
Wer weiß was du da für Blödsinn machst, weil GMX und Email nichts mit AVM zutun hat geschweige mit http oder ftp Links.
Entweder man nutzt Script oder die Excel Variante, oder hat halt Pech und nutzt die regulären Versionen.
Entweder man nutzt Script oder die Excel Variante, oder hat halt Pech und nutzt die regulären Versionen.
prisrak1
Mitglied
- Mitglied seit
- 14 Mai 2017
- Beiträge
- 573
- Punkte für Reaktionen
- 75
- Punkte
- 28
Wahrscheinlich jeder wie ich, hat bereits die beiden Varianten ".. man nutzt Script oder die Excel Variante.. " Ausprobiert, um an die Versionen wie.. 98, und 6.100 für die FRITZ!Box 6490 heranzukommen ausprobiert und gescheitert. Die Skriptversion und die Excel Variante funktionieren, liefern bei mir kein gewünschtes Ergebnis. Zu der Version ..87 bin ich auch damals durch den Skript gekommen und konnte meine eigene Freetz bauen.
Nochmals... dann hast du Pech... und es gibt hier keine Links... steht in diversen Themen der "Internen" Version direkt in #1.
Wildes probieren ist wohl auch mit Vorsicht zu genießen, siehe z.B. https://www.ip-phone-forum.de/threads/volkssport-curling.299275
Weiteres dazu wird als OT entfernt.
Wildes probieren ist wohl auch mit Vorsicht zu genießen, siehe z.B. https://www.ip-phone-forum.de/threads/volkssport-curling.299275
Weiteres dazu wird als OT entfernt.
Zuletzt bearbeitet von einem Moderator:
prisrak1
Mitglied
- Mitglied seit
- 14 Mai 2017
- Beiträge
- 573
- Punkte für Reaktionen
- 75
- Punkte
- 28
Es hat ja auch keiner nach den direkten Links angefragt. Danke für den Tipp vom Beitrag #1. grundsätzlich wird festgestellt, dass Wissen und die Information über etwas ist vorhanden, so wird man früher oder später an den begehrten Link und somit an das begehrtes Wissen herankommen. Unabhängig davon, wie gut es geschützt ist, oder eben nicht. Somit wird das zu den gegebenen Zeit für jeden zugänglich werden. Diejenigen die eben, es befürchten müssen, dass ihre FRITZ!Box angeblich verschrottet wird, sind hier sicherlich an dieser Stelle falsch. Ich bin bereits über diese Schwelle voraus. Aus diesem Grund bin ich eben bereit immer wieder neu "Beta Versionen usw." auszuprobieren und hab keine Angst, dass es angeblich die FRITZ!Box zum Absturz bringen könnte. Ich hab genug damit experimentiert, dass ich diese immer wieder zum laufen kriegen kann. Ob mein Beitrag hier gelöscht wird, oder eben nicht, liegt eben nur bei euch.
Zuletzt bearbeitet:
Funktioniert das noch für 228? Wäre nett wenn jemand Parameter hat, mit denen ein Update angezeigt wird
Dann halt nicht mehr
IPPF-Promi
- Mitglied seit
- 18 Apr 2008
- Beiträge
- 5,167
- Punkte für Reaktionen
- 948
- Punkte
- 113
Als ich gerade versucht habe, mit den Daten zur neuen Labor 154.07.08 einen Abruf via juis zu machen, kam diese Fehlermeldung:
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,298
- Punkte für Reaktionen
- 1,760
- Punkte
- 113
Keine Ahnung, was das für eine Version ist ... in der aktuellen im YourFritz-Repo steht in Zeile 1252 ein Kommentar.
Noch weiter zurück suche ich jetzt mal nicht ... bitte mit einer aktuellen Version noch einmal versuchen. Danke.
Dabei dann bitte auch den kompletten Inhalt der Konsole zeigen (also Ein- und Ausgabe), weil auch die Stelle im Text, an der das auftritt (wenn man das Skript mit "-d" aufruft), Rückschlüsse auf die Stelle in der Datei zuläßt und die Angabe von "154.07.08" ohne "Build" ja ohnehin falsch wäre.
Es gibt zwar irgendwo auch "printf"-Statements, die mit Oktal-Zahlen (das sind solche, wo nur die Ziffern 0 bis 7 verwendet werden und die Basis die 8 ist) arbeiten wollen (das ist jede Zahl, die in der Form "\nnn" daherkommt in der Maske und da wäre "\008" oder "\08" tatsächlich falsch), aber die finde ich ohne passende Zeilennummer nie (oder nicht mit vertretbarem Aufwand).
- https://github.com/PeterPawn/YourFritz/blob/master/juis/juis_check#L1252 - Version vom 31.10.2018
- https://github.com/PeterPawn/YourFr...ea8e98da0d0500c49fbcecf/juis/juis_check#L1252 - Version vom 20.10.2018
- https://github.com/PeterPawn/YourFr...092b75718c64eb8fc0b7d71/juis/juis_check#L1252 - Version vom 25.06.2018 - zwar kein Kommentar, aber auch kein "printf"
Noch weiter zurück suche ich jetzt mal nicht ... bitte mit einer aktuellen Version noch einmal versuchen. Danke.
Dabei dann bitte auch den kompletten Inhalt der Konsole zeigen (also Ein- und Ausgabe), weil auch die Stelle im Text, an der das auftritt (wenn man das Skript mit "-d" aufruft), Rückschlüsse auf die Stelle in der Datei zuläßt und die Angabe von "154.07.08" ohne "Build" ja ohnehin falsch wäre.
Es gibt zwar irgendwo auch "printf"-Statements, die mit Oktal-Zahlen (das sind solche, wo nur die Ziffern 0 bis 7 verwendet werden und die Basis die 8 ist) arbeiten wollen (das ist jede Zahl, die in der Form "\nnn" daherkommt in der Maske und da wäre "\008" oder "\08" tatsächlich falsch), aber die finde ich ohne passende Zeilennummer nie (oder nicht mit vertretbarem Aufwand).
Dann halt nicht mehr
IPPF-Promi
- Mitglied seit
- 18 Apr 2008
- Beiträge
- 5,167
- Punkte für Reaktionen
- 948
- Punkte
- 113
Mit der aktuellen Version habe ich den Fehler nun in einer anderen Zeile:
./7590: Zeile 1438: printf: 08: Ungültige Oktalzahl.
Dort steht:
./7590: Zeile 1438: printf: 08: Ungültige Oktalzahl.
Dort steht:
Mein .cfg sagt zur 7590:
Kann es sein, daß der 3. Teil der Versionsnr. in eine fälschlicherweise als Oktalzahl definierte Variable soll und das bei der aktuellen Version ".08"?
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,298
- Punkte für Reaktionen
- 1,760
- Punkte
- 113
Shell-Variablen sind untypisiert und falscher Inhalt fällt erst bei der Benutzung auf. Eine Oktalzahl kann also nur in der Maske auftauchen beim "printf" und das eigentlich auch nur dann, wenn da ein Backslash vor Ziffern steht, wie es hier:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/printf.html
für die "format string" in "EXTENDED DESCRIPTION" - Punkt 3 - als "\ddd" beschrieben ist und dann eine Ziffer außerhalb von 0 bis 7 folgt.
Ich versuche das mal mit der Konfigurationsdatei nachzustellen ... sieht ja auf den ersten Blick so aus, als wäre die "komplett" und man bräuchte keine Box dafür.
Zumindest kann es ja eigentlich nichts mit den unmittelbar davor eingefügten Zeilen zu tun haben (die dienen nur dazu, bei der Verwendung mit "modfs" auch für die aktuelle Version eine URL zu finden), wenn es auch in noch deutlich älteren Versionen dasselbe Problem gibt - denn diese Änderung ist erst von Anfang Oktober.
Wie gesagt ... ich schau's mir an.
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/printf.html
für die "format string" in "EXTENDED DESCRIPTION" - Punkt 3 - als "\ddd" beschrieben ist und dann eine Ziffer außerhalb von 0 bis 7 folgt.
Ich versuche das mal mit der Konfigurationsdatei nachzustellen ... sieht ja auf den ersten Blick so aus, als wäre die "komplett" und man bräuchte keine Box dafür.
Zumindest kann es ja eigentlich nichts mit den unmittelbar davor eingefügten Zeilen zu tun haben (die dienen nur dazu, bei der Verwendung mit "modfs" auch für die aktuelle Version eine URL zu finden), wenn es auch in noch deutlich älteren Versionen dasselbe Problem gibt - denn diese Änderung ist erst von Anfang Oktober.
Wie gesagt ... ich schau's mir an.