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

Kommt bei der 7560 etwa auch das Dateisystem UBIFS wie bei der 7580 zum Einsatz anstatt SquashFS3/4 oder ist das "nur" ein anderes Problem?
 
Möglich? Woran erkenne ich das?

Für deine Tabelle:
7560: Fritz_Box_HW221
 
Zuletzt bearbeitet:
@eisbaerin:
Der (Shell-)Debug-Ausgabe zufolge ist das kein ext2-Image in der filesystem.image, sondern direkt ein SquashFS4 (fstype=squashfs4) ... so wie es bei den NOR-Modellen auch der Fall wäre.

Hier sollte/müßte man erst einmal in Ruhe das tar-File begutachten ... wenn es eine Box mit NAND-Flash für das System ist, steht bestimmt im SquashFS-Image (also in der filesystem.image) auch eine /etc/inittab und in dieser (vermutlich) auch wieder ein Aufruf von /sbin/flash_update (oder etwas ähnliches) zum Übertragen der Firmware aus den MTDRAM-Partitionen in den Flash-Speicher. Taucht in diesem Skript dann der Begriff "ubi" auf, ist es wohl tatsächlich eine Box mit UBIFS, wie die 7580 (wobei ich das da auch bloß aus der Analyse der Firmware geschlossen habe ... ich habe auch noch keine Support-Daten o.ä. einer 7580 gesehen).

Aber diese erwähnte "filesystem.image" müßte sich dann direkt mit dem "unsquashfs" (oder auch mit dem unsquashfs4, wobei ersteres die neue "unpack all"-Variante wäre) auch auspacken lassen, nachdem man sie mit "tar" aus dem AVM-Image extrahiert hat.

Ich komme gerade nicht dazu, mir das anzusehen bzw. ich kenne mich und weiß, daß ich dann wieder kein Ende finde und mehr als 30 Minuten Ablenkung kann ich mir momentan nicht leisten.
 
super, vielen Dank.
Ich habe mir nun die SIAB installiert und mache mich nun an modfs und dann an meine AVM Firewall. Vielleicht hat da jemand noch ein paar Tips für mich?


Edit:
Ich schreibe hier mal meine Erfahrungen auf.

- Fritz OS 6.60 lässt sich ohne weiteres nicht mit telnet oder ssh ausstatten. Es muss ein Recovery auf eine ältere Version gemacht werden.
- linux_fs_start lässt sich bei mir nicht via ftp/nc auslesen noch setzen
- beide Partition waren neuer als 6.50. Das eine 6.60 das andere 6.51
- der SIAB lässt sich leider nicht mit Copy&Paste bedienen, es muss alles aus dem Browser händisch übertragen werden.
- Dropbear lässt sich nicht installieren. Es wird Kernel 2.6 erwartet. FritzOS 6.50 hat Kernel 3.10.

- Nach der Anleitung http://www.ip-phone-forum.de/showthread.php?t=284778 habe ich erst mal beide Partitionen neu mit dem Recovery bespielt.
- WARUM, da ich Schritt 1 durchgeführt habe. Da mir nicht klar war, dass ich das linux_fs_start nicht händisch umsetzen sollte, da sonst modfs keine Installation zulässt. Nach dem reboot war ich dann auf der anderen Partition und musste dort halt auch die neuere Version feststellen. Also zweites mal Recovery, um telnet / ssh zu erlangen.

