CWMP Account hinzufügen/ändern

Hi,

wenn ich wüßte, wo ich ctlmgr oder libtr069.so patchen müßte. Ich habe da nichts gefunden bis jetzt...

Die ctlmgr und libtr069 der 7170 unterscheiden sich stark zu denen von der 7270/KDG HomeBox.

Grüße

StefanV3
 
[Edit frank_m24: Mehrere Beiträge zusammengefasst. Man kann seine Beiträge auch editieren.]
Kannst Du mal die zu patchende Datei anhängen?

[Beitrag 2:]
EDIT: also am besten libtr069.so und ctlmgr von KD- und Zielbox
 
Dringender Hinweis: AVM Firmware steht unter die Copyright! Die Weitergabe ist illegal, auch von Teilen der Firmware. Bitte beachtet das bei eurer weiteren Vorgehensweise.
 
Hi,

auch hier nochmal, Entschuldigung...

Grüße

StefanV3
 
Das editieren funktioniert bei mir nicht.
 
Hallo,

wird dieses Thema noch bearbeitet?

Würde gerne wissen wo genau die CWMP Accountnummer hinterlegt ist.

Habe eine Fritz7390 mit CWMP, wo ich gerne die Nummer aus meiner alten Homebox eintrage würde.

Viele Grüße
 
Das Thema wurde nie richtig und wird nun gar nicht mehr bearbeitet. Der CWMP Account ist im Bootloader hinterlegt.
 
Hi,

also, ich wär ja dafür, das Thema nochmal auf zu rollen. Habe jetzt erst wieder die HomeBox 7270 wieder in Betrieb genommen, weil KDG bei meine Telefonie-Accounts auf einen anderen Server gelegt hat und damit auch ein Passwortwechsel einher ging.

Da wär ich doch nochmal interessiert...

Grüße

StefanV3
 
Habe gerade mal versucht via RUkernel dir tr069.cfg anzupassen, jedoch sind die Änderungen, nach laden der Werkseinstellung, wieder original.

Wie kann mann das dauerhaft ändern, da ein Laden der Daten von KD, erst nach einem Werksreset angeschubst wird.

Grüße
 
Es steht hier in diesem Thread schon mehrfach geschrieben, dass das CWMP Account dem Bootloader entnommen wird. :( D.h. Werkseinstellungen laden ist gar nicht notwendig, ein Restart reicht aus.
 
Zuletzt bearbeitet:
Es sollte doch mit einem Serial Interface möglich sein, die Werte zu verändern? Dann muss man doch nichts mehr patchen...?

Ein paar nützliche Infos zum Thema:

http://www.wehavemorefun.de/fritzbox/Tr069.cfg
http://www.wehavemorefun.de/fritzbox/Bootloader
http://www.wehavemorefun.de/fritzbox/ADAM2_Shell
http://www.wehavemorefun.de/fritzbox/Serielle_Konsole

Hat jemand in die Richtung mal geforscht?

Theoretisch stelle ich mir zwei Möglichkeiten vor:
1. man exportiert den Bootloader von der Zielbox (mit cat mtdxxx), ändert darin die Werte mit einem Hex-Editor (Expertenwissen vorausgesetzt) und spielt ihn dann wieder zurück - ACHTUNG: soweit ich gelesen habe kann man nicht den Bootloader von einer anderen Box rüber kopieren, da dort zu viele Hardware spezifische Werte vorhanden sind - und generell ist es gefährlich wenn man nicht weis was man da tut -> BRICK
oder
2. man benutzt die EVA/ADAM Shell über Serial und füttert darüber die Werte per Befehle in den Speicher (dies wäre wohl die sicherste Variante - WENN ÜBERHAUPT MÖGLICH)

dazu gehört für mich die MAC Adresse und die CWMP Daten - im System dann muss wohl nur noch die Tr069.cfg inkl. der umgebenen Daten (Zert) ersetzt werden.
 
Zuletzt bearbeitet:
2. man benutzt die EVA/ADAM Shell über Serial und füttert darüber die Werte per Befehle in den Speicher (dies wäre wohl die sicherste Variante - WENN ÜBERHAUPT MÖGLICH)
Wozu ein Serial Interface, wenn man doch auch so beim Booten in das Command Interface kommt, um den CWMP Account im Environment zu ändern oder hinzuzufügen?
 
Kommt man? Wenn ja ist es ja noch einfacher?
 
Bootloader mtd2 patchen ... Ich verzweifle ...

Hallö :)
Ich weiß, das ist schon wieder sooooo alt...
Aber irgendwie komme ich nicht weiter...
Ich möchte den Bootloader von 2 Boxen patchen (warum, sei mal egal *g*)
Box A soll alle Relevanten Daten von Box B und umgekehrt erhalten.
Relevante Daten sind z.B. die mac´s, tr069* und wlan_key.
wlan_key ist soweit kein Problem (sowohl per ADAM2 als auch per Telnet)
Die anderen Daten sind aber durchaus ein Problem weil sie bei jedem Reboot zurück gesetzt werden.

