[Problem] in-memory Image lässt sich nicht mit EVA-FTP-Client.ps1 auf 7590 hochladen

[mj084]

Edit DM41: abgetrennt aus Wie nutzt man das YourFritz "image2ram"

Ok, daran lags
Danke!

Nun stehe ich aber vorm nächsten Fehler, ich bekomme das in-memory Image nicht vollständig hochgeladen und zerschiesse mir dabei die Box...

PS C:\Users\XYZ> C:\freetz\EVA-FTP-Client.ps1 -Verbose -Debug -ScriptBlock { BootDeviceFromImage C:\freetz\7590_07.27.all_freetz-ng-18452-e6a583c04_20210712-083935.image.in-memory }
DEBUG: Response:
220 ADAM2 FTP Server ready

================
DEBUG: Sent
USER adam2
================
DEBUG: Response:
331 Password required for adam2

================
DEBUG: Sent
PASS adam2
================
DEBUG: Response:
230 User adam2 successfully logged in

================
DEBUG: Sent
SYST
================
DEBUG: Response:
215 AVM EVA Version 1.3578 0x0 0x46409

================
DEBUG: Sent
GETENV memsize
================
DEBUG: Response:
memsize               0x20000000

200 GETENV command successful

================
DEBUG: Memory size found    : 0x20000000 (512 MB)
DEBUG: Memory size used     : 0x08000000 (128 MB)
DEBUG: Image size found     : 0x0215ec00
DEBUG: Set memory size to   : 0x05ea1400
DEBUG: Set MTD RAM device to: 0x85ea1400,0x88000000
DEBUG: Sent
SETENV memsize 0x05ea1400
================
DEBUG: Response:
200 SETENV command successful

================
DEBUG: Sent
SETENV kernel_args_tmp mtdram1=0x85ea1400,0x88000000
================
DEBUG: Response:
200 SETENV command successful

================
DEBUG: Sent
TYPE I
================
DEBUG: Response:
200 Type set to BINARY

================
DEBUG: Sent
MEDIA SDRAM
================
DEBUG: Response:
200 Media set to MEDIA_SDRAM

================
DEBUG: Uploading file 'C:\freetz\7590_07.27.all_freetz-ng-18452-e6a583c04_20210712-083935.image.in-memory' to
'0x85ea1400 0x88000000' ...
DEBUG: Sent
P@SW
================
DEBUG: Response:
227 Entering Passive Mode (192,168,178,1,12,27)

================
DEBUG: Sent
STOR 0x85ea1400 0x88000000
================
DEBUG: Response:
150 Opening BINARY data connection

================
DEBUG: Sent
SETENV memsize 0x20000000
================
DEBUG: Response:
120 Service not ready, please wait

================
DEBUG: Sent
UNSETENV kernel_args_tmp
================
DEBUG: Response:
120 Service not ready, please wait

================
DEBUG: Sent
QUIT
================
DEBUG: Response:
120 Service not ready, please wait

================
Ausnahme beim Aufrufen von "Invoke" mit 0 Argument(en):  "Error uploading image file."
In C:\freetz\EVA-FTP-Client.ps1:638 Zeichen:21
+                     $ScriptBlock.Invoke()
+                     ~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [], ParentContainsErrorRecordException
    + FullyQualifiedErrorId : RuntimeException

Wo liegt jetzt noch der Hund begraben?

 

[PeterPawn]

Nach dem Upload des Images tritt eine zu große Pause ein, die als "Timeout" interpretiert wird, weil keine 226 Transfer complete-Message kommt. Beim anschließenden Versuch, die Speichergröße wieder auf den ursprünglichen Wert zu setzen (damit man ohne Neustart erneut ein Image laden könnte - ansonsten würde der Speicher bei jedem Versuch kleiner), behauptet die Box, sie wäre noch beschäftigt: 120 Service not ready, please wait

Bleibt die Frage, warum zwischen dem Ende der Übertragung (das dieses fünfsekündige Warten auf die Bestätigung auslöst: https://github.com/PeterPawn/YourFr...60b19387370/eva_tools/EVA-FTP-Client.ps1#L400) und der Meldung von der Box so viel Zeit vergeht - das Warten erfolgt in Zeile 407, falls Du das testweise höher drehen willst.

Nach meinem Eindruck treten solche Probleme erst auf (zumindest "öfter"), seitdem die AVM-Images auch größer werden - bei dieser Art der Installation auf den GRX-Boxen, wird ja auch der verfügbare Hauptspeicher per se auf 128 MB (noch abzgl. des Platzes für das Image) begrenzt. Bei den AVM-Images geht das u.U. "gerade noch so" gut - sowie die Images dann aber noch größer werden (bei AVM ist die filesystem.image knapp 25 MB groß - der Kernel wird derselbe und ca. 6 MB groß sein), kann das durchaus zu Problemen führen. Die Gegenprobe wäre hier derselbe Versuch mit einer originalen AVM-Firmware - natürlich ebenfalls in ein passendes Format gewandelt (mit image2ram). Wobei Speichermangel eigentlich noch kein Grund sein sollte, daß der Kernel nicht mehr entpackt werden kann - und da sollte dann auch die Erfolgsmeldung um FTP-Control-Channel ausgegeben werden. Das ist also in meinen Augen weniger wahrscheinlich ... aber der entsprechende Test ist "billig" und braucht praktisch keine Zeit.

Klappt es dann aber mit der AVM-Firmware doch noch, liegt es ja sicher am Image - dann bliebe z.B. immer noch der Beginn mit einem minimalen Image (mit eigenem öffentlichen Schlüssel für die Signatur) und das anschließende Update über das AVM-GUI, falls es tatsächlich auf Speichermangel hinaus läuft.

Ich gucke mir die Stelle mit dem Timeout aber noch einmal an ... wenn gar keine Rückmeldung von der Box kommt (also weder 226 bei Erfolg, noch 553 bei einem Fehler) und sie auf weitere Kommanso mit 120 antwortet), könnte man noch weitere Warteschleifen einlegen (im Rahmen des Vernünftigen jedenfalls).

