[Info] FRITZ!Box 7590 Fritz!OS 154.07.01 Release vom 20.09.2018

Ein Bug ist das imo nicht. Ich kenne diese Meldung jedenfalls schon lange und meiner Ansicht nach liegt das einfach nur daran, dass die entsprechenden DNS-Server die neue IP-Adresse noch nicht kennen

An Securepoint bzw. dessen "Unkenntnis" kann es nicht liegen, da meine UMTS-FB auf den Kanaren Sekunden nach einer nächtlichen Neuverbindung seitens 1&1, die noch die Zwangstrennung machen, die neue IP kennt und die LAN2LAN VPN steht. Die Fehlermeldung "datiert" wenn ~3Minuten nach der Neusyncronisation/Neuverbindung. Da kennt meine UMTS-FB schon längst die neue IP und hat VPN als Initiator neu aufgebaut. In meinen Augen ist die Fehlermeldung eher überflüssig als aussagekräftig, was Handlungsbedarf dahingehend bedürfte?
LG
 
Ich habe in der Firmware "Zwangstrennung durch den Anbieter verschieben in die Zeit zwischen 3-4 Uhr." eingestellt. Normalerweise wird auch einmal nachts getrennt, siehe unten am 28.09. um 03:02.

Am 29.09. wurde allerdings 2 mal getrennt, einmal um 3:01 und einmal um 3:58. Stört nicht, ist aber auch nicht richtig.

Gruß

akapuma

Code:
29.09.18 03:58:48 IPv6-Präfix wurde erfolgreich bezogen. Neues Präfix: xxxx:xxxx:xxxx:xxxx::/xx
29.09.18 03:58:47 Internetverbindung IPv6 wurde erfolgreich hergestellt. IP-Adresse: xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx
29.09.18 03:58:47 Internetverbindung wurde erfolgreich hergestellt. IP-Adresse: xx.xxx.xxx.xxx, DNS-Server: xx.xxx.xxx.x und xx.xxx.xxx.x, Gateway: xx.xxx.xxx.xxx, Breitband-PoP: xxxxxx
29.09.18 03:58:40 Internetverbindung wurde getrennt.
29.09.18 03:58:40 Internetverbindung IPv6 wurde getrennt, Präfix nicht mehr gültig.
29.09.18 03:58:37 Die Internetverbindung wird kurz unterbrochen, um der Zwangstrennung durch den Anbieter zuvorzukommen.
29.09.18 03:01:44 IPv6-Präfix wurde erfolgreich bezogen. Neues Präfix: xxxx:xxxx:xxxx:xxxx::/xx
29.09.18 03:01:43 Internetverbindung wurde erfolgreich hergestellt. IP-Adresse: xx.xxx.xxx.xxx, DNS-Server: xx.xxx.xxx.x und xx.xxx.xxx.x, Gateway: xx.xxx.xxx.xxx, Breitband-PoP: xxxxxx
29.09.18 03:01:43 Internetverbindung IPv6 wurde erfolgreich hergestellt. IP-Adresse: xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx
29.09.18 03:01:36 Internetverbindung wurde getrennt.
29.09.18 03:01:36 Internetverbindung IPv6 wurde getrennt, Präfix nicht mehr gültig.
29.09.18 03:01:33 Die Internetverbindung wird kurz unterbrochen, um der Zwangstrennung durch den Anbieter zuvorzukommen.
28.09.18 03:03:00 IPv6-Präfix wurde erfolgreich bezogen. Neues Präfix: xxxx:xxxx:xxxx:xxxx::/xx
28.09.18 03:02:59 Internetverbindung IPv6 wurde erfolgreich hergestellt. IP-Adresse: xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx
28.09.18 03:02:59 Internetverbindung wurde erfolgreich hergestellt. IP-Adresse: xx.xxx.xxx.xxx, DNS-Server: xx.xxx.xxx.x und xx.xxx.xxx.x, Gateway: xx.xxx.xxx.xxx, Breitband-PoP: xxxxxx
28.09.18 03:02:52 Internetverbindung wurde getrennt.
28.09.18 03:02:52 Internetverbindung IPv6 wurde getrennt, Präfix nicht mehr gültig.
28.09.18 03:02:49 Die Internetverbindung wird kurz unterbrochen, um der Zwangstrennung durch den Anbieter zuvorzukommen.
 
Dieses Verhalten ist beabsichtigt. Um der Zwangstrennung alle 24 Stunden zuvorzukommen wird immer nach 23:59 h getrennt. Dadurch wandert die Trennung jeden Tag eine Minute nach vorne. Ist die Grenze 3:01 erreicht wird um 3:59 Uhr nochmal getrennt und das Spiel beginnt von vorne.
 
  • Like
Reaktionen: goa-inge
Danke, das leuchtet ein (und man hätte sogar selbst draufkommen können :()

Gruß

akapuma
 
Und jetzt wurde es hier extra für dich auch noch zum mindestens zehnten Mal erzählt. :)
Na, ich wüste nicht, wo das in den letzten 5 Jahren mal erwähnt wurde.
Ich habe es selbst erst vor kurzem NDiIPP erklärt.

