[Gelöst] Newbie Problem mit Übertragen des Image

[blackhearted]

Hallo zusammen,
ich bin absoluter Newbie auf dem Gebiet Freetz-NG und Linux. Ich habe für meine 7530 ein Image erzeugt.
Wenn ich das Image dann mit Eva-FTP_Client auf die Box schieben will kommt immer ein Fehler. Was mache ich falsch? Anbei was angezeigt wird.
Über Lösungen würde ich mich sehr freuen.

Viele Grüße

PS C:\YourFritz\master\eva_tools> .\EVA-Discover.ps1 -maxWait 120 -Debug -Verbose
DEBUG: Using local IPv4 address 192.168.178.20 ...
AUSFÜHRLICH: Sending discovery packet (1) ...
AUSFÜHRLICH: Sending discovery packet (2) ...
AUSFÜHRLICH: Sending discovery packet (3) ...
AUSFÜHRLICH: Sending discovery packet (4) ...
AUSFÜHRLICH: Sending discovery packet (5) ...
AUSFÜHRLICH: Sending discovery packet (6) ...
AUSFÜHRLICH: Sending discovery packet (7) ...
AUSFÜHRLICH: Sending discovery packet (8) ...
AUSFÜHRLICH: Sending discovery packet (9) ...
AUSFÜHRLICH: Sending discovery packet (10) ...
AUSFÜHRLICH: Sending discovery packet (11) ...
DEBUG: Received UDP packet from 192.168.178.1:5035 ...
AUSFÜHRLICH: Found EVA loader at 192.168.178.1 ...
AUSFÜHRLICH: Trying to connect to the FTP port to hold up the device in bootloader ...
DEBUG: Error during FTP connection attempt ...
EVA_IP=192.168.178.1
True
PS C:\YourFritz\master\eva_tools> .\EVA-FTP-Client.ps1 -Verbose -Debug -ScriptBlock { BootDeviceFromImage .\fritzbox.image }
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.3584 0x0 0x46409

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

200 GETENV command successful

================
DEBUG: Memory size found : 0x10000000 (256 MB)
DEBUG: Memory size used : 0x08000000 (128 MB)
DEBUG: Image size found : 0x01eb6800
DEBUG: Set memory size to : 0x06149800
DEBUG: Set MTD RAM device to: 0x86149800,0x88000000
DEBUG: Sent
SETENV memsize 0x06149800
================
DEBUG: Response:
200 SETENV command successful

================
DEBUG: Sent
SETENV kernel_args_tmp mtdram1=0x86149800,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 '.\fritzbox.image' to '0x86149800 0x88000000' ...
DEBUG: Sent
P@SW
================
DEBUG: Response:
227 Entering Passive Mode (192,168,178,1,12,0)

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

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

 

[waldoo]

die Firewall hast du auf alle Fälle aus?

>> DEBUG: Error during FTP connection attempt ...
Das 2. Kommando bringt nichts, wenn das 1. schon einen Fehler bringt

 

[blackhearted]

Das hab ich mir auch eigentlich gedacht. Windows Firewall ist aus.

 

[PeterPawn]

Vermutlich wieder ein Timeout - die Firewall sollte man gar nicht erst anfassen bzw. keinesfalls deaktivieren (das ist nicht erforderlich, wenn es tatsächlich nur die Windows-Firewall gibt).

Warum die FTP-Verbindung im Discovery-Skript nicht funktioniert, kann man nicht sehen - das ist allerdings merkwürdig, daß hier überhaupt ein Problem auftritt. Denn eigentlich erfolgt da nichts anderes als ein Login mit anschließendem, umgehenden Logout - da kann fast nichts schiefgehen, wenn die Box zuvor gefunden wurde und nichts anderes (wie irgendeine andere Security-Suite, die FTP-Sessions als ALG überwachen will) im Wege steht.