- Ich habe zwar alles nach /var/media/ftp/mod entpackt und kopiert, jedoch ist alles nach dem reboot weg :(

- Die Beschreibung Schritt 3 ist leider sehr kurz. Hier wäre es schön zumindest kurz zu wissen, welche Fragen kommen werden und was dies kurz bedeutet... ich habe auf ein enable ssh gewartet. Was wird empfohlen?
-- 1. Frage: own files
-- 2. Frage: rc.user
-- 3. Frage: Branding
-- 4. Frage: Einbindung Erweiterungspakete
-- 5. Frage: Anzeige Heimnetz PCs mit MAC
-- 6. Frage: Busybox für Telnet Daemon
-- 7. Frage: LED Anzeigen wieder steurn
-- 8. Frage: USB Label als Mountpoint
-- 9. Frage: Anzeige Name bei eigener Rufnummer
-- 10. Frage: /etc/profile
-- 11. Frage: Kommandos aus dem TFFS Node 98
-- 12. Frage: Anzeige Gerätenamen statt Typ
-- 13. Frage: VPN Status auf Startseite
-- 14. Frage: USB Subsystem mit swap korrigieren

Es wurde beim letzten ENTER aufregend. Habe ich am Ende mein telnet /ssh?
Wo bekomme ich den richtigen Dropbear her?
Leider kein SSH, aber telnet wieder über das Telefon aktivieren: #96*7* - deaktivieren: #96*8*
Danach mit putty und telnet (Port23) auf die Fritzbox zugreifen
 
Zuletzt bearbeitet:
Ich komme hier nicht mehr mit.

HalliHalloSchat schrieb:
beide Partition waren neuer als 6.51. Das eine 6.60 das andere 6.51
Hier mag ich noch an einen Schreibfehler glauben. Wobei auch das eigentlich nicht so richtig sei kann ... wenn die Box tatsächlich fabrikneu war und es noch keinen Eintrag für "linux_fs_start" gab (weiter oben in der Liste zu lesen), woher sollte dann die zweite "bespielte Partition" kommen?

Da bist Du wahrscheinlich eher durcheinander gekommen, weil Du die Zusammenhänge erst verstanden hast, nachdem Du schon mit der Umsetzung begonnen hattest.

Ja, in ShellInABox ist kein Copy&Paste möglich ... liegt aber am verwendeten Browser und der Tatsache, daß ein solcher meist keinen Zugriff auf den Clipboard-Inhalt zuläßt, wenn der nicht aus derselben Domain stammt. Kann man auch nichts dran ändern, solange der Browser keine Einstellung dafür hat. Ob eine "cross domain policy" helfen könnte, weiß ich nicht ... habe ich auch keine Lust zu ermitteln.

"modfs-Starter" ist nur ein Angebot für einen Shell-Zugang zur Box ... wer C&P braucht und will, muß eben an die Stelle von SIAB das Einrichten des Telnet-Zugangs setzen. Die Boxen, die bereits ab Werk mit einer Version >= 06.51 ausgestattet sind, kommen ja erst so nach und nach bei den Kunden an und bisher gab es einfach auch noch keinen Druck, einen anderen Weg bereitzustellen ... die notwendigen Beschreibungen dafür gibt es trotzdem bereits, nur müßte man sich seine Dateien eben selbst erstellen und/oder zusammenstellen.

Welchen "dropbear" Du da von wo installieren wolltest, geht aus dem Geschriebenen auch nicht einmal im Ansatz hervor ... woher sollen wir nun wissen, warum Dein "dropbear"-Binary eines für einen 2.6er-Kernel war? Schon das klingt komisch, weil das eigentlich keinen echten Unterschied machen sollte bei der uClibc. Also wird das wohl eine statische Variante sein und warum die auf einen 2.6er-Kernel fixiert sein sollte, muß man dann immer noch nicht verstehen. Der umgekehrte Fall, daß eine Software auf einem früheren Kernel nicht laufen will, weil dort hinzugekommene Syscalls fehlen könnten, der wäre wieder denkbar ... aber die Informationen sind einfach zu spärlich.

Ich habe noch kein SSH-Paket "veröffentlicht", nur die Patches für Freetz, damit man sich selbst einen "dropbear" basteln kann, der mit dem Box-Zertifikat/-Schlüssel arbeiten kann. Damit gibt es in "modfs" bisher keinen SSH-Zugang und ich verstehe den Zusammenhang zum SSH in diesem Thread ohnehin nicht.

Wenn Du die Bootloader-Variable "linux_fs_start" nicht auslesen kannst bei einer fabrikneuen Box, liegt die Vermutung nahe, daß sie einfach noch nicht gesetzt ist. Wenn Du sie dann aber auch nicht setzen kannst, liegt wieder eine andere Vermutung näher ... wahrscheinlich arbeitest Du einfach mit dem falschen FTP-Server (nämlich dem aus dem FRITZ!-NAS) und das sollte eigentlich auch nicht passieren, wenn man von Beginn an und bis zum Ende liest, bevor man ans Werk geht. Es ist auch nicht weiter schwer, diese FTP-Server auseinanderzuhalten ... in der BOOTSELECTION.ger steht ausdrücklich drin, wie die "welcome message" des Bootloaders aussieht und die ist kaum mit der des NAS-FTP-Servers zu verwechseln.

Dann hätte sich auch eine Beschreibung finden lassen, wie man unter Zuhilfenahme einer älteren FRITZ!OS-Version (es geht auch eine neue mit 3.10er-Kernel, aber die Beschreibung arbeitet noch mit einer älteren) ShellInABox bei einer Firmware mit strikter Signaturprüfung zum Laufen bringen kann .... auch ohne Recovery auf eine Version <= 06.50. Insofern stimmt die Aussage
HalliHalloSchat schrieb:
Es muss ein Recovery auf eine ältere Version gemacht werden.
einfach nicht und sie kann daher nicht unwidersprochen stehenbleiben. Das ist ein einziger Weg, das Problem zu lösen und es gibt viele andere, die ebenso zum Erfolg führen.

-Beim Thema Firewall würde ich aber trotzdem von einer Änderung an der AVM-Firewall abraten. Auch da hättest Du ohnehin den steinigen Weg über Neustarts zwischen den Änderungen an Einstellungen in der ar7.cfg vor Dir, wenn Du sicher sein willst, daß die Änderungen auch wirksam werden und damit bist Du beim Vorgehen nicht weit vom Import entfernt (außer daß eben nur eine einzelne Datei neu geschrieben wird). Hier dürfte es wesentlich effektiver sein, wenn eine Filterung nach Ursprungsadressen tatsächlich erst auf dem Zielserver erfolgt ... die Möglichkeiten der AVM-Firewall sind da nicht so vielfältig, als das etwas wie das Geplante ohne weiteres umgesetzt werden könnte. Ich persönlich würde schon bezweifeln (weiß es aber zugegebenermaßen auch nicht), daß sich da beliebig viele Regeln einstellen lassen und Du gehst ja sicherlich nicht davon aus, daß man alle Adressen außerhalb der D-A-CH-Region mit einigen wenigen Regeln ausschließen könnte (oder auch einschließen, das macht in diesem Falle von der Anzahl her wahrscheinlich wenige Unterschiede). Das Abfragen irgendwelcher (DNS- oder WhoIs-)Datenbanken und eine "live decision" ist m.E. auch nicht machbar ... das sind aber alles Problemstellungen, für die es normalerweise schon fertige Pakete gibt, solange die nicht auf einer FRITZ!Box laufen sollen.
 
Konnte erst jetzt antworten, da ich mal wieder einen PPPoE Ausfall von 5,5h hatte.

Aber diese erwähnte "filesystem.image" müßte sich dann direkt mit dem "unsquashfs" (oder auch mit dem unsquashfs4, wobei ersteres die neue "unpack all"-Variante wäre) auch auspacken lassen, nachdem man sie mit "tar" aus dem AVM-Image extrahiert hat.
Genau so ist es. Konnte es jetzt entpacken.

/etc/inittab gibt es:
Code:
#
/dev/ttyLTQ0::sysinit:/etc/init.d/rc.S

# Start an "askfirst" shell on ttyS0
/dev/ttyLTQ0::askfirst:-/bin/sh

# Stuff to do before rebooting
/dev/ttyLTQ0::shutdown:/bin/sh -c /var/post_install

/sbin/flash_update gibt es nicht (in der 7490 auch nicht).
 
Zuletzt bearbeitet:
Naja, was heißt Farbikneu... meine 1&1 FritzBox AutoUpdated sich nun schon seit zwei Jahren vor sich hin.

Woher soll den die Version 6.51 kommen?
Ich habe Recoverys auf 6.50 gemacht und original war die Version 6.60 vom autoupdate drauf.

Ich denke eher, dass ich das Problem habe, dassich weder mit ftp noch nc noch socat noch dem paar scritpen von Peter meine linux_fs_start auszulesen oder zu ändern. Den User "adam2" mit dem selben Passwort akzeptiert er bei besten willen nicht. Wenn eine Verbindung mit ftp oder nc haben nur meine in der Box erzeugten Accounts funktioniert, diese ?dürfen? wahrscheinlich nicht die env ändern.

Ich habe viele Anleitungen gefunden die alle das dropbear von http://www.spblinux.de/fbox/cfg_dropbear bekommen. Man suche mit google einfach nur nach AVM Fritzbox dropbear und nimmt die ersten Seiten.
Die Informationen mit dem Kernel 2.6 sind dann immer gekommen, wenn ich cfg_dropbear install ausführen wollte.
Woher bekomme ich denn ein passendes dropbear und eine kleine Anleitung? Vielleicht ist das auch bisher mein Problem, also Neuling finde ich zwar sehr viele Einträge aber welche nun für meine Version gültig ist, ist meistens nicht ersichtlich ohne absolut linux-profi zu sein.

Ja, genau. ich habe die NAS-Variante aktivieren müssen, damit überhaupt irgendetwas auf dem Port 21 läuft. Wo gibt es denn noch einen ftp-server den ich starten/beenden kann?
Ich habe eine Antwort vom FTP-Server erhalten die am Ende auch ein "FTP Server ready" beinhaltet, daher bin ich mir sicher gewesen, alles korrekt gemacht zu haben.
Ich habe mir die Anleitung einmal durchgelesen und die für mich wichtig erscheinenden Punkte berücksichtigt. Ich werde es nachher nochmal schauen wo es geht, aber dafür müsste ich wissen, wo ich den besagten ftp-server starte. Auf meiner Box, die bereits seit zwei Jahren voll im Einsatz ist, läuft kein Dienst auf Port 21.

@Peter:
Kleine Anmerkung noch zu den scripten vom github: https://github.com/PeterPawn/YourFritz/blob/master/eva_tools.
Diese funktionieren so leider nicht auf Anhieb. Im script eva_discover Zeile 1: #! /bin/sh verträgt sich nicht mit Zeile 120: source yourfritz_helpers.
Die shell unterstützt kein source, dies kann nur die /bin/bash ;)
Desweiteren wurde mein interfacename nicht erkannt, wenn ich diesen mit script eva_switch_system gesetzt habe. Mein Aufruf: eva_switch_system enp3s0 192.168.178.1. Error: INTERFACE invalid.
Wenn ich das eva_discover alleine ohne Übergabeparameter gestartet habe, hat er mir sogar in der Ausgabe erzählt, das er INTERFACE enp3s0 über den Gateway Eintrag ausgewählt hat. Setzen konnte ich diesen aber nicht, ohne die invalid Fehlermeldung.

