[Info] FRITZ!Box 7490 FRITZ!OS 6.92 vom 09.11.2017

[_fbfuser_]

Was ist eigentlich aus dem Punkt: "Smarthome-Funktion im FRITZ!Box-Heimnetz freigeben" geworden, der in einer der letzten Betafirmwares gelöscht wurde?

Seitdem kann ich die DECT Steckdose kaum schalten.

 

[BroFri]

Was ist eigentlich aus dem Punkt: "Smarthome-Funktion im FRITZ!Box-Heimnetz freigeben" geworden

Den hat AVM entfernt. Hatte dazu mit AVM folgenden Mailverkehr:

Ich:
In meinem Netzwerk sind 2 x 7490 und eine 7390 vorhanden. Eine 7490 ist als Router geschaltet.
An ihr hängen am LAN 1 eine weitere 7490 und eine 7390, welche als IP-Client konfiguriert sind!

Die beiden 7490 sind mit Datei auf 113.06.90 aktualisiert worden.
Die Router 7490 dient als DECT-Basisstation und WLAN ist auch aktiv. Die 7390 dient auch gleichzeitig als DECT-Repeater und WLAN-AP.

Mesh spielt bei mir keine Rolle, da die 7390 (06.83) dies nicht unterstützt.

Jetzt zu SmartHome:

Ich habe in meinem Netzwerk 4 x DECT 200 angeschlossen. Vor dem Update konnte ich von jeder Fritzbox (und auch FHEM) aus jeden DECT 200 schalten, jetzt geht das nur noch von der Fritzbox aus an welcher die entsprechende DECT 200 angeschlossen ist.
Damit sind die SmartHome Funktionen nicht mehr verfügbar. Der Menuepunkt:
"Smart-Home-Funktion im FRITZ!Box-Heimnetz freigeben"
ist auch weggefallen. Es scheint diese Funktion deaktiviert zu sein. Wo kann man jetzt diese Funktion wieder freigeben damit SmartHome im gesamten Heimnetz funktioniert? Es kann ja nicht sein, dass mit einem Update eine Funktion wegfällt.

AVM:
Nach dem Update kann ich Ihre Beobachtungen bestätigen.

Die Option "Smart-Home-Funktion im FRITZ!Box-Heimnetz freigeben" wird an FRITZ!-Access-Points mit Mesh-fähigem FRITZ!OS (6.90 / 6.91) unter "Heimnetz > Netzwerkeinstellungen > Heimnetzfreigaben" nicht mehr angezeigt. Vielmehr ist diese innerhalb des Mesh-Netzwerks automatisch aktiv.

WICHTIG:

In einem Misch-Szenario, indem sich sowohl FRITZ!--Access-Points mit als auch welche ohne Mesh-Funktion im Heimnetz befinden, ist die Freigabe bzw. der Zugriff auf Smart Home-Funktionen zwischen diesen Geräten nicht (mehr) möglich.

Ich:
Vielen Dank für ihre schnelle Antwort und die Bestätigung, dass Teile
der SmartHome-Funktionen durch die neue Firmware entfernt wurden.
Nun stellt sich die Frage ob dies ein Versehen war oder gewollt wurde?
Ist es AVM-Strategie sich nach und nach aus dem SmartHome-Szenario
zurückzuziehen? Vielleicht gibt es eine Nachbesserung in einem späteren
Release damit die Funktionalität wieder vorhanden ist? Wenn nicht,
müsste ich meine DECT 200 Komponenten versuchen zu verkaufen und auf
andere Anbieter zu wechseln, die "SmartHome"-Komplettlösungen anbieten.

AVM:
Ich kann Ihre Skepsis aus Nutzer-Sicht nachvollziehen, diese ist jedoch unbegründet.

Es ist keinesfalls geplant, dass AVM sich aus dem Smart-Home-Bereich zurück zieht.

Das Verhalten stellt sich nun im einem Misch-Szenario aus Mesh-fähiger und nicht-Mesh-fähiger Firmware so dar, dass die Schaltung und die Anzeige von Smart-Home-Geräten an der FRITZ!Box statt findet, an dem diese auch gekoppelt sind. Ich gebe Ihnen recht, dass hier ein gewisser Komfort verloren geht, die grundsätzliche Funktion steht aber weiterhin zur Verfügung.

 

[stronzo46]

Wenn aber im Client eine feste IP hinterlegt wurde, sofern überhaupt möglich @Shirocco88 und @H'Sishi den richtigen Riecher!

