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

@muellmann4, hattest du einen USB-Stick mit einem SWAP verwendet, Größe mind. 512 MB? Wenn nicht, dann hast du Glück gehabt, dass modfs überhaupt lief.
 
Hallo jono! Nein - hatte ich nicht. Soweit ich verstanden hatte, ist dies auch nur nötig um 7.01 drauf zu bekommen und hat mit meinem "Problem" bzw. meiner "Unwissenheit" hier Telnet wieder zu bekommen erstmal Nichts zu tun. Denn ich wollte dann schon am Ende des Tages einen USB-Stick mit meinen Daten für den Mediaserver anstecken...
Nun: 7.01 ist drauf... aber wie komme ich an Telnet?
 
ShellInABox (SIAB)?
 
? Also ich bin vor bestimmt 1,5 wenn nicht schon vor 2 Jahren mal den Weg über ShellInABox gegangen - aber danach immer nur über den Weg des "normalen" Telnet, da ich die Webseitenzugriffe nicht nur nicht mag sondern auch den Weg Telnet schlicht ein- und auszuschalten (immer wenn es ich benötige) zu können immer sehr geschätzt habe.
Davon einmal abgesehen - würden denn bei 7.01 immer noch ein inject von ShellInABox funktionieren? [sorry - habe mich damit schon ewig nicht mehr auseinandergesetzt]
 
90 Minuten kann "modfs" aber fast nicht brauchen, wenn die Box technisch in Ordnung ist.

Ohne spezielle Parameter beim Aufruf wird eben (absichtlich) kein Arbeitsverzeichnis mehr im NAS-Flash verwendet (habe ich in #1494 beschrieben) - damit wird aber die Geschwindigkeit des verwendeten USB-Speichers wichtiger und wer hier mit einem USB-Adapter für µSD-Karten mit sehr geringer Schreibrate arbeitet, der wartet schon beim Entpacken der Firmware praktisch endlos (um mal ein Beispiel zu nennen). Wenn das dann auch noch ein USB-Volume mit dem falschen Dateisystem ist und der ext3-Container ausgepackt werden muß, dann geht das allerdings richtig in den Keller ... nur ist das auch die Schuld des Benutzers und daran kann "modfs" nichts ändern, der Benutzer aber sehr wohl.

-----------------------------------------------------------------------------------------------------------

Ein vernünftiger USB-Stick mit akzeptabler Schreibrate und Platz für den Swap-Space (am besten als Partition, aber wie das mit einer Datei auch ginge, habe ich kürzlich (innerhalb der letzten 3 Monate) noch einmal ausführlich gezeigt) ist Grundvoraussetzung für die Benutzung von "modfs" ... dabei spielt es auch gar keine Rolle, von welcher Version man auf welche aktualisieren will. Schon um diese Diskussionen gar nicht erst aufkommen zu lassen, gilt das als "Faustregel": Kein Swap-Space, kein "modfs".

Funktioniert es trotzdem, ist das pures Glück und kann von so vielen Umständen abhängen (weil die AVM-Firmware eben auch einen unterschiedlichen Speicherbedarf im RAM hat, je nachdem, was man von den Funktionen alles nutzt), daß man das bitte nicht verallgemeinern sollte und selbst bei der eigenen Box kann es beim nächsten Versuch problemlos schiefgehen, wenn es eben noch funktioniert hat.

Ich bin jedenfalls nicht wirklich bereit, mich mit Fehlfunktionen zu befassen, die in "Abwesenheit" von Swap-Space auftreten ... und ich will noch einmal ausdrücklich an die Debug-Ausgabe erinnern, die Voraussetzung für das Eingrenzen von Fehlern ist, weil "raten" eher suboptimal ist als Strategie bei der Fehlersuche und nur unnötig Zeit kostet, selbst wenn man ggf. richtig läge.

-----------------------------------------------------------------------------------------------------------

Der Shell-Zugriff per "telnet" braucht zwei Faktoren ... einmal den Symlink unter "/usr/sbin/telnetd" für den Daemon, wenn man die AVM-BusyBox verwendet, in der die Existenz dieses Symlinks durch einen zusätzlichen Patch geprüft wird - EDIT: dieser Symlink wird mit "mod_telnet_enable" erstellt.

Die andere Voraussetzung ist es, daß jemand diesen Daemon dann auch startet ... und das macht die AVM-Firmware ab Labor 06.98 nicht mehr, wenn man nichts weiter ändert.

Also gibt es drei Möglichkeiten, diesen Start dennoch ausführen zu lassen:
  • man startet den "telnetd" einfach selbst an einer anderen Stelle (Nachteil ist, daß der dann immer aktiv ist), dafür gibt es den Patch "mod_telnet_start", den man aber erst selbst aktivieren muß, weil er sonst gar nicht angeboten wird - wie das über die Dateirechte oder eine "custom_modscripts"-Datei funktioniert, habe ich mehrfach beschrieben
  • man verwendet einen anderen Telefon-Code für das Starten und Stoppen des "telnetd", dafür gibt es den Patch "mod_telnet_start_as_dtrace" - auch der ist deaktiviert und muß erst vom Benutzer passend aktiviert werden
  • man benutzt den "telefon"-Daemon im "privaten Modus", der mit dem "mod_enable_calllog" eingeschaltet wird - hier ist der Start des "telnetd" und die Verfügbarkeit der Telefon-Codes zu dessen Steuerung dann eher eine Nebenwirkung des "privaten Modus" und es gibt zumindest einen Nachteil ... der Inhalt der "/var/flash/calllog" wird bei jedem eingehenden Anruf ausgeführt und wenn man diese Datei (wie ich) gerne mal für andere Zwecke verwendet (weil die AVM-Firmware sie ex- und importiert und sie ansonsten nicht weiter genutzt wird, wenn der "private Modus" nicht aktiv ist), dann kann das zu Unverträglichkeiten führen
Wobei die "drei Möglichkeiten" sich nur auf das beziehen, was von "modfs" selbst auch angeboten wird ... es gibt natürlich noch jede Menge anderer Möglichkeiten. Eine Zeile für den "telnetd" in der "/etc/inetd.conf" (die per Symlink nach "/var/tmp/inetd.conf" beschreibbar ist) wäre auch eine "übliche" Lösung, wobei das spezielle Parameter beim Aufruf des "telnetd" braucht.
 
Zuletzt bearbeitet:
Hallo,

ich brächte bitte euer Hilfe/Rat.
Ich hab die FB 7362SL per modfs auf die 7.01 geupdatet.
Soweit so gut, einziges Problem das ich aktuell habe ist das der integrierte gui_bootmanager nicht angezeigt wird.
Unter "System->Sicherung->Neustart" steht hier

Code:
Sie können hier die FRITZ!Box neu starten.
Hinweis:
Beim Neustart werden die Ereignismeldungen gelöscht. Alle Einstellungen der FRITZ!Box bleiben erhalten.
sh: /usr/bin/gui_bootmanager: Permission denied

Statt das die Auswahl des zu-bootenden Systems angezeigt wird
Die Berechtigung kann ich nicht ändern da das Filesystem Read-Only ist.
Kann ich dieses irgendwie kurzfristig RW mounten um die Berechtigungen anzupassen?
07-10-_2018_16-18-11.jpg

---------------EDIT-----------------
habs selber gelöst, handisch vor dem flashen die Berechtigung korrigiert :)
07-10-_2018_16-18-11.jpg


07-10-_2018_16-18-11.jpg

07-10-_2018_16-18-11.jpg
 
Zuletzt bearbeitet:
@muellmann4
Code:
mkdir -p /var/mod;cd /var/mod;wget -qO- http://yourfritz.de/modfs.tgz | gunzip -c | tar x
lädt das "alte" modfs.tgz in der "modfs_version=0.4.6-280220180003" herunter was imho mit der 7.01 nicht klarkommt.

Persönlich bin ich zu blond herauszufinden via Browser http://yourfritz.de auf welche Version da verlinkt wird und wie diese Version wohl korrekt heissen mag.
Code:
wget -qO- http://yourfritz.de/modfs-0.5.0-beta.tgz ... modfs-master

Btw. schlägt der Wechsel zwischen 6.93<->7.01 via GUI-Bootauswahl dahingehend fehl, dass die Internetverbindung (hier WLAN-Repeater->WLAN-Master via 5GHz-Netz) fehlt. Ich muss stets erst das 5GHz-Netz neu suchen lassen um die Internet-Verbindung neu aufbauen zu können. Ähnliches wurde ja auch für DSL-Verbindung berichtet. Eigentlich sollten die Einstellungen im TFFS ja für beide Partitionen gelten.
LG
Edit:
Bingo @freshgodfather
upload_2018-10-7_18-26-37.png

Ich hatte Dein Post nicht richtig interpretiert :D Hast Du das Packen mit dem grossen "Q" unterbrochen und dann in dem Auspackverzeichnis die Rechte geändert? Und wie lässt man das script dann zwecks Packen und flashen und aktivieren der alternativen Partition weiterlaufen?

//edit by stoney: Bild geschrumpft
 
