[Problem] o2 Neuanschluss & AVM 7490 - kein Telefon

dexter.nrw

Neuer User
Mitglied seit
6 Jan 2016
Beiträge
8
Punkte für Reaktionen
0
Punkte
0
Hallo zusammen
ich habe seit heute einen Neuanschluss von o2

Ich habe hier noch eine unbrandet AVM 7490 Fritzbox mit aktuellstem Fritz!OS
ich habe meine Zugangsdaten eingetragen und mich auch an folgenden Topic gehalten:
http://www.ip-phone-forum.de/showthread.php?t=275469

aber bei mir kommen die Telefonnummern NICHT

Die Schaltung von meinem Anschluss war heute Vormittag um 9Uhr
Wo liegt der Fehler?
Habe die Fritzbox auch schon 2x auf Werkseinstellungen zurück gesetzt & Daten neu eingegeben, doch das hat mir leider auch nicht geholfen.
DSL hingegen funktioniert problemlos.
Bitte um Hilfe
 
Da fehlt wohl der ACS in der FRITZ!Box ... der kommt ja auch nicht mit den Zugangsdaten. Bei den Boxen mit der "provider additive"-Konfiguration von O2 ist das vermutlich genau die Einstellung, die von dieser Zusatzkonfiguration gesetzt wird. Bleibt also nur das Ermitteln der korrekten URL und der sonstigen notwendigen TR-069-Einstellungen, damit die Box sich überhaupt beim Provider meldet und dort die SIP-Accounts abholt.

Theoretisch könnten das auch die Einstellungen in der providers-049.tar in der Firmware übernehmen ... solange wir keine Ahnung haben, was Du da überhaupt eingestellt hast, kann aber niemand nachsehen, was da gesetzt wird. Also bleibt Dir wohl nur der eigene Blick in das Export-File und die Überprüfung der dort eingetragenen Daten. O2 wird (vermutlich) auf der Basis der IP-Adresse die Daten ausliefern, ansonsten müßte man Dir dort (bei "kundeneigenem Router") entweder die SIP-Credentials oder die notwendigen Daten für das Abrufen per TR-069 mitteilen - wenn da kundeneigene Router überhaupt (schon) unterstützt werden.

Ansonsten kann Dir nur jemand mit einer O2-FRITZ!Box (einer 7490 auch noch) und intakter provider-additive.tar helfen - die Daten werden wohl kaum kundenspezifisch sein, dann könnte man diese Boxen auch gleich komplett konfiguriert ausliefern, wenn der Prozess ohnehin für jeden Kunden andere Daten schreiben würde. Auch in der tr069.cfg steht natürlich bei anderen O2-Kunden die notwendige Information, aber zumindest die Credentials sind dort verschlüsselt, selbst wenn das "universelle Daten" sein sollten oder sogar leere Zeichenketten - die darf man natürlich nicht in der verschlüsselten Form übernehmen.
 
Da fehlt wohl der ACS in der FRITZ!Box ... der kommt ja auch nicht mit den Zugangsdaten. Bei den Boxen mit der "provider additive"-Konfiguration von O2 ist das vermutlich genau die Einstellung, die von dieser Zusatzkonfiguration gesetzt wird. Bleibt also nur das Ermitteln der korrekten URL und der sonstigen notwendigen TR-069-Einstellungen, damit die Box sich überhaupt beim Provider meldet und dort die SIP-Accounts abholt.

Wie soll ich denn an die TR-069 Daten kommen? bzw an die URL?
Laut dem Verlinkten Topic von mir in Post1 soll das ja so funktionieren


Theoretisch könnten das auch die Einstellungen in der providers-049.tar in der Firmware übernehmen ... solange wir keine Ahnung haben, was Du da überhaupt eingestellt hast, kann aber niemand nachsehen, was da gesetzt wird. Also bleibt Dir wohl nur der eigene Blick in das Export-File und die Überprüfung der dort eingetragenen Daten.

Meinst du was ich bei der Einrichtung der FB eingetragen habe? "O2 DSL" habe ich ausgewählt und da drunter meinen Zugangsdaten eingetragen
 
