eva_to_memory - Syntax Error

[jerkball]

Sorry for Msg in german:

./eva_to_memory: Zeile 321: / 1024 / 1024 : Syntax Fehler: Operator erwartet. (Fehlerverursachendes Zeichen ist \"/ 1024 / 1024 \"). Memory size is

Anything missing in my system or the code just broken?

Thanks

[PeterPawn]

Da wird offensichtlich ein Environment aus der Box gelesen und zwar auch erfolgreich (sonst sollte das Skript nicht im "if"-Zweig nach dem "get_environment" landen - https://github.com/PeterPawn/YourFritz/blob/master/eva_tools/eva_to_memory#L317) und dann enthält dieses Environment offenbar keinen Wert für "memsize".

Etwas mehr Fleisch darf da also schon noch am Knochen sein ... angefangen beim Modell der Firmware bis zum kompletten(!) Protokoll - das wird irgendwo als "eva_to_memory_session.log" gespeichert. Auch der ausgelesene Inhalt des Environments (wenn Du den findest - z.B. anhand von Trace-Ausgaben ... wobei man den auch gesondert mit "eva_get_environment" auslesen kann, um ihn erst einmal zu prüfen) wäre natürlich interessant ... ich hoffe mal, es läuft nicht auf eine "komische Bedingung" beim "get_environment" hinaus. Einige Modelle haben auch gar kein TFFS-Environment - daher hätte ich schon ganz gerne die Info, was das überhaupt für ein Modell sein soll.

Sorry for Msg in german:

No matter ... meinetwegen auch komplett in Deutsch weiter. Oder auch in Englisch ... falls die deutsche Antwort jetzt nicht verstanden wird (läßt sich aber bestimmt maschinell übersetzen).

[jerkball]

Hi Peter,

deutsch ist perfekt.. dachte nur an die Netiquette von Github...

Hier mein Fleisch zum Knochen... Gebaut habe ich im WSL von Windows 10... (Aktuelle Version: Build 19041.1)

Darin läuft ein Debian 9 Stretch....

gcc 6.3.0

Box war eine Fritzbox 7430 mit 07.12.... mehrmals recovered....

Leider kein eva_to_memory_session.log... dafür aber ein eva_to_memory.log

220 ADAM2 FTP Server ready USER adam2 331 Password required for adam2 PASS adam2 230 User adam2 successfully logged in SYST 215 AVM EVA Version 1.2589 0x0 0x47409 TYPE I 200 Type set to BINARY MEDIA SDRAM 200 Media set to MEDIA_SDRAM P@SW 227 Entering Passive Mode (192,168,178,1,12,2) RETR env 150 Opening BINARY data connection 226 Transfer complete SETENV memsize 0xfffffffffe370800 200 SETENV command successful SETENV kernel_args_tmp mtdram1=0x7e370800,0x80000000 200 SETENV command successful TYPE I 200 Type set to BINARY MEDIA SDRAM 200 Media set to MEDIA_SDRAM P@SW 227 Entering Passive Mode (192,168,178,1,12,10) STOR 0x7e370800 0x80000000 150 Opening BINARY data connection

Zeilenumbrüche musst du dir leider denken....

Die Box tut nun ihren Dienst... nachdem mein Laptop mit Ubuntu zum Erfolg führte... Aber ich habe die Zweitbox noch hier liegen und mache gerne Tests mit WCL und YourFritz für nachfolgende Kollegen, die vllt nur Windows haben....

[PeterPawn]

Ist das tatsächlich reproduzierbar und war die Box zu diesem Zeitpunkt auch neu gestartet, bevor sie im Bootloader (wie genau?) angehalten wurde?

Was steht denn in einem neu ausgelesenen Environment? Bitte eva_get_environment verwenden, weil das eva_to_memory auch so macht und zumindest eine 7490 da unterschiedliche Werte liefert, je nachdem, ob man "RETR env" oder "GETENV memsize" verwendet,

Dem Protokoll nach soll das "RETR env" ja funktioniert haben (der Inhalt der Übertragung wird leider nicht protokolliert), aber beim Subtrahieren der Image-Größe vom ausgelesenen Wert für memsize ergibt sich ein negativer Wert (0xfffffffffe370800) ... daraus kann man zumindest vermuten, daß der ausgelesene Wert 0 war bzw. daß er gar nicht vorhanden ist.

Das kann eigentlich bei einer neu gestarteten Box gar nicht passieren, da dieser Wert beim (Kalt-)Start des Bootloaders immer wieder auf den korrekten Inhalt gesetzt wird und gar nicht dauerhaft (sprich: über einen Kaltstart hinaus) geändert werden kann, soweit ich das kenne (von der 7490 und 7412, aber eine 7430 sollte der 7412 doch sehr ähnlich sein). Da sollte also ein memsize 0x08000000 im Environment stehen und wenn das nicht der Fall ist, ist irgendetwas faul ... aber mit dem Device und nicht mit dem Skript.

Bei passendem Eintrag sollte das Problem auch nicht reproduzierbar sein und auf irgendeiner ungewöhnlichen Reihenfolge von Aufrufen oder einer vorhergehenden falschen Behandlung der Box (ob Deinerseits oder vom Vorbesitzer) beruhen.

Ich könnte mir z.B. vorstellen, daß irgendwie das TFFS gelöscht wurde (ich habe selbst auch noch kein Schreiben einer leeren Datei nach "mtdnand" probiert und weiß nicht genau, wie sich dieser Unsinn dann auswirkt) und nun der Bootloader da den Wert für "memsize" beim Start nicht richtig hinzufügen kann ... aber das muß man alles gar nicht erraten, das kann man wunderbar nachsehen.

Hinsichtlich des Protokoll-Namens hast Du recht ... den kann man über eine Angabe von EVA_LOG=<somewhere> aber auf jede beliebige Stelle umbiegen (https://github.com/PeterPawn/YourFritz/blob/master/eva_tools/eva_to_memory#L32):

logfile=${EVA_LOG:-$0.log}

[PeterPawn]

Vorerst geschlossen ... ohne weitere Informationen (die in den letzten neun Tagen nicht eintrafen) ist der Fehler nicht zu (er-)klären.

Zwar wäre eine bessere Kontrolle der Zuweisung an die Variable "memsize" denkbar, was dann den o.a. Fehler vermeidet ... aber erstens handelt es sich nur um eine Demonstration des Prinzips (zumindest bei den Shell-Skripten, die noch jede Menge Verbesserungspotential hätten - von der Verwendung einer beliebigen "netcat"-Version bis zum TCP-Support der "bash", von ordentlicher Auswertung der Parameter bis zu aussagekräftigen Fehlermeldungen) und zweitens ändert das am grundsätzlichen Problem des "reporters" wohl auch nichts, denn die Frage hier wäre, warum trotz erfolgreichem Auslesen des Environments da kein "memsize"-Eintrag vorhanden ist.

Sollte es neue Informationen geben, kann das hier ja gerne erneut geöffnet werden - bis dahin mache ich hier zu.