[Gelöst] Freetzen einer 7590 mit FW 7.12

JohnDoe42

Aktives Mitglied
Mitglied seit
17 Mrz 2009
Beiträge
1,466
Punkte für Reaktionen
3
Punkte
38
Hallo zusammen,

eigentlich habe ich die Aufgabe schon (EVA-FTP-Client.ps1) gelöst, wollte aber doch noch einmal nachfragen:
Bei einer frisch aus dem Karton gepackten 7590 mit FW 7.12 gibt es unter System->Update keine Möglichkeit mehr, ein Update-Image anzugeben.
Das heißt, man gelangt garnicht erst zu der Stelle des Meckerns über ein unsigniertes Image.
Gibt des aktuell nur noch diese Möglichkeit via ADAM2, ein Freetz-Image auf eine 7590 zu Flashen oder habe ich etwas übersehen / überlesen ?
Grüße,

JD.
 
Zuletzt bearbeitet:
Zuletzt bearbeitet:
Okay, danke!
 
Gibt des aktuell nur noch diese Möglichkeit via ADAM2, ein Freetz-Image auf eine 7590 zu Flashen oder habe ich etwas übersehen / überlesen ?
Jein. Ein für die aktuell laufende Firmware gültig signiertes Firmware-Image kann nach wie vor über das Webinterface installiert werden (also man kann nach wie vor ein Update-Image manuell angeben). Vorausgesetzt natürlich man hat die erweiterte Ansicht aktiviert.

Für den "Initial-Flash" einer modifizierten Firmware (in dieser kann man ja dann seinen eigenen Schlüssel mit einbauen für die Überprüfung der Signierung bei zukünftigen Updates) bietet sich jedoch der Bootloader an.
 
nachdem darauf noch niemand einging
Bei einer frisch aus dem Karton gepackten 7590 mit FW 7.12 gibt es unter System->Update keine Möglichkeit mehr, ein Update-Image anzugeben.
Es muss die erweiterte Ansicht in der F!B erst aktiviert werden. Wobei das auch die Signierung nicht umgeht, wie bereits genannt, aber diese Frage (so gestellt) ist somit beantwortet.
 
@stoney, @NDilPP:

Mea culpa. Ich hab' das so lange nicht mehr gemacht, dass mir dieser offensichtliche Teil glatt entfallen ist.
Trotzdem danke.
Ich versuche, ins Freetzen jetzt wieder ein bischen Übung 'reinzubringen. ;-)
(OT: Um ehrlich zu sein ist mir am Freetzen primär die Lust etwas vergangen, als das ursprüngliche Projekt begann zu divergieren oder auch zu sterben. Aber das gehört nicht hierher)
 
Ich habe meine Fritzbox 7590 mit 7.12 gefreezt und läuft super
 
  • Like
Reaktionen: gismotro
Ich habe mir gerade neu eine 7590 mit 7.12 geleistet und will die jetzt natürlich ebenfalls freetzen.

Ich habe nur das Problem, dass ich nachdem ich mich per ftp beim ADAM angemeldet habe und versuche, das kernel.image draufzuschieben, die Box die Verbindung kappt und neu bootet.
Also ich mache folgendes: ich boote die Box und warte darauf, dass sie "auftaucht" - dann verbinde ich mich händisch per ftp (von Ubuntu 18.04 aus). Das alles samt Einloggen funktioniert...
Dann im ftp:
Code:
ftp> bin
200 Type set to BINARY
ftp> passive
Passive mode on.
ftp> quote MEDIA FLSH
200 Media set to MEDIA_FLASH
ftp> put kernel.image mtd1
local: kernel.image remote: mtd1
227 Entering Passive Mode (192,168,178,1,12,16)
150 Opening BINARY data connection
netout: Connection reset by peer
421 Service not available, remote server has closed connection
Beim letzten Schritt beginnt die Übertragung, dann sehe ich an den LEDs, dass er neu bootet - da bricht dann auch schon die Verbindung ab...

Aber warum?
 
@Massa :

Ich glaube, dass das wie "früher" via FTP mit den neueren Boxen qua Dual Boot nicht mehr so einfach geht, da Du meines Erachtens nach mindestens vor dem Flashen die Zielpartition aussuchen musst.
Aber guck mal hier, das sollte für eine 7590 genau so funktionieren.
 
Weil Du einfach nur Glück hattest, daß die Box sich nicht darum schert, was Du ihr da für Unsinn "aufgeben" willst?

Ich empfehle hier "Lesen" und zwar VOR dem ersten Schritt. Die AVM-Geräte, bei denen ein Schreiben nach "mtd1" noch Sinn ergibt, sind entweder sehr alt (bis 7390) oder sehr beschränkt in ihren Möglichkeiten (wg. bewußt reduzierter Hardware, wo dann auch mal 32 MB SPI-Flash reichen müssen für ein Gerät).

Eine 7590 ist eigentlich keins von beidem ... sie ist weder alt, noch "auf das Nötigste" reduziert und so geht es deren Besitzern wie allen anderen seit einigen Jahren, wenn sie eine eigene Firmware darauf installieren wollen - sie müssen sich erst einmal etwas "einarbeiten".

Es gab auch schon Leute, die sich bei solchen Aktionen eben die 7590 richtig zerschossen haben: https://www.ip-phone-forum.de/threads/fritzbox-7590-bootloader-defekt-nach-flashversuch.299062/ - insofern solltest Du heute noch feiern, wenn/daß das bei Dir nicht passierte und Dich ab morgen dann mit den Änderungen vertraut machen.
 
@PeterPawn: O.K., kannst Du mich dann bitte mit der Nase auf die korrekten Seiten stoßen, bei denen ich nachlesen soll - ich finde hier nur veraltete Dinge (In den ganzen FAQs, Wiki-Seiten etc. zu freetz oder freetz-ng steht - wenn überhaupt - die von mir verwendete Methode noch drin)...
....oder nicht passende Dinge.

