juis_check: Leerzeichen im Produktnamen

[fda77]

Ich bekomme diese Sache mit dem Escapen als Aufrufparameter nicht hin! Ich habs auf viel verschieden Wegen ausprobiert. Kannst du mal schauen ob das bei dir noch funktioniert? Vielleicht liegts auch wieder an meinem Fedora.
Was dagegen funktioniert ist alle Werte in eine Datei zu speichern und diese über die Variable vor dem Scriptaufruf zu setzen. Eine Zwischendatei, mktemp, trap etc wollte ich vermeiden und hab damm im Script einfach alle _durch Leerzeichen ersetzt...
Ich finde dass diese eine gute Vereinfachung ist die du aufnehmen könntest

100-juis_check-spaces_for_prod_name.patch.txt und demnächst Freetz-NG/freetz-ng@36b0244

[PeterPawn]

Ich hoffe, daß 1a75024 das Problem umfassender und nachhaltiger löst (da war(en) tatsächlich (ein) Fehler in der (jetzt auch schon wieder alten) Neufassung, wenn die Angabe mit Leerzeichen auf der Kommandozeile erfolgte) - jetzt funktioniert jedenfalls (bei mir zumindest) auch die Angabe von Dateinamen mit Leerzeichen (siehe Commit-Text).

[fda77]

Damit hätte ich nicht gerechnet :) Ich erstell wohl zukünftig besser nur noch Issues die man bei Bedarf in Diskussionen konvertieren kann
Die neue Version funktioniert bei mir nun auch, danke.
Allerdings soll das Script von einem Script oder innerhalb "make" aufgerufen werden, da verschwinden irgendwo die Escapes. Ich glaub ich nutzte statt Unterstrichen einfach ein ZWSP :} Aber ich bin auf jeden fall einen zusätzlichen Patch los.

Mit ist noch aufgefallen, dass Flag='empty' als Parameter zu einem empty im Request führt, und ein Flag=empty genutzt werden muss um wirklich ein leeres Flag zu haben. Solang man es weiss ist es okay

Und scheinbar ist meine Shell nicht zu "juis_check -h" kompatibel:

[PeterPawn]

Allerdings soll das Script von einem Script oder innerhalb "make" aufgerufen werden, da verschwinden irgendwo die Escapes.

Ich weiß zwar gerade nicht, wo man jetzt noch Escapes bräuchte ... aber wenn man ohnehin aus einem anderen Skript aufruft, kann man die Werte ja auch schon vor dem Aufruf setzen. Das Skript löscht ja absichtlich keine älteren Inhalte der entsprechenden Variablen und nutzt die Namen auch 1:1 so (mit ganz wenigen Ausnahmen), wie es in der juis_boxinfo.xml zu finden ist.

Dazu muß man halt vor dem Aufruf die entsprechenden Variablen bereits setzen ... das geht entweder - wenn man die Zuweisungen nur "lokal" für den einen Aufruf machen will - über die Angabe entsprechender KV-Sets VOR dem aufzurufenden Programm oder man exportiert sie gleich richtig in den Zeilen vor dem Aufruf.

Name='FRITZ!Box 7491 (UI)' dash /usr/local/bin/juis_check -d -s "output of request.xml" fb7490

verwendet ebenso das "7491" im Produktnamen, wie die beiden Beispiele aus dem Commit-Text. So zugewiesene Werte werden nur noch auf eine Länge > 0 geprüft und weder aus der Box ausgelesen, noch anschließend erneut zugewiesen. Wenn man das also mit passendem Quoting macht, bleiben auch darin vorhandene IFS-Zeichen ohne Escapes erhalten.

---

Mit ist noch aufgefallen, dass Flag='empty' als Parameter zu einem empty im Request führt, und ein Flag=empty genutzt werden muss um wirklich ein leeres Flag zu haben.

Das kann ich nicht nachvollziehen, egal wie ich es aufrufe - sowohl mit dash (was dann zum Respawn mit bash führt) als auch mit bash direkt:

Name='FRITZ!Box 7491 (UI)' bash /usr/local/bin/juis_check -d fb7490 Flag='empty'
Name='FRITZ!Box 7491 (UI)' bash /usr/local/bin/juis_check -d fb7490 'Flag=empty'
Name='FRITZ!Box 7491 (UI)' bash /usr/local/bin/juis_check -d fb7490 Flag="empty"
Name='FRITZ!Box 7491 (UI)' bash /usr/local/bin/juis_check -d fb7490 "Flag=empty"
Name='FRITZ!Box 7491 (UI)' bash /usr/local/bin/juis_check -d fb7490 Flag=empty
Name='FRITZ!Box 7491 (UI)' dash /usr/local/bin/juis_check -d fb7490 Flag='empty'
Name='FRITZ!Box 7491 (UI)' dash /usr/local/bin/juis_check -d fb7490 'Flag=empty'
Name='FRITZ!Box 7491 (UI)' dash /usr/local/bin/juis_check -d fb7490 Flag="empty"
Name='FRITZ!Box 7491 (UI)' dash /usr/local/bin/juis_check -d fb7490 "Flag=empty"
Name='FRITZ!Box 7491 (UI)' dash /usr/local/bin/juis_check -d fb7490 Flag=empty

... das Ergebnis bleibt immer dasselbe: Als Flag landet im Request eine leere Zeichenkette:

