[Info] Update-Check über den neuen AVM-Service

Update 25.06.2019:
Wer auf der Suche nach dem öffentlichen Schlüssel ist, mit dem die Signatur einer JUIS-Antwort geprüft werden kann, wird hier fündig.

Update 03.01.2018:
Ich habe eine neue Version bereitgestellt und (mehr als ausführlich, ich kann die Klagen praktisch schon wieder hören) beschrieben. Der komplette Beitrag dazu findet sich hier:

https://www.ip-phone-forum.de/threads/update-check-über-den-neuen-avm-service.287657/page-9#post-2256618

Ich hoffe mal, daß es jeder versteht, wenn ich künftige Fragen und/oder Probleme nur noch dann zur Kenntnis nehme, wenn sie sich auf diese neue Version beziehen.

Der Rest in diesem Beitrag bleibt nur noch aus "historischen Gründen" stehen ... bitte im oben verlinkten Beitrag weiterlesen, wenn man nicht gerade Archäologe werden möchte.

=================================================================

EDIT (16.03.2017): Es gibt schon seit geraumer Zeit eine Version, die ausschließlich mit einer POSIX-kompatiblen Shell arbeiten kann (also auch mit "dash"), wenn ein passendes "nc"-Kommando für die Netzwerk-Kommunikation irgendwo verfügbar ist. Diese nennt sich dann "juis_check" und die zugehörige Konfigurationsdatei verwendet die Erweiterung "cfg".
Ansonsten hat sich ggü. der weiteren Beschreibung wenig bis nichts geändert. Es wird auch absichtlich immer noch die "jason_boxinfo.xml" als Quelle für die Daten der Box herangezogen, da die "juis_boxinfo.xml" nur in neueren Versionen vorhanden ist. Irgendwann könnte sich das noch einmal ändern ... wenn AVM irgendwelche zusätzlichen Änderungen am Service umsetzt und das Skript daran angepaßt werden müßte. Änderungen nehme ich jedenfalls nur noch an dieser neuen Version vor - Anpassungen (u.a. auch die Auswertung der AVM-Signatur in der Antwort und die Suche nach internen Versionen für die 7580, wenn das überhaupt machbar ist über die Abfrage) wird es ausschließlich für "juis_check" geben.

EDIT: @Joe_57 hat das auch mit der "bash" unter W10-x64 zum Laufen gebracht: http://www.ip-phone-forum.de/showthread.php?t=287657&p=2192420&viewfull=1#post2192420

Ich habe mal ein Skript ins GitHub-Repo gestellt, mit dem man die Prüfung auf neue Versionen auch außerhalb der FRITZ!Box auf recht einfache Art und Weise ausführen kann und neben einem Return-Code mit der Angabe, ob eine neuere Version existiert, auch noch die URL für den Download erhält.

Dabei wird aber nur das neue AVM-Interface für die Update-Prüfung unterstützt (hatte ich irgendwo bei der 06.69 für die 7490 mal angetextet, was man da sehen konnte - die Abfrage über TLS dachte ich dort allerdings auch gefunden zu haben und das wird im Moment zumindest noch nicht verwendet), meines Wissens wird das bisher von der 6490, dem Labor-Zweig der 7490 und eventuell der 7580 verwendet selbst verwendet - aber es kann auch sein bzw. es sieht so aus, als wenn AVM für die anderen älteren Modelle dieselben Daten bereitstellt, wie über die alte Schnittstelle. Ich konnte jedenfalls auch eine Abfrage für eine 7412 machen (bei 137.06.32 als "aktuelle Version" lieferte die Abfrage dann auch brav die aktuelle 137.06.50 mit der richtigen URL).

Das Skript verarbeitet eine Konfigurationsdatei "juisupdatecheck.conf", in dieser kann man entweder seine eigene FRITZ!Box "fest verdrahten" mit der IP-Adresse oder (das ist der Ausgangszustand im Repo) die IP-Adresse der FRITZ!Box als ersten Parameter beim Aufruf angeben und dort in der Konfigurationsdatei (die kann auch wieder beliebige Shell-Kommandos enthalten) zuweisen.

Um die ganzen Werte für eine Update-Abfrage korrekt zu setzen, liest das Skript die (frei zugängliche) "jason_boxinfo.xml" aus der Box und weist die dort enthaltenen Angaben zu FRITZ!Box-Modell und OS-Version den passenden Variablen zu, wenn man sie nicht explizit "vorgibt". Auf diese Weise kann man das Skript auch ohne langwierige Parameterlisten beim Aufruf für mehrere Modelle benutzen und man behält trotzdem mit den passenden Einträgen in der Konfigurationsdatei (einfach den Kopf des Skript-Files lesen, was da ansonsten noch so geht oder auch gleich die Shell-Kommandos analysieren) die volle Kontrolle darüber, was man da bei AVM abfragen will, wenn man z.B. ein Modell prüfen will, das man selbst gar nicht besitzt.

