[Problem] Fritzbox 7390 Fon Wlan -- Portfreigabe -- Ziel nicht im Heimnetz ?!

Übrigens, nur der Vollständigkeit halber: die offizielle 6.23 hat das Problem auch. Scheint auch ein gewolltes Nicht-Feature zu sein, denn jetzt wird es über die Oberfläche verhindert und ggf. in der ar7.cfg auskommentiert, wenn man es händisch reineditiert und ar7cfgchanged aufruft oder neu startet.
 
An Meyergru:

Das war in den vorherigen Versionen aucn schon so (seitdem das Problem überhaupt besteht).
 
Ich weiß, aber ich hatte noch die leise Hoffnung, dass das nicht gut überlegt war und wieder rückgängig gemacht wird. Genau wie die Geschichte mit dem fehlenden nmbd ist es aber offenbar Absicht. Für mich ist damit jetzt endgültig Ende mit Experimenten mit neueren Firmware-Versionen, ich bleibe bei 6.04, weil die danach entweder instabil sind oder Features entfernen, die ich brauche. Die Hoffnung auf eine brauchbare Version inklusive Stabilität bei hohem Durchsatz via VPN habe ich sowieso aufgegeben.
 
Wie? Bei 6.04 ist die VPN Einstellung noch drinnen?!
Also mit den ports geht komischerweise alles jetzt bei mir. Aber schon bei 6.20
 
Ich weiß, aber ich hatte noch die leise Hoffnung, dass das nicht gut überlegt war und wieder rückgängig gemacht wird. Genau wie die Geschichte mit dem fehlenden nmbd ist es aber offenbar Absicht.
Wir spekulieren ja alle nur, was die Motivation von AVM für bestimmte Aktionen angeht.

Aber beim Spekulieren kann man ja auch Begründungen für seine Annahmen anführen ... bei der fehlenden Möglichkeit, Portfreigaben woandershin als ins LAN einzurichten, springt für mich die Sinnhaftigkeit eines solchen Vorgehens tatsächlich ins Auge (hatten wir weiter vorne aber schon) und die Tatsache, daß es irgendwo extra mit einer passenden Fehlermeldung geprüft und abgelehnt wird, ist ja auch ein starkes Anzeichen für ein geplantes Vorgehen der Entwickler.

Das ist beim Fehlen des nmbd keineswegs so, ganz im Gegenteil. Auch in den Firmware-Versionen, wo kein nmbd enthalten ist, wird z.B. versucht, ihn in /bin/inetdctl zu starten und zu stoppen, auch in /etc/samba_control wird er beim Stoppen der ganzen Samba-Dienste berücksichtigt. Normalerweise fängt AVM solche Starts mit einem entsprechenden Test ab, wenn die Möglichkeit besteht, daß ein Programm nicht in einer Firmware enthalten ist. Abgesehen davon ist es - anders als beim Wegfall der falschen Portforwards - nur in einer einzigen Firmware-Version bisher der Fall und auch da ist die historische Herleitung (alles nur für 7390 und m.W. keine anderen Modelle, wenn man mal den Speichermangel bei einigen 7360 und das generelle Fehlen des NAS dort ausblendet):

1. 06.0x international ohne Samba wegen Platzmangel (seit Herbst 2013)
2. 06.20 deutsch mit Samba und allem, was man dazu braucht, inkl. nmbd (Sept. 2014)
2. 06.20 int. auch wieder mit Samba, weil Platz geschaffen wurde durch die Sprach-DB-Plugins, aber ohne nmbd (Okt. 2014?)
3. 06.21-Labor deutsch dann immer noch mit smbd, aber ohne nmbd
4. 06.23 deutsch dann immer noch ohne nmbd

eigentlich doch eher ein Zeichen dafür, daß da jemand versehentlich den nmbd vergessen hat (der Platzbedarf des nmbd ist tatsächlich zu vernachlässigen) und in der Folge daraus der KB-Artikel bei AVM entstand, der zwar für die internationale Version bereits bei der 06.20 stimmt (für frühere internationale stimmt er ja auch nicht, denn da hilft auch kein Laufwerks-Mapping, weil schlicht der gesamte smbd fehlt), aber für die deutsche Version eben erst ab 06.23. Die Wahrscheinlichkeit, daß da jemand in dem Skript/der Dateiliste, mit dem/der die Dateien vom Build-System zu einem lauffähigen Image zusammengestellt werden, bei der "Reaktivierung" von Samba den nmbd ganz schlicht vergessen hat und diese Vorlage dann wieder verwendet wurde, um die deutsche Labor-Version zu erzeugen, ist ja nicht vollkommen von der Hand zu weisen und so etwas kann ja mal vorkommen.

