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

Ich habe unter dem Namen "juis_check" (mit abweichender Endung "cfg" auch für die Konfigurationsdatei) eine andere Variante eingecheckt, die auf die Benutzung der "bash" als Shell und auf "xmllint" für das Parsen mit "xpath" verzichtet und auch anstatt "wget" nur noch "nc" für den Netzwerkzugriff verwendet.

Hier ist das Auslesen von XML-Daten dann eben etwas unsicherer (da wird "sed" genommen), aber dafür eignet sich diese Version besser für die Update-Prüfung in "modfs" ... ich wollte weder "xmllint" noch eine "bash" als Standalone-Programm (statisch gelinkt) nur für diese Prüfung in das "modfs"-Archiv aufnehmen müssen.
 
Hab als Linux relativ Unkundiger erst mal versucht, das Ubuntu in Win10 zu aktivieren und zu nutzen, damit habe ich keine der 2 Versionen zum laufen gebracht. Hab mir dann die aktuelle Knoppix-Version runtergeladen, damit konnte ich Version 2 zum Laufen bewegen, vielen Dank für deine Arbeit, vor allem für die gute Dokumentation, da macht es Freude, zu experimentieren. Die Version 1, die bei mir nicht funktioniert, bringt mich dazu, mich mal wieder mit Linux zu befassen, ich habe dort den Ehrgeiz, das Problem selbstständig zu lösen. Habe sonst, außer bei meiner Dreambox, kaum Berührung zu Linux gehabt.
Gruß digi1
 
Hallo, habe mich mal mit der 7580 an dem Script versucht.
Bekomme immer diese Ausgaben beim 2ten Script.

