Wünsche für neue Firmware-Features

Es tut mir sehr leid, wenn sich das deiner Vorstellungskraft entzieht, dass selbstverständlich eine Fritzbox hinter einem LTE-Router (DMZ) bestens funktioniert mitsamt DynDNS, VPN, Remotezugriff und nur die stur auf WAN-IP = DynDNS-IP beharrenden AVM-Funktionen fehlschlagen.
 
eine Fritzbox hinter einem LTE-Router (DMZ)
Na wenn man so eine spezielle Konstruktion hat, dann sollte es doch auch kein Problem sein in der FB ein eigenes Script laufen zu lassen, welches das DynDNS macht. Das mache ich zumindest so.
 
Hallo Gemeinde,

ich möchte eine Zeit- und Abschaltfunktion für die WLAN-Bänder getrennt anregen. D. h. man kann das 2,4 GHz- und 5 GHz-Band individuell zeitgesteuert schalten. So könnte nachts das 5 GHz-Band deaktiviert werden, das 2,4 GHz-Band, auf dem die meisten Smart Home-Komponenten funken, bleibt aber aktiv.

Besten Dank und ein schönes WE.

Thomas
 
  • Like
Reaktionen: Grisu_
Es sollte aber auch genügen, DDNS einfach nicht zu aktivieren, wenn der Router gar nicht am öffentlichen Netz hängt und DDNS wg. LAN-IP entsprechend nicht benutzt werden kann.

Warum soll denn dabei DDNS nicht benutzt werden können? Es funktioniert ja, nur die dazugehörige "Überprüfung" nervt, weil die in der derzeitig implementierten Form dann nicht funktioniert. Alternativ: Die "Überprüfungsroutine" wird überarbeitet und zieht zur Ermittlung der externen IPv4-Adresse (optional!) nicht die WAN Adresse heran sondern ermittelt sie über einen externen Service (aka STUN o.ä.).
 
Die Benutzung des DynDNS-Services ist halt außerhalb eines Edge-Routers nicht von AVM vorgesehen - verwendet man den (AVM-)Client trotzdem, muß man halt auch mit seinen Schwächen leben lernen (wobei der Wunsch nach genaueren Einstellmöglichkeiten ja legitim bleibt).

Denn diese Überprüfung seitens des AVM-Clients ist ja nicht das einzige Problem auf einem kaskadierten System ... dieses bekommt nämlich i.d.R. (ohne einen eigenen Abfragemechanismus, der in originaler Firmware ebenso fehlt) auch nicht mit, wenn sich die externe, öffentliche IP-Adresse ändert und damit das DynDNS (zeitnah) eine Aktualisierung benötigen würde.

Hier bei solchermaßen "verteilten Systemen" nur der einen Komponente eine "Fehlfunktion" oder eine "falsche Weltsicht" zu unterstellen, ist zu kurz gedacht (der DynDNS-Service spielt für das AVM-VPN auch eine entscheidende Rolle - ohne ständige Abfragen und Überprüfungen, würde der "aggressive mode" mit dynamischen IP-Adressen nicht funktionieren bzw. bis zur fälligen Aktualisierung der Adresse in der Luft hängen) - wobei ja das "Verstecken" der entsprechenden Fehlermeldungen auch nichts daran ändert, daß die Probleme weiterhin bestehen.

Wer den Edge-Router die DynDNS-Aktualisierung übernehmen läßt (und der ist nun mal der "Eigentümer" der öffentlichen Adresse), wird bei AVM-Geräten auch selten Probleme haben ... wer das anders handhabt, muß sich ohnehin auch noch zu anderen Aspekten dieses Themas Gedanken machen und nicht nur zur Frage, wieviele Einträge das Protokoll verträgt - wobei schon das Zusammenfassen mehrerer identischer Einträge zu einem einzelnen eine "AVM-Spezialität" ist, die nur bei wenigen anderen Geräten zu finden ist - und auch ihre Schattenseiten hat, weil den vorhergehenden Einträgen die Zeitstempel fehlen und man damit keine Intervalle u.ä. erkennen kann.