Deine Tipps zur Firewall. Vielen Dank erstmal dafür.
Ich nutze apache2 als webserver, kannst du mir fertige Pakete empfehlen? Oder wirklich mit freetz die iptables nutzen?
Bin da auch noch ein ziemlicher Anfänger, was dies alles angeht. Mich nerven nur die vielen Anfragen in den Logs die aus der ganzen Welt kommen.
Mein Gedanke war da der, das diese erst gar nicht durch die FritzBox bis zu meinem Homeserver kommen und an der Firewall bereits verworfen werden.
Die Firewallrules während schon sehr lang geworden, dass stimmt.

@All:
So und nun zum wichtigsten!:
Ich finde eure Arbeit SEHR GUT.
Wie sonst kann man aus einer COTS Hardware noch so sehr viel heraus holen und diese seinen eigenen Wünschen anpassen.Ich wollte nur meine Erfahrungen hier niederschreiben, sodass auch meine "Helfer Experten" ein Feedback von mir als "Anfrager" bekommen.
So sind alle hoffentlich zufrieden, ich habe meine Hilfe bekommen und die Experten sehen ihre Arbeit mal aus einer anderen Perspektive, wie so ein Anfänger überhaupt alles so im Wald voller Informationen sieht.
Ich habe bisher immer noch keine Ahnung, wie ich ohne Recovery von 6.60 zu einem telnet/ssh gekommen wäre.

Ich habe ./modfs update wieder die FritzOS 6.60 aktuell am laufen.
Ein SSH Zugang möchte ich immer noch gerne nachträglich einbauen, welcher ist zu empfehlen?
Wo ist der richtige ftp-ADAM2-server?
 
Zuletzt bearbeitet:
Wo gibt es denn noch einen ftp-server den ich starten/beenden kann?
Ich habe eine Antwort vom FTP-Server erhalten die am Ende auch ein "FTP Server ready" beinhaltet, daher bin ich mir sicher gewesen, alles korrekt gemacht zu haben.
Ich habe mir die Anleitung einmal durchgelesen und die für mich wichtig erscheinenden Punkte berücksichtigt. Ich werde es nachher nochmal schauen wo es geht, aber dafür müsste ich wissen, wo ich den besagten ftp-server starte. Auf meiner Box, die bereits seit zwei Jahren voll im Einsatz ist, läuft kein Dienst auf Port 21.
Vom korrekt machen warst du ganz sicher weit entfernt. Deshalb noch einmal: Der FTP in adam steht im Bootloader nur in den ersten fünf Sekunden nach dem Einschalten zur Verfügung.
 
@HalliHalloSchat:
Die sind auch bisher nicht dafür gedacht, daß sie jemand einfach auf sein System kopiert und dort ausführt, ohne den Aufbau und die Anwendung vorher zu untersuchen und zu verstehen (diese Aufforderung gehört bei mir zum "Standardrepertoire", wie man unschwer nachlesen kann).

