Routerzwang - wie eine 1 : 1 Kopie der Firmware einer AVM 7390 herstellen ?

holox

Neuer User
Mitglied seit
11 Mrz 2008
Beiträge
69
Punkte für Reaktionen
0
Punkte
6
Guten Tag,

bzgl. meiner Frage habe ich schon im Internet recherchiert - jedoch nichts erklärendes für mich gefunden.

Nun zu meiner Frage :

Da ich, hier auf dem Lande, schnelles Internet nur von einem Anbieter bekommen kann (nämlich von KomDSL), wechselte ich zu diesem Anbieter und bin mit diesem auch sehr zufrieden.

Ich erhielt von ihm, als Router, eine AVM 7390. Wohl mit modifizierter Firmware - soll heißen, ich muß weder Nutzername noch Passwort eingeben. Einfach den Router anschliessen - fertig.

Dieses an die 7390 gebunden sein, stört mich erstmal nicht, da die 7390 ja viele Einstellungsmöglichkeiten bietet.

Da mir vor langer Zeit, durch Blitzeinschlag, ein Router zerstört wurde, möchte ich, für den Fall der Fälle, als Reserve, eine mir noch vorhandene AVM 7390 von 1&1 mit der Firmware der aktuell genutzten

Box von KomDSL versehen.

Über die Systemeinstellungen einfach die Einstellungen der 7390 KomDSL auslesen und diese in die 7390 von 1&1 einspielen, ging nicht - habe ich mir auch fast gedacht, dass dies zu einfach wäre.

Kann mir jemand sagen, ob mein Vorhaben überhaupt möglich ist, und wenn ja, was ich da genau tun muss ?

Vielen Dank für Antworten im voraus

Viele Grüße

Holox
 
Moins


Über die Systemeinstellungen einfach die Einstellungen der 7390 KomDSL mit Passwort exportieren und diese in die 7390 von 1&1 einspielen, als aus einem anderen Fritz!Box Modell, geht nicht?
 
Der Threadtitel passt nicht zum Text. Eine 1 : 1 Kopie der Firmware gibt es auf dem AVM Download-Server. Die Firmware ist nicht modifiziert.
 
Du könntest aber auch auf das Inkrafttreten des Anti-Routerzwang-Gesetz warten, und Dir dann die Zugangsdaten herausgeben lassen.
Ich meine bei DSL Anbietern gab es da keine 6 Monatige Übergangsfrist, oder?
 
erstmal vielen Dank für die Antworten !
"aus einem anderen FritzBox Modell wählen" funktioniert nicht ! Ich musste sogar diesen Punkt wählen, da ein Übernehmen in das gleiche Modell mit einer Fehlermeldung endete - warum auch immer.
Was ich noch erwähnen muss, ist, dass bei Internet -> Zugangsdaten -> wählen Sie Ihren Internetanbieter aus : bei der 7390 von 1&1 mehrere Anbieter zur Auswahl stehen (T-online usw.) - aber nicht komDSL.
Bei der komDSL 7390er steht natürlich komDSL zur Auswahl, wird ja auch genutzt, und weitere Anbieter - auch 1&1, T-online usw. - daher meine Frage ob die Firmware modifiziert ist.

Hat das irgendwas mit Branding zu tun ?
 
Wenn Branding nicht AVM ist, dann ja.

Wenn Branding nicht in der normalen FW enthalten ist, bist sogar auf die extra FW angewiesen vom Anbieter, sofern da Einstellungen enthalten sind die zwingend notwendig sind und normal nicht mit bei sind.

Die FB ruft wohl Daten über TR-069 ab beim Anbieter, und dafür wird wohl MAC oder ähnliches der FB verwendet.
 
Über den Menüpunkt System->update kann ich von AVM die aktuellsten Firmwareneuerungen herunterladen - diese werden dann auch auf die Box aufgespielt.

Wenn ich das recht verstehe, gibt es wohl in dieser Box eine Besonderheit (separat eingespielte Dateien) , welche von diesen Firmwareneuerungen unabhängig ist, aber dennoch für den Provider notwendig.

Diese speziellen "Einspielungen", welche der Provider (hier komDSL) benötigt, kann ich nicht irgendwie auslesen und auf eine andere Box einspielen ?
 
Ich würde auf "Provider Additive" im Environment tieppen - Da sollte ein Aufkleber auf der Box sein.

Hier im Forum findest du mehr über Provider Additive.
 