Wäre möglich, war aber in beiden Geräten nicht der Fall.Beide hatten keine feste IP hinterlegt.Schon komisch, aber egal.Problem gelöst.Vielen Dank.


Gesendet von meinem SM-G935F mit Tapatalk

 

[PeterPawn]

Auch diese Version hat immer noch ein Problem mit dem "voipd".

Folgende Konfiguration:

• 7490 als IP-Router (also ohne Modem, Internetzugang über LAN1) hinter einer anderen FRITZ!Box (6490, spielt aber keine Rolle für das Problem)
• es ist eine statische Route zu 192.168.0.0/16 (ganz normal über das FRITZ!OS-GUI eingetragen) zu einem anderen lokalen Gateway konfiguriert
• es ist auf dem WAN-Interface eine Telefonnummer konfiguriert, die als Registrar die 6490 verwenden soll
• auf dem WAN-Interface erhält die 7490 per DHCP eine Adresse aus dem Segment 192.168.xxx.0/28 von der 6490 ("xxx" ist natürlich nicht dieselbe Angabe wie im LAN)

Auftretender Fehler:

• der SIP-Client der 7490 meldet sich nicht bei der 6490 an nach einem Neustart der 7490

Ursache (zumindest nach meinen bisherigen Tests):

• der "voipd" ordnet offenbar den einzelnen SIP-Clients direkt bei seinem Start das entsprechende Interface zu, das ist wegen der zusätzlichen Route für 192.168.0.0/16 zu diesem Zeitpunkt halt noch "dev lan" (oder "homenet", um mit dem "voipd" zu sprechen)
• die WAN-Verbindung ist zu diesem Zeitpunkt wohl noch nicht hergestellt, damit ist die (genauere) Route zu 192.168.xxx.0/28 noch nicht aktiv

Möglicher Workaround:

• hat man Shell-Zugang, kann man - ohne jede andere Konfigurationsänderung - durch Stoppen und Neustart des "voipd" dafür sorgen, daß nunmehr das richtige Interface ("internet" im "voipd"-Jargon) für die Verbindung ausgewählt wird

Offenbar hilft es nicht einmal mehr, wenn man über den "dsld" (bzw. den "multid") ein "Neu verbinden" auslöst ... dem ersten Anschein nach wird dabei der "voipd" auch nicht neu gestartet, sondern lediglich zur erneuten Registrierung aufgefordert.

Da es sich bei allen geschilderten Einstellungen eigentlich um "legale" Möglichkeiten handelt (und das auch wirklich nur über das GUI konfiguriert wurde bzw. konfiguriert werden kann), ist das (auch wenn die Route für 192.168.0.0/16 ein Spezialfall sein mag) irgendwo auch ein Bug in der Firmware - allerdings bringt diese Route ja auch an anderen Stellen (z.B. beim VPN, wo sie der Annahme, daß der zu verschlüsselnde Verkehr automatisch an "dev dsl" geht, zuwiderläuft) Probleme. AVM hat hier zwar den Text:

Achtung!
Änderungen auf dieser Seite können dazu führen, dass die FRITZ!Box nicht mehr erreichbar ist. Beachten Sie unbedingt die Hilfe, bevor Sie Änderungen vornehmen.

im GUI untergebracht, aber auch die angesprochene Hilfeseite fördert nicht wirklich Erleuchtendes für diesen Fall zutage.

Warum schreibe ich das überhaupt auf? Weil immer wieder auch die Meinung auftaucht, über das GUI dürfte sich eigentlich nichts konfigurieren lassen, was die FRITZ!Box "unusable" macht. AVM hat ja an einigen Stellen bereits zusätzliche Prüfungen eingebaut ... wobei das hier mit dieser Route ja tatsächlich eine plausible Konfiguration ist, die in passenden Netzwerken eben dafür sorgt, daß jeder Traffic für eine "private" Adresse aus 192.168.0.0/16 an ein anderes Gateway gesendet wird, solange keine genauer spezifizierte Route für die Zieladresse existiert.

Insofern ist das Verhalten der AVM-Firmware wohl tatsächlich ein Fehler ... beim Aktivieren einer VPN-Verbindung (LAN-LAN) müßte eine Route für das entfernte Netzwerk über "dev dsl" hinzugefügt werden (dazu habe ich mind. drei Tickets Anfragen über die Jahre bei AVM aufgemacht) und der "voipd" müßte vor der Registrierung einer Rufnummer noch einmal prüfen, ob er wirklich das richtige Interface verwendet - bzw. spätestens bei einem Fehler (Timeout) in der Fehlerbehandlung die zuvor getroffene Zuordnung noch einmal prüfen.