In dem von Dir verlinkten Beitrag (> 1 Jahr alt) geht das bei der Vertreibung aus dem Paradies los (mit Firmware 06.05) ... insofern bezweifele ich schon mal, daß Du Dich tatsächlich wie hier in #1 behauptet, an den dort beschriebenen Ablauf gehalten hast und bei Deiner FRITZ!Box erst einmal mit Version 06.05 begonnen hast. [EDIT] Schon die Frage, woher Du diese Version dann hattest (den "Suche"-Thread hier kannst Du bei Deinem "Alter" kaum genutzt haben), wäre dann zu klären. OK, die hat AVM tatsächlich noch auf einem Server herumstehen, das vereinfacht es ... dann bleibt die Frage, was da als ACS eingetragen ist (man müßte dann für die Kenntnis, was dort durch "O2 DSL" hinterlegt wurde, auch in dieser Version nachsehen). Bleibt die Frage, ob denn die Box von O2 mit der Firmware 06.05 überhaupt über TR-069 konfiguriert wurde oder nicht ... das gibt ja eine entsprechende Nachricht im Eventlog. [/EDIT]

Wie Dir bei der ausführlichen Lektüre sicherlich nicht entgangen ist, wird dort eben die TR-069-Verbindung noch mit der alten Version 06.05 (Punkt 3 der Anleitung) hergestellt.

Also wäre es schön, wenn Du den tatsächlichen Ablauf bei Dir selbst (wahrheitsgemäß) beschreiben könntest und nicht erwartest, daß sich jetzt jeder, der Dir helfen will, da selbst durch den anderen Thread arbeitet (und das mit höchster Wahrscheinlichkeit eben auch noch umsonst, weil Du Dich eben (ich bin mir nahezu sicher) gar nicht an den dort dargestellten Ablauf halten konntest). Das nehme ich zurück, Du hättest es tatsächlich tun können.

Also schön der Reihe nach ... und wenn Du Glück hast, findet sich ja noch jemand mit einer O2-Box, der für Dich in der TR-069 nachsieht.

Ansonsten hast Du es ja noch nicht einmal geschafft, die von Dir tatsächlich verwendete FRITZ!OS-Version irgendwo mal zu vermerken, damit weiß man nicht einmal, in welcher Firmware-Version man jetzt nachsehen muß, um die in der providers-049.tar enthaltenen Einstellungen für "O2 DSL" auszulesen.

Das könnte man zwar vermutlich auch für die beiden "aktuellsten" Versionen (06.30 und 06.50) machen (spätestens in einem weiteren Jahr weiß kein Mensch mehr, was heute die "aktuellste" Firmware war), aber warum sollte man das tun?

Es kann nicht so schwer sein, korrekte Angaben zu machen oder sich selbst die betreffende Firmware bei AVM zu besorgen, sie auszupacken, die darin enthaltene providers-049.tar zu suchen und dann die dort in der tr069.cfg hinterlegten Angaben zum TR-069 mit denen aus den eigenen Einstellungen (stehen in jeder Sicherungsdatei der Einstellungen) zu vergleichen.

Nun kannst Du Dir ja überlegen, welcher der beiden Wege für Dich der einfachere wäre, den Vergleich mit den eigenen Einstellungen müßtest Du allerdings immer noch selbst machen, selbst wenn jemand anderes für Dich in die providers-049.tar schaut.

Ansonsten müßte Dir die O2-Hotline die URL des korrekten ACS sicherlich auch geben können (inkl. der Info, ob eine Anmeldung überhaupt benötigt wird, die Identifikation könnte ja auch über die IP-Adresse laufen, wie schon mal angemerkt) - wenn die dort wissen, daß Du eine eigene FRITZ!Box verwenden willst, sollten sie das auch tun.

EDIT: Um nach meinem eigenen Irrtum noch guten Willen zu beweisen, hier die tr069.cfg aus dem Provider "o2 DSL" (name=otwored) in der 113.06.05:
Code:
tr069cfg {
        enabled = yes;
        igd {
            DeviceInfo {
                    ProvisioningCode = "";
            }
        managementserver {
                        url = "https://acs.o2online.de/nbbs/tr69";
                        username = "00040E-000000000000";
                        password = "o2acs";
                        URLAlreadyContacted = no;
                        PeriodicInformEnable = yes;
                        PeriodicInformInterval = 3600;
        }
    }
        FirmwareDownload {
        enabled = yes;
        enabled_converted = yes;
        }
        ACS_SSL {
                verify_server = yes;
                trusted_ca_file = "/etc/default/avm/root_ca.pem";
        }
        Download_SSL {
                verify_server = yes;
                trusted_ca_file = "/etc/default/avm/root_ca.pem";
        }
}
In der 06.50 sieht die Datei nicht anders aus ... bleibt also die Frage, was da im TR-069-Dialog passiert bzw. ob das überhaupt eingeschaltet ist.
 
