[Info] modfs - SquashFS-Image (AVM-Firmware) ändern für NAND-basierte FRITZ!Boxen

[PeterPawn]

Das dient der Vorbereitung von dynamisch geladenen Paketen ... solange ein passender Key existiert, kann man über das (Update-)GUI oder vom USB-Stick (wenn man Dateien entsprechend vorhandener AVM-(DECT-)Technik passend umbenennt) jedes beliebige "Pseudo-Image" laden und die darin enthaltene "./var/install"-Datei ausführen lassen (jedoch mit unterschiedlichen Pfaden, je nach Art des Ladens).

Wenn ich also ein Paket für - sagen wir mal - die Netzwerk-Diagnose bereitstellen wollte, welches nach dem Laden das vorhandene System (dauerhaft) modifiziert und um eine entsprechende Seite erweitert, bräuchte das eine passende Signatur. Die könnte zwar auch jeder selbst erstellen und damit "individuell signierte Pakete" verwenden, aber dann müßte man selbst zuvor auch das passende Schlüsselpaar erzeugen und den eigenen Key bei den Modifikationen einbauen lassen. Erfahrungsgemäß machen das wenige ... die meisten setzen immer noch auf den Shell-Zugriff.

Daher werde ich (irgendwann in der Zukunft) an die Stelle von "modfs" eben ein anderes Angebot setzen (welches dann auch GRX-Boxen einschließt), mit dem man (automatisch bzw. auch "headless") das existierende System modifizieren lassen kann. Die Pakete dafür werden eine Signatur tragen müssen (schon damit die AVM-Bordmittel wie "tr069fwupdate" genutzt werden können, aber auch aus Gründen der Sicherheit) und das wird - vor der Möglichkeit, das Paket selbst (erneut) zu signieren - dann eine sein, zu der dieser öffentliche "YourFritz-Key" gehört.

EDIT: Im Prinzip ist es die "modfs"-Entsprechung dieses Skripts: https://github.com/PeterPawn/YourFritz/blob/master/framework/implant_public_key - auch wenn dieses beliebige Keys installieren kann und die nur temporär gültig wären.

 

[ThAlex]

Stand bei mir ist:
Aktive Partition: aktuelle Firmware 113.07.01, installiert mit modfs mit folgenden Modifikationen:

create edit_rcuser command, unhide MAC by default, add led display tab, mount by label, add night time control to system menu,
show phone number names, enable custom profile extension, enable rc.user execution, remove affected swap space before stopping USB devices,
enable telnet daemon, add YourFritz key.​

Die inaktive Partition (nennt man die Wrapper Partition) enthält die Firmware: 113.06.92-47565, ebenfalls mit modfs installiert und diversen Modifikationen.

Ich würde hier aber eher die folgende Reihenfolge wählen:

- Update auf aktuelle AVM-Version
- SIAB einpflanzen
- "modfs" über SIAB ausführen und das alternative System nach den eigenen Vorstellungen gestalten

Würde das nicht bedeuten, die alte Firmware 113.06.92-47565 auf der zweiten Partition wird überschrieben?
Welchen Vorteil hätte es, erst nach diesem Update SIAB einzupflanzen?
Könnte ich das nicht auch schon mit der aktuell installierten 113.07.01 machen?

Zum Einpflanzen von SIAB brauche ich folgendes Image?

d.h. folgendes Image per EVA-Tools im Bootloader anstarten
https://github.com/PeterPawn/first_...645c0da7d5f3/implant_siab_3.10.107.image.7490

Ist es richtig, dass dieses Image die YourFritz-Signatur noch nicht enthält?
Deshalb kann ich es nicht über FritzBox-Oberfläche als Pseudo-Image installieren lassen?

Gruß
Thomas

 

[PeterPawn]

Verstehe ich nicht mehr ... der letzte "Status-Bericht" lautete ja: Ich habe 07.01 installiert und dabei hat die Aktivierung von Telnet und Bootmanager nicht funktioniert, nun komme ich nicht mehr per Telnet in die Box und kann nicht mehr auf die letzte Version per GUI umschalten.

Jetzt muß man sich halt überlegen, was man will ... solange man nur "Standardänderungen" am Image vorgenommen hat, die "modfs" anbietet und jederzeit reproduzieren kann, sollte es kein Problem darstellen, von der laufenden 07.01 dieselbe Version noch einmal (per Datei) zu installieren oder ggf. auch eine neuere (bis hin zur Beta-Version 07.03) und in dieser Version (die überschreibt dann tatsächlich die alte Version, die vor der 07.01 zum Einsatz kam) dann per SIAB den Shell-Zugang zu aktivieren und mittels "modfs" die (derzeit installierte) 07.01 mit einer neuen Version mit den gewünschten Änderungen zu überschreiben.

