@WileC:
DAS wäre nun tatsächlich eine Änderung, die ich als sinnvoll erachte, wenn man damit eine genauere Fehlermeldung und umfangreichere Prüfung auch gleich noch verbindet.
Dazu gehört dann zunächst die Prüfung, daß das Ergebnis von Resolve-Path tatsächlich ein lokaler Dateiname ist (UNC-Pfade würde ich persönlich per Definition an dieser Stelle verbieten, weil ich Netzwerk-Probleme bei vielen Benutzern erwarten würde, die dann bloß wieder zusätzliche Fragen provozieren) und daß es auch nur eine dedizierte Datei ist - Resolve-Path löst ja auch Wildcards auf und die Rückgabe könnte auch ein String-Array sein.
Dann kann/sollte man auch gleich noch "ObjectNotFound" beim Resolve-Path abfangen, weil sich daraus dann wirklich die passende Fehlernachricht (Datei existiert nicht oder ist nicht lesbar) ableiten und anzeigen läßt (BootDeviceFromImage verwendet bisher "Test-Path" zur Prüfung) und schlußendlich kann man dann auch gleich noch prüfen, daß man (also der Benutzer) tatsächlich die Rechte hat, diese Datei zu öffnen und zu lesen bzw. daß diese Datei nicht leer ist (oder daß das zumindest absichtlich so ist).
Damit "umgeht" man dann auch noch ein paar unnötige Aktionen ... beim Senden des STOR-Kommandos löscht die Box ja zunächst die zu beschreibende Flash-Partition (jedenfalls darf man annehmen, daß es das ist, was die relativ lange Pause zwischen dem Senden des Kommandos und dem Öffnen der Datenverbindung seitens der Box verursacht) und wenn dann die Datei wegen eines bisher "ungetesteten" Problems gar nicht gesendet werden kann, geht (a) der bisherige Inhalt der Partition unnötigerweise verloren und (b) kriegt der Flash (vermutlich, genau weiß ich das natürlich auch nicht, aber ich glaube nicht, daß da vorher geprüft wird bei NOR oder SPI) beim nächsten Versuch dann noch einen weiteren Löschzyklus verordnet, der seine Lebensdauer (ebenfalls unnötig) verringert.
-Wobei ich ohnehin mal etwas genauer getestet habe und (für mich) zu der Feststellung gekommen bin, daß die Implementierung des FTP-Servers in verschiedenen Modellen und Versionen des Bootloaders durchaus unterschiedlich ist. Die besten (reproduzierbaren) Ergebnisse habe ich erhalten, wenn ich das komplette FTP-Protokoll für jede Sitzung durchlaufen lasse. Alles andere liefert früher oder später einen Fehler ... bei der 7580 (bootloaderVersion 1.3229 - die Variable "urlader-version" ist gar nicht gesetzt, wie das bei anderen Modellen m.W. der Fall ist) kann ich z.B. mit einem zusätzlichen "QUIT" nach der "211 Goodbye"-Meldung problemlos dafür sorgen, daß die Box auf den nächsten Versuch einer FTP-Verbindung gar nicht mehr reagiert (und der Stecker gezogen werden muß). Da kommt wohl die "state machine" des Servers etwas durcheinander und das wird wohl nicht ordentlich zurückgesetzt nach einem FIN ... und mehrere parallele Verbindungen funktionieren ja ohnehin nicht (zumindest nicht bei den Modellen, auf die ich Zugriff habe).
Das heißt dann, daß es auch für das "Festhalten" der Box im Bootloader in den beiden Discovery-Skripten die vermutlich beste Lösung ist, wenn man da nicht nur eine Verbindung aufbauen läßt und diese dann einfach wieder schließt oder mit "QUIT" beendet (worauf der Server ja dann teilweise auch noch mit "530 not logged in" anstatt mit "211 Goodbye" reagiert), sondern wenn man sich tatsächlich komplett einloggt (also USER und PASS sendet) und sich erst dann mit "QUIT" wieder verabschiedet. Dann ist es mir zumindest bei allen hier vorhandenen Modellen (7490, 7412, 6490, 7580) gelungen, immer wieder aufs Neue eine Verbindung mit dem Bootloader per FTP herzustellen und so in mehreren FTP-Sitzungen (ohne zwischenzeitliche Neustarts) mehrere Aktionen nacheinander auszuführen.
Nun fehlt aber in den beiden Discovery-Skripten der ganze Teil für den FTP-Client (das ist eben etwas mehr als das "blinde Senden" von "QUIT", was der Client da leisten muß) ... und ehe ich da bei der PowerShell-Variante (bei der (Linux-)Shell-Version bin ich noch unsicher) jetzt gegenseitige Aufrufe der beiden ps1-Skripte implementiere, gehe ich wohl den anderen Weg und fasse die beiden zu einem einzelnen zusammen ... dann wird eben "discovery" ein (vielleicht auch nur optionaler) zusätzlicher Schritt vor dem Verbindungsaufbau zum FTP-Server. Obwohl bei der PowerShell-Variante natürlich auch ein FTP-Client mit der passenden .NET-Klasse die Anmeldung und Auswertung der Antworten übernehmen könnte ... das wird noch ein gesonderter, erster Schritt der Änderung an den PowerShell-Versionen sein, damit da ein besseres Ergebnis beim "Festhalten" erzielt wird, bevor ich die Skripte zusammenfasse.
Zumindest die hier verfügbaren Boxen (Liste s.o.) reagieren auch nach den fünf Sekunden unmittelbar nach dem Start (wenn sie erst einmal "festgehalten" wurden) noch auf die UDP-Broadcasts und (zumindest solange sich der FTP-Server in einem "neutralen Zustand" befindet) sogar auf nachträgliche Änderungen der IPv4-Adresse über solche Broadcasts. Damit schadet es vermutlich auch gar nicht, wenn man tatsächlich vor jedem Verbindungsaufbau die (startende oder bereits wartende) Box per UDP-Broadcast suchen läßt und ihr dabei entweder eine "Wunschadresse" zuweist oder sogar nur die aktuell verwendete auf diesem Weg ermittelt und gar nicht mehr als Parameter (egal ob mit oder ohne Standardwert) erwartet. Erst mit einem "REBOOT" oder durch das erfolgreiche Laden eines "in-memory"-Images (und dessen Start) verläßt die Box den "Wartezustand" dann wieder.
Für die PowerShell-Variante werde ich das wohl demnächst umsetzen ... vielleicht wird ja tatsächlich aus einer "Konzeptstudie" noch eine "Lösung", wenn ich das (mehr oder weniger gezwungenermaßen) zusammenführe. Bei der Linux-Variante zögere ich noch etwas, weil es für Discovery eben "socat" bräuchte, während die FTP-Client-Funktionen auch mit "netcat" (sogar ohne spezielle Optionen, wenn man es anders macht als jetzt) auskommen würden und das ist auch gerne mal in einer BusyBox dabei ("socat" ist da schon wesentlich exotischer).