Vielen Dank.
Habe jetzt, hier im Forum, darüber gelesen.
Das könnte es sein, was ich meine - und was ich, fälschlicherweise, mit modifizierter Firmware benannt habe.

Nur, scheint es so, dass die meisten hier im Forum, diese Addititve loswerden möchten. Ich aber möchte diese Additive mit in eine andere Box kopieren, incl. Firmware.
 
Moins

Nun, die Additive Provider Variable verhindert ein Recovery.
Das Entfernen erlaubt zwar ein Recovery (von AVM), aber zerstört das Provider TAR-Archiv.
Also braucht es für das Recovery das Original von deinem Anbieter.
...mit anschliessenden setzen der Additiven Variable, oder?
 
Also braucht es für das Recovery das Original von deinem Anbieter.
Warum? Prinzipiell schon, aber seine Frage lautet ja auch anders ... m.W. gibt es auch keine Recovery-Programme mehr, die für spezielle Provider bereitgestellt werden (zumindest nicht mehr in dem Maße, wie bei früheren FRITZ!OS-Versionen und FRITZ!Box-Modellen).

Er hat doch noch eine funktionierende 7390, aus der er sich dieses tar-File extrahieren kann.

Mehr braucht es als Sicherung eigentlich auch nicht (ggf. noch die Support-Daten für den Inhalt des Urlader-Environments - hier besonders der "provider"-Variablen - einmal ordentlich abspeichern) ... damit kann man dann jede originale AVM-Firmware nachträglich wieder mit den Provider-Einstellungen versehen, wenn die originale Box vom Provider wieder einem Blitzschlag zum Opfer fallen sollte.

Abgesehen davon, sollte auch mit einer vorhandenen Sicherung der Einstellungen nach der ersten Provisionierung durch den Provider eigentlich wieder eine funktionierende Box entsprechend einzurichten sein ... denn diese "provider additive"-Einstellungen rüsten in der Regel ja auch nur die passenden TR-069-Konfigurationen für den ACS beim Provider nach und diese sind auch in einer Sicherungsdatei danach vorhanden.

Sollte die FRITZ!Box vom Provider zusätzlich über einen CWMP-Account verfügen, sind natürlich auch dessen Credentials eine Sicherung wert (dann reichen auch die Support-Daten nicht mehr, diese Angaben werden dort maskiert mit "SECRET"), da geht dann am besten mit dem Sichern der Ausgabe eines "cat /proc/sys/urlader/environment" in eine Textdatei, die man sicher weglegt.

Bei fast allen Konfigurationen, wo ich mich bisher mit einem CWMP-Account auseinandersetzen mußte, spielte auch das "Kennwort" dieses Accounts praktisch keine Rolle ... die (DSL-)Provider nehmen in der Regel wohl nur den CWMP-Account-Namen zur Hand und überprüfen ihn, wenn überhaupt - das Kennwort mußte meist gar nicht aus einer anderen Box übernommen werden.

Auch ist beim DSL die MAC-Adresse der Box nun wieder in den vielen Fällen egal (nicht zu verwechseln mit DOCSIS, da spielt die MAC-Adresse eine größere Rolle, weil da eigentlich immer DHCP zur Konfiguration der WAN-Verbindung verwendet wird) und es müssen keine Kopfstände zu deren Änderung unternommen werden - nur wenn auch beim DSL DHCP verwendet wird und beim Provider in diesem Zusammenhang die MAC-Adresse geprüft wird, muß man sich die Arbeit machen ... beim DSL ist aber der Kunde i.d.R. schon über die TAL (kein "shared medium") identifiziert und es braucht die MAC-Adresse gar nicht mehr.

EDIT: Die 1:1-Übernahme der Einstellungen aus einer Sicherungsdatei funktioniert m.W. nur bei identischem Branding ... also entweder die 1&1-Box auf "avm" umstellen (die KomDSL-Box ist ziemlich sicher mit diesem "Branding" versehen, was ja eigentlich keines ist) oder den OEM-Eintrag in der Sicherungsdatei ändern (inkl. Prüfsumme) und darauf bauen, daß KomDSL das Branding schlicht egal ist.
 
Zuletzt bearbeitet:
vielen Dank !!! für die ausführliche Erklärung !!!

auch wenn ich wohl nach all diesen Informationen kapitulieren muss - was meine ursprüngliche Absicht angeht.

Das übersteigt mein diesbezügliches Wissen doch deutlich.