Wenn das fertig wäre und irgendeinen Status jenseits einer "Konzeptstudie" erreicht hätte, gäbe es entsprechende (ausfürhliche) Hilfetexte für den Aufruf und die Verwendung. Einzige Ausnahme (eigentlich kann sie auch das nicht wirklich sein, weil sie auf unfertige Bestandteile - wie z.B. eva_discover - zurückgreifen muß) wäre eva_switch_system ... das funktioniert bei vielen auch in der "dargebotenen" Form, kann aber logischerweise nicht auf jedem unix-artigen System "out of the box" verwendet werden.

Was da jetzt mit dem Interface beim Aufruf von "eva_switch_system" ist, kann man ja auch mal untersuchen, wenn's denn interessiert ... leider fehlt aber wirklich jeder Fakt, um das auch nur im Ansatz nachvollziehen zu können. Wenn ich es nicht überlesen habe, könnte das locker ein FreeBSD-System oder ein MacOS X sein, von dem Du da schreibst ... da nehme ich zwar die Erfahrung zur Kenntnis, leite daraus aber tatsächlich keinerlei Konsequenz für mein eigenes Handeln ab.

Nicht einmal die Verwendung des "dot"-Kommandos anstelle von "source" ist dadurch zu rechtfertigen (die Frage, was "die shell" ist, stelle ich gar nicht erst - ich kenne Debian-Nutzer, die tatsächlich der Meinung sind, "die shell" wäre "dash", nur weil der Symlink /bin/sh bei ihrer Installation auf diese "Geschmacksrichtung" verweist) ... ich habe genau zwei Umgebungen, in denen ich die Dateien in meinen Repos vorher teste (auch das steht irgendwo in den Weiten des IPPF).

Das ist einerseits die Box selbst als primäres Ziel (hier ist die "ash"-Implementierung aus der BusyBox "die shell") und daneben eine OpenSuSE-Installation, wo eben die "bash 4.2.irgendwas" "die shell" ist. Mit beiden sollte es so funktionieren, wie es im Repo eingecheckt wurde, zumindest hat es das bei mir getan.

Beide Testumgebungen (die ash und die bash) unterstützen das Synonym "source" anstelle des "." und da dieser allzu leicht "überlesen" wird beim Review (wozu ich - nochmal wiederholt - jeden Verwender meiner Elaborate stets aufs Neue ermutige/auffordere), benutze ich da lieber das "source". Wer tatsächlich mit einer 100% Posix-kompatiblen Shell arbeitet und keine Möglichkeit zur Verwendung einer anderen hat (selbst auf anderen "embedded systems" wie Einplatinen-Computern gibt es in aller Regel die BusyBox mit "ash"), der muß eben die Dateien vorher anpassen. Wenn ich bereits im SheBang ein "/bin/bash" eintragen würde, funktioniert es am Ende auf der originalen AVM-Firmware nicht mehr, dort gibt es nämlich keinen /bin/bash-Symlink ... einen Tod muß man sterben.

Wenn man das auf andere Installationen "überträgt" (z.B. auch auf solche, wo es explizit des Aufrufs mit "sudo" bedarf, falls ein Programm oder Shell-Skript Aktionen starten will, die "root"-Rechte erforderlich machen), dann muß man auch genug davon verstehen, um selbst solche "Klippen" bei der Adaption zu erkennen und da gehört die Änderung des "SheBang" von /bin/sh auf /bin/bash noch zu den harmloseren Schwierigkeiten, auf die man dabei stoßen mag.

Auf die Diskussion über /bin/sh lasse ich mich nicht wirklich ein ... in aller Regel ist das ein Link auf die tatsächlich verwendete/bevorzugte Shell, zumindest war es das in der Historie über eine lange Zeit.

Die Dateien sind eben (siehe oben) auch nicht zur "blinden Anwendung" gedacht und solange man nicht bereits dort mit "autoconf" oder einem ähnlichen Helfer eine Anpassung an das jeweils vorhandene System vornehmen will (was ich definitiv nicht unterstützen werde), wird es auch kaum möglich sein, sämtliche *nix-Umgebungen beim Entwurf zu berücksichtigen.

@eisbaerin:
Dann wirf mal einen Blick in die /var/install ... steht da etwas vom "UBIFS"? Wenn nicht, machst Du mich dann doch neugierig - also bitte bitte finde dort das "Formatieren" der Dateisystem-Partitionen mit den "ubi"-Utilities (im Interesse meines Zeitmanagements). Daß die 7560 wieder auf NOR-Flash für das System setzt (dann wäre die filesystem.image ja wieder 1:1 in den Flash übertragbar, auch wenn AVM dann wohl doch eher wieder ein "hidden root image" daraus gemacht hätte), kann ich eigentlich nicht glauben.

EDIT: @HalliHalloSchat:
An anderen Stellen kann ich mir (beim wiederholten Lesen) das Schmunzeln auch nicht verkneifen ... anstatt nach der Ursache zu suchen, warum der FTP-Server einfach die ausdrücklich beschriebenen Credentials mit "adam2" nicht akzeptieren will, hast Du dann einfach einmal die vorhandenen FRITZ!Box-Benutzer "substituiert" und warst immer noch der Überzeugung, Dich dabei auf dem von mir beschriebenen Weg zu befinden? Wir haben vermutlich vollkommen unterschiedliche Vorstellungen, wie man an solche Probleme herangehen sollte. Wenn es bei Dir dann irgendwann auch funktioniert, freut mich das (für Dich) ... aber bitte verstehe auch, wenn ich daraus jetzt nicht unbedingt direkte Konsequenzen für eine Änderung von Beschreibungen oder gar Shell-Skripten ableite. Bei "penibler Vorbereitung" und verstehendem Lesen der (gesamten) vorhandenen Beschreibungen bevor man irgendetwas lädt oder gar ausführt, sollte man nach meiner Überzeugung gar nicht in die von Dir eingeschlagene Richtung "abdriften" können. Selbst wenn ... überprüft man bei unerwarteten Ergebnissen dann die Eingangsvoraussetzungen/-vermutungen noch einmal anstatt recht unbekümmert irgendwelche Randbedingungen zu variieren, sollte man auch wieder auf den richtigen Weg zurückfinden.
 
