7590: Unterschied push-firmware von freetz-ng und dem Recovery-Tool von AVM

[Parallix]

Seit einigen Tagen beschäftigt mich ein Problem, denn ich bekomme auf meine 7590 (HWRevision 226) einfach keine mit freetz-ng gebaute Fw drauf.

Für‘s Flashen nutze hierzu Debian/Linux (nativ, also ohne dem Umweg über eine VM) und erkenne aus den Informationen, die während push-firmware läuft, dass die Box immer wieder die ftp-Verfindung kappt (Meldung: „No reply from box, assuming switch-off or restart. Trying to re-detect box“).

Abfragen, die an die Box gehen, werden ausgeführt. So wird z.B. folgendes festgestellt:

* Detected memsize: '0x20000000'

* MAPSTART=0x80000000
* FULLSIZE=0x20000000 (512 MB)
* MAPLIMIT=0xa0000000
* FILESIZE=0x19a4c00 (25 MB)
* FREESIZE=0x1e65b400 (486 MB)
* MTDSTART=0x9e65b400

Nur via eines wiederholten PowerOn-Resets komme ich schrittweise bis zu dem Punkt, an dem die Fw auf die Box gespielt wird. Aber auch hier kappt die Box offenbar nach einiger Zeit die ftp-Verbindung, so dass der Fw-Upload nicht abgeschlossen werden kann.

Nun frage ich mich, was denn im Recovery-Tool von AVM anderes gemacht wird, als im Upload-Prozess, der mit push-firmware in freetz-ng angeworfen wird. Hat hier irgend jemand nähere Informationen?

 

[NDiIPP]

Das Recovery-Tool von AVM erstellt zusätzlich (aus dem Environment und dem Counter) ein neues TFFS-Image und lädt dieses in mtdnand hoch. Und setzt meiner Erinnerung nach auch noch die Variable "firmware-info" mit einem "recovered" Wert.

Ansonsten sollten sich die Unterschiede imo in Grenzen halten (abgesehen vielleicht noch von den Überprüfungen des Recovery-Tool um zu sehen ob die Box geeignet ist). Wobei ich push-firmware aus freetz-ng nicht näher kenne da ich lieber die YourFritz-Tools verwende.

 

[PeterPawn]

Ich würde hier auch noch einmal das Image überprüfen ... erstens wird das in "push_firmware" einigermaßen blind extrahiert aus dem angegebenen Firmware-Image (die Fehlerbehandlung beschränkt sich auf den Test, ob die entstandene Datei leer ist oder nicht) und zweitens wird (egal, welcher FTP-Client verwendet wird) zwischendrin auch nicht wirklich auf Fehlermeldungen des FTP-Servers reagiert ... das ist alles eher "Batch-Verarbeitung" und die Tatsache, daß z.B. bei einem fehlerhaften (In-Memory-)Image (wenn der Bootloader den ins RAM geladenen Kernel nicht entpacken und starten kann oder die Adressen nicht passen oder ähnliches) der FTP-Server mit FTP-Error 553 reagiert, wird nirgendwo wirklich "behandelt" - das ist auch eine eher "ungewöhnliche" Fehlermeldung, die nicht jeder FTP-Client unbedingt korrekt verarbeiten muß (auch wenn er die "Fehlerklasse" 5xx schon kennen sollte und darauf passend reagieren müßte).

Ansonsten klingt das auch irgendwie noch nach "Offload"-Problemen ... lagert das OS z.B. einige Teile des TCP-Processings an die Netzwerk-Karte aus (vom Fragmentieren bis zum Berechnen von Prüfsummen), kann das auch schiefgehen.

Hier fehlt ja irgendwie die Info, ob das nun zum ersten Mal mit dem PC passiert oder ob es bisher klappte - zumindest lese ich das nirgendwo explizit.

Der TCP-Stack im Bootloader einer FRITZ!Box und der darauf aufsetzende FTP-Server ist eher rudimentär und irgendwelche Spielereien wie "Jumbo-Packets" o.ä., bringen den schnell mal durcheinander. Hier wäre also ein "Kreuztest" zumindest der erste Schritt, um eine "schuldige Komponente" zu finden.

 

[Parallix]

Ich würde hier auch noch einmal das Image überprüfen ... erstens wird das in "push_firmware" einigermaßen blind extrahiert aus dem angegebenen Firmware-Image (die Fehlerbehandlung beschränkt sich auf den Test, ob die entstandene Datei leer ist oder nicht) und zweitens wird (egal, welcher FTP-Client verwendet wird) zwischendrin auch nicht wirklich auf Fehlermeldungen des FTP-Servers reagiert ... das ist alles eher "Batch-Verarbeitung" und die Tatsache, daß z.B. bei einem fehlerhaften (In-Memory-)Image (wenn der Bootloader den ins RAM geladenen Kernel nicht entpacken und starten kann oder die Adressen nicht passen oder ähnliches) der FTP-Server mit FTP-Error 553 reagiert, wird nirgendwo wirklich "behandelt" - das ist auch eine eher "ungewöhnliche" Fehlermeldung, die nicht jeder FTP-Client unbedingt korrekt verarbeiten muß (auch wenn er die "Fehlerklasse" 5xx schon kennen sollte und darauf passend reagieren müßte).

Das Image sieht soweit in Ordnung aus und zwar entpackt wie folgt:

-rwxr-xr-x 1 parallix parallix 22134792 Nov 25 08:02 filesystem.image
-rwxr-xr-x 1 parallix parallix  4753928 Nov 25 08:02 kernel.image

Ansonsten klingt das auch irgendwie noch nach "Offload"-Problemen ... lagert das OS z.B. einige Teile des TCP-Processings an die Netzwerk-Karte aus (vom Fragmentieren bis zum Berechnen von Prüfsummen), kann das auch schiefgehen.

Hier fehlt ja irgendwie die Info, ob das nun zum ersten Mal mit dem PC passiert oder ob es bisher klappte - zumindest lese ich das nirgendwo explizit.

Bei gleicher Konfiguration läuft das AVM-Recovery, gestartet aus einer VM (mit Windows 7 als Guest und Debian/Linux als Host-BS) - wie beschrieben - einwandfrei.

Der TCP-Stack im Bootloader einer FRITZ!Box und der darauf aufsetzende FTP-Server ist eher rudimentär und irgendwelche Spielereien wie "Jumbo-Packets" o.ä., bringen den schnell mal durcheinander. Hier wäre also ein "Kreuztest" zumindest der erste Schritt, um eine "schuldige Komponente" zu finden.

Die MTU habe ich zwecks Test explizit auf 1500 gesetzt. Alles andere habe ich gem. Default belassen.

Da die Verbindung nach kapp einem MB abbricht und die ETA dann steigt und steigt, sieht es für mich sehr nach einem Timeout seitens der Box aus.

LibNcFTP 3.2.5 (January 17, 2011) compiled for linux-x86_64-glibc2.27
Uname: Linux|pluto|5.3.0-2-amd64|#1 SMP Debian 5.3.9-3 (2019-11-19)|x86_64
Contents of /etc/debian_version:
  bullseye/sid
Contents of /etc/issue:
  Debian GNU/Linux bullseye/sid \n \l