Ich hatte so die, vielleicht naive, Vorstellung, dass es für solche "Auslesungen" und wieder "Einspielungen" spezielle Programme gibt, welche dann zu dieser 1:1 Kopie führen können.

Wie extrahiere ich diese tar-file ? - wie spiele ich es in die neue Box ein ?

Wie sichere ich die Support-Daten für den Inhalt des Urlader-Environments - hier besonders die "provider"-Variablen - und wie spiele ich diese wieder ein ?

Wie die Credentials des CWMP - Accounts ?

all dies sind Vorgänge, die mir nicht bekannt sind.

Gruß Holox
 
Zu jedem dieser Punkte gibt es hier mindestens einen (eher viele) Thread(s), das geht schon beim Auslesen der Support-Daten einer FRITZ!Box los ... das ist richtig kompliziert und nur die wenigsten kriegen das auf die Reihe.

Das Lesen der schon vorhandenen Beiträge wird Dir niemand abnehmen (können, ich persönlich auch nicht wollen) ... fertige Programme für 1:1-Kopien einer FRITZ!Box gibt es m.W. nicht. Wozu auch?

Wie schon geschrieben, kannst Du mit sehr hoher Wahrscheinlichkeit sogar einfach die Einstellungen aus der KomDSL-Box in die 1&1-Box importieren, wenn Du es richtig machst und vorher mit dem FBEditor den OEM-Eintrag anpaßt (identische FRITZ!OS-Versionen unterstelle ich).

Die Alternative, die 1&1-Box auf "avm" umzustellen (was die KomDSL-Box verwendet, steht in der Sicherungsdatei ziemlich am Anfang), braucht immerhin auch ca. 3 Minuten Arbeit (allerdings je nach eigener Lesegeschwindigkeit 1-2 Stunden für die richtige Anleitung und - viel entscheidender - deren Suche).

Dann kannst Du Dir vermutlich alles weitere sparen, das kriegst Du ja schon durch den einfachen Austausch gegen den (noch funktionierenden) KomDSL-Router heraus, ob es funktioniert oder nicht.

Wenn Du das erst dann beginnen willst, wenn das Kind schon mit der Flinte in den Brunnen geworfen wurde und die jetzt verwendete 7390 vor sich hinraucht, dann wäre es allerdings wahrscheinlich zu spät - zumindest für die Sicherung der Daten aus der 7390 und ggf. auch für den Download von Anleitungen und/oder Tools zur Umsetzung derselben.
 
Danke für den Hinweis !

Dann werde ich mal versuchen dies alles hinzubekommen.

Gruß Holox
 
Wie extrahiere ich diese tar-file ? - wie spiele ich es in die neue Box ein ?

Wenn Du einen Konsolen-Zugang zur Box hast (z.B. per Telnet), kannst Du die Datei providers-049.tar aus Deiner laufenden Box kopieren und an die geeignete Stelle Deiner zweiten Box kopieren. Evtl. könntest Du hier weitere Infos finden.

Wie sichere ich die Support-Daten für den Inhalt des Urlader-Environments - hier besonders die "provider"-Variablen - und wie spiele ich diese wieder ein ?

Sowas steht u.A. im Freetz-Wiki, wobei Du das nicht im laufenden Betrieb tun mußt, also ein Risiko weniger.

Bei allen Basteleien erste Bürgerpflicht: Vorher Konfiguration(en) sichern und ein passendes Recovery herunterladen.
 
Nochmal vielen Dank an alle - für die Hilfen

Ich denke, dass ich demnächst mal mein Glück versuchen werde

Viele Grüße Holox
 
Kleine Korrektur ... es geht um eine Provider-Konfiguration im Flash (/var/flash/provideradditive.tar, die normalerweise gar nicht als Node vorhanden ist, ähnlich wie die 87 (0x57) mit den "System geändert"-Flags, die intern "fwattrib" heißt) und nicht um die "providers-049.tar" in den Standardeinstellungen (/etc/default.$CONFIG_PRODUKT/$OEM) im SquashFS, letztere hat mit der "additive"-Konfiguration nur am Rande zu tun.

Wie genau der Provider diese Konfiguration jetzt in eine Box kriegt, ist m.W. aber auch noch nirgendwo beschrieben (genauso wenig wie der korrekte Inhalt einer per USB automatisch zu importierenden Datei) ... eine Behandlung dieser Einstellmöglichkeit findet sich sowohl im ctlmgr als auch in der libcfgimpexp.so.