Man kann natürlich auch gleich per SIAB-Injektion die 07.01 ohne Telnet-Zugang mit einer Möglichkeit für den Shell-Zugriff versehen ... dann hat man "den ersten Schritt" aus meiner Aufzählung ja bereits vollzogen. Ob diese "aktuelle Version" nun "original" von AVM ist oder ein mißglückter "modfs"-Versuch, interessiert ja niemanden wirklich - entscheidend ist, daß sie zuerst keinen Shell-Zugang enthält (warum auch immer) und nach der Anwendung des SIAB-Images dann den Shell-Zugang bereithält.

Will man einfach nur auf die 06.92-irgendwas zurück, braucht man ja nur über den Bootloader umschalten ... dann geht man von dieser (alten) Version aus einfach hin und installiert mit "modfs" die aktuelle Version noch einmal. So what?

Meine "Aufzählung" sollte nur eine Alternative sein, bei der man in jedem Falle zum Erfolg kommt - egal, welche Version sich jetzt in welcher Partition befindet (jedenfalls solange durch die Versionsnummern ein Update auf eine "frische" AVM-Version (per GUI) machbar ist, die man danach mit SIAB um den Shell-Zugang erweitert, damit man "modfs" aufrufen kann) und ob man auf die ältere Version nun noch einmal umschalten kann oder nicht.

PS: "wrapper" meint aber auch nicht das inaktive System, sondern die (48 MB große) Flash-Partition im YAFFS2-Format, in der das eigentliche Root-Dateisystem als SquashFS-Image (mit dem Namen "filesystem_core.squashfs") liegt, das dann vom Kernel im Verlauf des Startvorgangs gemountet wird und diese "wrapper"-Partition (per "pivot-root") ersetzt ... daher steht diese YAFFS2-Partition dann (normalerweise read-only gemountet) auch unter "/wrapper" in einem laufenden FRITZ!OS zur Verfügung und kann (zumindest lesend) genutzt werden - das ist das ganze "Geheimnis" hinter dem Einpflanzen von SIAB per Bootloader-Image (was mit einem Pseudo-Image absolut nichts zu tun hat, denn das ist wieder etwas vollkommen anderes).

 

[Shirocco88]

d.h. folgendes Image per EVA-Tools im Bootloader anstarten
https://github.com/PeterPawn/first_...645c0da7d5f3/implant_siab_3.10.107.image.7490

Ist es richtig, dass dieses Image die YourFritz-Signatur noch nicht enthält?
Deshalb kann ich es nicht über FritzBox-Oberfläche als Pseudo-Image installieren lassen?

das "implant_siab.image" wird nur angestartet und modifiziert "inplace ersetzen" zur Laufzeit die LINUX-Partition der Fritzbox; als "Payload" wird das SIAB-Binary sowie der automatische Start dieses SIAB-Binaries in die LINUX-Partition implantiert.

Bei modfs- oder Update-Lauf werden neue LINUX-Partitionen geflashed.

 

[ThAlex]

Eigentlich bin ich mit der installierten aktuellen Firmware (7.0.1) ganz zufrieden. Was ich im laufenden Betrieb brauche, ist mit modfs modifiziert.
Nur wenn ich mal eine neue Firmware installieren muss, brauche ich wieder Shellzugang, um modfs starten zu können. Dazu hatte ich bisher Telnet verwendet und nur bei Bedarf über das Telefon eingeschaltet. Das steht jetzt erstmal nicht zur Verfügung.

Daher werde ich (irgendwann in der Zukunft) an die Stelle von "modfs" eben ein anderes Angebot setzen, mit dem man (automatisch bzw. auch "headless") das existierende System modifizieren lassen kann. Die Pakete dafür werden eine Signatur tragen müssen (schon damit die AVM-Bordmittel wie "tr069fwupdate" genutzt werden können, aber auch aus Gründen der Sicherheit) und das wird - vor der Möglichkeit, das Paket selbst (erneut) zu signieren - dann eine sein, zu der dieser öffentliche "YourFritz-Key" gehört.

Vielleicht ist ja dann, wenn ich eine neue Firmware brauche, dieses Projekt soweit und die Modifikation 'add YourFritz key' ist ja enthalten, sodass ich sie nutzen könnte.

 

[SneakyNinjaDE]

Huhu,

kann mir jemand helfen?

Ich hab bereits die Fritz!Box mehrfach über das Recover laufen lassen. Ebenso habe ich bereits über das NAS sowie überr den Download per Konsole Versucht. Ich bekomme immer folgende Fehlermeldung:

Packing new root file system ... failed
The specified message number 1 was not found at the language file for 'en'.

Die Locale File DE hab ich auch bereits gelöscht, sowie die von EN, ebenso die Daten untereinander ausgetauscht, keine Besserung.

Hat das noch jemand? Ist der Fehler bekannt? Gibt es einen Workaround? Im Netz hab ich nichts gefunden, und auf den letzten 3-5 Seiten habe ich auch keine Information hierüber gefunden.

Die komplette LOG hab ich im Anhang als Text beigefügt. (Wird sont zu Unübersichtlich)

 

[PeterPawn]

