Da hat der FTP Client immer gesagt, invalid command.
Dann war das wohl der falsche FTP-Server oder vielleicht doch auch nur das falsch verstandene und falsch verwendete Kommando.
Der FTP-Server in EVA geht zwar manchmal gar nicht (zumindest bei einigen Bootloader-Versionen), wenn das TFFS einfach nur zerschossen wurde ... aber daß der am Ende behauptet, er kenne die Kommandos "RETR env" und "RETR count" (meinetwegen auch "RETR config", wobei das ja nicht wirklich gebraucht würde, um ein TFFS-Image zu bauen) gar nicht, wäre eher neu.
Nun stellt sich natürlich die Frage, ob das schon bei der Eingabe im FTP-Dialog so falsch verwendet wurde, wie es in #108 steht (oder ob nur die "Beschreibung" hier im Thread die falsche ist) ... welche (dann offensichtlich falsche) Anleitung/Erklärung behauptet denn, daß man auf die korrekte Schreibweise der Kommandos keine Rücksicht nehmen müsse?
Code:
vidar:/home/GitHub/YourFritz/eva_tools $ ./eva_discover INTERFACE=vlan1 FROM=192.168.178.2 TO=192.168.178.1 BLIP=1;nc 192.168.178.1 21
EVA_FOUND=1
EVA_IP=192.168.178.1
220 ADAM2 FTP Server ready
USER adam2
331 Password required for adam2
PASS adam2
230 User adam2 successfully logged in
SYST
215 AVM EVA Version 1.3125 0x0 0x36409
MEDIA FLSH
200 Media set to MEDIA_FLASH
retr ENV
502 Command not implemented
RETR env
425 can't open data connection
QUIT
221 Thank you for using the FTP service on ADAM2
221 Goodbye.
vidar:/home/GitHub/YourFritz/eva_tools $
Ich habe auf die tatsächliche Übertragung von Daten verzichtet, weil der Unterschied zwischen den beiden eingegebenen "RETR"-Versuchen hoffentlich augenfällig ist, auch im Hinblick auf die Antworten des Servers.
Wenn es aber schon an solchen "Kleinigkeiten" scheitert, würde ich (egal, wie das jetzt wieder ankommen mag) erst mal die Empfehlung mit dem "auf den Hosenboden setzen" aussprechen ... nach einigem Lesen kommen einem dann auch wieder passende Ideen, woran es ansonsten noch liegen könnte.
Da bei der Verwendung von "eva_get_environment" die Kommandos ja normalerweise in der korrekten Schreibweise abgesetzt werden, wird die Box wohl wirklich keine Daten mehr liefern ... wobei auch hier der Blick in die Log-Datei für das Skript (die heißt dann "eva_get_environment_session.log") ja eigentlich nicht schaden würde. Ob jetzt der FTP-Dialog nicht korrekt abläuft oder die Datenverbindung nicht richtig geöffnet wird (und dann irgendwann nur ein Timeout auftritt) oder ob da tatsächlich 0 Byte Daten (in kurzer Zeit) gesendet werden oder ob gar nur das Schreiben der Ausgabedaten (wenn da eine Umleitung beim Aufruf erfolgte, was bei der Idee mit der Weiterverarbeitung der Daten ja naheliegend wäre) irgendwie schiefgeht, MUSS man ja nicht unbedingt mit Raten ermitteln, wenn man es auch nachlesen kann ... die "Trefferrate" ist einfach viel höher dabei.
Müßte ich raten (und eigentlich muß man das ja, angesichts der fehlenden Infos), würde ich auf irgendwelche Versuche des Vorgängers tippen, die Einstellungen in MTD3 und MTD4 durch den - immer wieder gerne genommenen - Unfug mit dem Speichern einer leeren Datei in diesen Partitionen zu löschen (dieser Quatsch ist offenbar auch nicht auszurotten - aber selbst schuld, wer auf so etwas dann hereinfällt). Das führt dann nicht bei allen Bootloader-Versionen zu dem Problem, daß der FTP-Server der Box gar nicht mehr erreichbar ist, weil die ARP-Pakete Unsinn enthalten (das altbekannte "0x00, "-Problem) ... bei manchen gibt das dann auch nur ein "generisches Environment", das sich zum Teil aus den "Geburtsdaten" der Box speist (daher könnte auch in diesem Zustand noch das "kdg" kommen) und zum Teil (bei noch aussichtsloserer Lage für den Bootloader) aus "noch generischeren" Angaben, die praktisch in jedem EVA-Bootloader (quer durch alle Modelle) dieselben sind (da steht dann eine "maca" von "00:04:0E:FF:FF:01").
Wobei die Box auch mit dem generischen Environment eigentlich starten müßte, solange das "Branding" zur installierten Firmware paßt ... da tippe ich jetzt mal (reiner Erfahrungswert, nicht persönlich gemeint, aber auch auf dem oben Stehenden mit den falschen FTP-Kommandos basierend) auf weitere (hoffentlich unbewußte) Fehler in der Anwendung der (passenden) Tools - wobei das ja eigentlich auch alles mit irgendwelchen Fehlermeldungen verbunden sein müßte, die man als jemand, der von sich denkt: "Ich kriege das schon hin." ja wohl eher nicht einfach nur ignorieren würde, oder?
Insofern habe ich zwar einige solcher "Vermutungen", aber irgendein Fakt oder irgendeine Überlegung paßt da jeweils nicht ... damit wäre es an Dir, da "Licht ins Dunkel" zu bringen, indem Du einfach deutlich ausführlicher beschreibst, was Du eigentlich machst und die Ergebnisse vielleicht nicht nur in Prosa, sondern in Protokolle kleidest.
Dann sollte man eine FRITZ!Box, die offenbar noch reagiert und erreichbar ist im Bootloader, auch wieder zum Leben erwecken können; ja, selbst bei den Modellen mit dem "0x00, "-Fehler ist das machbar (habe ich selbst auch schon mehrfach ausgeführt). Ob die Box dann tatsächlich das notwendige neue Zertifikat hat, um mitsamt dem CM genutzt zu werden, steht auf einem ganz anderen Blatt.