Bis AVM hier etwas korrigiert, muß man sich halt mit eigenen Erweiterungen oder Korrekturen der Firmware zu helfen wissen.

 

[Benares]

Hallo PeterPawn,
findest du dieses Problem nicht etwas an den Haaren herbeigezogen?
Klar sollte eine genauere Route zu 192.168.xxx.0/28 präferiert werden, selbst wenn eine ungenauere, statische Route zu einem anderen Gateway wie 192.168.0.0/16 existiert. Und dass sowas an einigen Stellen einfach nicht berücksichtigt ist, kann ich mir ganz gut vorstellen.
Aber warum sollte man sowas tun - ganz ohne Not?

 

[PeterPawn]

Die Frage ist doch gar nicht, ob das irgendwo "berücksichtigt" wird oder nicht ... wenn so ein Routing-Eintrag existiert (und er kann problemlos eingerichtet werden), arbeitet die Firmware schlicht nicht richtig.

Warum ein solcher Eintrag Sinn machen kann, habe ich oben beschrieben und ich hätte das auch kaum bemerkt, wenn ich es nicht genauso bei mir konfiguriert hätte, weil ich das brauche, wenn ich nicht 30 (und mehr) einzelne Routen zu Netzwerken mit 192.168.yyy.0/24 als verwendetes Segment konfigurieren will.

Am Ende scheitert es auch nur daran, daß AVM in eigenen Komponenten halt Annahmen trifft, die nicht zwangsläufig richtig sind bzw. sein müssen ... und in neuerer Firmware wird auch nichts mehr unterstützt (z.B. statische Routen, die nicht über "dev lan" gehen), mit dem der Kunde das selbst korrigieren könnte.

Also: "Nein, ich finde das nicht an den Haaren herbeigezogen."

Es ist eine (unerwartete) Abweichung im Verhalten des FRITZ!OS ... das heißt noch lange nicht, daß ich mit einer Korrektur durch AVM rechne bzw. ich weiß mir schon selbst zu helfen. Trotzdem halte ich die Beschreibung hier (auch als Fehler) für legitim, denn ggf. stehen auch andere vor einem ähnlichen Problem und dann ist zumindest schon mal die Ursache geklärt.

Das mit dem VPN habe ich auch nicht zum ersten Mal hier im IPPF beschrieben und irgendwo gibt es iirc sogar ein Skript, mit dem man den Zustand einer VPN-Verbindung abfragen kann, damit man dann eben selbst die notwendige Route für das entfernte LAN einrichten kann, wenn eine VPN-Verbindung aktiviert wird.

Das Phänomen mit dem "voipd" ist allerdings (zumindest für mich) durchaus neu (deshalb konzentrierte sich der vorhergehende Beitrag auch auf dieses Problem und erwähnte VPN nur am Rande) ... ich schreibe es zusätzlichen Sicherheitsmaßnahmen bei AVM zu, die verhindern sollen, daß "martian sources" für SIP-Verbindungen verwendet werden können und auf anderen Interfaces SIP-Dialoge gestartet werden. Das ist an sich sehr löblich ... nur ist halt (so würde ich das jedenfalls aufgrund meiner Tests und der Erfahrungen daraus schlußfolgern) der Zeitpunkt für diese "Festlegung" der falsche bzw. die einmal getroffene Entscheidung muß ggf. revidiert werden, wenn sich die Netzwerk-Umgebung (valide) ändert und eine IP-Zuweisung an das WAN-Interface infolge eines DHCP-Requests ist in meinen Augen so ein Auslöser.

 

[Benares]

Hallo PeterPawn,
>daß AVM in eigenen Komponenten halt Annahmen trifft, die nicht zwangsläufig richtig sind bzw. sein müssen
Denk dran, dass AVM lange Zeit annahm, das es nur eine FB im LAN gibt (ich sag nur mal "fritz.box"), Dass man weiteren Fritzboxen eigene Namen geben konnte, kam erst sehr viel später. Das scheint mir immer noch alles sehr "gebastelt" zu sein.
Von daher denke ich, dass AVM einfach noch nicht soweit ist, um auch komplexere Intranet-Strukturen zu berücksichtigten und da noch einige Leichen im Keller hat. Dein Beispiel mag nur eines von vielen sein.

 

[H´Sishi]

Hdass AVM lange Zeit annahm, das es nur eine FB im LAN gibt (ich sag nur mal "fritz.box"),