Wenn AVM jetzt tatsächlich (Warum eigentlich? Um das Gesicht zu wahren und damit der KB-Artikel paßt?) dazu übergehen sollte, den nmbd aus der deutschen 7390 absichtlich herauszulassen, dann kann das eigentlich nur als "Kaufanreiz" für andere Modelle verstanden werden und daß ein verärgerter Kunde, der eine - gut oder weniger gut - funktionierende FRITZ!Box wegen fehlender Windows-Netzwerkunterstützung entsorgen muß, wieder zu einem Modell desselben Herstellers greift, ist ja eher unwahrscheinlich. Wo wäre also der Vorteil, der für AVM daraus entstehen könnte?

Du bist doch das beste Beispiel für einen verärgerten Kunden, denn aus
Die Hoffnung auf eine brauchbare Version inklusive Stabilität bei hohem Durchsatz via VPN habe ich sowieso aufgegeben.
eine Zufriedenheit - geschweige denn Begeisterung - herauszulesen, gelingt mir irgendwie nicht.

Also sollte man diese beiden Sachen eher nicht in einen Topf werfen (meine Meinung dazu) und sich mit dem Fehlen der Portfreigaben abfinden. Warum muß man überhaupt einen Port in das Gastnetz freigeben, welcher Gast kommt denn mit seinem eigenen Server (darunter verstehe ich jedes Gerät, das einen "Service" für andere anbietet) vorbei und will diesen Server dann auch noch (er ist ja schließlich selbst vor Ort) aus dem Internet nutzen? Wenn jemand das Gastnetz als DMZ mißbrauchen will (und damit in gewisser Weise zeigt, daß er den Unterschied einfach nicht versteht, denn "geht doch" oder "ging doch bisher auch" ist nun mal kein Argument), dann finden sich andere Mittel und Wege und auf die derzeit umgesetzte Weise ist die FRITZ!Box wenigstens vor dem allzu naiven Eigentümer einigermaßen sicher. Nur wer das Know-How hat, um diese "Sperre" zu umgehen, der hat auch genug Netzwerk-/FRITZ!Box-Kenntnis, um gefahrlos Dienste aus anderen Netzen ins Internet freizugeben, weil es bestimmt auch einige wenige Szenarien gibt, wo das Sinn machen könnte.
 
Du bist doch das beste Beispiel für einen verärgerten Kunden, denn aus

...

eine Zufriedenheit - geschweige denn Begeisterung - herauszulesen, gelingt mir irgendwie nicht.

Es war auch nicht meine Intention, Begeisterung auszudrücken, das hast Du richtig erkannt.

Also sollte man diese beiden Sachen eher nicht in einen Topf werfen (meine Meinung dazu) und sich mit dem Fehlen der Portfreigaben abfinden. Warum muß man überhaupt einen Port in das Gastnetz freigeben, welcher Gast kommt denn mit seinem eigenen Server (darunter verstehe ich jedes Gerät, das einen "Service" für andere anbietet) vorbei und will diesen Server dann auch noch (er ist ja schließlich selbst vor Ort) aus dem Internet nutzen? Wenn jemand das Gastnetz als DMZ mißbrauchen will (und damit in gewisser Weise zeigt, daß er den Unterschied einfach nicht versteht, denn "geht doch" oder "ging doch bisher auch" ist nun mal kein Argument), dann finden sich andere Mittel und Wege und auf die derzeit umgesetzte Weise ist die FRITZ!Box wenigstens vor dem allzu naiven Eigentümer einigermaßen sicher. Nur wer das Know-How hat, um diese "Sperre" zu umgehen, der hat auch genug Netzwerk-/FRITZ!Box-Kenntnis, um gefahrlos Dienste aus anderen Netzen ins Internet freizugeben, weil es bestimmt auch einige wenige Szenarien gibt, wo das Sinn machen könnte.