Zuletzt bearbeitet:
@KunterBunter:
Ja, diese Information hat mir gefehlt.
Korrekt machen, ich stolpere gerade so vor mich hin.

@PeterPawn:
Naja, überzeugt war ich dann wirklich nicht mehr, als die adam2 credentials nicht funktioniert haben. Wollte eigentlich nur wissen, ob meine User funktionieren und etwas zurück liefern.
Du musst da wirklich keine Konsequenzen aus meiner Nachricht ziehen. Ich freue mich gerade, dass du schmunzeln musstest. Ich habe mich auch gefreut als etwas gut funktioniert hat und manche Sachen halt auch total daneben gingen.

Erledigt war dann auch das ein oder andere sehr schnell, dank den Anleitungen.
Ich habe Ubuntu genutzt.

Ich hoffe nun einfach mal, dass ich mich noch weiter mit der FritzBox auseinander setzen werde um das ein oder andere zu verstehen.
 
also bitte bitte finde dort das "Formatieren" der Dateisystem-Partitionen mit den "ubi"-Utilities
Leider nein, es gibt da kein "ubi".

In der /var/install ist aber der Bereich "Copy filesystem image" viel kürzer als bei der 7490. Es fehlen logischerweise alle "mount" Befehle:
Code:
####################
# watch update process state
echo "update_state=good" >>/var/post_install
# ---
# Delete mtds
echo "echo Erase mtd partitions '$var_kernel_mtdnr' and '$var_fs_mtdnr' ..." >>/var/post_install
if [ -x "/sbin/update_kernel" ] && [ -e "/dev/mtd$var_kernel_mtdnr" ] ; then
    echo "/sbin/update_kernel -o /dev/mtd$var_kernel_mtdnr" >>/var/post_install
    echo "/sbin/update_kernel -o /dev/mtd$var_fs_mtdnr" >>/var/post_install
else
    echo "echo mtd $var_kernel_mtdnr erase all > /proc/mtd" >>/var/post_install
    echo "echo mtd $var_fs_mtdnr erase all > /proc/mtd" >>/var/post_install
fi
# ---
# Copy kernel image
echo 'echo Copy kernel image...' >> /var/post_install
if [ -x "/sbin/update_kernel" ] && [ -e "/dev/mtd$var_kernel_mtdnr" ] ; then
    echo "/sbin/update_kernel -i /var/tmp/kernel.image  -o /dev/mtd$var_kernel_mtdnr" >>/var/post_install
else
    echo "cp /var/tmp/kernel.image /dev/mtdblock$var_kernel_mtdnr" >> /var/post_install
fi
echo '[ $? -ne 0 ] && echo failed with error "$?" && update_state=bad' >> /var/post_install
# ---
# Copy filesystem image
#### no wrapper
echo 'echo Copy filesystem image ...' >> /var/post_install
if [ -x "/sbin/update_kernel" ] && [ -e "/dev/mtd$var_fs_mtdnr" ] ; then
    echo "/sbin/update_kernel -i /var/tmp/filesystem.image  -o /dev/mtd$var_fs_mtdnr" >>/var/post_install
else
    echo "cp /var/tmp/filesystem.image /dev/mtdblock$var_fs_mtdnr" >> /var/post_install
fi
echo '[ $? -ne 0 ] && echo failed with error "$?" && update_state=bad' >> /var/post_install
echo 'echo ... Copy filesystem done' >> /var/post_install
# ---
 
Zuletzt bearbeitet:
Steht ja da ... "#### no wrapper" - sieht so aus, als würde AVM bei der 7560 auf das "äußere Dateisystem" verzichten und direkt ein SquashFS-Image in die Dateisystem-Partition schreiben (das ist dann tatsächlich wie bei den NOR-Modellen, nur eben wohl doch Kernel und Dateisystem getrennt - vermute ich mal, man sieht ja die Installation des Kernels in dem Auszug oben nicht).

Das wäre etwas schade, weil es einige meiner Erweiterungen dort tatsächlich unmöglich macht (in erster Linie solche, die einen beschreibbaren dauerhaften Speicher in der Box aus abseits des yaffs2-Dateisystems unter /var/media/ftp benutzen) ... aber lassen wir es erst einmal so stehen, daß die 7560 im Moment nicht mit "modfs" zu modifzieren ist. Irgendwelche Anpassungen kann ich da auch nur dann vornehmen, wenn ich den kompletten Aufbau der Box (das geht bei den Support-Daten los und braucht dann wohl noch ein paar zusätzliche Angaben, für die man wohl erst einmal eine Shell benötigt) auch verstanden habe.

Ist im Moment nicht vordringlich ... erst einmal müssen sich die Boxen auch materialisieren und zwar in nennenswertem Umfang und nicht nur als Vorabexemplare für die Presse o.ä. - dann kann man weitersehen.
 
man sieht ja die Installation des Kernels in dem Auszug oben nicht
Das habe ich mal oben vervollständigt, ist aber gleich zur 7490.

Ja, sehe ich auch so, daß es nicht vordringlich ist.
Wollte dich auch keinen Fall drängen!
Aber jetzt weißt du schon was es für dich noch zu tun gibt, und kannst es entsprechend ein takten.

- - - Aktualisiert - - -