debug: Flag=""
...
               <q:Annex>B</q:Annex>
               <q:Flag></q:Flag>
               <q:UpdateConfig>1</q:UpdateConfig>

obwohl in der FRITZ!Box, aus der der Rest der Werte kommt, etwas anderes steht:

       <q:Flag>prov_acs</q:Flag>
       <q:Flag>medium_lan</q:Flag>
       <q:Flag>mesh_master_no_trusted</q:Flag>

und das beim Aufruf ohne Flag-Vorgabe auch genutzt wird:

               <q:Annex>B</q:Annex>
               <q:Flag>prov_acs</q:Flag><q:Flag>medium_lan</q:Flag><q:Flag>mesh_master_no_trusted</q:Flag>
               <q:UpdateConfig>1</q:UpdateConfig>

Das "Überschreiben" mittels empty funktioniert also bei mir in jeder Form, die mir gerade einfällt und plausibel erscheint.

---

Und scheinbar ist meine Shell nicht zu "juis_check -h" kompatibel:

Da hilft es schon, die Ausgabe mit einer Pipe irgendwohin zu schreiben, wo es sich bei STDOUT (bei -h geht die Ausgabe dorthin) nicht um ein Terminal handelt. Da der Hilfetext mehr als eine Terminal-Seite umfaßt (jedenfalls bei der überwiegenden Zahl der Benutzer), wird er - wenn es sich beim File-Descriptor 1 um ein Terminal handelt - mit dem (oftmals existierenden) Pager less angezeigt, wenn dieser gefunden werden kann. Abhilfe wäre hier z.B. ein Aufruf wie folgt:

juis_check -h | cat

wenn man dem Pager aus dem Weg gehen will.

Und für das Vermeiden der Anzeige der ANSI-Escape-Sequenzen in der oben gezeigten Art und Weise, empfiehlt es sich (für viele andere Programme auch), die Optionen für das less-Kommando (die können über eine Environment-Variable LESS vorbelegt werden) um die Option -R zu ergänzen ... dann sollten Farben, Hervorhebungen (bold) und Unterstreichungen auch wieder korrekt dargestellt werden. Manche Programme/Skripte geben das selbst beim Aufruf von less noch mit an, wenn sie wissen, daß die Daten solche Sequenzen enthalten - ich denke mal darüber nach, das hier (vorsichtshalber) auch so zu machen.

---

Wobei ich generell feststellen muß, daß sich auch meine (POSIX-)Script-Library seit der Überarbeitung von juis_check noch deutlich weiterentwickelt hat und ich hoffe immer noch, daß ich die irgendwann auch mal fertig bekomme in der Form, daß sie für die Veröffentlichung taugt.

Da wäre das Pager-Handling ohnehin bereits drin - daher kann es auch sein, daß ich das einfach lasse und davon ausgehe, daß einige andere Programme/Skripte das auch nicht selbst machen und es dem Benutzer obliegt, für passende Optionen für das Pager-Programm zu sorgen.

Auch wenn ich hier tatsächlich nur tumb auf less abstelle - üblicherweise würde man $PAGER benutzen und davon ausgehen, daß genau dort der Name eines Programms zu finden wäre, das der Benutzer für die seitenweise Anzeige von Text verwenden will.

Es ist also denkbar, daß ich eher in diese Richtung anpasse - wie gesagt, die Optionen für LESS sollte ohnehin jeder in seinem Shell-Profile-Skript so setzen, wie er es braucht und ein -R schadet eigentlich auch nichts, solange das Terminal ANSI-kompatibel ist.

---

Da liegt auch das BuildType-Problem noch ... in der Schublade und zwar seit 2019:

commit ff176f0e7f2c731f9a3832b6a16aaba918e9ddf6 (HEAD -> juis_check, origin/juis_check, github/juis_check)
Author: YourFritz <git@yourfritz.de>
Date:   Wed Mar 13 04:34:21 2019 +0100

    juis_check: add preliminary support for beta versions

Ich habe den Branch mal in dieses Repo gepusht (ff176f0), aber das funktioniert noch nicht so, wie es sollte - so habe ich es zumindest in Erinnerung ... und auch hier will ich erst wieder wirklich ran, wenn ich irgendwann mal Bock hatte, die ScriptLib bis zur Veröffentlichung zu bringen und sie hier dann auch gleich verwendet werden kann.

Problem für mich ist hier auch die Rückwärtskompatibilität zu älteren Versionen von juis_check - das mit dem Public=0 hatte ich damals halt eingeführt, weil mir die ständigen Nachfragen, wie man die Firmware finden könnte, auf den Geist gingen. Dabei habe ich leider nicht beachtet (bzw. es war noch nicht bekannt - zumindest nicht mir), daß AVM da auch noch andere Werte verwenden könnte (für Labor, BETA, PHONE, PLUS) und daß obendrein die Logik mit dem Public noch bei mir negiert ist, weil eine 1 an der Stelle im BuildType eben genau für die "non-public versions" steht (ich unterstelle mal, daß das eine Hexadezimalzahl dort ist, für einen 16- oder 32-Bit-Integerwert ohne Vornullen).