Zuletzt bearbeitet:
danke für deine Antwort
ich hab/hatte mehrere FW Versionen durch und stehe momentan wieder auf 6.05
tr-069 ist im FB Interface aktiviert (anbieterdienste zulassen)

meine tr-069 sieht etwas anders/ausführlicher aus
da auch nutzer und PW bei mir verschlüsselt aussehen, werde ich diese etwas via * zensieren

/*
* /var/flash/tr069.cfg
* Fri Jan 8 13:56:12 2016
*/

meta { encoding = "utf-8"; }

tr069cfg {
enabled = yes;
litemode = no;
tr181_support = no;
igd {
DeviceInfo {
ProvisioningCode = "";
FirstUseDate = "2016-01-08 13:56:12";
}
managementserver {
url = "https://acs.o2online.de/nbbs/tr69";
username = "$$$$FLF*************************************************************************WT";
password = "$$$$OW2************************************************************************WT";
URLAlreadyContacted = yes;
LastInformReq = "2016-01-08 13:56:12";
LastSuccessfulContact = "2016-01-08 13:56:12";
URLbyDHCPIface = "";
PeriodicInformEnable = yes;
PeriodicInformInterval = 3600;
PeriodicInformTime = "1970-01-01 01:00:00";
UpgradesManaged = no;
ACSInitiationEnable = yes;
SessionTerminationWithEmptyPost = no;
ConnectionRequestUsername = "";
ConnectionRequestPassword = "";
dnsprefer = tr069dnsprefer_ipv4;
}
}
FirmwareDownload {
enabled = yes;
enabled_converted = yes;
upload_enabled = no;
valid = no;
suppress_notify = no;
status = 0;
StartTime = "1970-01-01 01:00:00";
CompleteTime = "1970-01-01 01:00:00";
method = Download_Method_DL;
}
RebootRequest = no;
RebootRequest_CommandKey = "";
ACS_SSL {
verify_server = yes;
trusted_ca_file = "/etc/default/avm/root_ca.pem";
}
Download_SSL {
verify_server = yes;
trusted_ca_file = "/etc/default/avm/root_ca.pem";
}
guimode = guimode_visible;
}


// EOF

ausgabe von oben via ruKernelTool erlangt
 
Zuletzt bearbeitet:
Ich denke mal, die FRITZ!Box nimmt keinen Kontakt zum ACS auf bzw. fragt da nicht nach den Konfigurationsdaten (denn Kontakt nimmt sie wohl schon auf, wenn man den Angaben in der tr069.cfg traut). Dekodiert müßte in den Feldern für Benutzernamen und Kennwort eben genau dasselbe stehen, was in der Provider-Konfiguration in der providers-049.tar steht, sonst wurde das bereits beim ersten Kontakt zum ACS neu gesetzt (das geht auch, keine Ahnung, ob o2 das so macht).

Eventuell hilft es auch hier, einfach mal einen Mechanismus zu mißbruachen, der mal für KDG eingebaut wurde (und normalerweise nur auf deren FRITZ!Boxen sichtbar ist). Dazu braucht man eine Shell auf der Box und dort gibt man dann
Code:
ctlmgr_ctl w tr069 settings/tr069resetcfg 1
ein.

Danach sollte das CPE die TR-069-Konfiguration neu initialisieren (u.a. auch "FirstUseDate" wieder löschen, wenn ich mich richtig erinnere) und erneut die Kontaktaufnahme mit dem ACS versuchen.

Zumindest erhält man dann im Dateisystem unterhalb von /var auch eine Datei, in der die bis dahin aufgelaufene Kommunikation mit dem ACS protokolliert wird.

Die kann man dann entweder zu Fuß mit "showshringbuf tr069" auslesen oder man fischt die Ausgabe aus den Support-Daten heraus.
 
Code:
/*
 * /var/flash/tr069.cfg
 * Fri Jan  8 16:52:05 2016
 */

meta { encoding = "utf-8"; }