Danach ist das ja auch offensichtlich nicht mehr der Fall - der FTP-Dialog beim Upload sieht an sich gut aus, nur kommt aus irgendeinem Grund innerhalb der definierten Wartezeit (https://github.com/PeterPawn/YourFr...4abc720f1f2/eva_tools/EVA-FTP-Client.ps1#L407) keine Rückmeldung von der Box. Hier kann man (versuchsweise) die Zeit (es sind Millisekunden) mal deutlich erhöhen (ich würde mit 15 Sekunden beginnen) - ggf. hat sich das Problem dann schon erledigt. Denn die Box ist offensichtlich noch beschäftigt - auf die Versuche, die Änderungen im Environment wieder rückgängig zu machen (damit nicht mit jedem weiteren Versuch der verfügbare Speicher immer kleiner wird), gibt es seitens der Box gar keine Reaktion(en) mehr.

Ich war mal an einer geänderten Version dran, die das Timeout-Problem besser regeln sollte (https://github.com/PeterPawn/YourFritz/blob/eva_tools_ps/eva_tools/EVA-FTP-Client.ps1 - im Branch eva_tools_ps) - aber die ist nicht komplett ausgetestet und hat es daher nie in dem main-Branch geschafft. Aber man kann die durchaus auch mal probieren anstelle der älteren Version - ich werde da nicht so schnell zu kommen und vor allem habe ich nicht genug Geräte, die länger als die bisher definierten 5 Sekunden brauch(t)en.

 

[NDiIPP]

War bei einer 7530 nicht eine zusätzliche 0 notwendig?
C:\YourFritz\master\eva_tools> .\EVA-FTP-Client.ps1 -Verbose -Debug -ScriptBlock { BootDeviceFromImage .\fritzbox.image 0 }

 

[Master SaMMy]

Ja 7520, 7530 und FRITZ!Repeater 3000 sind IPQ4019-Modelle daher brauchen sie die 0 am Ende

 

[PeterPawn]

So genau hatte ich gar nicht hingesehen ... diese zusätzliche 0 dürfte dazu führen, daß der verfügbare Hauptspeicher beim Upload nicht auf 128 MB reduziert wird, wie das bei GRX5-Boxen (wg. des "bootcore"-Kernels, der an einer fixen Adresse darüber liegen will) notwendig ist und aus irgendwelchen Gründen auch bei VR9 schon so von AVM praktiziert wurde (wobei ich hier den Grund bisher nie wirklich verstanden habe, ich gehe mal von irgendwelchem "memory-mapped I/O" auf den oberen Adressen aus, wo ein Adressbereich ansonsten vom Image im RAM blockiert würde).

 

[blackhearted]

Hab das ganze auch mit der 0 getestet. Gleiches Ergebnis.
Was interessant war. Als ich danach wieder auf fritz.box gegangen bin kam die Nachricht das ein Update auf FritzOS 7.29 gemacht wurde. Keine Ahnung warum.

Ich mach Schluss für heute.

Allen einen guten Rutsch

 

[blackhearted]

So. Problem war vermutlich eine zu alte Version von Powershell.

Jetzt ist mir aufgefallen, dass ich ja ein image.in-memiry brauche. In freetz bekomme ich nur eine normale Image Datei. Nicht aber die in memory.

Was muss ich da einstellen?

 

[B612]

Was muss ich da einstellen?

Das weiß ich nicht ob das geht. Man kann es aber einfach hinterher mit Peters image2ram erzeugen.

 

[Master SaMMy]

Wenn wer es image2inmemory

 

[B612]

Es geht beides. Siehe hier:

[HowTo] - Wie erstell ich aus einem .image ein .inmemory

Dies funktioniert mit allen Images, also von AVM, Freetz, modfs, Freetz-NG, ... aus push-firmware tar xf DAS.image for f in ./var/tmp/kernel.image ./var/tmp/filesystem.image; do FREETZVERZEICHNIS/tools/tichksum -r $f >/dev/null dd if=$f bs=256 conv=sync 2>/dev/null done > NEUES.inmemory...

www.ip-phone-forum.de

 

[blackhearted]

Ich hab's geschafft. Danke