Also zunächst mal sind beide Punkte für mich einfach fehlende Eigenschaften. Und Eigenschaften für die gilt: "ging doch bisher auch" einfach zu streichen oder zu "vergessen", wie Du annimmst, kommt nie besonders gut an - besonders, weil der unbegeisterte Kunde dann wieder Monate auf eine finale Version warten darf, in der dann (vielleicht) der Flüchtigkeitsfehler (also hier nmbd) korrigiert wird. Leider nach meiner Erfahrung dann oft aber mit anderen, neuen Bugs.

Aber so ist das einfach, wenn man wie AVM:

a. Keine "offizielle" Feature-Liste hat und
b. die Firmware für derartige Geräte ständig weiterentwickelt

Letzteres hat an sich positive Effekte, wenn Features neu hinzukommen, ersteres führt aber dazu, dass z.T. auch Features gestrichen werden, die man vorher nie "offiziell" unterstützt hat, die aber z.T. liebgewonnen wurden. Der geneigte Kunde darf dann in einem Forum Mutmaßungen darüber anstellen, ob das jeweilige Feature nur aus Versehen verhunzt oder gar absichtlich ausgebaut wurde.

Und was die Frage angeht, womit man sich abfinden muss: Die von mit angeführten Features stehen auf meiner Must-Have-Liste und müssen für niemanden sonst gelten. Dennoch: Die Frage, wie ich ein bestimmtes Feature nutze - z.B. ein vom eigentlichen Intranet abgekoppeltes Netzsegment - (nämlich als DMZ) ist vollkommen unabhängig davon, was sich der Hersteller bei der Einführung als potentielles Zielszenario vorgestellt hat (nämlich Gastnetz). Insbesondere glaube ich nicht, dass diese Nutzungsart irgendwas mit mangelndem Verständnis zu tun hat, sondern höchstens mit kreativer Nutzung vorhandener Möglichkeiten.
Die Unterstellung, dass es kaum sinnvolle Szenarien für diese Art der Nutzung gibt, wird durch die bloße Existenz dieses Threads ad absurdum geführt - wenn man sich denn mal von der Vorstellung löst, dass es "Gäste" sind, die im "Gastnetz" Serverdienste anbieten wollen.


Ich habe lediglich die Abwesenheit der aufgezählten Features auch in der neuesten Finalversion festgestellt und - für mich - entschieden, dass die Weiterentwicklung von AVM seit einiger Zeit in eine Richtung geht, die mir nur Features beschert, die ich nicht brauche, während Dinge, die ich nutze (oder nutzen will), oft genug:

a. ohne Not entfernt werden (Freigabe ins "Gastnetz": mir fehlt da nämlich immer noch das überzeugende Sicherheitsargument, wieso man keine Freigaben ins "Gastnetz" machen soll).
b. vergessen werden (nmbd)
c. nicht richtig funktionieren und schlicht nicht korrigiert werden (Reboots bei hohem Durchsatz via VPN u.v.a.m.)

Da das Hauptthema in diesem Thread die Portfreigabe ins Gastnetz ist, werden etwaige Leser wohl wie ich Interesse genau daran haben und sich eventuell ebenfalls nicht "daran gewöhnen" wollen, sondern wie ich einfach die alte Version nutzen.
 
Zuletzt bearbeitet:
Die Unterstellung, dass es keine sinnvollen Szenarien für diese Art der Nutzung gibt, wird durch die bloße Existenz dieses Threads ad absurdum geführt - wenn man sich denn mal von der Vorstellung, dass es "Gäste" sind, die im "Gastnetz" Serverdienste anbieten wollen.
Erstens habe ich das nicht unterstellt, wenn Du den letzten Satz meines Beitrags auch noch liest, wirst Du feststellen, daß ich die Existenz solcher Szenarien durchaus anerkenne. Aber schon der Name "Gastnetz" sagt eigentlich, für wen dieses Netz gedacht ist und da will ich mich gar nicht von der Vorstellung lösen, daß sich ein Client im Gastnetz als "Gast" zu verhalten hat. Ansonsten ist es kein Gastnetz ...

