Wie installiere ich das jetzt bei mir?
So etwas ist pauschal ja schlecht zu beantworten, aber zwei mögliche Wege greife ich mal heraus.
Das wäre als erstes der Download der Skript-Datei als "raw file" von GitHub - das ist dann eben der "Text" aus der Skript-Datei und da das Ganze ja nur aus dieser einen Text-Datei besteht, braucht es keine Kommandos zum Entpacken oder ähnlichem. Es reicht vollkommen, die gespeicherte Datei noch als "ausführbar" zu markieren und schon kann man sie aufrufen: " wget
"
- sollte sich das Verzeichnis, in dem man die Datei gespeichert hat, in der PATH-Variablen befinden, kann man das "./" vor dem Namen halt auslassen.
Die zweite Möglichkeit wäre das Klonen des kompletten Repos von GitHub, natürlich am besten in ein Dateisystem, welches native Linux-Zugriffsrechte unterstützt:
cd /tmp
git clone
Da beim Klonen auch die Zugriffsrechte korrekt gesetzt werden, braucht es hier kein "chmod", nur den Wechsel in das richtige Unterverzeichnis, bevor man das Skript dann aufrufen kann.
Wer das auf anderen Wegen "installieren" will (das ist ja ohnehin viel zu hochtrabend für das Speichern einer Text-Datei und das Setzen von Zugriffsrechten), der wird sicherlich auch die notwendigen Schritte und Kommandos auf seinen eigenen System kennen, die er dafür braucht.
Wo kann ich das Skript überall benutzen?
Kurz gesagt ... das Skript sollte fast überall zum Laufen zu bewegen sein - manchmal muß man sich vielleicht erst noch eine passende(!) BusyBox mit allen benötigten Applets besorgen, wenn man ein sehr exotisches (und von sich aus sehr beschränktes) System verwenden möchte.
Wie verwende ich das Skript bei meiner eigenen Box?
Das Skript kann problemlos mit der Option "--help" (oder kurz auch "-h") aufgerufen werden, dann zeigt es einen (eher längeren) Text an, wie man es aufrufen kann und welche Angaben es versteht. Diese Hilfe-Seite
werden - wenn das Ausgabegerät ein Terminal ist und das Programm "less" (das ist ein "terminal pager", also ein Programm zur seitenweisen Anzeige einer Datei) vorhanden ist - auf dem Terminal mit genau diesem "less" angezeigt, ansonsten ohne "less". (Wer sich mit "less" nicht auskennt: Mit einem einfachen "q" kann man das Programm wieder verlassen.)
Dieselbe Information (nur etwas anders formatiert) findet man auch im Repository und zwar sowohl in
als auch in
. Es wäre nett, wenn man sich einfach dort (GitHub oder Hilfetext) erst einmal informiert und dann - wenn man wirklich etwas nicht verstanden hat und auch mit (mehr oder weniger mutigem) Probieren nicht mehr weiterkommt (es kann ja absolut nichts passieren, hier wird nicht ein Bit an der Box wirklich geändert und eigene Erfahrungen sind meist durch nichts Gleichwertiges zu ersetzen), aber wirklich erst dann, mit einer eigenen Frage hier aufläuft - wobei man dann idealerweise auch noch ein paar Seiten in diesem Thread rückwärts gelesen hat, damit die eigene Frage nicht einfach auf der vorherigen Seite schon (möglichst noch mehrfach) beantwortet wurde.
Ansonsten reicht es tatsächlich aus, das (korrekt installierte) Skript mit der Angabe des Namens oder der IP-Adresse einer lokal erreichbaren FRITZ!Box aufzurufen:
./juis_check 192.168.13X.1 -> verschiedene Boxen bekommen die passende ip
Wer das lieber etwas ausführlicher haben möchte, der gibt dann beim Aufruf noch die "debug"-Option mit an, das sieht dann etwa so aus:
./juis_check -d 192.168.178.1
Im einfachsten Fall fragt man aber auch bloß den Exit-Code des Skripts ab, bei "2" gibt es keine neue Firmware und bei "0" kriegt man auf STDOUT die URL geliefert, von der man die neue Firmware laden könnte.
Wie kann ich Firmware für eine andere FRITZ!Box finden, die ich vielleicht nicht einmal selbst besitze?
Was genau AVM jetzt an Parametern für eine Antwort auswertet, variiert (zumindest dem Anschein nach) wohl von Modell zu Modell und hängt u.a. auch davon ab, welche "Geschmacksrichtung" der Firmware man nun eigentlich sucht.
Was offensichtlich auf jeden Fall zum abgefragten Modell passen muß, ist der Wert von "HW", was als "HWRevision" im Gerät hinterlegt ist. Das ist deshalb so offensichtlich, weil der Servername bei AVM, an den man den SOAP-Request senden muß, diese Nummer als ersten Bestandteil enthält, danach folgt dann erst ".jws.avm.de" - für eine 7490 mit "HWRevision 185" ist dann der Servername bei AVM also "185.jws.avm.de".
Alle anderen Parameter werden bei einigen Modellen berücksichtigt und bei anderen wieder nicht ... eine echte Systematik scheint dort nicht zu existieren und wenn man mit nur wenigen passenden Angaben gar keine Antwort (sondern einen Server-Fehler) oder immer wieder eine "falsche Antwort" erhält, muß man eben so lange die Parameter variieren und mit den richtigen Angaben für die gewünschte Box ergänzen, bis die Abfrage dann doch mal klappt. Wer richtig schlau ist, merkt sich diese Parameter-Kombination dann für das nächste Mal ...
Für eine 6590 reicht es z.B. bereits aus, wenn man nur die richtige "HW"-Angabe verwendet und noch ein zusätzliches "Flag", was so auch nur bei den DOCSIS-Modellen existiert und bei der 6490 wieder ignoriert wird (Beispiele im nächsten Abschnitt).
Für eine 7490 wäre z.B. das die minimale Bestückung mit Parametern, bei der ich noch eine sinnvolle Antwort vom AVM-Service erhalten kann:
.. /YourFritz/juis # juis_check -d -i HW=185 Version=000.00.00-00000 Serial=12 Name=7490 OEM=avm Lang=empty Annex=empty Country=empty Flag=empty
was also auch noch nicht unbedingt der Maske nach eine MAC-Adresse sein muß - es reicht bereits, wenn es mind. ein alphanumerisches Zeichen ist ... dazwischen könnten sogar Leerzeichen auftauchen neben den alphanumerischen Zeichen, solange das letzte keines ist. Meine Angabe "12" oben paßt jedenfalls auf diese Maske.
Weiß man also nicht genau, welche Angaben AVM für die eigene Box erwartet und welche davon ggf. auch noch stimmen sollten, selbst wenn man ein Modell abfragen will, auf welches man selbst keinen Zugriff hat und damit auch die richtigen Werte weder von Hand nachschlagen noch von diesem Skript automatisch auslesen lassen kann, dann tastet man sich halt solange mit weiteren Angaben vor, bis einem die Antwort irgendwann mal gefällt.
Dabei darf man auch keine Scheuklappen aufhaben, weil nicht immer ein direkter Zusammenhang zwischen einem Parameter und einer "ablehnenden Antwort" ersichtlich ist ... die oben gezeigte Abfrage für die 7490 liefert z.B. die Information "keine neue Firmware", wenn man den OEM-Wert nicht angibt:
juis_check -i HW=185 Version=000.00.00-00000 Serial=12 Name=7490 OEM=empty Lang=empty Annex=empty Country=empty Flag=empty
Es gibt also kein echtes "Rezept" dafür, was an Parametern jeweils passend sein muß ... es kann aber auch nichts passieren bei einem eigenen Test. Vielleicht springt AVM etwas im Dreieck, aber so ein öffentlich erreichbarer Service sollte auch gegen echte Angriffe gewappnet sein und da ist das, was wir hier machen, eher Kinderkram. Man darf also auch nicht zu schüchtern sein (die Debug-Ausgabe ist natürlich auch hilfreich, wenn man ein Problem finden will) - notfalls fragt man dann andere hier im IPPF, die so ein Gerät besitzen und die richtigen Werte auslesen lassen können.
Denn natürlich gilt auch hier die Regel, daß es kein Problem darstellt, wenn man einen von AVM nicht wirklich ausgewerteten Parameter trotzdem richtig und vollständig angibt - es gibt keine "Pflicht zur Lücke" und nicht einmal die Angabe der eigenen, korrekten MAC-Adresse der Box sollte ein Problem darstellen ... denn das, was das Skript hier macht, ist keinesfalls illegal oder sonst irgendwie "anrüchig".
Es gibt auf diesem AVM-Service keine weitere Zugangssicherung für eine Abfrage (nicht einmal eine "symbolische", die vermutlich auch nicht als rechtliche Handhabe ausreichen würde) - damit muß da auch nichts überwunden werden und man darf bei so einem Service tatsächlich erwarten, daß er auch gegen Fehl"eingaben" bestens gehärtet ist.
Solange jetzt also nicht Millionen von Abfragen in kurzer Folge stattfinden, die nicht von den FRITZ!Boxen stammen, sollte das bei AVM in den Server-Logs auch kaum auffallen. Ich würde aber auch darum bitten, daß man das Skript mit Sinn und Verstand anwendet ... wer regelmäßig nach neuer Firmware sucht, sollte das selbst in den Zeiten einer Labor-Reihe in einem vernünftigen Intervall machen (mind. 60 Minuten erscheinen mir angemessen). Wer das nur benutzt (und zwar mit sehr kleinen Intervallen), um immer mal wieder "Erster" zu sein beim Finden einer neuen Firmware, konterkariert meine eigenen Intentionen mit diesem Skript auf recht hässliche Weise.
Wie wäre es mal mit ein paar Beispielen?
Ausnahmsweise ... hier z.B. die Abfrage für die 6590, bei der alles auf der Kommandozeile angegeben wird:
juis_check -i HW=220 Version=000.00.00-00000 Serial=12 Name=6590 OEM=avm Lang=empty Annex=empty Country=empty Flag=cable_retail
oder:
juis_check -i HW=220 Version=000.00.00-00000 Serial=12 Name=6590 OEM=avm Lang=empty Annex=empty Country=empty Flag=empty
Die funktioniert (wie schon mal erwähnt) eben ohne das "Flag=cable_retail" nicht, wie man oben sehen kann ... bei der 6490 ist das hingegen nicht erforderlich:
juis_check -i HW=213 Version=000.00.00-00000 Serial=12 Name=6490 OEM=avm Lang=empty Annex=empty Country=empty Flag=empty
root/bin/juis_check: No newer version found, check was made with source version '0.00.00-00000'.
vidar:~/GitHub/YourFritz/juis # juis_check -i HW=213 Version=141.06.00-00000 Serial=12 Name=6490 OEM=avm Lang=empty Annex=empty Country=empty Flag=empty
root/bin/juis_check: No newer version found, check was made with source version '141.06.00-00000'.
vidar:~/GitHub/YourFritz/juis # juis_check -i HW=213 Version=141.06.60-00000 Serial=12 Name=6490 OEM=avm Lang=empty Annex=empty Country=empty Flag=empty
root/bin/juis_check: Found newer version: 141.06.87
URL=
Dafür muß man hier, wie man oben in den letzten beiden Aufrufen sehen kann, wenigstens die Versionsnummer bis zum Wert von "Patch" angeben, ansonsten ist die Antwort nicht die richtige.
Am bequemsten ist es natürlich, wenn man einfach nur die IP-Adresse der eigenen Box angeben muß - oder auch "fritz.box", wenn man den aktiven Router abfragen will. Der löst i.d.R. "fritz.box" als DNS-Server auf seine eigene Adresse auf. Das ist aber oben bei "eigene Box" ausreichend gezeigt.
Was hat es denn jetzt mit diesen "internen Versionen" auf sich?
Das ist auch schnell erklärt ... offenbar verwenden auch andere "externe Tester" (oder gar die AVM-Mitarbeiter selbst bei sich daheim) FRITZ!Boxen mit einer Firmware, die noch nicht offiziell verfügbar ist, also weder als Release- noch als offizielle Labor- oder Beta-Version. Auch diese muß ja irgendwie mal aktualisiert werden (es macht sicherlich wenig Sinn, wenn die AVM-Mitarbeiter zuhause mit Versionen arbeiten müssen, die gar nicht mehr dem aktuellen Stand entsprechen) und so suchen wohl auch diese Boxen über den AVM-Service nach Updates für ihre Firmware.
Diese ist dann auch gerne mal mit "Zusatzfunktionen" ausgestattet, z.B. mit einer Shell-In-A-Box-Version, die mit dem Box-Zertifikat über eine TLS-Verbindung sogar einen sicheren Shell-Zugang (sogar von der WAN-Seite) bereitstellen kann oder auch mit ein paar zusätzlichen Debug-Skripts und anderen Programmen, die von AVM in den offiziellen Versionen entsorgt wurden, weil sie ein Sicherheitsproblem darstellen.
Unter anderem deshalb sind diese Versionen eigentlich wirklich nichts zum Spielen und wer sie sich nur installiert, weil er es kann, möge sich hinterher weder darüber aufregen, wenn die Box gar nicht mehr geht und er sie irgendwie wieder zum Leben erwecken muß oder wenn durch diese Zusatzprogramme am Ende wieder Lücken gerissen werden, die in offizieller Firmware gar nicht vorhanden sind und er darüber irgendwie angegriffen wurde (für "webcm" braucht man nur eine gültige SID und die dazugehörige IP-Adresse - das geht notfalls auch im Browser über ein Advertising mit passendem JS-Code als Malware).
Wie auch immer ... man kann auch für diese Versionen mit dem Skript eine Abfrage an den AVM-Service richten und wenn AVM das wirklich in ernsthaftem Maße stören sollte, kann man dort ja problemlos den Service weiter abdichten - entweder auf der Serverseite, die nur noch bestimmte Abfragen beantwortet oder auf der Client-Seite, indem man einen anderen Server verwendet (also das "jws.avm.de" durch etwas anderes ersetzt). Insofern habe ich auch hier wenig "Herzdrücken" - wer so etwas nicht mit einer Zugangssicherung versieht, wird sich eher nicht wundern (bzw. darf sich nicht wundern), wenn es von anderen genutzt wird.
edenfalls kann man mit der Angabe von "Public=0" beim Aufruf auch versuchen, eine "nicht-öffentliche" Firmware-Version zu ergattern ... dabei werden aber (so zumindest meine bisherigen Ergebnisse) noch ein paar mehr Angaben berücksichtigt, die dann zur angeblichen Box passen müssen. Wer die Box tatsächlich besitzt, sollte aber wenig Probleme haben, von AVM eine sinnvolle Antwort zu erhalten ... aber es gibt diese "inhouse"-Versionen lange nicht für alle Modelle.
juis_check -d 192.168.13X.1 Public=0
Wie man sehen kann (zumindest wenn man sich damit auskennt), ist die Ausgangsversion auf der verwendeten Box eine ganz normale Release-Version 113.06.92, die bis gestern auch noch die aktuellste Version war. Trotzdem wird mit "Public=0" dann nicht die seit gestern aktuelle 113.06.93 gefunden (weiter oben in einem Beispiel hingegen schon), sondern eine vollkommen andere Version, die als Name dann "_INTERN Inhaustest IQ17p2" hat ("17p1" war sicherlich die 06.9x-Release, wenn man nach den URLs für die Online-Hilfe geht).
.. vom PeterPawn
, 