Wobei dann auch sofort auffällt, daß AVM immer noch keine Syslog-Protokollierung ermöglicht, wo dann auch jeder Syslog-Server selbst seine Filterung bestimmen könnte. DAS wäre (gerade für die Leute, die auch andere Geräte im Netzwerk haben und fast jedes (Kauf-)NAS stellt heute auch einen Syslog-Server als Erweiterung bereit) dann mal ein lange überfälliges Feature, zumal AVM inzwischen intern sogar den Syslog-Mechanismus benutzt (wenn auch weiterhin nur mit einem Ringpuffer) bei einigen Einträgen.
 
  • Like
Reaktionen: eisbaerin
Au mann, es ging mir nur um die überflüssigen Meldungen, dass meine korrekt aktualisierte DynDNS-IP wie erwartet nicht der lokalen AVM-WAN-IP entspricht. Mein Problem ist dann eben nur, dass nach ca. 3 Tagen die ersten möglicherweise Information enthaltenen Meldungen überschrieben wurden. Komischerweise habe ich seit 2 Jahren keinerlei VPN-Probleme mit meiner in einem Dritte-Welt-Land (Brandenburg) gar nicht so exotischen Routeranordnung.
 
Au mann, es ging mir nur um die überflüssigen Meldungen
Ich lese in
nur die stur auf WAN-IP = DynDNS-IP beharrenden AVM-Funktionen
halt etwas anderes - nämlich die Ansicht, das wäre "so nicht ganz richtig", was die Box da macht und würde Dir gar nichts bringen, also sollte man das eher "abstellen" oder so machen, "wie alle anderen".

Und selbst der geäußerte Wunsch nach unterschiedlichen "log levels" erscheint mir (aus dem Blickwinkel der Nützlichkeit "für die Allgemeinheit") etwas zu kurz gesprungen bzw. gedacht. Während Dich als Beispiel die Meldungen des DynDNS-Clients der FRITZ!Box stören, sind es beim nächsten vielleicht die zum WLAN.

Ich hänge hier mal spaßeshalber die Liste der EventLog-Meldungen von FRITZ!OS 7 (113.07.11) ran (es sind 1174 mögliche Meldungen) - Du kannst Dir ja schon mal überlegen, wieviele Log-Level man bräuchte und welche Messages Du welchem Log-Level zuordnen würdest - immer mit dem Gedanken im Hinterkopf, daß andere FRITZ!Box-Besitzer vielleicht andere Schwerpunkte setzen würden.

Die übliche Ordnung unter Linux für (Sys-)Log-Messages (nach "severity" und "facility" unterschieden) ist Dir ja vermutlich bekannt ... wie bringt man diese jetzt (wenn man keine eigenen Log-Level erfinden will) jemandem nahe, der sich mit dem Thema "Log-Files und deren Filterung" nicht auskennt und trotzdem seine FRITZ!Box möglichst nicht so verkonfigurieren soll, daß sie (a) unsicher ist oder (b) gar nicht mehr läuft? Das dürfte ja für die Mehrzahl der FRITZ!Box-Besitzer zutreffen - und genau für diese macht auch die von Dir bemängelte "Sturheit" des AVM-DynDNS-Clients wieder Sinn bzw. vermutlich profitierst Du sogar von ihr, ggf. ohne es zu wissen.

Jedenfalls besteht der Wunsch nach einem konfigurierbaren Syslog-Server im LAN ja schon sehr lange (und DAS können nun wirklich sehr viele andere Geräte, sofern sie nicht von AVM stammen) ... das dürfte auch weiterhin die sinnvollere Lösung bei der Umsetzung sein (als "Grund" wurde ja die Befürchtung angegeben, diese wiederholten Meldungen würden andere, wichtigere Nachrichten verdrängen, was bei einer Speicherung extern zur FRITZ!Box (und ohne Ringbuffer) ja keine Rolle mehr spielt), denn die (spezialisierte) Software zum Aufzeichnen solcher Messages (also ein syslog-Daemon) unterstützt eine extensive Filterung von Einträgen bereits von Haus aus und das muß man ja nicht unbedingt neu erfinden.

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