Glibc: 2.29 (stable)
220: ADAM2 FTP Server ready
Connected to 192.168.178.1.
Cmd: USER adam2
331: Password required for adam2
Cmd: PASS xxxxxxxx
230: User adam2 successfully logged in
Logged in to 192.168.178.1 as adam2.
Cmd: MEDIA SDRAM
200: Media set to MEDIA_SDRAM
Cmd: SETENV memsize 0x1e65b400
200: SETENV command successful
Cmd: SETENV kernel_args_tmp mtdram1=0x9e65b400,0xa0000000
200: SETENV command successful
Cmd: TYPE I
200: Type set to BINARY
Cmd: MLST 0x9e65b400 0xa0000000
502: Command not implemented
Cmd: PASV
227: Entering Passive Mode (192,168,178,1,12,18)
Cmd: STOR 0x9e65b400 0xa0000000
150: Opening BINARY data connection
/tmp/freetz_iki/ramboot.flash:     ETA:  75:44    0.94/ 25.64 MB    5.57 kB/s =

Andererseits bleibt die grüne Power/DSL-LED permanent an, was zumindest gegen ein vollständiges Booten der Box spricht. In diesem Zustand ist die Box aber nicht mehr (z.B. via ping 192.168.178.1) erreichbar.

 

[PeterPawn]

Bei gleicher Konfiguration läuft das AVM-Recovery, gestartet aus einer VM (mit Windows 7 als Guest und Debian/Linux als Host-BS) - wie beschrieben - einwandfrei.

Wo wurde das denn beschrieben? Oder meinst Du damit nur die Tatsache, daß Du erwähnt hattest, daß Du eine native Linux-Installation benutzt? Von Windows und dem AVM-Recovery-Programm (bzw. dessen erfolgreichem Einsatz und nicht nur der Frage, was die Programme unterscheiden könnte) hattest Du hingehen noch gar nichts geschrieben.

Abgesehen davon, "überzeugt" dieser Test mit einer VM nicht wirklich ... die Windows-VM kommt ja mit einem eigenen IP-Stack daher und der Netzwerk-Treiber der VM kommuniziert direkt mit dem Hypervisor bzw. dem physikalischen Netzwerk-Treiber. Der IP-Stack des Host-Systems ist hierbei außen vor und von diesem ausgehende Probleme sind damit weiterhin nicht ausgeschlossen. Bei den potentiell schädlichen Optimierungen geht es auch weniger um die MTU (die MRU der Box ist ohnehin entscheidender), sondern um andere Dinge, wie die TCP-Window-Size oder SACK-Support, etc. - solange das nicht der einzige PC ist, der dafür genutzt werden kann, würde ich da also noch einmal richtig testen und ansonsten mal mit einem anderen System als dem bisher verwendeten Debian - z.B. mit einem Kali vom Stick oder einem Ubuntu als Live-System.

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

Daß der Einsatz von "fertigen" FTP-Clients eben auch mal zu Kommandos führt, die in dem FTP-Dialog eigentlich nichts zu suchen haben, kann man oben schön am "MLST"-Kommando sehen (und ja, weiter hinten komme ich auch zu Informationen, die ggf. für die Lösung Deines Problems hilfreich sein könnten - dank des Protokolls kann man da jetzt bessere Ideen entwickeln) ... nach RFC 3659 sollte sich eigentlich der Client erst mal mittels "FEAT"-Kommando davon überzeugen, welche Erweiterungen der FTP-Kommandos der Server überhaupt unterstützt (das "FEAT" fehlt da ganz offensichtlich ja im Dialog oder sehe ich das falsch?) und das nicht einfach blind unterstellen, wie es hier NcFTP offenbar macht. Die Gegenstelle ist hier ja kein "ausgewachsener" FTP-Server, der gegen alle möglichen Fehleingaben und potentielle Angriffe gehärtet wurde und damit von der Client-Seite nicht aus dem Tritt zu bringen ist.

DAS kann man also schon mal als Unterschied zwischen dem AVM-Recovery-Programm und "push_firmware" mit "NcFTP" in dieser Installation (aus der das o.g. Log stammt) festhalten ... das AVM-Programm setzt keine Kommandos an den FTP-Server ab, die dieser nicht versteht.

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

Abgesehen davon, erscheinen mir die Angaben zu den verwendeten Speicheradressen etwas komisch (wobei ich nicht verläßlich einschätzen kann, ob sie tatsächlich falsch sind und mangels 7590 kann ich es auch nicht überprüfen) - das Recovery-Programm von AVM begrenzt jedenfalls den Speicher auf 128 MB und rechnet auf dieser Basis dann weiter ... exakt so mache ich das auch in meinen "eva_tools".

Bisher hatte ich mir das immer so erklärt, daß der zweite Kernel in der "kernel.image" (das ist der, der unter "bootcore" segelt - die GRX-Boxen haben ja eine Virtualisierung, auch wenn auf dem "bootcore" wohl nur eine VM läuft) ja auch an einer bestimmten Adresse zu entpacken ist (der ist schließlich auch so gelinkt, daß der feste Adressen enthält) und diese Adresse im oberen Teil des Speichers liegt (wo genau, kann man sich irgendwo in der "dmesg"-Ausgabe ansehen, iirc). Wenn dort jetzt aber das "mtdram"-Device liegt, kann der Bootloader ihn nicht an diese Adresse entpacken, ohne den Inhalt des "in-memory images" dabei zu zerstören.

Ich habe keine Ahnung, ob das "push_firmware" in letzter Zeit mal geändert wurde (und ich habe auch keinen Bock, mir das jetzt reinzuziehen) ... aber so, wie es nach dem o.g. Protokoll versucht zu arbeiten, wird das (zumindest meiner Ansicht nach, auch wenn die nicht 100% zutreffend sein MUSS) eher nichts werden. Zumindest ist es eine Abweichung zu dem, was bei AVM passiert: https://www.ip-phone-forum.de/threads/freetz-auf-7580-aufspielen.294020/ ... und wenn ich die beschriebenen Symptome hinsichtlich des Verhaltens des FTP-Servers in dem verlinkten Thread mit denen hier vergleiche, sehe ich durchaus Parallelen.