Der Eintrag im Urlader-Environment hat wohl nur eine Schutzfunktion für den Inhalt des TFFS ... bei Werkseinstellungen bleibt dieser Inhalt ja erhalten (die provideradditive.tar hat theoretisch die Minor-ID 29 (0x1D) im TFFS und alles kleiner 100 wird dabei nicht gelöscht) und das Löschen über Recovery wird durch die Weigerung des Windows-Programms, wenn es eine nicht leere "provider"-Angabe (ID 451) im Environment findet, verhindert. Es ist nicht einmal ganz einfach zu ermitteln, ob der Wert der Einstellung tatsächlich irgendwelche abweichenden Abläufe auslöst ... m.W. ist dort lediglich "additive" hinterlegt.

Ich habe eben auch noch keine Box mit "provider-additive"-Konfiguration selbst in der Hand gehabt, aber - nur nach meinem Verständnis und anhand von "Spurensuche" in der Firmware - ich würde behaupten, daß der "active_provider"-Eintrag in der ar7.cfg das Vorhandensein einer solchen Konfiguration anzeigt und der ctlmgr beim Erkennen dieser Einstellung den passenden Inode-Eintrag unter /var/flash erst selbst erzeugt und dann die Daten aus diesem tar-File liest. Soweit man mir das bisher berichtet hat, ist jedenfalls auf solchen Boxen ein char-Device für die provideradditive.tar irgendwann mal vorhanden und da es nicht im Skript-Code angelegt wird wie alle anderen, muß es irgendwo an einer Fundstelle in binärem Code sein und da kommt eben nur der ctlmgr (oder libcfgimpexp.so, aber die ist eigentlich nur für den Im- und Export der Einstellungen zuständig) in Frage, wenn der Dateiname nirgendwo anders zu finden ist.

Damit sollte es eben ausreichend sein, die provideradditive.tar aus einer solchen Box zu sichern und dabei auch noch die Werte aus dem Urlader-Environment irgendwo abzuspeichern. Erstens stehen dort dann MAC-Adresse, WLAN-Key und CWMP-Credentials der "Quell-Box" drin und zweitens findet man da auch den richtigen Wert für die "provider"-Einstellung.

In einer anderen Box muß man dann eigentlich nur das gesicherte tar-Archiv in ein char-Device für genau dieselbe Minor-ID des TFFS kopieren, notfalls legt man das mit "mknod" (oder bequemer mit "mkconfigfile") vorher selbst an. Dann noch die "provider"-Einstellung im Urlader vorgenommen (und event. noch den "active_provider" in der ar7.cfg richtig gesetzt, wobei ich das erst bei einem zweiten Versuch machen würde) und bei einem Neustart sollte die Provider-Konfiguration wirksam werden. M.W. ist das in allererster Linie ohnehin nur die Einstellung für den richtigen ACS in der tr069.cfg, event. wird aber auch hier noch etwas in der ar7.cfg eingestellt, z.B. abweichende Parameter einer DSL-Verbindung, denn die wäre ja die Voraussetzung für einen erfolgreichen Kontakt zu einem ACS beim Provider.

Bis hier die Theorie ... in der Praxis konnte ich das selbst bisher nur teilweise testen. Interessant ist auch noch, daß diese Provider-Konfiguration wohl gar nicht immer mit exportiert wird, obwohl es auch in der libcfgimpexp.so entsprechende Werte für Angaben im Kopf so einer Datei gibt:
Code:
# strings lib/libcfgimpexp.so | grep Provider.*=
ProviderDefaultConfig=yes
[COLOR="#FF0000"]ProviderAdditiveConfig=yes[/COLOR]
Ich würde daher darauf tippen, daß man mit so einer Angabe ein spezielles "export"-File erstellen kann, das nur aus den "diff"-Files für die Provider-Einstellungen besteht (nicht wirklich im "diff"-Format, sondern als "Misch-File" wie bei allcfgconv) und dessen Bestandteile dann eben nicht direkt angewendet, sondern zu dieser "provideradditive.tar" zusammengepackt werden. Das könnte zumindest ein denkbarer Weg sein, wie man solche Daten in die Box kriegt, wenn das nicht bereits bei der Produktion erfolgt.

Natürlich kann das genauso gut auch mit einem "speziellen" Recovery-Programm erfolgen, was dann eben in den beiden zu schreibenden TFFS-Partitionen bereits die notwendigen Daten im an die Box zu übertragenden Image hat. Dabei reicht es ja sogar aus, nur MTD3 und MTD4 zu schreiben, das eigentliche System müßte dabei ja gar nicht angefaßt werden.

