EWE Fritz!Box 7490 - WebUI nach Debranding nicht mehr erreichbar

[B612]

aber die dort aufgerufene Datei /etc/boot.d/core/oemcheck fehlt

Hat die AVM vergessen oder ist die bewusst weg? Und dann warum?

 

[KunterBunter]

dass die firmware_version wieder auf "ewe" zurückgestellt wurde.

Welchen Wert hatte denn die Environment-Variable "firmware_version" vorher? "ewe" kann es nicht gewesen sein, denn das ist kein gültiger Wert.

 

[nicoe]

[Edit Novize: Überflüssiges Fullquote des Beitrags direkt darüber gelöscht - siehe Forumsregeln]
Ich bin mir leider nicht mehr zu 100% sicher, glaube aber dass es ewe war. Vermutlich irre ich mich dann aber. Habe leider nicht dran gedacht, dass das später nochmal relevant sein könnte... Auf der Box steht hinten auf dem Sticker "Edition EWE", falls das von Interess ist.

 

[PeterPawn]

@B612:
Ich arbeite ja bekanntlich nicht dort und auch nicht FÜR AVM. Ich weiß es also auch nicht und müßte spekulieren. VERMUTLICH wird es tatsächlich nur in den DOCSIS-Boxen verwendet in den OEM-Versionen der Firmware - das ist ja auch keine Prüfung, die fest im Gerät verankert ist, sondern eben in der jeweiligen Firmware.

---

Aber das scheint es hier ja dann doch nicht zu sein ... wobei mir wieder die Phantasie fehlt, was es dann noch sein könnte. Wenn sich jemand selbst als "blutigen Anfänger" bezeichnet, schrecke ich auch davor zurück, Alternativen wie SIAB für die Suche nach dem Problem vorzuschlagen. Ansonsten wäre das für mich erst mal der Königsweg - SIAB ist auch unabhängig von einem funktionierende GUI. Nur bringt das eben fast nichts, wenn man sich mit einer Linux-Shell nicht auskennt - die "geführte Fehlersuche" dauert eher seeehr lange und von dabei gemachten Fehlern, die dem Ausführenden gar nicht auffallen, kriegt man auch nichts mit ... ob sich das für eine 7490 tatsächlich noch lohnt?

---

Wenn schon so simple Änderungen wie ein Umsetzen von linux_fs_start nicht funktionieren, wird es ja "komisch" (immer unter der Annahme, daß alle Aktionen jeweils komplett ausgeführt, korrekt geprüft und "dokumentiert" wurden - was ich jetzt mal voraussetze). Allerdings ist ja auch bekannt, daß der MS-FTP-Client nun mal nicht das geeignete Werkzeug ist, um mit EVA zu kommunizieren, denn der läßt sich - gerade wenn ein GETENV dabei ist - ja auch gerne mal von der Protokollverletzung seitens EVA (bei mehrzeiligen FTP-Antworten, wie es beim GETENV nun mal der Fall ist) irritieren und zeigt dann im Terminal nur noch Mist an.

Ich würde - ohne exakte Kenntnis, was zwischendrin noch so alles unternommen wurde und welche "Geschichte" die Box ansonsten noch hat - auch nicht einfach firmware_version wieder auf irgendetwas anderes setzen ... zumindest in dem aktiven Slot ist ja jetzt vermutlich eine "normale" AVM-Firmware installiert.

Das Recovery-Programm sollte auch alle Additive und vorher vorhandenen Einstellungen gelöscht haben - wenn man das nicht (was mancher in seiner Panik dann eben doch macht) viele Male nacheinander laufen läßt, sollte sich im FTP-Protokoll dieses Programms ja auch noch finden lassen, wie der Dialog bei der Installation der Firmware aussah - außerdem findet man dort dann auch noch (sofern beim "ersten Versuch" noch ein Additiv vorhanden war und das Recovery-Programm sich weigerte) die alten Inhalte des Environments - das Recovery-Programm speichert ja bis zu 20 von diesen Dateien.

Wenn man das ursprüngliche Branding herausfinden kann (dazu müßte man eben schauen, ob es noch eine entsprechende environment.log im Windows-System gibt - wo die zu finden ist, habe ich im "Recovery-Thread" erklärt), könnte man zwar darüber nachdenken, ob im anderen Slot noch eine ältere Firmware-Version mit diesem Branding stehen sollte oder nicht.

Ich würde mir davon aber nicht zu viel versprechen, weil es ja wohl doch mehrere Recovery-Versuche gab und solange man nicht weiß, ob dabei "beide" Slots jeweils mind. einmal beschrieben wurden, ist das einigermaßen unwahrscheinlich, daß es noch ein funktionierendes System gibt.