Das dachten sie bei den Repeatern auch - mittlerweile haben die ein extra Eingabefeld "Repeater-Name".

 

[PeterPawn]

@gmeyer:
Dieser von mir beschriebene Fehler schließt natürlich nicht aus, daß es weitere gibt.

Aber auch ein Beispiel von vielen kann ja als Beleg dafür herhalten, wo da nachzubessern ist und wenn es weitere gibt, sollte man sie ebenfalls aufschreiben.

Im Idealfall kann man beim Beheben von Fehlern dann nach einem gemeinsamen Nenner suchen und mit einer (vernünftig geplanten) Änderung mehrere Fehlerbilder auf einen Schlag behandeln.

Das hat dann auch nichts mehr mit "Basteln" zu tun ... inzwischen gibt es (glücklicherweise) bei AVM ja sogar Änderungen, die auch mal alte Zöpfe abschneiden, wenn sie sich als Hemmnis für echte Verbesserungen erweisen sollten.

So richtig glücklich wären die FRITZ!Box-Besitzer vermutlich aber erst dann, wenn nicht irgendwelche Funktionen ersatzlos gestrichen, sondern durch etwas wirklich Besseres ersetzt würden - leider gibt es dieses "Streichen" aber auch ab und an mal und auch das ohne (plausible) Begründungen - das ist dann die Schattenseite dieses "neuen Selbstbewußtseins" von AVM.

 

[rotarum]

Die 6.83 liefert immer noch die besten Sync Werte!

6.90 und 6.92 haben etwa 3-4 Mbit weniger im Download und etwa 1 Mbit weniger im Upload.

 

[morenoralfo]

## unnötiges Vollzitat entfernt ##
@rotarum
Dat spijt me zeer voor jou! Je zou maar DSL moeten hebben.

 

[ip-hape]

Meine Kombination läuft seit 6.92 sowohl auf dem Repeater, als auch auf der 7490 schlecht wie nie. Ohne Mesh ist es besser, aber weit entfernt von gut.
Wenn das nicth besser wird, werde ich den Repeater durch PowerLAN und eine 7390 (liegt noch eine im Schrank) ersetzen. Der DVB-C Tuner war eh noch nie der Renner (wird ständig zurückgesetzt) und ist mit den aktuellen WLAN-Problemen auf den mobilen Geräten überhaupt nicht brauchbar.

Seit dem Umstieg auf die 6.90 läuft es hier auch eher unbefriedigend und ich finde auch die 6.92 nicht akzeptabel, obwohl da offenbar schon ein paar Bugs behoben wurden. Habe inzwischen auch nach mehreren kurzen Versuchen mesh immer wieder deaktivieren müssen. Statt des DVB-C Tuner/Repeaters habe ich hier die Kombination aus einem 1750E mit Geniatech 4-fach-DVB-C-Receiver im Netz und ab der 6.90 laufen die Streams nicht mehr sauber. Aufnahmen haben nach einiger Zeit deutlichen Bid/Ton-Versatz, weil der Stream immer mal für bis zu ca. 1-2 Sekunden einfriert, was früher nicht oder nur sehr selten der Fall war. Habe jetzt auch mal mit AVMs-Powerlan Versuche gemacht, aber da gibts ebenfalls laufend Aussetzer abgesehen vom oder vielleicht gerade durch den deutlich geringeren Durchsatz gegenüber WLAN. Irgendwo ist noch der Wurm drin auch mit abgeschaltetem mesh und nur noch mit 5Ghz WLAN.
Die Pingzeiten mit 1,2 MSec durchs WLAN kommen mir auch etwas lang vor. Von einer AirportExtreme zu einem Macmini brauchen die Pings nur 0,2 MSec, aber das muss ja nichts heissen.

 

[H´Sishi]

Bild- und Tonspur werden beim Streamen durchgehend getrennt übertragen? Es müßte doch alle xx Sekunden so was wie einen Sync-Frame geben, der die beiden Spuren wieder synchronisiert.
Ansonsten müßte eigentlich dem streamenden Gerät auffallen, daß es zu Verschiebungen kommt und entsprechend Bild oder Ton überspringen.

Eventuell gibt's auch ein Problem beim abspielenden Gerät.

 

[ip-hape]

Bild- und Tonspur werden beim Streamen durchgehend getrennt übertragen? Es müßte doch alle xx Sekunden so was wie einen Sync-Frame geben, der die beiden Spuren wieder synchronisiert.
Ansonsten müßte eigentlich dem streamenden Gerät auffallen, daß es zu Verschiebungen kommt und entsprechend Bild oder Ton überspringen.