Warum das dann aber bisher niemandem aufgefallen sein sollte, daß "push_firmware" in diesem Kontext gar nicht funktioniert, weiß ich auch nicht ... die einzige Erklärung, die mir dazu einfiele, wäre die, daß ich hier total auf dem Holzweg bin mit meiner Analyse (wobei man mal wieder sieht, wie wichtig und hilfreich ein Protokoll sein kann) oder es tatsächlich seit der Änderung an "push_firmware" vor neun Monaten (https://github.com/Freetz-NG/freetz...4cc66e3#diff-ed8c11aa10f8ce6ad863568e20b79e5a - denn ich habe mich dann doch nicht zurückhalten können, mir das noch einmal im Freetz-NG anzusehen und dankenswerterweise geht das ja inzwischen auch wieder ohne den (lahmen) Trac-Server direkt in GitHub) noch von niemandem (erfolgreich wohlgemerkt!) benutzt wurde, um eine GRX5-Box mit 512 MB RAM mit einer neuen Firmware zu beschicken.

Das erscheint mir aber - basierend auf den astronomischen Download- und User-Zahlen, die hier von jemandem (und es war nicht der Maintainer selbst) für Freetz-NG veröffentlicht wurden (und ja, dieser Seitenhieb mußte tatsächlich sein und richtete sich gar nicht primär an den Maintainer des Forks) - auch wieder nicht so richtig plausibel. Da werden ja sicherlich auch Leute darunter sein, die sich eine 7590/7580/7583/6890/usw. neu zugelegt haben und nun das erste Mal Freetz installieren wollten ... ich bin also leicht verunsichert.

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

Aber in jedem Falle würde ich Dir hier dann empfehlen, anstelle von "push_firmware" einfach mal "eva_to_memory" zu verwenden (mit der passenden Datei natürlich) ... sollte es damit funktionieren, kannst Du ja einen entsprechenden Fehlerbericht für Freetz-NG einreichen. Ich weiß allerdings nicht, ob dafür dann doch unbedingt der Trac-Server genutzt werden muß oder ob es inzwischen auch wieder über GitHub-Issues funktioniert, ich persönlich bin (oder war zumindest mal) dort "gesperrt" von fda77 beim Auslösen neuer und/oder Reagieren auf existierende "Issues" - daher kann ich hier "nur anregen".

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

EDIT: OK, die 9 Monate sind wohl Quatsch ... am Beginn war da tatsächlich noch eine Begrenzung (ausgehend von der 7490) auf 256 MB in "push_firmware" enthalten: https://github.com/Freetz-NG/freetz...7904d95fd99fb4cc66e3/tools/push_firmware#L352 , solange die "-ram"-Option eben NICHT angegeben wurde. Die wurde dann aber irgendwann zur Pflichtveranstaltung (https://github.com/Freetz-NG/freetz...8ac04d1#diff-ed8c11aa10f8ce6ad863568e20b79e5a) und letztlich wird sogar der Wert von "memsize" aus der Box ausgelesen (https://github.com/Freetz-NG/freetz-ng/blob/master/tools/push_firmware#L75) - wo genau das jetzt geändert wurde, weiß ich nicht und es geht auch aus den Commit-Messages (zumindest für mich) nicht hervor: https://github.com/Freetz-NG/freetz-ng/commits/master/tools/push_firmware ... zu einer sequentiellen Suche nach dem exakten Zeitpunkt habe ich keine Lust.

 

[Parallix]

...
Abgesehen davon, erscheinen mir die Angaben zu den verwendeten Speicheradressen etwas komisch (wobei ich nicht verläßlich einschätzen kann, ob sie tatsächlich falsch sind und mangels 7590 kann ich es auch nicht überprüfen) - das Recovery-Programm von AVM begrenzt jedenfalls den Speicher auf 128 MB und rechnet auf dieser Basis dann weiter ... exakt so mache ich das auch in meinen "eva_tools".
...

Basierend auf o.g. habe ich zwischenzeitlich push-firmware jetzt einmal mit "-ram 128" aufgefufen. Nun laufen in push-firmware alle Schritte bis einschließlich dem ftp komplett durch, ohne dass man der Box immer wieder ein POR spendieren muss.

Leider verharrt die Box aber nach dem ftp in einem Zustand mit dauernd eingeschalteter grüner Power/DSL-LED. In diesem Zusand ist die Box auch nicht mehr via ping 192.168.178.1 zu erreichen (egal ob ich vorher push-firmware mit -lfs 0, 1 oder 9 aufgerufen habe). Nach ca. 5 Minuten habe ich dann ein POR-Reset durchgefüht. Dann startet die Box normal (und schnell) durch, zeigt aber nach dem Booten keine Fw-Änderung, sondern meldet sich mit der original AVM-Oberfläche.

Hier noch die Debugging-Info:

freetz-ng@pluto:~/projects/freetz-trunk$ tools/push_firmware -ram 128 -lfs 0

* Analyzing 'images/7590_07.12.ger_freetz-ng-16390_20191128-072049.image' ...

* Using command: ncftpput
* Target host: 192.168.178.1
* Outgoing IP: 192.168.178.100
* Flash mode: ram-boot
* Allowed memory size: 128 MB
* Designated linux_fs_start: 0

!!! WARNING !!! WARNING !!! WARNING !!! WARNING !!! WARNING !!!
!!!  THERE IS NO WARRANTY AT ALL !!! USE AT YOUR OWN RISK   !!!

* Are you sure, that you want to flash this file to the device?
   images/7590_07.12.ger_freetz-ng-16390_20191128-072049.image
   Proceed? (y/[n]) y

* You should now reboot your box (192.168.178.1). Waiting for shut down.
   Switch off, if reboot is not detected because it happens too quickly.
   Some newer bootloader versions allow to flash on power-cycle only.

* MAPSTART=0x80000000
* FULLSIZE=0x8000000    (128 MB)
* MAPLIMIT=0x88000000
* FILESIZE=0x19a4c00    (25 MB)
* FREESIZE=0x665b400    (102 MB)
* MTDSTART=0x8665b400

* No reply from box, assuming switch-off or restart. Trying to re-detect box.
   Waiting ................... found!

* Box is back up again, initiating transfer.

LibNcFTP 3.2.5 (January 17, 2011) compiled for linux-x86_64-glibc2.27
Uname: Linux|pluto|5.3.0-2-amd64|#1 SMP Debian 5.3.9-3 (2019-11-19)|x86_64
Contents of /etc/debian_version:
  bullseye/sid
Contents of /etc/issue:
  Debian GNU/Linux bullseye/sid \n \l
Glibc: 2.29 (stable)
220: ADAM2 FTP Server ready
Connected to 192.168.178.1.
Cmd: USER adam2
331: Password required for adam2
Cmd: PASS xxxxxxxx
230: User adam2 successfully logged in
Logged in to 192.168.178.1 as adam2.
Cmd: MEDIA SDRAM
200: Media set to MEDIA_SDRAM
Cmd: SETENV memsize 0x665b400
200: SETENV command successful
Cmd: SETENV kernel_args_tmp mtdram1=0x8665b400,0x88000000
200: SETENV command successful
Cmd: TYPE I
200: Type set to BINARY
Cmd: MLST 0x8665b400 0x88000000
502: Command not implemented
Cmd: PASV
227: Entering Passive Mode (192,168,178,1,12,8)
Cmd: STOR 0x8665b400 0x88000000
150: Opening BINARY data connection
/tmp/freetz_ABV/ramboot.flash:     ETA:   0:01   22.06/ 25.64 MB    3.66 MB/s  226: Transfer complete
/tmp/freetz_ABV/ramboot.flash:                          25.64 MB    2.55 MB/s
Cmd: SETENV linux_fs_start 0
200: SETENV command successful
Cmd: QUIT
221: Thank you for using the FTP service on ADAM2
Cmd: QUIT
221: Goodbye.

done

 

[PeterPawn]

Es paßt eben immer noch nicht, was "push_firmware" da macht ... nach erfolgreicher Übertragung der Daten ins RAM sollte die Box mit "226 Transfer complete" reagieren und auch unmittelbar mit dem Entpacken des Kernels beginnen und diesen dann starten.

Weitere Reaktionen der Box sind an dieser Stelle gar nicht zu erwarten - Beispiel-Dialoge mit dem AVM-Recovery-Programm und/oder meinen eigenen Tools habe ich inzwischen - auch in diesem Thread - oft genug verlinkt bzw. die sind über eine Suche nach "eva_tools" definitiv zu finden, so daß eine komplette "Aufzählung" von relevanten Threads bzw. Beiträgen meinerseits höchst überflüssig wäre und der Hinweis auf die Existenz dieses "Angebotes" ausreichend sein sollte als Motivation für eine entsprechende Suche nach Informationen.

Das Setzen von "linux_fs_start" NACH dem Hochladen des Images wird also ohnehin nicht funktionieren ... ob es hier (neben der fehlenden Quittung der Box in Form der "226", die wohl auch irgendeine Ursache haben wird) auch ursächlich ist für das Problem, interessiert mich nicht wirklich. Das mit dem falschen Ablauf kann/sollte man dann in dem Fehlerbericht für Freetz-NG aber ggf. auch noch erwähnen, so man denn einen "einreichen" will.

Ansonsten habe ich bereits meine Empfehlung für einen Weg abgegeben, auf dem auch bereits mehrere Nutzer selbsterstellter Images diese auf die Box bekommen haben (entsprechende Threads/Beiträge kann sich nun mal jeder selbst suchen und dort dann nachlesen) - der Versuch, das mit "-ram 128" als Parameter für "push_firmware" zu erreichen, gehörte iirc nicht zu meinen Vorschlägen.

Denn meine generelle "Kritik" an der Verwendung von "NcFTP", aus der ja auch der Versuch mit dem "MLST"-Kommando resultiert und das offenbar auch nicht auf eine - wie auch immer geartete - Quittung im Control-Channel wartet, bevor weitere Kommandos abgesetzt werden (sonst hätte es das "SETENV" gar nicht mehr gegeben), habe ich bereits weiter vorne formuliert. Das zu ignorieren und nur selektiv die Abweichung bei der "memsize" als Argument aus #5 zu berücksichtigen, ist legitim ... zeugt aber für mich von einer gewissen "Beratungsresistenz", die weiteres Engagement meinerseits obsolet erscheinen läßt.

Ich wäre auch sehr verwundert, wenn tatsächlich jemand diese Abfolge von Kommandos erfolgreich (das Ausrufungszeichen aus einem früheren Beitrag müßte hier - im Widerspruch zu den Board-Regeln - mehrfach angebracht werden am vorstehenden Adjektiv) verwendet hat - erst recht zusammen mit "NcFTP" als Client, was da offenbar (ebenso wie die FRITZ!Box, aber die reklamiert für sich da ja auch keinen RFC-konformen Server im Bootloader - das Problem der "multiline response" beim "GETENV" wurde auch schon thematisiert hier im IPPF) nicht viel davon hält, sich am jeweils gültigen Standard zu orientieren.

Aber damit bin ich dann hier raus ... eine Wiederholung meiner Empfehlung erspare ich mir (und späteren Lesern). Der Fragesteller hat sich ja dazu entschlossen, den eigenen Test mit "-ram 128" auszuführen, wogegen zunächst mal auch gar nichts einzuwenden wäre ... zeugt es doch vom verstehenden Lesen von #5. Offenbar war an meiner Argumentation dann doch etwas dran, denn zumindest kam es nun ja nicht mehr zu den in #1 beschriebenen Symptomen bei der FTP-Data-Connection.

Aber danach wurde offenbar nicht weiter getestet und damit eben auch meine Empfehlung für einen (erprobten) Weg zur Lösung ignoriert - dieser hätte man ja auch noch folgen können/dürfen, nachdem das mit dem "-ram 128" offensichtlich ebenfalls nicht funktionierte. Meine Argumentation in #5 beschränkte sich ja nicht nur auf dieses "memsize"-Problem und ich verband mit der - eher wieder ausführlichen - Erklärung die Hoffnung, daß damit beim Leser nicht nur die "Empfehlung" für die Verwendung eines anderen Tools hängenbleiben würde, sondern auch die Begründung für diesen Vorschlag.

Es wird sicherlich einen Grund geben, warum er sich so entschieden hat ... das Fehlen jeder eigenen Begründung dafür (niedergeschrieben und so plausibel, daß man sich damit "identifizieren kann" bzw. daß man die Motive an dieser Stelle verstehen könnte) läßt weitere Anstrengungen meinerseits in diesem Thread eher als "vergebens" erscheinen.

 

[Parallix]

Es wird sicherlich einen Grund geben, warum er sich so entschieden hat ... das Fehlen jeder eigenen Begründung dafür (niedergeschrieben und so plausibel, daß man sich damit "identifizieren kann" bzw. daß man die Motive an dieser Stelle verstehen könnte) läßt weitere Anstrengungen meinerseits in diesem Thread eher als "vergebens" erscheinen.

Danke für die große Anzahl an Zeilen, von denen sich aber viele leider nicht mit der von mir in #1 gestellten und im Titel auch noch einmal explizit genannten Fragestellung beschäftigen. Immerhin sind zwischenzeitlich scheinbar einige Erfolge zu verzeichnen, die tatsächlich aber keine sind.

Um es noch einmal klar zu Ausdruck zu bringen: Ich möchte nicht auf irgendeine Weise das Image auf die Box bekommen, sondern bin hauptsächlich daran interessiert, dass push-firmware in freetz-ng so funktioniert, dass es (auch im Fall einer 7590) nutzbar ist.

 

[PeterPawn]

Um es noch einmal klar zu Ausdruck zu bringen:

Dem "noch einmal" widerspreche ich dann einfach mal, weil die Ausgangsfrage in #1 (für jeden nachlesbar) nicht so lautet, sondern da steht:

Nun frage ich mich, was denn im Recovery-Tool von AVM anderes gemacht wird, als im Upload-Prozess, der mit push-firmware in freetz-ng angeworfen wird. Hat hier irgend jemand nähere Informationen?

Genau auf diese Frage bin ich (auch mit den vielen Sätzen, die aus Deiner Sicht nichts mit Deinem Problem zu tun haben) eingegangen ... ein "Thema verfehlt" lasse ich mir hier also nicht auf's Auge drücken. Bist Du der Ansicht (und kannst das "nachweisen"), Du hättest das in der Folge irgendwo in diesem Thread bereits "erwähnt", wäre ein Beleg dafür nett.

Aber mit der "Klarstellung" in #8 ist dann ja meine (nur auf der Basis Deines Verhaltens geschlußfolgerte - denn das hast Du eben [entgegen Deiner Behauptung] so nicht geschrieben) Vermutung hinsichtlich der Errfolgsaussichten weiterer Bemühungen von meiner Seite bestätigt.

Dann hoffe ich mal, daß sich hier der Autor dieser Änderungen noch melden wird ... ausgehend von der Historie der Änderungen an "push_firmware" behaupte ich mal, daß das spätestens ab hier: https://github.com/Freetz-NG/freetz...7904d95fd99fb4cc66e3/tools/push_firmware#L161 nie richtig getestet (zumindest nicht mit der anschließenden "Umschaltung" von "linux_fs_start") und eher "theoretisch" erstellt wurde.

Außerdem wage ich mal die These, daß Du dann mit Deinem Ansinnen im DEB oder im IRC eher eine Chance haben wirst, denn der "Freetz-NG"-Support findet eher spartanisch/spontan/sporadisch im IPPF statt und Dein Problem ist dann (wenn Du gar nicht das Image auf die Box bringen willst, sondern das "push_firmware" aus Freetz-NG zum Laufen) eher spezifisch für diesen Fork.

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

EDIT: Wobei das "226 Transfer complete" ja tatsächlich noch vom Client empfangen wurde (steht halt im Protokoll zwischen irgendwelchem (Statistik-)Müll (und auch noch "mittendrin") und nicht da, wo andere "commands and responses" stehen - daher leicht zu übersehen dort am Zeilenende, solange man nicht jede Zeile aufmerksam liest) ... da würde ich dann sogar spekulieren, daß entweder die "unbekannten Kommandos" davor den Server schon per se durcheinanderbringen oder der Versuch, nach dem "226 Transfer complete" noch weiter mit ihm zu kommunizieren.

DAS ist jedenfalls der Teil, der weder beim AVM-Recovery-Programm noch bei meinen Tools (egal, ob für Linux oder Windows) stattfindet ... denkbar, daß der Server bei einem weiteren Kommando den Prozess des Entpackens unterbricht. Sollte diese Vermutung stimmen (ich teste das jetzt nicht - mangels 7590 - und ich müßte wenigstens erst eine 7580 aufbauen dafür), hätte das tatsächlich noch nie funktioniert, wenn man das "SETENV" dort "nachschieben" wollte.

Zumindest kann man damit dann wieder einen Test machen, bei dem die Parameter so gewählt werden, daß das "SETENV" (für "linux_fs_start") gar nicht stattfindet - ob das "QUIT" ebensolche Probleme bereitet (das "quit" für den Client wird ja - sichtbar im Protokoll oben - sogar zu zwei "QUIT"-Kommandos für den Server ... das zweite vermutlich in Reaktion auf die "221"-Message vom Server), weiß ich nicht. Aber ich weiß sicher, daß auch dieses Kommando vom AVM-Programm und von meinen Tools nicht gesendet wird ... beide Implementierungen lassen dem Server die Zeit, den Kernel zu entpacken und zu starten, wenn das "226 Transfer complete" nach einem "STOR"-Kommando ins RAM empfangen wurde.

 

[Parallix]

Genau auf diese Frage bin ich (auch mit den vielen Sätzen, die aus Deiner Sicht nichts mit Deinem Problem zu tun haben) eingegangen ... ein "Thema verfehlt" lasse ich mir hier also nicht auf's Auge drücken.

Bleib fair! Ich hatte "viele" und keineswegs "alle" geschrieben:

Danke für die große Anzahl an Zeilen, von denen sich aber viele leider nicht mit der von mir in #1 gestellten und im Titel auch noch einmal explizit genannten Fragestellung beschäftigen.

Überdies bin ich für Deine konstruktiven Rückmeldungen ja auch sehr dankbar!

Außerdem wage ich mal die These, daß Du dann mit Deinem Ansinnen im DEB oder im IRC eher eine Chance haben wirst, denn der "Freetz-NG"-Support findet eher spartanisch/spontan/sporadisch im IPPF statt und Dein Problem ist dann (wenn Du gar nicht das Image auf die Box bringen willst, sondern das "push_firmware" aus Freetz-NG zum Laufen) eher spezifisch für diesen Fork.

Natürlich will ich mit push-firmware aus freetz-ng auch ein Image auf die Box bringen, aber es geht mir eben nicht darum, dies über ein Portfolio externer Tools zu machen. Sollte freetz-ng für mich auch mittelfristig nicht sinnvoll einsetzbar sein, dann bilde ich mir mein Urteil über diesen Fork von freetz und dessen "Support". Solange bin ich aber fair und hoffe ...

 

[PeterPawn]

Solange bin ich aber fair und hoffe ...

Auch damit habe ich kein Problem ... nur wäre es eben auch nett gewesen, wenn Du irgendwie zu erkennen gegeben hättest, daß Du meine ausführlichen Bemühungen einer Erklärung auch tatsächlich zur Kenntnis genommen hast.

Ich schreibe mir hier einen Wolf ... und am Ende machst Du doch nur das, was Du selbst als richtig erachtest und Deine Beweggründe dafür, kann man nirgendwo lesen - erst in #8 äußerst Du Dich dann überhaupt dazu, nachdem ich (inzwischen zugegebenermaßen schon etwas genervt ob der zur Schau getragenen Sturheit bzw. Ignoranz) indirekt danach gefragt habe.

Da wäre es dann auch von Deiner Seite aus "fair", wenn Du solche "Nebensätze" wie das "wie beschrieben" (und meine Nachfrage dazu hast Du in den Skat gedrückt) oder das "noch einmal" einfach beiseite lassen oder eben mit entsprechenden Links belegen würdest ... gerade dann, wenn Du mit:

Bleib fair!

solches von anderen einforderst.

Abgesehen davon, bist Du mit der Annahme:

aber es geht mir eben nicht darum, dies über ein Portfolio externer Tools zu machen.

auch deutlich auf dem Holzweg - hätte "Fairness" es jetzt nicht auch erfordert, daß Du Dich hier erst einmal "richtig schlau" machst?

Im "originalen" Freetz ist das "YourFritz"-Projekt seit dem 22.06.2016 enthalten und auch der "Freetz-NG"-Fork nutzt dieses Paket an anderen Stellen weiterhin kräftig ... nur wurde in diesem Fork im Februar/März 2019 (nachdem es zuvor ein paar unschöne Diskussionen hinsichtlich der Frage gab, ob es mit "Freetz" nun weitergeht und wie ein Fork aussehen sollte - inzwischen sind einige der damals "angeprangerten" Entscheidungen wieder revidiert worden für diesen Fork) dann das "push_firmware" so erweitert, daß es in der Lage sein sollte, mein "eva_to_memory" zu ersetzen (und auch beim Signieren von Images mußte dann plötzlich eine nachprogrammierte Lösung her) ... die Nutzer des "originalen" Freetz leben jedenfalls seit der Aufnahme dieses Projekts in "Freetz" auch ganz gut mit diesem - aus Deiner Sicht "externen" - Tool und auch Du wirst - wissentlich oder unwissentlich - den einen oder anderen Teil aus diesem Projekt verwenden.

Jedenfalls findest Du dieses "Portfolio externer Tools" dann auch weiterhin in Deinem eigenen Build ... Du brauchst nur mal einen Blick in https://github.com/Freetz-NG/freetz-ng/tree/master/tools/make zu werfen. Angesichts der Probleme, die sich für "push_firmware" hier zeigen, werden dann wohl andere Nutzer auch auf "eva_to_memory" ausgewichen sein - oder ein anderer FTP-Client für "push_firmware" arbeitet dann doch deutlich besser als "NcFTP".

Abgesehen davon: Ich habe in #9 noch etwas ergänzt ... vielleicht bringt Dich das bei der Suche nach dem Problem weiter. Denn ich finde es tatsächlich sehr löblich, wenn jemand einem Problem auch auf den Grund gehen will und nicht immer nur "geht nicht" konstatiert ... nur sollte er das dann eben (deutlich erkennbar) auch so zum Ausdruck bringen, damit sich andere ihre Mühen bei der Hilfe dann (basierend auf eigenen Entscheidungen) verkneifen können.

PS:

Ich hatte "viele" und keineswegs "alle" geschrieben:

Da fällt das "Bleib fair!", was Du davor geschrieben hast, zugegebenermaßen auch schwer ... denn da steht zwar tatsächlich nicht "alle" (ich hatte sogar selbst "viele" geschrieben - auch bei mir steht da also kein "alle"), aber eben auch kein "einige" und nach dem gängigen Verständnis der deutschen Sprache ist "viele" in diesem Kontext ja wohl der größere Part ... mal ganz abgesehen von Deinen Bemerkungen zu Deinen "scheinbaren Erfolgen" (und hier kann man "scheinbar" tatsächlich mal so verwenden), die ja auch eher danach klingen, als würdest Du Dein "Versagen" den wenig hilfreichen Vorschlägen für eine Lösung anlasten.

 

[Parallix]

Danke für die klärenden Worte!

Abgesehen davon: Ich habe in #9 noch etwas ergänzt ... vielleicht bringt Dich das bei der Suche nach dem Problem weiter.

Deine Ergänzungen finde ich prima und denke, dass ich basierend darauf auch weiter suchen kann. Danke!

Einen kleinen Anmerkung möchte ich noch betreffend des "schlau machens" anbringen. Denn meinerseits habe ich - bevor ich den Thread eröffnet habe - im Forum nach einer Erläuterung im Sinne einer Prozessbeschreibung gesucht, wie genau das Recovery im Falle der AVM-Lösung für die 7590 abläuft. Erst nachdem ich keine zufriedenstellende Info gefunden habe, habe ich mich an die Gemeinde hier im IP-Phone-Forum gewandt. Im Nachhinein bin ich der Ansicht, dass ich ganz oben in #1 besser die Frage nach einer Prozessbeschreibung des Flashens am Beispiel der 7590 gestellt hätte, denn Bezug auf freetz oder irgendeinen seiner Forks zu nehmen. Sorry hierfür!

 

[PeterPawn]

für die 7590

DAS war dann vielleicht die Stelle, die da "etwas zu speziell" bei der Suche war. Denn bekanntlich gab es mit den GRX5-Prozessoren vor der 7590 bereits zwei andere Modelle, nämlich die 7580 und die 7560 (Frühjahr/Sommer 2016), bevor dann die 7590 ein Jahr später fertig wurde.

Es wäre sicherlich eher ungewöhnlich, wenn

• die "Community" mit dem Erkunden der GRX5-Boxen so lange gewartet hätte, bis die 7590 erschien oder
• die zuvor bereits zusammengetragenen Erkenntnisse für die 7580 (die nun tatsächlich bei dieser Fragestellung praktisch identisch ist mit der 7590 - die 7560 hat als "Sparversion" weniger Speicher und ist daher tatsächlich leicht abweichend zur 7580/7590) nun alle noch einmal für die 7590 wiederholt würden, anstatt nur zu konstatieren, daß diese Modelle sich praktisch gleich verhalten

Ich weiß, daß es niemand gerne hört oder liest, daß er bei der Suche nach bereits vorhandenen Infos "versagt" hat (bitte nicht zu hoch hängen - ich könnte auch schreiben: "durch eigene Schuld ineffektiv war", wenn Dir das weniger "offending" erscheint - wobei ich das "durch eigene Schuld" ja auch versuche zu begründen) ... und trotzdem kann auch eine solche Bemerkung, die er selbst jetzt vielleicht als Angriff ansieht (und oft genug sind solche "stundenlangen Suchen" ja - leicht zu belegen - auch nur eine Schutzbehauptung, was ich hier ausdrücklich nicht unterstellen will), dem nächsten Leser schon wieder einen Hinweis darauf geben, mit welcher Abwandlung seiner bisher vergeblichen Bemühungen er vielleicht doch noch zum Ziel kommt.

Das wäre bei Dir halt die Suche nach vergleichbaren Modellen gewesen (der/die Nächste wird sicherlich auch nicht nach der 7583 oder der 6890 suchen bzw. er/sie hätte nur denselben, mangelhaften Erfolg, der auch Dir beschieden war) ... den Thread, in dem auch der FTP-Dialog des AVM-Recovery-Programms für eine 7580 zu sehen ist (und zwar "in voller Schönheit", beginnend mit dem Auslesen von "env" und "count", dem Schreiben des TFFS-Images nach "mtdnand" (das zuvor vom Recovery-Programm mit den ausgelesenen Infos zusammengestellt wurde), der anschließenden Kontrolle von "env" und "count" und dem - abschließenden - Speichern der "mtdram"-Partition), hatte ich oben bereits in #5 verlinkt.

Hier wäre dann die "Nachfrage", ob es Abweichungen von der 7580 zur 7590 gibt, ggf. noch "verständlich" gewesen, obwohl auch das mehrfach thematisiert wurde und irgendwann dann anstelle der "einzelnen" Modell-Bezeichnungen eher die "Zusammenfassung" der Architekturen anhand des Prozessors (VR9, GRX5, BCM-irgendwas) und der verwendeten Flash-Architektur (weil die tatsächlich großen Einfluß auf die Abläufe hat) Einzug hielt.

Das mit dem "schlau machen" bezog sich außerdem - in meinen Ausführungen in #11 - ja auch gar nicht auf die Frage, ob/was Du hinsichtlich des FTP-Dialogs hättest suchen und finden müssen/sollen ... da ging es eindeutig darum, das von Dir "kultivierte Vorurteil", es handele sich bei den Empfehlungen für den Einsatz der "YourFritz"-Tools (auch von @NDiIPP in #2 bereits so erfolgt) um die Empfehlung des Einsatzes eines "Portfolios externer Tools", zu hinterfragen.

Denn daß die Änderungen an "push_firmware" für die Behandlung der Boxen mit selbst-installierenden Images erst aus dem Februar/März 2019 stammen, kann man leicht feststellen und daß sie bei "Freetz" gar nicht vorhanden sind, war auch schon sehr früh geklärt - da hätte man sich ja auch die Frage stellen können (oder gar müssen?), wie wohl die anderen "Freetzer" ihre Boxen bis dahin mit der ersten, selbsterstellten Firmware bestücken konnten, wenn es doch die 7590 (und deren Unterstützung in Freetz) oder gar die 7580 (und deren Unterstützung in Freetz) bzw. auch die 7560 (und deren Unterstützung in Freetz) schon 1,5 Jahre zuvor gab (und da gab es den Fork noch gar nicht). Auch die Frage, wie denn andere "Freetz-NG"-User das mit "push_firmware" wohl anstellen und wieso Deine Probleme dort ggf. nicht auftreten, wäre ja naheliegend ... das kann immer noch ein anderer FTP-Client sein, der da den Ausschlag gibt.

Ich habe Dir hier also gar nicht "mangelhafte Suche" vorgeworfen (DAS hätte ich dann tatsächlich auch so geschrieben, wie man mehrfach nachlesen kann) ... ich sehe(sah) #1 sogar als "informativer" an, als es gewöhnlich bei solchen Fragen der Fall ist (meist steht nicht mal da, was für ein System oder welcher Fork zum Einsatz kam), auch wenn das (später "nachgereichte") Protokoll da noch fehlte.

Ansonsten hätte ich inzwischen wohl auch gar nicht mehr reagiert ... auch wenn meine ersten "Annahmen" in #3 am Ende vielleicht nicht zutrafen. Man kann aber auch an anderen Stellen wieder nachlesen, daß es mit Offload durchaus Probleme gibt (für die 7390 weiß ich das sogar "ganz konkret": https://www.ip-phone-forum.de/threads/wie-recovere-ich-eigentlich-richtig.299790/post-2280290) und die Ausführungen zur "mangelhaften" Auswertung der Ergebnisse in den FTP-Clients von "push_firmware", haben ja weiterhin Gültigkeit, auch wenn das hier nicht das primäre Problem war.

Daß jemand am Ende die Skript-Dateien (zumindest bei meinen "eva_tools" oder auch das Upload-Formular im GUI) mit dem falschen "Dateityp" füttert, ist ebenfalls "gängige Praxis" und alles andere als ungewöhnlich ... zumal hier eben für "eva_to_memory" vom Freetz-"make" das korrekte Format als "in-memory"-File erzeugt wird, während es für "push_firmware" erst wieder in ein komplettes "image"-File eingepackt werden muß, damit dieses Skript es wieder auspacken kann (auf die einzige Prüfung, daß die Datei nicht die Länge 0 hat, habe ich schon hingewiesen).

Bevor man also "sehen" konnte, was da beim "push_firmware" im FTP-Dialog offensichtlich schief lief, waren auch die "abwegigen Vermutungen" in #3 noch einigermaßen wahrscheinlich ... zumal man eben auch mal von der Schiene "runter" muß, daß sich jeder - aber auch wirklich jeder - Teil einer solchen Antwort auf die konkrete Situation des Fragestellers beziehen muß. Denn dann wäre das tatsächlich wieder der "individuelle Support" für den Fragesteller und brächte anderen Lesern, die nicht exakt dasselbe Problem/dieselbe Frage haben, eher wenig. Da muß man es dann auch mal aushalten, wenn eine Antwort "etwas weiter ausholt" und dabei ggf. versucht, weitere Zusammenhänge zu erläutern oder andere potentielle Problemquellen zu erwähnen. Ob das dann "einige", "viele", "die Mehrzahl" oder "am Rande" ist, liegt sicherlich auch immer im Auge des Betrachters und hängt unmittelbar mit der Frage zusammen, wie exakt die "Eingangsfrage" denn zum eigenen Problem des jeweiligen Lesers paßt.

 

[Parallix]

Denn bekanntlich gab es mit den GRX5-Prozessoren vor der 7590 bereits zwei andere Modelle, nämlich die 7580 und die 7560 (Frühjahr/Sommer 2016), bevor dann die 7590 ein Jahr später fertig wurde

Ehrlich gesagt finde ich das "bekanntlich" wenigstens genauso problematisch wie einige meiner Formulierungen oben. Daher schlage ich vor, dass wir künftig auf solche oder ähnliche Formulierugen verzichten.

Das wäre bei Dir halt die Suche nach vergleichbaren Modellen gewesen ...

Auch glaube ich nicht, dass die Informationen, die man bei Suche nach "vergleichbaren Modellen" bekommen hätte, einen konkreten Frage, wie z.B. die im Thread-Titel, wirklich beantworten. Meinerseits führen Sie nur zu Mutmaßungen, die korrekt aber auch falsch sein können.

Festhalten möchte ich an dieser Steĺle in jedem Fall, dass im Thread hier von Dir, PeterPawn, einige wertvolle Informationen gegeben wurden, für die ich wirklich sehr dankbar bin!

 

[Parallix]

Es gibt erfreuliches zu berichten: Ohne vorhandenes "ncftp" läuft "tools/push_firmware -ram 128 -lfs 9" komplett durch und die Box meldet sich nach einem selbstständigen Reboot mit freetz-ng auf der Box!

 

[PeterPawn]

Ehrlich gesagt finde ich das "bekanntlich" wenigstens genauso problematisch wie einige meiner Formulierungen oben.

Weißt Du, was der Unterschied in der Verwendung solcher Formulierungen ist? Du verwendest sie ("wie beschrieben", "um es noch einmal zum Ausdruck zu bringen") zur "Ausschmückung" Deiner eigenen Einlassungen hier im Thread und versäumst es sogar auf explizite Nachfrage, dafür entsprechende Belege in Form von zitierten Textstellen aus Deinen Beiträgen zu präsentieren.

Ich beziehe mich hier auf Quellen, die jeder im Internet mit - durchaus zumutbarer - Recherche jederzeit selbst einsehen kann - das will mir bei Deinen Behauptungen (die sich ja wohl auf diesen Thread beziehen) einfach nicht gelingen und ich denke mal, es liegt nicht an der falschen Lesebrille.

Die von mir "referenzierten" Quellen für diese "bekannten Informationen" beginnen mit der Auflistung der FRITZ!Boxen bei router-faq.de (da steht auch das jeweilige Erscheinungsdatum eines Modells) und ziehen sich bis zu boxmatrix.info (da steht neben dem Datum auch noch einiges zum Aufbau der Geräte, wenn man das nicht aus anderen Quellen zusammensuchen kann/will) ... dazwischen liegen noch mehrere Threads hier im IPPF, wo die Boxen (auch von mir selbst in entsprechenden Beschreibungen, z.B. hier: https://www.ip-phone-forum.de/threads/fritz-box-7580-firmware-153-06-90-telnet-service-freischalten-geht-auch-für-7560-und-7590.296678/post-2239701 und da steht sogar etwas zum Installationsprozess, der sich an das Laden ins RAM anschließt) ebenfalls thematisiert wurden.

Auch die Beiträge bei teltarif.de, in denen die verschiedenen FRITZ!Box-Modelle ausfgeschraubt und ihre "Innereien" untersucht werden, würde ich in die Reihe der "bekannten Quellen" einordnen.

Wenn Du all diese Informationen nicht finden kannst (zumindest offenbar nicht alleine), ist es - zumindest in meinen Augen - aber auch nicht die Aufgabe von anderen, das für Dich zu übernehmen - höchstens noch, Dir dabei (auf Deine Bitte hin) entsprechende Hilfe beim Erlernen einer korrekten Recherche zu offerieren.

Ob Du dann glaubst, daß diese Quellen Dich irgendwie weiterbringen würden oder nicht, spielt eigentlich auch keine Rolle ... solange Du sie nicht gefunden und gelesen hast, wird diese Annahme immer nur als "Vermutung" weiter existieren. Und an diesem Zustand kannst auch nur Du durch eigene Initiative (eben durch Lesen und "Bewerten" ihres Inhalts) etwas ändern ... das kann (bzw. sollte) niemand für Dich übernehmen, zumal auch die Einschätzung der "Nützlichkeit" anderer Beiträge durchaus differieren kann, je nach Erkenntnishorizont des Betrachters.

Da sehe ich also letzten Endes - gerade anhand der vielen Quellen als möglicher Beleg für mein "bekanntlich", die ich absichtlich nur "beschrieben" und nicht verlinkt habe - durchaus heftige Unterschiede zu Deinen Formulierungen, zumal es Dir ja offensichtlich nicht einmal gelingt, Deine "Anmerkungen" innerhalb dieses einen Threads (was nun wirklich mit "hoher Lokalität" der Verweise verbunden wäre) entsprechend zu belegen.

Da Dein "wenigstens" dann auch noch suggeriert, daß Du diese Feststellung meinerseits eigentlich noch als "viel schlimmer" empfindest (ich sehe nichts im bisherigen Verlauf, was mich dazu veranlassen könnte, anzunehmen, daß Du da Deinerseits irgendwelche Abstriche nach meinen Erklärungen hier vornehmen würdest), denke ich ebenso, daß wir uns wohl nichts mehr zu sagen/schreiben haben.

EDIT wg. Typos

 

[Parallix]

Da Dein "wenigstens" dann auch noch suggeriert, daß Du diese Feststellung meinerseits eigentlich noch als "viel schlimmer" empfindest (ich sehe nichts im bisherigen Verlauf, was mich dazu veranlassen könnte, anzunehmen, daß Du da Deinerseits irgendwelche Abstriche nach meinen Erklärungen hier vornehmen würdest), denke ich ebenso, daß wir uns wohl nichts mehr zu sagen/schreiben haben.

Nicht jeder ist so wahrnehmungsbegabt, wie Du!

 

[PeterPawn]

Ja, diese Feststellung, ich wäre "hochsensibel", höre ich häufig ... das merkt man schon meinem Äußeren an, daß ich eher zart besaitet und eigentlich "ein Sensibelchen" bin.

Aber man muß auch gar nicht besonders sensibel sein, um hinter dem plötzlichen Umschwenken auf "ad hominem" anstelle des Eingehens auf die Fragen, worauf Deine Formulierungen letztlich basieren (und hinsichtlich des "bekanntlich" in meiner Aussage in #13 warst Du ja offensichtlich ebenso "hochsensibel"), dann doch die Ratlosigkeit und das Bemühen um Ablenkung vom Thema zu erkennen.

Und nun behaupte bitte nicht, Deine Worte in#12 und #14 hätten noch irgendetwas mit der Ausgangsfrage zu tun und daher wäre das ohnehin alles "off-topic" und dieses "Abschweifen" Deinerseits auch nur das Ergebnis meiner eigenen Einlassungen ... ich bin nur dagegen, das hier mit einem "Fazit" von Dir zu beenden, dem ich meinerseits nicht zustimme und das in meinen Augen erneut unwahre bzw. unbelegte oder auch "zu hinterfragende" Behauptungen enthält.

Aber wir können ja auch über das Wetter reden ... das hat dann auch nichts mit meinen "Nachfragen", worauf Du Dich da jeweils bezogen haben könntest, zu tun. Oder man kann auch den dreiköpfigen Affen hinter Dir besprechen ... es gäbe sooo viele Möglichkeiten.

 

[Parallix]

Und nun behaupte bitte nicht, Deine Worte in#12 und #14 hätten noch irgendetwas mit der Ausgangsfrage zu tun ...

In der Tat haben meine Worte zu Beginn von #12 und am Ende von #14 nicht direkt etwas mit der Ausgangsfrage zu tun. Vielmehr waren meine netten Worte an Dich dazu gedacht, wieder etwas Sachlichkeit in die Unterhaltung zu bringen.

Hast Du eigentlich bemerkt, dass ich vor Beginn Deiner heutigen Posts nach meinem Frühstück um 8:00 Uhr in diesem Thread in #15 einen Erfolg vermelden konnte?

 

[PeterPawn]

Ja, das habe ich bemerkt ... offenbar ist also der "NcFTP" bzw. dessen Vorhandensein bei der Suche nach einem verwendbaren FTP-Client daran schuld.

Das ändert aber auch nichts an meiner Aussage, daß diese Kombination dann offenbar nie vernünftig getestet wurde ... da ich auch dann nicht sehen kann, warum es mit einem anderen FTP-Client immer noch funktionieren sollte, wenn man eben nicht "-lfs 9" verwendet (und damit auf das "SETENV" nach dem "STOR" verzichtet) und diese Option bietet das Skript ja ebenso noch an, wie es ohne "-ram" den falschen Wert aus der Box liest bzw. einen falschen Wert verwendet.

Insofern also "Glückwunsch", daß es Dir mit dem "push_firmware" letzten Endes gelungen ist, eine Firmware zu installieren ... ich bin mal gespannt, ob nach Deinem Fehlerbericht dann auch die versammelten Macken so ausgemerzt werden, daß es auch mit "-lfs 0" (oder 1) funktioniert (das erfordert zumindest eine andere Reihenfolge der Kommandos) und daß jeweils die richtige Begrenzung der Speichergröße verwendet wird, sofern ein Kernel mit "bootcore" vorliegt (DAS könnte man sogar anhand der "kernel.image" noch ermitteln).

Ich hatte schon meine Gründe, warum ich meinerseits nicht alles in ein einzelnes Skript gekippt habe und warum ich keinen "batchfähigen" FTP-Client verwende, sondern die FTP-Kommunikation lieber "zu Fuß" programmierte. Die Komplexität der Aufgabe, ein Skript als "eines für alle" zu schreiben, ist deutlich größer, als es der Autor der Änderungen an "push_firmware" zuerst wahrhaben wollte ... daß es ein "nice to have" wäre, wenn es ein solches gäbe und daß man sich dazu irgendwie mal abstimmen müßte, was man von so einem Tool erwarten würde und was es leisten sollte, war schon zu Freetz-Zeiten klar (irgendwo gibt es im GitHub dazu eine Diskussion mit er13) - nur gab es solche Diskussionen (und erst mal das Erarbeiten der Grundlagen, wie das nun wirklich funktioniert - siehe der Versuch, das "SETENV" nach dem "STOR" zu machen) auch vor den Änderungen an "push_firmware" (offensichtlich) nicht ... und das ist der Kern meiner "Vorwürfe" zu diesen Änderungen.

Daß es sich bei meinen Skripten eigentlich nur um einen "proof of concept" handelte und diese dringend überarbeitet werden müßten, wurde meinerseits auch oft genug betont (zumindest für die Linux-Versionen, die PowerShell-Implementierung wurde schon mit mehr Augenmerk auf die Nachnutzbarkeit erstellt) ... nur hatte ich mir das zugegebenermaßen eher als Zusammenarbeit vorgestellt und nicht als "Verdrängungswettbewerb" - daher meine Skepsis (bis hin zur Ablehnung) in Bezug auf dieses Skript.

Zumal auch die Sache mit dem "-ip"-Parameter zwar als Option sinnvoll ist, aber spätestens bei einer Box mit "ungewisser Vergangenheit" auch nicht weiterhilft ... ist so eine Box (z.B. mit dem ruKernelTool) auf eine andere Adresse gestellt im Bootloader, weiß der Besitzer gar nicht, was er bei "-ip" angeben soll bzw. bringt der Standardwert 192.168.178.1 auch nichts.

Es gibt ja auch einen Grund, warum das AVM-Recovery-Programm zunächst mal mit dem UDP-Broadcast nach der startenden Box sucht und sich nicht auf eine solche IP-Adresse festlegt (die taucht erst in den Fehlerbehandlungsvorschlägen von AVM auf, falls das Recovery-Programm tatsächlich mal versagen sollte), sondern eher die Box auf eine Adresse einstellt, die zur vorliegenden Netzwerkkonfiguration paßt.

Wer da mit einem Windows-PC mit LAN-Adresse 192.168.100.irgendwas (eine "gerne genommene" Adresse, warum auch immer) das AVM-Recovery-Programm verwendet (hat), der findet dann eben seine FRITZ!Box mit ihrem Bootloader ab diesem Zeitpunkt unter 192.168.100.1 und nicht unter 192.168.178.1 - das wird auch durchaus persistent im TFFS (im Environment) abgelegt, wie man an den ganzen Boxen mit der "ruKernelTool-Adresse" immer wieder sehen konnte. Für ein wirklich universelles Tool ist da also auch das "push_firmware" mit dem Parameter nicht wirklich geeignet - hier kann/sollte man sich für eine "komplette Lösung" tatsächlich mal ein Beispiel am AVM-Recovery-Programm (und/oder an meiner Re-Implementierung der UDP-Kommunikation in "eva_discover" bzw. "EVA-Discovery.ps1") nehmen.