- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,275
- Punkte für Reaktionen
- 1,751
- Punkte
- 113
EDIT (01.12.2018): Wer auf der Suche nach einer anderen und für ihn/sie vielleicht leichter zu verstehenden Beschreibung bzw. einer "step by step"-Anleitung ist, kann ja mal einen Blick hierauf werfen:
/howto-fritz-box-firmware-images-auch-unsignierte-ueber-den-bootloader-installieren-577
Der Link auf den originalen Speicherort dieser Anleitung funktioniert nicht mehr, ich habe unter http://yourfritz.de/desc-eva eine Umleitung auf diese Anleitung in der Wayback-Machine angelegt.
-----------------------------------------------------------------------------------------
Der folgende Text ist ein Duplikat aus einem anderen Beitrag, in dem ich vor einiger Zeit mal die Anwendung der Skript-Dateien aus dem Unterverzeichnis "eva_tools" in meinem "YourFritz"-Repository beschrieben hatte. Da der offenbar schwer zu finden ist, ziehe ich den relevanten Teil hier noch einmal heraus und passe die Formatierungen etwas an, weil die XenForo-Software leider nicht alle zuvor verwendeten Features (insb. das Kolorieren von Code-Blöcken) unterstützt. Teile des Textes brauchen ggf. auch den Kontext aus dem anderen Thread, aber ich habe im Moment weder Zeit noch Lust, das noch einmal zu überarbeiten.
Wer nicht weiß, wie er an die beschriebenen Skript-Dateien kommen soll und/oder was ggf. noch passieren muß, damit diese Dateien zur eigenen Linux-Installation passen, kann am Beginn dieses Threads nachlesen.
Wie man ein GitHub-Repository unter Windows klont und was man beim Editieren von Dateien hinsichtlich der unterschiedlichen Zeilenenden unter Windows bzw. Linux (oder anderen "unix-artigen" Systemen) beachten muß, ist nicht Gegenstand dieses Beitrags und auch die Geistesarbeit, den Namen der Image-Datei beim Upload in den Speicher der Box an die eigenen Gegebenheiten anzupassen, bleibt dem Leser überlassen.
Die URL zum YourFritz-Repository wäre jedenfalls die folgende: https://github.com/PeterPawn/YourFritz
==================================================
Hier beginnt jetzt der Text aus dem anderen Thread ...
==================================================
Jedenfalls haben wir nun unser bootfähiges Image auf dem Linux-Rechner liegen und müssen uns nur noch daran machen, es irgendwie auf die Box zu bringen. Dazu verbinden wir den Rechner und die FRITZ!Box mit einem Ethernet-Kabel und hier gabelt sich unser Weg dann, je nachdem, ob wir den Zugriff auf den Bootloader der FRITZ!Box von einem Linux- (oder OS X-) oder einem Windows-System ausführen wollen.
Warum spielt hier Windows überhaupt eine Rolle, wenn wir doch fürs Erstellen des Images ohnehin eine Linux-Installation brauchten? Da komme ich dann wieder auf die oben geschriebenen Zeilen zur GPLv2 zurück und zu dem Gedanken/der Möglichkeit, daß jemand anderes mit einem Linux-System so ein Image für uns vorbereitet haben könnte und wir damit gar kein Linux-System mehr benötigen, um so eine Aktion wie das Umschalten auf "keine Anmeldung erforderlich" auszuführen ... das geht dann also auch mit einem Windows-PC.
Mit anderer Technik aus einem aktuellen Haushalt (Smartphone, Tablet), die auch nicht zum Erstellen eines solchen Images genutzt werden kann, wird es sicherlich auch schwerer, den notwendigen Zugriff über ein LAN-Kabel zu erlangen ... aber auch das wäre machbar, wenn man die FRITZ!Box und einen (autonomen) WLAN-AP (Access Point, also eine WLAN-"Basisstation") miteinander per Kabel verbindet und sich mit seinem WLAN-Gerät am AP anmeldet. Zumindest mit einem (ggf. gerooteten) Android-Gerät sollte das auch funktionieren - das wäre dann aber wieder mehr die Richtung "Linux-System" und bei iOS-Geräten mit Jailbreak läuft es auf dasselbe hinaus (ohne Jailbreak aber dort auch keine eigenen Kommandos in der Shell).
Wenden wir uns also zuerst dem Thema "Linux-System für EVA-Zugriff" zu ... das ist gleichzeitig die erste (und voraussichtlich einzige) Beschreibung meinerseits (jedenfalls in diesem Umfang), wie man die Shell-Skripte aus "eva_tools" benutzen kann.
Beim Zugriff auf den Bootloader einer FRITZ!Box gibt es zwei - eigentlich getrennte - Aufgaben ... einerseits geht es erst einmal darum, eine startende FRITZ!Box im LAN zu finden, sie dann in diesem Modus "festzuhalten" (weil sie nur für 5-10 Sekunden auf eingehende FTP-Verbindungen beim Start wartet) und als zweites geht es dann um die Kommunikation mit dem FTP-Server. Egal ob man auf EVA mit einem Windows-PC oder einem Linux-System zugreifen will ... da eine startende FRITZ!Box ihre Ethernet-Schnittstellen erst einmal aktivieren muß und das System am anderen Ende des Kabels erst dann darüber informiert wird, daß da jetzt "jemand ist", kann jede automatische Netzwerk-Konfiguration, die auf dieses (angenommene) "Einstecken" eines LAN-Kabel reagiert und dann erst einmal per DHCP irgendwelche IP-Adressen für das Interface erfragen möchte, bereits dazu führen, daß die erwähnten 5 bis 10 Sekunden lange um sind, wenn die Netzwerkschnittstelle dann endlich bereit ist, um mit der Box kommunizieren zu können.
Schon aus diesem Grund sollte man - sofern man ein passendes Gerät besitzt, dafür reichen auch alte Gurken für Fast-Ethernet (100 MBit/s) oder sogar solche für 10 MBit/s - irgendeinen Ethernet-Switch (notfalls tut es auch ein Hub und bei der Variante mit dem WLAN-AP wäre auch dieser bereits ausreichend) zwischen FRITZ!Box und PC schalten und auf dem PC dafür sorgen, daß das verwendete Ethernet-Interface bereits eine IPv4-Adresse hat - das kann bei einem Windows-System auch gerne eine APIPA-Adresse aus dem Bereich 169.254.0.0/16 sein (oder das "zeroconf"-Pendant beim Linux).
Wichtig ist nur, daß diese Adresse bereits aktiv ist (also kein bis dahin unkonfiguriertes Interface erst beim "media sensing" auf die Suche nach einer DHCP-Adresse geht) - arbeitet man ohne zusätzliche Hardware zwischen FRITZ!Box und PC, muß man ggf. das "media sensing" im verwendeten PC-Betriebssystem auch abschalten - das Internet hilft bei der Suche, wie das beim eigenen System geht und auch Windows-Benutzer müssen heutzutage dafür nicht mehr in die Tiefen der Registry hinabsteigen; also Vorsicht vor allzu alten "Anleitungen", wie man das über die Registry machen kann - zumal das dann erst nach einem Neustart wirksam wird.
Für den ersten Schritt (das Suchen der FRITZ!Box, bei dieser Suche kann man dann einer FRITZ!Box mit einer bis dahin unbekannten Adresse, die diese im Bootloader benutzt, auch gleich noch eine definierte Adresse zuweisen, die zu Konfiguration des eigenen Ethernet-Interfaces paßt) gibt es Unterstützung von mehreren Seiten ... ich zähle mal ein paar auf, bevor ich mich den Skript-Dateien im YourFritz-Repository für diesen Zweck widme:
Es ist also gar nicht notwendig, daß man die beiden Schritte (Suchen der Box und "Festhalten" im Bootloader einerseits und die Kommunikation mit dem FTP-Server andererseits) mit demselben Programm erledigt oder auch nur auf derselben Plattform. Wer z.B. kein Linux-System mit einer "socat"-Variante hat (die wird für die UDP-Broadcasts benötigt und ich kenne keine Alternative, die ohne C-Compiler auskommt - womit ich dann wieder beim Thema "zusätzliche Software" bin), kann auch die Box mit einem Windows-System und dem AVM-Recovery-Programm (wie geschrieben, für ein falsches Modell - die Idee dahinter hatte ich hier schon früher beschrieben) bis zu diesem Punkt treiben und dann mit einem anderen System (z.B. einem RasPi mittels einer SSH-Session) mit dem FTP-Server weiter arbeiten.
Will man dann unter Linux (oder OS X, wobei ich das noch nicht getestet habe) mit meinem "eva_discover" arbeiten, braucht man zunächst mal Informationen zu seinen eigenen Netzwerk-Einstellungen. Das Skript an sich ist weit, weit von einer Fertigstellung entfernt ist, das war auch mal in der Vergangenheit nur eine "Prinzipskizze" (vorab für jemanden als Beispiel eingecheckt) mit jeder Menge offener Baustellen bei den Parametern, bis mir dann die Notwendigkeit der wiederholten Betonung dieser Tatsache auf den Geist ging und ich jeden Code zur Erkennung von Einstellungen deaktiviert habe. Damit braucht man jetzt folgende Informationen, wenn man das Skript erfolgreich aufrufen will:
Optional verkraftet das Skript zum Suchen der FRITZ!Box (das heißt - nebenbei bemerkt - dann "eva_discover") auch noch weitere Angaben:
Wie man jetzt Interface-Namen und IP-Adressen findet, beschreibe ich hier nicht ... das ist u.a. auch von der Distribution abhängig und definitiv "nicht mein Tisch". Bei mir nehme ich einfach das Interface "vlan1" und die eigene IP-Adresse 192.168.178.2 (mit einer 24er-Maske, die hier aber nicht angegeben wird) - das ergibt dann für die 7412 die Möglichkeit, mit der Adresse 192.168.178.1 (auch hier wieder eine implizierte /24, die aber auch nicht angegeben wird) zu arbeiten. Man kann hier aber wirklich mit jeder beliebigen eigenen Adresse arbeiten und muß sich nur eine dazu passende Adresse der FRITZ!Box "ausdenken", damit die Pakete auch auf dem richtigen Netzwerk-Interface (vorausgesetzt, die Linux-Maschine hat mehr als eines) gesendet werden. Dann sind die anderen Einstellungen auch egal, weil das alles innerhalb derselben L2-Domain arbeiten muß und da spielen dann auch Netzwerk-Masken nur noch eine sehr untergeordnete Rolle. Wir passen hier also die FRITZ!Box an unsere Vorstellungen an und nicht umgekehrt unsere Vorstellungen an die FRITZ!Box.
Wenn das "eva_discover"-Skript die FRITZ!Box nicht finden kann innerhalb der vorgegebenen Zeit, wird "EVA_FOUND=0" auf STDOUT ausgegeben, ansonsten "EVA_FOUND=1" und als "EVA_IP=<ip>" auch die Angabe, welche Adresse die FRITZ!Box jetzt hat. Man kann nämlich mit "TO=0.0.0.0" ihr auch gestatten, die bisher eingestellte Adresse weiterhin zu verwenden - ggf. muß man mit Problemen rechnen, wenn diese bei der eigenen Linux-Maschine auf einem anderen Interface läge, wie es häufig bei "99.88.77.xx" der Fall sein dürfte, da wird wohl in der überwiegenden Zahl der Fälle die "default"-Route zuständig sein. Diese Art der Ausgabe auf STDOUT (alle anderen Ausgaben gehen nach STDERR und sind damit leicht von diesen Angaben zu trennen) macht es auch möglich, den Aufruf einfach in eine Form
zu kleiden ... da erkennt man dann auch, warum es gar nicht erforderlich ist, die Box mittels "HOLD=1" irgendwie aus dem Tritt zu bringen. Wenn man weiß, was man machen will, packt man einfach diese 7 Zeilen in eine Textdatei (mit den richtigen Angaben beim Aufruf von "eva_discover" und "eva_to_memory") und ruft die dann mittels "bash <dateiname>" auf (oder auch mit der "dash" oder "ash", wenn man eine BusyBox verwendet). Da die Parameter eben von der eigenen Installation abhängig sind, macht es auch wenig bis keinen Sinn, so etwas als "template" bereitzustellen.
Wir haben also unsere Box "vorbereitet" mit der Verkabelung und sind jetzt zurück in der oben unterbrochenen Linux-Shell-Session:
Während die FRITZ!Box gesucht wird, erfolgt durch das "BLIP=1" beim Aufruf eine Anzeige mit einer wachsenden Anzahl von Punkten (für jedes UDP-Paket einer) auf STDERR, die am Ende über ANSI-Terminal-Sequenzen wieder gelöscht wird, daher taucht sie oben bei mir nicht auf in der CODE-Box. Während diese Punkte nun einer nach dem anderen angezeigt werden, muß man irgendwie die FRITZ!Box neu starten ... das geht vom "Strom aus/ein" (das man auch an beiden Ende der Stromversorgung praktizieren kann oder über eine fernsteuerbare Steckdose) bis zum "reboot"-Kommando (auch über das GUI), was hier aber vermutlich nicht in Frage kommt, solange man sich auf der Box nicht einloggen kann.
Zusatz: Bei den GRX5-Modellen (7560, 7580, 7590) wurde inzwischen beobachtet, daß diese den FTP-Server im Bootloader wohl nur noch dann starten, wenn es sich um ein echtes "PowerOn-Reset" handelt - bei diesen Modellen sollte man also immer den Stecker ziehen und es nicht mit einem "Warmstart" versuchen.
Bisher hat noch jede FRITZ!Box, die ich dabei bewußt beobachtet habe, beim Initialisieren der GPIO-Ports für die Ansteuerung der LEDs alle gleichzeitig kurz aufblinken lassen und danach beginnt die Karenzzeit (wie gesagt, irgendwas zwischen 5 und 10 Sekunden nach meiner Erfahrung), in der man mit der Box Verbindung aufgenommen haben muß. Wenn sich also innerhalb von - sagen wir mal - 15 Sekunden nach dem Herstellen der Stromversorgung noch nichts getan hat (die GRX500-Boxen brauchen wohl länger, was ich auf die angenommene Virtualisierung zurückführen würde), dann ist irgendetwas anderes faul im Staate Dänemark und wenn das auch bei einem zweiten oder dritten Versuch nicht funktionieren will, ist da der Wurm drin und es wird auch beim 20. Versuch (ohne Änderungen) eher nicht funktionieren. Dann gibt es i.d.R. irgendwo einen Fehler, z.B. hängt die Box (oder der dazwischengeschaltete Switch) am falschen Ethernet-Port des Rechners oder es wird doch irgendeine langwierige Autokonfiguration verwendet und die frißt dann schon die verfügbare Karenzzeit. Das ist allerdings bei Windows-PC deutlich häufiger der Fall, weil diese Autokonfiguration unter Linux eher (und gründlicher) abgeschaltet werden kann.
Hier habe ich jedenfalls im oben stehenden Beispiel auch gleich noch den Aufruf für den Zugriff auf den FTP-Server angehangen ... auch dieser ist auf vielen anderen Wegen realisierbar - es muß nur eine passive Datenübertragung möglich sein und damit fällt der Kommandozeilen-FTP-Client von Windows bereits aus. Allerdings sind eben ein paar Berechnungen auf der Basis der Hauptspeichergröße der FRITZ!Box und der Größe des Images notwendig und diese Berechnungen übernimmt i.d.R. kein anderer "FTP-Client" ... genau für diesen Upload eines bootfähigen Images ist das Skript "eva_to_memory" ja mal entstanden. Das erwartet als ersten Parameter den Namen der zu übertragenden Image-Datei (deshalb haben wir das weiter oben ja direkt in diesem Verzeichnis gespeichert, das erspart uns jetzt die Angabe von Pfaden) und als optionalen zweiten Parameter die IP-Adresse der FRITZ!Box, wobei da "192.168.178.1" verwendet würde, wenn die Angabe fehlt.
Anders als "eva_discover" braucht nun "eva_to_memory" anstelle von "socat" auch nur noch eine Version von "netcat" (unter dem Namen "nc"), wobei hier die "Geschmacksrichtung" aus dem "netcat-openbsd"-Paket die erste Wahl ist. Das "netcat-traditional" (das ist m.W. die GNU-Version) kennt einige der verwendeten Parameter nicht und ich habe bisher keine Lust gehabt, das Skript so abzuändern, daß es auf diese Parameter verzichten könnte. Jedenfalls ist nun "netcat" auch auf durchschnittlichen Linux-Installationen deutlich öfter bereits vorhanden, als das beim "socat" der Fall ist, auch wenn wohl die meisten Distributionen die Installation von "socat" aus einem (Binär-)Repository unterstützen werden.
[...]
... jetzt wäre es (vom Aufbau her) eher an der Zeit, sich dem EVA-Zugriff von einem Windows-System unter Benutzung der PowerShell-Skripte aus dem "eva_tools"-Verzeichnis zu widmen.
==================================================
Auch hier beim Windows will ich mich nicht mit Fragen aufhalten, die mit dem Zugriff auf den Bootloader nur am Rande zu tun haben ... z.B. dem Thema, wie man das erzeugte bootfähige Image nun von der Linux-Maschine, auf der es erstellt wurde, auf irgendein Windows-System mit einer PowerShell bekommt. Was vermutlich nicht funktionieren wird (ich habe es aber auch nicht wirklich probiert), ist die Verwendung der Skripte in der von Canonical mit Microsoft entwickelten "bash"-Shell unter Windows (x64 unter "developer tools"). Das liegt m.E. daran (auch wenn ich es nicht getestet habe), daß dort gar keine echten Treiber für Dateisysteme existieren dürften und das Mounten unseres eigenen Images damit schon fehlschlagen sollte. Wenn es doch funktioniert, bin ich zumindest mal überrascht ... aber zu dem, was unter dieser Shell aus dem YourFritz-Repository benutzbar ist und was nicht, habe ich irgendwo an anderer Stelle schon etwas geschrieben - auch wenn ich selbst nicht mehr weiß, wo das genau war und das will ich jetzt auch nicht suchen und hier verlinken. Zunächst mal reicht es mir, wenn ich meinerseits einfach feststelle, daß diese Skripte nicht für die "bash" unter Windows x64 gedacht sind und jede erfolgreiche Anwendung rein zufällig und von mir nicht beabsichtigt wäre.
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.
Da es ein paar Sicherheitbeschränkungen bei der Benutzung der PowerShell gibt und man als "Hobby-Anwender" sicherlich eher nicht auf die Idee kommen wird, die Skripte irgendwie zu signieren, muß man - nach dem Download der Skripte als Textdatei mit Speichern an irgendeiner Stelle, wo man sie auch wiederfindet - zunächst mal diese Sicherheitseinstellungen korrekt vornehmen (das gilt für jedes PowerShell-Skript und ist nicht spezifisch für die EVA-Skripte) ... auch das ist wieder ein Thema, was mehrfach im Internet beschrieben ist (Stichwort "Set-ExecutionPolicy") und was ich hier nicht noch einmal auswalzen will.
Für die erste Aufgabe beim Kontakt zum Bootloader einer FRITZ!Box (das war das Suchen und Finden der Box) gibt es das Skript "EVA-Discover.ps1", welches - neben den ansonsten noch möglichen Parametern für praktisch jedes Skript - als Parameter "-maxWait" die Anzahl der Sekunden erwartet, die es auf die FRITZ!Box warten soll, wobei hier der Standardwert nur 30 Sekunden sind. Mit "-requested_address" kann man die IP-Adresse für die FRITZ!Box "ansagen" (der Standardwert ist die AVM-übliche 192.168.178.1) und mit "-nohold 1" könnte man auch hier den TCP-Verbindungsversuch zur FRITZ!Box unterbinden ... anders als bei der Linux-Variante nutzt aber das PowerShell-Skript inzwischen eine korrekte FTP-Anmeldung bei dieser Verbindung und das funktioniert dann - nach meiner bisherigen Erfahrung - auch wesentlich besser, weshalb hier auch die Bedeutung des Parameters (und dessen Standardwert) so geändert ist, daß man den Wunsch nach "nicht anhalten" gesondert äußern muß. Mit den Parametern "-Debug" und "-Verbose" kann man ein paar zusätzliche Nachrichten generieren, damit man auch hier die "Warterei" des Skripts sehen kann.
Anschließend steht hier die FRITZ!Box wie eine Eins und man hat alle Zeit der Welt, sich dem FTP-Zugriff zu widmen.
Dazu brauchen wir dann das andere Skript (oben schon mal verlinkt), welches sich auf zwei verschiedenen Wegen benutzen läßt, wie im Skript (derzeit um Zeile 610 herum, das kann sich auch mal etwas verschieben) beschrieben ist. Man kann entweder vor der Benutzung hingehen und die auszuführenden Aktionen (die Liste der bereits implementierten Funktionen steht in der erwähnten Beschreibung) der Reihe nach in die geschweiften Klammern um diesen Kommentarblock herum einfügen, dann braucht man beim Aufruf nur den Parameter "-Address" angeben mit der IP-Adresse der FRITZ!Box und auch das ist nur erforderlich, wenn es nicht die als Standard vorgegebene 192.168.178.1 wäre. Auch hier kann man wieder mit "-Debug" und "-Verbose" etwas mehr an Informationen aus dem Skript herauskitzeln, während es mit der Box kommuniziert.
Da dieses Editieren der Datei etwas unpraktisch sein kann (es sei denn, man hat eine Kopie für einen ganz gezielten Anwendungsfall, die man desöfteren verwenden will), bevorzugt das Skript die Angabe eines "ScriptBlock"-Parameters beim Aufruf. Das ist im Prinzip nichts anderes als die Angabe der aufzurufenden Funktion(en) in geschweiften Klammern ... das aber nicht mit irgendwelchen Anführungszeichen oder ähnlichem, weil das keine Zeichenketten sein sollen. Will man mehrere Aktionen ausführen lassen (z.B. ein TFFS-Image in beide TFFS-Partitionen schreiben lassen, wobei die 7412 auch dort nur eine Partition (mtdnand) hat), trennt man diese mit einem Semikolon innerhalb des Blocks (also innerhalb der geschweiften Klammern). Zusammengesetzt sieht das dann so aus (alle Dateien auf dem Desktop gespeichert, mit "Save as" für die "raw"-Versionen aus GitHub und bitte auch das "unblock" in den Eigenschaften nicht vergessen), wenn man wieder dieselbe Image-Datei in die 7412 laden läßt:
Das war es dann aber auch schon, wenn man die PowerShell-Skripte unter Windows verwenden will - mehr wüßte ich dazu jetzt nicht zu schreiben.
Wenn irgendjemand im Text oben noch Reste der Formatierung aus dem anderen Thread findet, mache er/sie mich bitte darauf aufmerksam ... aber wirklich nur hinsichtlich der (unter Xenforo nicht funktionierenden) Formatierungen. Fehlende Zusammenhänge, die sich daraus ergeben, daß der Text aus einem anderen Beitrag stammt, kann man selbst dadurch herstellen, daß man den anderen Beitrag auch liest.
Der Link auf den originalen Speicherort dieser Anleitung funktioniert nicht mehr, ich habe unter http://yourfritz.de/desc-eva eine Umleitung auf diese Anleitung in der Wayback-Machine angelegt.
-----------------------------------------------------------------------------------------
Der folgende Text ist ein Duplikat aus einem anderen Beitrag, in dem ich vor einiger Zeit mal die Anwendung der Skript-Dateien aus dem Unterverzeichnis "eva_tools" in meinem "YourFritz"-Repository beschrieben hatte. Da der offenbar schwer zu finden ist, ziehe ich den relevanten Teil hier noch einmal heraus und passe die Formatierungen etwas an, weil die XenForo-Software leider nicht alle zuvor verwendeten Features (insb. das Kolorieren von Code-Blöcken) unterstützt. Teile des Textes brauchen ggf. auch den Kontext aus dem anderen Thread, aber ich habe im Moment weder Zeit noch Lust, das noch einmal zu überarbeiten.
Wer nicht weiß, wie er an die beschriebenen Skript-Dateien kommen soll und/oder was ggf. noch passieren muß, damit diese Dateien zur eigenen Linux-Installation passen, kann am Beginn dieses Threads nachlesen.
Wie man ein GitHub-Repository unter Windows klont und was man beim Editieren von Dateien hinsichtlich der unterschiedlichen Zeilenenden unter Windows bzw. Linux (oder anderen "unix-artigen" Systemen) beachten muß, ist nicht Gegenstand dieses Beitrags und auch die Geistesarbeit, den Namen der Image-Datei beim Upload in den Speicher der Box an die eigenen Gegebenheiten anzupassen, bleibt dem Leser überlassen.
Die URL zum YourFritz-Repository wäre jedenfalls die folgende: https://github.com/PeterPawn/YourFritz
==================================================
Hier beginnt jetzt der Text aus dem anderen Thread ...
==================================================
Jedenfalls haben wir nun unser bootfähiges Image auf dem Linux-Rechner liegen und müssen uns nur noch daran machen, es irgendwie auf die Box zu bringen. Dazu verbinden wir den Rechner und die FRITZ!Box mit einem Ethernet-Kabel und hier gabelt sich unser Weg dann, je nachdem, ob wir den Zugriff auf den Bootloader der FRITZ!Box von einem Linux- (oder OS X-) oder einem Windows-System ausführen wollen.
Warum spielt hier Windows überhaupt eine Rolle, wenn wir doch fürs Erstellen des Images ohnehin eine Linux-Installation brauchten? Da komme ich dann wieder auf die oben geschriebenen Zeilen zur GPLv2 zurück und zu dem Gedanken/der Möglichkeit, daß jemand anderes mit einem Linux-System so ein Image für uns vorbereitet haben könnte und wir damit gar kein Linux-System mehr benötigen, um so eine Aktion wie das Umschalten auf "keine Anmeldung erforderlich" auszuführen ... das geht dann also auch mit einem Windows-PC.
Mit anderer Technik aus einem aktuellen Haushalt (Smartphone, Tablet), die auch nicht zum Erstellen eines solchen Images genutzt werden kann, wird es sicherlich auch schwerer, den notwendigen Zugriff über ein LAN-Kabel zu erlangen ... aber auch das wäre machbar, wenn man die FRITZ!Box und einen (autonomen) WLAN-AP (Access Point, also eine WLAN-"Basisstation") miteinander per Kabel verbindet und sich mit seinem WLAN-Gerät am AP anmeldet. Zumindest mit einem (ggf. gerooteten) Android-Gerät sollte das auch funktionieren - das wäre dann aber wieder mehr die Richtung "Linux-System" und bei iOS-Geräten mit Jailbreak läuft es auf dasselbe hinaus (ohne Jailbreak aber dort auch keine eigenen Kommandos in der Shell).
Wenden wir uns also zuerst dem Thema "Linux-System für EVA-Zugriff" zu ... das ist gleichzeitig die erste (und voraussichtlich einzige) Beschreibung meinerseits (jedenfalls in diesem Umfang), wie man die Shell-Skripte aus "eva_tools" benutzen kann.
Beim Zugriff auf den Bootloader einer FRITZ!Box gibt es zwei - eigentlich getrennte - Aufgaben ... einerseits geht es erst einmal darum, eine startende FRITZ!Box im LAN zu finden, sie dann in diesem Modus "festzuhalten" (weil sie nur für 5-10 Sekunden auf eingehende FTP-Verbindungen beim Start wartet) und als zweites geht es dann um die Kommunikation mit dem FTP-Server. Egal ob man auf EVA mit einem Windows-PC oder einem Linux-System zugreifen will ... da eine startende FRITZ!Box ihre Ethernet-Schnittstellen erst einmal aktivieren muß und das System am anderen Ende des Kabels erst dann darüber informiert wird, daß da jetzt "jemand ist", kann jede automatische Netzwerk-Konfiguration, die auf dieses (angenommene) "Einstecken" eines LAN-Kabel reagiert und dann erst einmal per DHCP irgendwelche IP-Adressen für das Interface erfragen möchte, bereits dazu führen, daß die erwähnten 5 bis 10 Sekunden lange um sind, wenn die Netzwerkschnittstelle dann endlich bereit ist, um mit der Box kommunizieren zu können.
Schon aus diesem Grund sollte man - sofern man ein passendes Gerät besitzt, dafür reichen auch alte Gurken für Fast-Ethernet (100 MBit/s) oder sogar solche für 10 MBit/s - irgendeinen Ethernet-Switch (notfalls tut es auch ein Hub und bei der Variante mit dem WLAN-AP wäre auch dieser bereits ausreichend) zwischen FRITZ!Box und PC schalten und auf dem PC dafür sorgen, daß das verwendete Ethernet-Interface bereits eine IPv4-Adresse hat - das kann bei einem Windows-System auch gerne eine APIPA-Adresse aus dem Bereich 169.254.0.0/16 sein (oder das "zeroconf"-Pendant beim Linux).
Wichtig ist nur, daß diese Adresse bereits aktiv ist (also kein bis dahin unkonfiguriertes Interface erst beim "media sensing" auf die Suche nach einer DHCP-Adresse geht) - arbeitet man ohne zusätzliche Hardware zwischen FRITZ!Box und PC, muß man ggf. das "media sensing" im verwendeten PC-Betriebssystem auch abschalten - das Internet hilft bei der Suche, wie das beim eigenen System geht und auch Windows-Benutzer müssen heutzutage dafür nicht mehr in die Tiefen der Registry hinabsteigen; also Vorsicht vor allzu alten "Anleitungen", wie man das über die Registry machen kann - zumal das dann erst nach einem Neustart wirksam wird.
Für den ersten Schritt (das Suchen der FRITZ!Box, bei dieser Suche kann man dann einer FRITZ!Box mit einer bis dahin unbekannten Adresse, die diese im Bootloader benutzt, auch gleich noch eine definierte Adresse zuweisen, die zu Konfiguration des eigenen Ethernet-Interfaces paßt) gibt es Unterstützung von mehreren Seiten ... ich zähle mal ein paar auf, bevor ich mich den Skript-Dateien im YourFritz-Repository für diesen Zweck widme:
- ein "falsches" Recovery-Programm von AVM (gibt es nur für Windows) ... dieses setzt seinerseits eine zum Netzwerk-Interface des Windows-Systems passende IP-Adresse für die Box und hält sie zugleich im richtigen Modus fest, wenn es bei der Kommunikation mit der Box feststellt, daß diese das falsche Modell ist - das ist gerade für "Anfänger" eine nahezu narrensichere Variante, solange da keine "Security-Suite" (aka "Schlangenöl") auf dem Windows-System wieder für zusätzliche Probleme sorgt
- das "ruKernelTool" (näheres hier irgendwo im Forum - i.d.R. schon älter, weil es da mal Streit gab - oder beim Autoren; auch hier hilft die Suche im Internet), welches auch dafür genutzt werden kann, die FRITZ!Box zu suchen, ihre Adresse zu setzen (das macht das Tool etwas eigenwillig und setzt irgendwas mit 99.88.77.xx) und eine FTP-Sitzung zur Box zu starten (die kann man dann einfach beenden und die Box wartet weiter im richtigen Modus, wo man ihr dann mit dem PowerShell-Skript zuleibe rücken kann (*)
- irgendein Perl-Skript (der Name ist mir gerade nicht geläufig) aus der Freetz-Toolchain enthält auch noch den Code, um eine FRITZ!Box per UDP-Broadcast zu suchen ... ob da auch die Adresse gesetzt werden kann, weiß ich nicht mehr
- und "last but not least" habe ich im YourFritz-Repository sowohl für *nix-Systeme (unter Verwendung des Programmes "socat" i.V.m. einer "bash"-Shell) als auch für Windows-Systeme (hier mit PowerShell-Skript) eine Variante "im Angebot", mit der man das auch machen kann (natürlich beschreibe ich unten dann diese Variante - die anderen haben deren Autoren ja schon dokumentiert)
Es ist also gar nicht notwendig, daß man die beiden Schritte (Suchen der Box und "Festhalten" im Bootloader einerseits und die Kommunikation mit dem FTP-Server andererseits) mit demselben Programm erledigt oder auch nur auf derselben Plattform. Wer z.B. kein Linux-System mit einer "socat"-Variante hat (die wird für die UDP-Broadcasts benötigt und ich kenne keine Alternative, die ohne C-Compiler auskommt - womit ich dann wieder beim Thema "zusätzliche Software" bin), kann auch die Box mit einem Windows-System und dem AVM-Recovery-Programm (wie geschrieben, für ein falsches Modell - die Idee dahinter hatte ich hier schon früher beschrieben) bis zu diesem Punkt treiben und dann mit einem anderen System (z.B. einem RasPi mittels einer SSH-Session) mit dem FTP-Server weiter arbeiten.
Will man dann unter Linux (oder OS X, wobei ich das noch nicht getestet habe) mit meinem "eva_discover" arbeiten, braucht man zunächst mal Informationen zu seinen eigenen Netzwerk-Einstellungen. Das Skript an sich ist weit, weit von einer Fertigstellung entfernt ist, das war auch mal in der Vergangenheit nur eine "Prinzipskizze" (vorab für jemanden als Beispiel eingecheckt) mit jeder Menge offener Baustellen bei den Parametern, bis mir dann die Notwendigkeit der wiederholten Betonung dieser Tatsache auf den Geist ging und ich jeden Code zur Erkennung von Einstellungen deaktiviert habe. Damit braucht man jetzt folgende Informationen, wenn man das Skript erfolgreich aufrufen will:
- den Namen irgendeines Netzwerk-Interfaces (als Angabe "INTERFACE=<name>" beim Aufruf) in der verwendeten Maschine ... das muß gar nicht das richtige Interface sein, an dem auch die FRITZ!Box hängt; es ist ein Relikt aus der Zeit, wo einige Parameter noch (bzw. "schon") teilweise "erraten" wurden auf der Basis von anderen und davon ist immerhin noch die Prüfung übrig geblieben, ob der Parameter angegeben wurde (was jetzt "Pflicht ist") und daß es sich um ein vorhandenes Netzwerk-Interface handelt
- die eigene IP-Adresse des Interfaces, über das man auf die FRITZ!Box zugreifen will (als "FROM=<ip>")
- eine zur eigenen Adresse passende Angabe für die FRITZ!Box (als "TO=<ip>"), diese wird dann in der FRITZ!Box "eingestellt"
Optional verkraftet das Skript zum Suchen der FRITZ!Box (das heißt - nebenbei bemerkt - dann "eva_discover") auch noch weitere Angaben:
- eine Angabe, wie lange nach der FRITZ!Box gesucht werden soll (als "WAIT=<n>", wobei "n" die Anzahl der Sekunden ist und hier sind zwei Minuten der Standard) - dabei wird jede Sekunde ein UDP-Broadcast-Paket gesendet, damit eine gerade startende FRITZ!Box so früh wie möglich erkannt wird
- die Angabe, ob schon "eva_discover" eine TCP-Verbindung zum FTP-Port der Box aufbauen soll oder nicht (als "HOLD=<0|1>", wobei "1" für die TCP-Verbindung steht, die sofort wieder beendet wird und nur dazu dient, daß die Box nicht weitermacht im Bootvorgang) - das würde ich in dieser Form nur selten empfehlen ("HOLD=0" ist auch der Standard), weil "eva_discover" selbst kein FTP-Login enthält und die verschiedenen Bootloader (teils auf demselben Modell nach meiner Meinung) durchaus unterschiedlich auf den plötzlichen Abbruch der TCP-Verbindung, wie ihn "eva_discover" praktiziert, reagieren; besser ist es, die Skripte "aneinanderzureihen", so daß der nachfolgende FTP-Zugriff (dort dann inkl. der Anmeldung) innerhalb der Wartezeit erfolgt
- über die Angabe von "BLIP=1" kann man eine Anzeige für jedes als Broadcast gesendete UDP-Paket erhalten ... das ermöglicht die Verfolgung der Aktivitäten von "eva_discover", was ansonsten etwas dröge daherkommt und sich bis zum Auffinden der FRITZ!Box oder bis zum Ablauf der Wartezeit nicht weiter bemerkbar machen würde
Wie man jetzt Interface-Namen und IP-Adressen findet, beschreibe ich hier nicht ... das ist u.a. auch von der Distribution abhängig und definitiv "nicht mein Tisch". Bei mir nehme ich einfach das Interface "vlan1" und die eigene IP-Adresse 192.168.178.2 (mit einer 24er-Maske, die hier aber nicht angegeben wird) - das ergibt dann für die 7412 die Möglichkeit, mit der Adresse 192.168.178.1 (auch hier wieder eine implizierte /24, die aber auch nicht angegeben wird) zu arbeiten. Man kann hier aber wirklich mit jeder beliebigen eigenen Adresse arbeiten und muß sich nur eine dazu passende Adresse der FRITZ!Box "ausdenken", damit die Pakete auch auf dem richtigen Netzwerk-Interface (vorausgesetzt, die Linux-Maschine hat mehr als eines) gesendet werden. Dann sind die anderen Einstellungen auch egal, weil das alles innerhalb derselben L2-Domain arbeiten muß und da spielen dann auch Netzwerk-Masken nur noch eine sehr untergeordnete Rolle. Wir passen hier also die FRITZ!Box an unsere Vorstellungen an und nicht umgekehrt unsere Vorstellungen an die FRITZ!Box.
Wenn das "eva_discover"-Skript die FRITZ!Box nicht finden kann innerhalb der vorgegebenen Zeit, wird "EVA_FOUND=0" auf STDOUT ausgegeben, ansonsten "EVA_FOUND=1" und als "EVA_IP=<ip>" auch die Angabe, welche Adresse die FRITZ!Box jetzt hat. Man kann nämlich mit "TO=0.0.0.0" ihr auch gestatten, die bisher eingestellte Adresse weiterhin zu verwenden - ggf. muß man mit Problemen rechnen, wenn diese bei der eigenen Linux-Maschine auf einem anderen Interface läge, wie es häufig bei "99.88.77.xx" der Fall sein dürfte, da wird wohl in der überwiegenden Zahl der Fälle die "default"-Route zuständig sein. Diese Art der Ausgabe auf STDOUT (alle anderen Ausgaben gehen nach STDERR und sind damit leicht von diesen Angaben zu trennen) macht es auch möglich, den Aufruf einfach in eine Form
Code:
eval $(./eva_discover ...)
if [ "$EVA_FOUND" = "1" ]; then
printf "FRITZ!Box gefunden unter der IP-Adresse %s" "$EVA_IP" 1>&2
./eva_to_memory 7412_skip_auth.image $EVA_IP
else
printf "FRITZ!Box nicht gefunden" 1>&2
fiWir haben also unsere Box "vorbereitet" mit der Verkabelung und sind jetzt zurück in der oben unterbrochenen Linux-Shell-Session:
Code:
linux:/tmp/YourFritz/toolbox $ cd ../eva_tools/
linux:/tmp/YourFritz/eva_tools $ eval $(./eva_discover INTERFACE=vlan1 TO=192.168.178.1 FROM=192.168.178.2 BLIP=1);[ "$EVA_FOUND" = "1" ] && ./eva_to_memory 7412_skip_auth.image $EVA_IP
Found AVM bootloader: AVM EVA Version 1.2605 0x0 0x47409
Found hardware revision: 209
Memory size is 0x08000000 (128 MB)
Memory size limited to 128 MB
Image size is 0xc63e00 (12 MB)
Setting temporary memory size to: 0x0739c200
Setting temporary kernel args to: mtdram1=0x8739c200,0x88000000
Image uploaded to device.Zusatz: Bei den GRX5-Modellen (7560, 7580, 7590) wurde inzwischen beobachtet, daß diese den FTP-Server im Bootloader wohl nur noch dann starten, wenn es sich um ein echtes "PowerOn-Reset" handelt - bei diesen Modellen sollte man also immer den Stecker ziehen und es nicht mit einem "Warmstart" versuchen.
Bisher hat noch jede FRITZ!Box, die ich dabei bewußt beobachtet habe, beim Initialisieren der GPIO-Ports für die Ansteuerung der LEDs alle gleichzeitig kurz aufblinken lassen und danach beginnt die Karenzzeit (wie gesagt, irgendwas zwischen 5 und 10 Sekunden nach meiner Erfahrung), in der man mit der Box Verbindung aufgenommen haben muß. Wenn sich also innerhalb von - sagen wir mal - 15 Sekunden nach dem Herstellen der Stromversorgung noch nichts getan hat (die GRX500-Boxen brauchen wohl länger, was ich auf die angenommene Virtualisierung zurückführen würde), dann ist irgendetwas anderes faul im Staate Dänemark und wenn das auch bei einem zweiten oder dritten Versuch nicht funktionieren will, ist da der Wurm drin und es wird auch beim 20. Versuch (ohne Änderungen) eher nicht funktionieren. Dann gibt es i.d.R. irgendwo einen Fehler, z.B. hängt die Box (oder der dazwischengeschaltete Switch) am falschen Ethernet-Port des Rechners oder es wird doch irgendeine langwierige Autokonfiguration verwendet und die frißt dann schon die verfügbare Karenzzeit. Das ist allerdings bei Windows-PC deutlich häufiger der Fall, weil diese Autokonfiguration unter Linux eher (und gründlicher) abgeschaltet werden kann.
Hier habe ich jedenfalls im oben stehenden Beispiel auch gleich noch den Aufruf für den Zugriff auf den FTP-Server angehangen ... auch dieser ist auf vielen anderen Wegen realisierbar - es muß nur eine passive Datenübertragung möglich sein und damit fällt der Kommandozeilen-FTP-Client von Windows bereits aus. Allerdings sind eben ein paar Berechnungen auf der Basis der Hauptspeichergröße der FRITZ!Box und der Größe des Images notwendig und diese Berechnungen übernimmt i.d.R. kein anderer "FTP-Client" ... genau für diesen Upload eines bootfähigen Images ist das Skript "eva_to_memory" ja mal entstanden. Das erwartet als ersten Parameter den Namen der zu übertragenden Image-Datei (deshalb haben wir das weiter oben ja direkt in diesem Verzeichnis gespeichert, das erspart uns jetzt die Angabe von Pfaden) und als optionalen zweiten Parameter die IP-Adresse der FRITZ!Box, wobei da "192.168.178.1" verwendet würde, wenn die Angabe fehlt.
Anders als "eva_discover" braucht nun "eva_to_memory" anstelle von "socat" auch nur noch eine Version von "netcat" (unter dem Namen "nc"), wobei hier die "Geschmacksrichtung" aus dem "netcat-openbsd"-Paket die erste Wahl ist. Das "netcat-traditional" (das ist m.W. die GNU-Version) kennt einige der verwendeten Parameter nicht und ich habe bisher keine Lust gehabt, das Skript so abzuändern, daß es auf diese Parameter verzichten könnte. Jedenfalls ist nun "netcat" auch auf durchschnittlichen Linux-Installationen deutlich öfter bereits vorhanden, als das beim "socat" der Fall ist, auch wenn wohl die meisten Distributionen die Installation von "socat" aus einem (Binär-)Repository unterstützen werden.
[...]
... jetzt wäre es (vom Aufbau her) eher an der Zeit, sich dem EVA-Zugriff von einem Windows-System unter Benutzung der PowerShell-Skripte aus dem "eva_tools"-Verzeichnis zu widmen.
==================================================
Auch hier beim Windows will ich mich nicht mit Fragen aufhalten, die mit dem Zugriff auf den Bootloader nur am Rande zu tun haben ... z.B. dem Thema, wie man das erzeugte bootfähige Image nun von der Linux-Maschine, auf der es erstellt wurde, auf irgendein Windows-System mit einer PowerShell bekommt. Was vermutlich nicht funktionieren wird (ich habe es aber auch nicht wirklich probiert), ist die Verwendung der Skripte in der von Canonical mit Microsoft entwickelten "bash"-Shell unter Windows (x64 unter "developer tools"). Das liegt m.E. daran (auch wenn ich es nicht getestet habe), daß dort gar keine echten Treiber für Dateisysteme existieren dürften und das Mounten unseres eigenen Images damit schon fehlschlagen sollte. Wenn es doch funktioniert, bin ich zumindest mal überrascht ... aber zu dem, was unter dieser Shell aus dem YourFritz-Repository benutzbar ist und was nicht, habe ich irgendwo an anderer Stelle schon etwas geschrieben - auch wenn ich selbst nicht mehr weiß, wo das genau war und das will ich jetzt auch nicht suchen und hier verlinken. Zunächst mal reicht es mir, wenn ich meinerseits einfach feststelle, daß diese Skripte nicht für die "bash" unter Windows x64 gedacht sind und jede erfolgreiche Anwendung rein zufällig und von mir nicht beabsichtigt wäre.
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.
Da es ein paar Sicherheitbeschränkungen bei der Benutzung der PowerShell gibt und man als "Hobby-Anwender" sicherlich eher nicht auf die Idee kommen wird, die Skripte irgendwie zu signieren, muß man - nach dem Download der Skripte als Textdatei mit Speichern an irgendeiner Stelle, wo man sie auch wiederfindet - zunächst mal diese Sicherheitseinstellungen korrekt vornehmen (das gilt für jedes PowerShell-Skript und ist nicht spezifisch für die EVA-Skripte) ... auch das ist wieder ein Thema, was mehrfach im Internet beschrieben ist (Stichwort "Set-ExecutionPolicy") und was ich hier nicht noch einmal auswalzen will.
Für die erste Aufgabe beim Kontakt zum Bootloader einer FRITZ!Box (das war das Suchen und Finden der Box) gibt es das Skript "EVA-Discover.ps1", welches - neben den ansonsten noch möglichen Parametern für praktisch jedes Skript - als Parameter "-maxWait" die Anzahl der Sekunden erwartet, die es auf die FRITZ!Box warten soll, wobei hier der Standardwert nur 30 Sekunden sind. Mit "-requested_address" kann man die IP-Adresse für die FRITZ!Box "ansagen" (der Standardwert ist die AVM-übliche 192.168.178.1) und mit "-nohold 1" könnte man auch hier den TCP-Verbindungsversuch zur FRITZ!Box unterbinden ... anders als bei der Linux-Variante nutzt aber das PowerShell-Skript inzwischen eine korrekte FTP-Anmeldung bei dieser Verbindung und das funktioniert dann - nach meiner bisherigen Erfahrung - auch wesentlich besser, weshalb hier auch die Bedeutung des Parameters (und dessen Standardwert) so geändert ist, daß man den Wunsch nach "nicht anhalten" gesondert äußern muß. Mit den Parametern "-Debug" und "-Verbose" kann man ein paar zusätzliche Nachrichten generieren, damit man auch hier die "Warterei" des Skripts sehen kann.
Code:
PS C:\Users\PeH> .\Desktop\EVA-Discover.ps1 -maxWait 120 -Debug -Verbose
VERBOSE: Sending discovery packet (1) ...
VERBOSE: Sending discovery packet (2) ...
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
TrueDazu brauchen wir dann das andere Skript (oben schon mal verlinkt), welches sich auf zwei verschiedenen Wegen benutzen läßt, wie im Skript (derzeit um Zeile 610 herum, das kann sich auch mal etwas verschieben) beschrieben ist. Man kann entweder vor der Benutzung hingehen und die auszuführenden Aktionen (die Liste der bereits implementierten Funktionen steht in der erwähnten Beschreibung) der Reihe nach in die geschweiften Klammern um diesen Kommentarblock herum einfügen, dann braucht man beim Aufruf nur den Parameter "-Address" angeben mit der IP-Adresse der FRITZ!Box und auch das ist nur erforderlich, wenn es nicht die als Standard vorgegebene 192.168.178.1 wäre. Auch hier kann man wieder mit "-Debug" und "-Verbose" etwas mehr an Informationen aus dem Skript herauskitzeln, während es mit der Box kommuniziert.
Da dieses Editieren der Datei etwas unpraktisch sein kann (es sei denn, man hat eine Kopie für einen ganz gezielten Anwendungsfall, die man desöfteren verwenden will), bevorzugt das Skript die Angabe eines "ScriptBlock"-Parameters beim Aufruf. Das ist im Prinzip nichts anderes als die Angabe der aufzurufenden Funktion(en) in geschweiften Klammern ... das aber nicht mit irgendwelchen Anführungszeichen oder ähnlichem, weil das keine Zeichenketten sein sollen. Will man mehrere Aktionen ausführen lassen (z.B. ein TFFS-Image in beide TFFS-Partitionen schreiben lassen, wobei die 7412 auch dort nur eine Partition (mtdnand) hat), trennt man diese mit einem Semikolon innerhalb des Blocks (also innerhalb der geschweiften Klammern). Zusammengesetzt sieht das dann so aus (alle Dateien auf dem Desktop gespeichert, mit "Save as" für die "raw"-Versionen aus GitHub und bitte auch das "unblock" in den Eigenschaften nicht vergessen), wenn man wieder dieselbe Image-Datei in die 7412 laden läßt:
Code:
PS C:\Users\PeH> .\Desktop\EVA-FTP-Client.ps1 -Verbose -Debug -ScriptBlock { BootDeviceFromImage .\Desktop\7412_skip_auth.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.2605 0x0 0x47409
================
DEBUG: Sent
GETENV memsize
================
DEBUG: Response:
memsize 0x08000000
200 GETENV command successful
================
DEBUG: Memory size found : 08000000
DEBUG: Image size found : 0x00c63e00
DEBUG: Set memory size to : 0x0739c200
DEBUG: Set MTD ram device to: 0x8739c200,0x88000000
DEBUG: Sent
SETENV memsize 0x0739c200
================
DEBUG: Response:
200 SETENV command successful
================
DEBUG: Sent
SETENV kernel_args_tmp mtdram1=0x8739c200,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 '.\Desktop\7412_skip_auth.image' to '0x8739c200 0x88000000' ...
DEBUG: Sent
P@SW
================
DEBUG: Response:
227 Entering Passive Mode (192,168,178,1,12,2)
================
DEBUG: Sent
STOR 0x8739c200 0x88000000
================
DEBUG: Response:
150 Opening BINARY data connection
================
DEBUG: Response:
226 Transfer complete
================
TrueDas war es dann aber auch schon, wenn man die PowerShell-Skripte unter Windows verwenden will - mehr wüßte ich dazu jetzt nicht zu schreiben.
Wenn irgendjemand im Text oben noch Reste der Formatierung aus dem anderen Thread findet, mache er/sie mich bitte darauf aufmerksam ... aber wirklich nur hinsichtlich der (unter Xenforo nicht funktionierenden) Formatierungen. Fehlende Zusammenhänge, die sich daraus ergeben, daß der Text aus einem anderen Beitrag stammt, kann man selbst dadurch herstellen, daß man den anderen Beitrag auch liest.
Zuletzt bearbeitet:
