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

eisbaerin · 23 Jan 2018

Mit MacOS kann ich dir nicht helfen, aber ich wollte dir noch eine Rückmeldung wegen des nc (#190) geben:

Seit du nach Zeile 934 folgendes ergänzt hast:

Code:

            while [ -e "$name" ]; do
                name="${name}_$$"
            done

geht es mit beiden nc aus beiden Busyboxen.

PeterPawn · 23 Jan 2018

OK, somit trat das Problem immer dann auf, wenn ein Aufruf von "mktmp" zu schnell hintereinander erfolgt (war fast eine "race condition"), als daß da die Linux-Zeit einen Unterschied zwischen zwei Namen erzeugt und es tatsächlich kein "mktemp" auf dem System gibt - also die Emulation benutzt werden muß.

Durch den zusätzlichen Namen, der für den Input-FIFO bei der Verwendung von "nc" benötigt wird (Zeile 842), nachdem bereits zuvor in Zeile 889 ein Name für die Ausgabedatei generiert wurde, gab es beim zweiten Aufruf eben denselben Namen noch einmal (wenn dazwischen nicht zufällig die Sekunde gewechselt hatte) und diese Datei wurde dann auch einfach wieder gelöscht, wenn sie nicht mehr gebraucht wurde - in der Folge sah es dann eben so aus, als wären gar keine Daten von der Box gelesen worden.

Danke für die Info ...

Ich bin gerade am Überlegen, ob ich nicht auch noch "base64" und "mknod" gegen POSIX-kompatible Lösungen austausche ... "base64" habe ich ja bereits in der Skript-Library in einer POSIX-Version mit "cmp" und "/dev/zero" (was man auch mit einer temporären Datei und der notwendigen Anzahl von binären Nullen ersetzen kann, denn das gehört auch wieder nicht zum POSIX-Standard, im Gegensatz zu "/dev/null", was aber EOF beim Leseversuch liefert) und "mkfifo" wäre wieder POSIX-Standard als Ersatz für "mknod -p", aber fehlt halt auf der FRITZ!Box bei AVM - zumindest in einigen Versionen - und so müßte man beim Fehlen von "mkfifo" wieder auf "mknod" testen und dann auch darauf zurückgreifen.

Wenn die beiden Programme auch noch raus sind, nähert es sich tatsächlich (bis auf "nc", für das es aber keinen Ersatz gibt bzw. geben kann) an "pure POSIX" noch weiter an - wenn die Lösung mit "kill -0" anstelle des Nachsehens im "procfs" im MacOS X hilft (nur dann schafft sie es in die Version im "master"). Wenn ich dann noch "/dev/urandom" rausnehme und irgendwoanders ein paar Bytes Zufall finde, dann wäre das auch kein Thema mehr (das Device gehört auch nicht zum Standard) und AVM interessiert es m.E. ohnehin nicht, was da in "nonce" steht - das dient nur dazu, einen vom Aufrufer vorgegebenen Wert in die Antwort einzubeziehen, damit eine Replay-Attacke nicht möglich ist.

eisbaerin · 23 Jan 2018

PeterPawn schrieb:
(wenn dazwischen nicht zufällig die Sekunde gewechselt hatte)

Das heißt also meine FB arbeitet viel zu schnell

PeterPawn · 23 Jan 2018

Wenn ich es richtig in Erinnerung habe, hatte ich in der Vorgängerversion einfach irgendwo ein "sleep 1" eingebaut, damit es keine doppelten Namen gibt - ist aber auch nur eine Krücke (mache ich aber irgendwo in "modfs" auch so). Irgendwo muß man halt Zufall herbekommen und hier war es dann nicht genug davon. Man könnte natürlich auch irgendwelche festen Namen verwenden - dann klappt's halt mit dem Parallelisieren gar nicht mehr, während man so auch 100 Instanzen gleichzeitig laufen lassen könnte (weil die PID auch einbezogen ist im Namen) ... daher tue ich mich generell etwas schwer damit, irgendwo einen Namen fest zu "verdrahten", selbst wenn es - wie bei "modfs" - vielleicht sogar möglich wäre.

PeterPawn · 24 Jan 2018

Ich habe mal eine geänderte Version eingecheckt, die - bis auf "nc" halt, was nicht im POSIX-Standard ist - nur noch mit POSIX-Programmen und -Optionen arbeitet, wenn keine "bash" vorhanden ist. Die Änderungen für MacOS X sind da auch mit eingeflossen - auch wenn noch Rückmeldungen zum Erfolg oder Mißerfolg fehlen.

Ich habe die Änderungen nur unter Tumbleweed und der W10-bash getestet ... hoffe aber, daß es keine größeren Probleme auf anderen Systemen gibt, wenn jemand "frisch auscheckt".

Den längeren Beitrag zur Beschreibung habe ich hinsichtlich der Voraussetzungen auch noch einmal angepaßt.

Joe_57 · 24 Jan 2018

Hallo Peter,
wird die Versionsnummer deines Scriptes auch angepasst?
Derzeit steht da noch die "version 0.3" drin.

PeterPawn · 24 Jan 2018

Hatte ich eigentlich nicht vor ... aber Du hast recht - ich werde die mal um 0.1 erhöhen. Mußte ohnehin noch eine weitere Korrektur vornehmen, weil auch der "stat -c"-Aufruf unter BSD so nicht funktioniert - war mir auch nicht bewußt, daß "stat" tatsächlich ebenfalls kein POSIX-Utility ist. Nun ist da "wc -c" im Einsatz (das gehört zum POSIX-Standard) und das sollte hier auch funktionieren.

eisbaerin · 24 Jan 2018

PeterPawn schrieb:
ich werde die mal um 0.1 erhöhen

Danke. Bei mir geht es schon von 0.3.0 bis .0.3.7
Ein Datum+Zeit drin, wie bei modfs, wäre auch nicht schlecht.

PeterPawn · 24 Jan 2018

Bei "modfs" habe ich das in erster Linie deshalb eingebaut, weil es da das Archiv von mir auch auf anderen Wegen gibt (eben den Download über yourfritz.de) und damit eine Zuordnung gebraucht wurde, um welchen Stand es sich handelt.

Den gibt es aber bei GitHub praktisch gratis dazu, die Hash-Werte in der Historie einer Datei (hier für juis_check: https://github.com/PeterPawn/YourFritz/commits/master/juis/juis_check - es werden nur die ersten sieben Zeichen des Hashwerts für den Commit als Link angezeigt) sind zwar keine fortlaufenden Nummern, ermöglichen aber ein noch viel genaueres Eingrenzen des verwendeten Standes und den Vergleich von Änderungen.

Für die Verwender der Kommandozeile liefert dann

Code:

vidar:/home/GitHub/YourFritz # git whatchanged juis/juis_check | cat
commit 2531462badc155b297bb1189e78a3380fc099ca5
Author: YourFritz <[email protected]>
Date:   Wed Jan 24 14:35:52 2018 +0100

    circumvent 'dd' usage, create a file containing 32 bytes of NUL with exponential copy

:100755 100755 7dd80f2... 8044663... M  juis/juis_check

commit ebe8054ce71b7a7710381e7682dd9c51526f4ad2
Author: YourFritz <[email protected]>
Date:   Wed Jan 24 14:21:31 2018 +0100

    incremented version number - suggested by @Joe_57 on IPPF

:100755 100755 f2fcaae... 7dd80f2... M  juis/juis_check

commit a5093de2e0d69558eeba74d4390008750fe0e4cf
Author: YourFritz <[email protected]>
Date:   Wed Jan 24 11:45:33 2018 +0100

    replace 'stat' (non-POSIX) with 'wc -c' (POSIX)

:100755 100755 64b7d78... f2fcaae... M  juis/juis_check

commit cc93d06ffe3c77fc613db3261f14e9b8c9edfa33
Author: YourFritz <[email protected]>
Date:   Wed Jan 24 03:22:03 2018 +0100

    claim MacOS X compatibility again

:100755 100755 80be01f... 64b7d78... M  juis/juis_check

commit 06fcb2676d5cf25b9326e75fb50e25c30c473ac8
Author: YourFritz <[email protected]>
Date:   Wed Jan 24 01:56:27 2018 +0100

    even more POSIX compliance

    - 'mkfifo' is part of standards, but it may not be present on a
      FRITZ!Box device with the original BusyBox from AVM and in this
      case 'mknod' will be used as alternative
    - remove some unused sub-functions, imported in the past from framework
    - add command alternatives to prerequisites check

:100755 100755 82ac3a0... 80be01f... M  juis/juis_check

commit eff2ba9bde17389fddb29630b34da70e6eb35783
Author: YourFritz <[email protected]>
Date:   Wed Jan 24 01:36:40 2018 +0100

    replace unused message definitions

:100755 100755 bde3f95... 82ac3a0... M  juis/juis_check

commit 2bf0cecf99fc1af9b218c6ac2b274c770ab09d9d
Author: YourFritz <[email protected]>
Date:   Wed Jan 24 01:08:11 2018 +0100

    various changes to be more POSIX-compliant

    - remove all 'local' statements, it's not in the standards, even if
      nearly each shell supports it
    - convert most sub-functions to sub-shell calls (and change 'return'
      to 'exit') to make variables 'local' again
    - do not use '/dev/urandom' and 'base64' anymore, replaced them with
      'date', 'cmp' and inline Base64 encoding of current time and date
      as nonce - not really unpredictable, but good enough for our needs
    - replace 'procfs'-based search for PIDs with 'kill -0' like in the
      'good old times'
    - try 'realpath' to pretty-print filenames, but do not rely on its
      existence

:100755 100755 a94c3ce... bde3f95... M  juis/juis_check

commit b890667b2d5089ee552a3e6635808a92c8ff014d
Author: YourFritz <[email protected]>
Date:   Tue Jan 23 13:10:06 2018 +0100

    removed the claim to support MacOS X, it lacks procfs support and needs another solution

:100755 100755 a2ae43e... a94c3ce... M  juis/juis_check

commit d95c8f40a48a574de3828537ff25596caf4feece
Author: YourFritz <[email protected]>
Date:   Wed Jan 3 03:53:07 2018 +0100

    handling of 'empty' keyword was a little bit wrong

:100755 100755 2907e05... a2ae43e... M  juis/juis_check

commit 911a06d5674acbff1e3d8722becef8b18582c73f
Author: YourFritz <[email protected]>
Date:   Wed Jan 3 01:21:08 2018 +0100

    unknown option handling added again

:100755 100755 2211461... 2907e05... M  juis/juis_check

commit b17797080d174375e9797fc8d451dbd545526e38
Author: YourFritz <[email protected]>
Date:   Tue Jan 2 11:14:38 2018 +0100

    protect $check against unexpected content, it's only a 2nd line of defense

:100755 100755 1f58780... 2211461... M  juis/juis_check

commit 4dd9d10e3f7ecc2ff6cfab84a062e534e6b2e101
Author: YourFritz <[email protected]>
Date:   Tue Jan 2 10:46:59 2018 +0100

    limit language check to one line, if LC_ALL or LANG contains a new-line character

:100755 100755 ea512b0... 1f58780... M  juis/juis_check

commit d9735d578257ac4964850d53328888b9dd21820c
Author: YourFritz <[email protected]>
Date:   Tue Jan 2 04:01:19 2018 +0100

    correct 'mktemp' emulation, ensure 'HW' is present

:100755 100755 3e3b2c4... ea512b0... M  juis/juis_check

commit 22605b507f0d9b402c5a127821b1e055617ad3ff
Author: YourFritz <[email protected]>
Date:   Mon Jan 1 14:27:50 2018 +0100

    use only a pager, if STDOUT is a terminal

:100755 100755 f38ce98... 3e3b2c4... M  juis/juis_check

commit 81c3a24351c99a680e1586d1ea59ea19940627de
Author: YourFritz <[email protected]>
Date:   Sun Dec 31 22:23:11 2017 +0100

    reformat lines with tabs

:100755 100755 3e3199b... f38ce98... M  juis/juis_check

commit b0ef5049d0b7235417ba48cc7aea2500d098f665
Author: YourFritz <[email protected]>
Date:   Sun Dec 31 21:49:43 2017 +0100

    remove trailing blanks

:100755 100755 50f4c50... 3e3199b... M  juis/juis_check

commit c388cdf378b40c7fef9177edc87ca2aab7bf8d13
Author: YourFritz <[email protected]>
Date:   Sun Dec 31 21:20:15 2017 +0100

    same name like previous versions, default config files not needed anymore

:000000 100755 0000000... 50f4c50... A  juis/juis_check
vidar:/home/GitHub/YourFritz #

die Übersicht der Änderungen.

Das hat auch noch den Vorteil, daß man (konkret ich) sich nicht darum kümmern muß und die "Entscheidung", wann man so einen "timestamp" nun aktualisiert und wann nicht, gar nicht erst getroffen werden muß.

eisbaerin · 24 Jan 2018

Nur, daß die FB kein git kann

PeterPawn · 24 Jan 2018

Aber ihr/e Besitzer/in hat doch sicherlich auch noch einen Browser ... wie gesagt: Ich sehe den Vorteil nicht wirklich - notfalls geht man eben hin und macht einfach vorher ein passendes "wget" für die jeweils aktuellste Version.

Da tut sich zwar gleich das nächste Problem auf, wenn man nur eine originale AVM-Firmware hat (deren "wget" bekanntlich kein HTTPS kann, was man aber mit einer eigenen BusyBox und einem vernünftigen OpenSSL-Programm auch umgehen könnte) - aber dann kriegt man ja ohnehin die Datei nicht auf direktem Weg auf eine FRITZ!Box, denn m.W. gibt es gar keinen HTTP-Download mehr von GitHub.

Also braucht es noch irgendeine zusätzliche Aktion, welche das Skript auf die FRITZ!Box schiebt (oder den eigenen HTTPS-Download direkt auf die Box) und dann kann man das verwendete Kommando auch so gestalten, daß man den Hash-Wert in den Dateinamen oder sogar in eine Kommentarzeile am Beginn der Datei einarbeitet - man braucht ja nur einen Weg, den Hash für den letzten Commit zu ermitteln.

Beim Download liefern diese URLs (im Moment) alles dasselbe Ergebnis:

https://raw.githubusercontent.com/PeterPawn/YourFritz/master/juis/juis_check
https://raw.githubusercontent.com/P...155b297bb1189e78a3380fc099ca5/juis/juis_check
https://raw.githubusercontent.com/PeterPawn/YourFritz/2531462/juis/juis_check

... man muß also nur herausbekommen, wohin "master" zum Zeitpunkt des Downloads gerade zeigt, wenn man den Hash irgendwo "einbauen" will. Das ist aber auch easy, z.B. mit dem folgenden Kommando:

Code:

vidar:/home/GitHub/YourFritz # wget -q -O - https://api.github.com/repos/PeterPawn/YourFritz/commits/master | sed -n -e "/\"sha\"/p" | sed -n -e "1s|.*\"sha\": \"\([^\"]*\)\".*|\1|p"
2531462badc155b297bb1189e78a3380fc099ca5
vidar:/home/GitHub/YourFritz #

- wer die komplette Antwort mal sehen will, läßt einfach die "sed"-Aufrufe in der Pipe weg, die dienen nur dazu, die Ausgabe auf den einzig wissenswerten Teil zurechtzuschneiden.

Aus diesem Wert (wie gesagt, es reichen die ersten sieben Zeichen, dann trägt das nicht so sehr auf bei der Länge eines Dateinamens, könnte man auch gleich noch im "sed" machen lassen) jetzt einen passenden Namen zu erzeugen oder eben die Datei zu laden und dann meinetwegen nach dem SheBang noch eine Kommentarzeile mit dem (kompletten) Hash einzufügen, ist dann nicht mehr so kompliziert.

Aber auf diesem Weg kommt man eben auch an jeden vorhergehenden Stand heran - dieser Hash-Wert (bzw. dessen erste sieben Zeichen) wird also durchaus zur "Versionsnummer" für eine Änderung bzw. einen bestimmten Stand.

KingTutt · 8 Mrz 2018

Kann es sein, dass die aktuelle Version 0.4 des scripts einen Fehler beim Parsen der Version aus einer Config Datei hat? Als ich heute von meiner 6430 Cable die Info-Mail über eine neue FW Version 06.87 bekam, wunderte ich mich, dass auch dem AVM Server noch keine neue Info.txt Datei lag.
Mein altes juis script brachte nichts neues zutage (kein Wunder, es gibt eine neue Version: herzlichen Dank an Peter!)
Aber auch die neue Version wollte mit meiner Konfiguration einfach nicht laufen, auf der Kommandozeile klappte es letztendlich. hier der Output:

Code:

$ ./juis_check -d
debug: Verarbeiten der Konfigurationsdatei '/home/xxxxx/tmp/juis_check.cfg' mit folgendem Inhalt:
debug: -------------------------------------------------------
       Public=1
       Name="FRITZ!Box\ 6430\ Cable"
       HW=231
       Version=159.06.83-44526
       Serial=12
       OEM=avm
       Lang=de
       Annex=Kabel
       Country=049
       Flag=cable_retail
       Box=192.168.xxx.100
debug: -------------------------------------------------------
debug: Ende der Verarbeitung der Konfigurationsdatei
debug: Zusammengesetzte Versionsnummer für die Prüfung: '0.00.00-'
debug: -------------------------------------------------------
debug: Werte der Variablen:
debug: -------------------------------------------------------
debug: Serial="12"
debug: Name="FRITZ!Box\ 6430\ Cable"
debug: HW="231"
debug: OEM="avm"
debug: Lang="de"
debug: Annex="Kabel"
debug: Country="049"
debug: Major=""
debug: Minor=""
debug: Patch=""
debug: Buildnumber=""
debug: Flag="cable_retail"
debug: Public="1"
debug: type="1001"
debug: hostname="231.jws.avm.de"
debug: nonce="MTY6MDQ6NTUwMy8wOC8xOA=="
debug: -------------------------------------------------------

Offensichtlich kann die Variable 'Version' nicht in ihre Einzelteile zerlegt werden, denn schon die "Zusammengesetzte Versionsnummer für die Prüfung" steht auf '0.00.00-'
Mache ich etwas falsch oder ist das ein Bug?

Ein direkter Aufruf mit

Code:

./juis_check -d -i HW=231 Version=159.06.83-44526 Serial=12 Name=6430 OEM=avm Lang=de Annex=Kabel Country=049 Flag=cable_retail

klappt problemlos.

PeterPawn · 8 Mrz 2018

Muß ich mir mal ansehen ... theoretisch sollte die Angabe in der Konfigurationsdatei genau so funktionieren, wie sie bei Dir steht. Nur die Angabe der einzelnen Werte (Major, Minor, usw.) auf der Kommandozeile habe ich wieder rausgeworfen, weil das ansonsten zu unübersichtlich geworden wäre.

Ich schreibe es auf die ToDo-Liste ... sollte ich etwas finden und ändern, werde ich das hier festhalten.

EDIT:
So, ich habe mal etwas eingecheckt, was das Problem beheben sollte ... bisher wurde die Angabe von "Version" weder im Environment noch in der Konfigurationsdatei berücksichtigt, weil im allerersten Anlauf (wo die Konfigurationsdatei gelesen wird) noch kein Zerlegen in die einzelnen Werte (Major, Minor, Patch, Buildnumber) erfolgte.

Wenn dann - wie bei @KingTutt - kein Zugriff auf eine der XML-Dateien der Box mehr erfolgte, wurden diese "Einzelwerte" auch nachträglich nicht mehr gesetzt ... Ergebnis war dann eben das "0.00.00-" als zusammengesetzte Version.

Joe_57 · 23 Mrz 2018

Funktioniert der juis_check von @PeterPawn generell nicht mehr, oder ist da nur in meiner .cfg was nicht mehr gültig?

Code:

Box=fritz.box
Public=0

PeterPawn · 23 Mrz 2018

Code:

vidar:~ # juis_check fb7490 Version=113.06.98-00000 Public=0
~/juis_check: Found newer version: 113.06.98-53124 Inhaus
URL=ftp://[email protected]/<somewhere>/FRITZ.Box_7490.113.06.98-53124.image
DelayDownload=783

Bei mir klappt es - allerdings nur bei Angabe von 113.06.98 als Basis-Version (wobei ich nicht alles jedesmal aufs Neue durchteste und auch meine "Gewohnheiten" bei der Angabe von Parametern habe).

fritzfon9 · 23 Mrz 2018

Ja es klappt mit der o.a. Anfrage.

Joe_57 · 23 Mrz 2018

Danke @PeterPawn, mit dem Version-Paramater funktioniert das Script wieder.
Eigentlich wollte ich genau diesen Parameter weglassen. Früher hatte mir der einfache Wechsel zwischen Public=0/1 gereicht.

PeterPawn · 23 Mrz 2018

Joe_57 schrieb:
Früher hatte mir der einfache Wechsel zwischen Public=0/1 gereicht.

Ich vermute ja immer noch, daß AVM das "pro Firmware" entscheiden kann, welche Voraussetzungen erfüllt sein müssen, damit eine neue Version auf diesem Wege "verkündet" wird und das ist offenbar (so erkläre ich es mir zumindest) bei der 06.98 so eingestellt, daß nur von einer solchen Version beginnend die "inhouse"-Versionen annonciert werden.

Die Benennung "Public" für dieses (vermutliche) Bit in "Buildtype" ist ja auch nur willkürlich von mir gewählt ... das hat bei AVM garantiert einen vollkommen anderen Namen und irgendeine andere Funktion - es ist halt nur der (sichtbare) Unterschied zwischen "Inhouse wird gefunden" und "Inhouse wird unterschlagen" gewesen bei meinen Versuchen, auf denen die erste Version für JUIS basierte.

Die Vorgänger-Variante von AVM kannte m.W. diese "Unterscheidung" noch gar nicht ... es ist ja auch nicht so, daß solche Online-Abfragen generell erst mit JUIS bei AVM Einzug gehalten hätten - da wurde es nur auf "Zusatzgeräte" erweitert, wo früher einfach irgendeine Text-Datei von einer AVM-URL geladen wurde, in der dann die korrekte URL für den Download (z.B. von DECT-Updates) enthalten war. Das war natürlich auch für Dritte recht einfach zu manipulieren, weil man nur "avm.de" entsprechend spoofen mußte.

passuff · 6 Apr 2018

Hallo zusammen. juis check läuft bei mir einwandfrei. Danke dafür!
Leider finde ich über JUIS keine intern für die 6490, sondern lediglich die letzte stable.
Kann mir jemand mit einem Link weiterhelfen?
Gruß

tomsoyer · 7 Apr 2018

Ich würde mich auch über einen weiterhelfenden Link zur 6490 freuen, danke

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

IPPF-Urgestein

IPPF-Urgestein

IPPF-Urgestein

IPPF-Urgestein

IPPF-Urgestein

IPPF-Promi

IPPF-Urgestein

IPPF-Urgestein

IPPF-Urgestein

IPPF-Urgestein

IPPF-Urgestein

Mitglied

IPPF-Urgestein

IPPF-Promi

IPPF-Urgestein

Mitglied

IPPF-Promi

IPPF-Urgestein

Neuer User

Neuer User

Statistik des Forums