Bei der ersten Methode ginge es halt über die Box selbst - aber wohl erst nachträglich, denn ein Import ohne gesetztes Kennwort geht wohl nicht mehr und dann müßte man nach so einer Anpassung erst noch einmal "Werkseinstellungen" laden. Bei der zweiten braucht es einen "intelligenten" FTP-Client oder eben ein spezielles Programm, was das alles unter einem Dach handhaben kann - aber auch das wird sicherlich nicht unbedingt in "Handarbeit" ausgeführt wie das Recovern beim Benutzer ... wobei man manchmal da auch zu viel erwartet und es u.U. dann eben genau so läuft. Die Trivialität im realen Leben bei vielen Vorgängen an solchen Stellen ist immer wieder verblüffend.

Das sind nur theoretische Überlegungen auf der Basis einiger Fundstellen in der Firmware, wie es funktionieren könnte ... ich habe die hier eigentlich nur mal gesammelt aufgeschrieben (und korrigiere Fehler gerne, wenn man mir sagt, worin sie bestehen), damit diese immer wieder auftauchenden Fragen (was ist das, wie kommt das, kriege ich das auch hin) vielleicht mal eine Referenz finden. Um das bis ins Detail selbst auszuprobieren, fehlen mir auch Daten aus solchen Boxen, mit denen man das mal ordentlich vergleichen könnte - daher beim Ausprobieren bitte auch das eigene (Nach-)Denken nicht vernachlässigen.

Wenn man allerdings wie hier eine funktionierende "additive"-Box und eine zweite zum Probieren hat, die man auch noch anstelle der ersten anschließen kann, wenn man denkt, es könnte passen ... wieviel idealer sollen denn die Testbedingungen noch sein?
 
Lass dir doch die Firmware von KomDSL zuschicken
 
Ich weiß thema ist etwas alt aber vielleicht bringen meine infos dem ein oder anderen ja was :)

Bis hier die Theorie ... in der Praxis konnte ich das selbst bisher nur teilweise testen. Interessant ist auch noch, daß diese Provider-Konfiguration wohl gar nicht immer mit exportiert wird, obwohl es auch in der libcfgimpexp.so entsprechende Werte für Angaben im Kopf so einer Datei gibt:
Code:
# strings lib/libcfgimpexp.so | grep Provider.*=
ProviderDefaultConfig=yes
[COLOR=#FF0000]ProviderAdditiveConfig=yes[/COLOR]

Da kann ich etwas licht ins dunkel bringen und zwar habe ich so eine .export datei von meinem provider nun nach längerem hin und her bekommen, die datei ist nur 7kb groß und anfangs wird der befehl ProviderAdditiveConfig=yes aufgeführt, mit dieser .export kann ich nach einem UNSETENV und einem recover nun meine provider additive (internet, voip und tr069) wieder aufspielen und danach einfach meine eigene sicherungsdatei einspielen.
 
Zuletzt bearbeitet:
@Blackace:
Also im Prinzip das, was ich unter dem Code-Kasten in #17 geschrieben hatte, wenn ich das richtig verstanden habe. Kannst Du nicht mal die "Struktur" Deiner Datei zeigen ... das sind ja "providerspezifische" Einstellungen (und keine kundenspezifischen) und meinetwegen braucht es auch keinen "Inhalt" in den Dateien. Mich interessiert in erster Linie "der Kopf", die folgenden Datei-"Grenzen" (also die ****-Zeilen) und ggf. am Ende noch die Prüfsumme - speziell, ob die mit der "herkömmlichen" übereinstimmt (ich würde darauf zwar wetten, aber vielleicht schaltet eben das "ProviderAdditiveConfig=yes" auch diese Prüfung ab, wie es früher "NoChecks=yes" machte).

Theoretisch sollte sich diese Datei auch über "tr069starter" von einem USB-Stick lesen lassen ... dafür muß aber das Format und der Name auch wieder stimmen. Da sich dort (nach meiner Überzeugung) eine weitere Sicherheitslücke verbirgt (ein Angreifer könnte eine Datei auf dem USB-Stick ablegen und bei deren Import z.B. einen zusätzlichen User-Account im FRITZ!OS anlegen lassen), würde mich der korrekte Aufbau so einer Datei mal brennend interessieren - das spart viele Experimente und jede Menge Zeit.
 
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.