tr069cfg {
        enabled = yes;
        litemode = no;
        tr181_support = no;
        igd {
                DeviceInfo {
                        ProvisioningCode = "";
                        FirstUseDate = "2016-01-08 16:52:04";
                }
                managementserver {
                        url = "https://acs.o2online.de/nbbs/tr69";
                        username = "$$$$GYBU6L2SRJBVOSTSPDU5E3AVQFREZR1KCOIXBAF6EIYFGPP5D3HLSO3OOKQCEKWKENOKBHARTAJSMKWT";
                        password = "$$$$W4HGRPPYCJOYAPUQ6RUFBFJ2G2K4FSCX6PACE66UDDZYY3TKBID2D4ULPQ5AVQ5ZMAAK15YQ4BSXCKWT";
                        URLAlreadyContacted = yes;
                        LastInformReq = "2016-01-08 16:52:05";
                        LastSuccessfulContact = "2016-01-08 16:52:05";
                        URLbyDHCPIface = "";
                        PeriodicInformEnable = yes;
                        PeriodicInformInterval = 3600;
                        PeriodicInformTime = "1970-01-01 01:00:00";
                        UpgradesManaged = no;
                        ACSInitiationEnable = yes;
                        SessionTerminationWithEmptyPost = no;
                        ConnectionRequestUsername = "";
                        ConnectionRequestPassword = "";
                        dnsprefer = tr069dnsprefer_ipv4;
                }
        }
        FirmwareDownload {
                enabled = yes;
                enabled_converted = yes;
                upload_enabled = no;
                valid = no;
                suppress_notify = no;
                status = 0;
                StartTime = "1970-01-01 01:00:00";
                CompleteTime = "1970-01-01 01:00:00";
                method = Download_Method_DL;
        }
        RebootRequest = no;
        RebootRequest_CommandKey = "";
        ACS_SSL {
                verify_server = yes;
                trusted_ca_file = "/etc/default/avm/root_ca.pem";
        }
        Download_SSL {
                verify_server = yes;
                trusted_ca_file = "/etc/default/avm/root_ca.pem";
        }
        guimode = guimode_visible;
}


// EOF

habe den code von dir in der Shell eingetragen und habe nun die tr-069 wie oben, allerdings verwundert es mich, das da user & passwort anders sind als in der "Vorgängerversion" meiner tr-069

im ereignislog ist das einzigst "interessante?" folgendes
Code:
[TABLE="class: zebra"]
[TR]
[TD]08.01.16[/TD]
[TD="class: date"]16:54:08[/TD]
[TD][URL="http://fritz.box/help/help.lua?sid=de51f5848ab5c337&helppage=hilfe_syslog_117.html"]Filter-Liste der von der BPjM indizierten Internetseiten erfolgreich aktualisiert.[/URL][/TD]
[/TR]
 [TR]
[TD]08.01.16[/TD]
[TD="class: date"]16:52:04[/TD]
[TD][URL="http://fritz.box/help/help.lua?sid=de51f5848ab5c337&helppage=hilfe_syslog_2104.html"]Die Systemzeit wurde erfolgreich aktualisiert von Zeitserver 217.188.59.84.[/URL][/TD]
[/TR]
[/TABLE]

was ich nicht verstanden habe ist:
Code:
showshringbuf tr069
sollte ich das in der shell eintragen? wenn ja, gab mir dieses keine ausgabe.

oder man fischt die Ausgabe aus den Support-Daten heraus

die wären wo?

auch merkwürdig ist, wenn ich die URL des ACS von o2 im browser eintrage erhalte ich nur:
Code:
[h=1]Not Found[/h] The requested URL /cwmpWeb/WGCPEMgt was not found on this server.

normal?
 
Vorweg ... ich habe keinen o2-Anschluß, kann also auch nicht selbst testen.

Die Speicherung der verschlüsselten Werte in den Konfigurationsdateien enthält einen zufälligen Wert (salt), daher sehen die nach jeder Änderung der Datei (das muß nicht einmal einen der verschlüsselten Werte betreffen) anders auf. Kannst Du einfach testen, indem Du TR-069 abschaltest (ctlmgr_ctl w tr069 settings/enabled 0) und dann die neue tr069.cfg mit der davor vergleichst ... wieder einschalten mit 1 nicht vergessen.