Ansonsten war mit dem "Ausschalten" der Box zwischen FTP-Session und Recovery-Programm auch klar, daß die Änderung dann doch permanent war ... damit fällt mir aber auch kein (halbwegs plausibler) Grund mehr ein, warum das GUI nicht arbeiten sollte, wenn der Rest paßt (keine Hardware-Schäden) und beim rootfs in einem SquashFS-Image kann man auch zu früh abgebrochene Flash-Vorgänge ausschließen, weil wichtige Daten am Ende des Images stehen und ohne die tatsächlich die Box (wegen des fehlenden rootfs) in einer (recht kurzen) Bootschleife landen würde.

Da fällt mir dann auch nur noch die Empfehlung ein, sich jemanden im Bekanntenkreis zu suchen (oder sich die Kenntnisse selbst anzueignen), der mit einer Linux-Shell umgehen kann - dann könnte man mit ein paar gezielten Hinweisen (aber deutlich unterhalb der Schwelle einer "geführten Fehlersuche") beim Ermitteln der Ursache helfen.

---

Allgemein noch als Ergänzung zur Frage, ob eine Einstellung nun "fest" ist in EVA oder nicht:

Mit neueren Boot-Manager-Versionen kann man sich den Inhalt des Konfigurationsbereichs in EVA auch anzeigen lassen: https://github.com/PeterPawn/YourFr...16c74fd84c01cc0ab/bootmanager/bootmanager#L75 - dazu muß man nur zu einer Shell kommen (bei einer 7490 ja kein Problem, da kann man jederzeit SIAB "injizieren"), die Datei irgendwie auf die Box bringen (braucht bei originaler AVM-Firmware dann httpsdl und die URL für den "raw content" des Skripts NACH der letzten HTTP-Umleitung(EDIT: das hat AVM ja mittlerweile doch im Griff und Redirections sind auch für httpsdl nicht länger ein Problem) - das ist im "modfs"-Thread weiter hinten irgendwo beschrieben) und sie dann passend aufrufen (sh bootmanager show_eva_cfg) - das würde dann etwa so aussehen auf einer 7490:

~ # pwd
/
~ # cd /var
/var # httpsdl -n https://raw.githubusercontent.com/PeterPawn/YourFritz/main/bootmanager/bootmanager
ok
/var # ls -l /var/bootmanager
-rw-r--r--    1 root     root        118634 Apr  1 11:53 /var/bootmanager
/var # sh /var/bootmanager show_eva_cfg
>>>> fixed values from EVA configuration <<<<
maca=08:96:D7:6E:9A:xx
macb=08:96:D7:6E:9A:xx
macwlan=08:96:D7:6E:9A:xx
macwlan2=08:96:D7:6E:9A:xx
macdsl=08:96:D7:6E:9A:xx
usb_board_mac=08:96:D7:6E:9A:xx
usb_rndis_mac=08:96:D7:6E:9A:xx
HWRevision=185
HWSubRevision=3
ProductID=Fritz_Box_HW185
SerialNumber=0000000000000000
annex=B
usb_device_id=0x0000
usb_revision_id=0x0000
usb_manufacturer_name=AVM
>>> default values from EVA configuration <<<
firmware_version=1und1
wlan_key=<many digits>
/var #

- alles zwischen rot und grün ist "fest", das nach grün sind nur Standardwerte, die durch Einstellungen im TFFS überschrieben werden können.

 

[HarryP_1964]

@HarryP_1964: Noch nicht. Folgender Command wäre richtig? Probiere ich gleich aus.

quote SETENV linux_fs_start 1

Ich dachte eigentlich, dass Du vorher mit

quote GETENV linux_fs_start

erst mal checkst, auf welcher Seite ("0" oder "1") die Box steht und dann auf die andere umschaltest.

Harry

 

[KunterBunter]

Ich dachte eigentlich, dass Du vorher ...

Genau das hat er im Screenshot von #15 gemacht.

 

[HarryP_1964]

@KunterBunter

Stimmt, aber warum hat er nicht auch "0" ausprobiert?

Harry

 

[Novize]

@nicoe bitte nimm langsam mal die Hinweise der Forumssoftware zur Kenntnis, schaue Deine ganzen bisherigen Beiträge, insbesondere meine Überarbeitung, an und verhalte dich in Zukunft den Forumsregeln entsprechend. Danke

 

[nicoe]

