Ich hab z.B. eine Box (normale 7590, nicht AX) hier (mit Freetz und telnet offen) wo ich gerne die LAN-Mac-Adresse und das Web-Gui-Passwort ändern möchte, so dass es auch ein Recovery "überleben" würde.
Ich habe das früher mal bei 6490er Boxen gemacht, in dem ich ein mtdblock file und den urlader kopiert, per sed geändert und wieder zurück geschrieben/kopiert habe...
Ideal wäre also, ob man das einfach per telnet hinbekommt ... Linux ist kein Problem für mich, ich bin mir nur nicht sicher, welche Dateien ich modifizieren darf ohne nen Briefbeschwerer draus zu machen...
Ich hoffe ich habe mich verständlich ausgedrückt
Edit:
Und wegen "Eigenes-TFFS-Image-bauen":
A) Überlebt das auch ein Recovery?
B) Ist das git-repo in der Freetz-VM auch enthalten?
C) Welche mtd´s muss ich bei der 7590 flashen? Das sind doch andere als die mtd3/mtd4, oder?
Nach meiner Erfahrung kann man durch die Modifikation eine Fritzbox selten daraus ein Briefbeschwerer machen kann.
Ansonsten gelten die Befehle wie: set und get. Meine Erfahrungen basieren sich eben zurzeit nur auf den KD boxen ,ansonsten wende dich bitte an den
Sie müssen registriert sein, um Links zu sehen.
den Peter, wenn er eben dazu was dir antworten mag
Naja die modifikation der mtdblock Dateien ist schon ein heftiger eingriff und ich hab eine 7590 schon hier stehen die nicht mehr mag ...
Ich meine mich zu erinnern, dass ich damals mit Peter schon mal wegen gleichem bei der 6490 damals geschrieben hatte und er war da "nicht so begeistert" von...
Naja, ich werd mal rumprobieren und langsam Kupplung kommen lassen ...
Ein Recovery-Programm macht auch nichts anderes, als die Environment-Daten und die Zähler auszulesen und daraus ein neues TFFS-Image zusammenzubauen, was dann geflasht wird. Siehe die Shell-Skripte zum Umgang mit TFFS-Images (
Sie müssen registriert sein, um Links zu sehen.
).
Ich bin wie folgt vorgegangen (ich hab mich dazu den Tools bedient, die du in deinem YourFritz-Repo bereitstellst, danke dafür):
Environment und Counter via eva_get_environment abgerufen
Das Environment weitgehend so lassen,
Nametable aus vorhandenen TFFS Dump erzeugen via name_table_from_tffs
provideradditive.tar erzeugen und mit zlib komprimiere (default compression) und in 001D.bin umbenennen
Mit build_ttfs_image nametable env counter 001D.bin wird dann ein TFFS Image erzeugt
Abschließend nach Überfliegen des neuen Image wierd mit eva_store_tffs mtdnand tffs_new.img das Image auf die Box gebracht.
Nach Neustarten der Box werden nochmal externe Supportdaten erzeugt und über den TFFS Dump verifiziert
Nun leider ist es eben so, dass man beim Testen eben damit rechnen muss. ... Ständiger Bootloop kann verschiedene Ursachen mit sich bringen. z.B. falsches Branding. Womöglich verschiedene Images auf unterschiedlichen Partitionen können ebenfalls dazu führen.
Klar doch bringe ich a) viel Geduld zwecks Erfahrung und ggfs. Weitergabe hier auf
Nachvollziehbar ist: Wenn jemand nicht dazu bereit ist, irgendwas zu testen, so lasst es eben bitte lieber so sein wie es ist. Ich kann nur sämtliches auf meinen F!B-n testen. bzw. berührt meine Erfahrung nur auf eurer Aussagen. Ich kann eben nur das für euch zur Verfügung stellen, was ich eben euch zur Verfügung stellen kann..
Das ist ja auch sehr begrüssenwert und ich habe die bereitgestellte images auch getestet. U.a. hattest du ein "fesc-image" auf 7.29er-Basis vor Urzeiten auf dem teamserver, was dann leider verschwunden war wegen eines Disputes mit einem anderem Member?
Auch dies habe ich nicht einmal ansatzweise verlangt!
Back on Topic. Ich habe nun in "linux_fs_start 0" eine Stockfirmware 7.57 In "linux_fs_startt 1"ein fesc-image 7.29 mit telnetzugang für rd.600sec.
Wenn ich mir die erweiteret Supportdatei anschaue, scheint wland irgend ein Problem mit dem Lesen/Einbinden des eeprom vom WLAN-Chip zu haben?
Ein mehrfach aufzufindender Auszug in div. logs
Code:
[ 71.911560] [wlan_config] Given config is:
[ 71.911565] [wlan_config] hw_interface=0 chip_type=14 (cascade)
[ 71.911567] [wlan_config] hw_interface=1 chip_type=14 (cascade)
[ 71.923605] CHRDEV "wlan_eeprom" major number 217 goes below the dynamic allocation range
[ 71.935108] avm_net_trace: New net trace device 'WLAN Management Traffic' registered with minor 128.
[ 71.935356] avm_net_trace: udev device avm_net_trace128 created
[ 71.937787] [wlan_config] HWRevision now 233
[ 71.937797] [wlan_config] HWSubRevision now 8
[ 71.937808] [wlan_config] maca now 2c:91:ab:xx:xx:xx
[ 71.937827] [wlan_config] suspend_fw_unload now 1
[ 72.003134] AVM_WATCHDOG: System Init Ueberwachung abgeschlossen (55 s noch verfuegbar)
In einer intakten support-datei ist m.W. chip_type=6 zu erkennen? Das könnte darauf hindeuten, daß beim "Bauen" eine falsches WLAN-Paket eingepflegt wurde? Der Hinweis
mit dem "major" und "minor" deutet auf irgendeine falsche Erweiterung im Bootprozess hin?
DAS ist nur meine Laienhafte Vorstellung!
Eigentlich hatte ich "nur" laut Anleitung hier
Du musst Regestriert sein, um das angehängte Bild zusehen.
das kdg->avm und RTL=n auf y gesetzt und dann in einer telnetsession die zuvor via nano-editor geänderte mtd3 mit einem
überschrieben? Das fesc-image sollte einen patch haben, der gebrandetes TFFS wohl versteht? Nun stehe ich da mit meinem kurzem Hemd, da selbst das Zurückschreiben des Originals (mtdblock3) scheitert wegen "no space left".
OT: Da ich leider unfähig bin, ein lauffähiges "freetz oder ffritz" auf meinem Raspi4 unter Ubuntu 23.04 lunar ans Rennen zu bekommen, wäre es nett, wenn jmd. wie @Gismotro ein lauffähiges Linux-image für den/einen raspi zur Hand hätte, was man simple auf eine SD kurz bruzzeln könnte und mit "git-clone" nur noch seine config auswählen könnte und z.B. ein None-freetz alias modfs sich zu bruzzeln, was dann auch rudimentär läuft. Wegen der bei aktuellen Boxen immer komplizierterem Aufbau der FW -Stichwort uimage- wird allein das entpacken und modifizieren immer umfangreicher, sodaß ohne funktionierendes Handwerkszeug ambitionierte UserInnen/Laien trotz redlichen Mühungen auf dem Schlauch stehen.
Die 7590 hat imho einen komplett anderen Aufbau als DOCSIS-Boxen. Mit den bekannten modfs-Modifikationen sollte Branding und ggfs. auch die MAC-DSL+Co im Bootprozess abzufangen sein, sodaß sie auch einfache Reboots überstehen. Bei FW-Updates oder Recovery gehen sie "hopps"
Edith:
Nach einem Spaziergang zwecks Brain-Lüftens mal im NVRAM nachgeschaut
Code:
Trying 192.168.178.1...
Connected to 192.168.178.1.
Escape character is '^]'.
Fritz!Box user: fritz1970
password:
BusyBox v1.29.3 (2021-02-23 17:41:23 CET) built-in shell (ash)
# ctlmgr[2641]: WLANLIB: wcsi_socket_connect:313: Establishing RPC connection failed with TIMEOUT
cd /nvram
# ls
avm_tffs ffnvram itstore sec_vendorId
# ctlmgr[2641]: WLANLIB: wcsi_socket_connect:313: Establishing RPC connection failed with TIMEOUT
cd ffnvram
# ls
dropbear root-ssh shadow
# ctlmgr[2641]: WLANLIB: wcsi_socket_connect:313: Establishing RPC connection failed with TIMEOUT
ctlmgr[2641]: WLANLIB: wcsi_socket_connect:313: Establishing RPC connection failed with TIMEOUT
ctlmgr[2641]: WLANLIB: wcsi_socket_connect:313: Establishing RPC connection failed with TIMEOUT
cd ffnvram
-sh: cd: can't cd to ffnvram: No such file or directory
# telefon: SIGCHLD PID 8282 received!
telefon: SIGCHLD PID 8283 received!
cat ctlmgr[2641]: WLANLIB: wcsi_socket_connect:313: Establishing RPC connection failed with TIMEOUT
ffnvram
cat: can't open 'ffnvram': No such file or directory
# nano ffnvram
-sh: nano: not found
# ctlmgr[2641]: WLANLIB: wcsi_socket_connect:313: Establishing RPC connection failed with TIMEOUT
ctlmgr[2641]: WLANLIB: wcsi_socket_connect:313: Establishing RPC connection failed with TIMEOUT
ctlmgr[2641]: WLANLIB: wcsi_socket_connect:313: Establishing RPC connection failed with TIMEOUT
ctlmgr[2641]: WLANLIB: wcsi_socket_connect:313: Establishing RPC connection failed with TIMEOUT
ctlmgr[2641]: WLANLIB: wcsi_socket_connect:313: Establishing RPC connection failed with TIMEOUT
ctlmgr[2641]: WLANLIB: wcsi_socket_connect:313: Establishing RPC connection failed with TIMEOUT
ctlmgr[2641]: WLANLIB: wcsi_socket_connect:313: Establishing RPC connection failed with TIMEOUT
# Connection closed by foreign host.
Irgendwo in einem dir
Code:
avm_tffs ffnvram itstore sec_vendorId
ggf. im ffnvram mit
Code:
dropbear root-ssh shadow
wird der Bootprozess ausgehebelt bzgl des wland? Auf der box greift imho nur der rudimentäre nfi-Editor, den ich seit rd. einem Jahrzehnt nichtmehr genutzt habe. (syntax lässt grüssen).
Falls jmd. weiss, was ich löschen oder ändern sollte, bevor das Teil zum Briefbeschwerer wird, TX a Lot.
Anhänge
Du musst angemeldet sein, um die Anhangsliste zu sehen.
Hi ich habe eine FB 6591 von VD mit der frritz os 07.13 möchte sie als mesh benutzen aber dafür brauch ich ein Upgrade aber beim versucht sie zu flashen mit TC wenn ich put part_03_ATOM_ROOTFS.bin mtd0 flashen will bricht das ganze nach kurzer zeit ab Fehler bein hochladen ist die Meldung
Man müsste genau untersuchen, welchen TotalCommander Version benutzt du. Welcher Fehlermeldungen kommen vor. Wurden die anderen Dateien ordnungsgemäß übertragen etc.
Es gibt auch andere Flash Methoden.
Wie geschrieben, es gibt auch andere Möglichkeiten zum Flashen. Ich hab früher auch sämtliche Stunden mit verbracht, bis es funktioniert hat. Aus meiner Sicht ist die schnellste und beste Möglichkeit die Push firmware mit Virtual Box oder original Linux.
Screenshot in Windows geht mit folgenden Tasten: win + Shift + s
@logi36 probier es mal mit den eva-tools. Ich kann Dir gerade nicht sagen, wo sie zu finden sind, aber Google hilft Dir bestimmt.
Soo, habe ich an etwas erinnert: Probier mal bitte ein anderes Netzwerkkabel aus. Hatte das Problem auch. Lag am Netzwerkkabel.
Das Flashen wurde einfach irgendwann abgebrochen, weil was schief lief.
Wenn Du es geschafft hast, eines der Dateien oder nur einen Teil erfolgreich auf die Box zu schreiben, dann brauchst Du nix zu löten.
Du musst die "Dateien" mit Powershell ansteuern.
Powershell starten und dann den richtigen Befehl eingeben, um das passende Script zu starten. Hier gibt es genug Anleitungen dafür.
Sorry, dass ich gerade nicht mehr helfen kann, habe leider nicht so viel Zeit.