Zuletzt bearbeitet von einem Moderator:
Die falschen Permissions für /usr/bin/gui_bootmanager sind das Ergebnis des Einpackens ... da ich die bei mir eigentlich schon mit der richtigen UID/GID gespeichert habe in "files", habe ich auf die zusätzlichen "chown"- und "chmod"-Aufrufe verzichtet und wollte mittels "cp -a" eigentlich die Attribute alle mitkopieren. Nur klappt das halt nicht, wenn schon die Quelle keine "x-Flags" mehr hat ... vermutlich war auch hier wieder "git" Schuld beim Einchecken des "gui_bootmanager"-Files im "modfs"-Repo. Ich habe das "modscript" für den Boot-Manager entsprechend ergänzt ... nicht nur um das explizite Setzen der Attribute, sondern auch um die Prüfung im "postcheck", daß Owner und Attribute wie erwartet gesetzt sind. Allerdings ist diese Änderung noch ungetestet ... manchmal hat man ja auch Tomaten auf den Augen bei einer Änderung. Also muß auch das noch getestet werden.

-------------------------------------------------------------------------------------------------------

Beim Modifizieren einer 07.01 (bzw. 06.98-Labor) von einer früheren Version aus, sollte die alte Version (in Grenzen, weil nicht alle Patches funktionieren) durchaus arbeiten können ... das ist dieselbe Situation, wie sie bis zum Erscheinen des 07.01-Release bestand.

In der Beta sind geänderte Patches enthalten, die u.a. auch Änderungen in der 07.01 berücksichtigen und damit beim Modifizieren der 07.01 auch ein besseres Ergebnis liefern ... man muß halt immer zwischen dem Framework (das ist das "modfs"-Skript mit dem Kram drumherum, der nicht im "modscripts"-Verzeichnis steht) und den eigentlichen Patches (das sind dann die Skripte in "modscripts") unterscheiden. Wenn ich die in einer Datei zusammenpacke, ist das nur für größere Bequemlichkeit beim Benutzen ... rein theoretisch besteht da kein direkter Zusammenhang und für das "modfs"-Paket an sich ist es wichtig, daß es die Plattform unterstützt, auf der es ausgeführt wird, während es für die Patches wichtiger ist, daß sie die Version des Zielsystems (also die zu modifizierende Version) unterstützen. Da das zwei Paar Schuhe sind, kann man mit "besser unterstützt" nur schwer argumentieren.

-------------------------------------------------------------------------------------------------------

Ich kann aber gerne den "Beta-Status" für die 0.5.0 aufheben und von "modfs.tgz" dahin verlinken ... bisher war ich noch nicht der Ansicht, daß ich "fertig" wäre. Aber ich kann auch einfach eine Version dazwischen schieben ... wenn es keine größeren Probleme mit der "Beta" bisher gab. Dann wandert die "Installation" als signiertes Image halt in die nächste Versionsnummer.

Ich selbst habe damit allerdings in den vergangenen zwei Wochen bestimmt 30-40x sowohl die 06.93 als auch die 07.01 für die 7490 modifiziert (wenn auch nicht jede dieser Modifikationen am Ende installiert wurde) und dabei keine weiteren Probleme mit der Beta gefunden (das Permissions-Problem ist inzwischen gelöst, s.o.) bzw. habe die dann gleich entsprechend gefixt.

Dabei habe ich aber auch festgestellt, daß es bei mir keinerlei Probleme bereitet, zwischen einer 07.01 und einer 06.93 hin und her zu springen (auch die verwendete Konfiguration macht nicht wirklich Probleme), allerdings läuft die Box als LAN1-Router. Auch der Wechsel zwischen der deutschen und der internationalen Version (der 07.01) klappt problemlos - wenn ich das Branding fest setzen lasse, sogar auf der 7580 (auch wenn die von "modfs" nicht direkt unterstützt wird, geht es mir hier um den Boot-Manager).

Wobei man natürlich auch davon ausgehen kann, daß bei allem, was mit WLAN und Mesh in Verbindung zu bringen ist, die Unterschiede zwischen 06.93 und 07.01 ausreichend groß sind, daß ein nahtloser Wechsel eben nicht möglich ist ... solange es "nur" die normalen WLAN-Funktionen betrifft, ist das aber auch kein Problem, zumindest nicht bei mir hier.

Wenn niemand mehr größere Probleme berichtet, gibt's die 0.5.0-beta (in der Pause zwischen den beiden NFL-Spielen) nachher noch als "Release" ... aber damit wäre dann die Auslieferung der 0.4.6 über "yourfritz.de" auch Geschichte und jeder, der die ältere Version haben will (die für Boxen ohne 07.0x ja auch noch "gängig" wäre), müßte sie sich selbst aus dem älteren Stand im Repo zusammenstellen - daß bzw. warum ich nur noch eine einzige Version (abgesehen von der Beta für die nächste) über "yourfritz.de" bereitstelle, habe ich schon früher erläutert.
 
Da keine weiteren Fehler berichtet wurden, ist ab sofort die Version 0.5.0 aktiv und als "modfs.tgz" verlinkt. Die ältere 0.4.6 ist damit obsolet und müßte bei Bedarf aus dem "modfs"-Repo selbst zusammengestellt werden (am richtigen Commit dann natürlich).

Gegenüber der Beta-Version hat dieses Release noch folgende Änderungen erfahren:

Es wird jetzt getestet, ob mind. 256 MB Swap-Space verfügbar sind - ist das nicht der Fall, wird die Ausführung abgebrochen. Wer diese Prüfung absichtlich übergehen und trotzdem keinen Swap-Space bereitstellen will (dann aber bitte auch nicht mit entsprechenden Fehlerberichten hier auflaufen - zur Ausführung ohne Swap-Space steht weiter oben meine Warnung), der muß sicherstellen, daß für das Skript die Environment-Variable
Code:
MODFS_WITHOUT_SWAP=i_am_sure
gesetzt ist. Man kann die Prüfung also übergehen, aber man sollte es nicht tun.

Beim Start von "modfs" wird versucht, anhand der Kernel-Version des Host-Systems die passenden Binärdateien zu finden und - wenn die vorhanden sind und nicht mit den aktuell verlinkten übereinstimmen - den Link im "bin"-Unterverzeichnis von "modfs" entsprechend anzupassen. Damit sollten auf einer 07.01 als Host für "modfs" auch die Dateien für diese Version genutzt werden - selbst wenn die eigentlich alle statisch gelinkt sein sollten.

Der Abbruch vor dem Einpacken unter Beibehalten der modifizierten Dateistruktur ist auch mit der Environment-Variablen "MODFS_ABORT_BEFORE_PACK=Q" steuerbar.

--------------------------------------------------------------------------------------------------------------

Auch wenn sich die Frage nicht an mich richtete ... wie man die Dateistruktur vor dem Einpacken noch zusätzlich modifizieren kann, habe ich hier vor gar nicht soo langer Zeit noch einmal ausgeführt: https://www.ip-phone-forum.de/threads/modfs-squashfs-image-avm-firmware-ändern-für-nand-basierte-fritz-boxen.273304/page-73#post-2295245

--------------------------------------------------------------------------------------------------------------

Weiter geht es jetzt mit 0.5.1-beta, wenn jemand neue Versionen testen möchte. Ich werde das Bereitstellen neuer Beta-Versionen dann weiterhin hier ankündigen.

--------------------------------------------------------------------------------------------------------------

EDIT:
Ich habe mal die aktuellen Ausführungszeiten von "modfs" (scharf und "mit allem") auf (m)einer 7490 gemessen. Dabei kommt eine ältere PATA-HDD (WD Scorpio, WD2500BEVE-00WZT0) in einem USB2-Gehäuse mit Prolific-Wandler-Chip (067b:2506) zum Einsatz, die neben einer 4 GB Swap-Partition noch zwei Partitionen mit jeweils einem ext3-Dateisystem enthält. Als Arbeitsverzeichnis wird eines dieser Volumes benutzt. Das "modfs"-Verzeichnis mit dem Inhalt des Archivs von yourfritz.de befindet sich auf der anderen ext3-Partition.

Die gesamte Ausführung (weitgehend automatisch, also nur in sehr geringem Maße von Reaktionszeiten bei Fragen beeinflußt) dauerte keine 7' 15" - das Packen brauchte alleine schon 6' 10" davon.

Welche von mehreren, entsprechend ungünstigeren Bedingungen jetzt wieviel Zeit zusätzlich kostet (langsamerer USB-Speicher bei Schreibzugriffen, falsches Dateisystem), weiß ich auch nicht ... aber die Scorpio ist nun auch nicht die schnellste denkbare HDD, erst recht nicht mit dem Prolific-Wandler mit USB2. Aber 90 Minuten sind dann doch schon sehr heftig und mir fehlt etwas die Phantasie, wo die Zeit bleiben sollte. Das Debug-Protokoll ist aber auch hier hilfreich ... es enthält ja auch für jeden Eintrag eine Uhrzeit und so kann man zumindest mal sehen, wo die größten Lücken zwischen zwei Einträgen auftauchen:
Code:
2018-10-08 09:33:14.717 - progress: mode=1, msg=Packen des neuen root-Dateisystems ...
2018-10-08 09:33:14.736 - run_spinner: dir=/var/media/ftp/system/1538983933, command=pack_squashfs /var/media/ftp/system/1538983933 /var/media/ftp/system/1538983933/newroot.squashfs 0 65536 4
2018-10-08 09:33:14.767 - pack_squashfs: using SquashFS version 4
2018-10-08 09:33:14.801 - sq_mksquashfs: /var/media/ftp/YourFritz/modfs/bin/185/mksquashfs4 squashfs-root /var/media/ftp/system/1538983933/newroot.squashfs -info -b 65536 -force-uid 0 -force-gid 0
2018-10-08 09:39:21.731 - sq_mksquashfs: exiting, rc=0
2018-10-08 09:39:21.749 - pack_squashfs: exiting, rc=0
2018-10-08 09:39:21.773 - run_spinner: exiting, rc=0
2018-10-08 09:39:21.821 - progress: mode=3, msg= OK
2018-10-08 09:39:21.839 - modfs: packing done, rc=0
 
