Closed fda77 closed 3 years ago
PeterPawn
commented
3 years ago Hmm ... wo mag das denn bleiben? Mir fällt gerade keine (logische) Erklärung/Möglichkeit ein - muß ich mir erst mal anschauen. Aber nicht sofort - es war gerade Kickoff beim Super Bowl LV.
fda77
commented
3 years ago Bei andere wie zb 7490 oder 7590 gabs das Problem nicht. Evtl wegen der doppel-0 PS: Warum gibts das nicht mit deutschem Kommentar?
PeterPawn
commented
3 years ago PS: Warum gibts das nicht mit deutschem Kommentar?
Was genau meinst Du? Das Skript kann auch Deutsch, aber nur dann, wenn das POSIX-konform eingestellt ist: https://github.com/PeterPawn/YourFritz/blob/master/juis/juis_check#L471
Auf der Box könnte man zwar auch das language=... von AVM auswerten, aber da es ja nun auch noch jede Menge anderer Software gibt, die auf passende Spracheinstellungen Wert legt, sollte man auch unter Freetz lieber die passenden Settings im Environment verwenden und weniger Wert auf die "Sonderlocke" von AVM legen.
Beim modfs ist das wieder etwas anderes, denn das SOLL ja explizit auf der Box laufen (https://github.com/PeterPawn/modfs/blob/master/modfs#L2849) ... wenn man das auf juis_check übertragen wollte, müßte man zuerst mal sicherstellen (also genau prüfen), daß man auch auf einer FRITZ!Box ist - ein bisher für mich überflüssiges Ansinnen, weil ich auch da, wo juis_check intern verwendet wird, gar keinen Wert auf dessen Ausgabe lege und nur die Werte von STDOUT hole, die ich dann selbst auswerte.
Außerdem ist das Skript an sich (ohne Debug-Option) jetzt gar nicht so gesprächig (ich hoffe immer noch, daß ich die Frage richtig verstanden habe) und wer am Ende deutsche Texte in den Debug-Meldungen will, der braucht auch nur ein einfaches LC_ALL=de (das wäre sogar noch falsche Syntax und sollte für andere Software schon richtig gesetzt werden - z.B. auf de_DE.UTF-8) vor den Aufruf setzen (oder es sonst irgendwie ins Environment beim Aufruf befördern).
Das mit der 100 schaue ich mir noch an ... Shell-Arithmetik ist tatsächlich ein Kunststück für sich (weil sie intern eben mit Oktalzahlen arbeitet und Zeichenketten oktal interpretiert werden) und da treffe ich schon Vorkehrungen, um mit AVM-Versionsnummern mit Ziffern jenseits von 0 bis 7 richtig umzugehen: https://github.com/PeterPawn/YourFritz/blob/master/juis/juis_check#L1125
Das Problem wird wohl irgendwo im Code zum Zerlegen der Versionsnummer in ihre Bestandteile liegen: https://github.com/PeterPawn/YourFritz/blob/master/juis/juis_check#L1134 - ich habe es mir noch nicht genau angesehen ... und ja, das MUSS so kompliziert gemacht werden (bevor Du Dich das fragst und das optimieren möchtest), weil sonst wieder irgendein Fall nicht berücksichtigt wird und dann nicht klappt - das mit Deiner 100 dürfte ein weiterer dieser Fälle sein.
PeterPawn
commented
3 years ago Ich habe mal etwas geändert ... die zweite Änderung (jason_boxinfo.xml auch bei --local) ist aber ungetestet, weil ich keine passende Box griffbereit habe.
Das Problem mit der 100 sollte "weg" sein und die dritte Änderung soll dem Aufrufer helfen, wenn er lieber alle Parameter beim Aufruf festlegen will (also ohne Box und ohne Konfigurationsdatei arbeiten möchte) und am Ende doch noch eine Angabe fehlt.
Das sind alles Fehlerkorrekturen bzw. kleinere Änderungen, die das normale Verhalten nicht entscheidend abändern - es sollte also bei den Verwendern (inkl. Freetz/Freetz-NG) nicht zu zusätzlichen Problemen/Änderungen führen (müssen).
Wenn's bei Dir funktioniert, würde ich hier zumachen wollen.
fda77
commented
3 years ago Die Sprache war auf den Superbowl bezogen. Ich muss sagen dass ich nicht nachgesehen hab wie die "0" abbleibt. Du nutzt immer viele Dinge die ich nicht kenne, und dann ist es sehr mühsam so einen Fehler zu finden :)
Dieses komisch Handling von Zahlen kenn ich aber auch, zb kann $(( )) nicht mit Zahlen rechnen die mit "0" beginnen...
fda77
commented
3 years ago Ich hab die aktuelle Datei von https://raw.githubusercontent.com/PeterPawn/YourFritz/master/juis/juis_check direk auf eine 7320 geladen
./juis_check --debug -l
debug: Respawning script with Bash as shell, calling: command bash ./juis_check --debug --local --no-respawn
debug: Reading values from local file '/var/jason_boxinfo.xml'.
debug: Splitting compound version number '100.06.55-38630' to:
debug: Major=100
debug: Minor=06
debug: Patch=55
debug: Buildnumber=38630
expr: warning: '^0*\([1-9]*[0-9]*\)': using '^' as the first character
of a basic regular expression is not portable; it is ignored
expr: warning: '^0*\([1-9]*[0-9]*\)': using '^' as the first character
of a basic regular expression is not portable; it is ignored
expr: warning: '^0*\([1-9]*[0-9]*\)': using '^' as the first character
of a basic regular expression is not portable; it is ignored
debug: Compound version number used for request: '100.06.55-38630'
...
debug: Major="100"
...
<q:Major>100</q:Major>
...
juis_check: No newer version found, check was made with source version '100.06.55-38630'.$ bash --help
BusyBox v1.27.2 multi-call binary.
...EDIT -local kann wohl 06.00 nicht verkleinern Ein "bash: 0: unknown operand" wenn FOS mit 00 endet:
./juis_check --debug -l -c Version=100.06.00
debug: Respawning script with Bash as shell, calling: command bash ./juis_check --debug --local --current --no-respawn Version=100.06.00
debug: Setting 'Version' to '100.06.00' from command line parameter
debug: Reading values from local file '/var/jason_boxinfo.xml'.
debug: Splitting compound version number '100.06.00' to:
debug: Major=100
debug: Minor=06
debug: Patch=00
expr: warning: '^0*\([1-9]*[0-9]*\)': using '^' as the first character
of a basic regular expression is not portable; it is ignored
expr: warning: '^0*\([1-9]*[0-9]*\)': using '^' as the first character
of a basic regular expression is not portable; it is ignored
expr: warning: '^0*\([1-9]*[0-9]*\)': using '^' as the first character
of a basic regular expression is not portable; it is ignored
bash: 0: unknown operand
debug: Just decremented the version number to get an answer with URL for current version.
debug: Compound version number used for request: '100.06.-1-00000'
...
debug: Major="100"
debug: Minor="6"
debug: Patch="-1"
debug: Buildnumber="00000"Mist ... das mit der Warnung kriege ich weg (dann eben die regex ohne anchor), aber das mit dem Dekrementieren von 07.00 auf 06.99 hat mit der ed2c01cb81695dd55b7525ca74d365633f622e11 noch funktioniert. Dieser Sche*** mit der Shell-Arithmetik kann einen aber auch zur Weißglut treiben ... nun siehst Du aber wieder einmal, warum ich mir in der Regel doch lieber Zeit lasse mit den "regression tests". Hier wollte ich mal wieder "auf die Schnelle" ändern und prompt funktionieren dann andere Dinge, die davor kein Problem waren, nicht mehr.
Ich schaue es mir noch einmal an ... ob ich aber die notwendige Zeit für eigene ausführlichere Tests finde, kann ich nicht sagen. Ich mache also (für Dich zum Testen) einen Branch auf mit den Änderungen ab a8442d5148291c130a7ee0546bbb4f1fdade7c9d (auch wenn Teile davon wohl schon funktionieren) und erst wenn das alles wieder sauber läuft, mische ich den mit main (bzw. master) - Du kannst ja durch Angabe des Hashes auch den Branch auschecken in Deiner Testinstallation von Freetz-NG.
PeterPawn
commented
3 years ago So, die Version im Branch https://github.com/PeterPawn/YourFritz/commits/juis sollte die beiden Fehler beseitigen ... es hing beides an der Regex und die habe ich jetzt noch einmal genau getestet (siehe Commit-Text), daß sie für alles von [000]0 bis 0999 auch die richtigen (dezimalen) Werte zurück gibt - egal ob und wieviele Vornullen es gibt und auch für die einfache 0.
fda77
commented
3 years ago Ich hab das mir dem verkleinern von .00 so gemacht: https://github.com/Freetz-NG/freetz-ng/blob/master/make/mod/files/root/usr/mww/cgi-bin/exec.d/juis_check.sh#L24
VER="$(echo ${VER} | sed 's/\.//;s/^0*//')"
VER="$(echo 0$(( $VER - 1 )) | sed -r 's/.*(..)(..)$/\1.\2/')"Kannst du nicht gleich noch deinen "Public=2" commit mit aufnehmen - und auf "Buildtype=1" ändern? Ich benutze aktuell diese 2 Patches, weshalb der direkte Download vorhin keine "release" fand: https://github.com/Freetz-NG/freetz-ng/tree/master/tools/make/yourfritz-host/patches
Wenn ich noch was spezielles Testen soll sag bescheid. Das "-current nutze ich in Freetz aktuell nicht (Labor braucht gleiche Version, Release kleinere).
Also ich hab https://raw.githubusercontent.com/PeterPawn/YourFritz/juis/juis/juis_check auf der Box heruntergeladen. Mir sind jetzt keine Fehler aufgefallen.
Wo wir schon bei der Länge von Zaheln sind: Soll Minor nur noch 1 Stelle haben? Das war vorher auch schon so, ich weiss nicht wie AVM es macht
./juis_check --debug -l
debug: Splitting compound version number '100.06.55-38630' to:
debug: Major=100
debug: Minor=06
debug: Patch=55
debug: Buildnumber=38630
debug: Compound version number used for request: '100.06.55-38630'
...
debug: Variables set:
debug: Major="100"
debug: Minor="6"
debug: Patch="55"
...
<q:Minor>6</q:Minor>ich weiss nicht wie AVM es macht
Schau mal in die juis_boxinfo.xml bei AVM (wget -q -O - http://<ip>/juis_boxinfo.xml).
Ich überlege mir für den "BuildType" irgendetwas ... mein Problem ist eher, daß Du die (eigentlich nur zum Zeigen gedachte) Version in dem (alten) Branch juis_check so übernommen hast, daß Du da Public mit weiterem Wertebereich erwartest.
Ich hatte das damals eigentlich aufgegeben, weil mir das dann eher unhandlich erschien und ich eher eine Reihe von - einander ausschließenden - Variablen (Release, Labor, Beta, Inhouse, Plus, Phone) für die Geschmacksrichtung der Firmware verwenden wollte bzw. auch die direkte Angabe von BuildType (aber eben auch nur als Alternative zu den anderen "vordefinierten" Werten) zulassen wollte für die Kombinationen, die noch nicht bekannt sind.
Jetzt, wo Du das alles schon auf Public=2 getrimmt hast, ist das natürlich blöd zu entwirren - wenn ich das tatsächlich umsetzen sollte, würde ich das schon auch gerne so machen, daß alle etwas davon haben (und es für die anderen Benutzer auch einfach UND logisch bleibt).
Dabei würde ich die jeweiligen Namen der "Pseudo-Variablen" (s.o.) einem Build-Type zuordnen und aus Public=0 (als weiterer alternative Angabe) dann 1000 machen, während Public=1 als explizite Angabe weiterhin 1001 sein würde - aber nicht länger der Standardwert, wenn er gar nicht angegeben wurde. Da würde ich dann die 1 für Release=1 nehmen und das auch zum Standardwert erheben ... zumal 1001 und 1 bis auf die ganz wenigen Ausnahmen auch dasselbe Ergebnis liefern sollten.
Nur hieße das am Ende für Dich trotzdem, daß Du die ganzen Stellen bei Dir, wo Du den von mir verworfenen Ansatz mit Public=n verwendest, noch einmal ändern müßtest - wenn Du das in Kauf nehmen möchtest, schaue ich mal, daß ich die Änderungen doch noch "außer der Reihe" umsetze.
Ich halte jedenfalls im Moment diese Idee mit der Definition weiterer Variablen für die Ausrichtung der Firmware, die jeweils einem der (bisher bekannten) BuildType-Werte zugeordnet sind, für die sauberste Lösung, weil dabei sowohl die Rückwärtskompatibilität gewahrt wird (und der "Wertebereich" für Public bei 0 oder 1 bleibt) und andererseits mit dem "freien" BuildType als Alternative (aber eben nicht als "Pflicht") auch die notwendige Flexibilität einziehen würde, um auch bisher unbekannte Werte (ohne sofortige Änderung des Skripts) verwenden zu können.
Aber ich nehme hier auch alternative Ideen gerne zur Kenntnis - wenn es irgendeine schlüssige Begründung gibt, warum man etwas besser so als anders machen sollte. Bisher bin ich jedenfalls (ich habe ja seit ein paar Tagen da auch ab und an mal darauf herumgedacht) irgendwie in diesen Ansatz "verliebt" ... er bietet für alles, was ich dabei berücksichtigen wollte, eine Lösung, mit der ich dann leben könnte.
PeterPawn
commented
3 years ago Und noch einmal "anders" ... ich denke mal, ich habe mich jetzt entschieden.
Es wird eine neue Variable BuildType geben, die mit Public (egal welcher Wert da angegeben wurde, wobei nur 0 oder 1 - wie bisher - gültig sind) "mutually exclusive" ist und die als Wertzuweisung entweder einen der im vorherigen Kommentar angeführten (Text-)Werte haben kann (wobei die Namen noch nicht 100% fix sind) oder - wenn es keiner der vordefinierten Werte ist, aber nur aus Hexadezimalziffern besteht - direkt in den JUIS-Request übernommen wird.
Das reduziert das auf einen einzelnen zusätzlichen Parameter (bzw. eine weitere Variable) und es ermöglicht mit den vordefinierten Werten einerseits eine einfache Auswahl der passenden Firmware-Reihe (ohne daß man die dahinterstehenden Werte kennen muß) und andererseits gleichzeitig die Flexibilität für die bisher nicht bekannten Werte.
Der Standard wäre dann BuildType=Release und das Verhalten für die (früheren) Public-Werte mit 1000 bzw. 1001 bliebe (wenn das angegeben wird) auch beim alten.
fda77
commented
3 years ago Genau der Patch aus mit dem "alten" Branch wird früher oder später nicht mehr passen. Ich hatte diesen genommen, damit ich so gute wie nichts (nur die 1007) ändern musste.. kurz mal mutually exclusive googel .. okay, find ich gut :) Wie du das genau machst ist mir egal. Auf das genutzte "Public=2" brauchst du keien Rücksicht zu nehmen, das wird nur intern verwendet und ist leicht zu ändern. Falls man AVM's Buildtype angeben kann, hab ich das schon vorbereitet: https://github.com/Freetz-NG/freetz-ng/blob/master/config/mod/juis.in#L3
PeterPawn
commented
3 years ago Die Version im juis-Branch sollte jetzt die Option Buildtype kennen und diese "vorbelegten" Namen: https://github.com/PeterPawn/YourFritz/blob/1e8a8c28fbef9443e0bea9188095ea1f2e87885f/juis/juis_check#L680
Das kannst Du zwar gerne testen (ich habe es nur mit den gerade erreichbaren Boxen - einer 6490 und einer 7490 - gemacht), aber es ist noch nicht fertig, weil ich die Hilfe-Bildschirme noch anpassen muß ... aber jetzt ist erst mal Schicht im Schacht für heute (bzw. eher für gestern).
fda77
commented
3 years ago Cool, danke! Teste ich gleich mal. Auf den ersten Blick würde ich sagen INTERN:1000 und TEST:1006 könnte man noch dazumachen, die Schreibweise INHOUSE ist mir bislang nicht untergekommen
PeterPawn
commented
3 years ago die Schreibweise INHOUSE ist mir bislang nicht untergekommen
So nenne ich diese Versionen schon seit der ersten Vorstellung eigener Abfragen des JUIS im IPPF (https://www.ip-phone-forum.de/threads/update-check-%C3%BCber-den-neuen-avm-service.287657/post-2181096 - dritter Absatz von unten) - da kam selbst die von AVM inzwischen genutzte Benennung INHAUS erst danach "ans Licht der Öffentlichkeit". Ein CONFIG_LABORNAME gab es auch erst danach (iirc) und Download-URLs, in denen das ein Bestandteil des Pfades ist, ebenso.
Außerdem gibt es im Deutschen eigentlich gar kein INHAUS (das ist eher eine Eigenschöpfung irgendwelcher Mitarbeiter bei AVM) - ein INHOUSE steht hingegen sogar (mit Erklärung, die auch noch zur hier gewünschten Aussage paßt) in dieser Schreibweise im Duden.
Mit INTERN kann ich auch nichts anfangen (bzw. das benutzt keiner beim Charakterisieren der Firmware-Stränge) und TEST ist ja nun absolut nichtssagend - und meines Wissens bei AVM auch in freier Wildbahn noch nicht wirklich gesichtet (nur in irgendwelchen komischen Vorabversionen für neue Modelle). Was soll das also genau sein? Ist eine Labor-Version für die Öffentlichkeit kein "Test" mehr? Man muß auch nicht jeden intern bei AVM verwendeten Kram in die Öffentlichkeit tragen.
Die beiden zusätzlichen Werte INTERN und TEST habe ich also absichtlich weggelassen (denn ich kenne die natürlich auch - ich lese ja auch ab und an auf anderen Sites) - die braucht es meines Erachtens schlicht nicht bzw. sie bringen keinen zusätzlichen Nutzen.
Schon beim INHAUS hatte ich (aus den o.g. Gründen) meine Bauchschmerzen, aber AVM hat ja schon so manche "Neuheit" erfunden - bis hin zur "Push-Service-Mail", die bei anderen eben einfach nur "Mail" heißt oder auch "Benachrichtigung". Da es sich aber nun auch im IPPF (und bei anderen Benutzern) durch die AVM-Bezeichnung an dieser Stelle so "eingebürgert" hat, kann ich das gerade noch (vor mir selbst) rechtfertigen.
fda77
commented
3 years ago Soll das das nun so sein?
yf/juis/juis_check: Der Parameter 'Nonce' ist unbekannt.Die "intern" sind aktuell mit *key4 signiert und haben telnetd, "inhaus" beides nicht mehr: https://github.com/Freetz-NG/freetz-ng/commit/272366fb377924bb33617fa8f950016023c774c6
PeterPawn
commented
3 years ago OK, Korrektur: Die Variable in der rc.conf heißt tatsächlich CONFIG_LABOR_ID_NAME - und die gibt's wohl doch schon länger, aber nur in ausgewählten Versionen und was da bei AVM früher drin stand, weiß ich nicht. In der ersten geleakten "Inhouse-Version" FRITZ.Box_7490_BETA.113.06.35-30999_bkb.image (für mich der "Urvater" der Inhouse-Versionen, selbst wenn's die bei AVM schon früher gab, weil sich davon letztlich die ganzen Suchen und Anfragen nach diesen "geheimen" Versionen im IPPF ableiteten) ist es jedenfalls auch nicht gesetzt.
fda77
commented
3 years ago PeterPawn
commented
3 years ago Soll das das nun so sein?
Eigentlich nicht ... kriege ich mal den kompletten Aufruf?
fda77
commented
3 years ago Ist jetzt nichts besonderes...
tools/yf/juis/juis_check --debug Version=154.07.24-84000 Serial=3CA62F000000 Name=FRITZ!Box 7590 HW=226 OEM=avm Lang=de Annex=B Country=049 Flag=empty Buildtype=1001 Nonce=ha6R7MeMNkoWK1LqLb4EUQ==
debug: Setzen des Parameters 'Serial' auf '3CA62F000000' entsprechend der Angabe auf der Kommandozeile
debug: Setzen des Parameters 'Name' auf 'FRITZ!Box 7590' entsprechend der Angabe auf der Kommandozeile
debug: Setzen des Parameters 'HW' auf '226' entsprechend der Angabe auf der Kommandozeile
debug: Setzen des Parameters 'OEM' auf 'avm' entsprechend der Angabe auf der Kommandozeile
debug: Setzen des Parameters 'Lang' auf 'de' entsprechend der Angabe auf der Kommandozeile
debug: Setzen des Parameters 'Annex' auf 'B' entsprechend der Angabe auf der Kommandozeile
debug: Setzen des Parameters 'Country' auf '049' entsprechend der Angabe auf der Kommandozeile
debug: Setzen des Parameters 'Flag' auf 'empty' entsprechend der Angabe auf der Kommandozeile
debug: Setzen des Parameters 'Buildtype' auf '1001' entsprechend der Angabe auf der Kommandozeile
yf/juis/juis_check: Der Parameter 'Nonce' ist unbekannt.
Hier schauen
Schön ... und nun? Ist doch praktisch alles abgedeckt, außer die ganzen "Phantasie-Namen", die nur bei den 7270-Modellen aufgetaucht sind und den TEST-Versionen, die ja (ich hatte es nicht für alle auf dem Schirm) offensichtlich genau für die bisher nicht erhältlichen oder "ganz frischen" Boxen mal gesichtet wurden. Warum sollte ich jetzt die Benutzer von juis_check mit diesem "unnützen Wissen" belasten?
Ich will ja noch die Hilfe-Texte ändern und da kommt dann bei der Beschreibung von Buildtype auch noch eine (aus der Variablen im Skript generierte) Liste der möglichen Werte dazu - da habe ich schon gezögert, ob wirklich BETA und LABBETA parallel notwendig sind (ich führe ja auch aus gutem Grund eine Umwandlung in die Großschreibweise durch, damit das nicht daran auch noch scheitern kann) und ich sehe den Sinn in den anderen Werten nicht bzw. bin sogar der Ansicht, daß INTERN dann auch auf den User-Boxen nichts zu suchen hat.
Und wer tatsächlich danach suchen wollte (ich wüßte nicht mal, daß das beim Buildtype einen Unterschied macht - es ist ja immer "Schicksal", was da bei der Abfrage des JUIS zurückkommt), der muß dann halt die 1000 von Hand angeben, wenn ihm INHOUSE (mit dem identischen Wert) nicht paßt.
Außerdem soll das Skript ja zum Abfragen des JUIS dienen und nicht als "Erklärung" oder "Auflistung", was bei AVM da für Namen in CONFIG_LABOR_ID_NAME möglich wären - das ist einfach nicht seine Aufgabe und solange das am Ende auf dieselben Werte wie bei einem anderen Namen hinausläuft, juckt mich das kein bißchen, wenn AVM da noch weitere Namen für dieselben Werte "erfindet".
Das mit Nonce muß ich noch einmal prüfen - ich weiß aber gerade nicht, wo ich den aus der Liste der Variablen-Namen gelöscht hätte in irgendeiner Zeile. Also liegt es wohl daran, daß ich die Fehlerauswertungen weiter nach vorne gezogen habe, damit bei falschem Aufruf (u.a. bei Public und Buildtype gleichzeitig) nicht erst noch eine Datei von der Box gelesen werden soll, bevor der Fehler (in den Parametern) berichtet wird.
fda77
commented
3 years ago War nur ein Vorschlag was ich noch dazu gemacht hätte, ich benutze eh die Nummern direkt. OT: Das wären doch tolle Themen zu denen du was schreiben könntest: https://github.com/Freetz-NG/freetz-ng/discussions/189 und https://github.com/Freetz-NG/freetz-ng/discussions/191
PeterPawn
commented
3 years ago OT: Das wären doch tolle Themen zu denen du was schreiben könntest
Wenn Du mit "schreiben" Software meinst, eher nicht ... es ist nicht so, daß ich vor lauter Langeweile im Lockdown gar nicht wüßte, was ich mit meiner Zeit anfangen sollte. Ansonsten habe ich zu der einen Frage meinen Senf dazu gegeben - bei der 6660 gibt es nichts weiter zu sagen.
Ich bin ja immer noch überrascht, daß es bisher noch niemand in Angriff genommen hat (oder das zumindest nicht bekanntgegeben hat oder gar zum Ende brauchte), bei den GRX-Boxen auch einen vernünftigen Packer für das von EVA erwartete Format zu schreiben - das geht alles rein mit Shell-Code, dazu braucht es kein C oder anderes. Solange da der "Leidensdruck" offenbar nicht existiert, sollte es bei den Puma7-Boxen noch weniger "dringend" sein.
Ich habe da auch keinen echten Bedarf - wenn ich wirklich mal einen Kernel für eine GRX-Box erzeugen will, dann kann ich den auch mit dem Bootcore-Kernel von AVM zusammenpfriemeln und den zusätzlichen Header vor den beiden Kernel-Payloads von Hand erstellen.
War nur ein Vorschlag
No offense ... ich denke nur, wir zäumen das Pferd von verschiedenen Seiten auf und bei allem, was juis_check durch die letzten Änderungen dazugelernt haben mag, hat es immer noch eine dedizierte Bestimmung - und es soll für den potentielle Benutzer überschaubar bleiben. Das wird zwar sicherlich kein Windows-Programm werden, wie einige es offenbar brauch(t)en, aber außerhalb eines MS-Systems ist es immer noch die einzige (mir bekannte) Option zur Abfrage des JUIS.
Und wenn man da ohnehin noch weiteren Code herumbasteln muß/will, um das automatisch zu verwenden, dann kann man darin auch all die "Sonderwünsche" realisieren, die das eigene Projekt bzw. der eigene Anwendungsfall für das Skript noch so mit sich bringen mögen. Aber das gehört dann nicht in den Teil, der als "kleinster gemeinsamer Nenner" (oder mit sinnvollen Ergänzungen für eine bessere "Benutzererfahrung" - oder auch "better UX") auf möglichst vielen Plattformen gleichzeitig funktionieren soll (und das für MacOS gangbar zu machen, war echt nervig) und von möglichst vielen (auch nicht so sehr fitten) Benutzern ohne größere Probleme verwendet werden kann.
Ohne dieses Ziel vor Augen, würde ich mir auch den ganzen Aufwand mit den Hilfe-Bildschirmen/-Texten - und das noch in zwei Sprachen - gar nicht antun ... aber irgendwo muß man dann wieder Grenzen ziehen.
PeterPawn
commented
3 years ago 'Nonce' sollte auch wieder funktionieren - die Hilfetexte mache ich vielleicht auch nicht mehr heute, so daß es dann auch noch kein "merge" geben wird.
Wenn Du keine Fehler mehr beim Aufruf findest (vieles habe ich ja heute/gestern nacht selbst schon getestet), nehme ich das als Zeichen/Anlaß, die Texte auch noch zu ändern und dann den Branch zu mergen,
Nonce verwendet eigentlich niemand wirklich, das war ja nur, falls jemand tatsächlich die Signatur selbst prüfen will, denn dann braucht er das ja für die Prüfung, daß der Server nicht einfach einen anderen Nonce-Wert nimmt oder am Ende gar immer denselben, was dann auf eine "Replay-Attacke" hinauslaufen würde/könnte.
PeterPawn
commented
3 years ago Sag mal ... kann das sein, daß Du gar nicht mit einer bash als Shell arbeitest (generell nicht)? Denn normalerweise würde diese Dir (bei aktivierter History) das Ausrufungszeichen ohne Escape sehr übel nehmen (das hat eine spezielle Bedeutung bei Benutzung der Command-History).
Daher würde ich Dir (wenn Du diesen Aufruf irgendwo einem Freetz-Benutzer anzeigen solltest und sei es nur bei entsprechender "Geschwätzigkeit", die der wünscht) eigentlich empfehlen, das Name auch dann in einfache Hochkommata einzuschließen, wenn Du da ZWSP drin hast und damit die IFS-Zerlegung dort nicht zuschlägt.
Ich weiß nicht, wie aufwändig diese Änderungen wären - andererseits kenne ich tatsächlich auch noch keinen Bericht, daß AVM sich bei einer JUIS-Antwort irgendwie darum geschert hätte, was in Name am Ende tatsächlich stand. Auch ein 7491 (irgendwo hatte ich das mal als Test) interessiert nicht die Bohne - vielleicht solltest Du das dann (wenn Du da noch einmal ändern solltest) einfach gleich auf die Modellnummer begrenzen (falls Du die unbedingt haben möchtest) und das FRITZ!Box (und auch ein event. in Klammern noch folgendes Branding) von vorneherein weglassen.
fda77
commented
3 years ago Berechtigungen sind falsch:
juis/juis_check 100755 → 100644Doch, bash:
GNU bash, Version 5.0.17(1)-release (x86_64-redhat-linux-gnu)Beim Aufruf im Script braucht man das "!" seltsamerweise nicht zu escapen.. Bei Ausgabe und späterer Verwendung aber schon: https://github.com/Freetz-NG/freetz-ng/blob/master/tools/juis#L13 Ich versuche die Abfrage so zufällig wie möglich bei Serial/Build/Nonce zu generieren, aber so genau wie möglich beim Rest. Wenn man kein Nonce angibt, ist dann darin ein zufälliger Wert?
Eine Ausgabe der Parameter gibt es "normal" nicht
Du hättrst besser in der Diskussion vom Kernel geantwortet. Wenn ich hier schreibe dass ich keine Ahnung hab wie das gehen soll ws du hier oben geschrieben hast ist es OT (und man findet es wie das mit musl nie wieder..)
PeterPawn
commented
3 years ago Du hättrst besser in der Diskussion vom Kernel geantwortet.
Vielleicht sollte einfach mal jemand eine Issue dafür aufmachen, daß bei GRX-Boxen (das Problem ist ja der Bootcore-Kernel, der als erstes gestartet wird und dann die anderen (bzw. bei AVM DEN anderen) erst "hochzieht") auch das REPLACE_KERNEL funktionieren sollte? Dann kann man darin wieder dazu schreiben ... mache ich das selbst, sieht es am Ende so aus, als hätte ich auch selbst irgendein Interesse daran (was eben nicht der Fall ist).
Die Rechte werden beim Mergen noch korrigiert.
Und nein, Du brauchst "Nonce" nicht selbst beim Aufruf angeben ... das wird tatsächlich zufällig erzeugt: https://github.com/PeterPawn/YourFritz/blob/juis/juis/juis_check#L1029 und zwar aus Datum und Uhrzeit (sekundengenau - aber so ein Request braucht üblicherweise auch mehr als eine Sekunde, so daß es wieder "eindeutig" sein sollte).
Auf diese Weise "verrät" die Nonce auch nichts zusätzlich ... wie spät es ist und welches Datum das aktuelle wäre, weiß der Server i.d.R. auch alleine. Aber er weiß eben nicht, wann ein Request vom Benutzer kommt bzw. "alte" Nonce-Werte bringen nichts mehr für Replay-Attacks.
Diese Nonce dient ja mit ihrem (für den Server nicht vorhersehbaren) Inhalt nur dazu, daß sie in die Response übernommen wird und sich damit eine andere Signatur (also ein anderer Hash-Wert über die Response) ergibt, so daß man sicher sein kann, daß sie auch vom Inhaber des passenden privaten Schlüssels "kodiert" (oder eben signiert) wurde und nicht einfach nur das Nachplappern einer Antwort durch einen Dritten ist, der die vorher irgendwann mal gespeichert hatte.
Wenn man den Wert (so wie ich) aus einem ständig anderen Ausgangswert generiert, ist das zwar "vorhersehbar", aber da sich Werte dann auch nicht wiederholen, spielt es hier keine wirkliche Rolle.
fda77
commented
3 years ago Aus der aktuellen Zeit... ach deshalb sah ich schon öfter gleiche Noncen! https://github.com/Freetz-NG/freetz-ng/blob/master/tools/juis#L18 :D Ich entfern den Parameter dann im "normalen" Modus Es gibt doch jetzt für den Kernel ein Issue/Diskussion :(
PeterPawn
commented
3 years ago Es gibt doch jetzt für den Kernel ein Issue/Diskussion :(
Du wirst mir aber auch nachsehen, wenn ich das im Freetz-NG-Repo alles nicht verfolgen WILL. Wenn ich dann Diskussionen sehe, die so beginnen: https://github.com/Freetz-NG/freetz-ng/discussions/182 und das nur aufgrund einer einzelnen Bemerkung, wo man nicht mal genau weiß, wohin der "zensierte Link" gegangen sein soll (ganz gewiß eher nicht hier ins Repo, sondern vermutlich wieder mal ins DEB und daß die konsequent gelöscht werden, finde ich sehr begrüßenswert - warum das so ist, habe ich mittlerweile auch oft genug versucht zu erklären), dann ist das (und nicht erst dann, wenn die Diskussion da wieder mal ausufert) auch nichts, was ich mir antun möchte.
So nett dieses neue Feature in GitHub auch sein mag ... man muß es leider auch ein wenig "moderieren" und wenn Du dann nach dem äußerst inhaltsreichen Beitrag von @janfreetz in dieselbe Kerbe haust (egal, was man Dir im IPPF auch angetan haben mag, das will ich gar nicht weiter diskutieren oder beurteilen), dann läßt mich das tatsächlich darauf verzichten, mich in diese Stories "einzulesen" - ich bin zwar auch kein glühender Verfechter des IPPF mehr (in erster Linie wegen unterirdischer Platzierung von Ergebnissen in den Suchmaschinen), aber ich halte auch nichts davon, an anderer Stelle im Internet über eine weitere Site "herzuziehen" - es bringt am Ende (außer schlechter Laune und einer "Echokammer", in der sich die Leute gegenseitig versichern, daß sie das alle genauso sehen) auch nichts.
Und wenn Du das jetzt mit meiner Kritik am DEB vergleichen willst, kann ich das zwar nicht ändern, aber da bin ich selbst auch nie "offiziell" aufgetreten und daher konnte mir da auch nie jemand "ein Leid zufügen", über das ich mich jetzt beschweren müßte - obendrein begründe ich ja (gerne und häufig) auch, warum ich das DEB ablehne und das mache ich ja nicht jedes Mal nur, weil ich das so gerne wiederhole, sondern weil mir immer wieder irgendjemand reinsingen will, daß das doch alles nur halb so wild wäre.
Das mag Dir jetzt als Einstellung meinerseits auch wieder zu "unversöhnlich" erscheinen ... andererseits interessiert mich die Sache mit Freetz (und auch Freetz-NG) tatsächlich nur noch am Rande und wenn ich mir überlege, was ich eigentlich auf dem Zettel hatte für die letzten Tage, verbringe ich schon wieder viel zu viel Zeit mit "Gesprächen" (und Überlegungen), die sich um Freetz drehen und nicht um die Projekte/Entwicklungen, die mir eigentlich am Herzen liegen.
Wenn ich irgendwo "auf die Schnelle" helfen kann, ist das sicherlich noch etwas anderes ... aber ich WILL mich einfach auch nicht in die Probleme der Freetz-Benutzer vertiefen/hineinziehen lassen - wenn ich selbst im IPPF darum bitte, bei künftigen Problemen erst mal die GitHub-Diskussionen in meinen Projekten/Repos zu benutzen, ist das ja auch meinerseits ein Schritt zur "Abnabelung" vom IPPF (vorher gab es eben kein vergleichbares Feature in GitHub) und wenn ich die erst mal (komplett) vollzogen habe, lese ich auch nicht mehr ständig von Freetz-Problemen - das macht es dann sehr viel leichter, sich entsprechende Antworten "zu verkneifen". Und da wäre es dann natürlich doppelt dumm meinerseits, wenn ich diese Freetz-Probleme dann doch wieder "brühwarm" mitbekomme, weil ich es mir nicht verkneifen kann, die Diskussionen im GitHub-Repository von Freetz-NG zu verfolgen.
fda77
commented
3 years ago Ich hatte eigentlich vor wieder etwas mehr im IPPF zu schreiben, aber ich wurde nach kurzem wegen dem verarschen-Gate gesperrt. Dieses schlimmer Wort darf wohl jeder ausser mir nutzen: https://www.ip-phone-forum.de/search/503089/?q=verarschen Wenn du dich weniger mit freetz beschäftigen will will ich nicht mehr als nötig stören. Und falls du in der ng-Organisation etwas herummoderieren willst sag bescheid. So viele Optionen gibt es bei den Diskussionen aber noch nicht.
fda77
commented
3 years ago Sieht gut aus, mir ist ausser der fehlenden Dateiberechtigung nichts aufgefallen. Getestet hab ich auf einer 7320 und tools/juis bzw in make.
Noch eine kleine Verbesserung: Die Antwort von AVM ist 1 lange Zeile. Man könnte die Debugausgabe formatieren, zb | sed -r 's/>(<[^\/])/>\n\t\1/g'
PeterPawn
commented
3 years ago So, den Stand in dem Branch hätte ich dann so weit fertig ... ohne weitere Fehlermeldungen wird der morgen mit dem master gemerged.
Man könnte die Debugausgabe formatieren
Da besteht vermutlich ein Mißverständnis, wofür ich die debug-Option überhaupt anbiete. Die soll je nicht für "every day use" sein, sondern zur Fehlersuche, wenn man z.B. neue Geräte hat und erst mal die passenden Werte "austesten" muß oder auch, wenn man Probleme (wie das mit Puma6 und 6820) suchen bzw. analysieren will.
An der Stelle, die Du vermutlich meinst, ist das auch nicht die SOAP-Antwort, die da angezeigt wird (auch wenn die dort enthalten sein mag), sondern die komplette Antwort, die über das Netzwerk ankam (also inkl. HTTP-Overhead). Da werde ich nichts anfassen - nichts ist für mich so schlimm wie eine Debug-Ausgabe, die (ohne daß das zu erkennen wäre), schon irgendwie "nachbearbeitet" wurde.
Auch ist es ja einigermaßen inkonsequent, wenn man dann nur Zeilenumbrüche einbaut und der Rest bleibt so unübersichtlich, wie er es vorher auch war - das macht das nicht wirklich "besser", nur länger. Wenn schon, denn schon ... also habe ich noch eine Option hinzugefügt, mit der man sich jetzt wirklich nur die (SOAP-)Antwort auf STDERR ausgeben lassen kann (STDOUT ist für die "Variablen" reserviert - ich lasse nämlich die Ausgabe ganz einfach als Zuweisung von Shell-Variablen ausführen an einigen Stellen, wo ich das selbst einsetze). Damit das dann aber tatsächlich auch zusätzliche Übersichtlichkeit ergibt, wird zumindest mal versucht, das Ganze durch einen Linter/Formatter zu jagen - die Parameter und der Standardname sind auf xmllint ausgerichtet.
Dann habe ich auch noch die "bash"-Erkennung etwas angepaßt - wenn's nur ein Fake ist, was sich hinter command -v bash verbirgt, nutzt ein "respawn" ja tatsächlich nichts - und außerdem gibt's bestimmt irgendwo auch noch eine muchtige bash, die ohne Netzwerk-Support daherkommt (oder HAVE_NETWORK nicht gesetzt hatte beim Kompilieren). Daher gibt's dann doch noch mal einen Fallback-Versuch, falls es über /dev/tcp nicht klappt - dann braucht's halt auch unter bash noch ein nc. Dabei bot es sich dann aber auch an, die Fehler beim Lesen aus dem Netz eher abzufangen - daher gibt's auch noch einen weiteren Exit-Code für Netzwerk-Probleme.
Das werde ich dann (nach dem Merge) alles noch irgendwie ins IPPF kopieren, damit da auch "Bescheid" erging - ansonsten ist das Thema für mich jetzt erst mal wieder abgeschlossen und ich werde mit dem Merge ein paar Issues (u.a. diese hier) schließen. Ich hoffe mal, es braucht jetzt keine weiteren Patches, um das in Freetz-NG nachnutzen zu können.
fda77
commented
3 years ago jemand hat mir erzählt der Offset wäre meist 72
Das ist so - ausser bei den Neuesten bei den Hwrev und Majon gleich sind. Und bei sehr alten bei denen der Offset kleiner ist. Wenn du es genau wissen willst schau die Spalte Off(set) hier an: https://boxmatrix.info/wiki/HWR-Names
Da besteht vermutlich ein Mißverständnis, wofür ich die debug-Option überhaupt anbiete. An der Stelle, die Du vermutlich meinst, ist das auch nicht die SOAP-Antwort
Ich meine bei Nutzung der Option "--debug" die sehr lange Zeile fast am Ende. Ich fand es ganz nett diese Ausgabe anzuzeigen, wenn man im Webif auf "suchen" klickt. Ansonsten war ohne diese Option in dem Fenster nur 1 Zeile... "--show-response" muss ich mir mal anschauen. "--save-response" nutze ich schon zur späteren Verarbeitung
Markdown: Für inline-Quellcode reich am Anfang und Ende je 1 accent grave, ich find das besser lesbar. 3 brauch man nur für mehrere Zeilen mit Zeilenumbrüchen
Public auf Buildtype war recht einfach umzustellen (da ist noch ein Typo drin!): https://github.com/Freetz-NG/freetz-ng/commit/966bd4966837bfb32b12f35a629ff548eec6c29e
PeterPawn
commented
3 years ago Das ist so - ausser bei den Neuesten bei den Hwrev und Majon gleich sind.
Das weiß ich ... ich habe es auch nicht gelöscht, weil ich es anzweifele, sondern weil AVM bei den neueren Modellen damit gebrochen hat.
Als ich das zum ersten Mal irgendwo schrieb, gab es hinterher Diskussionen (u.a. von Ralf S. - auch wenn ich nicht mehr weiß, ob sich das an mich direkt richtete oder ich es nur nebenbei gelesen habe) - nur tangierte mich damals gar nicht, wenn diese "Berechnung" für die uralten Möhren nicht funktionierte, weil die ohnehin nicht für JUIS-Benutzung in Frage kamen (teilweise waren's ja auch OEM-Geräte) und die waren/sind mir egal.
Mir hat das auch ab und an mal selbst geholfen, wenn ich nur eine der beiden Zahlen präsent hatte und die andere nicht erst nachschlagen mußte - aber seitdem es bei AVM nicht mehr stimmt für die neueren Modelle, bringt es nur Verwirrung bzw. zusätzliche Fragen/Kommentare, daß das ja gar nicht stimmen würde -> ergo habe ich es entfernt.
Ich meine bei Nutzung der Option "--debug"
Schon klar ... das ist aber tatsächlich die komplette Response des AVM-Servers, inkl. der HTTP-Header. Wenn Du in den Code siehst, ist das ein einzelnes sed, mit dem die Einrückung jeder Zeile um das debug: erfolgt: https://github.com/PeterPawn/YourFritz/blob/juis/juis/juis_check#L1718 - und HTTP ist ein "zeilenorientiertes" Protokoll, deshalb ist das noch kein "tampering with results", wenn ich das dort durch die Einrückung "aufhübschen" lasse.
Da jetzt aber noch einzelne Zeilen aus dieser gesamten Antwort durch zusätzliche Zeilenumbrüche in mehrere zu verwandeln, geht mir einfach zu weit, solange es um eine Debug-Ausgabe geht und die ist nun mal zur Fehlersuche gedacht. Wenn Du Dir z.B. die Debug-Ausgabe in eine Datei (oder Pipe) schreiben und diese danach mittels less -S anzeigen läßt (dabei werden dann lange Zeilen nicht automatisch umgebrochen), steht die gesamte SOAP-Antwort da auch in einer Zeile und kann mittels Cursor links/rechts bewegt werden.
Das ist eben doch noch etwas anderes, als eine veränderte XML-Struktur, wobei für mich auch eine Rolle spielte, daß die Umbrüche das ohne Einrückungen m.E. nicht wirklich besser machen, was die Übersichtlichkeit angeht (den "fixen" Tabulator sehe ich nicht wirklich als "strukturverbessernde Einrückung"). Das nervt mich schon bei AVM immer in den Shell- und Lua-Dateien - selbst wenn ich da mittlerweile auch lieber mit einem passenden Editor arbeite, der beim Öffnen erst mal die Dateien umformatiert, wenn ich sie analysieren (und nicht wirklich ändern) will.
Wenn Du das -a auch auf der Box machen willst, brauchst Du halt xmllint (aber libxml2 wäre ja bereits vorhanden) - wobei ich das jetzt noch einmal so abgeändert habe, daß man durch passendes Setzen von XML_LINTER auch Dein sed an dieser Stelle verwenden kann - wie das genau aussehen müßte, steht im Commit-Text hier: https://github.com/PeterPawn/YourFritz/commit/83ef697c10f4729cec4b7568ef949df4a956e875
da ist noch ein Typo drin!
Das verstehe ich wieder nicht ... bei Dir oder bei mir? Wenn bei mir, hätte ich natürlich die genaue Stelle erwartet als Hinweis.
Markdown:
Ich finde es nett, daß Du mir Tipps zum Markdown gibst (das ist absolut ernst gemeint und keineswegs sarkastisch - nicht falsch verstehen), aber das weiß ich tatsächlich schon und nutze es hier ja auch weidlich, wenn ich im Browser schreibe.
Aber die README.md-Files (und manches andere, was Markdown-Text enthält) editiere ich üblicherweise mit vim und auch wenn es dort passendes Syntax-Highlighting gibt (wenn man es einstellt), ist der natürlich mit komplexeren Sachen wie den Tabellen am Ende heillos überfordert.
Daher greife ich dann zu VS Code mit entsprechendem Markdown-Validator samt Vorschau ... und der mag die "single code spans" nicht so sehr, sondern hätte lieber "code fences" an dieser Stelle.
Da der auch noch etwas gegen Inline-HTML hat (die <br /> in den Tabellen) und da schon genug herummault, füge ich mich bei den Backticks einfach und verwende (an dieser Stelle) auch dann die dreifache Version, wenn es ein einzelnes Zeichen auch machen würde.
Das verkürzt die Liste der Warnungen des MD-Linters deutlich - und macht mir jetzt nicht soo viel Mehrarbeit, daß ich da irgendwie wählen müßte (oder etwas ändern - auch nicht an den Validator-Rules ... so oft muß ich mich mit MD nicht befassen, solange ich nicht doch noch irgendwann zu Jekyll und GitHub Pages wechsele).
fda77
commented
3 years ago Ausgabe mit dem sed aus https://github.com/PeterPawn/YourFritz/issues/37#issuecomment-776816257 :
Das letzte Drittel des Bildes ist so einfach besser lesbar, als wenn man das in 1 Zeile hat und horizontal scrollen muss. Für die Prüfung muss eh eine neue Seite geöffnet werden, da gefiel mit --debug besser als insgesamt nur 1 Zeile mit (nicht)gefunden.
Einen XML parser mag ich jetzt nur dafür nicht noch auf die Fritzbox installieren
(die 2+ "
Ich finde die 1-accent Markierungen besser zu schreiben, nutze aber keinen Editor mit Highlighting
PeterPawn
commented
3 years ago Sollte ich mit dem "merge" doch noch warten?
peh@vidar:/tmp/freetz-ng> cat .config.compressed
FREETZ_USER_LEVEL_EXPERT=y
FREETZ_TYPE_FIRMWARE_DETECT_LATEST=y
FREETZ_PACKAGE_BIND=y
FREETZ_PACKAGE_BIND_RNDC=y
FREETZ_PACKAGE_BIND_NSUPDATE=y
FREETZ_PACKAGE_BIND_DIG=y
FREETZ_PACKAGE_DNSMASQ=y
FREETZ_PACKAGE_DNSMASQ_WITH_DNSSEC=y
FREETZ_PACKAGE_DROPBEAR_SFTP_SERVER=y
FREETZ_PACKAGE_DROPBEAR_STATIC=y
# FREETZ_PACKAGE_DROPBEAR_AUTHORIZED_KEYS is not set
FREETZ_PACKAGE_DROPBEAR_NONFREETZ=y
FREETZ_BUILD_TOOLCHAIN=y
FREETZ_RPATH="/var/custom/lib:/var/custom/usr/bin"
peh@vidar:/tmp/freetz-ng> git status
On branch master
Your branch is up to date with 'origin/master'.
nothing to commit, working tree clean
peh@vidar:/tmp/freetz-ng> git log -n 1
commit 3371178e3f1ce90434e093e803c4ccbf92da0d0a (HEAD -> master, origin/master, origin/HEAD)
Author: fda77 <fda77@users.noreply.github.com>
Date: Thu Feb 11 19:30:41 2021 +0100
docs: change changelog url of dnsmasq
peh@vidar:/tmp/freetz-ng> ./fmake -t
make
exit code 2
duration 0m1.493s
peh@vidar:/tmp/freetz-ng> cat fmake_2021-02-12_16-30-43.log
WARNING: The program inkscape was not found in path.
JUIS: No cached value, asking avm for latest firmware ... no valid answer, trying backup ...
ERROR: Failed to detect the URL of the latest firmware version
make: *** [make/Makefile.image.in:142: dl/fw/7590-xx.detected.image] Error 3
peh@vidar:/tmp/freetz-ng>Eigentlich nichts Besonderes - nur der Versuch, mit Freetz-NG ein paar Binaries (hier bind und dnsmasq) zu bauen. Erst einmal dynamisch gelinkt - wenn das klappt, dann mit passenden Patches auch mit statischem Linken.
Irgendwas ist da faul - oder ich habe etwas falsch verstanden und das SOLL auch erst nach dem "merge" funktionieren. Aber wenn ich raten müßte, fehlt Dir da noch die Abhängigkeit, damit die jeweilige Version des YourFritz-Repos auch rechtzeitig(!) geklont wird in einem frischen Checkout.
Nach einem make yourfritz-host klappt es danach dann auch mit der JUIS-Suche. Wobei auch das "spooky" aussieht - nur um das zuvor aus dem Klon erzeugte TAR-File dann entpacken zu können, wird sofort auch das GNU-tar und die BusyBox für den Build-Host gebaut, weil die (ohnehin vorhandenen) Entpacker unbedingt die aus der BusyBox sein sollen.
Da mir das auch bei Freetz schon auf die Gameten ging, hatte ich mal einen Branch host_tools präpariert (https://github.com/PeterPawn/YourFreetz/tree/host-tools), der diese Abhängigkeiten für einige Programme entfernt - die überall zu findende Abhängigkeit von $(UNPACK_TARBALL_PREREQUISITES) basiert letztlich nur darauf, daß da unbedingt die Dekompressoren aus der BusyBox verwendet werden sollen, wofür es nur wenige plausible Begründungen geben dürfte.
Wenn man den lokal installierten Programmen wirklich nicht traut, kann man deren Existenz entweder explizit vor dem Aufruf prüfen oder man packt sich in das tools-Verzeichnis ein Wrapper-Skript (da reicht ja auch eines für mehrere Programme) per Symlink unter dem Namen so eines benötigten Programms und das testet dann erst mal, ob es das benötigte Programm auf dem Host nicht doch schon gibt und schmeißt erst bei negativem Suchergebnis den Build für die BusyBox an.
Es mag zwar auch nicht die Freetz-Nutzung mit der allerhöchsten Priorität sein, aber wenn jedesmal bei einem frischen Checkout erst die halbe Toolchain komplett gebaut werden soll (um es mal zu überspitzen), weil man z.B. ein "unsquashfs" braucht (und das brauchen sogar OpenWRT-Nutzer ab und an mal, wenn sie DSL-Treiber aus der AVM-Firmware klauen wollen), dann ist das (schon im "originalen" Freetz) nicht wirklich gut umgesetzt. Schließlich ist auch make ja eigentlich dafür gedacht, solche Abhängigkeiten so aufzulösen, daß nur das (neu) erstellt werden muß, was auch erforderlich ist.
Wenn man dann natürlich bei allem und jedem immer gleich die "Basics" als eigene Abhängigkeit deklariert, dann geht der Build auch jedesmal von vorne los - das macht z.B. die Nutzung von Freetz in einem Container, um schnell mal ein paar Tools zum Extrahieren von AVM-Firmware zu bauen, extrem langwierig und das ohne wirkliche Notwendigkeit.
Und um wieder auf die fehlende Abhängigkeit des JUIS-Schritts vom Klonen von YourFritz zurückzukommen ... wenn dann beim yourfritz-host-Paket weiterhin die Abhängigkeit von $(UNPACK_TARBALL_PREREQUISITES) steht, wird natürlich zuerst auch wieder GNU-tar und die BusyBox gebaut - ich habe jetzt nicht geschaut, ob das am Ende zu irgendwelchen Zirkel-Dependenzen führt, weil auch der BusyBox-Download vom erfolgreichen Download der AVM-Firmware abhängt o.ä.
Aber das mit den Dekompressoren aus der BusyBox ist schon ziemlich "old school" - und das Klonen von Repos, die dabei dann erst zusammengepackt werden (und zwar in diesem Falle wohl mit LZMA-Kompression), verstehe ich auch gerade so noch.
Warum dann aber für das Entpacken dieses Archivs erst mal eine BusyBox erstellt werden muß, die wiederum das GNU-tar als Abhängigkeit hat, verstehe ich spätestens dann nicht mehr, wenn schon für das (erfolgreiche) Entpacken der Quelltexte für das tar 1.32 ein unxz benötigt wird und für die BusyBox dann sogar ein bunzip2. Warum sollte man annehmen, daß die (als Voraussetzung/Prerequisite installierten) Host-Programme zwar für diese beiden Quelltext-Archive funktionieren, aber für das gerade erst zusammengepackte Archiv des geklonten Repos nicht? Das kann ja (offensichtlich) nicht so ganz richtig sein (wie gesagt, ist schon in Freetz/freetz so).
fda77
commented
3 years ago Ich hab nichts an juis_check zu bemängeln :)
Aus diesen ganzen makefile-toolchain-etc-Zeug hatte ich mich immer herausgehalten und es er13 überlassen - weil ich davon kein Ahnung hab. Daher ändere ich allein nur was wenn es Probleme gibt - sonst verursache ich noch Probleme wo ich nachher ewig suchen muss...
Nach einem distclean gibt es die hosttools wie tools/yf/ so früh noch nicht. Mist.
PeterPawn
commented
3 years ago Das letzte Drittel des Bildes ist so einfach besser lesbar
Na ja, das ist offenbar Ansichtssache.
Aber ich würde das ohnehin nicht mit der Debug-Ausgabe in das GUI einbauen (ist vielleicht auch nur Geschmacksfrage, aber welcher FRITZ!OS-/Freetz-Benutzer kann mit diesen Infos etwas anfangen) und wenn doch, würde ich die Debug-Ausgabe wenigstens vom einer Checkbox o.ä. abhängig machen.
Das mit den ANSI-Sequenzen ist für das GUI natürlich auch blöd ... da kommt wieder das ins Spiel, was ich vor einiger Zeit schon mal angemerkt habe. Das Framework, auf dessen älterer Version auch juis_check basiert, hat sich auch weiterentwickelt und die aktuelle Version (auch wenn sie noch nicht freigegeben ist) erkennt erstens besser, ob es sich um ein Terminal handelt und läßt ansonsten die Escape-Sequenzen gleich weg und zweitens kann man dort die für die Ausgabe verwendeten internen Funktionen (emsg, debug, info, etc.) auch "überladen" und damit dann sowohl Markdown- als auch HTML-Code (jeweils im Rahmen der Möglichkeiten, wobei HTML auch "bunt" kann) ausgeben ... wobei diese beiden Möglichkeiten auch noch ins Framework sollen, weil ich das natürlich dann auch für ein eigenes GUI auf der FRITZ!Box (für YourFritz) brauchen kann und ich die Hilfe-Bildschirme auch in MD verfassen können will. Das ist zwar noch nicht fertig, aber es ist auch der Grund, warum ich da an den Framework-Funktionen im Skript (von Zeile 49 bis 634) derzeit nichts ändern mag.
Laß doch im besten Falle auf der Box das --debug einfach weg (es ist ja unwahrscheinlich, daß die Angaben in der dortigen juis_boxinfo.xml erst mühsam ermittelt/ausgetestet werden müssen) oder mache es wirklich von einer Checkbox abhängig (wenn's keinen "Los ..."-Button gibt, kannst Du ja ein changed-Event für die Checkbox vorsehen). Ich glaube nicht, daß der durchschnittliche Freetz-Benutzer das (unaufgefordert) alles lesen will - und wie schon mal irgendwo geschrieben: STDOUT ist bei dem Skript den drei möglichen Zeilen (URL, DelayDownload und NewVersion - wenn -p angegeben wurde) vorbehalten und den ganzen Rest kann man ausblenden, wenn man STDERR einfach irgendwohin umleitet. Sogar die drei Zeilen in STDOUT könnte man (wenn man schon HTML nutzen kann) noch passend aufbereiten und neue Versionen z.B. in Rot oder ähnlichem anzeigen. Das war/ist eigentlich wirklich zur "automatischen" Benutzung gedacht und nur in Ausnahmefällen sollte man den Benutzer (meine Meinung) mit den Einzelheiten oder Interna belästigen. Dann wird das Problem der passenden Formatierung der (Debug-)Ausgaben automatisch auch kleiner.
fda77
commented
3 years ago wenn jedesmal bei einem frischen Checkout erst die halbe Toolchain komplett gebaut werden sol
Es gibt mittlerweile dl-toolchains für alle fos! Es werden nur host-tools gebaut
Laß doch im besten Falle auf der Box das --debug einfach weg
Ich bin noch nicht ganz sicher was "hübscher" ist: https://github.com/Freetz-NG/freetz-ng/blob/master/make/mod/files/root/usr/mww/cgi-bin/exec.d/juis_check.sh#L37
Die lesbare+klickbare Anzeige kommt nach zurück-Button drücken:
fda77
commented
3 years ago Aber das mit den Dekompressoren aus der BusyBox ist schon ziemlich "old school" - und das Klonen von Repos, die dabei dann erst zusammengepackt werden (und zwar in diesem Falle wohl mit LZMA-Kompression), verstehe ich auch gerade so noch.
Heruntergeladen Repos werden in dl/ (Link nach ~/.... bei ng) als Archiv gespeichert, dh man muss diese Version nur höchsten 1x auschecken
PeterPawn
commented
3 years ago Ich bin noch nicht ganz sicher
Kann/will ich nicht beurteilen ... aber ich würde dem Benutzer nur das anzeigen, was er wirklich wissen muß/will und erst wenn er "neugierig" ist, kann man es ihm immer noch genauer auseinanderklamüsern.
Ich werde dann (in Kürze) erst mal das Merge für den Branch machen ... dann ist das hier (automatisch) zu.
Das Thema mit den Abhängigkeiten im Makefile kann man (wenn notwendig) ja dann im Freetz-NG-Repo weiterführen - im besten Falle brauchst Du in der makefile.image.in beim image:-Target auch nur die Abhängigkeit von yourfritz-host definieren (oder wie das als Target auch immer heißen mag) ... vielleicht noch in Abhängigkeit von den FREETZ-Symbolen, die angeben, ob JUIS zu befragen ist oder nicht (ansonsten würde es immer zuerst geklont).
Das wäre zumindest das, was ich (bei einem ersten und sehr flüchtigen Blick) in der Datei gesehen habe - das (erste und einzige) Target ist image und die Calls für das Makro über eval am Ende der Datei sollten damit zu eben diesem einzigen Target gehören. Abhängigkeiten für image gehören dann hinter den image:-Teil der Zeile 32 (siehe make-Dokumentation bei den GNU-Tools).
fda77
commented
3 years ago Da ich mir nicht sicher bin welche Ausgabe besser ist und dir die kurze Version besser gefällt änder ich das
Aus der Version "100.06.50" verschwindet eine der "0"en. Ergebnis: "10.06.50"