Da ich auch keinen Anbieter mit TR-069 habe, weiß ich nicht genau, ob im Ringbuffer für tr069 nun jegliche Kommunikation landen sollte oder nur Konfigurationseinstellungen, die der ACS übermittelt hat.

Theoretisch müßte Deine Box beim ersten Kontakt ihrerseits dem ACS eine URL mitteilen (der funktioniert ja nach dem, was in der tr069.cfg landet), unter der sie von ACS zu erreichen ist, inkl. passender Credentials. Dann sollte der ACS in nicht allzu ferner Zukunft das CPE zur Kontaktaufnahme auffordern und bei dieser Kontaktaufnahme (mit reason = CONNECTION REQUEST) sollte dann die Telefonie-Konfiguration vom ACS kommen. Vielleicht ist da inzwischen auch eine Mißbrauchserkennung beim Provider wirksam geworden, weil da zu viele ungültige Versuche in kurzer Zeit erfolgten? Ich habe keine Ahnung, aber mit einem durchlaufenden Mitschnitt auf der "1. Internetverbindung" sollte man früher oder später auch mal die Aufforderung des ACS (die geht an den Port 8089 bei einer FRITZ!Box) sehen. Kommt die gar nicht erst, ist vielleicht etwas im Kunden-Account bei o2 falsch oder "eingeschnappt".

Du hast nicht zufällig noch irgendwelche anderen Netzwerk-Geräte zwischen dem DSL und der FRITZ!Box, daß der ACS deshalb nicht zum CPE durchkommt? Wenn nicht, würde ich mal mit der o2-Hotline Kontakt aufnehmen, ob es da event. eine Mißbrauchserkennung gibt und die vielleicht ausgelöst hat bei Deinen bisherigen Versuchen.

Zu dem Versuch mit dem Browser kann man ohne Kenntnis des HTTP-Inhalts an dieser Stelle auch nichts sagen ... eigentlich will der ACS ja SOAP-Requests sehen, das kann also auch ganz simpel eine Redirection für "nicht-standardkonforme" TR-069-Clients sein. Zumindest die Developer-Tools des eigenen Browsers müßte man dann schon auf die Verbindung ansetzen, wenn man da sehen will, was im HTTP-Protokoll passiert.

BTW: Die heute bekannt gewordene Lücke im TR-069 bei o2 kennst Du? Vielleicht haben die deshalb in den letzten Tagen an dieser Stelle auch etwas grundsätzlich geändert ... das ist reines Rätselraten.
 
Zuletzt bearbeitet:
die Lücke kenne ich nicht bei o2
die Fritzbox ist direkt an der Telefondose angeschlossen, kein weiteres Gerät dazwischen
auch habe ich Handy und Co noch nicht mit der FB via Wlan verbunden, damit da nicht irgendwas "hakt".
laut meinem o2 Kundenaccount ist alles bei mir "aktiviert" - ich denke mal von denen aus "freigeschaltet" was jedoch nichts mit der FB zu tun hat.

ich warte nun einfach mal ab, was sich bis morgen mittag so tut, andernfalls werde ich mich an o2 wenden müssen (auch wenn laut einiger Aussagen im Internet, diese nicht die "hellsten" sind)
ich danke dir vielmals für deine Unterstützung hier! Sollte dir noch etwas einfallen was ich ausprobieren kann, werde ich es auch testen. :)
 
Ich glaube die Fritzbox 7490 fragt auch von sich aus automatisch beim o2-Autokonfigurationsserver nach der VoIP-Konfiguration, wenn bei den Internetzugangsdaten als Internetanbieter "o2 DSL" ausgewählt wird.

Es gibt auch eine Missbrauchserkennung bei o2, aber wenn man die Internetverbindung kurz trennt hat man ja hinterher eine neue IP-Adresse und kann somit eine etwaige Missbrauchserkennung umgehen.

Es gibt immer wieder Fritzbox 7490 (auch im o2-Hilfeforum), bei denen der Abruf nicht funktioniert ohne dass man den Grund dafür festmachen könnte.
Ein Grund kann aber sein, dass die Fritzbox keinen CWMP-Account hat, also im Environment die Variable tr069_serial fehlt. Dieser Wert wird nämlich auch an den o2-Autokonfigurationsserver gesendet und wenn der Wert fehlt funktioniert es nicht. Dies scheint z.B. bei den 1&1-Boxen der Fall zu sein und auch nachdem man das 1&1-Branding entfernt hat.