Das mit dem fehlenden Eintrag für eine Nachricht mit der Nummer "1" muß man nicht so ernst nehmen ... Ursache ist schlicht und einfach, daß das Packen mit "rc=1" beendet wird und dann wird (fälschlicherweise inzwischen) versucht, für diesen Fehler die passende Nachricht zu finden. Ist Unsinn ...

Entscheidender ist aber ohnehin die Frage, woher denn nun der Fehler beim Einpacken kommt ... und da sollte man sich - zumindest bei den ersten Gehversuchen - an die Anleitungen halten. Ich verstehe z.B. nicht, was der Aufruf mit "sh -x ./modfs ..." bringen soll ... die drei Punkte stehen zwar vielleicht in irgendeinem Beitrag, sind doch aber - m.E. auch ersichtlich - nur die Platzhalter für die jeweils richtigen Parameter, die der Aufrufer selbst einzusetzen hat.

Außerdem gibt es das Debug-Log - in dem werden die wichtigsten Eckdaten protokolliert (deshalb gibt's das ja überhaupt nur) und auch wenn ich keine Ahnung habe, ob darin eine genauere Ursache des Fehlers beim Aufruf von "mksquashfs" zu sehen ist (das liegt daran, daß die STDERR-Ausgabe umgeleitet wird, weil sie für die "spinner"-Ausgabe benötigt wird), sind da doch jede Menge weitere Informationen zu finden - vom freien Platz in den jeweiligen Verzeichnissen (ich würde hier auf zu wenig Speicher tippen, weil sowohl ins "tmpfs" entpackt als wohl auch wieder gepackt wird) bis zu den verwendeten Pfaden.

Für eine Hilfe ist also dieses Debug-Protokoll eine unabdingbare Voraussetzung ... auch wenn das Console-Protokoll i.d.R. besser als gar nichts ist. Wobei hier die (nicht näher erklärten) Kommandos in den jeweils falschen Verzeichnissen ja auch eher verwirrend sind in #1648 - selbst wenn's dann irgendwo später doch noch klappt.

Der Fall, daß jemand tatsächlich das laufende System modifizieren will, ist nicht sooo häufig mehr aufgetreten, seitdem "modfs" auch Updates verarbeiten kann - denkbar, daß da die Kontrollen auf ausreichend freien Speicherplatz nicht länger 100% korrekt arbeiten. Jedenfalls braucht man ja nur mal nachzurechnen, wieviel Platz es benötigt, wenn man das alles im "tmpfs" ent- und wieder packen will ... nicht ganz umsonst lautet die Empfehlung ja, das Arbeitsverzeichnis NICHT ins "tmpfs" zu legen. Denkbar, daß die "Sperren" gegen diese (fehlerhafte) Verwendung nicht greifen ... aber auch für die Kontrolle dieser Vermutung bräuchte es das korrekte Protokoll, weil dort auch nachzulesen ist, welche Tests jeweils gemacht wurden, daß/ob der Speicher reicht.

Den fehlerhaften Versuch der Ausgabe einer Meldung nach dem Fehlschlagen von "mksquashfs" (Zeile 3466) werde ich beim nächsten Update mit entfernen ... bis dahin spielt der aber keine Rolle, denn das eigentliche Problem ist zu diesem Zeitpunkt bereits aufgetreten.

 

[PeterPawn]

Neuer Timestamp -> neue Version mit 0.5.4

Änderungen:

- Die Protokollierung während des Entpackens und Packens ist jetzt dahingehend erweitert, daß bei "rc != 0" der Inhalt von "stderr" für das aufgerufene Programm mit ins Debug-Log geschrieben wird - die falsche Suche nach der Nachricht mit der Nummer 1 ist damit Geschichte.
- Nachdem AVM an die Versionsnummer in der SOAP-Ausgabe des JUIS noch ein " Labor" angehangen hat, kam "modfs" (zuvor schon teilweise "juis_check") ins Schleudern - das wurde auch entschärft.
- Der Patch zur automatischen Anzeige der MAC-Adressen in der LAN-Liste funktionierte nicht mehr in neueren Versionen, nach der Änderung sollte das jetzt auch wieder anders sein.

 

[bmaehr]

Erfolgreich auf meiner 7490 die Firmware 07.11 modifiziert und aufgespielt.
Auch telnet funktioniert (wieder). Danke an @PeterPawn für die Weiterentwicklung.

Für das Modifizieren hae ich das Image auf dem NAS abgelegt und von dort aus modifieziert und laut https://www.opena.tv/howtos/1513-swap-einrichten-auslagerungungsdatei-fuer-den-ram.html eine SWAP Datei angelegt.

 

[eDonkey]

...Auch telnet funktioniert (wieder).

Bis zur 7.01 hatte ich auch keine Problem. Mit der 7.11 geht bei mir Telnet nicht mehr. Die rc.user wird aber abgearbeitet, da das TSB noch funktioniert. Was mache ich falsch, oder läuft Telnet auf einem anderen Port?

edit:
Hat sich erledigt, nach dem 3. Versuch, läuft nun auch Telnet.

 

[TomTomNavigator]

Folgendes Szenario:
Fritz!Box 7430 mit Fritz!OS 7.10, Telnet funktioniert
Zurücksetzen auf Werkseinstellungen (übers Web UI), einige Tests, importieren bisheriger Einstellungen: kein Telnet
Wechsel auf das inaktive System, Fritz!OS 7.01: Telnet verfügbar
Wechsel auf 7.10: kein Telnet

Is das by design oder mache ich was falsch?

 

[koyaanisqatsi]

Moinsen

importieren bisheriger Einstellungen: kein Telnet

...wenn in den Einstellungen der telnetd nicht aktiv ist.
Speicher mal die Einstellungen mit aktivierten telnetd.
Bei Werkseinstellungen laden keinen aktiven telnetd zu haben ist logisch.

 

[TomTomNavigator]

Mir wäre nicht bekannt, dass sich im Export-File Einstellungen zu telnet finden.
Ich kann zwischen den beiden OS Versionen hin- und herwechseln. Fritz!OS 7.01 Telnet da, Fritz!OS 7.10 Telnet n/a.

 

[PeterPawn]

Hat AVM event. in der 07.10 bei der 7430 die Behandlung der alten Telefonie-Funktionen durch den "telefon" (dazu gehörte ja auch der Start des "telnetd") auch dann deaktiviert, wenn man den mit "CONFIG_RELEASE=0" startet?

Ich habe das unter 07.10 noch nicht genauer angesehen ... ich habe selten "telnetd" am Start und nutze eher SSH.

Ansonsten gibt es tatsächlich Einstellungen zum Start des Telnet-Daemons in der Export-Datei ... irgendwo habe ich sogar mal ausgeführt, an welcher Stelle in der Export-Datei (war die "fx_conf", iirc, wobei ich darauf nicht wetten würde, denn das ist nur aus dem Gedächtnis und das wird zunehmend schwach) man das Flag ändern mußte/konnte, wenn man keine andere Möglichkeit der Aktivierung hatte (Tastencode oder Telefonbuch).

EDIT: Bist Du auch sicher, daß die Modifikation für den Symlink funktioniert hat? Wenn der fehlt, wäre das auch noch eine Erklärung, warum es trotz gleicher Einstellung von dem einen System aus nicht klappt. Oder AVM hat sogar den "telnetd" ganz gestrichen aus der BusyBox ... ich nehme mal nicht an, daß Du die von AVM durch eine eigene ersetzt?

 

[TomTomNavigator]

Nach dem Update auf 7.10 hat auch alles funktioniert. Nur jetzt nach dem Laden der Werkseinstellungen und der Config-Wiederherstellung nicht mehr.

//EDIT: Alles halb so wild, wollte es nur mal wo geschrieben haben, falls jemand auch über das Problem stolpert. Einmal modfs und alles wird gut

 

[ThAlex]

Wollte heute das SIAB-Image einpflanzen. Da läuft aber etwas schief - auch nachdem ich Powershell 3.0 installiert habe:

Die Fehlermeldung ist:

PS C:\Users\Thomas> $PSVersionTable

Name                           Value                                                                        
----                           -----                                                                        
PSVersion                      3.0                                                                          
WSManStackVersion              3.0                                                                          
SerializationVersion           1.1.0.1                                                                      
CLRVersion                     4.0.30319.42000                                                              
BuildVersion                   6.2.9200.16398                                                              
PSCompatibleVersions           {1.0, 2.0, 3.0}                                                              
PSRemotingProtocolVersion      2.2                                                                          


PS C:\Users\Thomas> C:\Daten\Telefon\Fritzbox\modfs-siab\EVA-FTP-Client.ps1
Error connecting to remote host
Ausnahme beim Aufrufen von ".ctor" mit 2 Argument(en):  "Ein Verbindungsversuch ist fehlgeschlagen, da die Gegenstelle nach einer bestimmten Zeitspanne nicht richtig reagiert hat, oder die hergestellte Verbindung war fehlerhaft, da der verbundene Host nicht reagiert hat 192.168.178.1:21".

PS C:\Users\Thomas> C:\Daten\Telefon\Fritzbox\modfs-siab\EVA-Discover.ps1
EVA_IP=192.168.178.1
True

PS C:\Users\Thomas> C:\Daten\Telefon\Fritzbox\modfs-siab\EVA-FTP-Client.ps1

PS C:\Users\Thomas> C:\Daten\Telefon\Fritzbox\modfs-siab\EVA-FTP-Client.ps1 BootDeviceFromImage C:\Daten\Telefon\Fritzbox\modfs-siab\implant_siab_3.10.107.image
C:\Daten\Telefon\Fritzbox\modfs-siab\EVA-FTP-Client.ps1 : Die Argumenttransformation für den Parameter
"ScriptBlock" kann nicht verarbeitet werden. Der Wert
"C:\Daten\Telefon\Fritzbox\modfs-siab\implant_siab_3.10.107.image" vom Typ "System.String" kann nicht in den
Typ "System.Management.Automation.ScriptBlock" konvertiert werden.
In Zeile:1 Zeichen:77
+ C:\Daten\Telefon\Fritzbox\modfs-siab\EVA-FTP-Client.ps1 BootDeviceFromImage C:\D ...
+                                                                             ~~~~
    + CategoryInfo          : InvalidData: (:) [EVA-FTP-Client.ps1], ParameterBindingArgumentTransformationException
    + FullyQualifiedErrorId : ParameterArgumentTransformationError,EVA-FTP-Client.ps1

Anschließend konnte ich per ftp auf die alte Firmware umschalten und habe nun wieder Telnet-Zugriff.

Gruß
Thomas

 

[PeterPawn]

Das sind gleich drei Probleme auf einmal.

1. PowerShell 3.0 ist ebenfalls Asbach - die ausgelesene BuildVersion für PS (16398) liegt auch vor der minimal erforderlichen Version (16481). Ich weiß auch nicht, was MS da zwischen diesen zwei Ständen noch geändert hat (denkbar wäre auch nur der Unterschied zwischen englischem und deutschem Windows 7), aber ich zitiere mich mal selbst:

Wer die PowerShell-Skripte verwenden möchte, sollte als erstes mal seine PowerShell-Installation (gerade auch dann, wenn er - wie ich - immer noch gerne auf einem Windows 7 arbeitet) auf den aktuellen Stand bringen ... die Minimal-Anforderungen für die PowerShell-Version stehen in "EVA-FTP-Client.ps1" (ab Zeile 360 im Moment) und können jederzeit auf dem eigenen System durch die Eingabe von "$PSVersionTable" in einer PowerShell-Session abgefragt werden.

Der "aktuelle Stand" bei der PowerShell ist aber auch keinesfalls die Version 3.0: https://docs.microsoft.com/de-de/powershell/scripting/install/installing-windows-powershell - da findet man auch gleich den Link zur aktuellsten Version, die im Rahmen des WMF 5.1 auch für Windows 7 bereitgestellt wird von MS.

2. Ein Aufruf von "EVA-FTP-Client.ps1" OHNE Parameter ist in den allermeisten Situationen ziemlich witzlos ... allerdings kann man damit tatsächlich die Box auch im Bootloader anhalten, wenn das nicht zuvor schon der Aufruf von "EVA-Discover.ps1" erledigt hat. Da das aber das Standardverhalten ist und man in #1656 keine anderslautende Parametrierung sehen kann, sind ALLE Aufrufe ohne entsprechende Parameter (und da stehen sogar zwei davon) zumindest sinnlos, im schlechtesten Falle sogar falsch.

3. Wo findet man denn eine Anleitung, die eine Zeile der Form:

C:\Daten\Telefon\Fritzbox\modfs-siab\EVA-FTP-Client.ps1 BootDeviceFromImage C:\Daten\Telefon\Fritzbox\modfs-siab\implant_siab_3.10.107.image

als korrekten Aufruf beschreibt? Selbst wenn man den "ScriptBlock"-Parameter tatsächlich als "positional parameter" angeben wollte, gehören da immer noch die geschweiften Klammern rundherum und da er ja an Position 2 steht, müßte man davor noch die IP-Adresse angeben als ersten Parameter. Das sieht man auch ganz gut an der "Interpretation" der Parameter durch die PowerShell ... die erste Zeichenkette, die nicht per Keyword als Parameter identifiziert werden kann (das ist hier das "BootDeviceFromImage") wird "$Address" zugewiesen (daß das ohnehin falsch ist, wird an diesem frühen Punkt noch gar nicht festgestellt) und der zweite "positional parameter" (das ist dann der Dateiname des Images beim versuchten Aufruf) wird jetzt als ScriptBlock angesehen:

"ScriptBlock" kann nicht verarbeitet werden. Der Wert "C:\Daten\Telefon\Fritzbox\modfs-siab\implant_siab_3.10.107.image" vom Typ "System.String" kann nicht in den Typ "System.Management.Automation.ScriptBlock" konvertiert werden.

, was natürlich wegen falscher Syntax ebenfalls schiefgeht.

Wenn das oben Stehende alle Erfahrungen beim Versuch der Installation von SIAB umfaßt (also alle Ein- und Ausgaben), dann hat das jedenfalls auch gar nichts mit der verwendeten PowerShell-Version zu tun (komisch finde ich nur, daß die deutsche Version dann eine kleinere Build-Nummer hat als die englische) - das liegt dann nur an den falschen Aufrufen der Skript-Dateien.

Ich kann hier also tatsächlich nur "Anwendungsprobleme" entdecken und mich würde wirklich interessieren, ob das nur vom - ggf. unkonzentrierten - Lesen und falschen "Transformieren" auf die eigenen Umstände kommt oder ob es irgendwo tatsächlich eine "Nacherzählung" anderer Anleitungen gibt, die SOO falsch ist, daß dabei etwas herauskommt wie das in #1656 Gezeigte.

War das für Dich persönlich der erste Kontakt mit dem Thema und/oder der PowerShell?

 

[ThAlex]

War das für Dich persönlich der erste Kontakt mit dem Thema und/oder der PowerShell?

Genau!
Wenn ich es richtig verstanden habe müsste ich folgenden Befehl absetzen:

.\EVA-FTP-Client.ps1 -Verbose -Debug -ScriptBlock { BootDeviceFromImage .\implant_siab_3.10.107.image.7490\}

Es ist nur leider immer wenig Zeit, die FritzBox neu zu starten, weil die Familienmitglieder ungeduldig werden, wenn das Internet ausfällt.
Noch ne Frage: Ist die Shell-in-a-Box Installation persistent oder muss sie nach einem Update mit modfs wiederholt werden?

Danke,
Gruß Thomas

-- Aktualisiert --

So, jetzt hat's geklappt:

Spoiler: Ausgabe PowerShell

PS C:\Daten\Telefon\Fritzbox\modfs-siab> .\EVA-FTP-Client.ps1 -Verbose -Debug -ScriptBlock { BootDeviceFromImage .\implant_siab_3.10.107.image.7490 }
Error connecting to remote host
Exception calling ".ctor" with "2" argument(s): "Ein Verbindungsversuch ist fehlgeschlagen, da die Gegenstelle nach einer bestimmten Zeitspanne nicht
richtig reagiert hat, oder die hergestellte Verbindung war fehlerhaft, da der verbundene Host nicht reagiert hat 192.168.178.1:21".

PS C:\Daten\Telefon\Fritzbox\modfs-siab> .\EVA-Discover.ps1
EVA_IP=192.168.178.1
True

PS C:\Daten\Telefon\Fritzbox\modfs-siab> .\EVA-FTP-Client.ps1 -Verbose -Debug -ScriptBlock { BootDeviceFromImage .\implant_siab_3.10.107.image.7490 }
DEBUG: Response:
220 ADAM2 FTP Server ready

================
DEBUG: Sent
USER adam2
================
DEBUG: Response:
331 Password required for adam2

================
DEBUG: Sent
PASS adam2
================
DEBUG: Response:
230 User adam2 successfully logged in

================
DEBUG: Sent
SYST
================
DEBUG: Response:
215 AVM EVA Version 1.1939 0x0 0x740D

================
DEBUG: Sent
GETENV memsize
================
DEBUG: Response:
memsize 0x10000000

200 GETENV command successful

================
DEBUG: Memory size found : 0x10000000 (256 MB)
DEBUG: Memory size used : 0x08000000 (128 MB)
DEBUG: Image size found : 0x00595900
DEBUG: Set memory size to : 0x07a6a700
DEBUG: Set MTD RAM device to: 0x87a6a700,0x88000000
DEBUG: Sent
SETENV memsize 0x07a6a700
================
DEBUG: Response:
200 SETENV command successful

================
DEBUG: Sent
SETENV kernel_args_tmp mtdram1=0x87a6a700,0x88000000
================
DEBUG: Response:
200 SETENV command successful

================
DEBUG: Sent
TYPE I
================
DEBUG: Response:
200 Type set to BINARY

================
DEBUG: Sent
MEDIA SDRAM
================
DEBUG: Response:
200 Media set to MEDIA_SDRAM

================
DEBUG: Uploading file '.\implant_siab_3.10.107.image.7490' to '0x87a6a700 0x88000000' ...
DEBUG: Sent
P@SW
================
DEBUG: Response:
227 Entering Passive Mode (192,168,178,1,12,0)

================
DEBUG: Sent
STOR 0x87a6a700 0x88000000
================
DEBUG: Response:
150 Opening BINARY data connection

================
DEBUG: Response:
226 Transfer complete

================
True

Erst gab es noch ein paar Probleme mit den Netzwerkeinstellungen (habe das Recovery-Programm für die 7520 genutzt). Aber nachdem ich den PC von Hand auf 192.168.178.99 gestellt habe lief es durch.

Gruß
Thomas

-- Aktualisiert --

Jetzt müsste ich nur noch wissen, wie ich Shell-in-a-Box verwenden kann. Der Link auf der Seite https://github.com/PeterPawn/first_aid/ funktioniert nicht mehr.
Edit:
OK: https://fritz.box:8010/
Gefunden hier:

ShellInABox-Zugang für VR9-Boxen (z.B. 7490) mit OS7.01 herstellen (Seite 1) / Fritz!Load… / Fritz!Load…

Danke und Gruß
Thomas

 

[KingTutt]

Erfolgreich auf meiner 7490 die Firmware 07.11 modifiziert und aufgespielt.

Was für eine Möglichkeit habe ich zu debuggen, warum der GUI-bootmanager auf meiner 7490 mit Fritz!OS 7.11 nicht wie gewünscht funktioniert? Ich habe die AVM Firmware mit freetz fw_custom entpackt und beim wieder zusammenpacken den GUI-Bootmanager patch mit angewendet. Ist ja quasi in dem script schon eingebaut.
Nach dem aktuellen Stand von freetz direkt aus dem git entspricht die Yourfritz Version dort mit dem GUI-bootmanager der aus Peters git repo.

Wenn ich mir mit dem integrierten SIAB das Dateisystem der aufgespielten Firmware ansehe, dann finde ich unter /usr/bin/gui_bootmanager die Version 0.6, welche nach meinem Verständnis hier im Thread auch mit Version 07.08 etc. funktioniert (oder ist 07.11 schon wieder anders?).
Und unter /usr/www/avm/system/reboot.lua finde ich mit folgendem Auszug zumindest einen Hinweis, dass der Patch erfolgreich angewendet wurde (das gleiche im Pfad mit 1und1).

if box.post.linux_fs_start then                     
local linux_fs_start = string.gsub(box.post.linux_fs_start, "'", "")
local branding = box.post[linux_fs_start.."_branding"] ~= nil and string.gsub(box.post[linux_fs_start.."_branding"], "'", "") or ""
os.execute("/usr/bin/gui_bootmanager switch_to '"..linux_fs_start.."' '"..branding.."'")
end

Dennoch wird auf der Rebootseite im Webinterface nicht die bekannte Auswahl angezeigt. @PeterPawn kann ich irgendwie im Browser oder mittels SIAB feststellen, was schief geht?

 

[PeterPawn]

Prinzipiell mußt Du erst mal ermitteln, welcher Teil nicht funktioniert ... die Abfrage der Daten oder deren Anzeige.

Bei den neuen Versionen wird der HTML-Code nicht mehr vom Shell-Skript erzeugt ... dieses gibt nur noch die Variablen aus, die dann vom Lua-Code in JSON-Variable verpackt werden, die an den Browser gesendet werden. Dort übernimmt dann Javascript-Code den Einbau der übergebenen Daten in das HTML-DOM.

Ich habe gerade noch einmal geprüft, daß es - zumindest mit "modfs" - auch für die von Dir verwendete Version funktioniert:


Du hast jetzt folgende Optionen:

Du könntest mit den Developer-Tools des Browsers nachsehen, ob die JSON-Ausgabe korrekt erzeugt wird. Das sähe dann z.B. so aus:

{"data":{"intro":{"text":["Sie können hier die FRITZ!Box neu starten."]},"bootmanager":[{"name":"values","obj":[{"id":"active_version","value":"113.07.11"},{"id":"active_date","value":"22.05.2019, 10:47:40 Uhr"},{"id":"active_modified_by","value":"modfs"},{"id":"active_modified_at","value":"05.06.2019, 21:34:42 Uhr"},{"id":"active_brandings","value":"1und1 avm"},{"id":"inactive_version","value":"113.07.01"},{"id":"inactive_date","value":"10.09.2018, 11:42:49 Uhr"},{"id":"inactive_modified_by","value":"modfs"},{"id":"inactive_modified_at","value":"05.06.2019, 21:50:45 Uhr"},{"id":"inactive_brandings","value":"1und1 avm"},{"id":"current_branding","value":"avm"},{"id":"switch_branding_support","value":"true"},{"id":"current_switch_value","value":"0"},{"id":"system_is_switched","value":"false"}]},{"name":"messages","obj":[{"id":"headline","value":"Folgende Systeme stehen auf dieser FRITZ!Box zur Auswahl bei einem Neustart:"},{"id":"currsys","value":"das aktuell laufende System"},{"id":"altsys","value":"das derzeit inaktive System"},{"id":"switchvalue","value":"(linux_fs_start=%1%switch%)"},{"id":"version","value":"Version %1%version% vom %2%date%"},{"id":"modified","value":"zuletzt modifiziert am %1%date% durch \"%2%framework%\""},{"id":"altinv","value":"Das System in den alternativen Partitionen kann nicht identifiziert werden.\nEs verwendet entweder ein unbekanntes Dateisystem oder es könnte auch beschädigt sein.\nEine Umschaltung auf dieses System sollte nur ausgeführt werden, wenn man sich wirklich sehr sicher ist, was man da tut."},{"id":"altmiss","value":"Die derzeit inaktiven Partitionen enthalten kein gültiges System."},{"id":"brndhead","value":"Branding ändern"},{"id":"brndunsupp","value":"Bei diesem Gerät ist keine dauerhafte Änderung der Firmware-Version möglich."},{"id":"brndcurrfixed","value":"Die Firmware-Version des aktuell laufenden Systems ist fest auf \"%1%fixed%\" eingestellt und kann nicht geändert werden."},{"id":"brndcurrsingle","value":"Das oben ausgewählte System unterstützt nur die Firmware-Version \"%1%current%\", diese ist im Moment auch eingestellt."},{"id":"brndmulti","value":"Das oben ausgewählte System unterstützt mehrere Firmware-Versionen, im Moment ist \"%1%current%\" eingestellt."},{"id":"brndset","value":"Beim nächsten Start wird folgender Wert gesetzt und bis zur nächsten Änderung verwendet:"},{"id":"brndaltinv","value":"Da das alternative System nicht identifiziert werden konnte, ist auch keine Information über dort enthaltene Firmware-Versionen verfügbar."},{"id":"brndaltfixed","value":"Die Firmware-Version des derzeit nicht aktiven Systems ist fest auf \"%1%fixed%\" eingestellt und kann nicht geändert werden."},{"id":"brndaltsingle","value":"Das oben ausgewählte System unterstützt nur die Firmware-Version \"%1%alternative%\""},{"id":"brndaltnochg","value":", diese ist im Moment auch eingestellt."},{"id":"brndaltset","value":", im Moment ist jedoch \"%1%current%\" eingestellt."},{"id":"brndaltnew","value":"Bei der Umschaltung des zu verwendenden Systems wird daher auch gleichzeitig dieser Wert auf \"%1%alternative%\" geändert."},{"id":"style_caption","value":"padding-right: 8px;"},{"id":"style_sblbl","value":"padding-right: 8px;"}]}],"timestamp":276,"hints":[{"text":"Beim Neustart werden die Ereignismeldungen gelöscht. Alle Einstellungen der FRITZ!Box bleiben erhalten."}],"actions":[{"name":"reboot","text":"Neu starten"}]},"hide":{"dslStat":true,"dslSet":true,"liveTv":true,"faxSet":true,"provServ":true,"dslSpec":true,"mobile":true,"dslFeed":true,"dslOv":true,"dslGraph":true,"ssoSet":true},"pid":"reboot","sid":"xxx"}

Da es - wie gesagt - erst auf der Browser-Seite zusammengesetzt wird, müssen auch die ganzen Zeichenketten für die Anzeige mit gesendet werden (passend zur eingestellten Sprache) und normalerweise steht das auch alles in einer Zeile. Aber wenn das mit dem "data" beginnt und mit einer SID + der geschweiften Klammer ganz am Ende abgeschlossen wird, wären die Daten schon mal korrekt.

Alternativ könntest Du die anderen geänderten Dateien (die "reboot.lua" ist nur eine von zwei Dateien - die andere ist die "reboot.js") auch noch mit dem Original vergleichen ... da sollten auch Änderungen vorhanden sein.

Wobei ... wenn das Gezeigte tatsächlich der einzige Unterschied zur originalen "reboot.lua" sein sollte, dann fehlt da ganz erheblich etwas - womit sich dann die Frage stellt, wie das zustande kommt. Was da alles in der "reboot.lua" bei der 07.11 geändert werden müßte, kannst Du Dir hier ansehen: https://github.com/PeterPawn/YourFritz/blob/master/bootmanager/add_to_system_reboot.sh - warum das bei Dir nicht erfolgt, kann ich auch nur raten. Allerdings ist der Teil, der bei Dir offenbar in der Datei angekommen ist, auch wieder einer, der bei Versionen vor 07.08 und danach identisch ist. Es könnte also auch sein, daß da schlicht der falsche Patch angewendet wurde.

Nun habe ich diesmal ja den Aufruf in dem entsprechenden Freetz-Patch sogar selbst geändert: https://github.com/Freetz/freetz/bl...patches/scripts/800-modfs_boot_manager.sh#L13 ... aber ich habe den auch getestet. Allerdings KÖNNTE es sein, daß es im "no-freetz"-Modus dann doch wieder einen Unterschied gibt, den ich nicht bemerkt habe, weil ich diesen Modus tatsächlich nicht getestet habe. Am besten sieht man das wohl, wenn man zuvor folgenden Patch auf den Freetz-Tree anwendet:

diff --git a/patches/scripts/800-modfs_boot_manager.sh b/patches/scripts/800-modfs_boot_manager.sh
index bcc5cacd2..db34966fb 100644
--- a/patches/scripts/800-modfs_boot_manager.sh
+++ b/patches/scripts/800-modfs_boot_manager.sh
@@ -10,11 +10,13 @@ for oem in $(supported_brandings) all; do

    echo2 "adding boot-manager front end to branding \"${oem}\""

+   set -x
    TARGET_BRANDING="${oem}" \
    TARGET_SYSTEM_VERSION="${AVM_FW_MAJOR}.${AVM_FW_VERSION}" \
    TARGET_DIR="${FILESYSTEM_MOD_DIR}" \
    TMP="$TEMPDIR" \
-   sh "${TOOLS_DIR}/yf/bootmanager/add_to_system_reboot.sh"
+   sh -x "${TOOLS_DIR}/yf/bootmanager/add_to_system_reboot.sh"
+   set +x
done

rmdir "$TEMPDIR"

Dann werden die Zeilen beim Patchen zusätzlich angezeigt ... ein Problem mit der Version sollte man dort dann erkennen können.

Wenn die Daten hingegen korrekt im Browser ankommen, mußt Du schon noch ein paar mehr Infos liefern ... denn dann spielt der verwendete Browser natürlich eine entscheidende Rolle und man müßte mal schauen, was den vom Firefox (mit dem ich ausschließlich getestet habe, wobei ich soweit wie möglich ja von AVM entwickelten JS-Code nachgenutzt habe, eben um Probleme durch Änderungen zu vermeiden) konkret unterscheidet.