Wie sieht denn eigentlich die Ethernet-Verbindung zwischen PC und FRITZ!Box aus? Es gibt ja ein paar (sehr alte) Anleitungen, die auch schon mal empfehlen, 10 Mbit/s halbduplex einzustellen - da braucht dann aber auch die Übertragung von 35 MB für ein Image entsprechend lange. Da irgendwelche Probleme bei der "autonegotiation" (das ist die automatische Aushandlung des Ethernet-Modes) äußerst selten auftreten (zumindest nach meiner eigenen Erfahrung), würde ich so eine Möglichkeit (der festen Einstellung) auch erst als Allerletztes in Betracht ziehen.

Vielleicht startest Du doch erst einmal schnell mit dem Versuch, das AVM-Image auf genau demselben Weg zu installieren und je nach Ergebnis, kann man dann weiterdenken. Das ist für Dich letztlich nur ein Zwischenschritt, der nichts wirklich ändert ... ob das aktive System jetzt mit dem Freetz-NG-Image oder der originalen AVM-Firmware überschrieben wird - am Ende ist das bisherige in beiden Fällen weg.

---

EDIT:

Ich habe mal ein paar Änderungen an dem PS-Skript zusammengeklöppelt und auf GitHub eingecheckt - Download (raw) unter:

https://raw.githubusercontent.com/PeterPawn/YourFritz/eva_tools_ps/eva_tools/EVA-FTP-Client.ps1

Das ist komplett ungetestet - gerade mal einen flüchtigen Syntax-Check mit der PS-ISE habe ich gemacht bzw. das Skript in der ISE gestartet, ohne Parameter und ohne Box, die in EVA wartet.

---

Das Warten nach beendeter "copytask" erfolgt jetzt nicht mehr pauschal für fünf Sekunden, sondern es wird in 1 s-Intervallen von 20 heruntergezählt, während auf 226 oder 553 gewartet wird. Ist -Debug aktiviert, erfolgt pro Sekunde eine Meldung in der Ausgabe.

