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

[eisbaerin]

Danke für die Antwort!

Da ist es dann einfacher, den "callmonitor" aus Freetz zu nehmen und etwas anzupassen, damit er (wenn das noch nicht der Fall sein sollte) auch ohne Freetz laufen kann.

Das ist kein Problem, und läuft schon auf einer FB 7170 ohne Freetz.
Aber, wie ich schon in #315 schrieb: Es wird beim "callmonitor" kein Name aus dem Telefonbuch übermittelt!
Dagegen bei calllog schon!

Mein Wunsch ist also: Entweder calllog wieder zu beleben oder im callmonitor den Namen aus dem Telefonbuch zu übermitteln. Sollte doch eigentlich (für AVM) auch kein Problem sein.

 

[PeterPawn]

Ich habe nirgendwo eine Referenz gefunden, wie die Parameter beim Aufruf von "calllog" ausgesehen haben ... irgendwo habe ich zwar noch eine ältere "calllog" in Benutzung gehabt, die mir schön die Aufrufparameter protokolliert hatte, aber ich finde keines dieser Protokolle mehr und auch WHMF hat da nichts weiter.

Aber das Übersetzen einer (schon passend formatierten) Telefonnummer in den zugehörigen Telefonbucheintrag (bzw. den ersten, wenn es mehrere mit dieser Nummer gibt) ist mit einigen Zeilen Shell-Code auch getan, wenn es unbedingt auf der Box erfolgen soll. Ansonsten (also von extern) gibt es inzwischen ja gut dokumentierte Schnittstellen und da kann man dann sogar mit XML-Tools (XSLT/XPATH) den passenden Eintrag (oder auch mehrere wenn man will) selektieren. Auf der Box bleibt die größte Herausforderung derzeit aber das "Lauschen" am Callmonitor-Port.

EDIT: Auf die Idee der Änderung der Formate im CallMonitor kommt AVM hoffentlich nicht tatsächlich ... es ist eine seit langer Zeit stabile (wenn auch nur so la-la indirekt über den Telefoncode dokumentierte) Schnittstelle, die einen Namen anstelle der Nummer (oder gar zusätzliche Felder im Datensatz) nur schwer verkraften würde.

 

[eisbaerin]

Ich habe nirgendwo eine Referenz gefunden, wie die Parameter beim Aufruf von "calllog" ausgesehen haben

Da kann ich dir helfen:

$1 - callerid
$2 - eigene MSN
$3 - LINE z.B. POTS, ISDN, SIP0-19
$4 - Zusätze z.B. BUSY
$5 - Name aus dem Telefonbuch oder 2. originale MSN bei clip no screening

ist mit einigen Zeilen Shell-Code auch getan,

Gibt es da schon Beispiele?
Bitte einen Link. :habenwol:

 

[PeterPawn]

Gibt es da schon Beispiele?

Keine Ahnung ... ist etwas für einen regnerischen Nachmittag. Daher heute definitiv auch keine "Versuche" meinerseits, da wir hier in Berlin strahlenden Sonnenschein haben.

Man müßte einfach mal den "use case" richtig kennen, wenn es nicht nur um das Suchen eines Telefonbucheintrags (ist ja bekanntermaßen die Datei /var/flash/phonebook im XML-Format) gehen soll ... es bleibt ja dabei, daß AVM mit der Abschaffung des nc-Applets auch die Möglichkeit eines "boxinternen" CallMonitor-Listeners praktisch zunichte gemacht hat, solange die ash der Busybox die TCP-Syntax der bash nicht unterstützt. Während es immer noch genug Möglichkeiten gibt, eine Datenübertragung seitens der Box nach außen zu initiieren, sind die Möglichkeiten eines Clients auf der Box, der auf Netzwerkaktionen eines Servers reagieren soll, damit schon arg eingeschränkt (mit Stock-Firmware).

Wenn es am Ende dann an der Erkennung eines eingehenden Anrufs scheitert, bringt ja auch die Übersetzung einer eingehenden Rufnummer in den entsprechenden Telefonbuch-Eintrag nicht so sehr viel.