Zuletzt bearbeitet:
  • Like
Reaktionen: TomTomNavigator
Bei mir dauerte das Packen von modfs mit zusätzlichem Link im Dateisystem ca. 7:35 min, USBStick 3.0 am seitlichen USB-Anschluss, auch auf 3.0 gestellt, 2 GB SWAP.
Der anschließende Neustart der FB 7490 kommt auf knapp 5:45 min.
!!!Danke für die Super Arbeit!!! Alle Fragen liefen problemlos durch.

Edit: gestoppte Zeiten verwechselt, jetzt korrigiert.
 
Zuletzt bearbeitet:
So... ich habe es hinbekommen...
Was war mein Fehler?
Ich hatte gedacht, dass "http://yourfritz.de/modfs.tgz" bereits die verwendbare Version für Fritz!OS 7.01 richtig wäre - was sie nicht war.
[Vielen Dank für den indirekten Hinweis von PeterPawn: "Da keine weiteren Fehler berichtet wurden, ist ab sofort die Version 0.5.0 aktiv und als "modfs.tgz" verlinkt."]
Ich musste also das File neu laden - bzw. jetzt (nach der Umstellung von PeterPawn) funktionierte ja dann auch das ursprüngliche:
mkdir -p /var/mod;cd /var/mod;wget -qO- http://yourfritz.de/modfs.tgz | gunzip -c | tar x
Nächste Hürde dann die Aktion mit dem Swap-File... Ext3 - USB-Stick wurde von der FirtzBox 7940 verweigert mit "unbekanntes Filesystem" - mag aber daran liegen, dass das Tool mit dem ich den Stick an meinem Windows-PC formatiert habe kein "echtes" Ext3 schreibt / formatiert.
Mit Ext2 - Formatierung stand ich vor dem schon beschriebenen Problem des "schreibgeschützt" - aber immerhin erkannte die Box den Stick ordentlich.
Dann hatte ich keine Lust mehr auf Ext2 und Ext3 und habe den Stick schlicht unter Windows 10 mit FAT32 formatiert...
In der Box wurde er erkannt und mit FAT eingebunden.
Dann: per Telnet auf der Box...
dd if=/dev/zero of=/var/media/ftp/USBDISK3-0-01/swapfile bs=1024 count=327680
mkswap /var/media/ftp/USBDISK3-0-01/swapfile
swapon /var/media/ftp/USBDISK3-0-01/swapfile
free [nur zur Kontrolle]
und schon hatte ich ein ausreichend großes Swapfile um über die von PeterPawn eingebundene Hürde zu überspringen...
mkdir -p /var/mod;cd /var/mod;wget -qO- http://yourfritz.de/modfs.tgz | gunzip -c | tar x
lief durch und diesmal dauerte es noch ganze 20 Minuten bis die Box mit 7.01 fertig da stand.
Danach konnte ich den USB-Stick mit dem Swapfile auch wieder abziehen - den benötige ich ja nur beim nächsten Update wieder...
Kurzer Test noch:
"Telnet_enable" (#96*7*) - funktioniert!
"Telnet_disable" (#96*8*) - funktioniert!

Ich denke damit kann ich wieder alles machen was ich benötige.
[Irgendwie war ich zwar der Meinung dass statt #96*7* und #96*8* jetzt zwar #97*3* und #97*2* genutzt werden sollten - die blieben aber ohne Funktion und die alten Einträge in meinem Telefonbuch funktionierten weiterhin - egal - geht!]
[Unklar ist mir noch, warum ich mit der alten modfs.tgz - die ja wohl dann für 06.93 war (oder so) - recht problemlos (jedenfalls ohne Swapfile) - wenn auch ohne funktionierendes Telnet - wenn auch mit recht langer Installationsdauer - auf 7.01 gekommen bin; aber gut - man muss nicht alles verstehen.]
Allen die eine Idee geliefert haben um soweit zu kommen: HERZLICHEN DANK!
 
Zuletzt bearbeitet:
Nächste Hürde dann die Aktion mit dem Swap-File... Ext3 - USB-Stick wurde von der FirtzBox 7940 verweigert mit "unbekanntes Filesystem" - mag aber daran liegen, dass das Tool mit dem ich den Stick an meinem Windows-PC formatiert habe kein "echtes" Ext3 schreibt / formatiert.
Ich nutze das kostenlos-Tool Partition-Wizard was problemlos mit USB-Sticks extX und swap erstellen kann. Als Stick nutze ich seit modfs-Anfangszeiten Intenso-Microline-16GB-Sticks da sie sowohl hinten alsauch seitlich über den Rand nicht hinausragen. Bei 2GB SWAP und 8GB ext3 benötigt das aktuelle script hier ~5Min zum Einpacken wobei das Lesen der Choices nebst Inhalt länger gedauert hat, bis man sich entschieden hat ;)
Hier nach dem Wechsel zum alten 6.93 nach dem Reboot erstmals "nur" die Willkommens-Nachricht "Erfolgreich Installiert" und der "AVM-Benachrichtigungsmaske" und endlich eine korrekte Übernahme der Internetverbindungseinstellung (hier WLAN-Repeater via 5GHz das siehe Anlage nicht existent aber verbunden) wobei die erste Abfrage ANNEX A/B diesmal fehlte.
LG
 

Anhänge

  • Screen Shot 10-08-18 at 02.18 PM.JPG
    Screen Shot 10-08-18 at 02.18 PM.JPG
    91.9 KB · Aufrufe: 31
Der "Zwang" zum Swap-Space resultiert einfach daraus, daß (zumindest gefühlt) 3 von 4 hier berichteten Fehlern (zumindest in der Zeit, wo ich nichts Neues hinzugefügt habe) am Ende daran lagen ... mein Hinweis in #1 (inzwischen vom 06.11.2015) wurde entweder ganz offensichtlich nicht gelesen oder nicht ernst genommen und mehr als "nice to have" angesehen.

Damit ist jetzt erst einmal Schluß ... und um jemandem, der das gerne für sich selbst entscheiden möchte, noch eine Wahl zu lassen, gibt es die weiter oben beschriebene Environment-Variable. Aber ich hoffe mal inständig, daß jemand, der sich - entgegen jeder Warnung meinerseits - gegen die Bereitstellung von Swap-Space entscheidet, dann hinterher nicht hier aufschlägt und von seinen Leiden berichtet, wenn er danach auf Nachfrage (wie z.B. in #1561) zugeben muß, daß er gar keinen verwendet.

Ansonsten tritt noch das "permission denied" in den Fällen "gehäuft" auf, wo die Volumes mit "noexec" gemountet wurden und das "modfs"-Paket eben nicht in "/var/mod" entpackt wurde, wie es beschrieben ist. Das ist zwar durchaus auch "erlaubt", aber dann muß man sich eben mit dem Problem auskennen und selbst Hand anlegen, damit das Volume mit "exec"-Option gemountet wird.

So ganz kann ich nämlich (um mal wieder zum Swap-Space zurückzukommen) den Text:
Soweit ich verstanden hatte, ist dies auch nur nötig um 7.01 drauf zu bekommen und hat mit meinem "Problem" bzw. meiner "Unwissenheit" hier Telnet wieder zu bekommen erstmal Nichts zu tun.
nicht nachvollziehen ... noch deutlicher als in #1 (wie gesagt, nach dem 06.11.2015 schauen) kann man (ich) es kaum schreiben, daß es ansonsten Probleme mit dem freien Hauptspeicher (und durchaus auch bei 7490 und 3490, obwohl die den doppelten Hauptspeicher haben im Vergleich zu den anderen Modellen) gibt.

Auch vom Sinn des "mod_swapoff"-Patches habe ich inzwischen oft genug geschrieben ... solange nichts ausgelagert wurde, kann es auch kein Problem mit nicht eingelagertem Speicher geben und trotzdem konnte ich FRITZ!Boxen (gerade auch 7490) oft genug "aufhängen" beim Reboot, wenn Swap-Space vorhanden war und der USB-Stack beim Reboot "rücksichtslos" abgeräumt wurde, während noch Seiten ausgelagert waren, die zu später zu stoppenden Prozessen gehörten.

Immerhin ist diese "Warnung" meinerseits inzwischen auch fast drei Jahre alt und die Firmware hat sich in den drei Jahren schon einigermaßen verändert (und ist gewachsen - weniger vom Umfang der Dateien her, als vielmehr von der "utilization" des Hauptspeichers im Betrieb) ... damals war noch 06.3x "aktuell".
 
  • Like
Reaktionen: TomTomNavigator
Dann hatte ich keine Lust mehr auf Ext2 und Ext3 und habe den Stick schlicht unter Windows 10 mit FAT32 formatiert...

Ich war der Meinung, eine SWAP Partition ist leichter erstellt, als eine Datei.
(ext Partitionen mit Windows Bordmitteln sind ein Kreuz um nicht zu sagen unmöglich)
Die Partition wurde auch ordnungsgemäß eingebunden aber das Verzeichnis zum Entpacken der Firmware konnte nicht erstellt werden.
Ich konnte mit dem Inhalt von "showshringbuf modfs" nicht herausfinden wohin er das Verzeichnis erstellen will, muss aber wohl auf den Stick gehen.
Dann habe ich den Stick auch FAT32 formatiert und das swapfile darauf erstellt.
Damit lief dann auch modfs durch. Die Frage ist, ob es damit evtl. Probleme gibt?
Berechtigungen können auf FAT/FAT32 nicht gesetzt werden...

Irgendwie war ich zwar der Meinung dass statt #96*7* und #96*8* jetzt zwar #97*3* und #97*2* genutzt werden sollten
Da bin ich dann auch noch drüber geflogen.
Ich habe den callog-mod nicht aktiviert und dann ließ sich telnet nicht Aktivieren.

Die Lösung dafür steht in #1565
den Patch "mod_telnet_start_as_dtrace" - auch der ist deaktiviert und muß erst vom Benutzer passend aktiviert werden
Dieser mod bringt die Codes #97*3* und #97*2*

Kann jemand bestätigen, ob/dass der mod_exec_on_usb auch funktioniert?
Obwohl ich den ausgewählt habe, konnte ich nichts auf dem Stick ausführen.
Bis auf Weiteres läuft das jetzt mit einem remount,exec in der debug.cfg
Dann war die Bastelstunde auch wieder vorbei.
 
Kann jemand bestätigen, ob/dass der mod_exec_on_usb auch funktioniert?
Obwohl ich den ausgewählt habe, konnte ich nichts auf dem Stick ausführen.
Bis auf Weiteres läuft das jetzt mit einem remount,exec in der debug.cfg

könntest Du Bitte den Befehl "mount | grep var.media.ftp" nach Reboot eingeben und posten; vorher den Befehl "remount,exec" in der Datei "rc.user" temporär deaktivieren;
dann hat man mehr Diagnose-Inputs.
 
Kann jemand bestätigen, ob/dass der mod_exec_on_usb auch funktioniert?
Bei dem habe ich auch beschrieben, daß (und vor allem warum) er nur für Volumes mit nativen Dateisystemen gilt - zumindest in der Form, die ich "anbiete".

---------------------------------------------------------------------------------------------------------------------------

Man muß seinen USB-Stick auch nicht unter Windows vorbereiten ... das "modfs"-Paket enthält nämlich auch alles andere, was man für das Präparieren des eigenen Sticks benötigen würde:
Code:
root@FB7490:/var/media/ftp/YourFritz/modfs $ ls -la bin/$HWRevision/
drwxr-xr-x    2 1000     1001          4096 Oct  3 20:59 .
drwxrwxr-x    9 1000     1001          4096 Oct  7 20:12 ..
-rw-r--r--    1 1000     1001            10 Aug 14  2017 .gitattributes
lrwxrwxrwx    1 root     root            30 Sep 18 17:12 busybox -> ../common/busybox.34kc.3.10.73
lrwxrwxrwx    1 root     root            37 Sep 18 17:12 busybox.config -> ../common/busybox.config.34kc.3.10.73
lrwxrwxrwx    1 root     root            29 Sep 18 17:12 e2fsck -> ../common/e2fsck.34kc.3.10.73
lrwxrwxrwx    1 root     root            29 Sep 18 17:12 mke2fs -> ../common/mke2fs.34kc.3.10.73
lrwxrwxrwx    1 root     root            34 Sep 18 17:12 mksquashfs3 -> ../common/mksquashfs3.34kc.3.10.73
lrwxrwxrwx    1 root     root            34 Sep 18 17:12 mksquashfs4 -> ../common/mksquashfs4.34kc.3.10.73
lrwxrwxrwx    1 root     root            30 Sep 18 17:12 openssl -> ../common/openssl.34kc.3.10.73
lrwxrwxrwx    1 root     root            33 Sep 18 17:12 unsquashfs3 -> ../common/unsquashfs.34kc.3.10.73
lrwxrwxrwx    1 root     root            33 Sep 18 17:12 unsquashfs4 -> ../common/unsquashfs.34kc.3.10.73
root@FB7490:/var/media/ftp/YourFritz/modfs $
Die BusyBox enthält auch das "fdisk"-Applet und die oben stehenden ext2-Programme (die nun mal auch ext3 und ext4 "können" und nur "e2" heißen - wie immer unter Linux) haben gar keine andere Verwendung im Rahmen von "modfs", als einen USB-Speicher passend vorbereiten zu können.

Hier mal am Beispiel einer 7580 mit "originaler" AVM-Firmware:
Code:
# mkdir /var/mod; wget -O- http://yourfritz.de/modfs.tgz | gunzip -c | tar -C /var/mod -x
Connecting to yourfritz.de (85.214.20.177:80)
-                    100% |*********************************************|  5340k  0:00:00 ETA
# cd /var/mod
# ./bin/$HWRevision/busybox sh
/var/mod #
Zuerst wird das Paket geladen und entpackt (nach /var/mod, weil da die Frage "noexec" oder nicht, keine Rolle spielt) und dann in das Verzeichnis gewechselt, wo jetzt erst mal die Shell der (dazugepackten) BusyBox gestartet wird, damit die dort enthaltenen Applets auch ohne Symlinks gefunden werden. Daß es die neue BusyBox ist, sieht man am Prompt ... die AVM-Version ist ohne die Pfadanzeige beim Prompt übersetzt (die beiden darüber zeigen das schön).

Jetzt kann man sich die vorhandenen Block-Devices anzeigen lassen und zunächst mal ermitteln, welche Pfade zum Stick führen, denn das Einbinden beim Einstecken (oder beim Start) kann man bei der AVM-Firmware nicht unterbinden. Wenn der Stick tatsächlich vollkommen "blank" ist und gar keine Partition enthält (ich habe hier zu Demonstrationszwecken eine 2 GB Mikro-SD-Karte im USB-Adapter genommen, die sind i.d.R. schon mit exFAT oder FAT32 (bei kleinen Kapazitäten wie 2 GB) vorformatiert), dann taucht er hier halt nicht auf und man muß mit "cat /proc/diskstat" suchen, welches Gerät es ist.
Code:
/var/mod # blkid
/dev/sdb5: LABEL="storage" UUID="33132262-834d-41a5-b4eb-59b4266e8789" TYPE="ext3"
/dev/sdb2: LABEL="YourFritz" UUID="ed85d36c-ae21-431f-be3a-41df0884d49a" TYPE="ext3"
/dev/sdb1: TYPE="swap"
/dev/sda1: UUID="563B-7C7E" TYPE="vfat"
/dev/ubi0_3: UUID="64007ccf-f1f2-4fa5-ae5a-99ff51c15ffe" TYPE="ubifs"
/dev/ubi0_1: TYPE="squashfs"
/dev/ubi0_0: TYPE="squashfs"
/var/mod #
Wie gesagt ... es ist eine 7580 und da sehen die Block-Devices etwas anders aus als bei VR9-Boxen, aber hier ist "/dev/sda1" mit der "vfat"-Partition genau die Partition, die wir suchen und daraus leitet sich dann auch ab, daß "/dev/sda" der "USB-Stick" ist, der hier zu benutzen wäre (die anderen sind auf einem anderen USB-Stick, den ich nicht extra abgezogen hatte). Jedenfalls kann man nun mit "fdisk" auf den Stick losgehen, nachdem man sich zuvor davon überzeugt hat, daß er nicht mehr gemountet ist:
Code:
/var/mod # umount /dev/sda1
/var/mod # mount
rootfs on / type rootfs (rw)
/dev/root on / type squashfs (ro,relatime)
devtmpfs on /dev type devtmpfs (rw,relatime,size=216100k,nr_inodes=54025,mode=755)
proc on /proc type proc (rw,relatime)
tmpfs on /var type tmpfs (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
devpts on /dev/pts type devpts (rw,relatime,mode=600)
none on /sys/kernel/debug type debugfs (rw,relatime)
/dev/ubi0_3 on /var/media/ftp type ubifs (rw,sync,noexec,relatime)
debug on /debug type debugfs (rw,relatime)
/dev/sdb2 on /var/media/ftp/YourFritz type ext3 (rw,noexec,relatime,errors=continue,barrier=1,data=writeback)
/dev/sdb5 on /var/media/ftp/storage type ext3 (rw,noexec,relatime,errors=continue,barrier=1,data=writeback)
/var/mod #
Wenn das "umount" nicht funktioniert, weil da noch Dateien unterhalb von "FRITZ" von der Firmware offengehalten werden (z.B. vom "telefon"-Daemon für den AB), dann muß man den eben zuvor über das GUI auswerfen lassen, dann werden diese AVM-Daemons auch entsprechend "abgehängt". EDIT: Weiter unten habe ich auch noch gezeigt, wie man "per Kommando" so ein Volume auch von Hand aushängen lassen kann, ohne selbst "umount" oder das GUI zu benutzen.
Code:
/var/mod # fdisk -u /dev/sda

The number of cylinders for this disk is set to 1882.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
   (e.g., DOS FDISK, OS/2 FDISK)

Command (m for help): p
Disk /dev/sda: 1882 MB, 1973420032 bytes, 3854336 sectors
1882 cylinders, 64 heads, 32 sectors/track
Units: sectors of 1 * 512 = 512 bytes

Device  Boot StartCHS    EndCHS        StartLBA     EndLBA    Sectors  Size Id Type
/dev/sda1 *  1,0,1       857,63,32         2048    3854335    3852288 1881M 83 Linux

Command (m for help): d <=== Löschen der alten Partition
Selected partition 1

Command (m for help): n <=== Anlegen einer Swap-Partition mit 384 MB (siehe Anmerkung weiter unten im Text)
Command action
   e   extended
   p   primary partition (1-4)
p
Partition number (1-4): 1
First sector (32-3854335, default 32):
Using default value 32
Last sector or +size or +sizeM or +sizeK (32-3854335, default 3854335): +384M

Command (m for help): t
Selected partition 1
Hex code (type L to list codes): L

 0 Empty                  1b Hidden Win95 FAT32     9f BSD/OS
 1 FAT12                  1c Hidden W95 FAT32 (LBA) a0 Thinkpad hibernation
 4 FAT16 <32M             1e Hidden W95 FAT16 (LBA) a5 FreeBSD
 5 Extended               3c Part.Magic recovery    a6 OpenBSD
 6 FAT16                  41 PPC PReP Boot          a8 Darwin UFS
 7 HPFS/NTFS              42 SFS                    a9 NetBSD
 a OS/2 Boot Manager      63 GNU HURD or SysV       ab Darwin boot
 b Win95 FAT32            80 Old Minix              b7 BSDI fs
 c Win95 FAT32 (LBA)      81 Minix / old Linux      b8 BSDI swap
 e Win95 FAT16 (LBA)      82 Linux swap             be Solaris boot
 f Win95 Ext'd (LBA)      83 Linux                  eb BeOS fs
11 Hidden FAT12           84 OS/2 hidden C: drive   ee EFI GPT
12 Compaq diagnostics     85 Linux extended         ef EFI (FAT-12/16/32)
14 Hidden FAT16 <32M      86 NTFS volume set        f0 Linux/PA-RISC boot
16 Hidden FAT16           87 NTFS volume set        f2 DOS secondary
17 Hidden HPFS/NTFS       8e Linux LVM              fd Linux raid autodetect
Hex code (type L to list codes): 82
Changed system type of partition 1 to 82 (Linux swap)

Command (m for help): n <=== Anlegen einer weiteren Partition mit dem restlichen Platz auf dem Gerät
Command action
   e   extended
   p   primary partition (1-4)
p
Partition number (1-4): 2
First sector (750033-3854335, default 750033):
Using default value 750033
Last sector or +size or +sizeM or +sizeK (750033-3854335, default 3854335):
Using default value 3854335

Command (m for help): t
Partition number (1-4): 2
Hex code (type L to list codes): 83

Command (m for help): p <=== Anzeige des Ergebnisses
Disk /dev/sda: 1882 MB, 1973420032 bytes, 3854336 sectors
1882 cylinders, 64 heads, 32 sectors/track
Units: sectors of 1 * 512 = 512 bytes

Device  Boot StartCHS    EndCHS        StartLBA     EndLBA    Sectors  Size Id Type
/dev/sda1    0,1,1       366,14,17           32     750032     750001  366M 82 Linux swap
Partition 1 does not end on cylinder boundary
/dev/sda2    366,14,18   1023,63,32      750033    3854335    3104303 1515M 83 Linux

Command (m for help): w <=== Schreiben der Daten auf den Stick
The partition table has been altered.
Calling ioctl() to re-read partition table
fdisk: WARNING: rereading partition table failed, kernel still uses old table: Device or resource busy
/var/mod #
Ich habe hier eine größere Swap-Partition gewählt, weil die Angabe "+384M" wohl mit 10^6 arbeitet und nicht mit 2^20 - damit wäre "+256M" zuwenig gewesen für die "geforderten" 256 MB.

Wenn dann beim Schreiben ähnliche Nachrichten wie oben auftauchen, zieht man den Stick noch einmal ab, wartet eine Minute (damit das FRITZ!OS die alten Infos entsorgen kann) und steckt ihn dann wieder an:
Code:
/var/mod # cat /proc/diskstats
   7       0 loop0 0 0 0 0 0 0 0 0 0 0 0
   7       1 loop1 0 0 0 0 0 0 0 0 0 0 0
  31       0 mtdblock0 0 0 0 0 0 0 0 0 0 0 0
  31       1 mtdblock1 0 0 0 0 0 0 0 0 0 0 0
  31       2 mtdblock2 0 0 0 0 0 0 0 0 0 0 0
  31       3 mtdblock3 0 0 0 0 0 0 0 0 0 0 0
  31       4 mtdblock4 0 0 0 0 0 0 0 0 0 0 0
 254       0 zram0 0 0 0 0 0 0 0 0 0 0 0
  31       5 mtdblock5 838 13235 28146 10724 0 0 0 0 0 10480 10716
  31       6 mtdblock6 0 0 0 0 0 0 0 0 0 0 0
  31       7 mtdblock7 0 0 0 0 0 0 0 0 0 0 0
  31       8 mtdblock8 0 0 0 0 0 0 0 0 0 0 0
   8       0 sda 240 5298 17704 2268 4 0 11 300 0 1400 2560
   8       1 sda1 220 4929 14592 2028 3 0 3 156 0 1148 2176
   8      16 sdb 323 4095 32820 1576 11 2 104 32 0 892 1600
   8      17 sdb1 105 1524 11760 476 1 0 8 8 0 424 484
   8      18 sdb2 90 1142 9850 536 5 1 48 12 0 384 540
   8      19 sdb3 7 5 44 16 0 0 0 0 0 16 16
   8      21 sdb5 92 1286 10498 488 5 1 48 12 0 404 500
/var/mod #
killall: ftpd: no process killed
killall: ftpd: no process killed
Oct  9 13:17:52 rpctrl[13522]: SET(0,start/0)
Oct  9 13:17:53 rpctrl[13530]: GET(0,mstate/0)
Oct  9 13:17:53 rpctrl[13531]: SETLIST(80000018,udev/0)
modprobe: module sd_mod not found in modules.dep
modprobe: module usb-storage not found in modules.dep
Mounting [Generic-USBSDReader-01] to device /dev/sda1...
MOUNT: use blkid to get device /dev/sda1 data
MOUNT: filesystem type is:
MOUNT: unknown filesystem type  on device /dev/sda1
Mounting [Generic-USBSDReader-02] to device /dev/sda2...
MOUNT: use blkid to get device /dev/sda2 data
MOUNT: filesystem type is:
MOUNT: unknown filesystem type  on device /dev/sda2
/var/mod # cat /proc/diskstats
   7       0 loop0 0 0 0 0 0 0 0 0 0 0 0
   7       1 loop1 0 0 0 0 0 0 0 0 0 0 0
  31       0 mtdblock0 0 0 0 0 0 0 0 0 0 0 0
  31       1 mtdblock1 0 0 0 0 0 0 0 0 0 0 0
  31       2 mtdblock2 0 0 0 0 0 0 0 0 0 0 0
  31       3 mtdblock3 0 0 0 0 0 0 0 0 0 0 0
  31       4 mtdblock4 0 0 0 0 0 0 0 0 0 0 0
 254       0 zram0 0 0 0 0 0 0 0 0 0 0 0
  31       5 mtdblock5 838 13235 28146 10724 0 0 0 0 0 10480 10716
  31       6 mtdblock6 0 0 0 0 0 0 0 0 0 0 0
  31       7 mtdblock7 0 0 0 0 0 0 0 0 0 0 0
  31       8 mtdblock8 0 0 0 0 0 0 0 0 0 0 0
   8      16 sdb 323 4095 32820 1576 11 2 104 32 0 892 1600
   8      17 sdb1 105 1524 11760 476 1 0 8 8 0 424 484
   8      18 sdb2 90 1142 9850 536 5 1 48 12 0 384 540
   8      19 sdb3 7 5 44 16 0 0 0 0 0 16 16
   8      21 sdb5 92 1286 10498 488 5 1 48 12 0 404 500
   8       0 sda 299 16711 18928 2980 0 0 0 0 0 984 2968
   8       1 sda1 135 8386 9452 1436 0 0 0 0 0 588 1436
   8       2 sda2 152 8325 9380 1516 0 0 0 0 0 580 1508
/var/mod #
Da ja noch keine Partitionen initialisiert wurden (die Devices dafür waren ja gar nicht vorhanden), kann der Stick hier halt noch nicht eingebunden werden. Wir müssen also jetzt die Dateisysteme passend initialisieren ... dabei ist - wie immer - hohe Aufmerksamkeit Pflicht, damit man tatsächlich die richtigen Devices verwendet. Ich habe hier "/dev/sda1" als neue Swap-Partition und "/dev/sda2" als neue "extX"-Partition ... das kann auf einer anderen Box durchaus auch anders aussehen und statt "sda" irgendetwas anderes im Alphabet sein.
Code:
/var/mod # mkswap /dev/sda1
Setting up swapspace version 1, size = 383996416 bytes
UUID=3786459b-6f2c-4aa9-9f72-b852cb1c7d12
/var/mod # bin/$HWRevision/mke2fs -t ext3 -L YourFritz /dev/sda2
mke2fs 1.42.13 (17-May-2015)
Creating filesystem with 388037 4k blocks and 97152 inodes
Filesystem UUID: bcdd697b-7453-4633-83a4-0479220c653d
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912

Allocating group tables: done
Writing inode tables: done
Creating journal (8192 blocks): done
Writing superblocks and filesystem accounting information: done

/var/mod # blkid
/dev/sda2: LABEL="YourFritz" UUID="bcdd697b-7453-4633-83a4-0479220c653d" TYPE="ext3"
/dev/sda1: UUID="3786459b-6f2c-4aa9-9f72-b852cb1c7d12" TYPE="swap"
/dev/sdb5: LABEL="storage" UUID="33132262-834d-41a5-b4eb-59b4266e8789" TYPE="ext3"
/dev/sdb2: LABEL="YourFritz" UUID="ed85d36c-ae21-431f-be3a-41df0884d49a" TYPE="ext3"
/dev/sdb1: TYPE="swap"
/dev/ubi0_3: UUID="64007ccf-f1f2-4fa5-ae5a-99ff51c15ffe" TYPE="ubifs"
/dev/ubi0_1: TYPE="squashfs"
/dev/ubi0_0: TYPE="squashfs"
/var/mod #
Ich habe hier die ext-Partition als "ext3" formatieren lassen (ein Kompromiß zwischen Journaling und unnötigen Zugriffen) und ihr das Label "YourFritz" verpaßt. Das spielt demnächst noch eine Rolle, wie ein Volume heißt - ich habe allerdings bereits eines mit diesem Namen auf dem anderen Stick und so wird das neue nur mit einem zusätzlichen Suffix vom FRITZ!OS eingebunden werden.

Wer den Stick jetzt nicht noch einmal durch Aus- und Einstecken "frisch" erkennen will, der teilt das einfach dem "udevd" mit, daß er die "add"-Aktionen noch einmal ausführen soll - man muß gar nicht genauer spezifizieren wofür (auch wenn man es könnte):
Code:
/var/mod # udevadm trigger --action=add
/var/mod #
Oct  9 13:27:46 rpctrl[17068]: GET(0,mstate/0)
Oct  9 13:27:46 rpctrl[17069]: SETLIST(80000018,udev/0)
Oct  9 13:27:46 rpctrl[17071]: GET(0,mstate/0)
Oct  9 13:27:46 rpctrl[17076]: SETLIST(80000018,udev/0)
rmdir: '/var/media/ftp/YourFritz': Device or resource busy
[YourFritz] already mounted
Mounting [YourFritz-1] to device /dev/sda2...
MOUNT: use blkid to get device /dev/sda2 data
MOUNT: filesystem type is: ext3
MOUNT:mount -t 'extX' /dev/sda2 /var/media/ftp/YourFritz-1
killall: ftpd: no process killed
Oct  9 13:27:48 tr069starter[17464]: starting ...
2018-10-09 13:27:48 tr069starter[17464]: ready (0sec)
Mounting [Generic-USBSDReader-01] to device /dev/sda1...
MOUNT: use blkid to get device /dev/sda1 data
MOUNT: filesystem type is: swap
MOUNT: try to add swap
MOUNT: swap added
Mounting [SanDisk-UltraFit-01] to device /dev/sdb1...
MOUNT: use blkid to get device /dev/sdb1 data
MOUNT: filesystem type is: swap
MOUNT: try to add swap
swapon: /dev/sdb1: Device or resource busy
MOUNT: swap added
Oct  9 13:27:58 tr069starter[17466]: tr069starter: /var/media/ftp/YourFritz-1/fritzboxconfig.import not found - exit
Jetzt sind die beiden neuen Partitionen auch vom FRITZ!OS akzeptiert worden ... das sieht dann so aus (immer im Hinterkopf behalten, daß ich hier noch einen zweiten Stick benutze):
Code:
/var/mod # cat /proc/swaps
Filename                                Type            Size    Used    Priority
/dev/sdb1                               partition       1953772 0       -1
/dev/sda1                               partition       374996  0       -2
/var/mod # cat /proc/partitions
major minor  #blocks  name

  31        0       8192 mtdblock0
  31        1       1024 mtdblock1
  31        2       4096 mtdblock2
  31        3       8192 mtdblock3
  31        4     502784 mtdblock4
  31        5      45108 mtdblock5
  31        6      45108 mtdblock6
  31        7       2268 mtdblock7
  31        8     391356 mtdblock8
   8       16   30031250 sdb
   8       17    1953776 sdb1
   8       18   15626240 sdb2
   8       19          1 sdb3
   8       21   12450800 sdb5
   8        0    1927168 sda
   8        1     375000 sda1
   8        2    1552151 sda2
/var/mod # df -PT
Filesystem           Type       1024-blocks    Used Available Capacity Mounted on
/dev/root            squashfs       20480     20480         0 100% /
devtmpfs             devtmpfs      216100        96    216004   0% /dev
tmpfs                tmpfs         216252     13240    203012   6% /var
/dev/ubi0_3          ubifs         363820       340    358644   0% /var/media/ftp
/dev/sdb2            ext3        15380880   7022676   7576892  48% /var/media/ftp/YourFritz
/dev/sdb5            ext3        12255400   9185788   2447072  79% /var/media/ftp/storage
/dev/sda2            ext3         1527716     35084   1415028   2% /var/media/ftp/YourFritz-1
/var/mod #
... und der Benutzung des "neuen" USB-Sticks für "modfs" steht nichts mehr im Weg - auch kein "Format-Problem", weil man den Stick mit einem Programm eingerichtet hat, dessen Format das FRITZ!OS ggf. nicht erkennt.

Wer auch noch das "e2fsck" aus dem "modfs"-Paket mal verwenden will, muß halt vorher sicherstellen, daß das FRITZ!OS die Partition nicht mehr in Benutzung hat ... das geht wieder am einfachsten über das Auswerfen im GUI, wobei der Stick dann weiterhin angesteckt bleibt - entfernt man ihn und steckt ihn dann erst wieder an, bindet das FRITZ!OS die Partitionen auch umgehend wieder ein. Will man ein Volume "von Hand" entfernen lassen, ist das etwas komplizierter, weil die AVM-Skripte dafür die USB-Gerätenummer wissen wollen und man die erst auslesen muß (das ginge mit einem anderen Suchbegriff natürlich auch für den Mountpoint, denn der folgt dem Gerätenamen nach einem Doppelpunkt):
Code:
/var/mod # /etc/hotplug/storage umount_usb $(sed -n -e "s|^\([^=]*\)=/dev/sda2.*|\1|p" /var/tmp/mediadevmap)
storage:unmounting /var/media/ftp/YourFritz-1
killall: ftpd: no process killed
/var/mod # cat /var/tmp/mediadevmap
003/002=/dev/sda1:Generic-USBSDReader-01
001/002=/dev/sdb2:YourFritz
001/002=/dev/sdb5:storage
003/003=#removed
/var/mod # bin/$HWRevision/e2fsck -f -v -p /dev/sda2

          11 inodes used (0.01%, out of 97152)
           0 non-contiguous files (0.0%)
           0 non-contiguous directories (0.0%)
             # of inodes with ind/dind/tind blocks: 0/0/0
       14879 blocks used (3.83%, out of 388037)
           0 bad blocks
           1 large file

           0 regular files
           2 directories
           0 character device files
           0 block device files
           0 fifos
           0 links
           0 symbolic links (0 fast symbolic links)
           0 sockets
------------
           2 files
/var/mod #
Für den Aufruf der "zusätzlichen Kommandos" außerhalb der BusyBox im "bin/$HWRevision"-Folder (die Liste ist irgendwo am Beginn dieses Beitrags) muß man halt immer den Pfad mit angeben, weil "/var/mod/bin/$HWRevision" natürlich i.d.R. nicht im Pfad enthalten ist ... außer man setzt es zuvor tatsächlich noch selbst:
Code:
/var/mod # env | grep ^PATH
PATH=/sbin:/usr/sbin:/bin:/usr/bin
/var/mod # export PATH=/var/mod/bin/$HWRevision:$PATH
/var/mod # env | grep ^PATH
PATH=/var/mod/bin/225:/sbin:/usr/sbin:/bin:/usr/bin
/var/mod #
Ich habe das - wie oben schon erwähnt - auf einer 7580 "zusammengestellt" ... aber es ist auf anderen Modellen auch nicht anders, solange der Link für die HWRevision des verwendeten Modells nur richtig (und überhaupt vorhanden) ist, wobei die Puma-Binaries tatsächlich nicht in der "modfs.tgz" enthalten sind, obwohl die HWRevision-Nummern "verlinkt" sind. Die müßte man sich also selbst noch dazukopieren, wenn man das auf einer Puma6-Box macht (und das Verzeichnis für GRX5_3.10.104(!) ist auch noch nicht dabei im Archiv von "yourfritz.de").
Code:
/var/mod # ls -l bin
lrwxrwxrwx    1 root     root             5 Oct  9 12:32 156 -> Vx180
lrwxrwxrwx    1 root     root            11 Oct  9 12:32 175 -> VR9_3.10.73
lrwxrwxrwx    1 root     root            11 Oct  9 12:32 185 -> VR9_3.10.73
lrwxrwxrwx    1 root     root            11 Oct  9 12:32 192 -> VR9_3.10.73
lrwxrwxrwx    1 root     root            11 Oct  9 12:32 193 -> VR9_3.10.73
lrwxrwxrwx    1 root     root            11 Oct  9 12:32 203 -> VR9_3.10.73
lrwxrwxrwx    1 root     root            11 Oct  9 12:32 212 -> VR9_3.10.73
lrwxrwxrwx    1 root     root             6 Oct  9 12:32 213 -> P6ATOM
lrwxrwxrwx    1 root     root            11 Oct  9 12:32 218 -> VR9_3.10.73
lrwxrwxrwx    1 root     root             6 Oct  9 12:32 220 -> P6ATOM
lrwxrwxrwx    1 root     root            12 Oct  9 12:32 221 -> GRX5_3.10.73
lrwxrwxrwx    1 root     root            12 Oct  9 12:32 225 -> GRX5_3.10.73
lrwxrwxrwx    1 root     root            12 Oct  9 12:32 226 -> GRX5_3.10.73
drwxr-xr-x    2 1000     1001           220 Oct  9 12:32 GRX5_3.10.73
drwxr-xr-x    2 1000     1001           260 Oct  9 12:32 P6ATOM
drwxr-xr-x    2 1000     1001           220 Oct  9 12:32 VR9_3.10.107
drwxr-xr-x    2 1000     1001           220 Oct  9 12:32 VR9_3.10.73
drwxr-xr-x    2 1000     1001           200 Oct  9 12:32 Vx180
drwxr-xr-x    2 1000     1001           400 Oct  9 12:32 common
drwxr-xr-x    3 1000     1001           160 Oct  9 12:32 scripts
/var/mod #
---------------------------------------------------------------------------------------------------------------------------

Fazit: Man kommt bei der Benutzung von "modfs" auch ganz gut ohne ein Windows-System oder ein anderes Linux aus ... wenn man erst mal den Shell-Zugang hat, denn dafür braucht man ggf. noch irgendeine Möglichkeit des "Impfens" - zumindest bei den VR9-Boxen mit "wrapper" geht das ja.
 
Zuletzt bearbeitet:
  • Like
Reaktionen: TomTomNavigator
Schöne Anleitung, Danke!
Hat was, wenn man sieht wie Einer in seinem Element ist. Die Befehle habe ich alle schonmal gesehen, aber soviel Umgang habe ich leider nicht, sie entsprechend zur richtigen Zeit zielführend einzusetzen. :-(

dann muß man den eben zuvor über das GUI auswerfen lassen, dann werden diese AVM-Daemons auch entsprechend "abgehängt"
Das klappt aber auch nicht immer zuverlässig.

Bei dem habe ich auch beschrieben, daß (und vor allem warum) er nur für Volumes mit nativen Dateisystemen gilt - zumindest in der Form, die ich "anbiete".
Dann wäre das auch geklärt. Könnte man als Hinweis in den modfs Abfragetext einbauen.

Die Frage ist, ob es damit (aus- und einpacken des Image auf einem FAT) evtl. Probleme gibt?
Berechtigungen können auf FAT/FAT32 nicht gesetzt werden...
Kann es sein, dass das hier zum Problem wird?
Die Box ist nämlich bereits 2x abgeschmiert.
Wie kann man sowas debuggen? Nach einem Neustart ist ja das log leer (nicht dass ich darin einen sinnvollen Hinweis erwarten würde...).
 
Könnte man als Hinweis in den modfs Abfragetext einbauen.
Na ja, das ist zwar eine "gute Idee", aber die hatte ich tatsächlich schon und daher steht das da bereits drin und zwar seit der "ersten Veröffentlichung" dieses "modscripts":

https://github.com/PeterPawn/modfs/blob/master/modscripts/mod_exec_on_usb#L7

Die Box ist nämlich bereits 2x abgeschmiert.
Wäre die Frage, wobei das genau geschehen ist ... bei der Verwendung von "modfs" oder bei irgendwelchen anderen Aktionen. Ich höre jedenfalls irgendwie zum ersten Mal davon, daß eine mit "modfs" behandelte Box (deswegen) abstürzen würde ... eigentlich führt keine dieser Änderungen zur Abwandlung von wichtigen Abläufen in der AVM-Firmware - auch nicht von den kürzlich erst bereitgestellten, neuen.

Mit einer wichtigen Ausnahme, nämlich "mod_enable_calllog" ... und daß sich das nicht mit dem "Impfen" mit einem der "first_aid"-Images verträgt (weil das dort sein "Protokoll" abspeichert und dieses bei einer Firmware mit dem "privaten Modus" für den "telefon"-Daemon dann bei jedem Anruf ausgeführt werden soll), hatte ich auch schon erwähnt. Man muß also schon nach dem "Impfen" den Inhalt der "/var/flash/calllog" noch einmal löschen, bevor man künftig diese Zeilen bei jedem Anruf ausführen lassen will ... das geht mit einem einfachen Kommando (das erste zeigt den vorhandenen Inhalt an und das zweite löscht):
Code:
root@FB7490:~ $ cat /var/flash/calllog
#! /bin/sh
eventadd 1 "/var/flash/calllog was called with $*"
cat /proc/self/cmdline >/var/tmp/calllog.cmdline
ps l >>/var/tmp/calllog.cmdline
exit 0
+ new_script=/wrapper/etc/init.d/rc.shellinaboxd
+ shift
+ cp /etc/init.d/rc.S /tmp/init_rc_replacement
+ sed -e /^if ls.*S/a[ $gruppe -eq 9 ] && /bin/sh /wrapper/etc/init.d/rc.shellinaboxd start -i /tmp/init_rc_replacement
+ mount -o bind /tmp/init_rc_replacement /etc/init.d/rc.S
+ [ 1 -eq 1 ]
+ cat /etc/init.d/rc.S
#! /bin/sh
##########################################################################################
##########################################################################################
## Wird bei Broadcom bereits in einem anderen Script davor gemounted
mount -t proc proc /proc
mount -t tmpfs tmpfs /var
tar xf var.tar
if cat /proc/mounts | grep -q 'devtmpfs .*/dev' ; then
echo "nop - do not mount /dev"
else
tar cf /var/devices.tar /dev
mount -t tmpfs tmpfs /dev
tar xf /var/devices.tar
rm /var/devices.tar
fi
mount -t sysfs sysfs /sys
mkdir -p /dev/pts
mount -t devpts devpts /dev/pts
[ -d /sys/kernel/debug ] && mount -t debugfs none /sys/kernel/debug
if [ -e /etc/init.d/rc.core_sync.sh ] ; then
. /etc/init.d/rc.core_sync.sh
fi
##########################################################################################
## Festlegung des Dateinamens:
## [Kennbuchstabe][GruppenId][SubGruppeId]-<name>
## Kennbuchstaben:
## s/S shell Skript wird als Source gelesen
## e/E shell Skript wird mittels sh ausgeführt
## Große Buchstaben werden beim Systemstart, kleine beim Reboot genutzt.
## Aufteilung der Gruppen:
## 0x preinit
## 1x default Daten und Links zur Verfügung stellen
## 2x udev und andere system dämons starten
## 3x ---
## 4x netzwerk Komponenten
## 5x usb Komponenten
## 6x wlan Komponenten
## 7x Starten der Applikationen
## 8x ---
## 9x Abschluss der Initialisierung des Systems
## ACHTUNG: Alle Mitglieder einer Gruppe müssen so unabhängig sein dass die prinziepiell
## parrallel startbar sein sollen
##########################################################################################
for gruppe in 0 1 2 3 4 5 6 7 8 9 ; do
echo "source files in group ${gruppe} ...";
if ls /etc/init.d/S${gruppe}[0-9]-* 2>/dev/null ; then
[ $gruppe -eq 9 ] && /bin/sh /wrapper/etc/init.d/rc.shellinaboxd start
for skript in `ls /etc/init.d/S${gruppe}[0-9]-* | sort` ; do
echo "source ${skript}"
if [ ! -f /var/skip_init ] ; then
. ${skript}
else
echo "skip_init: ${skript} "
fi
done
fi
echo "execute files in group ${gruppe} ...";
if ls /etc/init.d/E${gruppe}[0-9]-* 2>/dev/null ; then
for skript in `ls /etc/init.d/E${gruppe}[0-9]-* | sort` ; do
echo "execute ${skript}"
if [ ! -f /var/skip_init ] ; then
if ! sh ${skript} ; then
echo "execute ${skript} failed."
fi
else
echo "skip_init: ${skript} "
fi
done
fi
echo "group ${gruppe} done ...";
done
echo "rc.S: System init scripts finished; detaching from console."
sleep 1
/usr/bin/detach
exit 0
+ sed -n -e s|^[ ]*\([0-9]*\) tffs$|\1|p /proc/devices
+ tffs=243
+ [ 3 -gt 0 ]
+ tffs_name=/tmp/add_startup_script.tffs
+ mknod /tmp/add_startup_script.tffs c 243 141
+ [ -c /tmp/add_startup_script.tffs ]
+ cat /tmp/add_startup_script.tffs /tmp/add_startup_script.log
root@FB7490:~ $
Code:
root@FB7490:~ $ echo clear_id 141 >/proc/tffs
root@FB7490:~ $ cat /var/flash/calllog
root@FB7490:~ $
Wer nicht - wie ich - die ersten fünf Zeilen oben in seiner "/var/flash/calllog" stehen hat, zu denen auch ein "exit 0" gehört, womit dann die Abarbeitung beendet wird, der rennt auch problemlos "weiter im Text" und das Skript zum Implantieren der SIAB-Instanz sichert eben (und das habe ich dokumentiert an der betreffenden Stelle) als letzte Aktion seine Debug-Ausgabe noch in dieser Datei ... allerdings wird sie hinten drangeschrieben.

Wenn jemand eine Modifikation verwendet, die als "Verarbeitung der /var/flash/calllog bei eingehenden Anrufen reaktivieren" beschrieben ist (und ich hatte ja meine - weiter oben dargelegten - Gründe, den Patch nicht einfach "Telefon-Codes benutzbar machen" zu nennen), dann erwarte ich eigentlich auch, daß er sich kundig macht, was denn in dieser Datei wohl stehen mag. Wenn da nur ein
Code:
#! /bin/sh
exit 0
steht, ist das auch noch in Ordnung, weil da dann eben Schluß wäre ... aber wenn da das Debug-Protokoll vom "Impfen" steht und dieses auch noch die komplette Kopie der "rc.S" (zur Kontrolle) als Zeilen enthält, die dann als Shell-Kommandos ausgeführt werden, dann kann die Box bei eingehenden Telefonaten fast nur noch abstürzen. Das trifft allerdings auch nur bei dieser Reihenfolge der Aktionen (und dem "Nichtlöschen" der Protokoll-Datei) zu ... wer das Image aus "first_aid" (oder ein selbstgebautes mit dem Skript aus "toolbox") nicht benutzt, hat auch nichts weiter in seiner "/var/flash/calllog" stehen, selbst wenn er diese Modifikation nur wegen der Telefon-Codes hat einbinden lassen.

EDIT: Links hinzugefügt
 
Zuletzt bearbeitet:
Ja, ich vermute da liegst Du relativ richtig. Ich muss es noch nachprüfen, aber die Indizien zeigen in die Richtung. Beim Eingehen eines Anrufes fliegt die Box.
Ich habe Deinen Beitrag nochmal gelesen und bin nicht sicher, ob ich das richtig verstanden habe.
Ein SIAB-Injektions-Image schreibt seinen log ins /var/flash/calllog und der modfs nimmt das mit ins neu erstellte Image?
Ich muss nochmal lesen gehen, aber der Zweck des calllogs ist mir noch nicht klar und was da normalerweise hinein gehört und was nicht.
Edit:
Und warum das Injektions-Image da hinein loggt?
A: OK, das ist halt dann so.
Edit2:
Und warum der Inhalt vor dem Einpacken des Images nicht geleert (oder auf Grundeinstellung gesetzt - was das auch sein mag) wird.
Edit3:
Wenn der Quark aus dem calllog ein paar Mal abgearbeitet wurde, sind die Änderungen dauerhaft bzw. ist es sinnvoll das Image neu zu flashen?
 
Zuletzt bearbeitet:
Die "/var/flash/calllog" wurde früher (und wird heute noch, wenn der "telefon"-Daemon im "privaten Modus" läuft) bei jedem eingehenden Anruf ausgeführt.

Das wurde in der "normalen" Firmware von AVM dann mal abgeschaltet, gleichzeitig blieb jedoch der Ex- und Import dieser Datei beim Sichern und Wiederherstellen der Einstellungen erhalten. Damit kann man also auch bei einer Box ohne Shell-Zugriff auf den Inhalt dieser Datei zugreifen ... und genau deshalb schreibt das Skript zum "Impfen" einer Box mit originaler Firmware in diese Datei hinein ... sie wird dort nämlich nicht ausgeführt und trotzdem kann man ihren Inhalt (auch mit den "regulären Mitteln" des FRITZ!OS) ansehen - das ist für andere Dateien gar nicht so einfach, wie man denken würde. Ohne gestarteten USB-Stack und gemountete Volumes kann man dort auch kein Protokoll ablegen und auch das YAFFS2-FS für NAS ist nicht überall erreichbar - die 7412 hat zum Beispiel keine NAS-Funktionen und damit kommt man dort unter der "originalen Firmware" gar nicht an den Inhalt irgendwelcher Dateien unter "/var/media/ftp" heran, selbst wenn man dorthin vermutlich schon protokollieren könnte, wenn man den Speicher mountet.

Der Dateiinhalt wird also nicht beim "modfs" irgendwo eingebunden ... aber wenn man den "mod_enable_calllog" verwendet, wird eben ihre Abarbeitung bei eingehenden Anrufen wieder reaktiviert und dann wird genau das ausgeführt, was zuvor vom Image zum Implantieren von SIAB dort abgelegt wurde als Protokoll.

Das sind zwei vollkommen unabhängige Vorgänge ... und wie bereits geschrieben: Wenn man sich der Konsequenzen bewußt ist (und rechtzeitig ein "exit" erfolgt), stört das "Fortschreiben" dieser Datei durch das Image auch nicht wirklich - allerdings muß man dann auch irgendwann den Inhalt der Datei mal auswerten/auslesen/löschen, wenn man zu oft das Image anwendet, denn es wird eben fortgeschrieben und bei 32 KB (ZIP-komprimiert) ist Schluß mit lustig.

--------------------------------------------------------------------------------------------------

Und warum der Inhalt vor dem Einpacken des Images nicht geleert (oder auf Grundeinstellung gesetzt - was das auch sein mag) wird.
Weil es nicht "Pflicht" ist, das "modfs" auf der Box auszuführen, wo das erzeugte Image auch installiert werden soll - die verschiedenen Modi sind aber dokumentiert und können nachgelesen werden. Die "/var/flash/calllog" ist auch gar kein Bestandteil des erzeugten Images und daher per se schon nicht vom "modfs" auf dem "build host" zu verändern.

Es gibt zwar beim "mod_rc_tail_sh" eine Ausnahme von dieser Regel und da schreibt das Skript tatsächlich auch auf der aktuell verwendeten Box (wo "modfs" ausgeführt wird) etwas in die "rc.user" - aber auch nur dann, wenn die ansonsten vollkommen leer ist und damit wird nichts anderes beeinflußt, weil die Datei ohne den Patch (wenn sie leer ist, darf man unterstellen, daß der Patch zuvor auch auf diesem System nicht angewendet wurde) auch nicht zur Ausführung gelangt ... und letztlich ist das eingefügte Kommando, was nur eine zusätzliche Zeile ins Event-Log schreibt, auch absolut harmlos.

Auch verwechselst Du hier ganz offensichtlich zwei unterschiedliche "Speicher" (ist aber auch wieder alles beschrieben, also kann ich mir den Hinweis auf "mehr Lesen" auch nicht ganz verkneifen) - während das Image tatsächlich zweimal existiert (für jedes System eines), gibt es die "/var/flash/calllog" eben nur ein einziges Mal - die ist Bestandteil der Einstellungen, die für beide Systeme gelten. Basierend auf der Feststellung, daß die ex- und importiert wird, ist das aber irgendwo auch klar - warum sollte etwas exportiert werden, was normalerweise "read-only" ist (wie alles im SquashFS) ... das kann man ja dann auch nicht wieder importieren.

Da ist also nichts mit "Löschen vor dem Einpacken" ... nicht einmal mit "Löschen beim Patch", weil man gar nicht entscheiden kann (ohne sehr ausführliche Tests), ob das "absichtlicher Inhalt" in dieser Datei ist (der auch tatsächlich bei einem eingehenden Anruf ausgeführt werden soll auf dem "build host") oder ob das Kunst wäre oder ob das wirklich weg kann.

Ich kann ja auch nachvollziehen, daß man sich als "Neuling" so manche Frage stellt, warum etwas so und nicht anders umgesetzt wurde. Das ist (in Grenzen) auch legitim ... aber ich bin nun bei Erklärungen auch nicht so zurückhaltend, daß man nur sehr schlechte Chancen hätte, daß ich meine Überlegungen bei bestimmten Patches auch aufgeschrieben habe (und zwar schon in der Vergangenheit) und man das also einfach nachlesen könnte, ohne daß ich es (erneut) beantworten muß - einfach mal mit dem Namen so eines Patches auf die Suche gehen, ist bestimmt auch keine so abwegige Idee.

Und ebenso häufig mache ich mir tatsächlich auch Gedanken, warum ich etwas so und nicht anders implementiere ... wenn man also Verbesserungsvorschläge hat, wäre es schöner, wenn man diese dann auch mit passenden Begründungen abgibt, warum das besser ist und warum es an anderen Stellen (für die ich meine Gründe dargelegt habe in der Vergangenheit) nicht schadet oder warum meine alten Überlegungen keine Rolle mehr spielen sollten.

Das erspart mir doppelte Erklärungen und es zeigt gleichzeitig, daß man Notiz genommen hat von meinen Überlegungen und trotzdem der Ansicht ist, man hätte die bessere Alternative vorzuschlagen. Was auch absolut sein kann, nicht daß man das mißversteht ... aber es macht auch nicht wirklich Spaß, dasselbe mehrfach zu schreiben (auch wenn's vielleicht die Chancen erhöht, daß jemand davon Notiz nimmt), nur weil jemand anderes die richtige Stelle nicht gefunden hat, wo ich das schon einmal beschrieben hatte.

Wenn der Quark aus dem calllog ein paar Mal abgearbeitet wurde, sind die Änderungen dauerhaft bzw. ist es sinnvoll das Image neu zu flashen?
Auch hier hast Du vermutlich wieder das Verständnisproblem für den Aufbau der AVM-Firmware und -Geräte ... egal wie oft man die "calllog" bei einem Anruf auch abarbeitet - solange darin keine Kommandos enthalten sind, die ein SquashFS-Image verändern würden, wird auch das Image nicht geändert - warum sollte man also ein neues erstellen lassen?.

Wenn es Änderungen an den Einstellungen sind, die durch die (falschen) Statements in der "calllog" vorgenommen würden, sind die auch bereits nach dem ersten Mal persistent und es spielt gar keine Rolle, wie oft man diese Kommandos noch abarbeiten läßt.
 

Zurzeit aktive Besucher

Statistik des Forums

Themen
246,085
Beiträge
2,245,799
Mitglieder
373,539
Neuestes Mitglied
Horst Fürst
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.