Da das Hauptthema in diesem Thread die Portfreigabe ins Gastnetz ist, werden etwaige Leser wohl wie ich Interesse genau daran haben und sich eventuell ebenfalls nicht "daran gewöhnen" wollen, sondern wie ich einfach die alte Version nutzen.
Und auch da irrst Du Dich gründlich ... der TE wollte eindeutig keine Freigabe ins Gastnetz (nach seinem eigenen Bekunden) und wurde lediglich mit dem Problem konfrontiert, daß bei ihm keine Freigabe ins Heimnetz einzurichten war. Das betraf andere Leute in diesem Thread genauso, die Idee mit der Freigabe ins Gastnetz wurde (ich zähle jetzt nicht nach und behaupte das nur aus der Erinnerung, das muß also nicht zu 100% stimmen) von 3 Leuten angeführt. Das ist bei weitem nicht das "Hauptthema" in diesem Thread und eigentlich wurde ein Fehler in einer Labor-Version hier zur Basis einer Diskussion über ein vollkommen anderes Thema ("AVM erlaubt keine Freigaben ins Gastnetz mehr", das ist nun mal etwas anderes als das Problem des TE) auserkoren.

Und was Du auf Deiner "must have"-Liste stehen hast, ist mir herzlich egal - das ist Deine eigene Angelegenheit und wenn Du Dich nun für eine andere Box entscheiden mußt (anstatt die ja trotzdem bestehenden Möglichkeiten mit dem Editieren der ar7.cfg zu nutzen), dann ist das auch alleine Dein Problem.

Ich wollte nur mit Argumenten aufzeigen, daß es einen gewaltigen Unterschied macht, ob ein Feature mit passender Fehlermeldung aus der Firmware entfernt wurde (wenn Du die Korrektur eines fehlerhaften Verhaltens (meine Interpretation, aber ziemlich offensichtlich auch die von AVM) einer möglichen Freigabe in das Gastnetz "entfernen" nennen willst) - das zieht sich auch offensichtlich durch alle neuen Firmware-Versionen - oder ob da für ein einzelnes Modell (die zeitliche Abfolge habe ich auch versucht zu vermitteln) eine einzelne Funktion nicht vorhanden ist, für die es - ziemlich offensichtlich, selbst auf der Samba-Mailingliste ist nichts zu Problemen mit dem nmbd zu finden - keine sinnvolle Erklärung gibt.

Wenn Du eine Differenzierung nicht für notwendig oder angebracht hältst, ist das sicherlich auch ein Standpunkt, aber nicht jeder muß ihn teilen. Und wenn ich schreibe: "Wenn jemand [...] mißbrauchen will" und Du siehst darin eine "kreative Nutzung vorhandener Möglichkeiten", dann verdeutlicht das schon sehr drastisch unterschiedliche Standpunkte.

Ich bin nicht der Meinung, daß potentiell gefährliche Möglichkeiten in der Firmware nicht nachträglich auch gefixt werden dürfen, wenn man die davon ausgehende Gefahr erst später erkennt, nur weil sich dann ein paar wenige Nutzer "auf den Schlips getreten" fühlen. Nun mag man sogar noch unterschiedlicher Meinung sein, wie schwerwiegend ein Problem ist, das ändert aber nichts an der Berechtigung, ja sogar der Verpflichtung, des Herstellers, solche potentiellen Probleme nach Kräften zu entschärfen.

Das ist auch nicht das erste Mal, daß AVM solche Geschichten fixt ... vielleicht kannst Du Dich ja auch noch an Zeiten erinnern, wo man einfach auf 169.254.1.1 oder 192.168.180.1 o.ä. weiterleiten konnte und damit auf der Box selbst landete. Dem wurde auch ein Riegel vorgeschoben ... unabhängig davon, wie einzelne Nutzer das beurteilt haben mögen und es war (meine Meinung) richtig so, denn das Ausschlaggebende sollte für AVM die breite Masse sein und der würde ich so ein Werkzeug schon deshalb nicht ohne gewisse Vorsichtsmaßnahmen in die Hand geben, weil es auch heute noch im Internet genug ungenaue bis falsche Beschreibungen gibt, welche Ports man wofür freigeben soll (damit läßt sich in der Firmware auch heute immer noch genug Unfug anstellen).

Ich stimme Dir sogar in vielen Punkten bzgl. einer Feature-Liste und einer gewissen Willkür von AVM bei der Bewertung der Priorität eines bestimmten Features zu (ich persönlich bräuchte die ganze HA nicht), trotzdem kann ich über meinen eigenen Tellerrand hinaussehen und dabei stelle ich dann fest, daß es neben meinen eigenen Interessen offenbar auch noch eine gewisse Anzahl von Kunden gibt, die AVM's Bestrebungen in dieser Hinsicht honorieren. Da kann ich mich jetzt in die Schmollecke setzen und mich auf den Standpunkt stellen, daß das nie in der Produktbeschreibung meiner FRITZ!Box stand, daß man damit irgendwelche DECT-Steckdosen steuern kann. Das wird aber auch AVM nicht davon abhalten, für mich persönlich wichtige Features mit wesentlich niedrigerer Priorität zu behandeln, als diese HA-Features.