Das, was ich bisher an externen "Anrufmonitoren" kenne, liest selbst das Telefonbuch und sucht dann bei eingehenden Anrufen auch selbst in diesem nach einem Eintrag.

 

[eisbaerin]

Keine Ahnung ... ist etwas für einen regnerischen Nachmittag. Daher heute definitiv auch keine "Versuche" meinerseits, da wir hier in Berlin strahlenden Sonnenschein haben.

Da hast du mich jetzt aber völlig falsch verstanden!
Ich fragte "gibt es schon", nicht "mach mal gleich"!
Ich lese hier ja sehr viel, aber manches mag ich auch übersehen.

Interessant war für michb ei calllog auch die Originale MSN bei clip no screening.
Die gibt es IMO beim Callmonitor nicht.

Der "use case" is ganz einfach:
meine vereinfachte calllog:

wget -O /dev/null "http://192.168.3.9:23232/@an Eisbaer $2 ($3) von $1, $5 [$4]" &

und der TrayMessage.jar popt bei mir auf dem PC eine Nachricht mit Namen auf.
Der Vorteil gegenüber allen anderen Programmen ist/war:
Ich kann (da das calllog ein skript ist) Bedingungen einbauen. z.B. daß nicht jede MSN an jedem PC angezeigt wird.

if [ $2 = 4711 ] ; then

IMO sollten wir das aber auslagern, da es mit dem eigentlichen Thema nur noch wenig zu tun hat. Machst du ein neues Thema auf oder ich?

 

[PeterPawn]

Machst du ein neues Thema auf oder ich?

Gibt irgendwo schon einen Thread, wie man einen simplen CallMonitor auf der Box selbst realisiert, auch ohne Freetz zu bemühen ... muß irgendwann im Herbst 2014 gewesen sein, nachdem die calllog-Behandlung in der Firmware abgeschafft wurde.

Da paßt dann notfalls auch das Thema: "Wie ermittle ich den Telefonbucheintrag zu einer Anrufernummer in Shell-Code auf der FRITZ!Box?" mit hinein ... bei der "originalen MSN" verstehe ich das ohnehin nicht so genau, was Du da meinst. Entweder der Anrufer übermittelt seine eigene (ggf. auch "gefälschte") Rufnummer (das wäre für mich CLIP-NS) oder sein Provider (nur der kann das "wissen") setzt eine gültige aus dem Vorrat für diesen Kunden.

Wenn Du Dir etwas in der Art der Anrufliste in der Box selbst vorstellst (wo also beide Nummern angezeigt werden), dann geht das über den CallMonitor-Port (TCP/1012) natürlich nicht. Da muß man dann eben mit einem passenden Selektor in die Anrufliste hinein (hatten wir auch schon, welches "tag" da die aktuell laufenden Anrufe haben, müßte ich aber auch erst wieder suchen) und dann kann man sich das "Übersetzen" im Telefonbuch in Shell-Code ja wieder schenken - da wäre die Zeile für den einkommenden Anruf auf dem TCP-Port nur der Trigger für die Abfrage der Anrufliste ... wobei ich nicht weiß, ob der Anruf schon "beim Klingeln" dort auftaucht oder erst nachdem er angenommen bzw. als "entgangen" gekennzeichnet wurde.

Aber Du hast vollkommen recht, das sollte man in einem anderen Thread weiterdiskutieren.

 

[Virgus]

Wow! 17 pages thread read through online english translator, I'm not sure I'll make it

I'm going to start reading, but just to summarize, my questions are about:
- making an automatic telnet activation at boot on international FritzOS 6.30
- find updated versions of busybox, dropbearmulti, and sftp-server for FB7490 to have SSH enabled
(like I had on my FB7270s)

Greetings from Paris!
V.

 

[PeterPawn]

Your first (definite) decision should be, which version you will use.

Up to 06.30 you could use Freetz to create an own firmware image containing all the needed additions.

At the moment of this writing, Freetz doesn't support 06.35 (and higher) version ... if you want to get a persistent telnet daemon with 06.35+, you can use modfs from this thread. It has an english language file (for non-german users) and is able to modify the firmware versions noted in the table from post #1 directly on a 7490 device.

