Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
Boxen, die 2 Frequenzbänder haben, haben m.W. 2Wlan-MACs
Schreibe das ganze doch in eine txt-Datei und flasche es. Flole hat das hier irgendwo aufgeschrieben. Btw. eine Serial mit F50x hat sie ziemlich sicher schon certs_new im Bootloader. Der Umbruch war im Juli sprich ca. F30x
M.W. haben/hatten die eva_tools einige Scripte, um aus einer Support-Datei ein flashbares tffs-image zu kreieren. Die . txt-Datei muss im Linuxkonformen Format vorliegen. Ggfs. wird beim Bauen noch eine Checksum oder Leerzeichen aufgefüllt. In irgendeinem Thread hatte iirc Flole eine defektes Environment komplettiert und zurückgeschrieben. Das ist in einem der Mega-6490-Threads. Am Handy ist mir das zu mühsam zu suchen. Sorry.
P.S.: Daß es das Environment so zerlegt hat, ist nicht normal. Ich habe da Deine unnötig zugefügte Zeile in Verdacht.
Beim Schreiben eines TFFS-Images müssen - nein: werden - gar nicht alle Werte neu gesetzt - vieles ergibt sich auch erst aus dem laufenden Betrieb. Was die KI da also als "fehlend" halluziniert, hat mit den tatsächlich erforderlichen Angaben praktisch nichts zu tun. Warum hört eigentlich IRGENDJEMAND auf diesen Schwachsinn und fragt dann erst HINTERHER hier nach, wenn er dann mit seiner heißgeliebten KI nicht weiterkommt? Ich persönlich habe jedenfalls keinen Bock, in Konkurrenz zu irgendeinem LLM zu treten bei dem Versuch, jemandem zu helfen. Entweder KI oder ich - entscheide Dich bitte.
Wie die "Geburtsdaten" einer 6490 aussehen und was da tatsächlich alles enthalten sein sollte/muss, kann man sich im Konfigurationsbereich des Bootloaders ansehen, den man auch per FTP extrahieren kann (Pseudo-Dateiname ist config, ob groß oder klein geschrieben, bin ich gerade nicht sicher, steht aber hier auch irgendwo im Board bzw. wäre ja zu probieren). Da stehen dann sowohl die "Basiswerte" für die Einträge im Environment drin, als auch das CM-Zertifikat (und auch noch einiges anderes).
Üblicherweise restauriert auch der Bootloader selbst alle benötigten Angaben aus diesem Konfigurationsbereich, wenn in BEIDEN Partitionen kein gültiges TFFS-Image vorliegt und er somit nicht anhand der Versionsnummer, die vorne im Header der TFFS-Partitionen steht, die neueste Version auswählen kann. Der Fall mit der Bootloader-Version, die bei leeren TFFS-Partitionen nicht korrekt auf ARP-Pakete antwortete, war nur ein "Ausrutscher" und nicht die Regel.
Der Inhalt eines TFFS-Images ist auch NICHT identisch mit dessen Textdarstellung - es ist also Unfug, ein neues TFFS-Image komplett mit SETENV-Kommandos erstellen zu wollen, zumal in #41 eben viele vollkommen unnütze Angaben stehen und teils sogar auch falsche, denn die Seriennummer z.B. enthält bei den 6490-Modellen iirc nur 16 (! - nicht 15 Zeichen, wie eine "richtige" Seriennummer) ASCII-Nullen und kann m.W. gar nicht sinnvoll bzw. dauerhaft(!) wirksam per FTP-Kommando eingetragen werden.
Auch ist das Schreiben irgendwelcher Texte in die TFFS-Partitionen Blödsinn - das sind dann genauso ungültige Daten, als wenn da überhaupt nichts mehr enthalten wäre. Beim Auslesen ist es (von EVA generierter) Text - geschrieben wird immer das "legacy format" für den AVM-TFFS-Treiber (auch bei Modellen mit anderer Speicherung des TFFS, da übernimmt dann EVA die Umwandlung).
Gleiches gilt für alle Definitionen der Partitionen (die mtdX-Zeilen), die sich m.W. auch schon lange nicht mehr "überschreiben" lassen, das ging wohl zuletzt bei der 7050 oder der 7170. Diese Angaben werden nämlich im Konfigurationsbereich des Bootloaders gar nicht "in Textform" abgelegt (das ist dann schon "aufbereitet" von der EVA), sondern stehen in Paaren aus Startadresse und Länge jeweils binär am Anfang (jedenfalls in Version 3 dieses Bereichs).
Also - das, was tatsächlich in ein funktionierendes TFFS-Image gehört, ist deutlich weniger als das, was in der Support-Datei am Beginn enthalten ist oder per RETR env ausgelesen werden kann … vermutlich bezieht Deine KI ihr "Wissen" aus so einer Datei. In Wahrheit reicht jedoch schon eine kleine Teilmenge dessen, was die Box auf ein RETR env (bzw. ein GET-kommando in einem FTP-Client) hin ausgibt, denn schon das dort Enthaltene wird nicht alles zum Generieren eines neuen Images verwendet. So wird z.B. weder my_ipaddress noch linux_fs_start vom AVM-Recovery-Programm genutzt, wenn es ein neues TFFS-Image generiert (was im Prinzip auch bei den "non-cable"-Modellen genauso abläuft) … und mehr als das, was der Bootloader per RETR env (das ist eben ohnehin ein "cooked view" auf den binären Inhalt des aktiven TFFS-Images) selbst preisgibt, steht dem Recovery-Programm eigentlich gar nicht zur Verfügung an Infos zum aktuellen Gerät.
Den Konfigurationsbereich des Bootloaders (RETR config) lesen die AVM-Programme auch nur dann aus, wenn sie ein Bootloader-Update machen wollen, weil sie dann das neue Bootloader-Image mit den Daten aus der Finalisierung für die Box "personalisieren" müssen, bevor es übertragen wird. Ob bei der 6490 tatsächlich ein Bootloader-Update per FTP funktioniert (der Bootloader-Code ist häufig genauso voller Artefakte aus anderen Modellen/Generationen, wie der Code des Recovery-Programms für Windows), wurde m.W. noch nie bewiesen (außerhalb von AVM jedenfalls).
Angesichts des Aufwands, der beim Austausch der Zertifikate betrieben wurde (die stehen ja auch im Konfigurationsbereich, zumindest bei den neueren Geräten und ich glaube mich zu erinnern, auch bei den alten, selbst wenn sie nicht wirklich genutzt wurden), bezweifle ich eigentlich, daß so ein Update funktioniert - dann wäre ein angepaßtes CVC-Image für ein Update über die DOCSIS-Mechanismen inkl. Bootloader-Update mit neu generierten Zertifikaten ja eigentlich der einfachere Weg gewesen, als der ganze Aufstand mit dem Vergleich der signierenden CA (um den "Gewinner" bei alten Zertifikaten im Konfigurationsbereich und neuen in der nvram-Pattition zu bestiimmen) und den Sicherungen, daß neue Zertifikate auf alten Boxen auch über Werksreset hinaus erhalten bleiben. Aber ich schweife ab … zurück zur vorliegenden Box.
Tatsächlich sieht das Flashen erst mal nicht sooo schlecht aus und anhand des Timings würde ich darauf tippen, daß es nur der Bootloader ist, der da in der "Karenzzeit" für den FTP-Zugriff irgendwann mal auf die Pings antwortet. Das würde dann bedeuten, daß mind. einer der beiden Kernel nicht richtig gestartet werden kann. Um das zu überprüfen, startet man die Box per Power-On (also Stecker rein, einen Schalter gibt es ja nicht) neu, während parallel ICMP-Pakete (vulgo: Pings) gesendet werden und verbindet sich mit dem FTP-Server, sobald das möglich ist. Antwortet die dann weiterhin auf die Pings und das für deutlich länger als 10 Sekunden (was sehr, sehr wahrscheinlich ist), ist es sicher NUR der Bootloader.
Anschließend liest man das Environment (über EVA!) aus und zeigt es hier - dann können wir gemeinsam "festlegen", was in einem "frischen" TFFS-Image enthalten sein muß, das Du hinterher mit build_tffs_image (https://github.com/PeterPawn/YourFritz/blob/main/tffs/build_tffs_image - die Suche nach dem Namen dieses Skripts hier im Board lohnt sich sicherlich auch) erstellen und dann nach MTD3 (und/oder MTD4, wobei eine Kopie vollkommen ausreichend wäre, wenn sie die "Auserwählte" für EVA ist) flashen kannst. Am besten packst Du gleich noch einen Hexdump des Konfigurationsbereichs dazu - zumindest der ersten 1024 Bytes. Dahinter kommen dann Abschnitte mit gepackten Daten (gzip-Format), in denen u.a. das CM-Zertifikat enthalten ist. Die Frage, ob das ein altes oder ein neues ist, spielt für Deine Zwecke ja keine Rolle und kann hinterher irgendwann mal in der Supportdatei nachgeschlagen werden. Liegen die ersten 1024 Byte des Konfigurationsbereichs auch binär vor (das Board hier will iirc nur gepackte Dateien akzeptieren), kann man sie "decodieren" lassen und sieht dann, was von diesen Daten "Voreinstellungen" und was "unveränderlich" ist, weil es bei jedem Start des Bootloaders wieder restauriert wird.
Nur wirst Du auch auf Deinem Mac eher nicht umhinkommen, Dir eine virtuelle Maschine mit einem echten Linux (MacOS ist ja ein BSD-Derivat) zuzulegen, wenn Du die Skriptdateien aus dem YourFritz-Repo benutzen willst, weil nur weniges dort auch unter MacOS ausführlich getestet bzw. extra angepaßt wurde.
Wenn Deine Bootloader-Version NICHT die defekte ist, kannst Du auch mal versuchen, absichtlich(!) beide TFFS-Partitionen durch Schreiben leerer Dateien zu invalidieren - ist hinterher der Bootloader noch erreichbar (beim ARP-Bug sehen wir dann neu weiter, auch das läßt sich wieder hinbiegen), müßte er selbst ein neues TFFS-Image erstellen, das Du dann wieder mit RETR env zur Kontrolle auslesen solltest. Funktioniert das, kannst Du das Thema TFFS-Inhalt erst einmal abhaken … warum, habe ich versucht zu erklären.
Bei Deinen Flash-Versuchen (unter Deiner künftigen Linux-VM würde ich dann die Benutzung der eva_tools anstelle von lftp empfehlen) fällt mir zumindest mal auf, daß da zwar der FTP-Server auf binäre Übertragung gesetzt wird (das ist das quote TYPE I, was ja auch vom Server richtig quittiert wird), aber eigentlich gibt es ja ein Kommando für den FTP-Client (üblicherweise binary, was sich bis bin abkürzen läßt - nicht zu verwechseln mit debug bin, was nur Voodoo ist), das dann selbst das TYPE I zum Server sendet, aber gleichzeitig den Client entsprechend umschaltet. Ich weiß zwar nicht, was bei lftp jetzt der Standardmodus wäre - aber wenn da TYPE A (also ASCII-Transfer) aktiv wäre, kann das Flashen binärer Daten eigentlich nur schiefgehen (weil dann Lineends analysiert und "interpretiert" werden vom Client). Warum also nicht gleich das passende Kommando verwenden, wenn es schon ein FTP-Client sein muß?
EDIT: Kleine Korrektur meinerseits - wenn das Pingen der Box tatsächlich kontinuierlich mit ICMP-Paketen in Abständen von ca. 1 Sekunde erfolgt, dann versucht EVA ja, die Box zu starten. Wenn der Bootloader die Box in dieser Zeit nicht auf ICMP-Pakete antwortet, ist das normal und erwartbar … dann ist es wohl irgendetwas im Verlauf der Initialisierung der Box, was da schiefläuft. Da wäre dann ein "richtiges" Protokoll des Timings (Stoppuhr statt Pings, den Neustart erkennt man am kurzen Aufblitzen aller LEDs) inkl. des zeitlichen Verlaufs des Zustands der LEDs deutlich hilfreicher (ggf. Video aufnehmen und beim Abspielen ausmessen/ablesen), das kann man dann mit der dmesg-Ausgabe einer funktionierenden 6490 vergleichen, um den ungefähren Punkt, wo der Neustart erfolgt, einzugrenzen.
Mit deiner Vermutung hattest du recht, sobald man sich per FTP verbindet, bleibt der Ping konstant stehen und reißt nicht wieder ab.
Habe die Fritzbox nun an einen Raspi gehängt und das YourFritz Repo dort ausgecheckt.
pi@pi4:~/Desktop/YourFritz/eva_tools $ /home/pi/Desktop/YourFritz/eva_tools/eva_get_environment CONFIG > config.bin
Found AVM bootloader: AVM EVA Version 1.2411 0x0 0x36409
Environment read from device: pi@pi4:~/Desktop/YourFritz/eva_tools $ /home/pi/Desktop/YourFritz/eva_tools/eva_get_environment env > env.txt Found AVM bootloader: AVM EVA Version 1.2411 0x0 0x36409
Environment read from device:
Danach "touch empty.bin" und dieses auf mtd3 und mtd4 geflashed.
Strom ab, Strom dran... ein wenig warten. (ca 30 Sekunden)
Danach Strom ab, strom dran und die danach die Variablen erneut ausgelesen:
Wenn ich dich richrtig verstanden habe, schaut das erstmal nicht so gut aus und wir müssen die "Geburtstdaten" zusammen tragen und dann mit dem SCript build_tffs_image ein image für mtd3 und mtd4 bauen.
Das sieht nach der "Notkonfiguration" aus, die jede EVA-Version an Bord hat - da sind immer MAC-Adressen aus der allerersten OID, die AVM zugeteilt wurde (00:04:0E), enthalten und zwar quer über alle Modelle. Mir fällt jetzt gerade kein plausibler(!) Grund ein, warum da eine Box keine eigenen Konfigurationsdaten haben sollte, solange da kein Vorbesitzer mit dem Bootloader herumgespielt hat.
Zum Hexdump: Der Beginn sieht noch ganz gut aus … die ersten vier Byte sind die Versionsnummer des Aufbaus dieses Bereiches (bei allen AVM-Modellen ab der 7390 (iirc) gleich, hier Version 3), danach kommen vier (oder acht, so genau weiß ich das aus dem Kopf nicht mehr) Byte mit der Speichergröße (memsize), an die sich dann 16 Paare aus Startadresse und Länge für die ersten 16 Partitionen im Flash-Speicher anschließen. Leere Partitioneinträge haben nur Nullen für beide Werte.
Da beginnt also die erste Partition (mtd0) bei Offset 0 und hat eine (hexadezimale) Länge von 0x400000, die zweite (mtd1) bei Offset 0x400000 und hat eine Länge von 0x80000. Die Bootloader Partition mtd2 liegt an Offset 0xa0000 und ist 0x20000 Byte groß. Und so weiter … die Anzeige im Environment besteht immer aus dem Startoffset und dem Offset für das erste Byte nach der Partition. Auch wenn die Werte nicht wirklich zum installierten SPI-Flash von 2 MB passen, stimmt das dennoch … relevant sind die nur für die Adressen und Grenzen der Partitionen, die im SPI-Flash gespeichert sind (Bootloader, nvram-Partition, TFFS-Partitionen).
Allerdings fehlen nach der "Partitiontabelle" die Daten - da sollten die Offsets (innerhalb des Konfigurationsbereichs) für zwei "Tabellen" stehen, in denen die Werte für die boxeigenen Merkmale, einmal nur als Voreinstellung und einmal alles das, was bei jedem Start erneuert wird, hinterlegt sein. So sähe der Beginn eines korrekten Konfigurationsbereichs (auch von einer 6490) aus:
Die sollte eigentlich in JEDEM (unveränderten) Bootloader dieselbe sein (ggf. an einer etwas abweichenden Adresse in der Partition liegen) und warum das bei Dir jetzt offenbar nicht der Fall ist (zumindest was die zwei angesprochenen Tabellen angeht), irritiert mich schon sehr. Auch das Auslesen mit RETR CONFIG (es war also die Version mit der Großschreibung) klappte bei mir "reibungslos" (und nicht nur einmal, das ist nur das Beispiel für diese spezielle Box):
Code:
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
TYPE I
200 Type set to BINARY
MEDIA SDRAM
200 Media set to MEDIA_SDRAM
P@SW
227 Entering Passive Mode (192,168,178,1,54,69)
RETR CONFIG
150 Opening BINARY data connection
226 Transfer complete
Ich würde aber dennoch erst einmal gar nicht weiter mit dem Environment hantieren - was ist denn mit meinen anderen Hinweise bzgl. der richtigen Verwendung von FTP-Client-Kommandos? Die Box sollte auch mit dem derzeitigen Environment zumindest erst mal starten können (dafür gibt es diese Notvariante ja), wenn ansonsten alles korrekt ist.
kommt etwas krumm daher - sieht es für Dich denn jetzt so aus, als würde der Loader die TFFS-Daten selbst restaurieren (mal abgesehen davon, daß es jetzt das "Not-Environment" ist) oder nicht? Die vorliegende Bootloader-Version macht genau das aus meiner Sicht - wie gesagt, warum da keine gültige boxspezifische(!) Konfiguration gefunden wird, steht auf einem anderen Blatt.
Ich persönlich würde jetzt so vorgehen: EINMAL (es gibt jetzt kein linux_fs_start im Environment, also ist das automatisch 0 und es reicht aus, die Partitionen für das aktive System neu zu beschreiben) die vier Images in die passenden Partitionen flashen und zwar so, daß dabei auch SICHER seitens des Clients die Daten als binär angesehen werden (um die Serverseite kümmert sich dann schon der Client, da braucht es kein gesondertes TYPE I-Kommando). Keine weiteren SETENV-Kommandos oder ähnliches. Danach den Start der Box mitfilmen (irgendwo wird sich ja ein Smartphone auftreiben lassen) und das weiter vorne schon erwähnte Timing aus dem Video "herausschreiben". Das Ziel ist es, die Box überhaupt erst einmal so weit zu bekommen, daß sie startet und irgendwie läuft - heißt: daß sie eben keinen Bootloop mehr hinlegt. Dann kann man sich ggf. daran machen, da eine angepaßte Firmware zu installieren, mit der man an einen Dump des Bootloaders kommt, damit man sich anschauen kann, warum da kein (gültiger) Konfigurationsbereich existiert. Ich habe die Vermutung, daß da jemand mit falschem Handling aus einem laufenden System heraus (das kann dann eigentlich auch nur eine angepaßte Version gewesen sein, wenn es schon eine 06.8x war) an der Bootloader-Partition (unter FRITZ!OS ist die dann mtd0 bzw. mtdblock0) herumgespielt hat, weil er den Bootloader und seine Konfiguration irgendwie "patchen" wollte.
Andererseits ist der von Dir ausgelesene Konfigurationsbereich ja deutlich länger (genauso groß wie bei mir:
Code:
drwxr-xr-x 4 root root 4096 Oct 19 2016 ./
drwxr-xr-x 9 root root 4096 Nov 9 2018 ../
drwxr-xr-x 2 root root 4096 Oct 19 2016 ARM/
drwxr-xr-x 2 root root 4096 Sep 10 2024 ATOM/
-rw-r--r-- 1 root root 58368 Oct 19 2016 config.bin
-rw-r--r-- 1 root root 150 Oct 19 2016 count.txt
-rw-r--r-- 1 root root 1900 Oct 19 2016 environment.txt
-rw-r--r-- 1 root root 365 Oct 19 2016 eva_get_environment_session.log
-rw-r--r-- 1 root root 701710 Oct 19 2016 support FRITZ.Box 6490 Cable 141.06.62_01.01.70_0105.txt
), was wieder gegen die "Zerstörung" der nachfolgenden Daten sprechen würde.
Ich mache mal eine direkte Konversation mit Dir auf (ich nehme sonst keine direkten Nachrichten an) ... wenn Du willst, kannst Du mir da ja mal den gesamten Konfigurationsbereich (also die ganzen 57 KB) zukommen lassen.
Wo es dann klemmt, wenn die Box nicht startet, kann man erst nach dem Vorliegen der Angaben zum Timing beim Start genauer einschätzen - am Environment sollte es jedenfalls nicht liegen, solange der schon erwähnte "killswitch" nicht noch zuschlägt (was aber auch erst zu beweisen wäre, daß der den Neustart auslöst).
Darf man fragen, ob der Fehler gefunden wurde, oder läuft das nur via PN. Ich finde es spannend und lehrreich, die Lösung zu erfahren, da für mich viele neue Dinge dabei sind, die ich so noch nicht kannte.
Mein letzter Stand: Die Box lief nach der Installation einer älteren FRITZ!OS-Version (06.6x) und dem (sicheren) Einbau von RS232-USB-Adaptern, aber Updates (per GUI) funktionierten nur auf 07.00, danach scheiterte der Versuch von 07.00 auf 07.57. Mehr habe ich auch nicht gehört seit letztem Montag … ob nun mit dem Notfall-Environment oder mit dem "richtigen", ist auch noch offen, ebenso wie die Frage, ob es überhaupt einen Dump des Bootloaders (worin man dann dessen Konfiguration und die Zertifikate, etc. hätte finden (oder zumindest suchen) können), gab oder gibt.
Moin zusammen.
6.64 ließ sich flashen und starten.
update über web ui auf 7.00 klappt auch.
Update auf 7.28 oder 7.57 danach nicht mehr
Vermutlich wegen des "leeren" tffs images.
In den Versionen die funktionieren wird auch die default mac adresse angezeigt und nicht die, die aufgedruckt ist.
Mit leeren TFFS Image und Version 7.00 habe ich die Box allerdings nicht in den echten IP-Client Modus bekommen.
Das Webui ist beschnitten (trotz AVM-Firmware).
Habe es noch ein wenig probiert die Sicherungs-Datei zu bearbeiten und wieder einzuspielen, aber dann irgendwann keine Zeit/Lust mehr gehabt.
In der Zwischenzeit ist eine weitere 6490 ohne Branding mit Firmware 7.57 hier eingetroffen.
Die leistet jetzt hier zuverlässig ihren Dienst, sodass am Sonntag das erste WM Spiel übertragen werden kann.
Danke Euch beiden für die Infos. Da hatte ein Vorgänger wohl mit dem Bootloader herumgespielt. Um den zu sichern braucht's wohl Telnetzugang, sprich modfs oder freetz, wobei das für alte Images nicht so einfach sein dürfte, falls neuere via adam2/ftp geflasht nicht booten.
Bei einem RETR CONFIG liefern die Puma6-Boxen wohl IMMER die vollen 57 KB des Konfigurationsbereiches aus, egal wieviel darin tatsächlich von sinnvollen Daten belegt wird. Die Größe des Downloads ist also KEIN Maßstab dafür, ob die Daten darin irgendwie noch sinnvoll sind oder nicht.