@PeterPawn: Was die Shell angeht bin ich jetzt kein "blutiger Anfänger" mehr. Ich arbeite in der Firma mit OSX, habe dadurch auch immer mal wieder mal Berührungspunkte damit (auch was meinen Raspberry angeht ). Bloß was das ganze Thema Fritz!Box und ihre Eigenheiten angeht bin ich gestern das erste mal "tiefer" eingestiegen. Mit "SIAB" würde ich mich gerne mal tiefergehend beschäftigen. Viel schlimmer als jetzt kanns ja vermutlich nicht werden, leider ist die Box in dem Zustand auch nicht mehr als ein teurer Briefbeschwerer. Wenn ihr da zufällig irgendwelche Geheimtipps habt für "Play Alongs" um in das Thema einzusteigen wäre ich sehr dankbar.
Die alte FW ist vermutlich mittlerweile durch meine Flashversuche überschrieben. Daran zu kommen scheint auch nicht so leicht (zumindest spuckt Google nichts dergleichen aus) und EWETel heißt mittlerweile nicht mal mehr so. Die ehemaligen Downloadseiten von denen für die Firmware scheinen alle nicht mehr verfügbar zu stehen.

Was mir noch aufgefallen ist (Siehe Anhang):

Der Webserver auf der Box scheint grundsätzlich erreichbar zu sein (denn eine Verbindung kann hergestellt werden), er antwortet einfach nur nicht.

@HarryP_1964: Ich habe es nur mit linux_fs_start 1 versucht - Macht es Sinn das Ganze auch einmal mit 0 zu probieren? Es scheint so als würde die Änderung über einen Start nicht persistiert (oder ich habe was falsch gemacht).

Viele Grüße
Nico

EDIT:

bitte nimm langsam mal die Hinweise der Forumssoftware zur Kenntnis

Ich bin erst seit gestern hier (langsam mal..., das ist meine erste "Ermahnung" ;-)), aber werde ich tun. Entschuldige die Umstände.

 

[PeterPawn]

Suche bitte dennoch erst einmal nach dem Thread, in dem ich die Verwendung des Recovery-Programms und die dabei - häufiger - auftretenden Hürden beschrieben habe - darüber solltest Du zu der Stelle auf Deinem PC gelangen, wo die ausgelesenen Environment-Daten gespeichert wurden. Solange Du den PC jetzt nicht schon "ein Leben lang" für das Recovery-Programm von AVM genutzt hast, sollte mindestens eine der vorhandenen Dateien (bis zu 20 werden eben aufgehoben) schon mal Auskunft geben können, was da zuvor eingetragen war. Aber das "nur am Rande" ...

Die Installation eines Shell-Zugangs zur 7490 ist simpel ... und ausführlich erklärt (in meinen Augen) und auch häufiger schon (erfolgreich) praktiziert (nicht nur von mir, sondern auch von anderen). Da es sich dabei um "Modifikationen" handelt, stehen diese ganzen Threads auch genau da, wo man sie dann "vermuten" würde: https://www.ip-phone-forum.de/forums/fritz-box-fon-modifikationen.444/ und irgendwo weiter hinten steht dann auch dieser (leider nicht gepinnt, daher nur selten "weit vorne", seitdem die VR9-Modelle nicht mehr "aktuell" sind): [Info] modfs-Starter - "Einmal-Impfung" mit ShellInABox für VR9-Boxen

 

[NDiIPP]

… nicht auch "0" ausprobiert?

"501 environment variable not set" für linux_fs_start entspricht bzw. "wirkt" normalerweise wie "linux_fs_start = 0".

Aber dennoch seltsam, dass der Wert dieser Variable gelöscht wird…

 

[Joe_57]

Wird diese Variable nicht erst beim ersten Update gesetzt?
Früher war die bei "jungfräulichen" Boxen nicht vorhanden und wurde erst beim ersten Update (oder auch beim Recover?) gesetzt.

 

[erik]

Beim Update ja, beim Recover wird die jeweils aktive Partition neu beschrieben. Habe ich ausprobiert, weil ich auf meinen 7412 auf der 1. Partition openWRT und auf der zweiten das neueste Fritz-OS vorhalte, eventuelle AVM-updates deshalb nur via Recover vornehmen kann.

 

[NDiIPP]

Die Variable wird (normalerweise) beim Update gesetzt, wenn diese nicht vorhanden ist. Und bei der 7490 ist das normalerweise nur im Auslieferungszustand der Fall, wenn man sie nicht manuell bzw. selbst gelöscht hat.

 

[H´Sishi]

Mußte man bei der 7490 nicht bei einem bestimmten großen Update-Schritt über eine Zwischen-Firmware gehen oder verwechsel' ich das gerade mit einer anderen Box?

Falls mich meine Erinnerung nicht täuscht, bringt vielleicht ein älteres Recovery etwas.
Falls ja, könnte sich @nicoe Release für Release nach "heute" durcharbeiten (in der Hoffnung, daß der Flash-Speicher noch genug Schreibzyklen hat).

 

[nicoe]

Danke für die ganzen Ratschläge und Tipps. Ich werde mich da in den kommenden Tagen mal tiefer einlesen und ausprobieren. Sollte ich irgendwie Erfolg haben gebe ich euch natürlich Bescheid wie ich es geschafft habe (oder wie eben nicht).

Euch ein schönes Wochenende. Tolles Forum!

 