Ich habe aber was zu "ubi" gefunden (gibt es bei der 7490 nicht):
Code:
7560# ls -la /usr/sbin/u*
-rwxrwxrwx    1 root     root         22256 Jul 19 12:06 ubiattach
-rwxrwxrwx    1 root     root         14676 Jul 19 12:06 ubiblock
-rwxrwxrwx    1 root     root          6544 Jul 19 12:06 ubicrc32
-rwxrwxrwx    1 root     root         16352 Jul 19 12:06 ubidetach
-rwxrwxrwx    1 root     root         67572 Jul 19 12:06 ubiformat
-rwxrwxrwx    1 root     root         25512 Jul 19 12:06 ubimkvol
-rwxrwxrwx    1 root     root         28772 Jul 19 12:06 ubinfo
-rwxrwxrwx    1 root     root         38812 Jul 19 12:06 ubinize
-rwxrwxrwx    1 root     root         18068 Jul 19 12:06 ubirename
-rwxrwxrwx    1 root     root         20000 Jul 19 12:06 ubirmvol
-rwxrwxrwx    1 root     root         22184 Jul 19 12:06 ubirsvol
-rwxrwxrwx    1 root     root         20128 Jul 19 12:06 ubiupdatevol
Wozu könnte das gebraucht werden?

BTW: Der telnetd ist noch in der busybox. :)
Code:
7560# busybox
BusyBox v1.22.1 (2016-02-03 18:42:38 CET) multi-call binary.
BusyBox is copyrighted by many authors between 1998-2012.
Licensed under GPLv2. See source distribution for detailed
copyright notices.

Usage: busybox [function [arguments]...]
   or: busybox --list
   or: function [arguments]...

        BusyBox is a multi-call binary that combines many common Unix
        utilities into a single executable.  Most people will create a
        link to busybox for each function they wish to use and BusyBox
        will act like whatever it was invoked as.

