Heute habe ich alle Verbesserungen eingearbeitet und eine Anleitung 2.0 für meine Kritiker (@PeterPawn und @stoney0815) geschrieben. Nach 3 Wochen in diesem Forum, habe ich geschafft meine Fritzbox zu flashen und das Branding zu entfernen. Solange die FritzBox noch über adam2 erreichbar ist, kann man mit dieser Anleitung jede Fritzbox cable 6490 retten. Quasi das Workaround für das fehlende AVM FritzBox Recovery Tool für die Fritzbox 6490 cable!
Fritz.box! 6490 cable Branding entfernen
- Ersteller xbutan
- Erstellt am
Dies ist eine Falschaussage; es gibt keine Spiegel-Partitionen alka SoftRAID-1 bei FB6490;
mtd11 ist eine unabhängige Partition, die für "Vorgänger-System-Partition des ARM-Root-Filesystems"
und mtd12 eine unabhängige Partition, die für "Vorgänger-System-Partition des ARM-Kernel-Filesystems"
verwendet wird.
- Mitglied seit
- 7 Okt 2015
- Beiträge
- 7,717
- Punkte für Reaktionen
- 997
- Punkte
- 113
Sorry für den Fullquote - aber ich möchte das später nochmals in Ruhe durchlesen, und verfolgen was denn an dieser "Anleitung" welche nicht mal die möglichen Unterschiede und Herrangehensweisen der div. FW Versionen angibt, verändert, denn bislang gab es wie auch anders im Netz nur "krawitschko". Was auch der Grund ist (ich denke es können sicher mindestens ein Dutzend Leute eine Anleitung verfassen, welche alle Belangen/Konstellationen abdeckt)
Ich bin mit meiner erst kürlich in Anrissen geposteten .txt bislang immer gut gefahren - ein File mit nicht mal 50 (kurzen) Zeilen - klar sollte man sich dann das nötige Wissen auch noch dazu erlesen, aber ansich kann ich mit meinen Notizen (die Infos stammen alle aus dem IPPF - nichts externes imo nichts falsch machen.
Und alle die jetzt neu in das Thema einsteigen, gilt leider "wer zu spät kommt den bestraft das Leben" (soll heißen diese müssen jetzt mindestens das doppelte lesen, als die "älteren")
Auch nicht IT Profis können sich die Infos im Forum holen (ich selbst bin auch "nur" Kaufmann, mit einem Hang zu IT)
-- aktualisiert --
bei mir dauert das ca. 10 Minuten ?!
Warum verfasst Du diese dann ? (das ist genau der Grund, weshalb es noch keiner richtig gemacht hat und alle "Anleitung" einfach fehlerhaft sind.)
Was genau soll man darunter verstehen ?
Hääää ??? Warum nicht direkt die linux-console missbrauchen??
das ist dann aber mehr Glück den Bootloader zu erreichen - im Zweifelsfall hilft die Netzwerkverbindungsanzeige - sobald diese von nicht verbunden wechselt - enter - oder eben weiter in Linux und mit eva_discover...
Man ist also autmatisch im richtigen Ausgangsverzeichnis, sodass Pfadangeben überflüssig werden/sind ?
Das sind doch Fehler? Wieso ignorierst Du diese einfach ?
Ich greife jetzt nicht alles auf, was mir ins Auge gefallen ist, weil mir ehrlich gesagt die Lust dazu fehlt, alles nochmals nachzuschlagen, damit ich nichts falsches schreibe, allerdings ist wie @PeterPawn schon zu allen "Anleitungen" dieser Art schrieb, extreme Vorsicht geboten und ein C&P führt sicher zu einem GAU.
Zuletzt bearbeitet:
Das Ausführen von Skripten mit falschem Befehls-Interpreter (DASH statt BASH) ist Unfug!
insgesamt ist die Anleitung2 schlecht recherchiert;
Beispiel:
unklar, wie hier TE die YourFritz-Tools auf den Win10 Rechner gebracht hat;
auch ist mir schleierhaft, ob der Verfasser jemals die "Anleitung" from "Scratch" mal ausprobiert hat;
Zuletzt bearbeitet:
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,148
- Punkte für Reaktionen
- 1,705
- Punkte
- 113
Ich bleibe bei meiner Warnung und damit auch dabei: Der TO hier hat einfach nicht verstanden, wie das TFFS-Image in den beiden Partitionen und die über den Bootloader "auslesbaren Dateien" mit den (Pseudo-)Namen "env" und "count" überhaupt zusammenhängen. Daher sind die gesammelten Ausführungen in #1 zum Auslesen dieser Daten (die beim Installieren der Retail-Firmware gar nicht geändert werden müssen, mit Ausnahme von "firmware_version") auch eher zusammenhanglos und/oder teilweise veraltet oder unlogisch oder auch schlicht falsch.
Anstatt sich zu überlegen, ob nicht nur irgendetwas beim Befolgen von fremden Anleitungen (z.B. der von @derlerner) durch den (und beim) TO nicht stimmte, wurden hier (unnötigerweise) irgendwelche "Workarounds" gesucht und beschrieben, die wiederum teilweise falsch sind und/oder vollkommen unnötig sind in den meisten Szenarien oder wo gar nicht plausibel wird, warum diese nun auf einmal funktionieren sollten, wenn das anderenorts beschriebene Vorgehen angeblich nicht klappte.
Bestes Beispiel hier ist das Auslesen des Environments über "eva_get_environment" vs. Auslesen im ASCII-Mode nach einer alten Anleitung (für den W501V) in WHMF. Da werden zwar exakt dieselben Daten aus der FRITZ!Box gelesen (beides ist ein "RETR env" nach "MEDIA FLSH" im FTP-Server), aber das eine funktioniert eben nicht und das andere dann angeblich schon. Die Logik dahinter würde ich zu gerne verstehen ... leider geht das offenbar über meinen Horizont.
Ich bin ja immerhin noch beruhigt, daß ich nur zu lange Kritiken schreibe und ansonsten halt nur defekte Shell-Skripte veröffentliche, die (zumindest nach Ansicht des TO) einfach nicht funktionieren .. trotzdem hat er offenbar an einigen Stellen auf das Repository zurückgegriffen. Das erfährt man aber nur, wenn man die Anleitungen von anderen liest ... ansonsten hat er offenbar irgendwo ein "build_tffs_image" gefunden.
Sollte es sich tatsächlich um Dateien aus meinem Fundus handeln: Gern geschehen ... aber das ändert immer noch nichts daran, daß ich jedem weiteren Leser dieser Anleitung in #1 nur ganz, ganz dringend raten kann, weder meine Dateien noch deren "Beschreibung" in #1 einfach so "hinzunehmen" und sich lieber selbst ein Bild zu machen, ob und wie die tatsächlich funktionieren - und zwar anhand der jeweiligen originalen Quellen und der Beschreibung an anderen Stellen als in diesem Thread.
Die tatsächlich sinnvollen Stellen (die Anleitung von @derlerner, die Anleitung von @fesc zum Erstellen des TFFS-Images mit den Tools auf dem YourFritz-Repo und nicht zuletzt meine Beschreibungen für "eva_discovery" und "eva_store_tffs" (mit dem man auch andere als die TFFS-Partitionen beschreiben kann) sind nicht so schwer zu finden und ggf. sogar in #1 tatsächlich verlinkt (sofern sie nicht von mir geschrieben wurden, dann gab es halt keine Chance) - was sich hinter den Links jeweils tatsächlich befindet, kriegt man ja nur durch das Folgen heraus, eine "Inhaltsangabe" fehlt leider.
Anstatt sich nun also irgendwie zu freuen, daß hier in #1 eine Anleitung zusammengetragen wurde, der man einfach nur zu folgen braucht und dann klappt das schon irgendwie, sollte man selbst noch einmal die verlinkten Quellen lesen, sie nach ihrem Alter beurteilen (alles vor 2015 sollte man gleich wieder vergessen, sofern dort nicht ausdrücklich noch irgendwann ergänzt wurde, daß es für die 6490/6590 ebenso funktioniert) und ansonsten eben so lange selbst suchen, bis man die passende Original-Quelle für die vom TO beschriebenen Teilschritte gefunden hat.
Beispiele für eher abstruse Quellenangaben gefällig?
Die wichtigen Quellen, die dem TO beim Erreichen seines Ziels geholfen haben, zuerst:
http://www.triebwerk23.de/joomla/index.php/firewalls/fritzbox-6490-cable-reset-bei-bootloop - schön bebilderte Anleitung, die aber (wie auch deren Autor selbst anmerkt) auf der Beschreibung von @fesc hier im IPPF beruht
http://www.wehavemorefun.de/fritzbox/TFFS_image_basteln_mit_mktffs.pl - ein Beispiel von enrik aus dem Jahr 2004, wie man mit einem Perl-Skript ein TFFS-Image erstellen könnte ... ich mag ja etwas voreingenommen sein, aber ich finde in #1 überhaupt nichts dazu, daß und wie der TO überhaupt Perl verwendet hat (oder daß er auch nur eine Idee hätte, was das sein sollte), aber vielleicht kann mir ja jemand auf die Sprünge helfen, wo hier ein Zusammenhang besteht.
https://www.ip-phone-forum.de/threads/help-fritz-7170sl.145910/ - ein 10 Jahre alter Thread hier aus dem IPPF zur 7170SL (keine Angst, nur drei Beiträge, schnell gelesen) ... was mag hier wohl die Ursache gewesen sein, daß dieser es in die "Hitliste" der für den TO wichtigsten Quellen geschafft hat?
http://www.wehavemorefun.de/fritzbox/Auslesen_des_Flashspeichers - die schon erwähnte Anleitung zum Auslesen des Flash-Speichers bei einem W501V ... erstens funktioniert das "GET" (aka "RETR") bei der 6490 ausschließlich für die vordefinierten Pseudonamen ("env" und "count" sind zwei davon), zweitens ist das aktives FTP (m.W. kann die 6490 das gar nicht, zumindest nicht mit meiner Loaderversion) und drittens ist das einzige, was da mit irgendeinem Text in #1 übereinstimmen dürfte, vermutlich das FTP-Login.
Bei "weitere Anleitungen" sind dann zwei Beiträge aus dem "großen Thread" verlinkt, in denen jeweils nur das Flashen eines einzelnen Systems (für eine Architektur im Puma6) beschrieben ist und wo das erst im Nachhinein klargestellt wurde im Thread, daß es schon vier Partitionen zu schreiben gilt bei der 6490.
Sieht man sich das alles wirklich genauer an, was da in #1 verzapft wurde und hinterfragt das ein wenig, ist es - inzwischen inkl. der "Quellenangaben" - an Albernheiten und Mangel von Plausibilität kaum noch zu überbieten; fehlt nur noch der Bergkristall, der zuvor dreimal über der Box geschwenkt werden muß.
Vor dem ebenfalls in #1 verlinkten tecchannel.de-Artikel aus 2006 kann man auch nur noch einmal ausdrücklich warnen, der dreht sich um eine Version 04.05 für eine FRITZ!Box 7050 ... das war ein vollkommen anderer Loader und ein vollkommen anderes System (noch ADAM2 und Kernel 2.4). Der mag damals gut und richtig gewesen sein, hat aber mit einer 6490 praktisch (fast) nichts mehr zu tun.
Im Vergleich mit dieser hier ist jedenfalls die Anleitung von @derlerner um Meilen besser ... die dort von mir geäußerten Kritikpunkte (unreflektierte Verwendung von "SETENV my_ipaddress" und "debug" - aber vielleicht erklärt mir ja auch mal irgendjemand, warum ich mich irre und dieses "debug" tatsächlich einen Sinn ergibt) tun mir schon fast leid (auch das Beklagen, daß da Erklärungen der einzelnen Schritte, gerade für Anfänger als Zielgruppe, fehlen), wenn ich mir hier ansehe, was man stattdessen an Unsinn hätte schreiben können.
Der größte Kritikpunkt beim Original (die schlechte Auffindbarkeit, wenn man diese Anleitung im "Monster-Thread" irgendwo mittendrin versteckt) hat sich ja leider immer wieder bewahrheitet und ich hoffe inständig, daß nicht dieser Thread am Ende von weiteren Lesern als "Anleitung" herangezogen wird, sondern daß so viele Leute wie nur möglich dann auf das Original von @derlerner zurückgreifen.
Anstatt sich zu überlegen, ob nicht nur irgendetwas beim Befolgen von fremden Anleitungen (z.B. der von @derlerner) durch den (und beim) TO nicht stimmte, wurden hier (unnötigerweise) irgendwelche "Workarounds" gesucht und beschrieben, die wiederum teilweise falsch sind und/oder vollkommen unnötig sind in den meisten Szenarien oder wo gar nicht plausibel wird, warum diese nun auf einmal funktionieren sollten, wenn das anderenorts beschriebene Vorgehen angeblich nicht klappte.
Bestes Beispiel hier ist das Auslesen des Environments über "eva_get_environment" vs. Auslesen im ASCII-Mode nach einer alten Anleitung (für den W501V) in WHMF. Da werden zwar exakt dieselben Daten aus der FRITZ!Box gelesen (beides ist ein "RETR env" nach "MEDIA FLSH" im FTP-Server), aber das eine funktioniert eben nicht und das andere dann angeblich schon. Die Logik dahinter würde ich zu gerne verstehen ... leider geht das offenbar über meinen Horizont.
Ich bin ja immerhin noch beruhigt, daß ich nur zu lange Kritiken schreibe und ansonsten halt nur defekte Shell-Skripte veröffentliche, die (zumindest nach Ansicht des TO) einfach nicht funktionieren .. trotzdem hat er offenbar an einigen Stellen auf das Repository zurückgegriffen. Das erfährt man aber nur, wenn man die Anleitungen von anderen liest ... ansonsten hat er offenbar irgendwo ein "build_tffs_image" gefunden.
Sollte es sich tatsächlich um Dateien aus meinem Fundus handeln: Gern geschehen ... aber das ändert immer noch nichts daran, daß ich jedem weiteren Leser dieser Anleitung in #1 nur ganz, ganz dringend raten kann, weder meine Dateien noch deren "Beschreibung" in #1 einfach so "hinzunehmen" und sich lieber selbst ein Bild zu machen, ob und wie die tatsächlich funktionieren - und zwar anhand der jeweiligen originalen Quellen und der Beschreibung an anderen Stellen als in diesem Thread.
Die tatsächlich sinnvollen Stellen (die Anleitung von @derlerner, die Anleitung von @fesc zum Erstellen des TFFS-Images mit den Tools auf dem YourFritz-Repo und nicht zuletzt meine Beschreibungen für "eva_discovery" und "eva_store_tffs" (mit dem man auch andere als die TFFS-Partitionen beschreiben kann) sind nicht so schwer zu finden und ggf. sogar in #1 tatsächlich verlinkt (sofern sie nicht von mir geschrieben wurden, dann gab es halt keine Chance) - was sich hinter den Links jeweils tatsächlich befindet, kriegt man ja nur durch das Folgen heraus, eine "Inhaltsangabe" fehlt leider.
Anstatt sich nun also irgendwie zu freuen, daß hier in #1 eine Anleitung zusammengetragen wurde, der man einfach nur zu folgen braucht und dann klappt das schon irgendwie, sollte man selbst noch einmal die verlinkten Quellen lesen, sie nach ihrem Alter beurteilen (alles vor 2015 sollte man gleich wieder vergessen, sofern dort nicht ausdrücklich noch irgendwann ergänzt wurde, daß es für die 6490/6590 ebenso funktioniert) und ansonsten eben so lange selbst suchen, bis man die passende Original-Quelle für die vom TO beschriebenen Teilschritte gefunden hat.
Beispiele für eher abstruse Quellenangaben gefällig?
Die wichtigen Quellen, die dem TO beim Erreichen seines Ziels geholfen haben, zuerst:
http://www.triebwerk23.de/joomla/index.php/firewalls/fritzbox-6490-cable-reset-bei-bootloop - schön bebilderte Anleitung, die aber (wie auch deren Autor selbst anmerkt) auf der Beschreibung von @fesc hier im IPPF beruht
http://www.wehavemorefun.de/fritzbox/TFFS_image_basteln_mit_mktffs.pl - ein Beispiel von enrik aus dem Jahr 2004, wie man mit einem Perl-Skript ein TFFS-Image erstellen könnte ... ich mag ja etwas voreingenommen sein, aber ich finde in #1 überhaupt nichts dazu, daß und wie der TO überhaupt Perl verwendet hat (oder daß er auch nur eine Idee hätte, was das sein sollte), aber vielleicht kann mir ja jemand auf die Sprünge helfen, wo hier ein Zusammenhang besteht.
https://www.ip-phone-forum.de/threads/help-fritz-7170sl.145910/ - ein 10 Jahre alter Thread hier aus dem IPPF zur 7170SL (keine Angst, nur drei Beiträge, schnell gelesen) ... was mag hier wohl die Ursache gewesen sein, daß dieser es in die "Hitliste" der für den TO wichtigsten Quellen geschafft hat?
http://www.wehavemorefun.de/fritzbox/Auslesen_des_Flashspeichers - die schon erwähnte Anleitung zum Auslesen des Flash-Speichers bei einem W501V ... erstens funktioniert das "GET" (aka "RETR") bei der 6490 ausschließlich für die vordefinierten Pseudonamen ("env" und "count" sind zwei davon), zweitens ist das aktives FTP (m.W. kann die 6490 das gar nicht, zumindest nicht mit meiner Loaderversion) und drittens ist das einzige, was da mit irgendeinem Text in #1 übereinstimmen dürfte, vermutlich das FTP-Login.
Bei "weitere Anleitungen" sind dann zwei Beiträge aus dem "großen Thread" verlinkt, in denen jeweils nur das Flashen eines einzelnen Systems (für eine Architektur im Puma6) beschrieben ist und wo das erst im Nachhinein klargestellt wurde im Thread, daß es schon vier Partitionen zu schreiben gilt bei der 6490.
Sieht man sich das alles wirklich genauer an, was da in #1 verzapft wurde und hinterfragt das ein wenig, ist es - inzwischen inkl. der "Quellenangaben" - an Albernheiten und Mangel von Plausibilität kaum noch zu überbieten; fehlt nur noch der Bergkristall, der zuvor dreimal über der Box geschwenkt werden muß.
Vor dem ebenfalls in #1 verlinkten tecchannel.de-Artikel aus 2006 kann man auch nur noch einmal ausdrücklich warnen, der dreht sich um eine Version 04.05 für eine FRITZ!Box 7050 ... das war ein vollkommen anderer Loader und ein vollkommen anderes System (noch ADAM2 und Kernel 2.4). Der mag damals gut und richtig gewesen sein, hat aber mit einer 6490 praktisch (fast) nichts mehr zu tun.
Im Vergleich mit dieser hier ist jedenfalls die Anleitung von @derlerner um Meilen besser ... die dort von mir geäußerten Kritikpunkte (unreflektierte Verwendung von "SETENV my_ipaddress" und "debug" - aber vielleicht erklärt mir ja auch mal irgendjemand, warum ich mich irre und dieses "debug" tatsächlich einen Sinn ergibt) tun mir schon fast leid (auch das Beklagen, daß da Erklärungen der einzelnen Schritte, gerade für Anfänger als Zielgruppe, fehlen), wenn ich mir hier ansehe, was man stattdessen an Unsinn hätte schreiben können.
Der größte Kritikpunkt beim Original (die schlechte Auffindbarkeit, wenn man diese Anleitung im "Monster-Thread" irgendwo mittendrin versteckt) hat sich ja leider immer wieder bewahrheitet und ich hoffe inständig, daß nicht dieser Thread am Ende von weiteren Lesern als "Anleitung" herangezogen wird, sondern daß so viele Leute wie nur möglich dann auf das Original von @derlerner zurückgreifen.
Ich muss euch natürlich Recht geben, dass es keine Originalquellen sind. Die Quellen wurde nur ausgewählt, um einen möglichst schnellen Überblick zu bekommen. Wie PeterPawn kritisch angemerkt hat, sind die Quellen alt und wurden für andere Modelle veröffentlicht. Der Punkt ist, dass es bei mir funktioniert hat. Daher werde ich die Methode erst überarbeiten, wenn jemand hier schreibt, dass die Methode nicht funktioniert hat und es auf eine andere Art besser ist.
Die Anleitung wurde absichtlich so aufgebaut, dass meine Methoden als letzte aufgeführt wurden. Von den getesteten zu den experimentellen Methoden, um eurer Kritik schonmal den Wind aus den Segeln zu nehmen. Ich hätte auch provokativ schreiben können, dass ein Skript zum auslesen der env Datei und das flashen mit 4 simplen Befehlen ersetzt werden kann. Habe ich aber nicht, da offensichtlich bei anderen das Skript von PeterPawn einwandfrei funktioniert. @Shirocco88 selbstverständlich habe ich den Header geändert und eine count.txt datei ohne Fehler verwendet. Ich habe nur die Grenzen ausgelotet.
Wenn jemand in der gleichen Situation ist und die Wahl zwischen einem Briefbeschwerer, einem unmoralischen Angebot die Box für 10 Euro zu verkaufen und einer Chance auf Rettung hat, für was wird er sich entscheiden?
Aber mir ist noch ein Problem aufgefallen, das ich allerdings bald lösen werde: Denn ich kann nicht überprüfen welche Seriennummer in der Box gespeichert ist bzw. ob mit einer modifizierten env.txt die Seriennummer verändert werden kann. Optimistisch betrachtet, ist entweder keine Seriennummer in der Box abgespeichert oder kann nicht vom dem Anwender oder dem Provider ausgelesen werden.
Falls ich nun meine Fritzbox als Router verwenden will, muss ich dem Provider meine Mac-Adresse und meine Seriennummer mitteilen. Solange beide die Originale sind, die auf der Box stehen, kann AVM oder der Provider lediglich in einer Tabelle diese nachprüfen und wird herausfinden, dass diese zueinander passen. Falls eine aktive Prüfung oder ein Schlüssel generiert wird, werde ich versuchen die originale Seriennummer der Fritzbox mit einer modifizierten env.txt Datei wieder herzustellen, da meine Seriennummer eventuell durch das Flashen von mtd3 und mtd4 gelöscht wurde.
Die Anleitung wurde absichtlich so aufgebaut, dass meine Methoden als letzte aufgeführt wurden. Von den getesteten zu den experimentellen Methoden, um eurer Kritik schonmal den Wind aus den Segeln zu nehmen. Ich hätte auch provokativ schreiben können, dass ein Skript zum auslesen der env Datei und das flashen mit 4 simplen Befehlen ersetzt werden kann. Habe ich aber nicht, da offensichtlich bei anderen das Skript von PeterPawn einwandfrei funktioniert. @Shirocco88 selbstverständlich habe ich den Header geändert und eine count.txt datei ohne Fehler verwendet. Ich habe nur die Grenzen ausgelotet.
Wenn jemand in der gleichen Situation ist und die Wahl zwischen einem Briefbeschwerer, einem unmoralischen Angebot die Box für 10 Euro zu verkaufen und einer Chance auf Rettung hat, für was wird er sich entscheiden?
Aber mir ist noch ein Problem aufgefallen, das ich allerdings bald lösen werde: Denn ich kann nicht überprüfen welche Seriennummer in der Box gespeichert ist bzw. ob mit einer modifizierten env.txt die Seriennummer verändert werden kann. Optimistisch betrachtet, ist entweder keine Seriennummer in der Box abgespeichert oder kann nicht vom dem Anwender oder dem Provider ausgelesen werden.
Falls ich nun meine Fritzbox als Router verwenden will, muss ich dem Provider meine Mac-Adresse und meine Seriennummer mitteilen. Solange beide die Originale sind, die auf der Box stehen, kann AVM oder der Provider lediglich in einer Tabelle diese nachprüfen und wird herausfinden, dass diese zueinander passen. Falls eine aktive Prüfung oder ein Schlüssel generiert wird, werde ich versuchen die originale Seriennummer der Fritzbox mit einer modifizierten env.txt Datei wieder herzustellen, da meine Seriennummer eventuell durch das Flashen von mtd3 und mtd4 gelöscht wurde.
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,148
- Punkte für Reaktionen
- 1,705
- Punkte
- 113
Auch wenn der Ton wieder sachlicher zu werden scheint, ist das noch kein Ersatz für eine akkurate Beschreibung in #1.
Spaßig ist schon mal, daß dem TO hier offenbar bisher immer noch nicht aufgefallen ist, daß es sich bei dem Forum unter der Adresse www.iptelevisionsforum.biz um genau dasselbe handelt, wie hier ... es ist lediglich eine andere (ältere) Adresse, für die obendrein seit einiger Zeit das TLS-Zertifikat nicht mehr stimmt und wo man sich also erst mit der üblichen Zertifikatwarnung eines modernen Browsers auseinandersetzen muß.
Ein weiteres Beispiel für (offensichtlich, jedenfalls nach meinem Dafürhalten) vollkommen falsch verstandene Zusammenhänge:
Das Überschreiben beider Systeme (aktiv und inaktiv) in der Box ist nicht nur unnötig, es ist am Ende auch fahrlässig, weil es den möglichen Rückweg zu einem funktionierenden System verbaut und den Benutzer dazu zwingt, zu einem (für ihn positiven) Ergebnis zu kommen, bevor er das Gerät wieder benutzen kann. Ich mag ja nur zu blöd sein, den Grund für eine solche Entscheidung zu verstehen ... aber eine "Erklärung" ist
Vom "freien Bearbeiten" der eigenen "env.txt", wie es in #1 empfohlen wird, kann man nur dringend abraten (es sei denn, man weiß wirklich, was man da tut und welche Auswirkungen das am Ende hat) und warum von den 3 KB der erzeugten TFFS-Image-Datei beim TO am Ende nur 2.302 Byte per FTP auf die Box übertragen wurden, würde ich mich als aufmerksamer Beobachter/Leser auch fragen.
Über die Frage, wieso die erste Version der Anleitung in #1 beim TO angeblich funktionieren konnte, wenn es dann weitere drei Wochen dauerte, bis die Box überhaupt wieder halbwegs funktionierte (nachdem das TFFS am Beginn bereits zerschossen wurde), denke ich da schon gar nicht mehr nach ... die einzige mögliche Antwort (in meinen Augen jedenfalls) wäre es halt, daß es glatt gelogen war, daß dieses Vorgehen tatsächlich funktioniert hätte.
Wie man so etwas (was offensichtlich bei einem selbst gar nicht funktionierte und das muß lange nicht an der jeweils verwendeten Anleitung liegen) dann auch noch selbst als "Anleitung" für andere veröffentlichen kann, verstehe ich einfach nicht ... da hat jemand entweder seine eigenen Fähigkeiten maßlos überschätzt oder die Empfehlungen:
Spaßig ist schon mal, daß dem TO hier offenbar bisher immer noch nicht aufgefallen ist, daß es sich bei dem Forum unter der Adresse www.iptelevisionsforum.biz um genau dasselbe handelt, wie hier ... es ist lediglich eine andere (ältere) Adresse, für die obendrein seit einiger Zeit das TLS-Zertifikat nicht mehr stimmt und wo man sich also erst mit der üblichen Zertifikatwarnung eines modernen Browsers auseinandersetzen muß.
Ein weiteres Beispiel für (offensichtlich, jedenfalls nach meinem Dafürhalten) vollkommen falsch verstandene Zusammenhänge:
"eva_store_tffs" (ich gehe hier allerdings davon aus, daß es sich bei dem Skript mit diesem Namen um das aus meinem YourFritz-Repository handelt, denn das taucht in #1 zumindest als Name auch mal auf) sollte, hat und wird niemals zum Auslesen des Environments dienen (in allen möglichen und richtigen Zeitformen dieses Verbs) ... das Skript dient dazu, ein zuvor erzeugtes TFFS-Image (dafür nimmt ja sogar der TO offenbar "build_tffs_image" - auch wenn es sein Geheimnis bleibt, woher es kommt) in die SPI-Partition einer FRITZ!Box zu transferieren.
Das Überschreiben beider Systeme (aktiv und inaktiv) in der Box ist nicht nur unnötig, es ist am Ende auch fahrlässig, weil es den möglichen Rückweg zu einem funktionierenden System verbaut und den Benutzer dazu zwingt, zu einem (für ihn positiven) Ergebnis zu kommen, bevor er das Gerät wieder benutzen kann. Ich mag ja nur zu blöd sein, den Grund für eine solche Entscheidung zu verstehen ... aber eine "Erklärung" ist
für mich ganz deutlich nicht, auch nicht in Kombination mit der (durchaus mißverständlichen und nach meiner Ansicht vom TO auch selbst nicht wirklich richtig "verdauten") Feststellung:
Ich persönlich finde das Prinzip der alternierenden Systeme in den FRITZ!Box-Routern damit nur sehr unzureichend beschrieben ... auf "linux_fs_start" geht der gesamte Beitrag in #1 (aktueller Stand) gar nicht erst ein. Keine Ahnung, ob der TO hier überhaupt weiß, worum es sich handelt und wie das funktioniert ... zumal das ja bei der 6490 auch noch direkte Auswirkungen darauf hat, welche eMMC-Partitionen nun tatsächlich vom Bootloader als "mtd0", "mtd1", usw. angesehen werden.
Vom "freien Bearbeiten" der eigenen "env.txt", wie es in #1 empfohlen wird, kann man nur dringend abraten (es sei denn, man weiß wirklich, was man da tut und welche Auswirkungen das am Ende hat) und warum von den 3 KB der erzeugten TFFS-Image-Datei beim TO am Ende nur 2.302 Byte per FTP auf die Box übertragen wurden, würde ich mich als aufmerksamer Beobachter/Leser auch fragen.
Hier würde ich einfach mal sagen/schreiben, daß niemand in eine solche Zwangslage geraten würde, wenn er sich zuerst mal schlau macht (und durch die immer noch bestehenden Wissenslücken des TO hier kann man m.E. weiterhin mit einem Bus fahren) und erst dann ans Werk geht. Solange er dazu nicht diesen Thread heranzieht, stehen seine Chancen auch recht gut, daß er niemals in eine solche Zwangslage geraten wird. Das Überschreiben von "mtd3" und "mtd4" mit einer Textdatei in der ersten Version dieser "Anleitung" war eindeutig ein "unforced error" ... ich wäre extrem überrascht, wenn es für ein solches Vorgehen irgendwoanders tatsächlich eine Anleitung geben sollte, die der TO auch wirklich richtig verstanden hat beim "Nachmachen" - deren Autor wäre dann aber (wenn das dort tatsächlich so beschrieben sein sollte) in etwa "dasselbe Kaliber" wie der TO hier.
Über die Frage, wieso die erste Version der Anleitung in #1 beim TO angeblich funktionieren konnte, wenn es dann weitere drei Wochen dauerte, bis die Box überhaupt wieder halbwegs funktionierte (nachdem das TFFS am Beginn bereits zerschossen wurde), denke ich da schon gar nicht mehr nach ... die einzige mögliche Antwort (in meinen Augen jedenfalls) wäre es halt, daß es glatt gelogen war, daß dieses Vorgehen tatsächlich funktioniert hätte.
Wie man so etwas (was offensichtlich bei einem selbst gar nicht funktionierte und das muß lange nicht an der jeweils verwendeten Anleitung liegen) dann auch noch selbst als "Anleitung" für andere veröffentlichen kann, verstehe ich einfach nicht ... da hat jemand entweder seine eigenen Fähigkeiten maßlos überschätzt oder die Empfehlungen:
von hier schlicht nicht verstanden/eingehalten.
Ich bräuchte noch einen Tipp, wie ich neue Zertifikate erstellen kann und wo diese gespeichert sind. Eine Fritzbox, die funktioniert, aber nicht als Router verwendet werden kann, ist letztendlich auch nur ein Briefbeschwerer.
- Mitglied seit
- 7 Okt 2015
- Beiträge
- 7,717
- Punkte für Reaktionen
- 997
- Punkte
- 113
Wie lange beschäftigst Du Dich jetzt schon so intensiv mit dem Thema?
Man kann sich selbst keine Zertifikate erstellen, diese sind entweder (ab Werk) an Bord oder wurden kurzzeitig mit einem FW Update ausgestellt/aktualisiert.
Man kann sich selbst keine Zertifikate erstellen, diese sind entweder (ab Werk) an Bord oder wurden kurzzeitig mit einem FW Update ausgestellt/aktualisiert.
Welchen Typ von Zertifikat meinst Du ? TLS oder CM
Bzgl. CM-Zertifikate wendest Du dich am Besten an den Verkäufer, der dieses Produkt erstmalig in den Handel gebracht hat, und an den Endkunden verkauft hat.
Hinweis: Bei Provider-Boxen ist dies nicht der Hersteller, z.B. FB7362SL ist dies 1&1;
bei FB6490 Provider-Mietboxen, die vergessen wurden zurückzugeben, kann es schwierig werden etwaige neue CM-Zertificate zu erhalten.
Zuletzt bearbeitet:
ist es eigentlich normal, dass die Box mehrmals durchstartet wenn sie ne Verbindung zum Kabelnetz bekommt? Hatte sie zurückgesetzt und eben mal kurz in meiner neuen Wohnung drangehängt. Ins Internet kam ich nicht, dafür startete die Box ständig komplett neu... Ich hab aber auch noch keinen blassen Schimmer ob da an der Dose wirklich etwas liegt, Unitymedia bekommt es schon nicht hin mir ihren Router an meine derzeitige Adresse zu senden... Ich glaube ich teste erstmal deren Router.. Das mit dem Neustart hatte ich aber auch schon als ich die Box an meiner 7490 über Lan1 hatte...
lag am Netzteil. Hab jetzt mal das von der Unitymediabox reingesteckt und es funktioniert [emoji16][emoji106] Bin grad in der neuen Wohnung über die Fritzbox online *freu*
Gesendet von iPhone mit Tapatalk Pro
Gesendet von iPhone mit Tapatalk Pro
Hallo
Ich habe eine FritzBox 6490 mit der Firmwareversion 6.50 (Kabelbetreiber KDG)
Habe ich hier irgendeine Möglichkeit es zu debranden und die aktuellste Firmware aufzuspielen, oder gibt es da keine Chance?
Danke
Ich habe eine FritzBox 6490 mit der Firmwareversion 6.50 (Kabelbetreiber KDG)
Habe ich hier irgendeine Möglichkeit es zu debranden und die aktuellste Firmware aufzuspielen, oder gibt es da keine Chance?
Danke
- Mitglied seit
- 7 Okt 2015
- Beiträge
- 7,717
- Punkte für Reaktionen
- 997
- Punkte
- 113
Ja hast Du, sogar zwei Möglichkeiten
suchen, lesen, verstehen und umsetzten musst Du allerdings.
Variante 1 in Stichpunkten
Variante 2 in Stichpunkten
suchen, lesen, verstehen und umsetzten musst Du allerdings.
Variante 1 in Stichpunkten
Code:
./tffs_add_file
run_update und update_firmware
./eva_store_tffs mtd3/4Variante 2 in Stichpunkten
Code:
./tffs_add_file
./eva_store_tffs mtd0,1,6,7 oder 11,12,13,14 je nach "linux_fs_start" VariableOha.. super, dann gibt es zumindest ein Fünkchen Hoffnung. Bloss mit den paar Zeilen kann ich jetzt auf Anhieb nicht viel anfangen. Gibt es hierfür irgendwo ein Tutorial mit Step-by-Step Anleitung? Das wäre super
Doch prinzipiell geht das, Stichwort FTP. Benutz dazu mal die Suchfunktion es würde hier schon alles Wissenswerte dazu geschrieben.
Sollte man aber tunlichst unterlassen wenn das die eigene miet- Fritz am eigenen KDG Anschluss wäre. Macht nur Sinn wenn man die grau erworben hat und bei einem anderen Anbieter ungleich KDG nutzen will. Bei KDG werden so grau erworbene boxen nicht aktiviert da man deren MAC kennt und die miet-boxen als unverkäuflich betrachtet.
Sollte man aber tunlichst unterlassen wenn das die eigene miet- Fritz am eigenen KDG Anschluss wäre. Macht nur Sinn wenn man die grau erworben hat und bei einem anderen Anbieter ungleich KDG nutzen will. Bei KDG werden so grau erworbene boxen nicht aktiviert da man deren MAC kennt und die miet-boxen als unverkäuflich betrachtet.
Nein, ich möchte die Übergangsweise für Unitymedia nutzen, aber dazu hätte ich gerne die aktuellste Firmware
- Mitglied seit
- 7 Okt 2015
- Beiträge
- 7,717
- Punkte für Reaktionen
- 997
- Punkte
- 113
Neueste Beiträge
-
Überspannungsschutz für DSL Kabel - Fritzbox ständig defekt (Modem)- Letzte: Exodus88
-
FRITZ!App Fon DTMF Steuerung geht nicht- Letzte: stoney
-
1und1 Umstellung auf 50/20 Mbit im Alt Tarif denkbar?
- Letzte: stoney
-
FRITZ!Box 5590 - INHAUS - Smart24P1 - 7.90 - Sammelthema- Letzte: Daniel Lücking
-
Vorlage für LED500 und Sensor 350, Farbwechsel möglich ?!?- Letzte: woriem
-
Ansage ohne Sprachaufzeichnung im UC Suite Paket
- Letzte: PowerMike