[PeterPawn]

Wird diese Variable nicht erst beim ersten Update gesetzt?

Stand da nicht weiter vorne etwas von: "SETENV linux_fs_start 1"?

EWE Fritz!Box 7490 - WebUI nach Debranding nicht mehr erreichbar

Hallo zusammen! Ich habe versucht ein ähnliches Thema zu finden, bin aber nicht fündig geworden. Folgendes Problem: Ich habe meine alte 7490 (mit EWE "Branding") versucht via FTP Variante zu debranden, damit ich anschließend das original Recovery-Tool von AVM verwenden kann um die original-FW...

www.ip-phone-forum.de

Zwar hat das vermutlich tatsächlich nicht geklappt (bei der Reaktion "Connection closed by remote host." auf dieses Kommando, denkt man natürlich sofort wieder an einen "FTP-Proxy" von irgendeiner Security-Suite, der da querschießen dürfte), aber WENN es geklappt hätte, wäre das ja auch nicht im Zusammenhang mit einem Update gewesen ... und DAS ist es ja auch eher, was da komisch erscheint. Ich wüßte jedenfalls nicht, daß eine EVA-Version (auf funktionierender Hardware) auf ein Schreiben von linux_fs_start mit einem Verbindungsabbruch (und vielleicht auch noch VOR der Quittung für das SETENV) reagieren würde - aber wie schon geschrieben: Der FTP-Client von MS ist durch ein GETENV auch leicht zu verwirren und dann stimmen seine "Anzeigen" auch nicht mehr - das IST nichts Neues und deshalb sollte man - wenn man den schon verwenden will/muß - da auch nach jedem GETENV die Verbindung erst mal schließen und eine neue FTP-Session starten, bei der dieser FTP-Client dann auch wieder "normal" ist.

---

Ein "Zwischenupdate" ist bei der Verwendung des Recovery-Programms ebenfalls nicht erforderlich - das würde also auch keinen Sinn machen. Nur beim Update(!) kann das erforderlich sein (https://avm.de/service/wissensdaten...e-alter-ist-als-die-momentan-aktive-Firmware/), weil AVM irgendwann nach der 07.12 dann mal einen Schnitt gemacht hat bei den ganzen Möglichkeiten, auch noch von uralten Kernel-Versionen aus die aktuelle Firmware zu installieren und vor allem auch Code entsorgt, der nur bei den Modellen mit einem einzigen System erforderlich war (und das teilweise auch nur vor 10 Jahren, als der Anrufbeantworter seine Daten noch in einer JFFS-Partition gespeichert hat).

Das brauchte dann - je nachdem, was da im aktuell laufenden System möglich war und was für ein Kernel lief - verschiedene Tools und wurde immer unübersichtlicher ... außerdem kam mit dem "Verschlanken" der Installation auch gleich noch die Option der "SILENT_UPDATES", wo bereits (bei den Boxen mit zwei Systemen) die neue Firmware "im Stillen" installiert wird und dann erst - irgendwann später - die Umschaltung von linux_fs_start und der Neustart erfolgt. EDIT: Da habe ich mich geirrt, die Umschaltung von linux_fs_start erfolgt doch direkt bei der Installation, nur der Neustart wird später ausgeführt.

Aber wie schon geschrieben - bei der Verwendung des Recovery-Programms ist das alles irrelevant, das dabei hochgeladene System ist IMMER in der Lage, sich selbst in dem Flash-Speicher zu schreiben, wenn es zuvor aus dem Hauptspeicher gestartet wurde.

 

[H´Sishi]

Spräche denn was dagegen, wenn @nicoe das Zwischenupdate (ggfs. auf beiden 'linux_fs_start'-Umgebungen) ausprobiert und erst dann, wenn die Box läuft und erreichbar ist, den Schritt auf's aktuelle Fritz!OS macht?

 

[NDiIPP]

Mußte man bei der 7490 nicht bei einem bestimmten großen Update-Schritt über eine Zwischen-Firmware gehen …

Nicht wenn man das Recovery-Tool verwendet. Dieser Zwischenschritt ist ggf. nur beim regulären updaten bspw. über das Webif notwendig.

Also ein "durcharbeiten" ist bei Verwendung des Recovery-Tool nicht notwendig.

Edit:
Lese gerade, dass das @PeterPawn ja schon in #37 geschrieben hatte.

 

[PeterPawn]

Spräche denn was dagegen

Jein ... was sollte das denn bringen? Was wäre die Theorie dahinter, warum das ein anderes Ergebnis liefern soll, als wenn man direkt die letzte Version per Recovery-Programm installiert?

Es spricht tatsächlich nichts DAGEGEN, daß man das so macht - es spricht aber auch nichts DAFÜR, daß man damit ein anderes Ergebnis erzielen würde ... und dann kann man es genauso gut auch lassen.