I'm a little bit confused, because you wrote about 06.35 and in my opinion there's no english (or french) version of this beta firmware yet. Would you like to use the german version here or was it only to look ahead in the future, when it will be available as international version?

Anyway ... you could "revive" the telnet daemon with modfs for an international version 06.30, if you'd like ... simply download the modfs archive from the server (link to modfs-0.3.1 is provided in #1, but do not use the first one, it's dead and the german text beneath is the appropriate warning) to the NAS of your box, start a telnet session (using the pseudo update image) and (after unpacking the archive, the needed commands are in #1 and you should be able to find them without translation) call the contained "modfs" script - simply with "modfs". It will copy the running system to the alternative partition set (if needed) and restart once (but only, if the copy operation was necessary).

After this restart call it again (you've to unpack it again, if you did not store the unpacked files to a persistent storage prior) and after detecting the same version within both partitions, it will modify the inactive system with some scripts ... the useful modifications in your case are the (optional) revival of the telnet daemon and - it was the main use case of the original script and will be activated without your option - the execution of the former debug.cfg at boot time, but using another name - rc.user - and with some special precautions to be taken while modifying the statements in this file, so you should consider to install "edit_rcuser" too, if you get the choice while running the script.

The steps above are the original behavior of modfs at a glance and are described in a whole in the embedded README file ... only the latest changes to support firmware >= 06.35 aren't documented yet in this file.

The whole script uses a language file to display its messages and these files are available for german and english readers. You shouldn't get any problems, because the FRITZ!OS uses an environment variable "Language" and if its value does not match the name of a language file, the script will use English as fallback choice. (If you'd like to translate the message file to French, I'll add your translation ... but in my opinion the FRITZ!Box devices are very rare in France and it's not worth the effort, even if the firmware supports this language.)

The other question (where to get precompiled binaries for 7490) should be delayed at the moment ... it's possible to integrate these additions, but (afaik) you've to compile/build them yourself. The good news: You can use the Freetz toolchain to do this. If you read the README file from modfs, you'll notice, that it's possible to do "incremental changes" to your FRITZ!Box ... that's why I'd suggest to modify the firmware step by step.

Please keep in mind, that you could use the Freetz project to create your own image in one single step, as long as you use 06.30 as the base. But as far as I remember, there were some issues with the international version ... you should search a little bit within the Trac system at freetz.org or here in the IPPF to make sure, that the 06.30 for the 7490i is full functioning, if you'd prefer to use an image with Freetz modifications instead.

 

[Virgus]

Peter, I really don't know how to thank you for your great instructions.

Unfortunately I thought it was too late to read your reply and I discovered what you wrote step by step.
It was good though to read your reply as a confirmation and it'll be really useful for the next non-german users who will buy a FB7490

As you imagined the 6.35 comment was a sort of "wishlist" and I saw the alerts here and there about the freetz problems with the international version. So I tried to follow your great readme file and got to the second launch of the script. I tried both the a (use the root image...) and b (download a fresh copy...) options and with both I got the same result: "Unpacking root file system image for modifications ... failed" - "Your selection is invalid."

I was using an USB3.0 FAT32 formatted key attached to the upper usb port, but then saw your notes in the first post of this thread and everything went fine:

mkdir -p /var/mod
cd /var/mod
wget -qO- http://yourfritz.de/modfs-0.3.1.tgz | gunzip -c | tar x

Now it's packing the new root file system, I keep my fingers crossed ;-)
Yes!!! Everything got fine the last ./modfs had to be launched from /var/mod

Tomorrow I'll start investigating about compiling the packets I need for the FB7490
(unless other users of this forum have already done the compiling and are willing to share...).

Talk to you soon and thanks again and again!
Virgus (an Italian in France)

BTW if other users will need I could do both translations, but I agree with you that english should be enough (I prefer english over french and italian for all the softwares I use).

 

[PeterPawn]

@Virgus:
I'd like to support you and we will track down your issues to their roots ... but it's late already and I'd prefer a direct contact (via IRC would be a good choice in my opinion). This can help to keep your special problems out of this thread (you know, there are already 17 pages at this moment) and an immediate feedback is surely the better way to solve the problems as quick as possible.

You should prepare an USB storage stick (or even a HDD, if you own one already) to contain a swap partition and another one with a native Linux filesystem like ext2, ext3 or ext4. Put it into the USB slot and restart the box. The firmware should mount the swap partition automatically and the native filesystem in the other partition can be used later to avoid the need of using a loopback device with a container file, which would slow down the whole process a lot (and is only a workaround if no other option is available). Having some swap space is a good precaution ... there are some reports, that the modification process has failed because the devices ran out of memory. It's better to exclude such problems a priori.

The option to download a fresh firmware image from AVM's FTP server needs some adjustments, because the search path at the server is hard-coded and it will download the german version only this time. That's why I wrote about modifying the existing system and therefore "a" was the correct choice already, as long as you didn't download the international image manually, in which case you could use option "c" and provide the path to this image, if prompted for it.

Only using the root filesystem of the running system gives you the ability to do some "incremental changes" ... each other choice for the first question requires, that all earlier modifications have to be repeated each time the firmware is modified. Both options are usable, but you've to understand the difference and build your own "strategy" for the future. The "b"-option of the first question should be avoided or you've to change line 83 of the script to contain the correct server path for the international version.

For debug purposes I've added some code to create a detailed log (some times ago, not yet mentioned in the README file), it can be activated calling the script with

MODFS_DEBUG=1 MODFS_BUFSIZE=32 ./modfs

and the log content can be displayed later using

showshringbuf modfs

You can try to translate #190 for further information regarding this debug option. Please provide the debug output next time ... I've even no idea, why the unpack process fails and the debug output should reveal the reason.

If you should get stuck again while considering the notes above, send me a personal message and I'll give you an e-mail address to arrange an IRC session for quicker responses. I'd like to keep the development of your problems up to a solution out of this thread, we can add a summary later, if we think it could be useful.

 

[Virgus]

Hello Peter,
I'm sorry I overwrite my last post hoping that nobody read it at that time of the night.

But you read it and replied and I thank you for that as you always provide precious informations.
Having changed my last post will result in apparent incoherence in our exchange and I'm sorry for the future readers of this forum.

Summarizing, after the problems I had, at the very end I tried re-reading your first post via the google translator and got aware of your instructions for uncompressing and launching the script. It just hung because I was launching the script from my usb key (without knowing the partitions requirements you just pointed out).

Your replies to my questions + your readme file constitute a complete step-by-step tutorial to FB7490 modding. With some time more I'd love to learn more about this (and add the packets I need).

AVM should pay you for what you're doing, as you're keeping some of its customers "on board". The reason why many of us are fond of FritzBox is because we can mod it, but AVM with this recent policy has made things harder for those of us who are not skilled enough to do what you can do.

Thanks for sharing your knowledge, experience and time with me and everybody else,
V.

PS As you suggest, for the next steps I'll contact you in PM, before writing to this thread and avoiding it grows too much.

 

[Virgus]

Hello Peter,
I'd like to share with all the others that I found compiled packages for mips and mipsel architectures here: http://www.fritzmod.net
I have finally my ssh back!

Now I'm trying to configure the new rc.user file. I'll post my questions in PM as agreed.

Cheers,
V.

 

[PeterPawn]

An die modfs-Benutzer: Bitte die heutige Änderung in #1 beachten, ich stelle meine Aktivitäten im IPPF ein - Fragen/Probleme zu modfs künftig nur noch über die in #1 "umschriebene" E-Mail-Adresse. Sollte jemand noch Nachfragen zu anderen von mir veröffentlichten Skripten haben, geht das (sparsam) auch über diese Adresse, aber bitte tatsächlich nicht übertreiben. Nachdem ich den Empfang von PM schon abschalten mußte (oder wollte), stehe ich trotzdem noch gerne Rede und Antwort, aber nicht mehr für Fragen "Was soll ich machen?" zur Verfügung, sondern für Antworten auf "Ich mache das und das, aber es klappt nicht ... wo liegt mein Fehler?". Diesen "Anspruch" meinerseits bitte auch beim Schreiben von E-Mails im Hinterkopf behalten ... danke.

 

[andiling]

Als stiller, interessierter Mitleser kann man künftig woanders die Entwicklung verfolgen?

 

[eisbaerin]

Da ich mich hier aus dem IPPF zurückziehen will

Och, schade. Ich habe mich immer auf Deine Beiträge gefreut!
Ohne Dich hätten wir hier einige Probleme nicht gelöst.

Ganz zurückziehen oder nur teilweise?
Teilweise, kann ich gut verstehen.
Ich habe nie verstanden, warum Du auf so viele niveaulose Fragen antwortest.
Das hast Du nicht nötig!

 

[koyaanisqatsi]

Ja, toll.

Wieder einer weniger der mich korrigiert wenn ich Blödsinn schreibe.

Ich halt jetzt einfach mal die Luft an und erwarte eine Korrektur in Post #333*


* Schnappszahl! Ich darf mir was wünschen

 

[qwertz.asdfgh]

... ich stelle meine Aktivitäten im IPPF ein ... Nachdem ich den Empfang von PM schon abschalten mußte

Auch ich hoffe, dass es sich lediglich um einen teilweisen Rückzug deinerseits handelt.

Da eine PN nicht mehr möglich ist "missbrauche" ich mal diesen Thread für meine Mitteilung bzw. Bitte, nur falls ich bzw. wir dich nicht umstimmen können und du dich tatsächlich komplett zurückziehen möchtest. Und zwar wäre es sehr schön wenn du dein Account hier nicht löschen lässt, das würde die Suche nach einigen informativen Beiträgen von dir sehr erschweren wenn man deinen Benutzernamen nicht mehr als Stichwort benutzen könnte.

Aber ich hoffe natürlich dennoch, dass es soweit (kompletter Rückzug) nicht kommen wird. Z.B. ein kleiner Beitrag bzw. "Lebenszeichen" von dir pro Monat würde evtl. schon reichen.

 

[PeterPawn]

Q: Wie geht es weiter?
A: Ich will ja nicht komplett die Beschäftigung mit der FRITZ!Box einstellen, ich werde nur hier praktisch nicht mehr antworten (das hat mehrere Ursachen, die ich nicht einzeln diskutieren will) und das halte ich selbst nur durch, wenn ich keinen Account mehr habe oder (wenn ich die Anregung von qwertz.asdfgh berücksichtige) keinen Zugriff mehr auf diesen Account habe. Ansonsten fehlt mir die "Selbstdisziplin", ich merke das immer dann, wenn es mich reizen würde, im Freetz-Trac wieder etwas zu schreiben.

Q: Was wird aus modfs?
A: Die Pläne für NOR-Boxen sind offiziell begraben, es wird aber (hoffentlich bald) eine Version von modfs in Form eines Pseudo-Images geben, das dann neben dem Skript für das Modifizieren an sich auch eine etwas größere Kollektion an zusätzlichen Skripten enthält und den gesonderten Telnet-Start dadurch überflüssig macht, daß dort gleich "ShellInABox" für HTTPS-Zugriffe enthalten ist.

Eines der Skripte wird dann auch die Möglichkeit (im Moment immer noch für das alte GUI, wie weit und wie schnell das an das neue angepaßt werden kann, weiß ich noch nicht) bieten, diese Boxen um "dynamische Pakete" zu erweitern. Auf der Startseite des alten GUI sieht das im Moment so aus:
Anhang anzeigen 84312
Am Ende ist das auch nichts weiter als ein Framework aus diversen Shell-Skripten, das sich an verschiedenen Stellen in die originalen AVM-Skripte hängt und dann eben bei definierten Events aufgerufen wird und am Framework angemeldete Erweiterungen mit entsprechenden Aufrufen über diese Ereignisse informiert. Das "Einklinken" steht in Form eines "modscripts" bereit (06.30 getestet, neues GUI nicht, in den Framework-Dateien unter "doc" abgelegt).

Da gehört natürlich noch jede Menge Skript-Code in /wrapper/custom dazu und auch einige andere Dateien, als "brauchbares Paket" gibt es (zumindest in einer Form, die man weitergeben könnte) bisher nur "ShellInABox" (wegen des o.a. Pseudo-Images). Das betreffende Paket kann man sich als "proof-of-concept" unter http://yourfritz.de/framework/yf_siab.tar ansehen, im tar-Archiv ist neben der Konfgurationsdatei noch ein SquashFS-Image mit den anderen Dateien enthalten. Die enthaltenen Binärdateien basieren alle auf einem Patch für das in Freetz enthaltene ShellInABox-Paket, den man unter der URL http://yourfritz.de/framework/shellinabox/shellinabox_from_freetz.patch findet (damit ist dann auch wieder der GPL Genüge getan).

Die Basisdateien des Frameworks (falls tatsächlich mal jemand hineinsehen will, ich suche praktisch händeringend nach Kritikern, die sich damit auskennen und einige Entscheidungen meinerseits auch mal hinterfragen können) finden sich unter http://yourfritz.de/framework/framework.tar - nicht zuviel erwarten, ist ein älterer Stand (fast zwei Monate) und "work in progress". Im Moment auf die 7490 mit dem "Restspeicher" in den Wrapper-Partitionen ausgelegt, da ist auch bei den anderen NAND-Modellen noch etwas Platz übrig (im Gegensatz zu /var/media/ftp bei Boxen mit 128 MB NAND-Flash gesamt), wo man Framework und Zusatzpakete dann speichern kann - vor allem hat das den Vorteil (ggf. auch den Nachteil), daß es zwei Versionen auf der Box geben kann, in jeder Systemversion eine eigene. Wie gesagt, einige Entscheidungen würde ich zu gerne diskutieren, aber nicht mehr hier im IPPF ... das auf dem Server liegende Archiv des Frameworks enthält auch den kompletten GUI-Teil nicht (auch das SiaB-Paket hat keine GUI-Files), da will/muß ich erst noch einiges klären, bevor ich das weitergeben kann. Im Moment enthält das bei mir eben auch modifizierte AVM-Files, die kann ich nur als "diff" zum ursprünglichen File in vollem Umfang weitergeben.

Nur mal als Beispiel, wie das "weiter hinten" aussieht:
Anhang anzeigen 84310
Das AVM-Logo ist (nur falls es jemanden irritiert) nicht Bestandteil der Framework-Dateien, es wird vom AVM-Server geladen und kommt ohne Internetverbindung aus dem Cache oder gar nicht:
Anhang anzeigen 84311

Für dieses Projekt werde ich dann irgendwann wohl doch in den sauren Apfel beißen und eine passende Webpräsenz unter yourfritz.de einrichten. Schon alleine die Notwendigkeit einer "Bedienungsanleitung" und einer "trusted source" für Erweiterungspakete macht das praktisch unumgänglich. Dort wird dann sicherlich der Fokus zwar auf YourFritz liegen, aber auch "modfs" als "Starter" für die Modifikationen wird weiterhin eine Rolle spielen.

 

[qwertz.asdfgh]

und das halte ich selbst nur durch, wenn ich keinen Account mehr habe oder (wenn ich die Anregung von qwertz.asdfgh berücksichtige) keinen Zugriff mehr auf diesen Account habe.

Ist zwar schade aber vielleicht könnte man den Account (dauerhaft) sperren anstatt löschen so wie damals bei betateil****, natürlich diesmal einvernehmlich mit der Forenleitung.

 

[PeterPawn]

@qwertz.asdfgh:
Ich lasse mir etwas einfallen ... vielleicht ändere ich meine Meinung auch noch in Teilen, weil ich festgestellt habe, daß ohne eigenen Account auch das (passive) Lesen praktisch unmöglich ist. Man kann schlicht nicht mehr "neue Beiträge" sinnvoll lesen ... oder man macht das mindestens 1x in 24h, weil es für diese Beiträge eine "Ansicht" gibt. Ansonsten braucht es eben das Konto auch für die Verwaltung des letzten Besuchs - das mußte ich beim Trac nicht berücksichtigen.

Mal sehen ... vielleicht lasse ich mir ja auch die Schreibrechte entziehen, ich "prüfe" noch meine Optionen. Aber damit ist es jetzt auch gut zu diesem Thema ...