Aber da kam eine interessante Frage auf:
Warum muß das immer eine Minute früher geschehen?
Ja, klar, damit man der Zwangstrennung zuvor kommt.
Aber aber warum muß man das unbedingt, wenn die Zwangstrennung dann in einer Mininute sowieso erfolgt?
Ist doch egal wer da jetzt trennt (oder gibt es da einen Unterschied?), Hauptsache es passiert zu der vorgeschriebenen Zeit.
Dann könnte man nämlich die Zeit auch richtig genau eingeben. z.B. 3 Uhr oder 4 Uhr und nicht von 3-4 Uhr.

Andererseits könnte die FB auch so "schlau" sein, wenn schon ein Resync (oder wie bei mir auch mehrere) am Tag erfolgt ist, dann kann sie auch gleich wieder bei 3:59 Uhr weiter machen und muß nicht stur ihren Plan z.B. 3:10 weiter machen, wo sie dann in wenigen Tagen die doppelte Trennung machen muß.

Und noch "schlauer" wäre:
Wenn der Resync um 3:05 war, dann muß sie gar keine Trennung machen!
Macht sie aber!

IMO ist die Resync Problematik bei den Programmierern noch nicht angekommen.
Ja, früher gab es auch nicht so viele, aber seit Vectoring ...
Ich habe z.B. in diesem Monat 24 Resyncs, aber der heutige Tag und damit Monat ist ja noch nicht zu ende ;)
Und da ich schon 2 Tage keinen hatte, ist die Wahrscheinlichkeit für heute äußerst hoch.
 
Zuletzt bearbeitet:
... oder gleich die Zwangstrennung auf eine bestimmte Zeit verlegen, damit dese dann vom Provider sekundengenau aller 24h wiederholt wird. Einfach 1x die Trennung am voreingestellten Zeitpunkt ausführen und erst dann wiederholen, wenn vorzeitig eine Trennung oder ein Sync stattfand.
 
Da die neue Verbindung auch immer 1-2 Sekunden benötigt, wird es immer einen kleinen Zeitverzug geben.

Oder man wechselt zum Anbieter der keine Trennung vornimmt, wie z.B. Telekom.

Dieses ist nicht unbedingt Thema der Firmware, Diskussion zur Zwangstrennung besser im extra Thema.
 
  • Like
Reaktionen: Meeeenzer
Der Reset des Bootloaders/Entfernen der Crash-Meldung mit Konsolenzugriff geht nicht. Telnet ist ja deaktiviert und bei Zugriff über SSH (mit aktuellem Putty) wird der Loginversuch auch einfach abgewiesen.
Was auffällt: Die neuere Fritzbox hat laut Logfile die gleiche Hardware (Wenn man mit der Taschenlampe in das Gerät durch die Lüftungsschlitze sieht, Öffnen geht ja nicht, da ich die Garantie nicht verlieren will, sieht man, dass aber auf jeden Fall ein anderer Kühlkörper verbaut ist), jedoch bootet diese sehr viel schneller als die ältere mit dem Crash im Logfile.
Was auch sehr ungünstig ist: Wenn man die Logfiles einfach zurückstellen könnte, könnte man auch bei einem Neustart herausfinden, ob die Crash-Variablen wieder angelegt werden, so geht das natürlich nicht, wenn die immer erhalten bleibt.

Was macht das Recovery eigentlich anders, als das normale Firmware-Update? Sollte ich wegen dem langsameren Starten der Box das eventuell doch mal flashen? Eventuell stimmt mit dem Bootloader ja doch etwas nicht???
 
Gerade das Update auf die 7.01 gemacht. Als erstes gleich aufgefallen: Sync nicht mehr 109/42 sondern nur noch 99/37
 
Gleicher Fehler bei der 7590 7.01 wie bei der 7490 7.01, die Indexierung funktioniert nur bei neuen Ordnern und nicht bei den alten Ordnern wenn eine neue Datei auf dem NAS liegt. :(
 
@Ralf-Fritz:
Wie greifst Du denn zu?

Die früher per "inotify"-Schnittstelle aktive Überwachung der Speichervolumes (die ohnehin nicht vollständig war), gibt es nicht mehr. Will man den Index aktualisieren, muß man das manuell anstoßen oder über FRITZ!NAS zugreifen - siehe hier: https://service.avm.de/help/de/FRITZ-Box-Fon-WLAN-7490/017p2/hilfe_speicher_einstellungen

Wenn das nicht das "Gemeinte" ist, wäre eine etwas ausführlichere Darstellung des "Problems" sicherlich hilfreich (oder ein Verlinken auf die Stelle, wo das bereits beschrieben ist).
 
@Ralf-Fritz:


Die früher per "inotify"-Schnittstelle aktive Überwachung der Speichervolumes (die ohnehin nicht vollständig war), gibt es nicht mehr. Will man den Index aktualisieren, muß man das manuell anstoßen oder über FRITZ!NAS zugreifen ).