desinfect@desinfect:~/Downloads$ ./juis_check 192.168.2.1
./juis_check: 155: [: x192.168.2.1: unexpected operator
./juis_check: 185: [: Serial: unexpected operator
./juis_check: 187: [: x: unexpected operator
./juis_check: 185: [: Version: unexpected operator
./juis_check: 187: [: x: unexpected operator
./juis_check: 185: [: Name: unexpected operator
./juis_check: 187: [: x: unexpected operator
./juis_check: 185: [: HW: unexpected operator
./juis_check: 187: [: x: unexpected operator
./juis_check: 185: [: OEM: unexpected operator
./juis_check: 187: [: x: unexpected operator
./juis_check: 185: [: Lang: unexpected operator
./juis_check: 187: [: x: unexpected operator
./juis_check: 185: [: Annex: unexpected operator
./juis_check: 187: [: x: unexpected operator
./juis_check: 185: [: Country: unexpected operator
./juis_check: 187: [: x: unexpected operator
./juis_check: 185: [: Public: unexpected operator
./juis_check: 187: [: x: unexpected operator
./juis_check: 207: [: x: unexpected operator
./juis_check: 209: ./juis_check: Bad substitution

Was mache ich falsch?
Script 1 läuft auch nicht.

Danke für Eure Tipps.

Grüße
Jens
 
Läuft die "desinfec't"-Version nicht auf der Basis von Ubuntu?

Vermutlich ist da wieder "dash" als "/bin/sh" verlinkt, dann hilft es, die erste Zeile in "juis_check" auf "#! /bin/bash" zu ändern (solange man außerhalb der FRITZ!Box ist). Wenn es dann auch noch nicht will, braucht es schon die Debug-Ausgabe (gilt auch für die erste Version mit "bash" und "xmllint", "läuft auch nicht" ist als Fehlermeldung etwas schmal), die man durch Aufruf mit "bash -x ..." (an die Stelle der drei Punkte kommt der sonstige Aufruf) erzeugen kann.

Mir ist zwar bewußt, daß viele eher unerfahrene Linux-Benutzer einen Ubuntu-Ableger (bzw. generell ein Debian-basiertes System) benutzen, aber ich habe die "dash" als "/bin/sh" dort nicht eingeführt und es war lange Jahre "Konsens", daß dort die aktuell verwendete Shell des Benutzers verlinkt ist. Wenn der "ksh" benutzt, funktioniert die Syntax ebenfalls nicht ... die zweite Version des Skriptes (juis_check) baut auf die Shell der BusyBox (die erste auch nur deshalb auf "bash", weil da der direkte Zugriff über "/dev/tcp" möglich war, die Verwendung der indirekten Adressierung bei Variablen war nur der Tatsache geschuldet, daß es eben ohnehin ging) - und die unterstützt nun mal einiges an (nützlichen) "bash-ismen".

Abgesehen davon kann ich den tatsächlichen Sprachumfang der "dash" auch nicht wirklich berücksichtigen, weil ich eigentlich Debian-basierte Distributionen eher ablehne (zumindest nicht freiwillig benutze) und mir die "dash" jedesmal gesondert für Tests installieren müßte.

Da der Posix-Standard (und mehr kann "dash" nicht) nicht einmal die "substring expansion" (n=${var:start:len}) versteht und an dieser Stelle meist die Benutzung von "awk" empfohlen wird, ist das aber auf einer originalen FRITZ!OS-Installation von AVM ohnehin kaum möglich, auf diesen "bash-ismus" zu verzichten ... die BusyBox von AVM kennt nämlich auch kein "awk".

Da sind die Fehler oben (die aus der Verwendung von "==" anstelle von "=" resultieren) eher Nebenkriegsschauplätze ... wobei man vermutlich auch den Test einer Variablen auf den Beginn mit "fixed:" irgendwie noch hinbekommt ohne "awk". Aber es erfordert eben wesentlich höheren Aufwand und auch Tests, was denn nun als "/bin/sh" verlinkt wäre und was als "$SHELL" gesetzt ist (damit man sich notfalls selbst noch einmal mit "/bin/bash" als Shell aufruft), sind zusätzlicher Aufwand, der auf der Box witzlos ist (da gibt es nur "ash" aus der BusyBox als "/bin/sh") und auch wenn ich den Ansatz der höheren Geschwindigkeit der Abarbeitung der "dash" nachvollziehen kann, haben die Ubuntu-Leute da nicht nur sich selbst ein Ei gelegt: https://wiki.ubuntu.com/DashAsBinSh

- - - Aktualisiert - - -

Ich habe mal (nur so zum Spaß) das Skript "juis_check" POSIX-kompatibel gemacht ... angesichts der dazu notwendigen Änderungen kann man sicherlich verstehen, wenn ich mich auch künftig bei "/bin/sh" auf die "ash" der BusyBox verlasse/einrichte und da, wo es unbedingt die "bash" sein soll/muß, das dann explizit angebe.
 
Ich sag auch mal DANKE, läuft :bier:
 
@PeterPawn
Danke das klappt dann "die erste Zeile in "juis_check" auf "#! /bin/bash" zu ändern"

Super
 
Wenn der AVM-Server etwas langsamer reagiert, hatte das POSIX-kompatible "juis_check" noch ein Problem, weil das eingesetzte 'nc'-Applet (oder Programm, falls ein anderes als das in der BusyBox benutzt wird) bei EOF auf STDIN auch die TCP-Verbindung sofort abbaut und die Option, das nicht zu tun (-q), bei einigen "nc"-Implementierungen vorhanden ist und bei einigen nicht.

Ich habe die POSIX-Variante nun auf die Benutzung eines FIFOs für den STDIN-Stream beim "nc" umgestellt und es wird jetzt für eine eingestellte Zeitspanne (timeout=20 in der Standardversion im Repo) getestet, ob die Antwort des Servers vollständig ist (Ende-Tag für "soap:Envelope" ist vorhanden). Anders wollte es auf einer 6490 (wo das 'nc'-Applet noch in der AVM-BusyBox vorhanden ist) nicht richtig funktionieren - die Option "-i 1" für eine Sekunde zwischen einzelnen Zeilen beim Senden hat hier nicht wirklich geholfen und die neue Lösung sollte zuverlässiger funktionieren.

Auch das "mktemp" (bei AVM nicht vorhanden) habe ich etwas aufgebohrt, damit sollte es problemlos auch auf originaler Firmware laufen.

Als Alternative gibt es ja auch noch im "modfs"-Repository eine Variante, welche direkt die Daten der aktuellen Box (also der, auf der das Skript läuft) aus der "/var/jason_boxinfo.xml" ausliest und auch die Angabe von zusätzlichen Parametern beim Aufruf nicht unterstützt.
 
habe beide Versionen auf einer VM mit Ubuntu 16.10 erfolgreich zum Laufen gebracht, allerdings wird mir keine der developer / internen Versionen als neuere Version angeboten.

Config:

Box=$1
shift
Public=$1
shift


Aufruf: ./juischeckupdate 192.168.178.1 0

No newer version, found, check was made with source version '153.06.69-41987'

Mach ich was falsch, oder funktioniert das Skript fuer die 7580 Firmwares noch nicht?
 
Mach ich was falsch, oder funktioniert das Skript fuer die 7580 Firmwares noch nicht?
Keine Ahnung, ich habe keine Box zum Testen.

Ad hoc würde ich sagen, daß da die falsche Revision gesendet wird und nur von einer Inhouse-Version aus auch auf eine "Public=0"-Version aktualisiert werden kann. Das müßte aber ggf. einer der Besitzer einer 7580 mit einer Inhouse-Version testen.

Welche Parameter AVM nun genau beim Service prüft, weiß ich auch nicht ... aber da war AVM ohnehin noch am Bauen.

Inzwischen gibt es eigentlich eine "juis_boxinfo.xml" auf den Boxen, die man anstelle der "jason_boxinfo.xml" vermutlich benutzen sollte - aber auch das ist bisher bei mir nur für die 7490 getestet.

Solange die 7490 offenbar noch das primäre Modell bei AVM für die Laborversionen ist (vielleicht ändert sich das ja nach dem nächsten Release schon), bleibe ich auch bei der 7490 - und solange die Kinderkrankheiten nicht beseitigt sind, will ich auch keine 7580 testen und untersuchen. Das muß sich alles erst mal etwas "settlen". Löcher finden sich vermutlich auch im Anschluß noch genug.

Wenn jemand mal eine (erfolgreiche) Abfrage des Services bei AVM mitschneiden kann, schaue ich es mir mal an ... ansonsten funktionieren eben nur die "offiziellen" Versionen.
 
Moin

PeterPawn schrieb:
Inzwischen gibt es eigentlich eine "juis_boxinfo.xml" auf den Boxen, die man anstelle der "jason_boxinfo.xml" vermutlich benutzen sollte - aber auch das ist bisher bei mir nur für die 7490 getestet.
Auf/In der BETA 6.69 für die 7560 sind beide vorhanden.
Also: jason_boxinfo.xml und...
juis_boxinfo.xml
HTML:
<e:BoxInfo*xmlns:e="http://juis.avm.de/updateinfo"*xmlns:q="http://juis.avm.de/request">
<q:Name>FRITZ!Box 7560 (UI)</q:Name>
<q:HW>221</q:HW>
<q:Major>149</q:Major>
<q:Minor>6</q:Minor>
<q:Patch>69</q:Patch>
<q:Buildnumber>41802</q:Buildnumber>
<q:Buildtype>1001</q:Buildtype>
<q:Serial>FFFFFFFFFFFF</q:Serial>
<q:OEM>1und1</q:OEM>
<q:Lang>de</q:Lang>
<q:Country>049</q:Country>
<q:Annex>B</q:Annex>
<q:Flag>crashreport</q:Flag>
<q:Flag>prov_acs</q:Flag>
<q:Flag>avm_acs</q:Flag>
<q:UpdateConfig>1</q:UpdateConfig>
<q:Provider>1und1</q:Provider>
</e:BoxInfo>
 
Zuletzt bearbeitet:
@koy:
Ist bei der Labor für 7490 auch so ... es gibt sie beide, aber die Datenfelder sind etwas anders zusammengestellt (Major, Minor, Patch, ...). Das hat mich bisher auch noch davon abgehalten, da eine Änderung vorzunehmen. Ich stelle mir das im Moment so vor, daß AVM irgendwann mal die "jason_boxinfo.xml" vielleicht abschaffen wird (wenn die nicht doch auch für MyFRITZ!-Konten gebraucht wird, ich habe da eine dunkle (und verschwommene) Erinnerung). Daher war der Plan, zuerst nach der "juis_boxinfo.xml" zu suchen und die "jason_boxinfo.xml" nur noch als Fallback für den Fall der fehlenden "juis_boxinfo.xml" zu verwenden. Aber im Moment ist die ohnehin nur in den Laborversionen vorhanden und ich habe inzwischen gelernt, daß man sich besser nicht darauf verläßt, daß so etwas auch "das Licht der Welt" im Release erblickt. Also warte ich einfach mal ab ...

@Shirocco88:
Kein "modfs" bisher - die Partitionen (filesystem + NAS, bei der 7560 auch nur rudimentär vorhanden) haben bei beiden 75x0-Modellen einen UBIFS-Layer und das ist mir zu heiß, da irgendetwas nur nach Theorie zusammenzuklöppeln und dann muß ein anderer die Suppe auslöffeln (bzw. für mich testen und ich habe keinen direkten Einfluß). Wer einen Blick ins Dateisystem wagen will, kann die Images entpacken - unsquashfs4-avm-irgendwas aus der Freetz-Toolchain (oder auch aus dem YourFritz-Repo in "bin") erkennt das ja praktisch automatisch und entpackt es problemlos.
 
Mich machen die...
HTML:
<q:Flag>crashreport</q:Flag>
<q:Flag>prov_acs</q:Flag>
<q:Flag>avm_acs</q:Flag>
...stutzig, dass riecht nach: TR-069

Bin mal gespannt, wie es nach dem Entbranden aussieht.
:rolleyes:
 
Mich machen die...
HTML:
<q:Flag>crashreport</q:Flag>
<q:Flag>prov_acs</q:Flag>
<q:Flag>avm_acs</q:Flag>
...stutzig, dass riecht nach: TR-069

Bin mal gespannt, wie es nach dem Entbranden aussieht.
:rolleyes:

Bei mir steht das auch drinne außer der prov_acs flag, und meine box hat avm branding.

Zu der Sache mit den inhouse versionen diese werden bei mir mit public 0 und einer alten gefakten inhouse versionsnummer auch nicht angezeigt bei der 7490.
Bekomme lediglich die labor version auch mit public 0.
 
crashreport - Versand der Protokolle nach einem Crash der Box an AVM beim nächsten Restart (siehe /etc/onlinechanged/irgendwas_mit_crash)

prov_acs - TR-069 zum Provider, m.W. ist nur entscheidend, ob es eingeschaltet ist (bei fehlendem ACS geht es ja trotzdem nicht)

avm_acs - "argo", der neue AVM-Service, der sich alle 3600 Sekunden (was ich schon sportlich finde, wenn man das mal hochrechnet) bei AVM über TR-069 meldet (argo.avm.de:7547 würde ich meinen, muß aber nicht stimmen) und auf Aufforderung das Ergebnis der Ausführung von /bin/suppordata.argo auch noch an AVM sendet - die "/bin/supportdata.argo" verwendet dann wieder "Plugins", die der Maske "/bin/supportdata_argo.*" entsprechen. Davon gibt es bisher vier bei der 7490, vorgesehen sind noch einige mehr in der "/bin/supportdata.argo". Das Ergebnis wird mit "gzip" komprimiert und wohl mit "httpsdl" an AVM gesendet - jedenfalls wird dabei getestet, ob der Server ein von der CA in der "jason_root_ca.pem" unterschriebenes Zertifikat vorweist. Wobei es auch sein könnte, daß der "argo" nur der Upload-Server ist und die regelmäßigen Meldungen an "r2.avm.de" gehen ... da das alles verschlüsselt ist, sieht man ohne MITM (dazu muß man eben die Adressen faken und das "jason_root_ca.pem" austauschen) auch nur den generellen Netzwerkverkehr und keinen kompletten Inhalt. Wobei man den Inhalt des Ergebnisses von "/bin/supportdata.argo" ja auch auf der Seite "AVM-Dienste" selbst einsehen kann, wenn man das kontrollieren will.
 
danke @PeterPawn u. @koyaanisqatsi. Habe zum Testen nun die Config so abgeaendert, dass die HW der 7490 festeingestellt ist, hier bekomme ich dann unter Verwendung einer gueltigen inhouse rev. auch den "ultra-geheimen" Link angezeigt.
Das Ganze funktioniert aber mit der HW fuer die 7580 und ebenfalls gueltiger inhouse rev. nicht, hier wird dann auf die letzte oeffentliche Beta bzw. die Release verlinkt, somit wird fuer mein Verstaendnis noch etwas anderes abgefragt? Den Link fuer die 7490 konnte ich auch nicht umbiegen, um damit an die 7580 Firmware zu kommen, aber irgendwie muss das doch auch gehen, wenn es denn mit Lesen und Recherchieren zu bewerkstelligen sein soll.
 
@mckey:
Für eine 7580 kann ich nichts definitives sagen - solange bei AVM die 7490 das primäre Modell bei neuen Entwicklungen ist, bleibe ich dabei. Es reicht schon die "Verzweigung" zu den DOCSIS-Boxen, da brauche ich nicht noch eine dritte Baustelle.

Solange niemand eine solche Abfrage für eine "Inhouse-Version" mit einer anderen vergleicht (aufgrund eines Paketmitschnitts), wird man da auch nichts machen können.

Da mein eigenes Interesse an der Stelle begrenzt ist, sind es auch meine Anstrengungen.

Stellt mir jemand diese Mitschnitte bereit, sehe ich sie mir an ... wenn nicht, dann eben nicht.

Und mehr gibt es von meiner Seite dazu auch nicht mehr zu sagen ... wenn jemandem die eigene Phantasie fehlt, wie man aus einer URL für die 7490 eine andere für ein anderes Modell machen könnte unter Verwendung von "veröffentlichten Details" (dann hätte man ja zumindest mal "den Einstieg" für die erste Inhouse-Version), dann sollte man ihn oder sie auch nicht mit der Nase darauf stoßen (sonst bricht das (Nasen-)Bein).

Manchmal hilft es ja auch, das Gelesene und Recherchierte kreativ anzuwenden ... sonst ist das alles "totes Wissen".

Ich glaube, ich ziehe um nach Delphi - ich tauge zwar eigentlich nicht als Pythia, aber vielleicht ja als Oberpriester des Apollon.
 
Den Link fuer die 7490 konnte ich auch nicht umbiegen, um damit an die 7580 Firmware zu kommen,

Hmm, ich schon, war überhaupt kein Problem...
(Edit: Dazu waren nur 4 Stellen Positionen in der URL abzuändern welche auch logisch sind)
 
Zuletzt bearbeitet:
@vielen Dank qwertz.asdfgh es ist unglaublich wie man es schafft x-mal ueber den selben so offensichtlichen Zahlendreher zu stolpern, der erste Ansatz mit den richtigen Parametern war nun erfolgreich. Und ich dachte schon so langsam tatsaechlich zu alt fuer den Scheiß zu werden :)
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.