Im Zusammenhang mit der Freigabe ins Gastnetz stellt sich dann für mich tatsächlich die Frage "Bug oder Feature?" und da stehen wir ganz offensichtlich auf diametral entgegengesetzten Standpunkten. Eine DMZ, in die keine Portfreigaben funktionieren, ist ziemlich witzlos, da stimme ich zu. Es gibt auch genug Leute (selbst Router-Firmware-Programmierer), die den Unterschied zwischen einer DMZ und einem "Exposed Host" nicht verstehen bzw. das gleichsetzen in ihrem Menüs. Das kann aber alles nicht darüber hinwegtäuschen, daß das offiziell von AVM "Gastnetz" genannte Feature (egal ob irgendwo beschrieben oder nicht), genau das macht, was man von einem isolierten "Gastnetz" erwartet (und auch gemeinhin darunter versteht) und zur Liste der Anforderungen an ein "guest network" (das ist ja beileibe keine AVM-Erfindung, sieh Dir einfach mal die Umsetzung bei diversen anderen Herstellern an) gehört nun mal nicht die Möglichkeit, externe Ports in dieses separate Netz weiterzuleiten. Auch ein Fehler, der kreative Möglichkeiten eröffnet, ist nun mal ein Fehler ... überspitzt: Die Nutzung eines HTTP-Requests an webcm ohne Definition der gewünschten Interface-Sprache war letzten Endes auch nur eine kreative Möglichkeit, beliebige Kommandos auszuführen und so z.B. den Zugang zu ansonsten unzugänglicen Funktionen der FRITZ!Boxen zu erlangen.

Nun mag man es ja für opportun halten, in Verbindung mit einer gewollt entfernten Unsicherheit und dem eigenen Ärger darüber, alles andere auch in einen Topf zu werfen, um irgendwie seinem Ärger Luft zu machen. Das will ich nicht be- oder verurteilen, das ging mir auch schon so, selbst wenn ich i.d.R. auch dann noch versuchen würde, eine logische/nachvollziehbare Begründung für meine Vorwürfe zu finden. Wenn das "Luft machen" Dein eigentliches Anliegen war, hoffe ich, es geht Dir jetzt besser.
 
Zuletzt bearbeitet:
7390- FRITZ!OS 06.23

Hallo zusammen,

Leider gibt es wohl nur euren Beitrag im Netz, bei dem es um die Fehlerausgabe geht

"Die Portfreigabe kann nicht erstellt oder aktiviert werden, da das Ziel nicht im Heimnetz liegt."

Und in meinem Fall habe ich jetzt sicher seit ca. 10 Monaten an den Freigaben nichts mehr gemacht.

Jetzt wo ich eine existierende Portfreigabe ändern wollte, stellte ich fest das diese Fehlermeldung mich daran hindert.

Interessant ist, dass ich Portfreigaben für IP´s erstellen kann die nicht in Verwendung sind, bzw. noch nie in Benutzung waren.
Somit habe ich einen Workaround, dann einfach nach erstellen der Freigabe, die IP des Geräts zu ändern.

Jetzt müsste man ja glauben das geht in die andere Richtung auch.
Auf die nun nicht mehr verwendetet IP des Gerätes, wieder eine Freigabe zu machen mit dem neuen Port, und beim Gerät danach wieder auf die richtige zurück.
Geht nicht - sobald es eine IP ist, die schon mal genutzt wurde, kann ich keine Freigabe erstellen weder ändern

Ich habe auch kein Gastnetzt oder Spezialitäten, wie hier in diesem Thread teilweise die Rede war.

Der Workaround ist langfristig beschi***.
Weil ich erstmal von vielen Gerärten die IP auswendig weiss mit den Jahren
Weil mir somit irgendwann mal die IP´s ausgehen für die Freigaben und meine Systeme logische Statische Bereiche haben
und es kein durcheinander sein soll.
IP Survilance 100-110
IP Telefone 120-140
VM´s Server, Exchange, MAil cleaner, 200-220