https://www.ip-phone-forum.de/threa...ase-vom-12-09-2018.300814/page-8#post-2296067

Alle Geräte die auf den Mediaplayer der Fritz!Box zugreifen z.B. SmartTV erhalten ja nur die Dateien angezeigt die auch Indexiert sind. Sollte eine Datei nicht Indexiert sein wird sie auch dort nicht angezeigt.
Deshalb stoße ich die Indexierung immer manuell über das Fritz!Fon an, und die Indexierung ist wieder vollständig. Bis zur Version 6.92 hat das auch noch wunderbar funktioniert, aber ab Version 7.00 bei der 7490 oder auch 7.01 bei der 7590, findet die manuelle Indexierung für den Mediaplayer der Fritz!Box nur in neuen Ordnern statt und nicht mehr in alten Ordnern.

Die Indexierung lässt die Ordner aus die schon mal Indexiert wurden, nur neue Ordner werden mit aufgenommen.
Bisher konnte ich das Problem nur umgehen das ich die Datei "fritznasdb_part.db3" komplett lösche, damit die Indexierung nur neue Ordner hat.
 
Mir ist ebenso ein Rätsel, warum AVM keinen Dienst/Service/Daemon (mehr) im Hintergrund laufen lässt der überwacht, ob neue Dateien hinzugefügt wurden. Eine komplette Neuindexierung jedesmal nach Start von Fitz!NAS... wozu?

Davon abgesehen sollte eine Indexierung zum schnelleren Auffinden / einer Suche dienen und nicht, ob überhaupt etwas sichtbar ist.
 
@Ralf-Fritz:
Das Verlinkte ist sicherlich tatsächlich ein Fehler ... was passiert denn, wenn Du Dir den Ordner mit der hinzugefügten Datei über FRITZ!NAS ansiehst? Erscheint sie dort (und in der Folge dann auch wieder im Index)?

Das mit dem Überwachen funktioniert nicht so ohne weiteres ... zumindest nicht bei größerer Anzahl von Dateien (hier findet man das API dafür: http://man7.org/linux/man-pages/man7/inotify.7.html und hier: https://lwn.net/Articles/605128/ einen etwas ausführlicheren Artikel).

Da muß man dann zuviele "inotify"-Überwachungen einrichten oder man beschränkt sich auf Ordner (noch "größere" Einheiten gibt es aber nicht) und kriegt dann trotzdem schon Änderungen zwei Ebenen tiefer nicht mehr mit - wenn da z.B. nur eine Datei zu einem bereits bestehenden Unterverzeichnis dazukommt. Also müßte man wieder alle Ordner unterhalb so eines Verzeichnisses überwachen ... das kostet nicht nur Speicher und Performance, es wird ab einer gewissen Anzahl von Verzeichnissen auch nicht mehr zur "Live-Überwachung" des Dateisystems reichen.

AVM hatte die Anzahl der Überwachungen schon extrem aufgeblasen:
Code:
# Set Inotify limit for Fritznasdb.
set_inotify_limit()
{
        if test -e /proc/sys/fs/inotify/max_user_watches ; then
                echo 30000 > /proc/sys/fs/inotify/max_user_watches
        fi
}
, aber was sind schon 30.000 Dateien angesichts der Größe heutiger Festplatten und bei einer "Musik-Sammlung".

Wer unbedingt "live" indizieren lassen will, muß in der "usb.cfg" die Einträge unter "nasdb" ändern (die setzt AVM beide auf "no") ... wie weit das am Ende gegen das beschriebene Problem hilft, weiß ich auch nicht (und ich glaube auch eher nicht, daß es hier hilft - nur wer wirklich wenige Dateien auf den Volumes hat, sollte den Index-Daemon mitlaufen lasse ... wobei der sich m.W. ohnehin nach einiger Langeweile selbst beendet). Ob der überhaupt noch "inotify events" verwendet für die Überwachung des Filesystems (in der neuen Version), müßte man auch erst mal prüfen.
 
Das Verlinkte ist sicherlich tatsächlich ein Fehler ... was passiert denn, wenn Du Dir den Ordner mit der hinzugefügten Datei über FRITZ!NAS ansiehst? Erscheint sie dort (und in der Folge dann auch wieder im Index)?

Wenn ich mir den Ordner über FRITZ!NAS anschaue erscheint die Datei auch nicht. Dort erscheint auch nur das was Indexiert wurde, ist die gleiche Ansicht wie am SmartTV.
 
Mir ist aufgefallen das ich nach dem Update von 7.00 auf 7.01 nicht mehr über fritz.box . In die Weboberfläche komme. Nur noch über die IP

Warum eigentlich ?
 
fritz.box funktioniert hier einwandfrei, sowohl mit FF, Chrome oder Opera
 
Moinsen


Vielleicht ein IPv6 Problem ?
...denn bei Nutzung einer DNS ( fritz.box ) besteht diese "Gefahr".
 
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.