Spätestens bei der Verwendung von "Public=0" als Einstellung ist aber dann entsprechende Vor- und Umsicht erforderlich, diese "Inhouse-Versionen" können auch problemlos gar nicht funktionieren (das sind die, die hier immer in den "Sammelthreads" herumgeistern) und sind genau deshalb eigentlich nicht für die Öffentlichkeit bestimmt - soweit man das von außen sehen kann bzw. annehmen müßte.

Dieser Parameter ist also bloß ein Sahnehäubchen ... der eigentliche Vorteil dieses Skripts ist es, daß man damit auch einen "Mirror" mit den freigegebenen Labor-Versionen erstellen kann, was bei der normalen Verwendung irgendeines Programms zum Auslesen des Servers (z.B. "wget -m") ja scheitert, da es dort kein "Inhaltsverzeichnis" der Labor-Versionen gibt. Das erfordert zwar, daß man die diversen Modelle abfragt, aber die meisten dürften ohnehin nur an den Modellen interessiert sein, die sie selbst besitzen oder zumindest betreuen.

Das hatte ich früher für den alten AVM-Service nur für die eigene, interne Verwendung ... nachdem AVM nun auf den neuen Service umstellt, kann man das auch nachnutzbar machen. Wer die komplette Antwort des AVM-Service braucht (z.B. auch den Namen des Updates oder die Einstellungen für das automatische Update), der muß sich halt das Skript entsprechend anpassen - das ist ja nicht so kompliziert. Die ganzen Einzelheiten in so einer Antwort verwaltet man vermutlich ohnehin besser in einer Datenbank anstelle irgendeiner Textdatei im Dateisystem.

@Daniel Lücking:
Da meinst Du jetzt aber hoffentlich die Firmware-Version aus #4, oder?

Das Skript sollte jedenfalls tatsächlich Daten senden (auch nach Moabit), die sollten aber nur dieselben sein, wie bei jeder Update-Prüfung in der Box selbst auch.

@koy:
Ich weiß auch nicht, ob die 7560 bereits über den neuen Service arbeitet ... ich würde denken, das es so ist, aber ohne jeden Beweis dafür oder dagegen.

Ansonsten einfach mal mit der Angabe einer älteren Version beim Aufruf (juischeckupdate 192.168.178.13 Public=1 Version=149.06.??-????? - die Fragezeichen halt passend ersetzen) prüfen, ob die aktuelle Version angezeigt wird. Meines Wissens liefert auch die Abfrage mit "Public=0" keine offiziellen Labor-Versionen als Ergebnis - wie das bei Release-Versionen aussehen mag, muß man wohl noch etwas abwarten, bis da erste Release-Versionen erschienen sind.

Wobei mir gerade noch aufgefallen ist, daß ältere Firmware bzw. Release-Versionen in der jason_boxinfo.xml die Revision nicht zwangsläufig noch einmal hinter der Versionsnummer stehen haben - das werde ich mal noch einbauen und beim Zusammenstellen von "Version" aus den Angaben in der FRITZ!Box berücksichtigen.

@Daniel Lücking:
Das mit der LED hatte ich an anderer Stelle schon registriert, aber eben keine Idee für eine (permanente) Lösung ... ich denke mal, es ist ein Fehler bei AVM im Treiber oder dem zuständigen LKM.

Die LED-Steuerung hat AVM ja merkwürdigerweise nicht in den Kernel gelinkt, sondern als Module nachladbar gemacht - daher läßt sich das auch erst relativ spät im Bootprozess überhaupt steuern.

Da sich die "Semantik" der LED "Internet" ja etwas verändert hat ggü. anderen Modellen, denke ich mal, AVM wird das irgendwann noch korrigieren. Meines Wissens gibt es keinen "allgemeinen" GPIO-Pin, über den man alle LEDs ausschalten kann, also muß das für jede LED einzeln passieren und das liegt ggf. noch irgendwo daneben - vermutlich weniger beim direkten Zugriff auf den Pin, sondern eher auf einer höheren Abstraktionsebene.

Wie hast Du überhaupt den Shell-Zugriff auf die 7580 erlangt? Oder ist es die "Inhouse-Version" mit ohnehin enthaltenem Shell-In-A-Box-Zugang?