Wenn ich also eine Angabe von BuildType direkt zulasse (das ist ja leicht zu bewerkstelligen, denn die Namen der Variablen sind ja ebenfalls "variabel" ... was ja zur Notwendigkeit dieser häufiger verwendeten eval-Statements führt und zu Problemen mit "normalem Escaping"), dann muß ich aber gleichzeitig die Verwendung von Public verbieten (zumindest in demselben Aufruf), weil sich das widerspricht.

Tatsächlich wären es sogar nur sehr wenige Änderungen, um BuildType auch als Parameter verwenden zu können ... nur würde das dann darauf hinauslaufen, daß entweder immer die Angabe aus der aktuell auf der Box laufenden Firmware verwendet wird (und damit von einer Release-Version aus nichts anderes gefunden wird) oder daß man den passenden und richtigen(!) Wert für BuildType tatsächlich bei JEDEM Aufruf als Parameter angeben müßte.

Das scheitert dann bei vielen anderen Benutzern, die das nicht automatisiert nutzen wollen, schon an der Frage, welchen Wert man denn angeben muß, wenn man eine bestimmte "Firmware-Reihe" sucht. Da ist das Public={0|1} für "Release vs. Inhouse" schon deutlich übersichtlicher, logischer und leichter in der Anwendung - mal abgesehen davon, daß es so dann eben auch in mancher Antwort in irgendwelchen Threads steht.

---

EDIT:
Kurz entschlossen habe ich das mit dem Pager noch geändert: 76747ff

[fda77]

kann man die Werte ja auch schon vor dem Aufruf setzen

Ich hatte bislang nur Variablen-in-einer-Datei und Variablen-als-Parameter gekannt...
Mal schauen ob ich das noch umbaue. Ein env - könnte innerhalb make hilfreich sein, fwmod setzt ja so einiges.
Ich hab das aktuell so definiert:

default "Serial=3431C4%SER% Name=FRITZ!WLAN Repeater DVB-C HW=205 Version=133.07.08-65%REV% Annex=Ohne     Flag=empty        OEM=%OEM% Lang=%LNG% Country=049 Public=0"  if FREETZ_TYPE_FIRMWARE_07_1X_INHAUS && FREETZ_TYPE_1759

Und dies wird alternativ auch durch ein Script ausgelesen. Deshlab ist das mit den Escapes so eine Sache (und ich nutze einfach keine Quotes mehr)

Ich habe den Branch mal in dieses Repo gepusht, aber das funktioniert noch nicht so, wie es sollte - so habe ich es zumindest in Erinnerung