Das ist nur ein "Angebot" ... wenn es keiner benutzt und dabei testet (ich komme da nicht zu, zumal ich erst passende Umgebungen zum Test aufbauen müßte), bleibt es für vier Wochen in dem Branch stehen und wird dann entsorgt. 2-3 positive Rückmeldungen (am liebsten mit passenden Protokollen aus dem PS-Host, wie in #12) und ich überführe das in den main-Branch. Gibt es hingegen Fehler oder Probleme mit diesen Änderungen, brauche ich die Protokolle und werde dann versuchen, das entsprechend zu korrigieren.

 

[mj084]

Danke erstmal für deine ausführliche Antwort

Hatte jetzt vor deinem Edit getestet und versucht das originale AVM Image im entsprechenden Format hochzuladen - erstmal mit Autoaushandlung bei der Geschwindigkeit des Netzwerkadapters, dann mit 10 M/Bit Vollduplex - Resultat:

PS C:\Users\XYZ> C:\freetz\EVA-FTP-Client.ps1 -Verbose -Debug -ScriptBlock { BootDeviceFromImage C:\freetz\FRITZ.Box_7590-07.27.image.in-memory }
DEBUG: Response:
220 ADAM2 FTP Server ready

================
DEBUG: Sent
USER adam2
================
DEBUG: Response:
331 Password required for adam2

================
DEBUG: Sent
PASS adam2
================
DEBUG: Response:
230 User adam2 successfully logged in

================
DEBUG: Sent
SYST
================
DEBUG: Response:
215 AVM EVA Version 1.3578 0x0 0x46409

================
DEBUG: Sent
GETENV memsize
================
DEBUG: Response:
memsize               0x20000000

200 GETENV command successful

================
DEBUG: Memory size found    : 0x20000000 (512 MB)
DEBUG: Memory size used     : 0x08000000 (128 MB)
DEBUG: Image size found     : 0x01fe7c00
DEBUG: Set memory size to   : 0x06018400
DEBUG: Set MTD RAM device to: 0x86018400,0x88000000
DEBUG: Sent
SETENV memsize 0x06018400
================
DEBUG: Response:
200 SETENV command successful

================
DEBUG: Sent
SETENV kernel_args_tmp mtdram1=0x86018400,0x88000000
================
DEBUG: Response:
200 SETENV command successful

================
DEBUG: Sent
TYPE I
================
DEBUG: Response:
200 Type set to BINARY

================
DEBUG: Sent
MEDIA SDRAM
================
DEBUG: Response:
200 Media set to MEDIA_SDRAM

================
DEBUG: Uploading file 'C:\freetz\FRITZ.Box_7590-07.27.image.in-memory' to '0x86018400 0x88000000' ...
DEBUG: Sent
P@SW
================
DEBUG: Response:
227 Entering Passive Mode (192,168,178,1,12,27)

================
DEBUG: Sent
STOR 0x86018400 0x88000000
================
DEBUG: Response:
150 Opening BINARY data connection

================
DEBUG: Sent
SETENV memsize 0x20000000
================
DEBUG: Response:
120 Service not ready, please wait

================
DEBUG: Sent
UNSETENV kernel_args_tmp
================
DEBUG: Response:
120 Service not ready, please wait

================
DEBUG: Sent
QUIT
================
DEBUG: Response:
120 Service not ready, please wait

================
Ausnahme beim Aufrufen von "Invoke" mit 0 Argument(en):  "Error uploading image file."
In C:\freetz\EVA-FTP-Client.ps1:638 Zeichen:21
+                     $ScriptBlock.Invoke()
+                     ~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [], ParentContainsErrorRecordException
    + FullyQualifiedErrorId : RuntimeException

Zumindest war die Box noch heile...

Ich probiere jetzt nochmal dein Update der EVA-FTP-Client.ps1 ...

 

[mj084]

Update:

Klappt auch mit dem aktualisierten Script nicht:

PS C:\Users\XYZ> C:\freetz\EVA-FTP-Client.ps1 -Verbose -Debug -ScriptBlock { BootDeviceFromImage C:\freetz\FRITZ.Box_7590-07.27.image.in-memory }
DEBUG: Response:
220 ADAM2 FTP Server ready

================
DEBUG: Sent
USER adam2
================
DEBUG: Response:
331 Password required for adam2

================
DEBUG: Sent
PASS adam2
================
DEBUG: Response:
230 User adam2 successfully logged in

================
DEBUG: Sent
SYST
================
DEBUG: Response:
215 AVM EVA Version 1.3578 0x0 0x46409

================
DEBUG: Sent
GETENV memsize
================
DEBUG: Response:
memsize               0x20000000

200 GETENV command successful

================
DEBUG: Memory size found    : 0x20000000 (512 MB)
DEBUG: Memory size used     : 0x08000000 (128 MB)
DEBUG: Image size found     : 0x01fe7c00
DEBUG: Set memory size to   : 0x06018400
DEBUG: Set MTD RAM device to: 0x86018400,0x88000000
DEBUG: Sent
SETENV memsize 0x06018400
================
DEBUG: Response:
200 SETENV command successful

================
DEBUG: Sent
SETENV kernel_args_tmp mtdram1=0x86018400,0x88000000
================
DEBUG: Response:
200 SETENV command successful

================
DEBUG: Sent
TYPE I
================
DEBUG: Response:
200 Type set to BINARY

================
DEBUG: Sent
MEDIA SDRAM
================
DEBUG: Response:
200 Media set to MEDIA_SDRAM

================
DEBUG: Uploading file 'C:\freetz\FRITZ.Box_7590-07.27.image.in-memory' to '0x86018400 0x88000000' ...
DEBUG: Sent
P@SW
================
DEBUG: Response:
227 Entering Passive Mode (192,168,178,1,12,24)

================
DEBUG: Sent
STOR 0x86018400 0x88000000
================
DEBUG: Response:
150 Opening BINARY data connection

================
DEBUG: Sent
SETENV memsize 0x20000000
================
DEBUG: Response:
120 Service not ready, please wait

================
DEBUG: Sent
UNSETENV kernel_args_tmp
================
DEBUG: Response:
120 Service not ready, please wait

================
DEBUG: Sent
QUIT
================
DEBUG: Response:
120 Service not ready, please wait

================
Ausnahme beim Aufrufen von "Invoke" mit 0 Argument(en):  "Error uploading image file."
In C:\freetz\EVA-FTP-Client.ps1:656 Zeichen:21
+                     $ScriptBlock.Invoke()
+                     ~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [], ParentContainsErrorRecordException
    + FullyQualifiedErrorId : RuntimeException

Was die Größe des Freetz-NG-Images angeht, ich hatte nur Wireguard hinzugefügt und den Rest so belassen...

Schon ein wenig ernüchternd wenn man an früher zurückdenkt, wie einfach es dort war Freetz auf die Boxen zu bekommen^^

Welche Alternativen habe ich jetzt noch, die jungfräuliche 7590 mit Freetz zu versehen?

 

[PeterPawn]

An ein generelles Problem mit dem Skript glaube ich nicht - dazu haben das schon zuviele Leute erfolgreich benutzt und die Datei im main-Branch hat schon lange keine Änderung mehr erfahren.

Wenn sich auch ein originales Image nicht flashen läßt, funktioniert Dein ganzes Setup nicht richtig. Du könntest es zwar mit einem anderen FTP-Client versuchen, denn die Kommandos stehen ja im Protokoll - der MS-Client kann aber keine passiven Transfers. Ich glaube da trotzdem nicht so richtig dran, sondern würde eher irgendeine Security-Suite verdächtigen, welche die Data-Connection blockiert, während die Control-Connection wohl funktioniert.

Wenn die aktuellen Einstellungen nicht wichtig sind (man kann ja auch eine Sicherung erstellen), würde ich tatsächlich mal zu den Basics gehen und das AVM-Recovery-Programm benutzen. Dessen Protokoll (dazu steht etwas in einem anderen gepinnten Thread hier irgendwo) sollte dieselben Kommandos benutzen, wie der Versuch mit dem originalen Image. Und wenn das dann auch scheitern sollte, muß man an anderen Stellen suchen.

Klappt's mit dem AVM-Programm mit identischen Kommandos, ist das ein deutliches Zeichen für ein Problem mit Firewall bzw. DPI (Deep Packet Inspection) - das sichtbare Protokoll passt auch dazu, daß die Data-Connection gar nicht zustande kommt bzw. daß da keine Daten gesendet werden, während die Box immer noch darauf wartet.

Wobei ich beim Versuch mit der geänderten Skript-Version auch mehr Nachrichten im Protokoll erwartet hätte - entweder ich liege da falsch mit der Annahme, wie der "control flow" im Skript bei Dir abläuft oder das war doch nicht die aktualisierte Version.

Vielleicht sollten wir als Erstes doch mal klären, ob da irgendwelche zusätzliche "Sicherheitssoftware" in Deinem Windows-System installiert ist und ob das AVM-Recovery-Programm funktioniert oder nicht.

Denn eigentlich ist es auch heute nicht schwieriger, ein anderes System auf einer FRITZ!Box zu installieren, als das früher der Fall war - dazu funktioniert das auch heute noch bei zu vielen Leuten. Hier kommt man eher zu der Vermutung, daß irgendetwas an Deinem Setup nicht stimmt und wenn das der Fall sein sollte, helfen Dir auch viele weitere Alternativen (soo viele gibt es ohnehin nicht) nicht - dann muß erst einmal dieses Problem ausgeräumt werden.

 

[mj084]

Moin und kurzes Update:

Es war definitiv die aktualisierte Version vom Script

Das AVM-Recovery ging gestern auch erst nachdem ich die interne Windows Firewall deaktiviert hatte, vorher brach es immer ab...

Beim neuen Test gestern war die Windows Firewall wieder aktiv :/

Habe jetzt Firewald und Defender händisch deaktiviert und teste nochmal mit dem AVM in-memory Image und deinem aktualisierten Script...

Edit:

Diesmal sieht die Ausgabe ein wenig anders aus, Image konnte ich dennoch nicht hochladen...
Box war dann in einer Bootloop und ich habe sie vom gleichen System mit dem AVM Tool wiederhergstellt...

PS C:\WINDOWS\system32> C:\freetz\EVA-FTP-Client.ps1 -Verbose -Debug -ScriptBlock { BootDeviceFromImage C:\freetz\FRITZ.Box_7590-07.27.image.in-memory }
DEBUG: Response:
220 ADAM2 FTP Server ready

================
DEBUG: Sent
USER adam2
================
DEBUG: Response:
331 Password required for adam2

================
DEBUG: Sent
PASS adam2
================
DEBUG: Response:
230 User adam2 successfully logged in

================
DEBUG: Sent
SYST
================
DEBUG: Response:
215 AVM EVA Version 1.3578 0x0 0x46409

================
DEBUG: Sent
GETENV memsize
================
DEBUG: Response:
memsize               0x20000000

200 GETENV command successful

================
DEBUG: Memory size found    : 0x20000000 (512 MB)
DEBUG: Memory size used     : 0x08000000 (128 MB)
DEBUG: Image size found     : 0x01fe7c00
DEBUG: Set memory size to   : 0x06018400
DEBUG: Set MTD RAM device to: 0x86018400,0x88000000
DEBUG: Sent
SETENV memsize 0x06018400
================
DEBUG: Response:
200 SETENV command successful

================
DEBUG: Sent
SETENV kernel_args_tmp mtdram1=0x86018400,0x88000000
================
DEBUG: Response:
200 SETENV command successful

================
DEBUG: Sent
TYPE I
================
DEBUG: Response:
200 Type set to BINARY

================
DEBUG: Sent
MEDIA SDRAM
================
DEBUG: Response:
200 Media set to MEDIA_SDRAM

================
DEBUG: Uploading file 'C:\freetz\FRITZ.Box_7590-07.27.image.in-memory' to '0x86018400 0x88000000' ...
DEBUG: Sent
P@SW
================
DEBUG: Response:
227 Entering Passive Mode (192,168,178,1,12,28)

================
DEBUG: Sent
STOR 0x86018400 0x88000000
================
DEBUG: Response:
150 Opening BINARY data connection

================
DEBUG: Sent
SETENV memsize 0x20000000
================
DEBUG: Sent
UNSETENV kernel_args_tmp
================
DEBUG: Sent
QUIT
================
Ausnahme beim Aufrufen von "Invoke" mit 0 Argument(en):  "Error uploading image file."
In C:\freetz\EVA-FTP-Client.ps1:656 Zeichen:21
+                     $ScriptBlock.Invoke()
+                     ~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [], ParentContainsErrorRecordException
    + FullyQualifiedErrorId : RuntimeException

 

[PeterPawn]

Wie sieht die ftp.log vom Recovery-Programm aus?

---

Wenn das garantiert die geänderte Version ist, dann bleibt - angesichts des Protokolls - eigentlich nur noch die Erklärung, daß die PowerShell nicht aktualisiert wurde und in einer zu alten Version vorliegt, um das verwendete CopyToAsync() (https://github.com/PeterPawn/YourFr...60b19387370/eva_tools/EVA-FTP-Client.ps1#L398) zu kennen - dann geht es auch direkt nach dem STOR-Kommando ins Exception-Handling (was dann auch dazu paßt, daß der Control-Flow offenbar ein ganz anderer ist, als ich ihn erwartete).

Welche Versionen erforderlich sind, steht im Skript und die Aufforderung, dafür eine aktuelle PS-Version (inkl. passender .NET-Runtime) zu verwenden, steht im Thread mit der Beschreibung, wie man diese Dateien benutzen kann: https://www.ip-phone-forum.de/threa...kript-dateien-aus-yourfritz-eva_tools.298591/

Wer die PowerShell-Skripte verwenden möchte, sollte als erstes mal seine PowerShell-Installation (gerade auch dann, wenn er - wie ich - immer noch gerne auf einem Windows 7 arbeitet) auf den aktuellen Stand bringen ... die Minimal-Anforderungen für die PowerShell-Version stehen in "EVA-FTP-Client.ps1" (ab Zeile 360 im Moment) und können jederzeit auf dem eigenen System durch die Eingabe von "$PSVersionTable" in einer PowerShell-Session abgefragt werden.

 

[mj084]

Wollen wir das ganze hier vielleicht mal vom ursprünglichen Thread abspalten?

ftp.log:

0:04:831: 2.01 gitbuild:1038875
0:04:831: Registry: SYSTEM\CurrentControlSet\Services\TcpIp\Parameters\DisableDHCPMediaSense=0
0:04:831: recover-firmware-id:        226
0:04:831: recover-firmware-version:    de-en-es-it-fr-pl-nl.154.07.27
0:05:143: check adapter(Realtek PCIe GBE Family Controller) adapter 0xd: Ip: 0.0.0.0(0.0.0.0) (static)
0:05:143: get ipaddress from registry 192.168.178.32
0:05:143: compatible ipaddress (static) found: 192.168.178.32 on adapter 0xd
0:05:159: search on addr: 192.168.178.1
1:05:643: search on addr: 192.168.178.1
1:08:275: ---> read environment <---
1:08:384: open ftp 192.168.178.1 port 21
1:08:384: recv: 220 ADAM2 FTP Server ready
1:08:384: send: USER adam2
1:08:384: recv: 331 Password required for adam2
1:08:384: send: PASS adam2
1:08:384: recv: 230 User adam2 successfully logged in
1:08:384: send: SYST
1:08:384: recv: 215 AVM EVA Version 1.3578 0x0 0x46409
1:08:400: send: TYPE I
1:08:400: recv: 200 Type set to BINARY
1:08:400: send: MEDIA SDRAM
1:08:400: recv: 200 Media set to MEDIA_SDRAM
1:08:400: send: P@SW
1:08:400: recv: 227 Entering Passive Mode (192,168,178,1,12,2)
1:08:400: open ftp data 192.168.178.1 port 3074
1:08:400: send: RETR env
1:08:400: recv: 150 Opening BINARY data connection
1:08:494: recv: 226 Transfer complete
1:08:603: environment successfully read(1397 bytes)
1:08:603: send: USER adam2
1:08:603: recv: 331 Password required for adam2
1:08:603: send: PASS adam2
1:08:603: recv: 230 User adam2 successfully logged in
1:08:603: send: SYST
1:08:603: recv: 215 AVM EVA Version 1.3578 0x0 0x46409
1:08:603: send: TYPE I
1:08:603: recv: 200 Type set to BINARY
1:08:603: send: MEDIA SDRAM
1:08:603: recv: 200 Media set to MEDIA_SDRAM
1:08:603: send: P@SW
1:08:603: recv: 227 Entering Passive Mode (192,168,178,1,12,18)
1:08:603: open ftp data 192.168.178.1 port 3090
1:08:603: send: RETR count
1:08:603: recv: 150 Opening BINARY data connection
1:08:665: recv: 226 Transfer complete
1:08:778: environment successfully read(152 bytes)
1:08:778: send: BYE
1:08:778: recv: 221 Thank you for using the FTP service on ADAM2
1:08:780:     hardware-revision:    226
1:08:780:     firmware-version:    154.07.27
1:08:780:     urloader-version:    1.3578
1:08:780:     oem:    1und1
1:08:780:     provider:   
1:09:409: set defaultsettings mtdnand (size: 2084)
1:09:409: ---> write image (mtdnand) <---
1:09:522: open ftp 192.168.178.1 port 21
1:09:522: recv: 220 ADAM2 FTP Server ready
1:09:537: send: USER adam2
1:09:537: recv: 331 Password required for adam2
1:09:537: send: PASS adam2
1:09:537: recv: 230 User adam2 successfully logged in
1:09:537: send: SYST
1:09:537: recv: 215 AVM EVA Version 1.3578 0x0 0x46409
1:09:537: send: TYPE I
1:09:537: recv: 200 Type set to BINARY
1:09:537: send: MEDIA FLSH
1:09:537: recv: 200 Media set to MEDIA_FLASH
1:09:537: send: P@SW
1:09:537: recv: 227 Entering Passive Mode (192,168,178,1,12,4)
1:09:537: open ftp data 192.168.178.1 port 3076
1:09:537: clear flash-partition (mtdnand)
1:09:928: send: STOR mtdnand
1:09:928: recv: 150 Opening BINARY data connection
1:09:928: flash clear (mtdnand) ok : now send image
1:10:037: update flash-partition (mtdnand)
1:10:053: send image (size=2084) for mtd8
1:10:787: recv: 226 Transfer complete
1:10:787: flash write (mtd8) ok
1:10:912: successfully update of mtd8
1:10:912: send: BYE
1:10:912: recv: 221 Thank you for using the FTP service on ADAM2
1:13:147: nand: load filesystem and kernel image to RAM (size: 33455104)
1:13:147: ---> read environment <---
1:13:256: open ftp 192.168.178.1 port 21
1:13:256: recv: 220 ADAM2 FTP Server ready
1:13:256: send: USER adam2
1:13:256: recv: 331 Password required for adam2
1:13:256: send: PASS adam2
1:13:256: recv: 230 User adam2 successfully logged in
1:13:272: send: SYST
1:13:272: recv: 215 AVM EVA Version 1.3578 0x0 0x46409
1:13:272: send: TYPE I
1:13:272: recv: 200 Type set to BINARY
1:13:272: send: MEDIA SDRAM
1:13:272: recv: 200 Media set to MEDIA_SDRAM
1:13:272: send: P@SW
1:13:272: recv: 227 Entering Passive Mode (192,168,178,1,12,10)
1:13:272: open ftp data 192.168.178.1 port 3082
1:13:272: send: RETR env
1:13:272: recv: 150 Opening BINARY data connection
1:13:366: recv: 226 Transfer complete
1:13:475: environment successfully read(1321 bytes)
1:13:475: send: BYE
1:13:475: recv: 221 Thank you for using the FTP service on ADAM2
1:13:475: ramload: savekernel activ for NAND
1:13:475: ---> write image mtd1 mtd1-base/size(500000/800000)ram-base/size(80000000/8000000) SquashFS(offset=0x600c00 - 25.902 MiB) <---
1:13:584: open ftp 192.168.178.1 port 21
1:13:600: recv: 220 ADAM2 FTP Server ready
1:13:600: send: USER adam2
1:13:600: recv: 331 Password required for adam2
1:13:600: send: PASS adam2
1:13:600: recv: 230 User adam2 successfully logged in
1:13:600: send: SYST
1:13:600: recv: 215 AVM EVA Version 1.3578 0x0 0x46409
1:13:600: send: SETENV memsize 0x600f400
1:13:600: recv: 200 SETENV command successful
1:13:600: send: SETENV kernel_args_tmp mtdram1=0x8600f400,0x88000000
1:13:600: recv: 200 SETENV command successful
1:13:600: send: TYPE I
1:13:600: recv: 200 Type set to BINARY
1:13:600: send: MEDIA SDRAM
1:13:600: recv: 200 Media set to MEDIA_SDRAM
1:13:600: send: P@SW
1:13:600: recv: 227 Entering Passive Mode (192,168,178,1,12,20)
1:13:600: open ftp data 192.168.178.1 port 3092
1:13:600: RAM-Load Image to 8600f400 Filesystem: 86610000
1:13:600: send: STOR 0x8600f400 0x88000000
1:13:600: recv: 150 Opening BINARY data connection
1:13:600: now send image mtd1 to ram
1:13:616: send image (size=33455104) for mtd1
1:47:659: recv: 226 Transfer complete
1:47:659: load to ram (mtd1) ok
2:23:362: ----EOF---

$PSVersionTable

Name                           Value
----                           -----
PSVersion                      5.1.19041.1023
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.19041.1023
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

Microsoft .NET Framework-Anforderungen

In der folgenden Tabelle finden Sie die .NET Framework-Anforderungen für Windows PowerShell.
Version .NET-Anforderung
Windows PowerShell 5.1 Erfordert die vollständige Installation von Microsoft .NET Framework 4.5. Windows 8.1 und Windows Server 2012 R2 enthalten standardmäßig Microsoft .NET Framework 4.5.

.NET Framework 4.5 Ist unter Windows 10 21H1 schon fester Bestandteil...

Sehr merkwürdig das ganze hier...

 

[stoney]

Wollen wir das ganze hier vielleicht mal vom ursprünglichen Thread abspalten?

Die Entscheidung liegt bei Dir - die Umsetzung dann an einem Mod, wenn Du diesem verrätst, wie Dein Thread heißen soll, verschiebe bzw lagere ich gerne aus.

 

[PeterPawn]

Das hier:

1:13:616: send image (size=33455104) for mtd1
1:47:659: recv: 226 Transfer complete

ist für meine Begriffe auch eine ganz schön lange Zeit - 34 Sekunden für den Upload von ca. 34 MB (mal gerundet, weil es sich besser rechnet) sind nur 1 MByte/Sekunde ... deutlich unterhalb von 1 Gbit/s, eher bei 10 Mbit/s. Wenn das nicht noch eine "vergessene" Festlegung der Geschwindigkeit durch Dich selbst ist, solltest Du vielleicht auch mal ein anderes Kabel verwenden oder doch einen Switch zwischen Box und PC. Von dem bisher genutzten Aufbau wissen wir m.E. bisher noch nichts, oder?

Ansonsten stimmen die Speicheradressen beim Recovery-Programm auch nur "ungefähr" - war das tatsächlich die Version 07.27? Wenn ja, frage ich mich wieder, wo die Größendifferenz des Images wohl herkommen mag. Die ist zwar nicht gewaltig, aber das dort geladene Image ist auch schon deutlich größer (nämlich 36.864 Byte) als das Image, was Du mit image2ram selbst aus der 07.27 erstellt hast.

---

Das mit dem Abspalten wäre natürlich auch eine Idee ... die bisher noch ungeklärte Frage ist halt, ob es an den Skript-Files liegt (dann ist es hier auch richtig, wobei sicherlich nicht image2ram das eigentliche Problem darstellt) oder doch eher an Deinem Setup (wozu ich nun mal stark tendiere) und dann ist es wohl in einem eigenen Thread doch besser aufgehoben. Ab #12 sollte dann abgetrennt werden, aber bis zur endgültigen Sicherheit, daß es NICHT an den Skript-Files liegt (auch wenn EVA-Discover.ps1 und EVA-FTP-Client.ps1 ihren eigenen Thread haben - zusammen mit den Linux-Pendants), kann man das ja auch hier noch fortführen.

---

Denn es gibt noch so einiges, was ich nicht verstehe ... es gibt für mich gar keinen (plausiblen) Weg, wie man mit einem (nicht erfolgreichen) BootDeviceFromImage zu einem Ergebnis wie diesem gelangen könnte:

ich bekomme das in-memory Image nicht vollständig hochgeladen und zerschiesse mir dabei die Box...

- man KANN sich nach meinem Wissensstand auf diesem Weg die Box gar nicht "zerschiessen", denn wenn kein Image geladen werden kann, kann es auch nicht gestartet werden und dann schreibt da auch nichts und niemand irgendetwas in den Flash-Speicher. Wie kann da also eine Box "zerschossen" werden?

---

Ich bastele mal noch etwas an einer "Spezialvariante" von EVA-FTP-Client.ps1 - die ursprüngliche Idee war aber dort auch, den Nutzer nicht mit zuvielen Infos zu erschlagen (zum "Ablauf"), die in den allermeisten Fällen ohnehin nur dieselben Ausgaben zur Folge hätten, wenn alles glatt läuft. Daher gibt es eben ein "Image upload failed" und nicht noch für jeden Step innerhalb dieser Funktion eine eigene Meldung zum Voranschreiten der Verarbeitung. Da ich die Änderungen diesmal auch selbst testen will und erst mal den Versuchsaufbau herstellen muß, dauert das mit den Änderungen noch bis in die Nacht hinein.

 

[mj084]

@PeterPawn

Ja, der Netzwerkadapter am Lenovo G50 (Windows 10 21H1) steht noch auf 10 Mbit/s Vollduplex - ich bin direkt am ersten LAN-Port der 7590 mit dem G50 verbunden...

Es war definitiv das 07.27 Recovery-Programm "FRITZ.Box_7590-07.27-recover.exe" - dieses funktionierte ja auch erst nach Deaktivieren der internen Firewall...

Welche Größe hat denn das in-memory Image der 07.27 der 7590 bei dir - vielleicht ist ja hier schon was schief gegangen...

Mit "Zerschiessen" meine ich übrigens nur, dass sie nicht mehr sauber bootet, sondern in einer Bootloop hängt - habe sie die letzten beiden Tage jetzt schon 3x "recovered"

Edit: 4x mal recovered^^

 

[stoney]

Boote W10 doch einfach im abgesicherten Modus mit Netzwerk, dann sollte das doch "fluppen".

 

[PeterPawn]

Mit "Zerschiessen" meine ich übrigens nur, dass sie nicht mehr sauber bootet, sondern in einer Bootloop hängt

Auch das ist nicht logisch bzw. kaum nachvollziehbar (bei "normalem" Verlauf) ... wieso sollte ein vollkommen in die Hose gegangener Startversuch mit einem eigenen Image die Box in eine Boot-Schleife schicken? Da passiert mal genau gar nichts, solange das hochgeladene Image nicht gestartet wird/werden kann ... einfach den Stecker erneut ziehen und wieder einstecken (weil ansonsten die temporären Änderungen der Speichergröße zum Problem werden - die werden ja nach dem Protokoll nicht wieder zurückgesetzt, weil die Box "busy" ist - siehe die 120 als Antwort) und die Box sollte ganz normal das zuvor installierte System booten.

Wenn das TATSÄCHLICH zu einer Situation führt, wo nur noch die Anwendung des Recovery-Programms möglich ist, dann ist da irgendetwas vollkommen anderes noch faul.

Denn eigentlich sind schon Deine Erfahrungen mit dem Recovery-Programm sehr, sehr ungewöhnlich - wenn man das nicht zuvor schon x-mal benutzt hat (und zwar genau diese eine Version) und dabei die Firewall eben NICHT RICHTIG eingestellt hat (wie das Recovern richtig funktioniert, steht auch in irgendeinem gepinnten Thread von mir), dann sollte das bei seiner ersten Verwendung ganz brav nach der Erlaubnis zum Ändern der Firewall-Einstellungen fragen und dann braucht man die (Windows-)Firewall auch nicht komplett zu deaktivieren. Und für EVA-FTP-Client.ps1 sollte die Firewall eigentlich auch KEINE Rolle spielen ... denn da werden nur ausgehende Verbindungen benutzt und die sind normalerweise in der Windows-Firewall auch erlaubt.

Bisher waren es immer irgendwelche zusätzlichen "Security-Suiten", die da verrückt gespielt haben ... einige, weil sie unbedingt auch in die FTP-Data-Connection "hineinsehen" wollen und mit dem Format des STOR-Kommandos im Control-Channel nicht klar kommen und andere stören sich dann wieder daran, wenn das Gerät mit der IP-Adresse 192.168.178.1 plötzlich die MAC-Adresse wechselt, nur weil man zuvor irgendeine andere Box auf dieser Adresse angesprochen hatte.

Wenn es die berichteten Probleme mit dem Notebook GENAU SO gibt, dann solltest Du dessen Netzwerk-Konfiguration einfach mal wieder "glattziehen" ... das Festtackern auf 10 Mbit/s ist Unfug, wie ich weiter vorne versucht habe zu erklären und ich kann mir auch noch vorstellen, daß aus irgendeinem Grund hier für die Data-Connection ein nicht richtig deaktivierter WLAN-Adapter verwendet werden könnte (Dein G50 wird ja sicherlich auch WLAN "sprechen"), falls der tatsächlich eine IP-Adresse aus demselben Subnetz haben sollte, wie der LAN-Anschluß. Auch da käme dann keine Data-Connection zustande - das AVM-Programm dürfte sich dadurch "retten", daß es gezielt den - von ihm selbst ausgesuchten, siehe ftp.log - Adapter für die Data-Connection vorgibt.

 

[mj084]

So, ich habe das Netzwerk am G50 zurückgesetzt, das Ergebnis bleibt das Gleiche - es ist auch keine SecuritySuite oder sonstiges Schlangenöl installiert...

Habe jetzt ein anderes Notebook (ebenfalls Win10 21H1) mit abgesicherten Modus mit Netzwerktreibern verwendet:

PS C:\Users\XYZ> C:\freetz\EVA-FTP-Client.ps1 -Verbose -Debug -ScriptBlock { BootDeviceFromImage C:\freetz\FRITZ.Box_7590-07.27.image.in-memory }
Error connecting to remote host
Ausnahme beim Aufrufen von ".ctor" mit 2 Argument(en):  "Es konnte keine Verbindung hergestellt werden, da der Zielcomputer die Verbindung verweigerte 192.168.178.1:21".
PS C:\Users\Martin> C:\freetz\EVA-FTP-Client.ps1 -Verbose -Debug -ScriptBlock { BootDeviceFromImage C:\freetz\FRITZ.Box_7590-07.27.image.in-memory }
DEBUG: Response:
220 ADAM2 FTP Server ready

================
DEBUG: Sent
USER adam2
================
DEBUG: Response:
331 Password required for adam2

================
DEBUG: Sent
PASS adam2
================
DEBUG: Response:
230 User adam2 successfully logged in

================
DEBUG: Sent
SYST
================
DEBUG: Response:
215 AVM EVA Version 1.3578 0x0 0x46409

================
DEBUG: Sent
GETENV memsize
================
DEBUG: Response:
memsize               0x20000000

200 GETENV command successful

================
DEBUG: Memory size found    : 0x20000000 (512 MB)
DEBUG: Memory size used     : 0x08000000 (128 MB)
DEBUG: Image size found     : 0x01fe7c00
DEBUG: Set memory size to   : 0x06018400
DEBUG: Set MTD RAM device to: 0x86018400,0x88000000
DEBUG: Sent
SETENV memsize 0x06018400
================
DEBUG: Response:
200 SETENV command successful

================
DEBUG: Sent
SETENV kernel_args_tmp mtdram1=0x86018400,0x88000000
================
DEBUG: Response:
200 SETENV command successful

================
DEBUG: Sent
TYPE I
================
DEBUG: Response:
200 Type set to BINARY

================
DEBUG: Sent
MEDIA SDRAM
================
DEBUG: Response:
200 Media set to MEDIA_SDRAM

================
DEBUG: Uploading file 'C:\freetz\FRITZ.Box_7590-07.27.image.in-memory' to '0x86018400 0x88000000' ...
DEBUG: Sent
P@SW
================
DEBUG: Response:
227 Entering Passive Mode (192,168,178,1,12,6)

================
DEBUG: Sent
STOR 0x86018400 0x88000000
================
DEBUG: Response:
150 Opening BINARY data connection

================
DEBUG: Sent
SETENV memsize 0x20000000
================
DEBUG: Sent
UNSETENV kernel_args_tmp
================
DEBUG: Sent
QUIT
================
Ausnahme beim Aufrufen von "Invoke" mit 0 Argument(en):  "Error uploading image file."
In C:\freetz\EVA-FTP-Client.ps1:656 Zeichen:21
+                     $ScriptBlock.Invoke()
+                     ~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [], ParentContainsErrorRecordException
    + FullyQualifiedErrorId : RuntimeException

Ich werde jetzt das Ganze mal mit de Backupbox 7490 probieren, erstmal mit dem in-memory Image der originalen Firmware und falls das wider Erwarten klappen sollte, mit nem Freetz Image^^

EDIT: mit der 7490 genau das Gleiche:/

 

[PeterPawn]

Es gibt eigentlich nur zwei Möglichkeiten, das Verhalten besser zu verstehen ... entweder man baut in das Skript zusätzliche Ausgaben ein (das könntest Du ggf. genauso wie ich) oder man schneidet hier dann doch einmal den Netzwerk-Verkehr zwischen dem PC und der FRITZ!Box (mit passendem Recording-Filter, damit auch wirklich nur diese Pakete aufgezeichnet werden) mit - im Moment hängt jedenfalls mein Verständnis daran, ob nun überhaupt eine Data-Connection aufgebaut werden kann und welche/wieviele Daten dabei am Ende übertragen werden. Wenn die TCP-Session für die Data-Connection zustande kommt, müßte sich beim Speichern der in dieser Connection übertragenen Daten (das kann Wireshark gut darstellen) ja 1:1 das gleiche binäre Abbild ergeben, wie es auch in der verwendeten Image-Datei zu finden ist.

Wenn Du nicht doch auf andere Systeme ausweichen willst (Linux wäre ja noch eine Option), muß man erst einmal die Ursache finden, warum das bei Dir so merkwürdig abläuft ... wobei ich auch nachher noch einmal einen Test mit dem AVM-Image und meiner 7580 machen will (eine 7590 habe ich gerade nicht im Zugriff bzw. da kann ich nicht mal so im Handumdrehen irgendwelche Experimente machen), ob der FTP-Client bei mir auch unter einen voll gepatchten W10 noch funktioniert.

Andererseits ist die originale Datei im main-Branch ja seit drei Jahren unverändert und wird in dieser Form auch häufig genutzt - zuletzt "gemeldet" hat sich bzgl. dieser Datei z.B. auch @WileC, als es um sein Skript ging, das die PS-Files zusammenfügt: https://github.com/WileC/FreetzTheBox - das war aber auch der andere Fall, wo es zu einer Fehlermeldung beim Upload kam, während die Übertragung dann wohl doch geklappt hatte.

Deshalb ist es praktisch unumgänglich zu verstehen, ob hier eine Verbindung zustande kommt und wie danach die Datenübertragung genau läuft (oder eben auch nicht). So ganz sicher läßt sich natürlich auch eine Änderung an der PowerShell nicht ausschließen - die käme dann bei den W10-Benutzern halt über irgendein Update herein. Wie gesagt ... ich versuche, mir das auch selbst anzusehen, weil ich (bei zwei Meldungen) auch nicht vollkommen ausschließen will, daß die Skripte wg. irgendeines Timings nicht mehr genau so funktionieren, wie das zuvor der Fall war.

Wenn Du "Vorlauf" haben willst, solltest Du mal Wireshark anwerfen und den Datenverkehr mit der Box mitschneiden, wenn Du nicht doch auf Linux wechseln willst (was dann ja auch das Windows und die PowerShell aus dem Spiel nimmt).

 

[PeterPawn]

Und by the way ... bitte melde die Beiträge ab #12 jetzt doch mal zum Abtrennen (damit würde das dann auch "Dein Thread"), denn mittlerweile hat es wirklich nichts mehr mit image2ram zu tun - letztlich ist nicht mal mehr das OS dasselbe. Dieser Beitrag hier kann dann auch gleich mit entsorgt werden (deshalb schon abgetrennt von mir).

 

[mj084]

Für mich hat eigentlich der Upload von freetz mit Wireguard Prio - ich wollte am Wochenende eigentlich die entfernte 7490 ebenso mit freetz bestücken...

Denke ich werde morgen mal ein DualBoot mit Ubuntu installieren...

 

[mj084]

@stoney

Bitte mal ab #12 abtrennen und den neuen Thread "in-memory Image lässt sich nicht mit EVA-FTP-Client.ps1 auf 7590 hochladen"

Danke

 

[PeterPawn]

Zwischenstand: Ich konnte das mittlerweile auch mit der 07.27 für die 7580 nachstellen ... die Box braucht (wie schon an anderer Stelle vermutet) zu lange, um nach dem Ende der Übertragung (und dem Flushen aller Buffer durch Schließen aller relevanten Objekte) die 226-Message auch zu senden. Ein komplizierteres Warten auf diese Meldung (oder irgendeine andere, denn es kommt da offensichtlich nach den bisher verwendeten fünf Sekunden noch gar keine Reaktion) braucht noch etwas von meiner Seite - das muß ich dann erst mal selbst gründlich testen.

In einem ersten Versuch hat der Upload aber auch wieder funktioniert, als ich - als "quick & dirty"-Ansatz - die Zeit in Zeile 407 auf 10 Sekunden angehoben hatte. Das kann auch jeder selbst dort editieren, damit sollte auch bei der 07.27 bei den GRX-Boxen kein "falsches Timeout" mehr auftreten (ansonsten noch mal mit 15 Sekunden probieren, aber auch nicht ins Unendliche verlängern). Das ist mir als echte Lösung aber zu dünn - das hatte ich hier: https://www.ip-phone-forum.de/threa...n-aus-yourfritz-eva_tools.298591/post-2434824 ja schon mal geschrieben. Das Warten kann man dann "smarter" machen - einfach in 1 Sekunden-Intervallen pollen, ob mittlerweile etwas passiert ist, anstatt einfach stumpf die Zeit zu erhöhen - das gilt dann ja auch nicht nur für die Boxen, wo das notwendig ist, sondern für alle. Das ist also für mich keine (dauerhafte) Lösung.

Ob das Anheben der Wartezeit auch bei Dir hilft, mußt Du selbst testen ... bei mir gab es auch im Fehlerfall keine 120-Messages und es wurde sogar das SETENV-Kommando beim Zurücksetzen der Speichergröße noch sauber ausgeführt:

[...]
DEBUG: Sent
P@SW
================
DEBUG: Response:
227 Entering Passive Mode (192,168,178,1,12,10)

================
DEBUG: Sent
STOR 0x860ef100 0x88000000
================
DEBUG: Response:
150 Opening BINARY data connection

================
DEBUG: Sent
SETENV memsize 0x20000000
================
DEBUG: Sent
UNSETENV kernel_args_tmp
================
DEBUG: Response:
226 Transfer complete
200 SETENV command successful
501 environment variable not set

================
DEBUG: Sent
QUIT
================
DEBUG: Response:
221 Thank you for using the FTP service on ADAM2
221 Goodbye.

================

- das sieht also bei meiner 7580 auch im Fehlerfall noch anders aus, als in Deinen Protokollen oben. Daher würde ich mich noch nicht darauf verlegen wollen, daß ein Erhöhen der Wartezeit auch bei Dir helfen sollte.

---

Offensichtlich tritt das Problem aber auch erst seit 07.24 (oder ggf. sogar noch höher, das werde ich mal versuchen einzukreisen) überhaupt auf ... eine 07.21 kann ich problemlos mit 5 Sekunden Wartezeit aus dem Speicher der 7580-Box starten lassen. Nach meiner Ansicht kann der Bootloader ohnehin erst nach dem Ende der Übertragung (wenn er alle Daten aus der Verbindung in seinem RAM hat) mit dem Entpacken des Kernels beginnen und erst wenn der sich auch entpacken ließ, weiß er genug über die hochgeladenen Daten, um sich zwischen 226 Transfer complete (mit anschließendem Start des entpackten Kernels) und 553 Execution failed zu entscheiden. Vielleicht sind am Ende auch die GRX-Boxen mit ihren zwei Kernel-Images dafür verantwortlich, daß das Entpacken dort länger braucht, als die bisher verwendeten (festen) fünf Sekunden.

Egal was letztlich das Problem ist ... ich werde das Warten nach dem Upload auf das erwähnte 1-Sekunden-Polling umstellen und eine max. Wartezeit als Parameter hinzufügen - irgendwann muß das Skript ja auch mal zum Ende kommen, falls da gar nichts mehr in der Control-Connection geantwortet wird.

 

[mj084]

Kurzes Update von hier:

Habe heute Nacht auf dem G50 noch Ubuntu 20.04 LTS via DualBoot installiert und mir eine freetz Buildumgebung erstellt - konnte dann auch via push_firmware das erstelle freetz Image problemlos auf beide Boxen spielen

Stehe für weitere Tests unter Windows aber gerne zur Verfügung...