Folgendes habe ich probiert:
--- export dummy=ABCD.EFG.HI.JKL.MNO
cp /dev/mtdblock3 /var/tmp/$dummy-mtd2.bin
cat /proc/sys/urlader/environment > /var/tmp/$dummy-mtd2.txt
cd /var/tmp
tftp -p -l $dummy-mtd2.bin 192.168.178.4 && rm /var/tmp/$dummy-mtd2.bin
tftp -p -l $dummy-mtd2.txt 192.168.178.4 && rm /var/tmp/$dummy-mtd2.txt
---
Damit ziehe ich mir ein Backup des mtd2 (mtdblock3) als ABCD.EFG.HI.JKL.MNO-mtd2.bin und den Inhalt (weil besser lesbar) vom environment als ABCD.EFG.HI.JKL.MNO-mtd2.txt per tftp auf meinen PC (192.168.178.4)
Soweit alles supi.
Ich ändere per Hex-Editor alle Relevanten Daten in dee ABCD.EFG.HI.JKL.MNO-mtd2.bin

So packe ich den "gepatchten" Bootloader zurück auf die Box:
--- export dummy=ABCD.EFG.HI.JKL.MNO
cd /var/tmp
tftp -g -r $dummy-mtd2.bin 192.168.178.4 && cat /var/tmp/$dummy-mtd2.bin > /dev/mtdblock3 && rm /var/tmp/$dummy-mtd2.bin
---
Es kommt auch keine Fehlermeldung und die /dev/mtdblock3 wird geändert.
Nach einem Reboot ist aber wieder alles beim alten :(
Habe mit mehreren Fritz!Box 7390 getestet.
Sowohl mit FW 84.05.54 als auch 84.06.23.

Hat jemand einen Tip für mich?
 
Zuletzt bearbeitet:
Aber irgendwie komme ich nicht weiter...
Wenn man den Rest des Geschriebenen so liest, kann man da tatsächlich nur sagen: zum Glück.

Ich weiß ja nicht, wo Du Deine Informationen beziehst, aber da stimmt fast nichts.

Das fängt schon damit an, daß Du den falschen Baum (sprich die falsche Partition) anbellst.

MTD3 ist gar nicht der Bootloader ... wie kommst Du auf dieses schmale Brett? Woher nimmst Du die Idee (bei der 7390), daß mtdblock3 das Äquivalent zu mtd2 wäre? Schon ein ganz simpler Test (inkl. Gegenprobe) zeigt, daß das nicht stimmen kann:

Code:
# cat /dev/mtd2 >/var/mtdchar2;cat /dev/mtdblock2 >/var/mtdblock2;cmp /var/mtdchar2 /var/mtdblock2
# cat /dev/mtd2 >/var/mtdchar2;cat /dev/mtdblock3 >/var/mtdblock3;cmp /var/mtdchar2 /var/mtdblock3
/var/mtdchar2 /var/mtdblock3 differ: char 1, line 1

Und was soll:

[...] und den Inhalt (weil besser lesbar) vom environment [...]
eigentlich heißen? Das ist eine Pseudodatei (die gibt es also nicht wirklich), was sollte man da ansonsten finden/kopieren/anzeigen können als den Inhalt, der ja extra beim Zugriff auf diese "Datei" erzeugt wird, damit man ihn lesen kann?

Die Partition MTD3, die Du da liest und wieder überschreibst, wird für das Speichern von Einstellungen verwendet. Dorthin schreiben alle char-Devices mit Major-ID 250. Das TFFS verwendet alternierend die Partitionen MTD3 und MTD4 und im Prinzip hast Du bisher nur verdammtes Glück gehabt, wenn Du Dir die Einstellungen der Box dabei nicht zerschossen hast (was durch Recovery aber sicherlich wieder zu lösen ist, solange es Dir nicht gelingt, MTD2 auch noch zu überschreiben).

Code:
# cat /proc/devices | grep tffs
250 tffs
# cat /proc/tffs
TFFS
mount=mtd3
mount=mtd4
request=1
mode: read/write: shared
thread state=process
# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00d8e000 00020000 "rootfs"
mtd1: 00152000 00020000 "kernel"
mtd2: 00020000 00020000 "urlader"
mtd3: 00080000 00020000 "tffs (1)"
mtd4: 00080000 00020000 "tffs (2)"
mtd5: 01000000 00020000 "reserved"
mtd6: 20000000 00020000 "nand-filesystem"

Hat jemand einen Tip für mich?
Hätte ich schon, wirst Du aber sicherlich nicht hören wollen: Lass es besser sein oder mach' Dich vorher wirklich schlau, was Du da eigentlich machst.

Wer unreflektiert irgendwelche veralteten Erkenntnisse auf eine aktuelle Firmware anwendet, der riskiert eine funktionsunfähige FRITZ!Box ... erst recht dann, wenn er ohne Sinn und Verstand (sorry, aber genau so sehe ich das) am Bootloader herumspielen will.

Das Allermindeste, was man in so einem Fall macht, ist das Überprüfen fremder Feststellungen, noch dazu dann, wenn sie definitiv schon älter sind und eigentlch auf ein anderes Modell bezogen waren (ich vermute mal, Du hast diese "Weisheit" irgendwo aus WHMF und da wird sicherlich eher nicht gestanden haben, das wäre bei der 7390 ebenfalls so).

Wenn Du Deine Box tatsächlich killen willst, ist ein Kommando wie "cat /dev/zero >/dev/mtd2" (/dev/zero kannst Du durch beliebige andere Quellen ersetzen, die nicht sofort "EOF" melden) die einfachere Lösung (wobei ich nicht getestet habe, ob /dev/mtd2 tatsächlich schreibende Zugriffe ausführt).

Um Angaben im Urlader-Environment zu ändern (und dazu zählen tatsächlich alle von Dir aufgezählten Werte), braucht kein Mensch irgendeine Partition zu überschreiben, wie Dir ein einfacher Blick in die TFFS-Quelltexte schon verraten hätte (auch das gehört zum systematischen Vorgehen, daß man sich die richtigen Informationen besorgt).

Wenn man diese Daten allerdings aus einem laufenden System heraus ändert, muß man zwingend hinterher ein FactoryReset ausführen (und das meint vor dem nächsten Start), weil die Box ihre eigenen gespeicherten Einstellungen nicht mehr dekodieren kann und man mit Standardeinstellung von Null starten muß. Dabei werden dann auch tatsächlich Änderungen an MTD3/MTD4 ausgeführt.
 
Hallo,

deiner Antwort entnehme ich, dass du auf dem Gebiet wahrscheinlich schon länger und intensiver unterwegs bist.
Vielleicht habe ich mich an der ein oder anderen Stelle misverständlich oder gar falsch ausgedrückt.
Fakt ist:
Ich habe zu diesem Thema "viel" gelesen und probiert. Ich habe in diversen Quellen immer wieder Aussagen gefunden, die mir das folgende vermittelt haben:
- Der CWMP-Account ist "verbunden" (sorry, weiss gerade nicht, wie ich das sonst fachmännisch korrekt ausdrücken soll. aber ich denke du weisst, was ich meine) mit den tr069_passphrase/serial settings.
- die tr069_serial besteht aus 00040E-{maca}
- die mac-Adressen und tr069-settings sind im bootloader definiert
- der bootloader ist /dev/mtd2 (Chraracter Device) bzw. /dev/mtdblock3 (Block Device)
- zum dauerhaften (dass es auch ein Recovery "übersteht") ändern der mac* und tr069* muss der Bootloader (Urlader/mtd2/mtdblock3) gepatcht werden

Zur Environment-Datei: Ja, ich weiß, das dies eine Pseudo-Datei ist. Wenn ich aber ein cat /proc/sys/urlader/environment mache, bekomme ich im Klartext alle (Environment-)Einstellungen der Box angezeigt und kann diese in eine .txt "exportieren" damit ich sie am PC lesen kann.
Bzgl. mtdblock3 "Datei": aus dem was ich gelesen habe und was ich an ca. 15 Boxen getestet habe, stehen immer alle Einstellungen des Urladers in dieser Datei.

Bisher habe ich noch keine einzige Box geschrottet. Und selbst wenn das passieren sollte, dann bin ich mir bewusst, das ICH das zu verantworten habe.
Aber ohne etwas zu probieren und eventuell dabei einen Fehlschlag zu erleiden kann ich nur schwer dazu lernen.

Bevor wir jetzt hin und her schreiben, kannst du mir ja gerne sagen, wie ich das gewünschte erreichen kann... Gerne nehme ich defekte Geräte in Kauf...
Du kannst mir auch gerne per PN schreiben, wenn du nicht möchtest, das es öffentlich ist...
 
sockd schrieb:
Der CWMP-Account ist "verbunden" (sorry, weiss gerade nicht, wie ich das sonst fachmännisch korrekt ausdrücken soll. aber ich denke du weisst, was ich meine) mit den tr069_passphrase/serial settings.
Stimmt. Das "CPE WAN Management Protocol" ist Gegenstand des "Technical Reports 069" (TR-069) und die FRITZ!Box verwendet als Identifikation (CWMP-Account) die Angaben aus dem Urlader-Environment (soweit vorhanden, das ist nur bei ausgewählten Boxen der Fall).

- die mac-Adressen und tr069-settings sind im bootloader definiert
Stimmt.

- der bootloader ist /dev/mtd2 (Chraracter Device)
Stimmt.

bzw. /dev/mtdblock3 (Block Device)
Stimmt nicht. Quelle?

Das "cmp"-Kommando in meinem Beitrag sollte schon aufgezeigt haben, daß bei der 7390 /dev/mtd2 und /dev/mtdblock2 identisch sind (und eben nicht /dev/mtd2 und /dev/mtdblock3) - die Unterscheidung in Block- und Character-Device hast Du ja schon richtig getroffen.

- zum dauerhaften (dass es auch ein Recovery "übersteht") ändern der mac* und tr069* muss der Bootloader (Urlader/mtd2/mtdblock3) gepatcht werden
Stimmt nicht, jedenfalls nicht, wenn Du mtdblock3 verwenden willst.

Ändern der Werte im Urlader-Environment sollte ausreichend sein, anschließend die beiden TFFS-Partitionen richtig löschen. Das ist zwar etwas "dirty", aber wenn die ungültig sind beim Start des Systems (wie es auch beim Löschen z.B. mit dem ruKT der Fall ist), dann werden die Partitionen mit den Angaben aus dem Urlader-Environment neu initialisiert (da steht dann Deine Änderung ja schon drin). Anschließend sollte man ruhig noch einmal ein "FactoryReset" machen, damit das "späte Initialisieren" des TFFS bei fehlerhaftem Inhalt nicht zu merkwürdigem Verhalten führt.

Ob man das "Leeren" von MTD3/MTD4 aus dem laufenden System oder aus dem ruKT heraus macht (da könnte man dann auch gleich die Urlader-Änderungen machen - es geht natürlich auch alles per EVA zu Fuß, wenn man will), hängt davon ab, was man sich selbst zutraut. Es bringt natürlich wenig, wenn nach dem Löschen noch weitere Schreibzugriffe aus dem laufenden System ins TFFS erfolgen und das Löschen wieder hinfällig machen.

Bzgl. mtdblock3 "Datei": aus dem was ich gelesen habe und was ich an ca. 15 Boxen getestet habe, stehen immer alle Einstellungen des Urladers in dieser Datei.
Ja, als "Duplikat" ... genau so stehen sie auch noch einmal in MTD4 und (an anderem Offset) in MTD2. Kannst Du leicht selbst überprüfen ... und das ist es eben, was ich mit "systematisch" meinte. Es ist zwar schön, wenn so eine "Nachschau" in mtdblock3 (also MTD3 bei der 7390) die eigenen Erwartungen bestätigt ... wenn aber die Eingangsannahmen schon falsch sind (in Deinem Falle eben der Zusammenhang zwischen Character- und Block-Device, den Du mit dem von mir gezeigten cmp-Kommando problemlos hättest validieren können), kann auch das Ergebnis nicht wirklich richtig sein. Die Ergebnisse erwecken den Anschein, als würde Deine Annahme stimmen ... am Ende bestätigst Du Dir aber bloß Deine "Vorurteile", wenn Du auf doppelte Überprüfungen (also positive und negative Tests) verzichtest.

Bisher habe ich noch keine einzige Box geschrottet. Und selbst wenn das passieren sollte, dann bin ich mir bewusst, das ICH das zu verantworten habe.
Aber ohne etwas zu probieren und eventuell dabei einen Fehlschlag zu erleiden kann ich nur schwer dazu lernen.
Das wollte ich damit auch nicht zum Ausdruck bringen ... ich wollte Dich nur darauf aufmerksam machen, daß lange nicht jede Quelle auch (aktuell noch) richtig sein muß und man solche Erkenntnisse eben immer selbst überprüfen muß ... ansonsten kann man sehr schnell Schiffbruch erleiden und wenn man die Warnungen bzgl. des Urladers (erst recht in Bezug auf das Bearbeiten mit einem Hex-Editor) nicht ernst zu nehmen scheint und gleichzeitig solchen "Blödsinn" schreibt (nicht persönlich nehmen, aber ich will verhindern, daß der nächste Leser das von Dir oben Geschriebene auch unreflektiert übernimmt), dann darf man sich auch nicht wundern, wenn einen andere (die das nicht "böse" meinen, aber bei vielen hilft nur sehr rüdes Auftreten, um sie entsprechend wachzurütteln) darauf hinweisen, man solle doch etwas systematischer vorgehen.

Bevor wir jetzt hin und her schreiben, kannst du mir ja gerne sagen, wie ich das gewünschte erreichen kann... Gerne nehme ich defekte Geräte in Kauf...
Du kannst mir auch gerne per PN schreiben, wenn du nicht möchtest, das es öffentlich ist...
Ich hoffe, ich habe das hiermit getan und gleichzeitig erläutert, warum das Löschen von MTD3/MTD4 erforderlich ist, wenn man im Urlader Änderungen vornimmt. Am besten macht man das wirklich aus EVA heraus (notfalls läßt man sich vom ruKT dahin bringen), dann kann das geladene FRITZ!OS da nicht dazwischen gehen. Anschließend "clear MTD3/MTD4" (wenn man nicht weiß, wie man das von Hand machen soll) und dann die Box neu starten. Solange man nicht wirklich am Bootloader herumbastelt, sollte die Box problemlos starten und - nach dem neuerlichen Werksreset, den man ruhig gleich am Beginn der Einrichtung noch einmal ausführen sollte - dann mit den richtigen Einstellungen im Urlader-Environment auch arbeiten.

Wenn das so nicht funktionieren würde (also das "Restaurieren" des TFFS mit den Angaben aus MTD2), wäre schon so manche Box den Heldentod gestorben, denn das ruKT löscht eben MTD3/MTD4 auch nur durch das Überschreiben des (vorher vom Bootloader gelöschten) Flash-Speichers mit einer 0 Byte langen Datei. Vielleicht sicherst Du Dir trotzdem mal die relevanten Partitionen (in erster Linie eben /dev/mtd2) und schaust bei der Gelegenheit auch gleich noch einmal mit dem Hex-Viewer in die Inhalte von MTD2 bis MTD4 - parallel mit dem Quellen des TFFS -, um das tatsächlich zu verstehen, wie das funktioniert.

Und das ist auch kein Problem, wenn das "öffentlich" ist ... es sind altbekannte Vorgehensweisen und das "Clonen" von CWMP-Accounts ist ohnehin nur zwischen Geräten desselben Modells halbwegs sinnvoll ... ein TR-069-INFORM-Request enthält ja nicht nur die MAC-Adresse, sondern auch noch die Modellangabe. Aus einer 7270v2 eine 7390 zu machen, klappt also ohnehin nur, wenn der ACS ein wenig dämlich ist. Außerdem fliegst Du hoffentlich bei jedem Provider mit dem parallelen Betrieb solcher Geräte ohnehin aus dem Netz ... außer vielleicht bei Kabelbetreibern, die sich immer noch darauf verlassen, daß schon niemand in die DOCSIS-Boxen kommt. Wenn die ihr Netz nicht im Griff haben (und die gleichzeitige Anmeldung desselben Gerätes für zwei verschiedene öffentliche IP-Adressen nicht sauber feststellen können), dann wird es ohnehin höchste Zeit, daß sich da etwas tut, bevor das Gesetz verabschiedet wird und in Kraft tritt. Ich glaube aber ohnehin nicht, daß der amerikanische Sport des Clonens in D irgendwelche Perspektiven haben wird. Und wenn jemand an zwei alternativen Standorten dieselbe Box betreiben will (solange das nicht gleichzeitig ist), sehe ich keinen großen Unterschied, ob das zwei verschiedene Geräte sind oder ob eine einzelne Box immer hin und her geschleppt wird.
 
Die Bootlader-bezogene "mtd2-mtd3-Verwirrung" kommt vermutlich aus der Historie.
Bei den älteren Boxen war tatsächlich der Bootlader "mtd2", so wie er auch im "Urlader" steht, im laufenden Betrieb als mtd3 ansprechbar...
So sieht das z.B. auf einer "alten" FB bzw. Eumex 300IP aus:

Code:
root@eumex:/var/mod/root# cat /proc/sys/urlader/environment | grep mtd
mtd0	0x90000000,0x90000000
mtd1	0x90010000,0x903C0000
[B]mtd2	0x90000000,0x90010000[/B]
mtd3	0x903C0000,0x903E0000
mtd4	0x903E0000,0x90400000
mtd5	0x90000000,0x90010000
root@eumex:/var/mod/root# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00400000 00010000 "phys_mapped_flash"
mtd1: 0030c100 00010000 "filesystem"
mtd2: 003b0000 00010000 "kernel"
[B]mtd3: 00010000 00010000 "bootloader"[/B]
mtd4: 00020000 00010000 "tffs (1)"
mtd5: 00020000 00010000 "tffs (2)"
mtd6: 00040000 00010000 "jffs2"
mtd7: 00370000 00010000 "Kernel without jffs2"
root@eumex:/var/mod/root# cat /proc/partitions 
major minor  #blocks  name

  31     0       4096 mtdblock0
  31     1       3120 mtdblock1
  31     2       3776 mtdblock2
 [B] 31     3         64 mtdblock3[/B]
  31     4        128 mtdblock4
  31     5        128 mtdblock5
  31     6        256 mtdblock6
  31     7       3520 mtdblock7
root@eumex:/var/mod/root#

Ich meine, bei der 7170 war es noch ebenso, bei (bzw. "ab") der 7270 waren die m.W. schon "identisch"

Code:
root@fritz:/var/mod/root# cat /proc/sys/urlader/environment | grep mtd
mtd0	0x90000000,0x90000000
mtd1	0x90020000,0x90F80000
[B]mtd2	0x90000000,0x90020000[/B]
mtd3	0x90F80000,0x90FC0000
mtd4	0x90FC0000,0x91000000
root@fritz:/var/mod/root# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00e3fe00 00020000 "rootfs"
mtd1: 00120200 00020000 "kernel"
[B]mtd2: 00020000 00020000 "urlader"[/B]
mtd3: 00040000 00020000 "tffs (1)"
mtd4: 00040000 00020000 "tffs (2)"
mtd5: 000e0000 00020000 "jffs2"
root@fritz:/var/mod/root# cat /proc/partitions 
major minor  #blocks  name

  31        0      14591 mtdblock0
  31        1       1152 mtdblock1
  [B]31        2        128 mtdblock2[/B]
  31        3        256 mtdblock3
  31        4        256 mtdblock4
  31        5        896 mtdblock5
   7        0        284 loop0
 254        0       8192 ramzswap0
root@fritz:/var/mod/root#

Sieht man z.B. auch hier auf wehavemorefun, bei der 7390 ist wie bei der 7270 "mtd2 immer mtd2".
 
@MaxMuster:
Der Fragesteller hat ja auch die Informationen ziemlich durcheinander gewürfelt bzw. veraltete Informationen auf die 7390 angewendet und durch unvollständige Tests (natürlich stehen die Urlader-Environment-Daten auch noch mal in MTD3, ja sogar in MTD4) auch seine Erwartungen bestätigt gesehen. Ich wollte eigentlich nur vermeiden, daß er sich tatsächlich den Bootloader zerschießt bzw. an dem mit einem Hex-Editor herumdoktert, wenn das weder notwendig noch zielführend ist. Spätestens bei einer NAND-Box stimmt das dann ohnehin alles nur noch sehr bedingt, weil dann nicht mal mehr MTD3/MTD4 im laufenden System genauso gemappt sind, wie in der EVA.

Im Freetz-Wiki findet sich auch eindeutig die Aussage, daß dieser "off by one"-Unterschied ab 7270v3 spätestestens nicht mehr existiert (Kommentar von kriegaex vom 06.01.2012), ergo auch bei der in Frage stehenden 7390 nicht - deshalb hatte ich auch explizit geschriebenm, daß

myself schrieb:
bei der 7390 /dev/mtd2 und /dev/mtdblock2 identisch sind (und eben nicht /dev/mtd2 und /dev/mtdblock3)

und das ja auch mit dem cmp-Beispiel belegt. Klar steht auch im Freetz-Wiki etwas von "mtdblock3", aber eindeutig als Beispiel gekennzeichnet und mit dem Hinweis, den korrekten Wert aus /proc/mtd auszulesen.

Inzwischen gab es auch noch drei PMs zwischen sockd und mir zu dem Thema, warum das nicht im Forum weiter behandelt wurde, weiß ich auch nicht ... nach der dritten habe ich dann auf Fortsetzung hier (wenn es überhaupt eine geben sollte) bestanden.

Ob das nun funktioniert hat, kann ich nicht sagen ... der letzte Stand ist, daß nach Recovery seine Einstellungen wieder "original" waren. Wie das geht, verstehe ich allerdings nicht, denn mein Vorschlag war "Löschen von MTD3/MTD4" (überschreiben mit NULL-File analog ruKT, damit bei Start des TFFS-Treibers aus MTD2 die Urladerangaben übernommen werden in MTD3/MTD4) und "SETENV"-Kommandos für die drei fraglichen Urlader-Werte ... hat bei mir eigentlich immer bisher einwandfrei funktioniert, wenn ich mit "maca" und "wlan_key" für die AVM-Verschlüsselung experimentiert habe, um eine "fremde" Box zu simulieren (die CWMP-Account-Werte waren nicht mein Thema, das Prinzip bleibt ja aber dasselbe).
 
@PeterPawn,

I am trying to change the macdsl-adres of mij 7360 permanently and came across your post. I managed to clear the mtd3 and mtd4 using ruKT, then set the macdsl using ADAM2, what should I do next to permanently save the macdsl in the usersetting?
 

Neueste Beiträge

Statistik des Forums

Themen
244,858
Beiträge
2,219,651
Mitglieder
371,572
Neuestes Mitglied
#Kuddel#
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.