Dass man acs.o2online.de nicht über den Browser erreichen kann ist normal (weil der ACS SOAP-Requests sehen möchte).

Ich bin gespannt, was o2 wegen der jetzt bekannt gewordenen Sicherheitslücke unternimmt, aber noch scheint da nichts passiert zu sein.

Was Benutzername und Passwort in der tr069.cfg angeht, kannst du diese ja mal mit dem ruKernelTool im Klartext auslesen (wenn du Firmware 06.05 hast).
 
Ein Grund kann aber sein, dass die Fritzbox keinen CWMP-Account hat, also im Environment die Variable tr069_serial fehlt. Dieser Wert wird nämlich auch an den o2-Autokonfigurationsserver gesendet und wenn der Wert fehlt funktioniert es nicht.
kann man cwmp manuell adden und wenn ja, wie?
 
danke
echo tr069_serial 00040E-mac_address

soweit verstanden doch die sache mit dem passwort ..
kann ich einfach eins erstellen und die FB übermittelt das dann an den acs server? oder wie darf ich mir das vorstellen
 
Da das ja wohl nicht bei o2 in irgendeiner Datenbank stehen kann, welches CWMP-Kennwort Deine Box verwendet, mußt Du Dir eines ausdenken. Wenn die reine Existenz des Eintrags entscheidend sein sollte, ist der Inhalt ja egal - ich kann es eben nicht selbst testen.

Ich glaube ohnehin nicht wirklich dran, eben weil für die erste Kontaktaufnahme explizit in den Providereinstellungen schon ein Name und ein Kennwort (o2acs) vorgegeben sind. Ich wollte bloß kein Spielverderber sein und wer weiß, welche versteckten Abhängigkeiten da doch noch existieren ... viel Hoffnung habe ich nicht, daß es etwas ändert, aber ich lasse mich auch überraschen und lerne gern dazu.
 
Die vorgegebenen Zugangsdaten sind Standardzugangsdaten.
Wie sich die tr069.cfg während der Provisionierung verändert, kann man z.B. hier sehen: https://hilfe.o2online.de/message/522063#522063

Prüf doch erst mal, ob die Variablen im Environment vorhanden sind oder nicht. Vielleicht liegt es ja auch an etwas anderem.
Ich hatte mal versucht über Telnet/SSH die beiden Variablen aus dem Environment zu löschen und war gescheitert. Ob das Eintragen funktioniert, konnte ich somit nicht testen. Es gibt ja aber auch noch den Weg die Daten über Adam2 einzutragen.

Eine grundsätzlich andere Alternative könnte natürlich sein sich eine weitere Fritzbox 7490 zu leihen um mit dieser die VoIP-Zugangsdaten abzurufen.
 
in der fb sind die daten nicht vorhanden dancedoc
 
Ich habe jetzt noch mal zwei Sachen getestet:
"showshringbuf tr069" gibt bei mir keine Ausgabe, auch nicht wenn gerade die TR069-Provisionierung stattgefunden hat.

