@WileC:
Theoretisch das falsche Unterforum ... besser eins höher (also "Modifikationen"), ehe sich jemand empört (PowerShell hat dann nicht einmal mehr etwas mit Linux zu tun und damit nur noch wenig mit "Freetz" gemein).
Ansonsten verhält sich das PowerShell-Skript anders als die Shell-Variante ... schaut man in den
Kopf der Datei, steht dort ja ein "$False" als Standard bei fehlender Angabe für den "nohold"-Parameter. Die PowerShell-Variante sollte also die Box anhalten (bei fehlender Angabe), die
Linux-Variante hingegen nicht.
Warum die Box hier nicht stehenbleiben mag, kann man so aber auch nicht sehen, dazu müßtest Du schon den Aufruf um die Parameter "-Debug" und "-Verbose" erweitern. Wenn dann ein Fehler angezeigt wird, muß man ggf. das Skript ändern für die korrekte/komplette Fehlermeldung, weil hier einfach ein "catch" für jeden Fehler gemacht wird (um das einfacher zu halten).
Ich würde ad hoc darauf tippen, daß die lokale Netzwerk-Konfiguration nicht dazu angetan ist, die FRITZ!Box unter der Adresse 192.168.178.1 zu finden. Das kann z.B. ein noch nicht verfallener ARP-Eintrag von einer anderen Box sein, der nun die 192.168.178.1 mit einer anderen MAC-Adresse verknüpft oder auch eine falsche IP-Adresse/Route, wo dann die Daten auf einem anderen Interface landen und nicht auf demselben, wo die Box gefunden wurde. Dann hilft ggf. schon die Angabe der "gewünschten" Adresse der FRITZ!Box, sofern diese Angabe zur eigenen Konfiguration des Netzwerks paßt. Vielleicht sucht hier auch erst einmal das Windows-Netzwerk (dank "media sense") nach einer eigenen Adresse per DHCP, nachdem das Interface nun dank "Power-On" bei der FRITZ!Box der Meinung ist, es müsse sich neu konfigurieren. Das kann man "von außen" und ohne weitere Angaben nicht sehen/einschätzen - da müßtest Du dann schon noch etwas mehr auf den Tisch packen.
Es ist aber i.d.R. ohnehin besser, die beiden Skript-Dateien unmittelbar nacheinander auszuführen und auf die zwischenzeitliche Verbindung zum FTP-Server (die ist es ja, was die Box im Loader "festhält" bzw. halten soll, auch über ihr Beenden hinaus) zu verzichten.
Es gibt sehr unterschiedliche Reaktionen von verschiedenen Bootloader-Versionen ... während die einen beim puren Aufbau einer Verbindung, die ohne jeden Austausch von Daten wieder geschlossen wird, etwas allergisch scheinen (und im Anschluß nicht mehr auf einen neuen Verbindungswunsch reagieren), geschieht das bei anderen wohl nur dann, wenn man diese Verbindung sofort wieder mit einem "QUIT" beendet.
Was ich noch nicht getestet habe, ist die Vermutung, daß es nach einer erfolgreichen Anmeldung an der Box (also nach "USER"- und "PASS"-Kommando) ein einheitliches Verhalten geben könnte ... ansonsten hätten die Recovery-Versionen von AVM auch so ihre Probleme mit unterschiedlichen Bootloader-Versionen, denn diese Programme melden sich ebenfalls mehrfach bei der Box an.
Allerdings gibt es für die natürlich auch keine Notwendigkeit, das in zwei getrennte Schritte zu splitten - ich weiß halt nicht, was die Ursache solcher Verbindungsprobleme nach einem Anhalten beim Aufruf eines der Discovery-Skripte tatsächlich ist. Die PowerShell-Variante benutzt jedenfalls die Variante ohne explizites "QUIT", was nicht jeder Bootloader mag - aber dann sollte die Box nur auf weitere Kommandos nicht mehr reagieren und nicht einfach mit ihrem Start fortfahren (außer nach einem erfolgreichen "in(to)-memory"-Upload, da wartet sie dann nicht auf weitere Kommandos).
Am einfachsten wäre da halt ein eigenes "Klammerskript" für die beiden Kommandos, wobei die PowerShell auch das Semikolon als Trennzeichen zwischen zwei Kommandos kennt und man das somit auch problemlos auf eine Zeile kriegt.
Die Ausgabe von "EVA-Discover.ps1" umfaßt eigentlich auch extra die IP-Adresse der Box, damit man bei einer weitergehenden Automatisierung auf diese Angabe zurückgreifen kann und auch der "
Rückgabewert" ist eigentlich dazu gedacht, daß der Aufrufer ermitteln kann, ob eine Box gefunden wurde oder nicht und ggf. die Verarbeitung bei einem Problem abbrechen kann.
Da der betreffende Fehler beim Herstellen einer FTP-Verbindung zum Bootloader im "EVA-FTP-Client.ps1" auch nicht einfach mit einem "catch (all)" weggefangen wird, kann man bei unmittelbar aufeinanderfolgenden Aufrufen die passende Fehlernachricht auch direkt dem zweiten Skript-Aufruf entnehmen und muß das erste nicht noch anpassen, damit man die ausführliche Fehlernachricht sehen kann.
Bei mir funktioniert jedenfalls (bei einer 7580, die ich gerade untersuche und passend verkabelt habe) auch das Anhalten im Bootloader:
Code:
PS C:\Users\PeH> [COLOR="#0000FF"][B].\Desktop\EVA-Tools\EVA-Discover.ps1 -Debug -Verbose[/B][/COLOR]
VERBOSE: Sending discovery packet (1) ...
VERBOSE: Sending discovery packet (2) ...
VERBOSE: Sending discovery packet (3) ...
VERBOSE: Sending discovery packet (4) ...
VERBOSE: Sending discovery packet (5) ...
VERBOSE: Sending discovery packet (6) ...
VERBOSE: Sending discovery packet (7) ...
VERBOSE: Sending discovery packet (8) ...
VERBOSE: Sending discovery packet (9) ...
VERBOSE: Sending discovery packet (10) ...
DEBUG: Received UDP packet from 192.168.178.1:5035 ...
VERBOSE: Trying to connect to the FTP port to hold up the device in bootloader ...
EVA_IP=192.168.178.1
True
PS C:\Users\PeH> [COLOR="#0000FF"][B].\Desktop\EVA-Tools\EVA-FTP-Client.ps1 -ScriptBlock { GetEnvironmentValue ProductID } -Debug -Verbose[/B][/COLOR]
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.3229 0x0 0x46409
================
DEBUG: Sent
GETENV ProductID
================
DEBUG: Response:
ProductID Fritz_Box_HW225
200 GETENV command successful
================
Fritz_Box_HW225
PS C:\Users\PeH>
- - - Aktualisiert - - -
BTW ... wer mittels "EVA-Discover.ps1" nur ermitteln will, welche IP-Adresse in der Box aktuell für den Bootloader eingestellt ist (die ist bekanntlich vollkommen unabhängig von der Adresse einer "richtig gestarteten" Box), der kann als "Wunschadresse" einfach 0.0.0.0 angeben - dann ändert die Box ihre eigene IP-Adresse nicht und antwortet unter/mit der aktuell eingestellten Adresse.