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

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
15,138
Punkte für Reaktionen
1,703
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:

  • 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)
(*) Warum ich kein echter Fan des "ruKernelTool" bin, kann man im anderen Thread nachlesen, das habe ich hier weitgehend entfernt.

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
fi
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:
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.
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.
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
True
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:
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

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

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.
 
Zuletzt bearbeitet:
Ich hab den Thread direkt 'Sticky' gesetzt.

Danke dafür

Möchtest Du diesen Thread als reines HTD (geschlossen) oder als Diskussionsthread?
 
Meinetwegen kann er offenbleiben ... wenn es zuviel (OT-)Diskussion wird, kann man ihn ja sicherlich immer noch abtrennen. Es ist auch nicht ausgeschlossen, daß ich den doch noch einmal etwas überarbeite - einiges macht eben nur im Kontext "Kennwort vergessen" Sinn. Aber im Moment habe ich eben keine Zeit dazu ... wenn er zu wäre, könnte ich ja später selbst auch nicht mehr ändern (zumindest war das bisher so).
 
Ich habe den Text jetzt bislang nur überflogen...

Wie sich die Editierbarkeit verhält weißt Du scheinbar besser als ich.

Gerne kannst Du mich anschreiben, wenn Du eine Aktualisierung 'offline' fertig hast oder es lässt sich ggf. ja doch via xenforo regeln...
 
Ich schliesse mich dann hier an, hoffe es passt hier besser her.

Stehe jetzt leider an, Flash schlägt fehl. Box wie mir scheint im Bootloop, erreiche sie nicht mehr unter 192.168.178.1
Auf den Bootloader komme ich wieder.

Code:
PS F:\> .\EVA-Discover.ps1
EVA_IP=192.168.178.1
True

PS F:\> .\EVA-FTP-Client.ps1 -Verbose -Debug -ScriptBlock { BootDeviceFromImage .\7590_06.92-freetz-devel-14596M.de_20180214-212131.image.in-memory }
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     : 0x01785100
DEBUG: Set memory size to   : 0x0687af00
DEBUG: Set MTD ram device to: 0x8687af00,0x88000000
DEBUG: Sent
SETENV memsize 0x0687af00
================
DEBUG: Response:
200 SETENV command successful

================
DEBUG: Sent
SETENV kernel_args_tmp mtdram1=0x8687af00,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 '.\7590_06.92-freetz-devel-14596M.de_20180214-212131.image.in-memory' to '0x8687af00 0x88000000'
...
DEBUG: Sent
P@SW
================
DEBUG: Response:
227 Entering Passive Mode (192,168,178,1,12,0)

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

================
SendCommand : Ausnahme beim Aufrufen von "Flush" mit 0 Argument(en):  "In die Übertragungsverbindung können keine
Daten geschrieben werden: Eine vorhandene Verbindung wurde vom Remotehost geschlossen."
In F:\EVA-FTP-Client.ps1:670 Zeichen:21
+                     SendCommand "QUIT"
+                     ~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: ( : ) [SendCommand], MethodInvocationException
    + FullyQualifiedErrorId : IOException,SendCommand

Box ist eine 7590, A-CH Version (!), originale FW war 6.83.

Krieg ich eine freetz-06.92 überhaupt auf die Box? Mir kommen da gerade Zweifel.
DSL muss nicht funktionieren hier (es kann daher auch die D-Version sein).

Auch war die aktive Partition bisher nicht gesetzt (Box ist neu und hatte bisher kein Firmware Update):

Code:
ftp> quote GETENV linux_fs_start
501 environment variable not set

Habe trotzdem geswitched und dann den Reboot vergessen:

Code:
PS F:\> .\EVA-FTP-Client.ps1 -ScriptBlock { GetEnvironmentValue firmware_version }
avme
PS F:\> .\EVA-FTP-Client.ps1 -ScriptBlock { SwitchSystem }
True

Nun komm ich zwar wieder zum Bootloader, das Skript gibt jetzt aus:

Code:
PS F:\> .\EVA-FTP-Client.ps1 -ScriptBlock { GetEnvironmentValue linux_fs_start }
1

Was kann ich machen?