Ich habe jetzt mal unter Windows versucht Dein Eva-Discover.ps1 zu verwenden - das findet aber die Box nicht (da kommt dann am Schluss immer
EVA_IP= FALSE
Unter Linux bekomme ich das eva_discovery überhaupt nicht zum Laufen.

Das Recoverytool von AVM findet die Box auch nicht.

Du schreibst im anderen, von @JohnDoe42 angemerkten Thread "oder Du nimmst dazu einfach ein "falsches Recovery-Programm" (alles zig-mal hier beschrieben, wie und warum das am Ende funktioniert)." - auch da kann ich nichts wirklich passendes finden.
Aber wahrscheilich bin ich einfach zu doof zum Suchen...

Ich lese gerne und bilde mich weiter - aber ich habe überhaupt keine Lust, Seiten über Seiten zu lesen, die im Endeffekt nichts sinnvolles beschreiben bzw. veraltete, nicht mehr funktionierende Dinge enthalten.
 
Eine Ebene höher findest Du z.B. einen angepinnten Thread (zu meinen Skripten) und wenn Du bei einer Suchmaschine die Ergebnisse auf dieses Board beschränkst, findest Du auch zig andere Threads, wo die Leute ihre 7590 mit Freetz versehen wollten ... die sind (fast immer) auch zu einem Ergebnis gekommen - mal mit meinem Ansatz, mal mit einem anderen und die Verweise auf die Anleitung von @qwertz.asdfgh sind eigentlich auch kaum zu überlesen, selbst wenn da ggf. die Links nicht mehr stimmen.

Aber es gibt inzwischen auch genug Threads, wo dann Links über die Redirections gesetzt wurden ... und die funktionieren auch heute noch (u.a. findest Du auch einen in dem von @JohnDoe42 in #9 verlinkten Thread). Und nachdem Du ja offenbar - nach der Signatur zu urteilen - bei Dir auf Freetz-NG setzt, käme ja auch das dort verwendete Tool in Frage, das nach einigen Korrekturen seit Anfang Dezember 2019 auch 7590-Boxen flashen können sollte.

Aber ich wage mal die Behauptung, daß es nicht wirklich sinnvoll ist, nach dem ersten Mißerfolg mit irgendeinem Tool (egal, welches es ist) einfach zum nächsten zu greifen ... es sei denn, man weiß genau, daß das Problem am verwendeten Tool liegt. Aber spätestens nach dem ersten Fehlschlag mit einem zweiten Tool sollte man dann noch einmal innehalten und sich selbst hinterfragen.

Angesichts der Tatsache, daß viele aber (auch mit meinen Skripten) zum Erfolg kommen, würde ich eher darauf schließen, daß Du etwas falsch machst bei der Verwendung der Werkzeuge (wenn weder die PS- noch die Shell-Version bei Dir funktioniert). Da erscheint es dann unwahrscheinlich, daß Du dieselben Fehler beim nächsten Tool nicht ebenfalls machst ... ich würde hier also nicht automatisch die "Schuld" bei den Tools suchen, sondern eher mein eigenes Setup noch einmal überprüfen, ob ich tatsächlich allen Hinweisen gefolgt bin, die da standen.

Und man muß tatsächlich nicht Seiten über Seiten lesen ... die korrekte Vorgehensweise hat sich seit dem Erscheinen der ersten 7590 nicht geändert und ist sogar noch dieselbe wie bei der 7580 bzw. 7560. Da das die ersten Boxen mit dieser Architektur waren, kann es tatsächlich mal sein, daß irgendein Thread gar nicht explizit auf die 7590 zielt - es wäre ja auch ziemlich dumm gewesen, bei der 7580 bzw. 7560 erst mal so lange zu warten, bis die 7590 endlich erschienen war, um dann die gesammelten "Erkenntnisse" zu präsentieren.

Man muß halt manchmal etwas nachdenken und sich ggf. erst mal überlegen, wonach man eigentlich suchen sollte. Nur ist das eben nicht meine Aufgabe - also nicht böse sein, wenn ich die auch nicht übernehmen will.

Ich habe nur Deine Frage aus #1 beantwortet, warum das bei Dir (glücklicherweise) nicht funktioniert hat - daraus kann man keine Verpflichtung für mich ableiten, das jetzt noch einmal zu beschreiben und auch nicht, die betreffenden Threads jetzt herauszusuchen ... ich habe tatsächlich auch kein eigenes "Verzeichnis" der Beiträge zu diesem Thema und es stammen auch nicht alle von mir (und für die von anderen habe ich erst recht kein solches Verzeichnis).

Vielleicht kann Dir ja schon geholfen werden, wenn Du einfach mal "aufschreibst", wonach Du gesucht hast und womit Du dann:
nur veraltete Dinge (In den ganzen FAQs, Wiki-Seiten etc. zu freetz oder freetz-ng steht - wenn überhaupt - die von mir verwendete Methode noch drin)...
....oder nicht passende Dinge.
gefunden hast. Dann könnte man Dir u.U. zeigen, wie eine solche Suche besser zu realisieren wäre.

Ich will also auch gar nicht Deinen Willen, Dich intensiver damit zu befassen, in Zweifel ziehen ... aber suchen solltest Du halt auch alleine und nachdem Dir jetzt die "Blauäugigkeit" Deiner ersten Versuche bewußt sein sollte, wirst Du ja sicherlich auch nicht gleich im ersten Beitrag eines von Dir gefundenen Threads (solange der kein "HowTo" sein soll) DIE LÖSUNG erwarten und alles, was da steht, sofort nachmachen. Spätestens beim Weiterlesen findet man dann i.d.R. auch heraus, was die "Vorgänger" jeweils falsch gemacht haben und weiß dann, was man selbst vermeiden sollte.
 
@Massa :
Hast Du das Flashen via EVA-FTP-Client.ps1 versucht ? Falls Ja: Was war das Ergebnis ?
 
Aber ich wage mal die Behauptung, daß es nicht wirklich sinnvoll ist, nach dem ersten Mißerfolg mit irgendeinem Tool (egal, welches es ist) einfach zum nächsten zu greifen ... es sei denn, man weiß genau, daß das Problem am verwendeten Tool liegt. Aber spätestens nach dem ersten Fehlschlag mit einem zweiten Tool sollte man dann noch einmal innehalten und sich selbst hinterfragen.
da hast Du natürlich vollkommen recht.
Ich denke, ich habe bereits bei meinem ersten Versuch mit dem direkten ftp-Flashen etwas zerschossen und habe jetzt eine dauerhafte Bootloop.

Angesichts der Tatsache, daß viele aber (auch mit meinen Skripten) zum Erfolg kommen, würde ich eher darauf schließen, daß Du etwas falsch machst bei der Verwendung der Werkzeuge (wenn weder die PS- noch die Shell-Version bei Dir funktioniert).
Da hast Du absolut recht - ich denke prinzipiell, dass ich etwas falsch gemacht habe, bevor ich die "Schuld" bei den Tools suche. Ich habe halt nur das Problem gehabt, dass an den Stellen, wo ich gelesen habe, nirgends definitiv stand, dass es _so_ nicht mehr mit aktuellen Boxen funktioniert; deswegen bin ich davon ausgegangen, dass die Methode immer noch funktioniert - nur halt etwas umständlich ist.
Dass dem nicht so ist, habe ich erst hier in diesem Thread erfahren - und jetzt bin ich nach Studium einiger Seiten durchaus ein wenig schlauer - weiß nur leider immer noch nicht, warum die "Auffinde-Tools" (avm-recovery, EVA-Discovery) die Box nicht entdecken...

Man muß halt manchmal etwas nachdenken und sich ggf. erst mal überlegen, wonach man eigentlich suchen sollte.
Tja, wenn man schon einige verschiedene Methoden bzw. Problemfälle gelesen hat, aber nicht recht weiß, in welche Richtung man weitersuchen soll (z.B. kann ich aus dem Stehgreif leider nicht genau sagen, welche Boxen miteinander ähnlich sind und welche nicht - deshalb kann ich auch nicht beurteilen, ob ein gefundener Thread jetzt der passende ist oder nicht - ich kann es nur versuchen) - da hatte ich halt gehofft, dass es Dir mir Deiner Erfahrung ein leichtes wäre, mich sozusagen "draufzustoßen"...

Nur ist das eben nicht meine Aufgabe - also nicht böse sein, wenn ich die auch nicht übernehmen will.
Natürlich ist das nicht Deine Aufgabe und habe auch keine Verpflichtung für Dich daraus abgeleitet, nur weil Du so in der Materie bewandert bist - ich bat Dich nur, mich evtl. mit der Nase darauf zu stoßen, weil ich zu blöd dazu bin bzw. den Wald vor lauter Bäumen nicht gesehen habe.

Ich habe nur Deine Frage aus #1 beantwortet, warum das bei Dir (glücklicherweise) nicht funktioniert hat
Leider scheint da doch etwas passiert zu sein.

So, jetzt mal wieder zu dem, was ich inzwischen versucht habe.
Wie geschrieben, haben die Auffindetools bei mir unter Windows 10 leider nicht funktioniert. Unter Linux (aus einer VM heraus) habe ich die Tools überhaupt nicht zum Laufen gebracht, da wurde beim Aufruf immer das Interface angemeckert - obwohl es sich m.E. um das richtige gehandelt hatte - aber das ganze aus einer VM heraus zu machen ist glaube ich sowieso nicht besonders gut (hatte es eigentlich nur wg. dem ."besseren" ftp-Programm gemacht gehabt).

Ich habe inzwischen die kombinierte Methode aus einem anderen Thread benutzt (finde ihn schon wieder nicht mehr :( ) - aber jetzt mal noch komplett zu meiner Umgebung:
Die Box habe ich über einen kleinen Switch mit dem Laptop verbunden.
Dieser hat auf der LAN-Schnittstelle zu diesem Switch die feste IP 192.168.178.30/255.255.255.0 bekommen.
Betriebssystem ist Windows 10 Pro, Deutsch - es ist aber auch noch VMWare Workstation und der OpenVPN-Client installiert (die eigene Netzwerkschnittstellen bereitstellen).

Zuerst habe ich in einer cmd dauerhaft ping -t 192.168.178.1 laufen lassen.
In einer anderen cmd habe ich den ftp 192.168.178.1 vorbereitet (aber noch nicht abgeschickt).
In einer vom Administrator gestarten Powershell Core 6.0.2 bin ich im Verzeichnis von PeterPawn's eva_tools gestanden und habe das Kommando .\EVA-FTP-Client.ps1 -Debug -Verbose -ScriptBlock { BootDeviceFromImage D:\7590\7590_07.12.ger_freetz-ng-master-20200504-8776d009a-dirty_20200504-215429.image.in-memory } vorbereitet (das Image hatte ich selber erstellt).
Dann habe ich die Box an den Strom angesteckt und gewartet, bis der ping im ersten Fenster zur Adresse "durchkommt". Im selben Augenblick habe ich in der zweiten cmd <Enter> gedrückt, um das ftp-Kommando abzuschicken. Das hat sich dann erfolgreich mit dem Adam2 in der Box verbunden und ich habe die Login-Daten "adam2/adam2" eingegeben.
Dann habe ich mit "bye" den ftp-Client wieder verlassen und habe schnell zur Powershell gewechselt und dort <Enter> eingegeben.
Aktuell ist das Ergebnis dann

Code:
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.3578 0x0 0x46409

================
DEBUG: Sent
GETENV memsize
================
DEBUG: Response:
memsize               0x20000000

200 GETENV command successful

================
DEBUG: Memory size found    : 0x20000000 (512 MB)
DEBUG: Memory size used     : 0x08000000 (128 MB)
DEBUG: Image size found     : 0x02496c00
DEBUG: Set memory size to   : 0x05b69400
DEBUG: Set MTD RAM device to: 0x85b69400,0x88000000
DEBUG: Sent
SETENV memsize 0x05b69400
================
DEBUG: Response:
200 SETENV command successful

================
DEBUG: Sent
SETENV kernel_args_tmp mtdram1=0x85b69400,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 'D:\Install\Hardware\FritzBox\7590\7590_07.12.ger_freetz-ng-master-20200504-8776d009a-dirty_20200504-215429.image.in-memory' to '0x85b69400 0x88000000' ...
DEBUG: Sent
P@SW
================
DEBUG: Response:
227 Entering Passive Mode (192,168,178,1,12,30)

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

================
SendCommand : Exception calling "Flush" with "0" argument(s): "Unable to write data to the transport connection: Eine vorhandene Verbindung wurde vom Remotehost geschlossen."
At D:\Install\Hardware\FritzBox\YourFritz\eva_tools\EVA-FTP-Client.ps1:681 char:21
+                     SendCommand "QUIT"
+                     ~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : NotSpecified: (:) [SendCommand], MethodInvocationException
+ FullyQualifiedErrorId : IOException,SendCommand
d.h. mitten in der Übertragung bricht er ab und bootet neu.
Ich hatte aber auch schon den Fall, dass das komplett erfolgreich durchgelaufen ist.
Nur leider führt die Box trotzdem immer wieder einen Reboot durch und ist auch sonst (ausser am Anfang über den ADAM2-ftp) nicht erreichbar, d.h. es gibt auch kein Webinterface o.ä.

Jetzt weiß ich natürlich nicht, ob das von mir übersetzte Firmware-Image korrekt ist und funktioniert - es gibt z.Zt. also zu viele Fehlerquellen auf einmal - wie kann ich die reduzieren?
Mit dem avm recovery-tool eine Image aufspielen würde sozusagen alles wieder auf Anfang zurückspulen - aber leider findet das ja die Box nicht...

EDIT: ein Versuch, das Image umzuschalten per linux_fs_start ist auch gescheitert - hier hat die Variable zuerst den Wert 1, den ich per setenv auf 0 geändert und dann neu gebootet habe; danach steht der Wert wieder / immer noch auf 1...

@Massa :
Hast Du das Flashen via EVA-FTP-Client.ps1 versucht ? Falls Ja: Was war das Ergebnis ?
s.o. - wie gesagt, ich glaube, durch den falschen Flash-Versuch ganz am Anfang, habe ich mir schon irgendwas zerschossen... :eek:
 
Zuletzt bearbeitet:
Da kann man eigentlich wenig zerschießen - solange der Loader noch arbeitet und das macht er bei Dir ja offensichtlich.

Ich würde hier hingehen und mit genau demselben Ansatz wie oben einfach mal eine originale AVM-Firmware flashen. Das Image dazu kann man sich z.B. mit "image2ram" zusammenbauen oder mit der "FirmwareImage.ps1" (wie, steht irgendwo in einem Thread, wo es um 07.08-Inhouse mit speziellen Zertifikaten geht, weil die damals ebenso installiert werden mußten).

Wenn das AVM-Recovery oder eines meiner Discovery-Skripte die Box nicht findet, muß das irgendeinen Grund haben ... einfach mal die Protokolldatei vom AVM-Recovery (frp.log) ansehen (nach "ftp.log" und "environment.log" und "Recovery" suchen, um die Threads zu finden, wo ich erklärt habe, wie man die Dateien finden kann).

Ich tippe ja bei Windows auf Firewall-Probleme und beim Linux auf Probleme bei der Zuordnung des korrekten Interfaces. Wobei auch das prinzipiell funktioniert ... mein Linux-System hat mehrere physikalische, sowie einige VLAN- und TAP-Interfaces und trotzdem klappt das - bei korrekter Angabe der Parameter, wobei "INTERFACE" als Name weniger wichtig ist, als die passenden Adressen bei TO und FROM - bei mir problemlos (und bei anderen auch). Aber auch da kann man häufig von Hand noch unterstützend eingreifen, z.B. durch das Abschalten aller nicht benötigten Netzwerk-Interfaces.

Wenn man das in einer VM probiert, MUSS man deren Netzwerk-Interfaces im Bridge-Modus auf dem VM-Host betreiben ... weder irgendwelche NAT-Varianten noch ein "host-only"-Network hätten hier irgendeine Chance, daß eine startende Box gefunden wird.

Wie ich schon schrieb ... die 7590 gehört wie die 7580 und die 7560 zu den GRX5-Boxen - die 7560 hat weniger Speicher und die 7580 ist praktisch identisch, bis auf die externe Telefonie. Das meiste, was für diese beiden Modelle gilt, hat damit auch für die 7590 Bestand.

Ich weiß natürlich auch nicht, was Du in dem Image alles veranstalten willst ... aber wenn bei einem Freetz-NG-Image schon ein "dirty" dazukommt (also eigene Änderungen am Code, der aus dem Repo ausgecheckt wurde), dann ist das sicherlich sehr weit von einem "Standard-Image" entfernt. Wenn das (nach #1) Deine erste GRX5-Box ist und Dein erstes Freetz-Image für dieses Modell, würde ich erst mal "klein anfangen" und mir ein Image mit dem Stand aus dem verwendeten Repo erstellen, was nur die unbedingt notwendigen Zusätze enthält. Ich weiß nicht, ob es in Freetz-NG inzwischen ein "replace kernel" für GRX-Boxen gibt ... wenn ja, solltest Du es (zumindest am Beginn) nicht verwenden.

Erst dann, wenn Du mit so einem "Übungs-Image" und den passenden Tools dann so sicher umgehen kannst, daß man Fehler dabei ausschließen kann als Ursache eines Problems, solltest Du Dich an weitere Pakete und eigene Änderungen (die dann zum "dirty" führen) und ggf. auch ein "replace kernel" heranwagen.
 
Da kann man eigentlich wenig zerschießen - solange der Loader noch arbeitet und das macht er bei Dir ja offensichtlich.
Hoffentlich...


Ich würde hier hingehen und mit genau demselben Ansatz wie oben einfach mal eine originale AVM-Firmware flashen. Das Image dazu kann man sich z.B. mit "image2ram" zusammenbauen oder mit der "FirmwareImage.ps1" (wie, steht irgendwo in einem Thread, wo es um 07.08-Inhouse mit speziellen Zertifikaten geht, weil die damals ebenso installiert werden mußten).
Habe die Anleitung dazu bei Dir auf den GitHub-Seiten gefunden ;) https://github.com/PeterPawn/YourFritz/tree/master/signimage
Habe das Original 7.12-Image jetzt also per FirmwareImage.ps1 in ein "In-Memory"-Image umgewandelt und versucht, das mit dem EVA-FTP-Client.ps1 auf die Box zu bringen.
Aber leider schaffe ich es nicht mehr, das ganze erfolgreich durchlaufen zu lassen - da kommt jetzt leider immer der o.a. Abbruch und der Neustart der Box dazwischen :(
Ich habe es nicht mehr geschafft, das ganze "durchlaufen" zu lassen.

Wenn das AVM-Recovery oder eines meiner Discovery-Skripte die Box nicht findet, muß das irgendeinen Grund haben ... einfach mal die Protokolldatei vom AVM-Recovery (frp.log) ansehen (nach "ftp.log" und "environment.log" und "Recovery" suchen, um die Threads zu finden, wo ich erklärt habe, wie man die Dateien finden kann).
Da habe ich danach gesucht.
Bei mir gibt es eine ftp.log und eine environment.log - wobei die environment.log-Datei leer ist.
Und in der ftp.log steht nicht viel erhellendes drin:
Code:
0:06:531: 2.00 gitbuild:3524e9a
0:06:531: Registry: SYSTEM\CurrentControlSet\Services\TcpIp\Parameters\DisableDHCPMediaSense=1
0:06:531: recover-firmware-id:        226
0:06:531: recover-firmware-version:    en-de-es-it-fr-pl-nl.154.07.13
0:06:843: check adapter(Intel(R) 82579LM Gigabit Network Connection) adapter 0x19: Ip: 192.168.178.30(255.255.255.0) (static)
0:06:843: compatible ipaddress (static) found: 192.168.178.30 on adapter 0x19
0:06:859: search on addr: 192.168.178.1
1:07:368: search on addr: 192.168.178.1
2:07:751: search on addr: 192.168.178.1
3:08:281: search on addr: 192.168.178.1
4:08:662: search on addr: 192.168.178.1
5:09:091: search on addr: 192.168.178.1
6:09:587: search on addr: 192.168.178.1
7:10:014: search on addr: 192.168.178.1
8:10:523: search on addr: 192.168.178.1
8:46:965: exit:    errorcode=-1
8:46:965: ----EOF---

Aber irgendwie werde ich das Gefühl nicht los, dass da bei meinem Rechner prinzipiell netzwerkmässig was nicht stimmt
--> da werde ich jetzt mal als erstes suchen.
Ich habe jetzt erstmal IPv6 komplett abgeschaltet (über Registry-Eintrag).
Wenn ich die Box direkt per LAN-Kabel an meinem Laptop mit aktiviertem W-LAN anschließe (d.h. die Schnittstelle ist erst einmal inaktiv), passiert beim ping folgendes:
Code:
C:\Windows\System32>ping -t 192.168.178.1

Ping wird ausgeführt für 192.168.178.1 mit 32 Bytes Daten:
Antwort von 62.155.245.159: Zielnetz nicht erreichbar.
Zeitüberschreitung der Anforderung.
Antwort von 62.155.245.159: Zielnetz nicht erreichbar.
Was soll das? Wieso antwortet mir diese komische Adresse?
Ein ping oder tracert auf diese Adresse ergibt, dass diese nicht erreichbar ist?!
Und wieso sehe ich bei vollständig abgeschaltetem IPv6 immer noch IPv6-Routen in der Routentabelle?
Code:
C:\Windows\System32>ipconfig

Windows-IP-Konfiguration


Ethernet-Adapter LAN-Verbindung:

   Verbindungsspezifisches DNS-Suffix: mohr.loc
   IPv4-Adresse  . . . . . . . . . . : 192.168.178.30
   Subnetzmaske  . . . . . . . . . . : 255.255.255.0
   Standardgateway . . . . . . . . . :

Unbekannter Adapter OpenVPN-Verbindung (TAP):

   Medienstatus. . . . . . . . . . . : Medium getrennt
   Verbindungsspezifisches DNS-Suffix:

Drahtlos-LAN-Adapter LAN-Verbindung* 1:

   Medienstatus. . . . . . . . . . . : Medium getrennt
   Verbindungsspezifisches DNS-Suffix:

Ethernet-Adapter VMware Network Adapter VMnet1:

   Verbindungsspezifisches DNS-Suffix:
   IPv4-Adresse  . . . . . . . . . . : 192.168.187.1
   Subnetzmaske  . . . . . . . . . . : 255.255.255.0
   Standardgateway . . . . . . . . . :

Ethernet-Adapter VMware Network Adapter VMnet8:

   Verbindungsspezifisches DNS-Suffix:
   IPv4-Adresse  . . . . . . . . . . : 192.168.159.1
   Subnetzmaske  . . . . . . . . . . : 255.255.255.0
   Standardgateway . . . . . . . . . :

Drahtlos-LAN-Adapter WLAN-Verbindung:

   Verbindungsspezifisches DNS-Suffix: zuhause.loc
   IPv4-Adresse  . . . . . . . . . . : 192.168.0.130
   Subnetzmaske  . . . . . . . . . . : 255.255.255.0
   Standardgateway . . . . . . . . . : 192.168.0.20

Ethernet-Adapter Bluetooth-Verbindung:

   Medienstatus. . . . . . . . . . . : Medium getrennt
   Verbindungsspezifisches DNS-Suffix:

C:\Windows\System32>netstat -rn
===========================================================================
Schnittstellenliste
 25...d0 67 e5 49 ac 68 ......Intel(R) 82579LM Gigabit Network Connection
 16...00 ff 7a 5a 61 20 ......TAP-Windows Adapter V9
 24...24 77 03 68 e7 61 ......Microsoft Wi-Fi Direct Virtual Adapter
  3...00 50 56 c0 00 01 ......VMware Virtual Ethernet Adapter for VMnet1
  4...00 50 56 c0 00 08 ......VMware Virtual Ethernet Adapter for VMnet8
 13...24 77 03 68 e7 60 ......Intel(R) Centrino(R) Ultimate-N 6300 AGN
 31...c0 18 85 d8 d6 c5 ......Bluetooth Device (Personal Area Network) #2
  1...........................Software Loopback Interface 1
===========================================================================

IPv4-Routentabelle
===========================================================================
Aktive Routen:
     Netzwerkziel    Netzwerkmaske          Gateway    Schnittstelle Metrik
          0.0.0.0          0.0.0.0     192.168.0.20    192.168.0.130     40
        127.0.0.0        255.0.0.0   Auf Verbindung         127.0.0.1    331
        127.0.0.1  255.255.255.255   Auf Verbindung         127.0.0.1    331
  127.255.255.255  255.255.255.255   Auf Verbindung         127.0.0.1    331
      192.168.0.0    255.255.255.0   Auf Verbindung     192.168.0.130    296
    192.168.0.130  255.255.255.255   Auf Verbindung     192.168.0.130    296
    192.168.0.255  255.255.255.255   Auf Verbindung     192.168.0.130    296
    192.168.159.0    255.255.255.0   Auf Verbindung     192.168.159.1    291
    192.168.159.1  255.255.255.255   Auf Verbindung     192.168.159.1    291
  192.168.159.255  255.255.255.255   Auf Verbindung     192.168.159.1    291
    192.168.187.0    255.255.255.0   Auf Verbindung     192.168.187.1    291
    192.168.187.1  255.255.255.255   Auf Verbindung     192.168.187.1    291
  192.168.187.255  255.255.255.255   Auf Verbindung     192.168.187.1    291
        224.0.0.0        240.0.0.0   Auf Verbindung         127.0.0.1    331
        224.0.0.0        240.0.0.0   Auf Verbindung     192.168.187.1    291
        224.0.0.0        240.0.0.0   Auf Verbindung     192.168.159.1    291
        224.0.0.0        240.0.0.0   Auf Verbindung     192.168.0.130    296
  255.255.255.255  255.255.255.255   Auf Verbindung         127.0.0.1    331
  255.255.255.255  255.255.255.255   Auf Verbindung     192.168.187.1    291
  255.255.255.255  255.255.255.255   Auf Verbindung     192.168.159.1    291
  255.255.255.255  255.255.255.255   Auf Verbindung     192.168.0.130    296
===========================================================================
Ständige Routen:
  Keine

IPv6-Routentabelle
===========================================================================
Aktive Routen:
 If Metrik Netzwerkziel             Gateway
  1    331 ::1/128                  Auf Verbindung
  1    331 ff00::/8                 Auf Verbindung
===========================================================================
Ständige Routen:
  Keine
Der ping auf 192.168.178.1 geht jetzt NIE durch - der scheint dauerhaft von dieser komischen Adresse beantwortet zu werden.

Dann habe ich meinen W-LAN Adapter abgeschaltet.
Jetzt sieht's bei inaktiver LAN-Schnittstelle so aus:
Code:
C:\Windows\System32>ipconfig

Windows-IP-Konfiguration


Ethernet-Adapter LAN-Verbindung:

   Medienstatus. . . . . . . . . . . : Medium getrennt
   Verbindungsspezifisches DNS-Suffix: mohr.loc

Unbekannter Adapter OpenVPN-Verbindung (TAP):

   Medienstatus. . . . . . . . . . . : Medium getrennt
   Verbindungsspezifisches DNS-Suffix:

Drahtlos-LAN-Adapter LAN-Verbindung* 1:

   Medienstatus. . . . . . . . . . . : Medium getrennt
   Verbindungsspezifisches DNS-Suffix:

Ethernet-Adapter VMware Network Adapter VMnet1:

   Verbindungsspezifisches DNS-Suffix:
   IPv4-Adresse  . . . . . . . . . . : 192.168.187.1
   Subnetzmaske  . . . . . . . . . . : 255.255.255.0
   Standardgateway . . . . . . . . . :

Ethernet-Adapter VMware Network Adapter VMnet8:

   Verbindungsspezifisches DNS-Suffix:
   IPv4-Adresse  . . . . . . . . . . : 192.168.159.1
   Subnetzmaske  . . . . . . . . . . : 255.255.255.0
   Standardgateway . . . . . . . . . :

Drahtlos-LAN-Adapter WLAN-Verbindung:

   Medienstatus. . . . . . . . . . . : Medium getrennt
   Verbindungsspezifisches DNS-Suffix: zuhause.loc

Ethernet-Adapter Bluetooth-Verbindung:

   Medienstatus. . . . . . . . . . . : Medium getrennt
   Verbindungsspezifisches DNS-Suffix:

C:\Windows\System32>netstat -rn
===========================================================================
Schnittstellenliste
 25...d0 67 e5 49 ac 68 ......Intel(R) 82579LM Gigabit Network Connection
 16...00 ff 7a 5a 61 20 ......TAP-Windows Adapter V9
 24...24 77 03 68 e7 61 ......Microsoft Wi-Fi Direct Virtual Adapter
  3...00 50 56 c0 00 01 ......VMware Virtual Ethernet Adapter for VMnet1
  4...00 50 56 c0 00 08 ......VMware Virtual Ethernet Adapter for VMnet8
 13...24 77 03 68 e7 60 ......Intel(R) Centrino(R) Ultimate-N 6300 AGN
  1...........................Software Loopback Interface 1
===========================================================================

IPv4-Routentabelle
===========================================================================
Aktive Routen:
     Netzwerkziel    Netzwerkmaske          Gateway    Schnittstelle Metrik
        127.0.0.0        255.0.0.0   Auf Verbindung         127.0.0.1    331
        127.0.0.1  255.255.255.255   Auf Verbindung         127.0.0.1    331
  127.255.255.255  255.255.255.255   Auf Verbindung         127.0.0.1    331
    192.168.159.0    255.255.255.0   Auf Verbindung     192.168.159.1    291
    192.168.159.1  255.255.255.255   Auf Verbindung     192.168.159.1    291
  192.168.159.255  255.255.255.255   Auf Verbindung     192.168.159.1    291
    192.168.187.0    255.255.255.0   Auf Verbindung     192.168.187.1    291
    192.168.187.1  255.255.255.255   Auf Verbindung     192.168.187.1    291
  192.168.187.255  255.255.255.255   Auf Verbindung     192.168.187.1    291
        224.0.0.0        240.0.0.0   Auf Verbindung         127.0.0.1    331
        224.0.0.0        240.0.0.0   Auf Verbindung     192.168.187.1    291
        224.0.0.0        240.0.0.0   Auf Verbindung     192.168.159.1    291
  255.255.255.255  255.255.255.255   Auf Verbindung         127.0.0.1    331
  255.255.255.255  255.255.255.255   Auf Verbindung     192.168.187.1    291
  255.255.255.255  255.255.255.255   Auf Verbindung     192.168.159.1    291
===========================================================================
Ständige Routen:
  Keine

IPv6-Routentabelle
===========================================================================
Aktive Routen:
 If Metrik Netzwerkziel             Gateway
  1    331 ::1/128                  Auf Verbindung
  1    331 ff00::/8                 Auf Verbindung
===========================================================================
Ständige Routen:
  Keine
Beim ping sieht's jetzt so aus:
Code:
C:\Windows\System32>ping -t 192.168.178.1

Ping wird ausgeführt für 192.168.178.1 mit 32 Bytes Daten:
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Antwort von 192.168.178.1: Bytes=32 Zeit<1ms TTL=250
Antwort von 192.168.178.1: Bytes=32 Zeit<1ms TTL=250
Antwort von 192.168.178.1: Bytes=32 Zeit<1ms TTL=250
Antwort von 192.168.178.1: Bytes=32 Zeit<1ms TTL=250
Antwort von 192.168.178.1: Bytes=32 Zeit<1ms TTL=250
Antwort von 192.168.178.1: Bytes=32 Zeit<1ms TTL=250
Antwort von 192.168.178.1: Bytes=32 Zeit<1ms TTL=250
Antwort von 192.168.178.1: Bytes=32 Zeit<1ms TTL=250
Antwort von 192.168.178.1: Bytes=32 Zeit<1ms TTL=250
Zeitüberschreitung der Anforderung.
Wie man sieht, habe ich die Box an den Strom gehängt und sie ist auch kurz erreichbar, bevor sie wieder "verschwindet".
Ein parallel laufendes AVM-Recovery findet übrigens weiterhin nichts.

Und die "On"-Zeit reicht leider nicht aus, um ein Image auf die Box zu schieben...

Ich tippe ja bei Windows auf Firewall-Probleme und beim Linux auf Probleme bei der Zuordnung des korrekten Interfaces. Wobei auch das prinzipiell funktioniert ... mein Linux-System hat mehrere physikalische, sowie einige VLAN- und TAP-Interfaces und trotzdem klappt das - bei korrekter Angabe der Parameter, wobei "INTERFACE" als Name weniger wichtig ist, als die passenden Adressen bei TO und FROM - bei mir problemlos (und bei anderen auch). Aber auch da kann man häufig von Hand noch unterstützend eingreifen, z.B. durch das Abschalten aller nicht benötigten Netzwerk-Interfaces.
Bei Windows ist der Firewall deaktiviert;
bei der Linux-VM war tatsächlich das Netzwerk-Interface auf NAT geschaltet - wenn ich das im Bridge-Modus betreibe, kommt die Schnittstelle überhaupt nicht hoch (obwohl ich da natürlich eine andere feste IP-Adresse 192.168.178.31 gesetzt habe)...

Ich weiß natürlich auch nicht, was Du in dem Image alles veranstalten willst ... aber wenn bei einem Freetz-NG-Image schon ein "dirty" dazukommt (also eigene Änderungen am Code, der aus dem Repo ausgecheckt wurde), dann ist das sicherlich sehr weit von einem "Standard-Image" entfernt. Wenn das (nach #1) Deine erste GRX5-Box ist und Dein erstes Freetz-Image für dieses Modell, würde ich erst mal "klein anfangen" und mir ein Image mit dem Stand aus dem verwendeten Repo erstellen, was nur die unbedingt notwendigen Zusätze enthält. Ich weiß nicht, ob es in Freetz-NG inzwischen ein "replace kernel" für GRX-Boxen gibt ... wenn ja, solltest Du es (zumindest am Beginn) nicht verwenden.
Huh?
Quellcodeänderungen habe ich eigentlich überhaupt keine - ich wußte nicht, dass das "-dirty" ein Anzeichen dafür ist.
Ich baue schon seit Ewigkeiten Images für meine 7490 - da steht das "-dirty" schon lange mit dran.
Die 7590 soll eigentlich meine 7490 ersetzen - also habe ich für den Build das git-Repository neu ausgecheckt und die 7490-Konfiguration als Basis genommen.
Dort habe ich dann eigentlich "nur" das Modell geändert und übersetzt...

Aber ja, ich würde jetzt gerne erst einmal wieder ein "normal" funktionierende Box mit AVM-Image haben...
 
@Massa :
Code:
SendCommand : Exception calling "Flush" with "0" argument(s): "Unable to write data to the transport connection: Eine vorhandene Verbindung wurde vom Remotehost geschlossen."
At D:\Install\Hardware\FritzBox\YourFritz\eva_tools\EVA-FTP-Client.ps1:681 char:21
Also das sieht für mich aich eher wie ein Verbindungs- als weniger ein prinzipielles Speicher-/Softwareproblem aus.
Probiere bitte Folgendes:
1. Switch weglassen
2. Sämtliche Firewall- und Virentools auf dem PC wirklich abschalten (ist sehr ungefährlich, da während des Flashvorgangs ja eine Bedrohung maximal von der zu flashenden Box kommt, welche bekanntlich noch nicht läuft).
3. IP des PCs fest auf 192.168.178.2 setzen
4. Den Rest mit Verbindung auf ADAM2 per ftp in einer "normalen Konsole" und dem EVA-FTP-Client.ps1 in einer Powershell kannst Du lassen
5. Erstelle ein absolutes Minimal-Image für die Box (ohne Remove-Patches, ohne zusätzliche Pakete, ohne Replace-Kernel, basierend auf 7.1*)
6. Versuche, das so entstandene .memory-Image zu flashen.

Dann bitte wieder berichten.
 
Also das sieht für mich aich eher wie ein Verbindungs- als weniger ein prinzipielles Speicher-/Softwareproblem aus.
Ja, mir auch - aber das liegt eben daran, dass die Box dann wieder neu bootet und deshalb wieder weg ist...

Probiere bitte Folgendes:
1. Switch weglassen
das habe ich bereits gemacht (s.o.) - mit Switch geht's gar nicht mehr...

2. Sämtliche Firewall- und Virentools auf dem PC wirklich abschalten (ist sehr ungefährlich, da während des Flashvorgangs ja eine Bedrohung maximal von der zu flashenden Box kommt, welche bekanntlich noch nicht läuft).
3. IP des PCs fest auf 192.168.178.2 setzen
4. Den Rest mit Verbindung auf ADAM2 per ftp in einer "normalen Konsole" und dem EVA-FTP-Client.ps1 in einer Powershell kannst Du lassen
5. Erstelle ein absolutes Minimal-Image für die Box (ohne Remove-Patches, ohne zusätzliche Pakete, ohne Replace-Kernel, basierend auf 7.1*)
6. Versuche, das so entstandene .memory-Image zu flashen.
Den Virenscanner hatte ich noch an - den habe ich jetzt auch mal abgeschaltet.
Keine Ahnung, ob's jetzt daran lag oder ob ich einfach "Glück hatte" - ich bin jetzt auf jeden Fall einmal mit dem Flashen erfolgreich durchgekommen.
Geflasht habe ich das Original AVM 7.12-Image (wie oben beschrieben umgewandelt mit PeterPawn's FirmwareImage.ps1:

Code:
PS D:\Install\Hardware\FritzBox\YourFritz\eva_tools> .\EVA-FTP-Client.ps1 -Debug -Verbose -ScriptBlock { BootDeviceFromImage D:\Install\Hardware\FritzBox\7590\FRITZ.Box_7590-07.12.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.3578 0x0 0x46409

================
DEBUG: Sent
GETENV memsize
================
DEBUG: Response:
memsize               0x20000000

200 GETENV command successful

================
DEBUG: Memory size found    : 0x20000000 (512 MB)
DEBUG: Memory size used     : 0x08000000 (128 MB)
DEBUG: Image size found     : 0x01978a00
DEBUG: Set memory size to   : 0x06687600
DEBUG: Set MTD RAM device to: 0x86687600,0x88000000
DEBUG: Sent
SETENV memsize 0x06687600
================
DEBUG: Response:
200 SETENV command successful

================
DEBUG: Sent
SETENV kernel_args_tmp mtdram1=0x86687600,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 'D:\Install\Hardware\FritzBox\7590\FRITZ.Box_7590-07.12.image.in-memory' to '0x86687600 0x88000000' ...
DEBUG: Sent
P@SW
================
DEBUG: Response:
227 Entering Passive Mode (192,168,178,1,12,10)

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

================
DEBUG: Response:
226 Transfer complete

================
True
Nur leider hat das immer noch nichts "geholfen" - nach dem Abstöpseln und wieder anstöpseln des Stromsteckers ist die IP-Adresse 192.168.178.1 per ping wieder kurz erreichbar, dann verschwindet sie wieder - und die Box resettet sich auch wieder und ist dann überhaupt nicht mehr erreichbar.
Ein Web-Interface erreiche ich auch in der kurzen Zeit, wo die IP da ist, nicht.
Die Box war zwar vorher auf Werkseinstellungen - aber vielleicht ist da was defekt; kann man die Einstellungen der Box irgendwie über Tastenkombinationen oder über Adam2 zurücksetzen?
 
@Massa:
Bei der Konfiguration der lokalen Adressen für die (W10-)VM hast Du Dich ja auch vertan:
IPv4-Adresse . . . . . . . . . . : 192.168.187.1
Das soll sicherlich eine 178 werden und wenn der Versuch mit dem "ping", wo irgendeine öffentliche IP dann antwortete, mit dieser Einstellung erfolgte, dann ist das nicht verwunderlich.

Aber tatsächlich scheint irgendetwas mit Deinem Netzwerk nicht so richtig zu stimmen ... wobei die Annahme, eine FRITZ!Box hätte IMMER die Adresse 192.168.178.1 im Bootloader, auch schlicht falsch ist ([Info] - Wie "recovere" ich eigentlich richtig? | IP Phone Forum ). Wenn man sich sicher sein will, daß da beim "ping" tatsächlich auch die FRITZ!Box antwortet, muß man schon noch auf die MAC-Adresse der Antworten schauen bzw. in die ARP-Tabelle, ob wirklich die Box auch auf 192.168.178.1 reagiert und nicht irgendein anderes Gerät.

Das Setzen einer "Wunschadresse" im Bootloader der Box (das macht EVA-Discover.ps1 bzw. eva_discovery gleich mit) setzt voraus, daß da lokale Broadcasts gesendet werden können ... die gehen per Definition nicht durch eine Network Address Translation (zumindest üblicherweise nicht) und daher KANN das nur funktionieren, wenn der Netzwerkadapter der VM auch ALLE Pakete direkt durchreicht (bei gesendeten) bzw. sieht (bei empfangenen), die da auf dem Kabel abgehen oder ankommen - genau das ist eine "Bridge" (zwischen dem Kabel und dem virtuellen Adapter).

Daher KANN auch keines der Programme, die mit "discovery" arbeiten (das macht das AVM-Programm ja auch), irgendwie funktionieren, solange da die VM nur über NAT mit dem Router verbunden ist. Schon als Bridge muß das nicht immer funktionieren ... daher würde ich, wenn ich solche Probleme hätte wie Du, das erst einmal "bare metal" ausprobieren (bis ich die Handhabung beherrsche).

Und ich muß auch @JohnDoe42 oben widersprechen ... wenn die FRITZ!Box gar nicht auf 192.168.178.1 stehen sollte, bringt es auch nichts, die lokale IP irgendwie auf 192.168.178.irgendwas zu setzen. Es gibt nur drei Wege, wie man einer FRITZ!Box die Adresse im Bootloader "ausreden" kann ... der eine ist der mit den UDP-Broadcasts und der andere wäre ein Schreiben eines neuen TFFS-Images (so setzt das AVM-Recovery-Programm diese Adresse zurück, egal unter welcher es selbst die Box gefunden hat) bzw. das Ändern über "SETENV".

Aber für die beiden letzten Optionen müßte man schon eine FTP-Session haben - das geht damit nur, wenn man die Box auch finden kann. Die erste Option funktioniert aber (bei korrekter Verkabelung bzw. "VM-Network-Configuration" - wobei eine VM an sich hier immer noch eine denkbare Fehlerquelle ist, ebenso wie irgendwelche TCP-Optimierungen und/oder Offload-Gedöns, denn der TCP-Stack im Bootloader ist nicht wirklich "schlau" und das muß/soll er ja auch gar nicht sein) in jedem Falle, solange der Bootloader noch arbeitet.

Und wenn die Box tatsächlich nicht auf 192.168.178.1 "eingerichtet" sein sollte, kriegst man sie da auch nicht mit einer festen lokalen Adresse oder irgendeinem "ping" von ab ... der einzige Weg ist es dann, ein Programm zu verwenden, was UDP-Broadcasts zum Suchen des Gerätes benutzt - und dann muß dafür natürlich auch die Netzwerk-"Anbindung" richtig sein, sonst kommen (a) die Broadcasts gar nicht bei der Box an (wenn eine VM da NAT benutzt) oder (b) die Antworten der Box, wo die Adresse auch noch mal drin steht und die dann auch vom AVM-Programm als "gefunden" interpretiert wird, erreichen den Empfänger nicht (weil gar kein "Tunnel" im Connection-Tracking einer Firewall existiert, da es ja kein passendes, ausgehendes Paket zuvor gab).

Außerdem kann man - wenn man's gar nicht glauben will - auch die Netzwerk-Kommunikation einfach mal mitschneiden und auswerten.

Ich werde den Verdacht nicht los, daß es hier mehr als eine FRITZ!Box im LAN gibt und ein guter Teil der "Verwirrung" einfach daher kommt (neben der falschen "Anbindung" des virtuellen Netzwerks), daß da manches durcheinander geht. Es gibt inzwischen bei VMs auch Optionen, daß virtuelle Netzwerk-Adapter irgendwelche Zustände eines physikalischen Adapters (Kabel drin, Kabel draußen, Auto-Negotiation) "spiegeln" ... auch solche Sachen sollte man (wenn man schon eine VM nutzt) abschalten.

Wenn Du tatsächlich beim ersten "ping 192.168.178.1" in #18 (das verrutscht dann noch, wenn Dein doppelter "Anfang" gelöscht wurde) eine Antwort von einem Internet-Router erhältst, muß es ja zumindest noch eine funktionierenden Internet-Anbindung geben und das ist nicht zufällig Deine alte 7490, die auch auf 192.168.178.0/24 arbeitet? Zumindest läßt mich die Feststellung, daß Du in der Linux-VM beim Bridge-Adapter eine 192.168.178.31 einstellen wolltest, auch in diese Richtung denken.

@Massa:
Du weißt aber schon, daß man die Box nach dem Hochladen eines Images erst mal so lange in Ruhe lassen muß, bis sie die Firmware in den Flash schreiben konnte? Danach startet sie dann schon von alleine noch einmal ... hast Du denn [Info] - Wie "recovere" ich eigentlich richtig? | IP Phone Forum wirklich gelesen?
 
So, jetzt habe ich mal per adam2 die Variablen "firmware_info" und "crash" zurückgesetzt, dann den Flash-Vorgang nochmal durchgeführt (lief wieder erfolgreich durch, obwohl ich den Virenscanner diesmal an hatte).
Dann habe ich 10 min. einfach nur gewartet...

In der Zeit hat die Box mehrmals die Power/DSL an- und ausgeschaltet / blinken lassen und auch die Lichtorgel war immer wieder kurz zu sehen.
Im parallel mitlaufenden ping auf 192.168.178.1 konnte ich die Box aber die ganze Zeit über nicht erreichen.
Erst als ich dann nach Ablauf der 10 min. den Stromstecker gezogen und wieder eingesteckt habe, habe ich die IP der Box wieder erreicht und mich mit dem adam2 verbinden können.
Die Variable "crash" war dann immer noch nicht wieder vorhanden, in der Variablen "firmware_info" steht "154.07.12"
 
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.