ein script was ausser dem environment auch eine config (Urlader) ausliesst kann ich in deinem repository (dem öffentlichen Teil) nicht erkennen
Nun .. wenn ich einfach mal nach
"retr config" eva_tools suchen lasse (
https://www.google.com/search?q="retr+config"+eva_tools), dann findet man (ohne Werbung, die bei mir nicht stattfindet in den Ergebnissen einer Suche) genau eine einzige Fundstelle:
und da sollte man als aufmerksamer Leser auch sofort erkennen können, wie man für
eva_get_environment einen alternativen ("entfernten") Dateinamen angibt, den man auslesen möchte ... und das ist dort auch noch genau
config.
Tatsächlich fand (und finde) ich das soo offensichtlich (gerade auch für Leute, die sich das Skript ansehen und verstehen wollen, was da geschieht ... und zwar möglichst BEVOR sie es selbst ändern), was da als erster Parameter angegeben werden kann (man könnte sich ja auch fragen, warum vorne im Skript die Zuweisungen der "positional parameter" an Variablen erst mit
$2 starten), daß ich (es ist ohnehin nur eine "Machbarkeitsstudie" wie man einen eigenen FTP-Client in Shell (
bash) mittels
netcat (bzw.
nc) implementieren KÖNNTE) es nicht als erforderlich ansehe, neben den diversen Erklärungen in vielen Beiträgen (auch hier kann die Suche im Internet nach
eva_get_environment gerne als "Beweis" selbst in Augenschein genommen werden) noch weiteres dazu (im Repository oder in den Skripten direkt) zu schreiben, was über den ohnehin vorhandenen Text in der
readme.md (
https://github.com/PeterPawn/YourFritz/tree/main/eva_tools#readme - die wird üblicherweise auch noch automatisch angezeigt beim HTTP-Zugriff auf das Unterverzeichnis im Repo) hinausgehen würde.
Es gibt dort genau vier (Shell-)Skripte dieses Typs (FTP-Kommunikation mit EVA) und mit denen werden praktisch alle relevanten Einsatzfälle abgedeckt und zwar mit so wenig wie möglich Redundanz im Code (wobei ein Abwägen zwischen dem Auslagern von Funktionen für den FTP-Zugriff und der Bequemlichkeit, die Datei(en) auch einzeln kopieren/laden zu können, erfolgen mußte). Sowohl das Schreiben und Lesen von "Dateien", als auch das Lesen und Setzen von Environment-Variablen und das Laden eines Image-Files in den RAM mit den dazu notwendigen Berechnungen werden exemplarisch gezeigt. Und dabei wird es auch bleiben - sorry.
Die Suche nach EIN PAAR Informationen (s.o.) halte ich absolut für zumutbar - bisher ist es auch schon vielen Benutzern gelungen, diese Hürden zu meistern. Auch der Name
eva_get_environment ist (und bleibt) in meinen Augen gerechtfertigt, denn das genau ist es, was das Skript ausgibt, sofern man keinen anderen (gültigen!) Dateinamen beim Aufruf spezifiziert.
Aber egal ... wie man an sein Ziel kommt, spielt ja nur beim (eigenen) Aufwand eine Rolle und wer sich mit der Suche im Internet nicht auskennt, muß eben durch eine eher "harte Schule". Ich würde dennoch bitten, die "Vollversion" des geänderten Skripts in #24 mit klaren Hinweisen auf den Ursprung (der originalen Version) zu versehen (auch wenn das nur ein PoC ist/war) oder sie ggf. auch einfach mit Hinweis darauf, daß sie eigentlich überflüssig ist, zu entfernen. Denn auch dann, wenn sich einem menschlichen Leser bei kompletter Lektüre des Threads der Kontext erschließen mag, ist das bei einem Spider einer Suchmaschine noch lange nicht garantiert und da die Urheberinformationen sich nicht aus dem Skript selbst, sondern nur aus dem Repository, in dem das Original zu finden ist, ableiten lassen, könnten daraus Unklarheiten entstehen. Danke.
@porcupine:
Welche "Hintergedanken" hast Du denn beim Flashen? Warum überschreibst Du gleich immer beide Systeme (und das meint hier Slot 0 und Slot 1, nicht jeweils ARM+ATOM)? Hast Du jemals überprüft, ob ein Umschalten von
linux_fs_start tatsächlich auch ohne Reboot von EVA wirksam wird? Denn das paßt eigentlich so gar nicht zu dem, was in Anleitungen stehen SOLLTE (mir ist auch klar, daß es viel zu viele falsche Nacherzählungen gibt) - üblicherweise schreibt man EIN System, das aus vier Partitionen besteht und WENN man das alternative (sprich: inaktive) Partition-Set beschrieben hat (den aktuellen Wert von
linux_fs_start liest man eben VORHER aus und zwar möglichst in einer getrennten FTP-Session), dann ändert man vor dem Reboot noch den Wert von
linux_fs_start.
Ich wollte ursprünglich noch einmal selbst mit meiner 6690 prüfen, ob sich Puma7-Geräte dabei ebenso wie Puma6-Boxen verhalten:
[Fullquote des Beitrags direkt darüber gelöscht - siehe Forumsregeln, Novize] mtd0 0x0,0x4000000 Filesystem ARM mtd1 0x4000000,0x4800000 Kernel ARM mtd2 0xa0000,0xc0000 Urlader mtd3 0xc0000,0x100000 Environment mtd4 0x100000,0x140000 Environment mtd5...
www.ip-phone-forum.de
- aber da ich in diesem Punkt nicht sicher bin und im Moment nicht zum Testen komme, würde ich an Deiner Stelle einfach den "Weg der geringsten Gefahr" gehen, zuerst mal
linux_fs_start auf
0 setzen und dann - nach einem Neustart des Routers, der nicht schaden kann - die Partitionen 0, 1, 6 und 7 "frisch" beschreiben (und zwar nur diese) und die Box dann neu booten, OHNE an
linux_fs_start zu drehen.
Irgendwie ist da etwas aus dem Lot geraten.
Bei den Puma-Modellen werden zusätzliche Daten (u.a. eben das Zertifikat und natürlich auch der private Schlüssel dafür) in diesem Konfigurationsbereich abgelegt, dazu gehören auch Kalibrierungsdaten für die beiden WLAN-Adapter und DECT. Das wird dann von einem zusätzlichen Kernel-Treiber in BLOBs zerlegt, die unter
/proc/avm in (Pseudo-)Unterverzeichnissen bereitgestellt werden.
Eigentlich kann man diese Infos nur dann beschädigen, wenn man irgendwelche Manipulationen am Bootloader vornimmt - so wäre jedenfalls MEIN Kenntnisstand. Nun kannst Du Dir ja mal überlegen, ob das bei Deiner Box der Fall sein könnte - denn offenbar funktionierte das zuvor ja noch, wie Deine Protokolle zeigen. Außerdem ist auch DAS ein (wenn nicht sogar: der) Grund, warum man nicht einfach 1:1 den Bootloader der einen auf eine andere Box übertragen kann (vielleicht weil man die CM-MAC und das Zertifikat ändern will, um die eigene Box doch noch beim Provider provisionieren zu lassen).
@fesc:
Sind die Zuordnungen bei Puma7 dynamisch (wie bei Puma6, denn m.W. gilt das von mir dazu Geschriebene - s. Link oben - auch für die 6590) oder sind die tatsächlich statisch, so daß 0, 1, 6 und 7 immer die Partitionen mit der
0 am Ende des Namens (also P2 bis P5) sind? Wenn Du das sicher weißt (weil Du es selbst getestet hast), kann ich mir den Test sparen.
