[Info] Wie verwende ich denn nun die Skript-Dateien aus YourFritz/eva_tools?

[PeterPawn]

wenn nicht schon das erste Powershell-Skript nicht das tut, was es soll.

Ich habe das auch beim ersten Mal schon zur Kenntnis genommen ... wobei ich auch nicht weiß, wie ich Dir bei der dürren Faktenlage da helfen soll.

Du bist jedenfalls (meines Wissens) der Erste, der sich hier meldet und bekundet, daß bei ihm die Skript-Dateien (trotz korrekter Handhabung) überhaupt nicht funktionieren. Ich habe zwar gerade auch keine W10-Home-Edition zur erneuten Kontrolle zur Hand, aber wenn ich mich richtig erinnere, habe ich das sogar mit dieser Windows-Version getestet und keine Probleme festgestellt ... mal abgesehen von den "üblichen Verdächtigen", angefangen bei Firewalls aus irgendwelchen "Security-Suites" (die auch bei "abgeschaltet" eben nicht wie erwartet alles durchlassen und das eher als "alles blockieren" interpretieren) bis hin zu hin zu einem vergessenen "unblock" für die Skript-Datei, obwohl man die "execution policy" auf "RemoteSigned" gestellt hat und aus dem Netz geladene Dateien dann das "Stigma" tragen, daß sie von "remote" kommen. Die (nachträgliche) Bearbeitung mit irgendeinem falschen Editor hatten wir hier auch schon, genauso wie Fehler beim Download der Skript-Dateien, bei denen am Ende irgendwelche HTML-Seiten anstelle des eigentlichen Skripts gespeichert und als PowerShell-Skript ausgeführt wurden.

Wie soll man also aus Deiner Beschreibung oben erkennen können, was Du genau ausgeführt hast und mit welchem Ergebnis? Du hattest schließlich auch die Bitte geäußert:

Bevor ich mit Wireshark dran gehe, würde ich gerne hören, ob jemand ähnlich Probleme unter Windows hat (Version 1803 if this matters)???

und soweit ich das sehe, wurdest Du bisher eher nicht mit #metoo-Nachrichten überrannt (oder diejenigen "trauen" sich dann nicht, das hier öffentlich zu machen). Es wird auch kaum helfen, Dir jetzt noch einmal zu versichern, daß sich solche Probleme bei anderen eher als Bedienfehler herausstellten ... das könntest Du alleine feststellen, denn diese Fehlermeldungen und -diskussionen sind ja i.d.R. hier öffentlich erfolgt. Wenn Du tatsächlich alle notwendigen Schritte korrekt ausgeführt hast und es trotzdem nicht funktioniert, muß man halt nach der Ursache schauen. Will man das nicht und weicht lieber auf die nächste Alternative aus (ein legitimes Vorgehen, solange man bei irgendeiner Version dann "das Sitzfleisch" aufbringt, den dort auftretenden Problemen mal wirklich zuleibe zu rücken - oft genug ist es eben auch nur ein eigener Denkfehler, der einen überall Probleme sehen und zur nächsten Alternative wechseln läßt), sollte man das - einfach der Übersichtlichkeit zuliebe - dann auch bei den anderen Tools weiter diskutieren. Ich habe in #1 zwar auch Alternativen benannt, aber der Titel sollte soweit eindeutig sein, daß man hier nicht über "ncftp" und dessen Verwendung zum Zugriff auf den Bootloader diskutieren sollte.

Abgesehen davon ... die Kommunikation mit der FRITZ!Box erfolgt (im Gegensatz zu "discovery", wo das Senden als Broadcast und der Empfang als Unicast erfolgen und damit keine "Zuordnung" in der Firewall möglich ist) beim FTP-Protokoll dann in einer Weise (inkl. der passiven Datenübertragung), daß auch eine Firewall sich daran nicht stören würde, weil die (TCP-)Antworten der Box in einer Verbindung gesendet werden, die vom PC selbst ausgehend aufgebaut wurde ... solange da tatsächlich "ncftpget" funktioniert (und die PS-Versionen stimmen), sollte "EVA-FTP-Client.ps1" arbeiten können und zwar vollkommen unabhängig davon, ob "EVA-Discover.ps1" nun funktioniert oder nicht.