Ja, weil das was du als "beta" bezeichnest eigentlich "plus" Versionen sind.
zB die 7390 bekamm nach EOM/EOS noch einen Securityfix, und das war 1 Jahr so eine "plus". Ansonsten haben nicht viele Geräte eine solche
Unter "beta" hätte ich mehr eine "Labor" verstanden. Buildtype=1 (release) kann man aber auch mit diesem Branch nicht setzen :(

dieser Parameter eignet sich auch nicht für den "Einstieg in eine Labor-Reihe, der muss immer noch über die manuelle Installation" der ersten Labor-Version erfolgen und erst danach kann man dann (vermutlich auf" der Basis von 'Buildnumber') auch weitere Labor-Versionen über die Abfrage bei" AVM finden"

Soweit ich das beobachtet hatte, reicht eine passende FOS Version, zb 07.2>>4<< und eine halbwegs plausible Buildnummer 80000+ oder 84000+. Und halt der richtige Buildtype

juis_check --help
Die Ausgabe ist nun korrekt! Von $PAGER hab ich noch nie was gehört - wie viele andere vermutlich auch.
Man kann wohl PAGER=less und LESS='-R' angeben, dies aber auf jedem Linux das man nutzt wäre schon aufwändig.
Daher lass ich sie wie gehabt weg, bislang waren mir dadurch noch keine Probleme aufgefallen

empty
Ich konnte das nun nicht mehr nachvollziehen. Wahrscheinlch wurde das mit dem Parameterhandling der "Leerzeichen im Produktnamen" mitbehoben

[PeterPawn]

BTW ... mein (ungefragter) Rat an Dich wäre es ohnehin, daß Du weniger Aufwand in die ganzen "Kconfig"-Geschichten in Freetz-NG steckst und mehr davon in Skript-Dateien investierst, die man dann auch anderweitig nutzen kann. Wenn Du das tatsächlich über irgendwelche Freetz-Settings machen willst mit den Parametern für eine automatische Suche von Firmware-Dateien bei AVM, handelst Du Dir nur eine Baustelle ein, die weiterer (intensiver) Pflege bedarf.

Gehst Du hingegen hin und legst für diese Parameter passende Konfigurationsdateien an (z.B. 7590-release oder 7590-inhouse) in einem dedizierten Verzeichnis, reicht es in den "Kconfig"-Files aus, wenn Du da einfach den passenden Namen setzt - der Rest an "Wissen" um die jeweiligen Parameter für die passenden JUIS-Abfragen steht dann wieder gesammelt an einer Stelle und ich habe diese Konfigurationsdateien (zumindest für mein juis_check) ja absichtlich so entworfen, daß es sich um stinknormale Shell-Files handelt (https://github.com/PeterPawn/YourFritz/blob/master/juis/juis_check#L1204) - man kann also auch problemlos nur eine Datei mit den passenden Einstellungen für die 7590-Release haben (weil das der Standard von Public wäre) und in der Datei für die Inhouse-Version nur noch diese 7590-Datei per source (bzw. per "dot command") einfügen und danach die restlichen Variablen noch setzen (hier eben dann ein Public=0).

Gibt man dann noch die Versionsnummer beim Aufruf über Variablen an, ändert sich üblicherweise am Inhalt dieser Dateien auch dann nicht ein einziges Byte, wenn man sie für unterschiedliche Versionen benutzen wollte (und die Versionsnummer hast Du ohnehin schon in den Freetz-Settings).

[PeterPawn]

Von $PAGER hab ich noch nie was gehört - wie viele andere vermutlich auch

Diese Nutzung ist aber (auch schon vor Linux) so weit verbreitet, daß es die PAGER-Variable sogar bis in die POSIX-Spezifikation geschafft hat und dort unter den Variablen aufgeführt wird, deren Namen man besser nicht für eigene Zwecke verwendet:

https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08_01

Jedes "anständige" Linux-System sollte eigentlich von sich aus (sowie less installiert ist) auch die richtigen Werte für alle (interaktiven) Benutzer setzen ... ob da allerdings immer ein -R dabei ist in den Optionen, weiß ich nicht.

Aber das habe ich ja noch mit geändert - ist PAGER am Ende less (oder gar nicht gesetzt, was dann auch zur Annahme von less führt), wird das -R zusätzlich angegeben beim Aufrruf, denn es schadet auch nichts, wenn das zweimal vorhanden sein sollte (es ist auch kein "toggle").

Daß da BuildType auch bei der (bisher unveröffentlichten) Version im Branch nicht direkt angegeben werden kann, war ja klar ... das war mehr ein "Zeigen", was bisher die Marschrichtung war, auch wenn das mittlerweile schon fast zwei Jahre her ist.

Für mich ist halt die Frage, ob ich da (in der jetzigen Form) noch Aufwand für BuildType treiben will oder nicht ... wenn ich das als juis_chk machen würde und damit das doppelte Parameter-Handling (Public vs. BuildType) entfallen lasse, ist mir im Moment am wohlsten.

Aber da denke ich noch ein wenig drauf herum ... ich bin da auch kein großer Freund von Schnellschüssen und bedenke lieber erst einmal die möglichen Konsequenzen in aller Ruhe (meistens jedenfalls - nur wenn klar ist, daß gar keine Seiteneffekte auftreten können, handle ich auch mal unüberlegter).

Bisher funktioniert das jedenfalls auch bei mir einigermaßen klaglos (und bei denjenigen, die modfs verwenden, kommt es auch zum Einsatz, wenn sie das Update bei AVM suchen lassen) und da haue ich mir nur ungerne die Beine weg und überlege erst mal, wo ich das sonst noch im Einsatz habe und welche Konsequenzen eine x-beliebige Änderung dann für diese (abhängigen) Projekte haben könnte.

Für die Suche nach Labor-Versionen reichte bei mir bisher (Ausnahme war die 6490, woraus dann auch die Issue wurde) immer die Angabe der Labor-Reihe und der Build-Nummer 00000 - bei Public=0 erhält man die Inhouse-URL und bei Public=1 die der offiziellen Labor-Version. Für die Release-Version ist es dann halt eine andere Versionsnummer - und da hilft dann auch ein Public=0 nicht unbedingt, weil es dafür i.d.R. keine "Inhouse-Version" gibt. Aber meine Option -c hat mich bisher eigentlich auch nie im Stich gelassen ... selbst von 07.00-12345 aus funktionierte das mit dem Dekrementieren und es wurde/wird mit 06.99-00000 nach der aktuellen Version (bei Retail) gesucht.

Ich wüßte im Moment außer dem einen Fall, aus dem #33 entstand, auch keinen weiteren, wo es mit den Versionsnummern und/oder dem BuildType tatsächlich Probleme gab - insofern sollte die Regel Public=0 für "Inhouse" bzw. Public=1 für offizielle Labor-Versionen (oder Releases, das hängt eben von der Versionsnummer ab) auch in den allermeisten Fällen weiterhin gelten und funktionieren. Das hält natürlich den Druck, da eine Version zu haben, wo der Benutzer BuildType selbst angeben kann (bzw. am Ende sogar muß, wenn er eine andere "Reihe" sucht), in Grenzen - daher kommt auch mein Mangel an Enthusiasmus, das jetzt übers Knie zu brechen.

Was ich aber wohl noch überarbeiten werde, sind die Ausführungen zum "Quoting" in Hilfe-Text - die treffen jetzt ja nicht länger zu seit der Änderung mit dem "zero-width space", denn das überlebt auch eval-Statements ohne Probleme.

[fda77]

Nur dass ich davon noch nie was gehört habe heisst ja nichts. ;-)
Scheinbar funktionier "juis_check -h" auch wenn PAGER=less und LESS='-R'gesetzt sind - das müsste ein doppeltes "-R" ergeben

Ich denke das grundlegene Konzept von juis_check ist das Problem: "Find nicht-release Versionen". Nur wenn man das weiss ergibt "Public=0/1" Sinn. Das war anfangs mein Verständnisproblem mit dem Variablennamen
Public=1 meint nämlich nicht die releases sondern die Labor!

Buildtype=1 brauch ich eigentlich aktuell nur für die Docsis. Seit heut gibts übrigens 6490/6590 Labors

Soweit funktioniert das nun

• https://github.com/Freetz-NG/freetz-ng/blob/master/config/mod/download.in#L865
• https://github.com/Freetz-NG/freetz-ng/blob/master/make/Makefile.image.in#L57
• tools/juis.sh wird nicht in make verwendet

[fda77]

Mit der 6820 v1 + v2 (v3 hat noch keine) kann ich mit juis_check keine release Firmware abrufen:

Erwartete Antwort für 6820v1: 142.07.13 rev73673 {GER} [MESH18 NL3]

Labor

tools/yf/juis/juis_check --debug -i Version=142.07.10-69000 Serial=C80E14000000 Name=FRITZ\!Box 6820 LTE HW=214 OEM=avm Lang=de Annex=Ohne Country=049 Flag=empty Public=1 Nonce=
 Neue Version gefunden: 142.07.19-82252 LabBETA

Inhaus

tools/yf/juis/juis_check --debug -i Version=142.07.10-69000 Serial=C80E14000000 Name=FRITZ\!Box 6820 LTE HW=214 OEM=avm Lang=de Annex=Ohne Country=049 Flag=empty Public=0 Nonce=
 Neue Version gefunden: 142.07.24-84747 Intern

Ich hab dann ff176f0 genommen und darin "1007" durch "1" ersetzt...

tools/yf/juis/juis_check --debug -i Version=142.07.10-69000 Serial=C80E14000000 Name=FRITZ\!Box 6820 LTE HW=214 OEM=avm Lang=de Annex=Ohne Country=049 Flag=empty Public=2 Nonce=
 Neue Version gefunden: 142.07.13

[PeterPawn]

Ich hab das "BuildType"-Problem ja auf dem Schirm, wie Du weißt. Trotzdem ist da (im Moment) von mir keine zeitnahe Änderung zu erwarten - die Reihenfolge, in der ich dabei vorgehen will, hatte ich oben versucht zu skizzieren und selbst dabei ist immer noch die Zeit, die ich generell in Software im FRITZ!Box-Umfeld investieren kann (und will), ein limitierender (und im Moment von mir auch nicht quantifizierbarer) Faktor.

Ich nehme also zur Kenntnis, daß es bei 6820 und Puma6-Boxen ein ähnlich gelagertes Problem gibt (von dem ich ja auch Kenntnis habe, wie Du selbst weißt), aber da das auch zwei Modelle sind, die jetzt nicht in unmäßigen Zahlen bei AVM-Kunden zum Einsatz kommen (zumindest nicht bei denen, die selbst nach neuer Firmware suchen müssen/wollen und das auch noch automatisiert in einer Linux- oder MacOS-Umgebung), hat das einfach keine Priorität für mich.

Wenn davon dann auch die automatische Suche nach aktuellen Versionen in Freetz-NG betroffen ist, tut es mir zwar leid - aber das kann und wird meine eigene Planung nicht entscheidend ändern. Bisher ging es in Freetz-NG ja auch (und zwar für alle Modelle) ohne dieses Feature, nachdem die Liste nicht mehr von boxmatrix.info geladen wurde - da sind diese zwei "Ausreißer" jetzt zwar ärgerlich (und ich habe auch den Vorsatz, das irgendwann in der Zukunft zu korrigieren), aber auch definitiv (zumindest für mich) kein Weltuntergang.

Wie oben schon geschrieben ... es sollte ein Leichtes sein, das Skript um "BuildType" als Parameter zu erweitern (ich habe es immer noch nicht einmal geschafft, die Erklärungen zum Quoting von Leerzeichen zu aktualisieren) und ihm dann einen anderen Namen zu geben.

Wenn man ohnehin die ganzen Parameter immer "alle" und "automatisiert" bereitstellen will, spielen meine Bedenken hinsichtlich Rückwärtskompatibilität und "simple use" ohne exakte Kenntnis des notwendigen "BuildType" für eine spezielle "Firmware-Reihe" von AVM ja auch keine Rolle.

Die angedachte Reihenfolge meiner nächsten Schritte ändert auch mein "Beifall" für den Einbau einer solchen automatischen Suche in Freetz-NG nicht grundlegend, obwohl ich das tatsächlich für einen deutlichen Fortschritt halte, weil es eben auch Tätigkeiten überflüssig macht, die ansonsten bei jedem AVM-Furz, wo erst eine Anpassung des Projekts erforderlich war, ausgeführt werden mußten. Ich sehe das also auf dem richtigen Weg und nehme das 6820-Problem auch als "Meldung" (bzw. ja eigentlich nur als Bestätigung, denn das eigentliche Problem war ja schon vorher benannt) zur Kenntnis - aber auch das ändert meinen Zeitplan jetzt nicht wirklich.

Solange auch bei Freetz-NG weiterhin die Angabe einer speziellen Firmware-Datei als "Modell" möglich ist und somit der Download der passenden Firmware ZUVOR vom Benutzer sichergestellt werden kann, sehe ich auch keine absolute Dringlichkeit - erst recht eben nicht, wenn es um diese "exotischen" Boxen geht (und die 6820 ist da noch weitaus exotischer als Puma6-Boxen von AVM).

[fda77]

Die 6820 ist schon ein Sonderfall, da bei ALLEN anderen die aktuelle Release-Firmware mit Public=1/0 abgerufen werden kann, also auch die Cable!

[fda77]

Ich hab das Script mal auf der Fritzbox ausprobiert, "help" will nicht mehr...

juis_check -h
less: invalid option -- R
BusyBox v1.33.0 (2021-02-05 22:16:33 CET) multi-call binary.

Usage: less [-EFIMmNh~] [FILE]...

View FILE (or stdin) one screenful at a time

        -E      Quit once the end of a file is reached
        -F      Quit if entire file fits on first screen
        -I      Ignore case in all searches
        -M,-m   Display status line with line numbers
                and percentage through the file
        -N      Prefix line number to each line
        -~      Suppress ~s displayed past EOF

[fda77]

"current" funktioniert für Labor nicht, FOS muss für Labor gleich (07.24) bleiben, aber die Revision muss kleiner als die aktuelle sein

OK:
juis_check --local
juis_check: No newer version found, check was made with source version '113.07.24-85840'.

Fail:
juis_check --local --current
juis_check: No newer version found, check was made with source version '113.07.23-00000'.

OK:
juis_check --local Version=113.07.24-85000
juis_check: Found newer version: 113.07.24-85840 Labor

OK:
juis_check --local Version=113.07.24-0
juis_check: Found newer version: 113.07.24-85840 Labor

[PeterPawn]

Da war mir dann wohl entfallen, warum ich (bevor ich das auf $PAGER geändert habe) bisher auf die Angabe von -R beim less verzichtet habe ... denn natürlich ist der Anspruch, daß es auf der Box lauffähig sein soll und das less-Applet kennt dann ja offenbar die Option nicht.

Die Option --current soll auch nur dazu dienen, die aktuelle Release-Version zu finden ... wie sie arbeitet (und arbeiten soll), ist im Hilfetext beschrieben. Dabei wird (absichtlich) die Versionsnummer verringert (und nicht nur die Build-Nummer auf 0 gesetzt, was zusätzlich auch noch passiert), DAMIT (zumindest bisher) keine Labor-Versionen, sondern nur freigegebene Releases gefunden werden.

Das Skript soll(te) letztlich nur im Rahmen von modfs dazu dienen, entweder automatisch das nächste Update für die installierte Firmware zu finden (wenn man update als Parameter beim modfs angibt und den Image-Namen wegläßt oder - wenn kein update als Parameter angegeben wurde - die aktuell installierte (Release-)Firmware aufzutreiben und als Modell zu benutzen, weil bei einer lokal vorhandenen Version (sprich: beim laufenden System, unter dem modfs ausgeführt wird) nicht sichergestellt ist, daß diese nicht bereits modifiziert wurde.

Zwar ist dieser Modus (inkrementelles Ändern) auch explizit vorgesehen gewesen beim modfs (ich hoffe mal, er funktioniert auch heute noch), aber es sollte auch die Option geben, mit einer "sauberen" Firmware vom AVM-Server durchzustarten (so steht's ja dann auch im "Dialog", den modfs in solchen Fällen mit dem Benutzer führt).

Es war für diese automatische Suche mit --current gar nicht vorgesehen, daß da auch Labor-Versionen gefunden werden - zumal man dann eben auch komplett davon abhängig ist, von welcher Version zu welcher da ein "Update-Pfad" von AVM vorgegeben wird. Deshalb gibt es eben (ich hoffe mal, das gilt auch für Freetz-NG noch genauso) in modfs auch die Option, die zu verwendende Firmware-Version explizit anzugeben (in Form einer zuvor geladenen Image-Datei).

Alles andere, was man da noch machen könnte, ist mir deutlich zu viel Aufwand (Labor auf nächste Labor, Labor auf Inhouse, Inhouse zu Release, Inhouse-Update, Release auf erste Labor, etc.) - das ist nicht Aufgabe von modfs, dem Benutzer diese Entscheidungen abzunehmen und es ist auch nicht Aufgabe von juis_check, (selbständig) zwischen den verschiedenen "Firmware-Reihen" (Release, Beta, Plus, Phone, Labor, Inhouse und wer weiß, was es noch alles gibt) zu wechseln.

Für die Fälle, für die es angedacht war, funktioniert es (und auch wenn es irgendwann zum "selbständigen Teilprojekt" wurde, war es am Beginn ja immer als Option für YourFritz bzw. modfs gedacht - vor der Neuimplementierung gab es für modfs sogar noch eine spezielle Version: PeterPawn/modfs@9e2e312) und das Berücksichtigen aller möglichen Kombinationen, von wo nach wo da ein Update erfolgen könnte, bläht das in meinen Augen nur unnötig auf - schon die Public=0-Option war eigentlich nur als "Service" für diejenigen gedacht, die ständig nach der URL der Inhouse-Versionen fragen mußten ... wenn man genau hinsieht, gab es die im "Original" in "modfs" in dieser Form nie und sie hat dort erst mit dem Zusammenlegen der beiden Versionen Einzug gehalten (und ist von modfs aus gar nicht zu beeinflussen).

Da bleibt's bei meiner Einstellung mit dem "KISS" für einzelne Skript-Dateien - die beschränken sich auf das, was sie wirklich können sollen und leisten müssen und alles, was darüber hinausgeht (inkl. des Ermittelns passender Versionsnummern und BuildType-Werte, damit die richtige/gewünschte Version auf dem AVM-Server auch gefunden wird), wäre die Aufgabe für zusätzlichen Skript-Code "außen herum", der dann seinerseits juis_check nur mit den passenden Parametern aufruft (was für BuildType eben noch nicht machbar ist).

Für das Ermitteln der URL der aktuellen Release-Version sollte das mit --current funktionieren (und auch mit --local, wenn es auf der Box läuft) und das reicht an dieser Stelle auch in meinen Augen an "Automatismen". Wer von diesem "Firmware-Pfad" abweichen will, der muß das eben mit zusätzlicher "Handarbeit" einleiten (und beim Update auch weiterführen, wenn er die aktuell installierte Version erneut laden will - will er aktualisieren, funktioniert es ja trotzdem und dann nimmt man auch nicht --current) ... wenn man genau nachdenkt, ist das bei AVM selbst auch nicht anders. Wer auf einer Release-Version ist, muß erst mal von Hand dafür sorgen, daß er auf eine andere Firmware-Schiene kommt - sonst bleibt's bei "no new version found".

Und wie das dann geht, wenn man eben nicht --current verwenden kann oder will, zeigst Du oben ja selbst ... niemand verlangt, daß da --current verwendet wird (das ist nur eine Erleichterung, weil dann eben nicht IMMER die Versionsnummer angegeben werden muß und außerdem ist die Suche nach der aktuellen Version eben auch ein Sonderfall, der bei der AVM-Firmware gar nicht vorkommt, denn die sucht selbst ja auch nur nach Updates), zumal das bei Labor-Versionen ohnehin immer nur so lange funktioniert (mit dem Finden der identischen Version), wie es keine neuere gibt, denn so etwas wie eine "Historie" der Labor-Versionen kriegt man bei AVM auch nicht (zumindest nicht über JUIS-Abfragen bzw. es wäre m.W. noch unbekannt, wie genau das funktioniert, falls es das doch geben sollte).

Das ist dann bei Release-Versionen zwar auch nicht anders (man findet über JUIS keine 07.12 mehr, wenn es für das Modell die 07.20 gibt), aber die Halbwertzeit von Release-Versionen ist deutlich größer.

Kurz zusammengefaßt: Das juis_check SOLL gar nicht jeden denkbaren Einsatzzweck schon mit den "Standardparametern" abdecken können ... genau damit man mit diesem Skript maximal flexibel ist, habe ich diesen ganzen Aufwand mit der "Wahlfreiheit" für die meisten Werte, die bei der JUIS-Abfrage eine Rolle spielen könnten, ja überhaupt nur getrieben. Wenn's nur um die Abfrage geht, ob es eine neuere Firmware für eine vorhandene Box gibt, bräuchte es das alles gar nicht - das stünde bereits alles 1:1 in der juis_boxinfo.xml.

[fda77]

Es ist schon überraschend dass das noch geht, aber Jason & Juis haben wohl die gleiche Datenbasis:

[PeterPawn]

Das ist aber eine Version, die schon über JASON nach Updates suchen konnte, in der gibt es schon eine jason_boxinfo.xml:

vidar:/home/GitHub/YourFritz/toolbox $ inspect_image /home/FritzBox/FB7320/FRITZ.Box_Fon_WLAN_7320-06.34.image
inspect_image, version 0.8

Copyright (C) 2018-2020 P.Hämmerlein (peterpawn@yourfritz.de)

This script is a part of the YourFritz project from https://github.com/PeterPawn/YourFritz.

This program is free software; you can redistribute it and/or modify it under the terms of the GNU
General Public License as published by the Free Software Foundation; either version 2 of the
License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without
even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
General Public License under http://www.gnu.org/licenses/gpl-2.0.html for more details.

--------------------------------------------------------------------------------------------------

Device uses NOR flash to store kernel and filesystem.
Padding extracted kernel from 1434880 bytes to the next 4096 byte boundary.
SquashFS version used: 3
SquashFS compression used: lzma
SquashFS byte order used: big

>>>>> Output of 'extract_version_values' <<<<<
Model="Fritz_Box_7320"
Product="FRITZ!Box Fon WLAN 7320"
Date="13.08.2019 13:24:20"
Version="100.06.34"
Subversion="-38646"
Buildnumber=""
Buildtype=""
Brandings="1und1 avm"
Release="1"
BetaRelease="0"
LaborName=""
DirtyBuild=""
InstallType="mips34_16MB_dect441_2eth_1ab_2usb_host_wlan11n_37273"
KernelVersion="2.6.32.61"
LibraryProject="uClibc"
LibraryVersion="0.9.33.2"
LibraryIdent="uClibc-0.9.33.2"
BootType="rc.S"
PublicKey1="00cb153e49c0f368b5667f5fe87c15a9e554a29af63145965b1e21df60e9b93b1d0e4211a8719befb51d1c61de205cee65bdd33a7067fde2ea398f8e0fcb20edff988e774ebce12489eaa01d98c67d8047dc3770c42e9fc6e137616887c80a62866b435fd42be935dabafb57d61f33434a5ce9c5bc4fa78f0d319b755997c1027b"
PublicKey2="00ea512c8af34840623dc1dac0a1584428e25892c39d866a2622fce000d42259336c82952e61f923e62607e2195212f3d9043a1f496faa8fa94313ad4b76b5721d9213a145838c3a69c54b819c5c80c17740ef514a47ba2c0395537ecce6f53f04877c0b4a94a8abdf2123794b925f3c836b3372812f03184d5ebc2b6347407c33"
PublicKey3="00f2ee9ffd8556211f5644da48a252b107124b330d4c20dcf3b9bac892924cabaa4df4f53e1c62e3f2aa12a23eb1d770df1520a998078738407e6a71b077f73ba976363836b880b0dd88741bc3b83ab061691226e823404b7fc88ed278d8130fe5336eb925c78f2f8ad7cb87d9586286f768ab3236fa8fb51ae7c4bbe1e041d849"
>>>>> ================================== <<<<<

The unpacked filesystem structure may be found at:

/tmp/tmp.bBisyqqybA/13679_inspect_image/fs

Please use another terminal session to inspect or backup data from the location above.

If you've done with it and want to continue, the whole working directory

/tmp/tmp.bBisyqqybA/13679_inspect_image

gets deleted - any possibly open file(s) within, will lead to an orphaned directory, which has to be removed manually.

Do you want to continue/exit? Enter 'x' / 'q' (eXit/Quit): ^Z
[1]+  Stopped                 inspect_image /home/FritzBox/FB7320/FRITZ.Box_Fon_WLAN_7320-06.34.image
vidar:/home/GitHub/YourFritz/toolbox $ find /tmp/tmp.bBisyqqybA/13679_inspect_image/fs -name "*boxinfo*"
/tmp/tmp.bBisyqqybA/13679_inspect_image/fs/usr/www/1und1/jason_boxinfo.xml
/tmp/tmp.bBisyqqybA/13679_inspect_image/fs/usr/www/avm/jason_boxinfo.xml
vidar:/home/GitHub/YourFritz/toolbox $ fg
inspect_image /home/FritzBox/FB7320/FRITZ.Box_Fon_WLAN_7320-06.34.image
q
vidar:/home/GitHub/YourFritz/toolbox $

[fda77]

Na, das hättest du besser vorher gesagt! Aber jetzt ists egal. So funktioniert es auch mit FOS 04

JUIS: Version=75.04.30-5000 Name=FRITZ!Box Fon WLAN 7570 vDSL HW=146 OEM=avme Lang=en Annex=B Country=99 Flag=empty Public=2
JUIS: Version=54.04.30-5000 Name=FRITZ!Box Fon WLAN 7270 v1 HW=122 OEM=avm Lang=de Annex=B Country=049 Flag=empty Public=2
JUIS: Version=29.04.30-5000 Name=FRITZ!Box Fon WLAN 7170 HW=94 OEM=avm Lang=de Annex=B Country=049 Flag=empty Public=2

[PeterPawn]

Ich bin vermutlich auch zu sehr abgelenkt ... aber ich verstehe im Moment nicht mal genau, wo der Zusammenhang zwischen Freetz und der Option --local existieren sollte. Denn die Option ist ja dafür gedacht, daß dabei die juis_boxinfo.xml im lokalen Dateisystem (auf der FRITZ!Box) gelesen wird ... beim Zugriff über das Netzwerk ist die "Fehlerbehandlung", die auf die jason_boxinfo.xml "zurückschaltet", ja bereits vorhanden.

Wer führt denn Freetz auf der Box aus? Oder baust Du gerade die Suche nach der aktuellen Firmware ins Freetz-GUI ein? Der Screenshot sieht danach aus ... aber was unterscheidet diese Suche dann eigentlich von der im AVM-GUI? Du wirst ja vermutlich nicht in der Lage sein, da - auf der Box selbst!!! - auf Knopfdruck ein Update auf die nächste FRITZ!OS-Version zu machen, bei dem auch gleich noch Freetz integriert ist ... zumindest nicht bei den alten Möhren, die gar nicht genug Ressourcen dafür haben.

[fda77]

Hey, hier passt deine Lieblingsredewendung sogar: Du musst zwischen den verschiedenen Falvours von juis_check in freetz unterscheiden!

• Zuerst mal das package-juis_check: mit diesem kommt nur dein Script auf die Box. In source/ ist die .pem schon vorbereitet, falls es eine Unteroption gegen sollte
• Dann das add-juis_check das im webif die Option zum prüfen hinzufügt. Das geht natürlich auch über avm's webif, dort weden aber diverse Daten geleakt wie mesh-Status, Provider, Serial/MAC. Ausserdem weisst du ja dass ich das freetz-webif lieber mag als das lahm von avm. Es hilft auch die URL zum download von Images zu finden die es nciht auf dem FTP gibt, zB Inhaus. Man könnte zb noch eine Combobox dazumachen, um Stable/Labor/Inhaus auszuwählen. Oder einfach freihand die Versions eingeben
• Und noch das make-Juis_check: Damit kann automatisch während make die aktuelle Version ermittelt und genutzt werden. Dann muss nicht ständig eine Labor commited werden. Falls AVM die stabke-URL mal ändern (früher hiessen die internationalen "english") gibt es damit auch keine Probleme beim Download
• tools/juis: Wird eigentlich von make genutzt, hat aber noch die undokumentierten Parameter (f)orce und (m)ulti. Falls du mal zufällig generierte Parameter aller Boxen brauchst