Currently defined functions:
        [, [[, arp, arping, ash, basename, brctl, bunzip2, bzcat, bzip2, cat,
        chgrp, chmod, chown, chroot, cmp, cp, cut, date, dd, df, dirname,
        dmesg, dnsdomainname, du, echo, egrep, env, ether-wake, expr, false,
        fgconsole, fgrep, find, flock, free, fstrim, ftpget, ftpput, getopt,
        grep, groups, gunzip, gzip, halt, hostname, id, ifconfig, ifdown, ifup,
        inetd, init, insmod, iostat, kill, killall, killall5, ln, login,
        logname, ls, lsmod, lsof, md5sum, mkdir, mkfifo, mknod, mkswap,
        modprobe, more, mount, mpstat, mv, nbd-client, netstat, nice, nohup,
        nslookup, passwd, pidof, ping, ping6, pivot_root, pmap, poweroff,
        printenv, printf, ps, pstree, pwd, pwdx, readlink, realpath, reboot,
        renice, reset, rm, rmdir, rmmod, route, sed, seq, setconsole,
        setserial, sh, sha3sum, sleep, smemcap, sort, stat, stty, swapoff,
        swapon, switch_root, sync, sysctl, tail, tar, tee, [COLOR="#00FF00"]telnetd,[/COLOR] test, tftp,
        time, top, touch, tr, traceroute, true, tty, [COLOR="#FF0000"]ubiattach, ubidetach,
        ubimkvol, ubirmvol, ubirsvol, ubiupdatevol,[/COLOR] umount, uname, uniq, unxz,
        unzip, uptime, vconfig, vi, wc, wget, whois, xargs, xz, xzcat, zcat
Ist das nicht etwas zu viel "ubi"? Warum doppelt?

- - - Aktualisiert - - -

Unter /usr/sbin gibt es auf der 7560 auch noch was interessantes Neues, eine "readchip".
Auf meiner 7490 sieht das so aus:
Code:
7490# readchip
        Part Number     : Unknown
        Version         : V12
        Wafer Lot Code  : 000032D?
        Chip Wafer Date : YEAR:2016 MONTH:12 DAY:4
        Chip Wafer ID   : 0x0
        X,Y LOC         : 0x70,0x3A
Error -> Not a GRX350/550 series device!!!
 
Zuletzt bearbeitet:
Ist es richtig

wenn ich via GUI ein FW-Update mache aktuell auf 06.60-33899 BETA und die Vorgängerversion aus der inaktiven Partition verschwindet, ich mühsamst den ganzen Kladderradatsch mit Recovery/SIAB/modfs-Starter usw. von vorne Beginnen darf?

Irgendwie gehen hier auf einer Produktiv-FB7490, auf die ich nur via WLAN Zugriff habe, persistent die Telnet-Option flöten!

Einzige Möglichkeit via WLAN auf eine gespeicherte Laborversion 7490.113.06.55-32922 nachzuflashen, die perse Telnet an Board hat, damit die inaktive Version mit modfs bearbeitbar und dann zurückzuswitchen? Wirklich produktiv und arbeitserleichternd ist das imho nicht!

Wie soll ich per WLAN ein Recovery ausführen ... GEHT imho nicht! Wie flashe ich eine neue FW e.g. Labor/Beta in die inaktive Partition? sodass ich die aktive FW testen und wieder zurück komme?

Dass SIAB und copy+paste nicht möglich wurde von PeterPawn ja erläutert ... ich wäre ja bereit mir einen exotischen Browser zu installen nur für diesen Zweck, da ich ellenlange Konsolenbefehle halt nicht mit der Muttermilch aufgesogen habe und via "Linux-Vokabeltraining" auch keine gesteigerten Ambitionen habe, das täglich zu trainieren ... "Auch wenn das I-Net wie frühers im Lateinunterrricht mittlerweile den Kleinen Linux-Stowasser vorhält" ... ist es mühsamst und eigentlich zu zeitaufwändigst!

LG und sorry, wenn ich gerade mal als DAU wieder etwas Frust ablasse ;) Nur jedesmal dank Eisbärins FAQ von vorne anzufangen und sich hier durchzwurschteln ist zeitraubend um den Ausdruck Nervig zu vermeiden! Könner und wie TE PeterPawn mögen das stets belächeln, aber die Zielgruppe/nichtsofirme Klientel rennt halt stehts 2-3mal mit dem Kopf schmerzhaft vors verschlossene Scheunentor
 
Zuletzt bearbeitet:
wenn ich via GUI ein FW-Update mache aktuell auf 06.60-33899 BETA und die Vorgängerversion aus der inaktiven Partition verschwindet, ich mühsamst den ganzen Kladderradatsch mit Recovery/SIAB/modfs-Starter usw. von vorne Beginnen darf?

Hallo Micha0815,
der Trick ist sämtliche neue Firmware per "modfs update /Pfad/zum/Firmware.image" zu installieren;

d.h. Firmware.image https://service.avm.de/downloads/be.../FRITZ.Box_7490_LabBETA.113.06.60-33899.image downloaden
und auf FB7490 NAS ablegen, z.B. nach /var/media/ftp/FRITZ.Box_7490_LabBETA.113.06.60-33899.image
und dann per "modfs update /var/media/ftp/FRITZ.Box_7490_LabBETA.113.06.60-33899.image" installieren.

Das war's.

LG
Tuxedonet
 
Ich habe viele Anleitungen gefunden die alle das dropbear von http://www.spblinux.de/fbox/cfg_dropbear bekommen. Man suche mit google einfach nur nach AVM Fritzbox dropbear und nimmt die ersten Seiten.
Die Informationen mit dem Kernel 2.6 sind dann immer gekommen, wenn ich cfg_dropbear install ausführen wollte.
Woher bekomme ich denn ein passendes dropbear und eine kleine Anleitung?

Oh, Gott!
die dropbear-0.50 Binaries von dieser Website sind doch "sehr angestaubt" und aus dem Jahr 2008 und für mipsel-Fritz!Boxen (z.B. 7270, 7170, ...)!!!

die FB7490 hat doch eine mips-CPU!!!
wie soll das gehen, wenn Big-Endian CUP-Typ verwendet wird und ein Little-Endian-Binary gestartet werden soll ?
dass hier der Kernel, Libs, usw. nicht passen und Fehlermeldungen aufschlagen ist doch klar.

Ein SSH Zugang möchte ich immer noch gerne nachträglich einbauen, welcher ist zu empfehlen?

Warum nimmst Du nicht den Lösungsvorschlag von Koy:
Für MIPS Binaries (dropbearmulti, sftp-server) und Anleitungen, besuch mal: "http://www.fritzmod.net/de/"
Code:
./dropbearmulti --help
Dropbear SSH multi-purpose v2013.62
Make a symlink pointing at this binary with one of the following names:
'dropbear' - the Dropbear server
'dbclient' or 'ssh' - the Dropbear client
'dropbearkey' - the key generator
'scp' - secure copy

Hier mein Startskript...
rc.dropbear
SNIP

LG
PantaRhei
 
Lieben Dank

Hallo Micha0815,
der Trick ist sämtliche neue Firmware per "modfs update /Pfad/zum/Firmware.image" zu installieren;
.

das hatte ich auch so halb im Hinterkopf laut http://www.ip-phone-forum.de/showthread.php?t=284778&p=2153613&viewfull=1#post2153613 nur fehlt dort imho ein Hinweis, möchte man/frau modfs behalten, man/frau jedwede FW-Updates ausschliesslich via modfs anstossen darf.

Unklar bleibt mir als DAU, ob nach einem solchen update via modfs dies für beide Partitionen funktioniert? und ob vor Allem die Einstellungen in einer FW erhalten bleiben und nicht erst auf ein "nacktes" System importiert werden müssen via export-datei.

Nach meinem Verständnis passiert bei einem normalen AVM-FW-Update auf einer 7490 folgendes. Das aktuelle FW-Image wird samt Einstellungen + Configs in die inaktive Partition verschoben/kopiert bzw. wird die inaktive Partiton mit der neuen FW überschrieben und nach einem Neustart aktiv gesetzt, was von aussen betrachtet auf dasselbe Ergebnis hinausläuft.

Der Mechanismus, wie modfs dies handhabt ist mir "reduziert betrachtet" nicht ganz klar.

Als Bsp. In der inaktiven Partition liegt FW 6.50 mit modfsbearbeitet und in der aktiven 6.60. Nun möchte ich eine Labor antesten. Welche muss weichen via modfs-update?

Imho gibt es sicherlich einige Beta-FW-Tester, die einfach eine FW A mit einer Labor bzgl. eigener Anschluss-/Einsatzszenarien nur durch einen Neustart der anderen Partition testen möchten, ohne ständig mit hin+herflashen in AVM-Manier ggfs. mit Recovery, was eines LAN-Zugangs bedarf, hantieren zu müssen.

LG und für den Ausdruck "Kladderradatsch" in #736 möchte ich mich entschuldigen, falls PeterPawn dies als persönliche Beleidigung ansah. Ein wirklich tolles Projekt.
 
Zuletzt bearbeitet:
Eine FRITZ!Box (wenn "modfs" sie unterstützt) hat zwar 2x Kernel und ein jeweils dazu gehörendes Dateisystem, aber ebenso nur 1x Einstellungen, wie jede andere auch.

Damit muß/kann da also gar nichts bei den Einstellungen kopiert werden ... es sind exakt dieselben für beide Systemversionen. Wenn es sich um unterschiedliche Firmware-Stände in den beiden Partition-Sets handeln sollte, muß man selbst dafür sorgen, daß da entsprechende Rücksicht genommen wird auf Inkompatibilitäten.

Die erste Version von "modfs" mußte darauf gar keine Rücksicht nehmen, weil sie eigentlich mal damit anfing, in beiden Partitionen das identische System vorauszusetzen. Auch heute noch wird das als allererstes geprüft, wenn man "modfs" ohne "update"-Parameter aufruft. Ruft man es hingegen mit diesem (später erst eingeführten) Parameter auf, erfolgt m.W. extra noch ein Hinweis, daß der Benutzer für die Verwaltung der Einstellungen selbst verantwortlich ist und ggf. bei inkompatiblen Systemen dann eben einen gesicherten Stand wiederherstellen muß, der zum startenden System paßt.

Ansonsten installiert jeder Aufruf von "modfs" eben genau ein einzelnes modifiziertes System in der inaktiven Partition und schaltet dann um ... das ist ziemlich exakt dasselbe, was eine Update-Installation von AVM auch macht ... "modfs" paßt halt dieses zu installierende System dabei noch an. Wenn man ohne eine solche Anpassung das AVM-System installiert und dann auf dieses umschaltet, was sollte denn dann passieren? Da kann doch gar keine Änderung durch "modfs" in diesem System vorhanden sein, wenn man es 1:1 aus der "stock firmware" installieren läßt.

Micha0815 schrieb:
für den Ausdruck "Kladderradatsch" in #736 möchte ich mich entschuldigen, falls PeterPawn dies als persönliche Beleidigung ansah.
Sieht/sah er nicht ... er kann sich trotzdem den Hinweis nicht verkneifen, daß es schon mehrfach beschrieben wurde, worin der Unterschied zwischen "update" und "recovery" liegt, welches System dabei jeweils "beschrieben" wird und was man anstellen muß, damit man z.B. eine Box hat, bei der zwischen einer Release-Version und einer Labor-Version mit der Erweiterung der "Neustart"-Seite hin- und hergeschaltet werden kann. (Ab hier ist dann auch wieder Schluß mit "dritte Person Singular", sonst diagnostiziert noch jemand Pronominalumkehr als klinisches Zeichen bei mir.)

Wenn man halt in der aktiven Partition eine (unveränderte) AVM-Version mit der 06.60 liegen hat, dann bietet diese logischerweise keine Auswahl des Systems beim Neustart an. Will man hier also eine Labor-Version installieren und hat nur in der inaktiven Partition eine Firmware mit aktiviertem Shell-Zugang liegen, bleibt ja gar nichts anderes als per Bootloader (FTP zur EVA) auf das andere System umzuschalten und von dort aus mit "modfs" ein Update zu machen ... das schreibt dann logischerweise in die zum Zeitpunkt der Ausführung von "modfs" inaktive Partition - im Beispiel also in die, wo bisher das 06.60 liegt bzw. dann lag.

Wenn man also erst einmal verinnerlicht hat, daß es gar keine zwei Sätze von Einstellungen gibt (das hatte ich mal versucht beim "alten Boot-Manager", wo man die Einstellungen pro System speichern konnte, hat aber mit "modfs" absolut nichts zu tun), dann sollten sich die Fragen, wann welches System aktualisiert wird und wie man sich beim Update auf die nächste Version verhalten muß, quasi von alleine erledigen. Die Frage, daß eben "modfs" nur ein einziges System ändert und sich nicht so im System verankert, daß es sich bei einem "normalen AVM-Update" auch wieder in das System einklinkt (das geht tatsächlich, aber dann wird man "modfs" nicht mehr durch einfaches Update auch wieder los und es erinnert schon wieder mehr an Malware), ist aber tatsächlich schon mehrfach erörtert worden.

Für diejenigen, die es ausprobieren wollen: Man kann die /var/post_install entsprechend ändern ... bei AVM werden dort ja die Kommandos zum Schreiben des Systems in die inaktiven Partitionen hinter den üblichen Ablauf beim Neustart angefügt. Läßt man also in der /var/post_install (nachdem man geprüft hat, daß da hinten noch ein AVM-Update in der Datei steht) das alte System auspacken, ändert z.B. den Telnet-Symlink und fügt die Kommandos zum (späteren) Ändern des Systems beim nächsten Update auch gleich noch zur var.tar für das neue System hinzu (inkl. der benötigten zusätzlichen Binaries), kann man sogar ganz normal mit dem AVM-Update ein vom Hersteller signiertes Update installieren lassen.

Die Prüfung der Signatur erfolgt nämlich bereits davor ... und wenn die Firmware diese Hürde erst einmal genommen hat, kann man sie hinterher ziemlich leicht wieder ändern. Man muß nur auch hier aufpassen, daß man das ausführen läßt, bevor einem das USB-Subsystem unter dem Sattel weggeschossen wird ... das klappt mit einer passenden Swap-Partition einfach besser und parallel muß man noch aufpassen, daß keine Watchdog-initiierten Neustarts das Packen eines neuen SquashFS-Images dann doch noch unterbrechen. Kriegt man das auf die Reihe, installieren die AVM-Kommandos auch klaglos das modifizierte Image.

Aber das geht eben wirklich schon mehr in die Richtung "Wurm" oder "Virus", der sich über Updates hinweg in der Firmware festkrallt (so eine Reproduktion ist ja ein Merkmal eines Virus) und auch wenn ich das als Machbarkeitsstudie tatsächlich mal umgesetzt habe (damit in einer Kundenbox gerne auch automatische Updates eingeschaltet werden können und trotzdem eine (recht einfache) Änderung wie mein "heartbeat service" nicht verloren geht), würde ich das für "normale Benutzer" nicht für sinnvoll und notwendig erachten. Hier ist es m.E. besser, wenn bei jedem Update der Besitzer der Box sich ganz bewußt dafür entscheiden muß, welche Änderungen er am System vornehmen lassen will. Spätestens bei signifikanten Änderungen durch AVM müßte man ohnehin wieder eingreifen und den Reproduktionsmechanismus entsprechend anpassen.
 
@PantaRhei:
Vielen Dank für deine Antwort. Ich schaue mir das die Tage einmal an. Ich habe aber irgendwo gelesen, dass AVM auch die debug.cfg nicht mehr ausliest und bei meinem kurzen Überflug auf der Seite, habe ich aber immer debug.cfg scripte gesehen. Wie ist das denn bei einer aktuellen Box zu lösen, ist das die user.rc?
 

Statistik des Forums

Themen
246,101
Beiträge
2,246,185
Mitglieder
373,583
Neuestes Mitglied
df3ei
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.