Komischerweise habe ich seit 2 Jahren keinerlei VPN-Probleme mit meiner in einem Dritte-Welt-Land (Brandenburg) gar nicht so exotischen Routeranordnung.
So komisch ist das gar nicht - wobei ich (wenn Du tatsächlich die FRITZ!Box nur als kaskadierten Router betreibst und auch über genau diese das erwähnte VPN läuft) bei einer tatsächlich unterbrechungsfreien VPN-Versorgung entweder "Glück gehabt" konstatieren würde (weil die Update-Versuche der FRITZ!Box - die nach einiger Zeit nur noch in 60-Minuten-Intervallen erfolgen, wenn ich mich richtig erinnere - so zeitnah zur Zuweisung einer abweichenden öffentlichen IPv4-Adresse erfolgten, daß Du die Unterbrechung gar nicht bemerkt hast) oder ich bezweifele es sogar, sofern Du keine zusätzlichen Maßnahmen getroffen hast, mit denen die FRITZ!Box über eine Änderung der externen IP-Adresse informiert wird.

Das alles natürlich nur in dem Kontext, wo der Anschluß eine dynamisch zugewiesene IP-Adresse hat, die auch bei einem "Neu verbinden" des Edge-Routers wechselt. Ansonsten gäbe es ja keine Änderungen nach einem Verbindungsverlust und DAS ist dann schon wieder eher "exotisch" (und für viele gar nicht wirklich wünschenswert aus Datenschutzgründen)- auch bräuchte man dann gar keinen DynDNS-Service mehr, weil sich die Adresse ja nicht ändert.

Ansonsten hilft Dir hier sogar diese von Dir als Sturheit von AVM interpretierte Penetranz des DynDNS-Clients ... der führt nämlich dann auch weiterhin (allerdings in größeren Abständen) neue Versuche aus, den DynDNS-Server zu aktualisieren und dabei erhält dieser Server dann nach einem Wechsel der externen IP-Adresse auch diese Information automatisch (egal, was die Box selbst sendet).

Würde AVM hier diese "Sturheit" (ich zitiere ja nur Deine Ansicht, die Du oben zum Ausdruck gebracht hast) nicht aufbringen und die "Nachkontrolle" erst gar nicht machen oder so lange einstellen, bis der Box eine erneute Änderung der externen Adresse bekannt wird bzw. bis sich ihre eigene WAN-IP ändert (was dann auch eine Aktualisierung des DynDNS-Services erfordert), hättest Du vermutlich sogar eher schlechte Karten mit Deinem VPN, wenn es tatsächlich in der skizzierten Konfiguration arbeitet.

Wäre diese Nachkontrolle hier gar abschaltbar (was ich auch begrüßen würde, leider geht das im Moment nicht mal über irgendwelche Interna, soweit ich das kenne) und der FRITZ!Box-Besitzer versteht die Zusammenhänge nicht oder baut keine eigenen Mechanismen zur Benachrichtigung von kaskadierten Routern ein, wäre das VPN-Problem jedenfalls vorprogrammiert - wer sollte denn die neue Adresse beim DynDNS-Server ansagen, wenn die FRITZ!Box gar nichts davon mitbekommt, daß sich die externe Adresse des Anschlusses (also hier des LTE-Routers) geändert hat?

Zwar ist das mit dem DynDNS-Client im Moment auch nicht wirklich zeitnah, aber es findet (und zwar nur dank der erwähnten Kontrolle, so sinnlos die nach Deiner Ansicht auch ist) wenigstens statt ... ohne dieses Feature hättest Du dann das nächste Problem und AVM muß sich nun entscheiden, welches Szenario häufiger vorkommt bei den FRITZ!Box-Besitzern. Da finden vermutlich viele das derzeitige Verhalten und die "Sturheit" von AVM (hinsichtlich des DynDNS-Clients) gar nicht so verkehrt (immerhin haben sie dann auch bei diesem Aufbau nach max. 60 Minuten eine aktuelle DynDNS-Adresse) und würden dann auch nur ungerne darauf verzichten, weil es viel komplizierter sein dürfte, der FRITZ!Box die Änderung der IP-Adresse am WAN-Anschluß des Edge-Routers irgendwie zu vermitteln.

Wenn das bei Dir anders laufen sollte (also nicht die FRITZ!Box als kaskadierter Router läuft bzw. Dein VPN nicht über die FRITZ!Box realisiert ist), glaube ich Dir aber unbesehen - nur stellt sich dann die Frage, warum unbedingt die FRITZ!Box (und nicht doch der Edge-Router) die Verwaltung der DynDNS-Aktualisierung übernehmen soll.