Nicht ganz umsonst habe ich oben (in #1) schon selbst ausgeführt, daß es sich beim Finden der Box und beim FTP-Zugriff um zwei - eigentlich getrennte - Problemstellungen handelt. Die kann man auch mit unterschiedlichen Programmen (und sogar auf unterschiedlichen Systemen) angehen ... aber hier wäre eben der Platz für die Diskussion/Fehlersuche, warum es mit den Skript-Dateien aus "eva_tools" nicht funktionieren will.

 

[vaxinf]

Der neueste Stand:

.\EVA-FTP-Client.ps1 -ScriptBlock { GetEnvironmentFile }

funktioniert. Die Fritzbox befindet sich im Zustand, wo ftp-Zugriff mit Username adam2 möglich ist.

Rufe ich anschließend .\EVA-Discover.ps1 ohne Parameter auf, findet das discover Skript die
FB nicht.

Auch die Branch Version zickt (unter Win10 Prof.).

Eberhard

 

[PeterPawn]

Das weist ja dann immer deutlicher in die Richtung eines Problems mit der Firewall ... wenn jetzt noch in einem Paketmitschnitt (der die Daten mit "winpcap" noch vor einer Firewall abgreifen sollte) eine Antwort der FRITZ!Box auf das Discovery-Paket auftaucht (das ist dann ein UDP-Unicast-Paket an Port 5035), dann wette ich, daß hier wieder mal "der Virenscanner" und/oder "die Firewall" dem Erfolg im Weg steht und genau dazu gibt es bisher eben gar keine Angaben (außer der Feststellung, diese wären "deaktiviert").

Wie das am Ende bei einigen aussieht (z.B. bei Kaspersky) mit dem "Deaktivieren", haben wir hier inzwischen (wenn auch in anderen Threads) so oft diskutiert, daß ich darauf einfach keine Lust mehr habe - bei mancher dieser angeblichen "Security-Suiten" reicht es schon aus, wenn sich die MAC-Adresse ändert, die man einer IP-Adresse zuvor zugeordnet hat (meist auch noch automatisch und unbewußt), damit da weiterer (unsolicited) Traffic blockiert wird nach einer Veränderung und daß es sich bei solchen Versuchen des Zugriffs auf den Bootloader dann für gewöhnlich um ein "öffentliches Netzwerk" handelt und nicht mehr um ein "privates" (weil Windows das gerne mal am DHCP-Protokoll und dem dabei publizierten Gateway bzw. an dessen MAC-Adresse festmacht), ist genauso ein "Allgemeinplatz", der eigentlich keiner Wiederholung bedarf.

Wenn das ein "vanilla Windows" ist, dann kannst Du gerne mit weiteren Informationen versuchen, das Problem einzugrenzen ... ansonsten ist das ziemlich sicher reine Zeitverschwendung.

PS: Das Skript "EVA-Discover.ps1" ist auch im EVA-Branch noch genau dasselbe ... da sind allerdings andere Klassen hinzugekommen (in anderen Dateien), mit denen man die Suche nach einer startenden FRITZ!Box einfacher gestalten kann - aber die sind ohnehin noch nicht für die Benutzung geeignet, solange man nicht selbst mit Objekten und Events hantieren will (oder kann).

 

[vaxinf]

Problem gelöst:

Schuld war weder die Firewall noch das Antiviren Programm.

Die Virtualbox aktivierte ein zusätzliches (Netzwerk)-Interface, weil ich eine Netzwerkbrücke aktiviert habe. Nach dem Desaktivieren dieses Netzwerks findet das EVA-Discover.ps1 ganz schnell die FB!

Also zu Mitschreiben: alle Netzwerkverbindungen disablen außer der Ethernetverbindung über TP-Kabel!

Danke für die schnelle Reaktion auf meine Fragen.
Eberhard

 

[PeterPawn]

Klingt komisch ... eine "Netzwerkbrücke" (aka Bridge) sollte ja eigentlich den Traffic 1:1 zwischen zwei (oder mehr) Interfaces übertragen und ansonsten keine Pakete unterdrücken.

Vielleicht habe ich ja die Begründung auch falsch verstanden ... aber gerade dann, wenn man für "-Address" beim Aufruf eine Adresse aus dem "eigenen Segment" verwendet (Standard ist ja 192.168.178.1), sollte das eigentlich "so speziell" sein, daß die Daten gar nicht auf irgendein anderes/falsches Interface ausgegeben werden können, solange das nicht dieselben oder "noch speziellere" Einstellungen (das meint in erster Linie eine noch "längere" Netzwerk-Maske) verwendet.

Ich würde jedenfalls das (softwareseitige) Deaktivieren von Ethernet-Adaptern nur dann tatsächlich empfehlen, wenn eine sehr komische Netzwerk-Umgebung vorliegt und das reine "Ziehen" von Ethernet-Kabeln aus ihren Buchsen nicht hilft.

Wobei schon (kommt auch etwas auf die Windows-Version an, bei 1803 läßt es sich m.W. nicht mehr direkt einstellen) auch die passende Reihenfolge der Netzwerk-Adapter im Windows hier deutliche Entspannung bringt:


Aber dieses "Adapters and Bindings" ist irgendwann in W10 dann dem Setzen der "interface metric" gewichen ... Windows sollte jetzt genau das Interface mit dem kleinsten Metric-Wert automatisch auswählen.

Beim Senden eines UDP-Broadcasts ist eben (ohne zusätzliche Angaben) noch vollkommen unklar, welcher Adapter von "Windows Sockets" genutzt wird ... es gibt da keinen "hint" anhand der IPv4-Adresse, auf welchem Interface das am besten gesendet wird.

Mal sehen, ob ich das in künftigen Versionen noch besser hinbiegen kann für "multi-homed devices" ... wobei ich mir da eher wenig Hoffnungen mache, weil ich in jedem Falle verhindern will, daß ein Abbruch der ganzen Angelegenheit das System in einem "unbenutzbaren" Zustand zurückläßt und dazu gehören (für mich) auch deaktivierte Netzwerk-Interfaces.

 

[vaxinf]

Hier noch einmal eine screenshot meiner konfig.
Wie gesagt, erst das Desaktivieren des Virtualboxinterfaces brachte das erwünschte Ergebnis.

 

[reinelektronik]

Hallo @PeterPawn,

gibt es eine Anleitung für DAU's zum übertragen eines Images mit PowerShell in Win10, denn wenn ich PowerShell die zwei Skripts öffne und bei EVA-Discover starte dann bekomme ich eine Rückmeldung:

PS E:\Downloads\YourFritz-master\eva_tools> E:\Downloads\YourFritz-master\eva_tools\EVA-Discover.ps1
EVA_IP=192.168.178.1
True
und wenn ich EVA-FTP-Client starte kommt nichts und wenn das aus#1 im Beispiel mit meinen Daten fürs Image versuche kommt nur das:
PS E:\Downloads\YourFritz-master\eva_tools> EVA-FTP-Client.ps1  { BootDeviceFromImage E:\VM\7590_07.01.de_20180927-153910.image.in-memory }
EVA-FTP-Client.ps1 : Die Benennung "EVA-FTP-Client.ps1" wurde nicht als Name eines Cmdlet, einer Funktion, einer Skriptdatei oder eines ausführbaren Programms erkannt. Überprüfen Sie
die Schreibweise des Namens, oder ob der Pfad korrekt ist (sofern enthalten), und wiederholen Sie den Vorgang.
In Zeile:1 Zeichen:1
+ EVA-FTP-Client.ps1  { BootDeviceFromImage E:\VM\7590_07.01.de_2018092 ...
+ ~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (EVA-FTP-Client.ps1:String) [], CommandNotFoundException
    + FullyQualifiedErrorId : CommandNotFoundException

was mache ich falsch??
Gruß Reiner

//edit by stoney: [CODE] TAG [/CODE] gesetzt

 

[PeterPawn]

Wenn der erste Aufruf mit komplettem Pfad funktioniert und der zweite ohne diesen nicht, dann würde ich zunächst mal darauf tippen, daß die Datei schlicht nicht gefunden wird.

Ob PS jetzt das aktuelle Verzeichnis in die Suche nach ausführbaren Dateien einbezieht oder nicht, ist Einstellungssache ... aber man braucht ja nur den absoluten Pfad angeben (wie beim Aufruf von "EVA-Discover.ps1") oder eben einen "relativen" (der beginnt dann einfach mit ".\EVA-FTP-Client.ps1").

Aber eigentlich ist das - mit etwas anderen Worten - ja auch nur dasselbe, was bereits oben in der Fehlermeldung steht:

Überprüfen Sie die Schreibweise des Namens, oder ob der Pfad korrekt ist (sofern enthalten), und wiederholen Sie den Vorgang.

 

[reinelektronik]

Hallo,

so jetzt geht das Skript durch aber am Schluss habe ich eine Fehlermeldung und das Image wurde nicht installiert. Das Image wurde im "no Freetz Mod" erstellt.

PS E:\Downloads\YourFritz-master\eva_tools> E:\Downloads\YourFritz-master\eva_tools\EVA-FTP-Client.ps1 -Verbose -Debug -ScriptBlock { BootDeviceFromImage E:\VM\7590_07.01.de_20180926-171817.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.3258 0x0 0x46409

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

200 GETENV command successful

================
DEBUG: Memory size found    : 08000000
DEBUG: Image size found     : 0x01832200
DEBUG: Set memory size to   : 0x067cde00
DEBUG: Set MTD ram device to: 0x867cde00,0x88000000
DEBUG: Sent
SETENV memsize 0x067cde00
================
DEBUG: Response:
200 SETENV command successful

================
DEBUG: Sent
SETENV kernel_args_tmp mtdram1=0x867cde00,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 'E:\VM\7590_07.01.de_20180926-171817.image' to '0x867cde00 0x88000000' ...
DEBUG: Sent
P@SW
================
DEBUG: Response:
227 Entering Passive Mode (192,168,178,1,12,13)

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

================
DEBUG: Response:
553 Execution failed.

================
DEBUG: Sent
SETENV memsize 0x0x20000000
================
DEBUG: Response:
200 SETENV command successful

================
DEBUG: Sent
UNSETENV kernel_args_tmp
================
DEBUG: Response:
501 environment variable not set

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

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

Ausnahme beim Aufrufen von "Invoke" mit 0

Argument(en):  "Error uploading image file."
In E:\Downloads\YourFritz-master\eva_tools\EVA-FTP-Client.ps1:627 Zeichen:21
+                     $ScriptBlock.Invoke()
+                     ~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: :)) [], ParentContainsErrorRecordException
    + FullyQualifiedErrorId : RuntimeException

was nun. Ich will nur Telnetzugang für 7590 um TSB zu installieren.
Gruß Reiner

//edit by stoney: [CODE] TAGs [/CODE] gesetzt

 

[NDiIPP]

PS E:\Downloads\YourFritz-master\eva_tools> E:\Downloads\YourFritz-master\eva_tools\EVA-FTP-Client.ps1 -Verbose -Debug -ScriptBlock { BootDeviceFromImage E:\VM\7590_07.01.de_20180926-171817.image }

Der Name des von dir verwendeten Firmware-Images, welches du versuchst hochzuladen, lässt vermuten, dass es das falsche ist (falls du es nicht umbenannt hast). Versuchst du tatsächlich die normale "*.image" hochzuladen oder hast du tatsächlich die "*.image.in-memory" in "*.image" umbenannt?

 

[reinelektronik]

Hallo,

als erstes habe ich das mit dem "7590_07.01.de_20180927-153910.image.in-memory" gemacht und das Skript lief auch ohne Fehler durch aber nach einem Neustart der Box lief diese mit 06.92
Dann habe ich noch versucht mit YourFritz ein Image zu erstellen aber bei dem Punkt yf$ git checkout binaries kam eine Fehlermeldung und der nächste Punkt in der Anleitung yf$ ls -ln bin/x86 kann dann nicht mehr ausgeführt werden somit war da Schluss. Ich bin noch am verzweifeln da war das mit Speed-to-Fritz und TC mit FTP und ein paar Befehlen zum laden des kernel.image einfach.

Gruß Reiner

 

[PeterPawn]

da war das mit Speed-to-Fritz und TC mit FTP und ein paar Befehlen zum laden des kernel.image einfach

Niemand verwehrt Dir, das "mit ein paar Befehlen" selbst zu machen ... die Idee hinter den Skripten ist es nur, die Eingabe dieser Befehle (inkl. der notwendigen Berechnungen, wo denn nun das MTDRAM-Device genau liegt bei der vorhandenen Größe der Image-Datei) etwas zu vereinfachen. Wenn das mit dem Skript nicht funktioniert, wage ich mal die Prognose, daß es "von Hand" noch deutlich geringere Erfolgschancen hat ... aber jeder so, wie er will.

Ansonsten wurde diese "Prozedur" zur Installation einer Firmware durchaus schon von mehr als einem Nutzer erfolgreich vollzogen ... offenbar bist Du ja der Ansicht, es läge an der falschen und/oder unvollständigen Beschreibung (siehe der Versuch mit dem anderen Thread), daß es bei Dir nicht klappt.

Vielleicht setzt Du ja an die Stelle der angedrohten Verzweiflung einfach noch einmal die genaue Lektüre der Anleitungen und wenn dann etwas nicht funktionieren will, erweist sich häufig auch das Infragestellen der eigenen Arbeitsschritte (mit der daraus resultierenden Kontrolle, ob man das auch wirklich alles so gemacht hat, wie es beschrieben wurde) als probates Mittel, sein Ziel vielleicht doch noch zu erreichen.

Keine Anleitung der Welt kann verhindern, daß Du etwas falsch machst bei der Anwendung und wenn Du auf die Protokolle Deiner Versuche verzichtest und das stattdessen lieber in Prosa beschreiben möchtest (s. #31), machst Du gleich die nächste Fehlerquelle auf - bisher waren es (bei den hier sichtbaren Protokollen) eben zweimal falsche Dateinamen in Deinen eigenen Eingaben (1x beim Skript, 1x beim Image) und das kann kein Mensch erkennen, wenn Du das nur "beschreibst" (und dann noch in der Überzeugung, daß Du selbstverständlich alles richtig gemacht hast).

Wenn ein passendes Image tatsächlich erfolgreich in den Speicher geladen und gestartet wurde und dieses Image dann auch noch genug Zeit bekommt, die neue Version tatsächlich in den Flash zu schreiben (das ist die nächste "wahrscheinliche" Fehlerquelle), dann kann eigentlich fast nichts mehr schiefgehen - also wäre die (plausibelste) Vermutung, daß einer der "Schritte" im "Wenn-Zweig" wohl nicht so gelaufen ist, wie Du das "beschrieben" hast ... und solange Du die entsprechenden Konsolen-Protokolle keinem zeigst, bleibst nur Du als "Kontrollinstanz" übrig und damit bist Du auch der Einzige (eigentlich sollte das auch in Deinem ureigensten Interesse liegen), der sich hier selbst helfen kann.

Mehr, als Dich auf die offensichtlichen Fehler hinzuweisen, kann hier niemand leisten und Deine Lage wird durch "Gejammer" auch nicht besser. Willst Du Dich also nicht nur in Deiner Verzweiflung suhlen, solltest Du einfach noch einmal lesen (wenn das Image schon erfolgreich geladen wird, vielleicht direkt noch einmal die Stellen, wo es darum geht, wann man die Box danach neu starten darf bzw. warum man das gerade nicht machen sollte) und Deine eigenen Arbeitsschritte noch einmal (mit kritischem Blick und nicht der Attitüde: "Ich mache das schon alles richtig, nur die Beschreibungen sind alle falsch oder viel zu kompliziert.") überprüfen.

PS: Und vor allem mußt Du Dich eben mal für einen Weg entscheiden und wenn Du mit Freetz ein Image erstellt hast, dann ist es einfach Quatsch, als nächstes irgendetwas anderes zu versuchen, nur weil Du beim Laden des Images in die Box gescheitert bist. Diesen Schritt kannst Du nämlich niemals umgehen und anstatt jetzt irgendein anderes Image (mit anderen Tools) bauen zu wollen, solltest Du lieber versuchen, das mit dem Freetz-Image einmal richtig zu machen.

 

[Shirocco88]

bei dem Punkt yf$ git checkout binaries kam eine Fehlermeldung

wie soll man Dir helfen, wenn Du nicht mal die Fehlermeldung postest ????

 

[PeterPawn]

Gut, das "git checkout binaries" kann tatsächlich nicht mehr funktionieren, seitdem ich das auf ein "submodule" umgestellt habe ... aber das wurde in den ansonsten an solchen Stellen auch noch verlinkten Threads schon oft genug "angesprochen":

https://www.ip-phone-forum.de/threa...-für-7560-und-7590.296678/page-3#post-2289846
https://www.ip-phone-forum.de/threa...-für-7560-und-7590.296678/page-3#post-2289851
https://www.ip-phone-forum.de/threa...-oder-besser-nicht.294386/page-3#post-2282996

Entweder man kennt sich mit "git" aus (dann erkennt man automatisch beim Klonen von YourFritz, daß es jetzt ein Submodule ist) oder man muß eben lesen ... ich kann nicht nach einer (wohldurchdachten und auch meinerseits begründeten, notwendigen) Änderung hingehen und alle alten Fundstellen noch einmal anpassen ... das ist schon zeitlich nicht zu schaffen.

 

[Fireball3]

Ich veruche gerade von Windows 7 aus, einer 7490 mit FW7.01 SIAB beizubringen.
Das übertragen des Images scheitert jedoch immer so.

PS R:\eva_tools> .\EVA-Discover.ps1 120 192.168.188.1 192.168.188.150
EVA_IP=192.168.188.1
True
PS R:\eva_tools> .\EVA-FTP-Client.ps1 192.168.188.1 -Verbose -Debug -Scriptblock { BootDeviceFromImage R:\first_aid\implant_siab_3.10.73.image.7490 }
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.1964 0x0 0x740D

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

200 GETENV command successful

================
DEBUG: Memory size found    : 08000000
DEBUG: Image size found     : 0x00568500
DEBUG: Set memory size to   : 0x07a97b00
DEBUG: Set MTD ram device to: 0x87a97b00,0x88000000
DEBUG: Sent
SETENV memsize 0x07a97b00
================
DEBUG: Response:
200 SETENV command successful

================
DEBUG: Sent
SETENV kernel_args_tmp mtdram1=0x87a97b00,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 'R:\first_aid\implant_siab_3.10.73.image.7490' to '0x87a97b00 0x88000000' ...
DEBUG: Sent
P@SW
================
DEBUG: Response:
227 Entering Passive Mode (192,168,188,1,12,9)

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

================
DEBUG: Sent
SETENV memsize 0x0x10000000
================
DEBUG: Response:
553 Execution failed.
200 SETENV command successful

================
DEBUG: Sent
UNSETENV kernel_args_tmp
================
DEBUG: Response:
501 environment variable not set

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

================
Ausnahme beim Aufrufen von "Invoke" mit 1 Argument(en):  "Error uploading image file."
Bei R:\eva_tools\EVA-FTP-Client.ps1:627 Zeichen:40
+                     $ScriptBlock.Invoke <<<< ()
    + CategoryInfo          : NotSpecified: (:) [], ParentContainsErrorRecordException
    + FullyQualifiedErrorId : DotNetMethodException

PS R:\eva_tools>

Liegt das an dem Ausdruck "SETENV memsize 0x0x10000000", dass da ein 0x zuviel ist?

Edit:
Und wenn der call schonmal offen ist, wie finde ich den Kernel, auf der Box heraus?
Ist bei der 7.01 automatich der 3.10.107 drin? (würde ich jetzt mal vermuten).

Und ich wollte noch erwähnen, dass die Box noch nicht eingerichtet ist. Also nicht am DSL hängt.

 

[PeterPawn]

Ich muß mal schauen, was da beim Zurücksetzen des Speichers schief läuft ... das ist aber nicht die Ursache des Fehlers, denn das findet erst statt, nachdem der Upload mit "553" gescheitert ist (und ohne Fehler gleich gar nicht).

Das "553" deutet i.d.R. auf ein falsches Image hin ... die Ursache dafür kann vom falschen Download bis zu Übertragungsfehlern reichen. Ich würde hier mal die Signatur der Datei überprüfen, denn das beinhaltet auch gleich den Test, ob die Datei richtig ist.

Ich werde aber parallel mal versuchen, bei mir eine 7490 mit dem Image zu starten ... denn das habe ich tatsächlich nur erzeugt mittels des passenden Skripts und nicht selbst getestet. Sollte ich dabei ein Problem im/mit dem Image finden, sage ich Bescheid.

Wobei das für eine 07.01 ja ohnehin das "falsche" Image wäre, denn ich habe ja auch eines für den 3.10.107-Kernel (und ja, die 07.01 hat einen solchen - am ehesten findet man das im Verzeichnis /lib/modules heraus) bereitgestellt. Eigentlich müßte ich also sogar beide bereitgestellten Images (1x 3.10.73, weil auch da ein neues Binary fällig war und 1x 3.10.107) noch einmal testen ... mal schauen, wie lange ich brauche.

 

[Fireball3]

Ich habe die 3.10.107 auch erfolglos versucht.
Ich schau jetzt mal wie ich die Dateisignatur prüfen kann.

 

[PeterPawn]

Das Problem, daß die Speichergröße nicht als Zahl angesehen wurde in EVA-FTP-Client.ps1, ist beseitigt. Bei mir haben auch beide SIAB-Images (sowohl für 3.10.73 als auch 3.10.107) einwandfrei funktioniert - es ist also eher ein Anwendungsfehler (beim Speichern vermutlich). Ich habe die natürlich auch tatsächlich aus GitHub "frisch" geladen und nicht einfach irgendwelche lokalen Dateien verwendet.

Zur Kontrolle die SHA-256-Hashes der Dateien:

31bad0b664ddf3f9840917fd2967f4499e02baa2a654803fc9ceadefee552968 implant_siab_3.10.73.image.7490
9e9422b984d5f839edb0c4fc8acd21f56465197c48c23fb0198987734e503336 implant_siab_3.10.107.image.7490

 

[Fireball3]

Hab meine Dateien eben gehasht.
Beide stimmen.
Ich hole jetzt nochmal die EVA-FTP-Client.ps1 frisch vom git und probiere nochmal.

 

[PeterPawn]

Dann würde ich am ehesten wieder auf eine Security-Suite tippen, die bei FTP-Verbindungen irgendwie dazwischenhängt. Oder auf "jumbo packets" ... auch damit kamen ein paar Bootloader-Versionen nicht so richtig zurecht.

Meine Ausgabe sah jedenfalls (mit dem zusätzlichen Breakpoint, um die "Berechnung" für "$originalmemory" und die Umwandlung nach dezimal im Ergebnis zu sehen) so aus:

PS C:\Windows\system32> Q:\EVA-FTP-Client.ps1 -Address 192.168.130.1 -ScriptBlock { BootDeviceFromImage "Q:\implant_siab_3.10.73.image.7490" } -Verbose -Debug
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.1964 0x0 0x740D

================
Hit Line breakpoint on 'Q:\EVA-FTP-Client.ps1:260'
[DBG]: PS C:\Windows\system32>>
DEBUG: Sent
GETENV memsize
================
DEBUG: Response:
memsize               0x10000000

200 GETENV command successful

================
[DBG]: PS C:\Windows\system32>>
[DBG]: PS C:\Windows\system32>> $originalmemory
268435456

[DBG]: PS C:\Windows\system32>> $memsize
0x10000000

[DBG]: PS C:\Windows\system32>>
DEBUG: Memory size found    : 08000000
DEBUG: Image size found     : 0x00568500
DEBUG: Set memory size to   : 0x07a97b00
DEBUG: Set MTD ram device to: 0x87a97b00,0x88000000
DEBUG: Sent
SETENV memsize 0x07a97b00
================
DEBUG: Response:
200 SETENV command successful

================
DEBUG: Sent
SETENV kernel_args_tmp mtdram1=0x87a97b00,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 'Q:\implant_siab_3.10.73.image.7490' to '0x87a97b00 0x88000000' ...
DEBUG: Sent
P@SW
================
DEBUG: Response:
227 Entering Passive Mode (192,168,130,1,12,3)

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

================
DEBUG: Response:
226 Transfer complete

================
True

PS C:\Windows\system32>

EDIT:
Wobei mir bei Windows 7 sofort wieder der Verweis auf die notwendigen Minimalversionen in den Sinn kommt ... irgendwo im Skript gibt es die Ausgabe von "$PSVersionTable" mit den notwendigen Infos.