Vorschlag an alexandri: Mach' Doch einen Thread mit solchen Beiträgen auf, dann brauchst Du in die Cross-Posts nur noch den Link dahin einfügen. Dann noch ein passendes Tag davor gesetzt und man hat nicht automatisch ein Déjà-vu bzw. zweifelt am eigenen Verstand, weil man genau denselben Text eben erst als "neu" schon einmal gelesen hatte.
Oder Du läßt etwas Kreativität walten und verwendest wenigstens unterschiedliche Texte - das läßt Cross-Posts (
https://www.ip-phone-forum.de/threads/ip-phone-forum-regeln.297224/ - Punkt 5.9) weniger auffällig erscheinen und die Zweifel beim Leser können auch nicht auftreten (zumindest nicht aus diesem Grund). Die spitzfindige Feststellung, daß es sich hier ja um dasselbe Subforum handelt und damit 5.9 automatisch nicht zutrifft, wenn man das in mehreren Threads in ein und demselben Unterforum postet, wird ja vermutlich nicht der Grund sein.
=====================================================================
Ansonsten finde ich inhaltlich diese Reaktion der Firmware sogar nachvollziehbar und sehe das (im Mesh-Betrieb) gar nicht als Bug an ... wenn das Ziel des Mesh-Verbunds die Kontrolle
aller Beteiligten von einem gemeinsamen Punkt aus ist, dann wäre die Vergabe einer bestimmten IP-Adresse für irgendein Netzwerk-Gerät ja eine Einstellung im DHCP-Server des Mesh-Masters bzw. in irgendeinem DHCP-Server, aber
über den Mesh-Master als Verwalter des Netzes.
Das Problem, daß ein Gerät mit DHCP nicht richtig umgehen kann und daher eine feste Adresse benötigt, besteht bei einer FRITZ!Box als Mesh-Slave ja gerade nicht bzw. eher selten - wenn man also das "Verteilen" von Einstellungen vom Master aus in einem Heimnetzwerk als Ziel ausgibt oder annimmt, finde ich diese Reaktion absolut nachvollziehbar bei einer Box im Slave- und IP-Client-Mode. Spannender wäre es, was bei einer Router-Kaskade passiert - da kennt der Mesh-Master vermutlich gar nicht alle Parameter, die für das zweite LAN erforderlich sind ... und trotzdem wäre es für mich auch nachvollziehbar, wenn hier der Mesh-Master quasi als Proxy für die Konfiguration weiterer Slaves benutzt wird und die Angaben stellvertretend vom Besitzer abfragen möchte.
Dann eben sogar bis hin zur Konfiguration eines Edge-Routers vom Mesh-Master aus ... schließlich will AVM wohl auch die Topologie-Daten im Mesh inzwischen an einer einzelnen Stelle sammeln - die entsprechenden Punkte in der Support-Seite (auch bei der Labor-Reihe sind die nicht von Beginn an dabei, soweit ich weiß) sind ja nur Information/Kontrolle, während intern mit den Daten dann wohl der (korrekte) schematische Netzwerk-Aufbau generiert wird.
Schaut man sich die anderen, neuen Funktionen zur Konfiguration
von einem Punkt aus an, halte ich es nicht mal für undenkbar, daß AVM bei Mesh-Slave-Betrieb künftig einige Punkte aus dem GUI komplett entfernt (u.a. auch die Netzwerk-Übersicht, damit endlich mal Ruhe ist mit den Diskussionen, daß da auf einem IP-Client oder einem kaskadierten Router etwas anderes angezeigt wird als im Edge-Router) - auch bei professionellen Netzwerk-Management-Systemen gibt es in der Regel einen Server, der die Informationen verwaltet, die er von verteilten Agents erhält und die "Konsolen" zur Visualisierung/Bedienung greifen dann auf diesen Server zu und nicht auf irgendwelche Agents, die nur die Hälfte des Überblicks haben (können).
So ein "Austausch" von Daten wäre also nur natürlich und wenn dann auf einem Mesh-Slave (sofern der eine "ausgewachsene Box" ist und nicht nur ein Repeater o.ä.) nur noch ein Link (oder eine Weiterleitung) auf den Master-Server vorhanden ist, hat man das Problem differierender "Ansichten" über die Geräte im Netz und ihre Namen, Adressen und Fähigkeiten tatsächlich endgültig gelöst und das auf denkbar elegante Weise. Zwar wäre auch ein Abruf der Topologie vom Master und die lokale Darstellung auf der Basis dieser Daten denkbar, aber warum sollte man sich das antun bei AVM? Bei einem Mesh-Slave als IP-Client (in einem Netz mit einem Mesh-Master auf einer FRITZ!Box) sollte mit einem unmodifizierten FRITZ!OS der Master per Definition von jedem Client erreichbar sein, der auch diese Box im IP-Client-Mode befragen könnte ... es spricht also praktisch nichts gegen eine Weiterleitung, höchstens noch das zusätzliche Login am Master.
Aber auch hier erwarte ich eher eine Lösung (wenn das nicht sogar schon implementiert ist), bei der eine erfolgreiche Anmeldung in so einem Szenario (also die Prüfung von Benutzername und Kennwort und die Vergabe einer SID) eher auf dem Master erfolgt als auf einem Slave irgendwo im Netz. Das hat neben der gemeinsamen Benutzerverwaltung über alle FRITZ!OS-Geräte (was in den meisten Szenarien ein gewünschter Effekt sein dürfte) auch noch den Vorteil, daß diese sensiblen Informationen nur an einer Stelle aufbewahrt werden müssen und damit auch nur an einer Stelle ausspioniert werden können. Die "Weitergabe" von Sitzungen an andere Mesh-Teilnehmer ist dann nur noch ein angenehmer Nebeneffekt.
Andererseits kriegt es AVM vielleicht auch irgendwann gebacken, daß sich zwei FRITZ!Boxen die Rolle als Mesh-Master teilen bzw. eine "automatische Umschaltung" für wichtige Funktionen (Anmeldung, Protokoll) erfolgt, wenn der eigentliche Master mal nicht erreichbar ist ... irgendwie werde ich nämlich den Eindruck nicht los, daß sich AVM auf diesem Weg ansonsten auch wieder einen SPOF (single point of failure) einfängt.
Es ist sicherlich verkraftbar, wenn die Änderung von Einstellungen nur dann möglich ist, wenn der Master verfügbar ist - der "Regelbetrieb" sollte aber auch bei seinem Ausfall klappen und über den WLAN-Drucker und einen AP sollte man auch dann noch drucken können, wenn der Mesh-Master gerade mal "down" ist und der Drucker trotzdem aus dem Sleep-Mode erwachen soll, wofür vielleicht auch eine WLAN-Authentifizierung erforderlich ist und wo im schlechtesten Fall sogar irgendwelche Daten über einen L2TPv3-Tunnel zum tonangebenden Router müssten (der aber gar nicht erreichbar ist). Bei "echtem Mesh" würde eben der Ausfall dieses L2TPv3-Tunnels zum Router kompensiert bzw. der Router komplett umgangen (wenn das von den Verbindungen her möglich ist).
Nicht ganz umsonst hat auch ein großer, professioneller RADIUS-Server in aller Regel ein Hot-Backup an seiner Seite - ich bin mal gespannt, wo hier bei AVM die Reise hingeht und wieviel Funktionalität auf dem Master gebündelt wird, damit der Ansatz der "zentralen Verwaltung" funktioniert (einige Infos müssen ja zwangsläufig über mehrere AP geshared werden, schon damit Handover klappt) und wieviel Autonomie die einzelnen Boxen am Ende noch wahren werden.
Der Ansatz, die Telefonie direkt vom Master weiterzuverteilen, ist für mich ein erster Schritt in die Richtung größerer Zentralisierung - hier würde mich mal interessieren, wie sich AVM das vorstellt, wenn ein Netz aus drei (und vielleicht noch mehr) FRITZ!Boxen besteht (1x Master, 2x Slave, meinetwegen auf unterschiedlichen Etagen), an denen jeweils DECT-Telefone angemeldet sind (oder andere angeschlossen wurden, die nicht auf IP-Basis arbeiten und damit nicht schon automatisch 1:1 zum Master durchgereicht werden (können)).
Von Hand würde man hier vermutlich selbst die Telefonie "vermaschen", indem man wechselseitig Accounts einrichtet ... es könnte ja auch sein, daß der Master wirklich mal defekt ist (auch etwas länger) und dann kann die interne Telefonie eben nur noch funktionieren, wenn die beiden Slave-Boxen direkt miteinander klarkommen. Auch die Konfiguration von einheitlichen Rufnummern über alle Boxen im Mesh wäre natürlich ein Vorteil, wobei AVM dann das starre Schema der Nummerierung von Telefoniegeräten auf jeder einzelnen Box aufgeben müßte ... es wäre natürlich für den (nicht allzu computer-affinen) Besitzer dieser Boxen ein Traum, wenn er das erste DECT-Telefon an der zweiten Slave-Box immer über dieselbe Nummer erreicht - auch ohne sich erst überlegen zu müssen, ob er nun mit "*#" erst auf die vorgeschaltete Box muß oder nicht bzw. an welcher DECT-Basis das von ihm zum Anrufen verwendete Telefon nun gerade angemeldet sein mag.
Das sind dann tatsächlich die Visionen, die ich von AVM erwarten würde und mit denen man beim normalen Kunden aus dem Thema "Mesh" wirklich Kapital schlagen könnte ... und das wäre auch ein klarer Vorteil (wenn man denn mehr als eine Box hat/braucht - die Anzahl der Kunden, die vom "Mesh" mit mehreren AP profitieren, ist halt immer noch limitiert, weil ich im 40m²-Appartment in der Großstadt auch keinen zweiten AP brauche), den auch diejenigen Kunden verstehen können, denen es ansonsten nur wichtig ist, daß ihr Gerät irgendwie funktioniert und die gar nicht wissen wollen, warum das so ist.
Denen ist es eben bisher i.d.R. deutlich zu kompliziert, irgendwelche endlosen Folgen aus Stern und Raute eintippen zu müssen, damit sie beim richtigen und tatsächlich gewünschten Gesprächspartner landen. Ähnliches gilt natürlich für die Synchronisation von Telefonbüchern und ggf. sogar von Anruflisten über alle beteiligten Boxen.
Wenn dann auch noch das Handover von DECT-Registrierungen zwischen den Boxen funktioniert, dann kann man am Ende tatsächlich einfach eine weitere FRITZ!Box ins Mesh hängen und das Telefon an deren Aufstellort ebenfalls einfach am Master per Knopfdruck registrieren (weil der alle bekannten DECT-Basen auf Registrierung schaltet und es damit egal ist, wo sich das Gerät tatsächlich gerade befindet). Was wäre so eine "reibungslose Einrichtung" für ein Verkaufsargument bei Lieschen Müller (oder ihrem Gatten, weil der Technik-Kram leider immer noch als Männerdomäne gesehen wird) ... zumindest wenn man es mit dem heutigen Zustand vergleicht, wo selbst gestandene FRITZ!Box-Kenner in bestimmten Situationen erst mal in aller Ruhe einen Plan machen müssen, wie das überhaupt funktionieren könnte und dann g