fritz.box_7590.06.92.recover-image.exe verweigert ein Recover wegen nicht kompatibler Box. :(
 
@rolex0815
Das ist hier aber OT!

Dein Problem ist wohl, dass du versucht auf eine Box mit firmware_version=avme ein Image für eine deutsche Box mit firmware_version=avm/1und1 (nicht avme) zu installieren, das endet natürlich in einem Bootloop.
Entweder du verwendest eine internationale Firmware oder du passt die deutsche Firmware entsprechend an damit sie die Bootloadervariable "firmware_version" ignoriert.

fritz.box_7590.06.92.recover-image.exe verweigert ein Recover wegen nicht kompatibler Box. :(
Logisch, das ist das Recovery-Tool für die deutsche Box. Du musst aber das Recovery-Tool für die internationale Version verwenden!
 
  • Like
Reaktionen: rolex0815
//verschobener Beitrag//

ein Umschalten von linux_fs_start hätte doch vollkommen gereicht wie @oldmen schon schrieb. und das noch ohne Settingsverlust.

Hallo,

gibt es inzwischen auch eine Lösung mit Windows-Bordmitteln?
Stichwort: Coming soon ... the same comfort for Windows users, based on some PowerShell scripts.
 
Zuletzt bearbeitet von einem Moderator:
Habe es mit dem Dos Promt als admin versucht.
Allerdings wurde das PW für den Benutzer ADAM2 nicht akzeptiert (User und PW sind meines Wissens doch gleich "ADAM2", oder?)
 
ja aber klein

https://github.com/PeterPawn/modfs/blob/master/BOOTSELECTION.ger ZEILE 85-102 schrieb:
C:\Windows\system32>ftp 192.168.178.1
Connected to 192.168.178.1.
220 ADAM2 FTP Server ready
User (192.168.178.1:(none)): adam2
331 Password required for adam2
Password:
230 User adam2 successfully logged in
ftp> quote GETENV linux_fs_start
linux_fs_start 1

200 GETENV command successful
ftp> quote SETENV linux_fs_start 0
200 SETENV command successful
ftp> quote REBOOT
221 Thank you for using the FTP service on ADAM2
221 Goodbye.
Connection closed by remote host.
ftp> bye
 
Zuletzt bearbeitet:
  • Like
Reaktionen: bino
@bino verwendest Du das PowershellScript von @PeterPawn oder doch manuell?

Denn wenn nicht via Script, passt es hier nicht rein und es müsste nochmals verschoben werden.
 
Hallo STONEY,

Bisher habe ich es mal manuell über die DOS-Eigabeaufforderung versucht.
Die PowerShell soll ja der Nachfolger der DOS-Eigabeaufforderung sein.
Mir ist aber nicht klar worin dieser besteht.

Ein Skript für Bash unter Windows 10 wäre für mich eigentlich der beste Weg.
Dazu habe ich aber bisher noch nichts im Forum gefunden.
 
gibt es inzwischen auch eine Lösung mit Windows-Bordmitteln?
Was verstehst Du darunter genau? [ Das Zitat stammt ja offenbar aus meiner Änderung der "BOOTSELECTION.ger" vom 26.04.2016 - den letzten Satz sollte ich vermutlich endlich mal entsorgen. ]

PowerShell ist für mich unter Windows ein "Bordmittel" und die beiden dafür bisher bereitgestellten Skripte sind in #1 auch durchaus "Thema".

Oder meinst Du die derzeit als "work in progress" laufende Implementierung für Windows-Benutzer auf der Basis von C# für die Benutzung mit dem .NET-Framework? (https://github.com/PeterPawn/YourFritz/commits/EVA)

EDIT: OK, ich habe den Hinweis auf "EVA-FTP-Client.ps1" mal in die "BOOTSELECTION.ger" noch mit eingebaut und das "coming soon" entfernt - das "soon" war ja schließlich schon der 27.04.2016; immerhin doch ein Tag (wieviele Stunden, schaue ich jetzt nicht nach), nachdem ich den monierten Satz in die "BOOTSELECTION.ger" geschrieben hatte.
 
Zuletzt bearbeitet:
Hallo PeterPawn,
Danke für Deine Antwort.

Ich möchte eigentlich (nur) einen möglichst einfachen bzw. komfortabelen Weg beschreiten,
um zwischen den beiden Bootpartitionen umschalten zu können,
 
Wie gesagt ... sehr viel einfacher als das "SwitchSystem" in "EVA-FTP-Client.ps1" geht es eigentlich nur noch dann, wenn man die Suche der startenden FRITZ!Box im LAN auch noch in das Skript integriert - da bin ich zwar (endlich) dran, aber das wird noch dauern.

Bis dahin muß dann das o.a. SwitchSystem eben ausreichen, zumal man das problemlos selbst mit "EVA-Discover.ps1" in einem eigenen Skript der Reihe nach aufrufen kann und die drei Zeilen hintereinanderzuschreiben, sollte jeder selbst hinbekommen. Die Vorbereitungen (Set-ExecutionPolicy) muß man ja auch selbst treffen ...
 
Ich verzweifele noch an dem EVA-Discover.ps1 Skript. Während ich mit Knoppix sofort mit eva_discover sofort die startende Fritzbox findet, meldet das Powershell-Skript nie, dass es eine Fritzbox findet. Die Konfiguration ist völlig unverändert (PC,Switch,FB). Ich habe schon das Skript als Administrator gestartet, den Virenscanner desaktivert und die Firewall disabled. Bevor ich mit Wireshark dran gehe, würde ich gerne hören, ob jemand ähnlich Probleme unter Windows hat (Version 1803 if this matters)???

Der zweite Punkt ist mehr eine Verständnisfrage:

Will man die "env" Daten auslesen, dann gelingt das wohl nur mit Hilfe von zwei "nc/netcat" Prozessen.
Nachdem man sich mit dem einen nc-Prozess an der FB angemeldet hat und alles "vorbereitet" hat,
muss man den zweiten nc-Prozess im Hintergrund starten mit "nc -d -w 60 192.168.178.1 9393 &" (das funktioniert sogar unter windows mit "start /b" !).

Wenn man dann "RETR env" in ersten Fenster startet, erscheinen im zweiten die env Daten.

Was ich nicht verstehe, wo die Portnummer 9393 eingetragen ist oder hat dies der Programmierer von AVM eingetragen hat?

Wieso macht es AVM überhaupt so schwer an diese Informationen zu kommen?

Danke im Voraus
Eberhard
 
Schau Dir mal das RFC zum FTP-Protokoll an und den Aufbau der Nachricht "227 Entering passive mode ..." ... da findest Du dann (in den letzten beiden Bytes in der Klammer) auch den Port (der erste Wert ist mit 256 zu multiplizieren).

Ansonsten macht vermutlich "eva_get_environment" genau das, was Du da von Hand mit zwei "nc"-Prozessen durchführen willst.

Ich habe (wenn Zeit ist) im Moment immer mal wieder eine neuere Version für PowerShell in der Mache, die auch unter Linux einsetzbar ist (Zwischenergebnisse gibt es im "EVA"-Branch des Repos) ... die braucht aber noch etwas Zeit, auch wenn "discovery" schon recht leidlich läuft.

Woran es jetzt bei Dir unter Windows scheitert, kann man aus der Beschreibung nicht erkennen ... wenn Du W10 1803 verwendest, kann es eigentlich auch nicht an zu alten PS-Versionen scheitern.
 
Vielen Dank für die Erklärung. Man lernt halt immer wieder dazu!

Ich werde noch einmal in den Branch schauen.

eva_get_environment ist halt linux basierend und ich brauche das Ganze leider für Windows.

Mit ncftpget (gibt's für Win/Unix/MAC) bekommt man die env Daten in einem Rutsch:

ncftpget -d stdout -t 5 ^
-o doNotGetStartCWD=1,useFEAT=0,useHELP_SITE=0,useCLNT=0,useSIZE=0,useMDTM=0 ^
-W "quote MEDIA SDRAM" ^
-W "quote RETR env" ^
-u adam2 -p adam2 ^
-C 192.168.178.1 ^
env env.txt

Die counter Daten sollten genauso zu holen sein.

Eberhard
 
Für Windows ist das Laden und Schreiben von Dateien im PowerShell-Skript "EVA-FTP-Client.ps1" realisiert und ich habe bisher auch noch nichts von (unüberwindbaren) Problemen bei dessen Nutzung gelesen.

Daher würde ich mir nun nicht extra noch "ncftp" installieren und damit "mixen" ... wenn die "ncftp"-Programme dann die Erkennung der FRITZ!Box im Netzwerk gelernt haben, überdenke ich diese Ansicht ggf. noch einmal.

Jedenfalls reduziert sich der Aufruf zum Laden der Environmentdaten mit "EVA-FTP-Client.ps1" dann auch auf:
Code:
.\EVA-FTP-Client.ps1 -ScriptBlock { GetEnvironmentFile }
, optional noch von einem "count" gefolgt, weil "env" der Standardwert für den Namen der zu lesenden Datei ist. Das finde ich (persönlich) jetzt einfacher, kürzer und weniger "fehlerträchtig" als den Aufruf von "ncftpget" oben ... erst recht dann, wenn man ansonsten schon mit "EVA-Discover.ps1" als PS-Skript arbeiten sollte oder will.
 
Ich musste bei mir die Netzwerkeinstellung so wählen, dass man unter Windows per ping die FB beim Starten erkennt (IP des PCs:192.168.178.x / NM 24).

Ich würde auch nicht mir die Mühen machen, wenn nicht schon das Powershell-Skript EVA-Discover.ps1 nicht das tut, was es soll.

Eberhard
 

Statistik des Forums

Themen
244,696
Beiträge
2,216,702
Mitglieder
371,316
Neuestes Mitglied
realbluethunder
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.