Gibt es bei der Fritzbox irgendeinen Cache den mal löschen kann, der keine Einstellungen verschmeisst.
Mit RuKernerl kann man ja einige Cache parts löschen.
Werkseinstellungen und dann komplett neu ist unmöglich.
Werkseinstellung und konfig zurückspeielen hab ich gemacht, erfolglos.
Da brauch ich stunden um die Konfig annähernd wieder hin zu bekommen und in der zeit geht nichts in der Firma.

Ehrlich gesagt hab ich noch nie bis heute Probleme gehabt, aber das ist schon fataler bug mit den Portfreigeaben

Alternative wäre mir eine zweite Box zu kaufen und diese Stück für Stück der anderen kofig anzugleichen.
Und hoffen das auf langfristig der Fehler wegbleibt


Gruss Danke
 
Zuletzt bearbeitet:
Ich rate mal wild drauflos und sage, daß da eine existierende Freigabe beim Validieren des gesamten Regelwerks dazwischen funkt.

Ich würde einfach alle Freigaben und alle bekannten Geräte löschen ... das ist m.E. das mindeste an Konfigurationsdaten, was Du "opfern" mußt. Auch ist dieser Vorgang in der notwendigen Gründlichkeit nicht über das GUI zu bewältigen, Du mußt schon die exportierte Konfigurationsdatei entsprechend bearbeiten, bevor Du sie nach "Werkseinstellungen" dann erneut importierst. Zum Bearbeiten kannst Du den FBEditor verwenden, dafür findest Du hier einen gesonderten Thread.

Wenn Du die Stellen in der Konfigurationsdatei nicht alleine identifizieren kannst, braucht man diese, um Dir entsprechende Hinweise geben zu können. Da dort alle Credentials so verschlüsselt sind, daß sie ohnehin kein Fremder entschlüsseln kann (es sei denn, Du gibst ihm noch weitere Informationen - auch dazu findest Du hier Infos), mußt Du da auch nicht groß "basteln", bevor Du sie hier einstellen kannst. Allerdings würden sicherlich verwendete IP-Netze und auch die MAC-Adressen von vorhandenen Geräten dort ersichtlich sein, was Rückschlüsse auf mögliche Angriffspunkte zuläßt.

Aber mit ein wenig Geduld findet man die richtigen Stellen in der Firmware-Konfiguration eigentlich ganz gut (vorher wirklich alle Forwardings löschen, soweit das geht) und auch ein oder zwei Versuche schaden dort sicherlich nicht. Daß man die "originale" Sicherung aufhebt, um bei einem Fehler von vorne beginnen zu können, versteht sich von selbst. Es gibt jedenfalls keine Konfigurationsdatei in der FRITZ!Box, die nicht in der Export-Datei enthalten ist und ein Werksreset überlebt ... zumindest keine für Deinen Fall relevante.
 
Nun ja... meine feststellung im Laufe der Zeit... es ist und bleibt ein BUG. Ich habe in der zwischenzeit einige Updates auf andere Firmwares (immer auf die nächste Beta bzw. Labor) durchgeführt. Mal ging nach einem Update die Portfreigabe und mal nicht!
AVM hat keine Anhung woran das liegt und nach jedem Update alles zu löschen und von Hand einzugeben ist keine Lösung!

Allerdings habe ich mittlerweile auch einen FritzBox 7490 (als Hauptbox) und dort den Fehler bisher noch nicht gehabt, obwohl ich die Einstellung der 7390 direkt automatisch in die 7490 übernommen habe!!

Es ist also sehr gut möglich, das mit dem nächsten Update bei dem einen oder anderen der Fehler von alleine verschwindet!!


Was tatsächlich stimmt, ich habe und hatte nie ein "Gastnetz"!! ;-) :)
 
Danke erstmal Peter Pawn für den Tipp,

das könnte ein Versuch wert sein, wirklich alle Freigaben zu löschen, das der Bereich mal "clean" ist.
Schnell und unkompliziert, die eine Sicherung von IST stand natürlich zur Hand als Rückfall.
Parallel werde ich ausschau halten nach einer gebrauchten 7390 im Netz, falls ich mich auf eine Parallelkonfig einlassen muss.

Ersteres werde ich Donnerstag abend mal ausprobieren und hier Feedback geben.

Noch mal zu meiner anderen Frage oben Bitte kurz:

Gibt es eine art cache auf der Fritzbox der diverse Daten speichert, welche mehr oder weniger zum Beispiel,
Verläufe der Dropdown Bars, vergebene Namen der Geräte, etc. löscht?

Gruss schönen Abend
 
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.