Bei Shell-Zugriff kann man jedenfalls mal mit "led-ctrl -l" die möglichen Aktionen auslesen und sie der Reihe nach durchprobieren (am besten immer mit "event=0" im Anschluß wieder zurücksetzen, denn die resultierende Anzeige ist das Ergebnis eines "Stacks", wo die eigentliche Ursache für das Leuchten der LED auch "weiter unten" liegen kann) - wenn man dann ein Ereignis gefunden hat, was die LED ausschaltet, muß man das eben nach jedem Neustart (bzw. nach jedem gegenteiligen Ereignis) erneut aufrufen. Das setzt ja dann nur die LEDs entsprechend und löst das "Ereignis" nicht wirklich aus (Ursache und Wirkung).

Die Frage wäre auch, ob "led-ctrl display_suspend" die nun mit abschaltet oder nicht ... "led-ctrl display_wakeup" macht das rückgängig.

"switch" soll sicherlich "shift" sein.

Fehler in Zeile 176?

Wie man's nimmt ... wenn man das Prinzip verstanden hat und den Namen unbedingt von Hand in der Datei angeben will, muß man da eben genug Escapes einbauen, damit das Leerzeichen später nicht als "word boundary" zählt. Das gilt analog auch für das Ausrufungszeichen in "FRITZ!Box" ... so etwas ist unter Shell-Bedingungen immer schwierig und vermutlich ist auch das eher der Fehler gewesen, als das Leerzeichen - das wäre m.E. sauber eingeschlossen mit "double quotes" um den Variablenwert herum.

Daher wird auch beim Lesen aus der Box selbst (Zeile 174) anstelle von "double quotes" mit "single quote" gearbeitet, da in einer Variablen, die aus der Box gelesen wurde, keine weitere Ersetzung notwendig sein sollte bzw. erwartet wird.

Das ist aber gerade bei indirekt referenzierten Variablen in der Konfigurationsdatei (das ist schließlich "bash", da gibt es derartige Konstrukte) nicht in jedem Falle so ... ich schrieb nicht umsonst irgendwo (denke in #1), daß die Konfigurationsdatei richtige Shell-Kommandos enthält und nicht nur irgendwelche stumpfen Variablenzuweisungen.

Wenn man also im Namen am Ende ein Leerzeichen haben will, muß man einfach nur
verwenden ... eigentlich ganz einfach, wenn man vorher mal das Skript gelesen hat.

Im Prinzip sollte genau so etwas, wie es @koy dann realisiert hat, ebenfalls möglich sein und bleiben (bei ihm dann eben drei "positional parameter", wobei man das auch mit $1 bis $3 und einem einzelnen "shift 3" hätte regeln können) ... man kann in der Konfigurationsdatei ziemlich beliebig die Daten hin und her schieben, solange am Ende die Variable "Box" gesetzt ist und jede andere, die man speziell belegen und nicht aus der Box auslesen will.

Ansonsten gehört da an eine "handgemachte" Versionsangabe eben noch die Build-Nummer ans Ende - beim Auslesen aus der Box wird die inzwischen ja sogar noch gesondert aus "Revision" erzeugt, wenn sie in der jason_boxinfo.xml nicht hinter der Versionsnummer steht.

Die korrekte Versionsangabe wäre also "113.06.69-41137" ... da das intern in vier einzelne Werte zerlegt werden muß (der Aufruf bei AVM will die einzeln sehen), ist der Aufbau wichtig und einzuhalten.

Generell gilt: Wenn man einen Fehler in einem Shell-Skript suchen will, ruft man das einfach mit einem "bash -x" davor auf ... nur durch reine Gedankenübertragung oder die Feststellung "geht nicht" wird die Suche nach einem Fehler eher nicht funktionieren.

Da es ohne eigene Konfigurationsdatei (bzw. zumindest mit dem "mitgelieferten Beispiel", wo die IP-Adresse der Box der erste Parameter beim Aufruf ist) ja funktioniert, wäre ich jetzt auch nicht als erstes auf die Idee gekommen, im Skript herumzuändern. Was sich jetzt aus der Änderung des "eval"-Statements in Zeile 176 auf "double quotes" mit Escapes für Konsequenzen für die anderen Variablen ergeben, kann man von außen auch schwer einschätzen ... genau deshalb nimmt man ja die Debug-Option zuhilfe, wenn man etwas am Code des Skripts geändert hat (bzw. sogar bei unklarem Verhalten in der Auswertung der "Konfigurationsdatei").

Wenn in der Fehlernachricht gar kein Status-Code steht, ist wohl die Antwort nicht die erwartete oder gar ganz ausgeblieben ... bei falsch aufgebautem Request auch nichts Ungewöhnliches.

Eigentlich sollte das auch nur eine Fingerübung bzw. eine Anregung für eigene Versuche sein ... wer lustig ist, kann ja noch die Berücksichtigung einer "debug"-Option beim Aufruf im Code ergänzen und die beiden Request-Dateien inkl. der Antwort von AVM über STDERR für die Fehlersuche ausgeben.

PS: Gerade wegen der (wechselnden) Versionsnummer habe ich ja das Auslesen der "jason_boxinfo.xml" eingebaut ... eine Update-Prüfung, bei der ich immer erst von Hand die aktuelle Versionsnummer raussuchen oder in einer Datei eintragen muß, ist halt recht unhandlich ... und wenn man schon die Versionsnummer in aller Regel auslesen wird, dann kann man die anderen Angaben (Serial, Name, usw.) auch gleich noch von dort holen.

Ich weiß zwar nicht, was Dich gebissen hat ... aber wahrscheinlich habe ich wirklich eine sehr spezielle "bash", denn bei mir macht die (mit dem Skript, so wie es im Repo steht und nicht mit dem von Dir geänderten) genau das mit dieser Zeile als Name, was ich geschrieben habe.

Außerdem zwingt Dich niemand, dieses Skript überhaupt zu verwenden ... gerade dann, wenn es von jemandem stammt, der Deiner Ansicht nach ja gar keine Ahnung von der "bash" hat; wer weiß denn schon, was der da noch für Fehler eingebaut hat.

Die "Klammerung" praktisch jeder Variablenzuweisung (sofern ich darin eine Zeichenkette vermute) in "double quotes" ist bei mir reine Gewohnheitssache und eben genau der Tatsache geschuldet, daß ansonsten z.B. ein Whitespace (was dazu genau zählt, ist abhängig vom Inhalt von $IFS) in einer Variablen in Shell-Code schnell mal zu unerwarteten Ergebnissen führt.

Bei einem "eval" wäre das tatsächlich nicht notwendig, weil der Tokenizer das ohnehin "wegoptimiert" - eben deshalb schadet es an dieser Stelle auch nicht. Trotzdem lasse ich mich nicht von meiner "gewohnten Schreibweise" abbringen, man findet das auch an vielen anderen Stellen in meinen Skript-Dateien. Wenn man davon ausgehen kann/muß, daß eine Zeichenkette auch Zeichen aus der IFS-Variablen enthalten kann, ist das der einzig sichere Weg, so eine Variable "als Ganzes" zu referenzieren ... bei "single quotes" erfolgt ja keine Substitution. Trotzdem habe ich auch in dem Skript tatsächlich noch Schwachstellen ... z.B. wenn "Public" aus einem Wert mit Leerzeichen bestehen würde. Das ist aber auch alles andere als neu ... Parameter mit Leerzeichen im Wert sind unter Linux immer etwas kritischer.

Wenn Dir meine Handhabung der Parameter nicht paßt, mache es einfach besser - ich habe auch nicht geschrieben, daß ich Deinen Punkt absolut nicht nachvollziehen kann ... da steht bei mir deutlich "wie man's nimmt" und ich sehe es halt anders.

Ich bleibe auch bei meiner Einschätzung und wenn Du die Meinung, daß derartige Werte besser mit Escapes (und zwar in passender Zahl, denn da ist einmal eine indirekte Referenz (var="${!n}") und einmal das "eval" am Start) behandelt werden, nicht teilst, kann ich damit leben. Ich teile die Deine ja auch nicht ... das ändert nichts daran, daß die von mir vorgeschlagene Lösung bei mir definitiv zu einem anderen Ergebnis führt als bei Dir - vielleicht hat ja meine "bash" auch nicht verstanden, was Deine da veranstaltet.

Auch hält Dich tatsächlich niemand davon ab, es so umzugestalten, wie Du es für richtig hältst ... so wie ich durchaus verstehe, daß es andere Lösungen als die meine geben mag (das ist bei Shell-Code nahezu zwangsläufig), so wirst auch Du akzeptieren müssen, daß ich es nach wie vor für richtig halte.

Hatte die Ehre ... vielleicht kommst Du ja noch dahinter, was bei Dir nun dazu führte, daß die von mir vorgeschlagene Variante nicht die erwartete Wirkung entfaltete. Dann hätte ja wenigstens einer von uns beiden verstanden, "wie bash funktioniert".