Wenn dieser Edge-Router selbst dafür zu doof ist (solche Geräte soll es z.B. von Huawei geben, wobei da häufig der bestellende OEM bzw. Provider der limitierende Faktor bei der Intelligenz einer Firmware ist), sollte man eher die FRITZ!Box "hochleben lassen", weil sie wenigstens diese Funktion (wenn auch nicht ohne Makel) realisiert - da dann von "stur" zu reden, klingt halt eher nicht nach "Ich feiere die Firmware und erkenne ihren (ungewöhnlich großen) Funktionsumfang an, der selbst mein eigenes "Mißbrauchsszenario" noch einigermaßen verläßlich umsetzen kann."

DAS war auch der Punkt (diese m.E. unberechtigte Kritik an der Implementierung, die mit dem "stur" zum Ausdruck kam und dem "sinnlos" in #3201), bei dem ich überhaupt erst eingestiegen bin ... neben Deinem zum Ausdruck gebrachten Mitleid für die - in Deinen Augen zumindest - zu geringe Vorstellungskraft anderer Akteure hier.

Ähnliche Feststellungen (a la "Das ging bisher auch immer so, selbst wenn das so gar nicht vorgesehen war und jetzt kann AVM das ja nicht einfach wieder entfernen.") gab es immer wieder mal bei Änderungen (von Fehlerkorrekturen bis Security-Fixes) von AVM - ich frage mich heute noch, warum die Leute, in deren Augen das damals "gar nicht ging" (u.a. der Wegfall von Portfreigaben in das Gastnetz, um mal ein Beispiel zu nennen), immer der Ansicht waren (oder vielleicht noch sind), die von ihnen genutzen "Funktionsabweichungen" müßten bei allen anderen FRITZ!Box-Besitzern auf dieselbe Euphorie treffen, wie bei ihnen bzw. ihre Sichtweise und ihr Verständnis wären nun die einzig möglichen Varianten. Entscheidend ist das, was man auf der Basis der Dokumentation "erwarten" kann ... wenn es da Abweichungen zur Realität gibt, ist das ein Mangel (an Funktion). Wenn man etwas benutzt, was dafür gar nicht vorgesehen ist (und das offenbar auch noch weiß), würde ich nicht direkt mit der "Schuldzuweisung" beim Hersteller beginnen.

Es ist doch einigermaßen klar, daß eine Firmware von AVM in erster Linie zwei Kriterien erfüllen muß: Sie muß erstens sicher sein (das würden wohl die meisten unterschreiben) und sie muß (b) einigermaßen universell einsetzbar sein - was am Ende eine wahnsinnige Spannbreite von Szenarien abdecken muß. Das geht schon beim DSL-Frontend und der dort eingesetzten Firmware los - das "Meckern" von einigen, bei denen sich die Sync-Werte mit einer neuen Firmware etwas verschlechtert haben, kann man hier praktisch bei jeder Version nachlesen; die Frage, ob es sich für andere Anschlüsse (von der Technologie (ADSL2 bis SVDSL) bis zum DSLAM als Gegenstelle und dessen Firmware-Version) vielleicht auch mal verbessert hat, interessiert diese Leute dabei halt nicht. Das mag man noch (in Grenzen) verstehen ... aber dann sollten diese Leute sich auch mal überlegen, was sie sagen würden, wenn sie nächste Woche einen anderen DSLAM vom Provider vor die Nase gesetzt bekommen und die Firmware dann mit diesem nur deutlich schlechter arbeitet - wie bei den anderen, die sie selbst bisher nicht weiter interessier(t)en.

Die FRITZ!Box-Firmware ist eindeutig ein Kompromiß ... für "Fachleute" hat sie (im GUI) viel zu wenige Einstellmöglichkeiten und für Laien ist sie gerade so noch geeignet (wenn auch weit besser, als bei anderen Herstellern). Wenn AVM also ändert, muß man dabei immer ALLE Kunden im Blick behalten ... das sollte man auch bei seinen Wünschen machen, sonst geht's einem wie dem Fischer (der wurde auch nicht Papst, nach dem Kaiserthron war Schluß) und der DynDNS-Client ist (ohne Kopfstände) gar nicht mehr zu benutzen, wenn die Box eine nicht-öffentliche IP-Adresse erkennt (was sie ja bereits kann, wie man an den Texten im GUI sieht).

Eigentlich müsste es auch für AVM sonnenklar sein, dass eine Fritzbox hinter einem Router, den man nicht in den Bridge-Modus konfigurieren kann oder will, am WAN-Port niemals eine öffentliche IP erhalten wird. Daher ergeben in diesem Fall weder die DynDNS-Prüfung noch die MyFritz-Zuordnung einer lokalen IP irgendeinen Sinn.
Unter diesem Aspekt kann man dann auf das oben Stehende (ja, das ist ein "Vollzitat", aber man kann da bei einem mageren Knochen halt kein Fleisch mehr wegschneiden) auch so interpretieren, daß (a) der Kunde selbst daran schuld ist, wenn er eine Funktion benutzt, die in diesem Szenario tatsächlich keinen Sinn macht oder es sogar (und das wäre dann "b") als "vernünftige Reaktion" von AVM ansehen, wenn man in der Firmware den DynDNS-Client (zumindest für IPv4 und nur dafür dürfte das "skizzierte Problem" ja auftreten) komplett totlegt, wenn die Box keine öffentliche Adresse erhält.

DAS würde dann deutlich mehr Leute treffen ... wäre aber auch eine "valide Reaktion" auf "Meckereien" (und noch einmal: hier meine ich das "stur daran festhalten" und nicht den Wunsch nach besserer Log-Filterung, auch wenn ich den Ansatz mit irgendwelchen LogLevel-Zuordnungen für Unsinn halte), weil die (hier mißbräuchlich genutzte) Funktion nicht genau den Vorstellungen entspricht.

An der Tatsache, daß AVM das praktisch "ansagt", daß hier mit Problemen zu rechnen ist (so "stur" ist man dort dann doch), beißt die Maus ja keinen Faden ab - sowohl der Hinweistext im GUI als auch die Online-Hilfe (hier am Beispiel der 7490: https://service.avm.de/help/de/FRITZ-Box-Fon-WLAN-7490/018/hilfe_dyndns) sind da sehr deutlich, wenn man bereit ist, das zu lesen. Da ist immer sehr richtig von der "öffentlichen Adresse der FRITZ!Box" die Rede und nicht vom "Internetanschluß" des FRITZ!Box-Besitzers - schon an Deinem Szenario erkennt man ja, daß das nicht zwangsläufig dasselbe sein muß.

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

Das paßt zwar alles nicht richtig in den "Wünsche"-Thread (solche längeren Diskussionen), aber wenn jemand bei einem solchen Wunsch seine eigene Sichtweise einbringt, kann man ja auch als "Wünscher" noch einmal überlegen, ob das gewünschte Feature nicht doch nur dem eigenen, ggf. etwas auf die eigenen Probleme verengten, Blickwinkel entspringt und für die meisten anderen Kunden gar keinen richtigen Sinn ergibt. Selbstverständlich kann das aber auch mir so gehen ... deshalb kann man sich ja trotzdem noch einigermaßen vernünftig "austauschen".

Zwar ist ein hier geäußerter Wunsch ja auch noch lange kein Grund, daß AVM etwas tatsächlich implementiert ... aber man muß mit einer "Nachfrage", warum man sich so ein Feature wünscht und es nicht anderweitig realisiert, ja trotzdem nicht zwangsläufig so umgehen, als hätte der Fragesteller nicht alle Tassen im Schrank. Es gab schon genug Leute hier, die erst nach dem Äußern eines solchen Wunsches erfahren haben (und zwar auch in diesem Thread), wie sie sich auch anderweitig helfen könn(t)en.
 

Anhänge

  • eventlog_messages.txt
    78.8 KB · Aufrufe: 6
IPS (und/oder AV-System) wünschenswert.

Es gab' mal eine alternative Firmware, in welcher ein kleines IPS (k.A. welche Engine, Snort/Suricata etc.?) mitlief.
Mir ist klar, dass die Performance der Fritten seeeeehr begrenzt ist, aber grundlegend auf bekannte "malicious Hosts", Botnets und sonstig auffällige IPs, Subnets und/oder Provider/Hoster zu scannen (ggf. mit lokalem, stündlich oder täglich aktualisierten Cache) sollte ja drin sein.

Von einem Full-Features IDS/IPS (gar mit L7-Proxy) mag ich jetzt ja garnicht reden, da gibts andere Möglichkeiten (in einer hinterhergeschalteten VM z.B.).
Was ist denn aus diesem Firmware-Test geworden?

- Ein OpenVPN-basierter Zugang wäre auch sehr schön (und wesentlich einfacher).
- Mehrere IPs auf den jew. zugewiesenen Switchports (oder VLANs) wäre wünschenswert (IoT/SmartHome etc. getrennt vom restl. Netz) und nein, sowas will ich auch nicht im Gastnetz laufen lassen.
 
Was ist denn aus diesem Firmware-Test geworden?
Dieses Feature (bei AVM "candc" genannt, wohl weil es meistens Command&Control-Server sind, die da auf der Blacklist stehen) ist m.W. in den Inhouse-Versionen immer noch im Test - in die Release-Versionen hat es noch keinen Einzug gehalten. Außerdem war das eigentlich nur eine Erweiterung des Blacklist-Features - kein "echtes" "Intrusion Prevention System" (und auch die "Detection Abilities" sind nur rudimentär angelegt).

Man weiß ja auch nicht so genau, was man davon halten soll ... einerseits ist es natürlich ein nettes Feature, bestimmte Adressen schon "paternalistisch" zu blockieren für Nutzer, die sich um nichts kümmern wollen ... andererseits ist das wieder der erste Schritt zum "Zensur-Router" für ebendiese Gruppe (die dann auch nicht weiß, wie sie das Feature ausschalten soll) und bestärkt ggf. wieder die "Filterblasen"-Theorie.

Ein lokal administriertes IDS/IPS in einer Firma (oder auch bei einem interessierten Privatmann) ist eben noch etwas anderes, als ein automatisch ausgelieferter "Internet-Filter", der an Millionen Anschlüssen den Zugriff auf bestimmte Sites blockiert ... wer die Kontrolle über die Filterliste hat, kontrolliert auch (in gewissen Grenzen), was diese Nutzergruppe im Internet sieht und was nicht.

Wenn das tatsächlich überprüfbar wäre, was in der Liste alles gelandet ist, ist das wieder eine andere Geschichte ... das ist ja die alte Kritik an der Filterliste der BPjM. Es gab mal einen Leak (da hat jemand einfach die URLs bekannter Sites selbst gehasht und mit dem Inhalt der Liste verglichen, um so auf die URLs zu kommen, die dort enthalten waren) und der zeigte u.a. auch, daß die "Wartung" dieser Liste doch sehr zu wünschen übrig ließ. Das gilt natürlich auch für alle anderen Listen dieser Art, gerade dann, wenn sie ihren Inhalt "geheimhalten" wollen, um nicht direkt als Linksammlung zu unerwünschten Inhalten zu dienen.

Das von AVM verwendete Format ist jedenfalls undokumentiert (soweit ich das kenne ... und ich habe ausführlich in diesem Kontext gesucht; es soll irgendwas mit JSON sein, nur ist das halt gepackt mit unbekannter Struktur und unbekanntem Algorithmus) - die Datei kann man sich (sofern man eine Version installiert hat(te), die diese Liste von AVM lädt/lud) unter "/var/media/ftp/FRITZ/candc.data" ansehen (mein alte Version ist z.B. vom 05.06.2019). Es gibt ja so einige Quellen im Netz für solche Listen von C&C-Servern (von Spamhaus bis zu Twitter-annoncierten Listen wie dieser für Emotet: https://paste.cryptolaemus.com/emotet/2019/06/21/emotet-malware-IoCs_06-21-19.html) ... aus welcher Quelle sich AVM da für die eigenen "Umarbeitungen" bedient, hat man (m.W. wieder) auch noch nicht in der Öffentlichkeit bekanntgegeben (vielleicht auf irgendwelchen Road-Shows mal, aber das hat keine (such- und findbaren) Spuren im Netz hinterlassen, afaik).

So sieht man das immer mit einem lachenden und einem weinenden Auge ... was AVM am Ende davon abhält, das in die öffentlichen Versionen zu integrieren (aus den Labor-Versionen ist es ja inzwischen auch wieder verschwunden), ist m.W. auch nie offiziell geworden. Da kann man nun raten, ob es zu geringe Erfolge sind (die Inhouse-Versionen berichten ja fleißig an AVM, wenn sie etwas in dieser Richtung finden - und das ist (nach dem, was ich bisher gesehen habe) auch nicht abstellbar durch den Besitzer, wenn das Feature aktiv ist), die von einem finalen Ausrollen des Features abhalten oder ob es nicht doch Datenschutzbedenken sind ... denn das "Reporten" von aufgerufenen IP-Adressen an den Router-Hersteller (auch wenn es sich um Malware-Server handeln mag) ohne ausdrückliche Einwilligung des Benutzers dürfte zumindest etwas problematisch sein.
 
Magic Paket:
Ich wünsche mir den Befehl "Computer starten" der aktuell im Netzwerk, Gerät suchen, dann Detail aufrufen ganz rechts unten sichtbar wird gleich als Button der Netzwerkansicht neben dem "Detail" und Lösch-Button.
Oder auch wenn man auf den Gerätenamen klickt kann doch gleich mal ein Magic Paket losgeschickt werden solange das Gerät nicht unter den aktiven Geräten aufscheint.
Wenn es einmal aktiv ist wird stattdessen ein neuer Tab mit der IP gestartet wie bisher.

Mesh-Einstellungsübernahme
Hier wünsche ich mir, daß man eine "generelle" Einstellungsübernahme bei Mesh-Nodes aktivieren kann, jedoch in JEDEM davon betroffenen Unterbereich ein "Disable" damit man nur für den Punkt andere Einstellungen vornehmen kann, unteschiedl. Funkkanal usw. oder etwa auch Zeitsteuerung vom WLAN.
 
  • Like
Reaktionen: kleinkariert
Ich wünsche mir, dass das Anlegen eines Google-/Gmail-Telefonbuchs "wieder" möglich ist.
 
Ich wünsche mir immer noch, dass mehrere Nachrichten auf der integrierten Mailbox markiert und zusammen gelöscht werden können.
Weiterhin, dass man eine Ansage bekommt, wenn der AB-Speicher voll ist.
 
Smarthome bei den Fritzboxen:
Ich wünsche mir das der Standardtab beim Wählen eines Gerätes einstellbar ist.
Jetzt lande ich immer auf dem statischen "Allgemein" Tab der mich normalerweise nicht interessiert.
Die veränderlichen "Energieanzeige" oder "Temperatur" will ich aber sehen.
 
Ich wünsche mir einen Alexa Skill von AVM. Zum Schalten des WLAN, Gastnetz, AVM-Heizkörperventile, Steckdosen, ...

Außerdem finde ich, dass der Punkt "-Fritz vom Internet aus konfigurierbar (evt. per ssh...)" nicht wünschenswert ist, denn das wäre eher ein Sicherheitslücke als Fortschritt. Mit nem VPN-Zugang ist das jetzt schon einfach und sicher möglich.
 
@fritz-fuchs Deswegen sagte ich ja Skill von AVM und nicht von einem Dritten. Den kenne ich schon und funktioniert meistens auch ganz gut.
 
WPS & Gast-WLAN und falls es noch nicht kam:
Aktuell kann ich im Mesh nur an der Master-Box eine WPS-Anmeldung am Gastnetz machen. Diese Hürde gab es anfangs generell beim WPS. Dazu wäre es noch wünschenswert, wenn man optional das Knopf-WPS auf Gast-WLAN umstellen könnte.
 
Du kannst WPS doch jetzt schon spezifisch entweder unter Sicherheit Tab WPS-Schnellverbindung zur normalen SSID bzw. unter Gastzugang selbiges für die Gast-SSID aktivieren.
Bezügl. Mesh-Nodes hab ich das noch nicht ausprobiert, da die Master überall zumindest noch soviel erreichbar ist um sich wenigstens über 2,4G verbinden zu können, dann buchen sich die Geräte selber in die stärkste Box um und gehen auf 5G.
Interne Geräte zur Haupt-SSID verbindet man doch nicht so oft, das geht genauso über die Oberfläche, mußt dann sicher eh noch gleich aufs Gerät zugreifen.

Wäre viel zu unsicher wenn jeder der vorbeigeht gleich Zugang in dein Intranet bekommt!!!
 
Ich weiß nicht ob der Wunsch schon da war

ich wünsche mir das ich die leitungslänge auch bei adsl2+ 995.2 B sehe kann !!
 
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.