"ctlmgr_ctl w tr069 settings/tr069resetcfg 1" hat bei mir dazu geführt, dass die tr069.cfg nicht mehr aufrufbar war ("cat /var/flash/tr069.cfg" lieferte keine Ausgabe. Auch ein Neustart der Fritzbox führte nicht dazu, dass die Konfigurationsdatei wieder verfügbar war. Erst als ich Internetanbieter auf "weitere Internetanbieter"=>"anderer Internetanbieter" und dann wieder auf "o2 DSL" umstelle war die Datei wieder da.

Bin gespannt, ob es nach Eintragen der Variablen ins Environment funktioniert. Da gibt es leider noch keine Erfahrungswerte.
 
Das ist sehr schade, daß das "showshringbuf" nichts ausgibt. Die einzige Stelle, wo ich so etwas mal gegen einen (offiziellen) ACS testen konnte, war eine 6490 und da kam dann auch etwas in diesem Buffer an.

Das Kommando findet sich m.W. auch bei den DSL-Modellen in der /bin/supportdata und daher hätte ich erwartet, daß es auch funktioniert.

Das Eintragen von Werten ins Environment läuft am Ende wohl doch etwas anders, als ich es vor langer Zeit mal im Trockentest analysiert hatte. In den Urlader mit den "Basis-Variablen" schreibt auch der Code aus tffs_intern.c nicht, der liest am Ende nur die Name-Table als "Datei" aus dem TFFS-Image (mit der ID der Name-Table) und beim Zugriff auf Variablen werden diese dann wie "richtige" Nodes von TFFS_Read gesucht und ausgelesen.

Ein Schreiben einzelner Werte in den Bootloader selbst (und damit das Überschreiben der Variablen aus der Herstellung) kann ja eigentlich auch nicht wirklich funktionieren, das ist ja ein Flash-Speicher und da muß zumindest ein kompletter Block in der "erase size" erst einmal gelöscht (SECTOR ERASE) und dann neu beschrieben werden, auch bei SPI. Zwischen dem "sector erase"- und dem nachfolgenden "page program"-Kommando wäre dieser Teil des Bootloaders "leer" und das riskiert AVM m.E. nicht wirklich "regelmäßig" bei Zugriffen auf den (NOR-)Flash. Auch bei den Einstellungen gibt es ja deshalb u.a. zwei Partitionen (double buffering), damit wenigstens eine immer gültig sein kann.

Selbst die "Name-Table" im Bootloader wird nicht so einfach "von außen" geändert, wie ich nach dem ersten bewußt wahrgenommenen Update (von @K auf @L) feststellen konnte, im Bootloader gibt es bei meiner 7490 immer noch keinen Eintrag "wlan_ssid", im Kernel und in den TFFS-Partitionen schon (von mir wurde auch ein Wert eingetragen).

Damit wirkt wohl alles nur auf MTD3/4 (EVA) bzw. MTD7/8 (Linux 7490), eben m.E. auch das Schreiben aus EVA heraus. Aber man kann das eben nur schlecht testen, weil man ja an den Inhalt der TFFS-Partitionen nach einer Änderung in EVA auch erst dann wieder herankommt, wenn das System schon geladen ist. Bliebe nur ein eigener Kernel - andererseits kann man ja problemlos feststellen, daß der Inhalt von MTD2 (EVA) bzw. MTD6 (Linux 7490) unverändert bleibt, egal was man per EVA oder procfs ändert.

Damit ist (mir) zwar immer noch nicht 100%ig klar, wer denn nun die "Basiseinstellungen" wieder aufbaut, wenn MTD3/4 einfach nur gelöscht wurden (also mit Länge 0 "programmiert"), die Name-Table am Beginn so einer Partition wird aber erst beim Fehlversuch mit "avm_urlader_open" neu aufgebaut (in tffs_intern.c) - leider klärt das wohl immer noch nicht, ob es nun EVA oder der (später gestartete) Linux-Kernel ist, denn diese Funktion wird wohl von beiden verwendet.

Auf alle Fälle bin ich mir (bei der 7490) inzwischen relativ sicher, daß es praktisch keinen Unterschied macht, ob man mit "SETENV" in EVA oder per procfs im laufenden System einen Wert ändert. Das macht das Löschen von MTD3/MTD4 zu einer schlechten Idee und ich rate tatsächlich davon ab, das (bei den NAND-Modellen) als "Problemlösung" zu verwenden. Mal sehen, vielleicht kriegt man es beim ruKernelTool ja auch hin, an die Stelle des Schreibens einer leeren Datei das Schreiben eines TFFS-Images zu setzen, nachdem die (belegten) Einträge aus dem Environment mit "RETR env" ausgelesen wurden. So kompliziert ist das ja nicht, ein Environment mit den Urlader-Einstellungen zusammenzustellen, da kommt ja noch gar kein "deflate" für die Werte zum Einsatz, das ist nur eine Aneinanderreihung von IDs und Werten mit passendem Header, beginnend mit einem Segment-Header, der die aktuell gültige Partition festlegt (der kleinere Wert gewinnt) und gefolgt von der Name-Table, die aber m.E. nicht mal "Pflicht" ist (wird dann eben aus den geladenen Kernel neu aufgebaut und geschrieben). Der Rest sind dann nur die IDs, Längen und Werte der Variablen ... das ist ziemlich leicht nachzubauen.
 

Neueste Beiträge

Statistik des Forums

Themen
244,695
Beiträge
2,216,687
Mitglieder
371,314
Neuestes Mitglied
Gjorstn
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.