Eventuell gibt's auch ein Problem beim abspielenden Gerät.

Ja, so habe ich mir das eigentlich auch gedacht, dass das so sein müsste. Der Stream bzw. die max. 4 Streams vom DVB-C RX werden bei mir 1:1 von EyeTV auf verschiedenen Macs aufgezeichnet. Wenn ich diese Dateien dann wiedergebe oder auch vorher via Handbrake komprimieren lasse, ist der Versatz bei allen Playern vorhanden. Ich werde das bei nächster Gelegenheit nochmal etwas genauer untersuchen. Wenn das bei der Wiedergabe oder beim Umwandeln korrigierbar wäre, wäre der Nachteil durch die Aussetzer nicht mehr ganz so gross.

 

[stoney]

IPv6?
Hardwarebeschleunigung? (sowohl Box als auch Repeater)

 

[ip-hape]

IPv6?
Hardwarebeschleunigung? (sowohl Box als auch Repeater)

IPv6 ist schon lange abgeschaltet.
Paketbeschleunigung+Hardwarebeschleunigung waren die ganze Zeit auf FB 7490 und RPTR 1750E abgeschaltet. Habe heute mal beide neu gestartet, um mal zu sehen, ob es einen Unterschied gibt, wenn die default Einstellungen gesetzt sind.
In der FB sind jetzt beide aktiv, auf dem Repeater nur die Paketbeschleunigung.
Überall hatte ich auf Euer Anraten "WLAN für Live TV optimieren" seit der 6.90 rausgenommen. Bei der 6.83 konnte die Einstellung ohne negative Folgen aktiv sein. In der 6.90 führte es zu harten Abbrüchen der Streams nach ca. 10 Minuten.
Der Repeater zeigt mir in der Übersicht 702 Mbit/sec bei der Verbindung zwischen FB und Repeater an. Da sollte eigentlich reichlich Reserve auch nach Abzug des Protokoll-Overheads vorhanden sein.
Die Aussetzer gibt es eben auch mit nur einem HD-Stream.
Die Hardware-Beschleunigung werde ich gleich auch im Repeater mal zuschalten, wenn Du meinst, dass das helfen könnte und nachher mal beobachten, was passiert.

 

[stoney]

wenn Du meinst, dass das helfen könnte

Einen Versuch ist es zumindest wert ob es hilft ist die andere Sache

Gibt es die Aussetzter auch, wenn eine direkte LAN Verbindung besteht ?

 

[ip-hape]

Gibt es die Aussetzter auch, wenn eine direkte LAN Verbindung besteht ?

Das konnte ich noch nicht testen. Wenn ich dort eine LAN-Verbindung hätte, wäre es sicher schonmal einfacher. So vom Bauchgefühl denke ich, dass in der Fritzbox irgendwas abläuft, was das Netz immer mal ausbremst. So wie mit der IP TV Optimierung die Strems immer nach 10 Minuten hart abbrachen, knicken sie jetzt etwa in dem Rythmus für 1-3 Sekunden, manchmal auch mehr, ein. Das führt dann offenbar zu dem immer stärkeren Versatz bei einer Aufnahme, was ich aber noch mit verschiedenen Playern testen will.
Man bräuchte eigentlich ein tool, das solche Einbrüche/Unterbrechungen sofort erkennt und protokolliert, um zu sehen, welche Massnahmen evtl. greifen.
Ich hatte neulich allerdings auch schon einmal den Effekt, dass die Einbrüche/Aussetzer mit der Zeit immer stärker/häufiger wurden und nach einem Neustart der Fritzbox fast verschwunden waren. Im Moment sieht es auch noch gut aus, aber nun habe ich zusätzlich zu den Reboots die Hardwarebeschleunigung aktiviert.

 

[Malcolm]

Hallo,
kann mir jmd erklären woher die FB "Phoneresearch" als Anrufer kennt?
Bei der 7490.
Im Telefenbuch steht es nicht drin, sonst wären ja auch das Zeichen AB nicht da.
Auf der Blacklist stehen die auch noch nicht.

Danke für eure Hilfe.

 

[H´Sishi]

Ich würde jetzt eine Rückwärtssuche vermuten ... hast Du ein Google-Telefonbuch mit der Box gekoppelt, auf das mehr als eine Person mit einem Smartphone Zugriff hat?
Evtl. hat jemand diese Rufnummer als "Phoneresearch" in dieses Telefonbuch eingetragen und die Box die Rufnummer mit dem Telefonbucheintrag ersetzt.